en-US Sat, 08 Aug 2026 04:00:13 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-61808 Sat, 08 Aug 2026 00:00:02 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-48039 Sat, 08 Aug 2026 00:00:02 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-71847 Sat, 08 Aug 2026 00:00:02 +0000 https://github.com/advisories/GHSA-9hj4-r449-hfvc buffer)`. 3. It sets `parser->buffer = Qfalse`. 4. The parser-state pointers into the released buffer are not reset. 5. `partial_value` makes a shallow copy of the parser state. 6. Reconstructing an incomplete object containing duplicate keys reaches the duplicate-key warning path. 7. `cursor_position` walks through the stale input pointers and reads released memory. Relevant source locations: * Buffer release: https://github.com/ruby/json/blob/fd61def38b9bb859fee7eec8e7d3143600e5b347/ext/json/ext/parser/parser.c#L2562-L2569 * Parser-state copy: https://github.com/ruby/json/blob/fd61def38b9bb859fee7eec8e7d3143600e5b347/ext/json/ext/parser/parser.c#L2647-L2654 * Stale-pointer read in `cursor_position`: https://github.com/ruby/json/blob/fd61def38b9bb859fee7eec8e7d3143600e5b347/ext/json/ext/parser/parser.c#L590-L628 * Duplicate-key handling path: https://github.com/ruby/json/blob/fd61def38b9bb859fee7eec8e7d3143600e5b347/ext/json/ext/parser/parser.c#L1196-L1255 When input is supplied to the resumable parser, the parser state stores direct pointers into the backing Ruby string: ```c RSTRING_GETMEM(parser->buffer, start, len); parser->state.start = start; parser->state.end = start + len; parser->state.cursor = parser->state.start + offset; ``` After the current buffer has been consumed, `cResumableParser_parse` clears the string and removes the parser's reference to it: ```c if (eos(&parser->state)) { json_str_clear(parser->buffer); parser->buffer = Qfalse; } ``` This path does not invalidate or replace: ```text parser->state.start parser->state.cursor parser->state.end ``` `JSON::ResumableParser#partial_value` subsequently makes a shallow copy of the parser structure: ```c JSON_ResumableParser *original_parser = cResumableParser_get(self); JSON_ResumableParser parser = *original_parser; ``` When the partial object contains duplicate keys, reconstruction follows this call path: ```text cResumableParser_partial_value_body -> json_decode_object -> json_on_duplicate_key -> emit_duplicate_key_warning -> emit_parse_warning -> cursor_position ``` `cursor_position` then reads through pointers that may refer to released storage. AddressSanitizer reports: ```text ERROR: AddressSanitizer: heap-use-after-free cursor_position at parser.c:604 freed by cResumableParser_parse at parser.c:2567 ``` The reproducer follows the normal resumable-parser API sequence: ```ruby parser]]> Sat, 08 Aug 2026 01:00:02 +0000 https://thehackernews.com/2026/08/claude-code-and-gemini-cli-flaws-let.html Sat, 08 Aug 2026 04:00:13 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-12261 Sat, 08 Aug 2026 00:00:02 +0000 https://www.bleepingcomputer.com/news/artificial-intelligence/openai-rolls-out-a-major-chatgpt-upgrade-even-if-you-dont-pay-for-it/ Sat, 08 Aug 2026 04:00:13 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-70640 Fri, 07 Aug 2026 18:00:03 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-70639 Fri, 07 Aug 2026 18:00:03 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-70638 Fri, 07 Aug 2026 18:00:03 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-67622 Fri, 07 Aug 2026 18:00:03 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-67621 Fri, 07 Aug 2026 18:00:03 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-43632 Fri, 07 Aug 2026 18:00:03 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-43631 Fri, 07 Aug 2026 18:00:03 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-43630 Fri, 07 Aug 2026 18:00:03 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-43629 Fri, 07 Aug 2026 18:00:03 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-43628 Fri, 07 Aug 2026 18:00:03 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-43627 Fri, 07 Aug 2026 18:00:03 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-19111 Fri, 07 Aug 2026 18:00:03 +0000 https://github.com/advisories/GHSA-x677-9fxg-v5c5 "When the backend normalizes underscore and dash header forms equivalently, an attacker can inject spoofed trust context — such as a trusted scheme or host — through the alias headers and bypass authentication on protected routes without valid credentials." The same threat model applies to the operator-configurable `headerField` (BasicAuth, DigestAuth) and `authResponseHeaders` (ForwardAuth, ingress-nginx snippet provider), but the underscore-handling primitive (`isManagedXHeader`) was not extended to those middlewares. I verified the bypass end-to-end on `traefik:v3.6.14` (the latest patched release containing both fixes) using a default-recommended canonical `headerField: "X-Auth-User"` config and reproduced the bypass with a single `curl -H "X_Auth_User: superadmin" ...` request alongside valid BasicAuth credentials. The defect is present in four code paths at HEAD `eec68dce064f843b4317c4393aaea81b6dea31d6`: 1. `pkg/middlewares/auth/basic_auth.go:101-105` — BasicAuth `headerField` 2. `pkg/middlewares/auth/digest_auth.go:99-103` — DigestAuth `headerField` 3. `pkg/middlewares/auth/forward.go:304-310` — ForwardAuth `authResponseHeaders` per-name writeback 4. `pkg/middlewares/ingressnginx/snippet/snippet.go:480-486` — Ingress-NGINX snippet `authResponseHeaders` per-name writeback The ForwardAuth instance (#3) is particularly notable: the attacker does NOT need credentials. The `authResponseHeaders` mechanism is intended to copy identity headers from the trusted auth server only; the underscore-variant bypass lets an unauthenticated attacker pre-inject the same identity header before any auth happens. The fast proxy at `pkg/proxy/fast/proxy.go:139` explicitly calls `DisableNormalizing()` on the outgoing fasthttp request, guaranteeing that the underscore-variant header reaches the backend wire verbatim. The standard `httputil.ReverseProxy` path at `pkg/proxy/httputil/proxy.go:55` likewise copies `req.Header` keys as-is during the wire write. ## Affected versions - `traefik` v3.6.x ≤ 3.6.14, v3.7.x ≤ 3.7.0-rc.2, v2.11.x ≤ 2.11.43, and all earlier versions sharing the same auth middleware architecture. The defect is present at HEAD post-CVE-2026-33433 fix (the fix added the `Del` line but the literal-key write defect-class survives for underscore variants). ## Root cause In `pkg/middlewares/auth/basic_auth.go` at HEAD `eec68dc`: ```go if b.headerField != "" { // TODO Deprecated we should add the header with canonical key. req.Header.Del(b.headerField) req.Header[b.headerField] = []string{user} } ``` The TODO comment shows the maintainer is aware of the literal-key write problem in general (canonical-key write would solve the case-canonicalization issue more cleanly than the current `Del` + literal-write pair). The comment does not acknowledge the underscore-variant survival corollary. `pkg/middlewares/auth/digest_auth.go:99-103` and the two ForwardAuth paths follow the same `Del` + literal-write pattern. Each is independently exploitable; the underlying primitive defect is shared. The maintainer's gold-standard primitive for handling this exact threat class is `pkg/middlewares/forwardedheaders/forwarded_header.go:53-66`: ```go func isManagedXHeader(key string) bool { if len(key) == 0 || key[0] != 'X' { return false } if _, ok := XHeadersSet[key]; ok { return true } if strings.IndexByte(key, '_') < 0 { return false } canonical := http.CanonicalHeaderKey(strings.ReplaceAll(key, "_", "-")) _, ok := XHeadersSet[canonical] return ok } ``` This treats `_` ↔ `-` equivalence as a security requirement. It is reachable only via the static `XHeadersSet` membership check, which contains exclusively the X-Forwarded-* family + X-Real-Ip. Operator-configurable identity headers are out of scope of this primitive. ## Proof of concept Verified on `traefik:v3.6.14` (the patched version, post-CVE-2026-33433 and post-CVE-2026-39858) using Docker compose. Full reproducer at https://github.com//traefik-ht1a-poc; commands below are verbatim. ### Setup ```yaml # docker-compose.yml services: traefik: image: traefik:v3.6.14 command: - --providers.file.filename=/etc/traefik/dynamic.yml - --entrypoints.web.address=:80 ports: - "8080:80" volumes: - ./traefik/dynamic.yml:/etc/traefik/dynamic.yml:ro echo: image: mendhak/http-https-echo:36 environment: - HTTP_PORT=8888 ``` ```yaml # traefik/dynamic.yml — canonical headerField, recommended operator config http: routers: protected: rule: "PathPrefix(`/`)" service: echo middlewares: [basic-auth] services: echo: loadBalancer: servers: [{url: "http://echo:8888"}] middlewares: basic-auth: basicAuth: users: - 'alice:$2b$05$FhDfYidZdDPuQjovYqcTAe22wHpQ/cILC7Tr2yAD6vLlvZh/Q45PC' # alice:secret123 headerField: "X-Auth-User" ``` `docker compose up -d`. ### Test 1 (control — CVE-2026-33433 fix works for canonical case) ```bash $ curl -s -u alice:secret123 -H "X-Auth-User: superadmin" http://localhost:8080/ { ... "x-auth-user": "alice", ... } ``` The attacker's canonical `X-Auth-User: superadmin` was correctly stripped by Traefik's `Del`; the backend receives only Traefik's authenticated-user writeback `alice`. ### Test 2 (HT-1A bypass — underscore variant survives) ```bash $ curl -s -u alice:secret123 -H "X_Auth_User: superadmin" http://localhost:8080/ { ... "x-auth-user": "alice", "x_auth_user": "superadmin", ... } ``` The underscore-variant `x_auth_user: superadmin` reached the backend intact, despite the `Del("X-Auth-User")` having executed. The backend sees both forms. ### Test 3 (double-send — same result) ```bash $ curl -s -u alice:secret123 \ -H "X-Auth-User: superadmin" \ -H "X_Auth_User: superadmin" \ http://localhost:8080/ { ... "x-auth-user": "alice", # Traefik's writeback "x_auth_user": "superadmin", # attacker's underscore — survived Del ... } ``` The canonical attacker header is stripped (Test 1 behavior). The underscore variant is forwarded. ### Backend impact The PoC's echo backend (`mendhak/http-https-echo`, Node.js) preserves both forms with the lowercase normalization Node.js applies. Application code reading `req.headers["x-auth-user"]` sees `alice`. Application code reading `req.headers["x_auth_user"]` sees `superadmin`. For backends that normalize `_` ↔ `-` equivalently — meaning the attacker's value wins: - **CGI / WSGI / PHP `$_SERVER`** (RFC 3875 §4.1.18 — header name uppercased with `-` replaced by `_`): both `X-Auth-User` and `X_Auth_User` map to `HTTP_X_AUTH_USER`. The last-set wins per the WSGI server's iteration order; many servers (gunicorn, uwsgi without `--disable-logging`, waitress) preserve both. Note: Apache + mod_php with default `HttpProtocolOptions Strict` filters underscore-headers from `$_SERVER` (this PoC's PHP backend test demonstrated the filter); Apache + mod_python, Apache + mod_wsgi without the strict mode, nginx + uwsgi, nginx + gunicorn, nginx + FastCGI, and standalone WSGI servers do NOT filter. - **nginx with `underscores_in_headers on`** (https://nginx.org/en/docs/http/ngx_http_core_module.html#underscores_in_headers): preserves underscore-variant headers and forwards them to upstream as separate values. Upstream application logic that does case-insensitive + underscore-insensitive matching (common pattern in security-sensitive code) merges them. - **Tomcat / Java EE servlet containers**: `HttpServletRequest.getHeader(name)` is case-insensitive; underscore handling is container-specific. Many normalize. - **Application middleware** (WAFs, log aggregators, security gateways, identity-aware proxies) that normalize header names before applying security policy: both forms collapse to the same authorization decision input. ## Severity I propose **HIGH CVSS 7.5** for the BasicAuth / DigestAuth case and **CRITICAL CVSS 9.1** for the ForwardAuth `authResponseHeaders` case (the latter requires no credentials). **CVSS 3.1 vector (BasicAuth / DigestAuth)**: `AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N=7.5` — one step above CVE-2026-33433 (which the maintainer scored MEDIUM 5.1 because it required misconfigured non-canonical `headerField`). HT-1A works against the canonical / recommended `headerField` configuration, broader operational scope. **CVSS 3.1 vector (ForwardAuth `authResponseHeaders`)**: `AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N=9.1` — parallel to CVE-2026-39858 (HIGH 7.5) but achieves spoofing without credentials because the `authResponseHeaders` mechanism trusts headers exclusively from the auth server and the underscore variant defeats that trust boundary. CWEs: - CWE-290 (Authentication Bypass by Spoofing) - CWE-178 (Improper Handling of Case Sensitivity) — analogous to CVE-2026-29054 - CWE-345 (Insufficient Verification of Data Authenticity) — same as CVE-2026-35051 ## Suggested fix Two equivalent approaches: **1. Extend `Header.Del` to handle underscore variants** at the four call sites. Replace: ```go req.Header.Del(b.headerField) req.Header[b.headerField] = []string{user} ``` with: ```go canonical := http.CanonicalHeaderKey(b.headerField) // Strip canonical AND underscore-variant of the canonical key. for key := range req.Header { if key == canonical || strings.EqualFold(strings.ReplaceAll(key, "_", "-"), canonical) { delete(req.Header, key) } } req.Header.Set(canonical, user) // canonical-key write ``` This pairs the headerField primitive with the same `_` ↔ `-` equivalence that `isManagedXHeader` enforces for X-Forwarded-*. **2. Generalize the existing `isManagedXHeader` primitive** into a `stripHeaderAndVariants(headers http.Header, name string)` helper in the `forwardedheaders` package and call it from `basic_auth.go`, `digest_auth.go`, `forward.go`, and `snippet.go`. Reusing the existing gold-standard primitive is the cleanest fix and minimizes future drift. Either approach should also resolve the `// TODO Deprecated we should add the header with canonical key.` debt at `basic_auth.go:102` and `digest_auth.go:100` by writing to the canonical key (`Header.Set(canonical, user)`) instead of the literal `b.headerField`. ## Why this is a Pattern-8 sibling, not a new CVE class The combination of: 1. CVE-2026-33433's fix scope (case-canonicalization for `headerField`) 2. CVE-2026-39858's fix scope (underscore-variant for `XHeadersSet`) 3. The defective primitive remaining at HEAD (the `Del` + literal-write pair at four call sites) establishes that the maintainer accepts the threat model and has architectural primitives to fix it — but did not cross the two cohorts. The "primitive depth-audit" of the CVE-2026-33433 fix (reading the actual `Header.Del` implementation against the documented threat model and Go's canonicalization semantics) reveals the gap. I confirmed there is no public PoC mentioning underscore-variant siblings of CVE-2026-33433 (WebSearched 2026-05-23). The fix-flurry from the April 2026 security release batch addressed the X-Forwarded family but not the headerField family. ## Credit Matteo Panzeri (GitHub `matte1782`). CVE credit requested. ## AI-assistance disclosure Static analysis, hypothesis writing, and hostile-review confirmation were assisted by Anthropic Claude (Opus 4.7). Live PoC reproduction, code-citation verification, and submission decision were made by the human author. ---]]> Fri, 07 Aug 2026 01:00:02 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-43622 Fri, 07 Aug 2026 12:00:06 +0000 https://www.bleepingcomputer.com/news/security/meta-ai-model-hacked-a-company-during-misconfigured-cyber-test/ Sat, 08 Aug 2026 04:00:13 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-19039 Fri, 07 Aug 2026 12:00:06 +0000 https://www.securityweek.com/zero-click-ai-browser-hacking-claude-and-chatgpt-atlas-hijacked-via-emails-x-posts/ Sat, 08 Aug 2026 04:00:13 +0000 https://thehackernews.com/2026/08/ai-recommendation-poisoning-how-ask-ai.html Sat, 08 Aug 2026 04:00:13 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-57819 Fri, 07 Aug 2026 06:00:19 +0000 https://www.securityweek.com/meta-ai-hacked-external-systems-during-cybersecurity-testing/ Fri, 07 Aug 2026 10:00:01 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-64583 bdc_mem_free() manually before returning: bdc_udc_exit() tears down individual endpoint objects via bdc_free_ep(), while bdc_hw_exit() -> bdc_mem_free() frees and NULLs the DMA-coherent status-report ring (bdc->srr.sr_bds) and kfree()s bdc->bdc_ep_array. Both happen while the IRQ handler (bdc_udc_interrupt, requested with IRQF_SHARED) remains deliverable in the window up to the post-remove devm free_irq(). On receipt of a shared interrupt in that window, bdc_udc_interrupt() dereferences bdc->srr.sr_bds[bdc->srr.dqp_index] (NULL or freed DMA) and dispatches sr_handler callbacks that index into bdc_ep_array, causing a NULL-deref or use-after-free. The same window affects the delayed_work bdc->func_wake_notify, which is armed from the IRQ handler via bdc_sr_uspc() -> handle_link_state_change() -> schedule_delayed_work() and may self-rearm from its own callback bdc_func_wake_timer(). No cancel exists anywhere in the driver, so a queued work item that fires after bdc_remove() returns and the bdc structure is devm-freed dereferences freed memory. Replace devm_request_irq() with request_irq() and add an explicit free_irq(bdc->irq, bdc) in bdc_remove(). Clear BDC_GIE before free_irq() to stop the device from asserting interrupts, then free_irq() drains any in-flight handler, then cancel_delayed_work_sync() drains the func_wake_notify delayed work. This ordering ensures the IRQ handler and delayed work cannot interfere with the subsequent endpoint and DMA teardown in bdc_udc_exit() and bdc_hw_exit(). Wire the matching free_irq() into the bdc_udc_init() error path so the IRQ is released on probe failure, and route the bdc_init_ep() failure through err0 instead of returning directly. This issue was found by an in-house static analysis tool.]]> Fri, 07 Aug 2026 06:00:19 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-19019 Fri, 07 Aug 2026 06:00:19 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-19005 Fri, 07 Aug 2026 06:00:19 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-67531 Fri, 07 Aug 2026 00:00:10 +0000 https://huggingface.co/blog/baseten Sat, 08 Aug 2026 04:00:13 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-69111 Thu, 06 Aug 2026 18:00:08 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-66298 Thu, 06 Aug 2026 18:00:08 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-18954 Thu, 06 Aug 2026 18:00:08 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-9205 Thu, 06 Aug 2026 18:00:08 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-9201 Thu, 06 Aug 2026 18:00:08 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-9196 Thu, 06 Aug 2026 18:00:08 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-9130 Thu, 06 Aug 2026 18:00:08 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-8478 Thu, 06 Aug 2026 18:00:08 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-8470 Thu, 06 Aug 2026 18:00:08 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-8183 Thu, 06 Aug 2026 18:00:08 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-8182 Thu, 06 Aug 2026 18:00:08 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-7869 Thu, 06 Aug 2026 18:00:08 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-7658 Thu, 06 Aug 2026 18:00:08 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-48168 Thu, 06 Aug 2026 18:00:08 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-17633 Thu, 06 Aug 2026 18:00:08 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-17632 Thu, 06 Aug 2026 18:00:08 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-17624 Thu, 06 Aug 2026 18:00:08 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-10547 Thu, 06 Aug 2026 18:00:08 +0000