### Impact h2 <=4.4.0 accepts request header blocks containing more than one Host header, and forwards every Host header to the consuming application. Where the consumer downgrades HTTP/2 to HTTP/1.1, the resulting request carries two Host header lines, which is a request smuggling primitive (CWE-444). ### Patches Patched and fixed in v4.4.1 ### Workarounds Users of the h2 library are advised to check and follow HTTP semantics best practices in their application code. h2 provides best effort sanity checks, but ultimately the calling code is responsible to ensure proper and safe usage of HTTP/2 as provided by h2, hyperframe, and hpack. ### References Similar to the previously disclosed and fixed duplicate content-length issue.

Craft CMS (composer package craftcms/cms) versions >= 5.5.0 and <= 5.9.13 contain a remote code execution vulnerability in the FieldsController::actionRenderCardPreview() method, which passes the fieldLayoutConfig POST parameter directly to Fields::createLayout() without calling Component::cleanseConfig(). An authenticated admin user can inject Yii2 event handlers (e.g., 'on init' keys) via the fieldLayoutConfig parameter to execute arbitrary PHP code and disclose sensitive information (such as environment variables containing database credentials and CRAFT_SECURITY_KEY). The issue is fixed in version 5.9.14.

Craft CMS 4.x (>= 4.0.0-RC1, < 4.17.0-beta.1) and 5.x (>= 5.0.0-RC1, < 5.9.0-beta.1) contain multiple stored cross-site scripting vulnerabilities where settings names and field option labels are rendered without sanitization (e.g., via the checkbox.twig template, which used {{ label|raw }}). An authenticated administrator (with allowAdminChanges enabled) can inject malicious payloads into section names, volume names, user group names, global set names, generated field names, checkbox/radio option labels, and custom source labels, causing arbitrary JavaScript to execute in other users' control-panel sessions. Fixed in 4.17.0-beta.1 and 5.9.0-beta.1.

Craft CMS from version 5.0.0-RC1 contains a stored cross-site scripting vulnerability in the User Permissions page where user group names are rendered without proper HTML escaping. Attackers with admin access can inject arbitrary JavaScript via the user group name field that executes when other users view or edit permissions.

### Impact PHP_CodeSniffer versions before v3.13.6 and v4.0.2 contain a command injection vulnerability in the code creating the `Gitblame`, `Hgblame` and `Svnblame` report(s). As a result, running PHP_CodeSniffer over untrusted files, for example, in a CI pipeline that scans pull requests, or on a developer machine reviewing third-party code, could result in attacker-controlled shell commands being executed when the `Gitblame`, `Hgblame` or `Svnblame` report(s) would process a file whose name contains shell metacharacters. * Users using the default `Full` report, or any of the other non-*blame reports, are not affected. * Users on a runtime platform which does not allow filenames to contain shell metacharacters, such as `"` and `;`, are not affected. ### Patched versions The issue has been fixed in PHP_CodeSniffer v3.13.6 and v4.0.2. We recommend all users upgrade to these versions at their earliest convenience. ### Workaround Users of PHP_CodeSniffer who cannot upgrade immediately should ensure they do not use the `Gitblame`, `Hgblame` or the `Svnblame` reports when scanning untrusted code. This is especially relevant for CI jobs, pre-commit or review tooling, automated review services, and any service that scans untrusted repositories or uploaded source trees. ### Credits Many thanks to both [@Faze-up](https://github.com/Faze-up) and [@edorian](https://github.com/edorian) for responsibly disclosing this vulnerability. ### How can I report a security bug? Please report security vulnerabilities privately via [the "Security and quality" tab on the PHP_CodeSniffer repository](https://github.com/PHPCSStandards/PHP_CodeSniffer/security).

## Summary `re2` infers a character's byte length from its UTF-8 lead byte alone, with no bound on the bytes actually remaining in the input. `Buffer` arguments reach the native layer verbatim — only strings are re-encoded into well-formed UTF-8 — so a `Buffer` whose last byte is a multi-byte lead promises continuation bytes that are not there, and the result builders read up to 3 bytes past the end of the buffer. In `replace()` and `split()` those bytes are copied into the returned `Buffer`, disclosing adjacent heap memory to JavaScript. The trigger is deterministic and requires no special heap grooming. Only `Buffer` input is affected. String input was never at risk: re-encoding guarantees every multi-byte sequence is complete. ## Root cause `getUtf8CharSize` maps a lead byte to a length of 1–4 and never sees the input size: ```cpp // lib/wrapped_re2.h inline size_t getUtf8CharSize(char ch) { return ((0xE5000000 >> ((ch >> 3) & 0x1E)) & 3) + 1; } ``` Callers then read that many bytes. In the zero-width branch of `replace()`, the guard proves only that at least *one* byte remains: ```cpp // lib/replace.cc else if ((size_t)offset < size) { auto sym_size = getUtf8CharSize(data[offset]); // may claim up to 4 bytes result.append(data + offset, sym_size); // reads data[offset .. offset + 3] byteIndex = offset + sym_size; } ``` `offset < size` permits `offset == size - 1`, so a lead byte of `0xF0` makes `append` read `data[size]`, `data[size + 1]` and `data[size + 2]`. Seven read sites shared the defect: | Site | Argument | Disclosed to JS | |---|---|---| | `lib/replace.cc` (zero-width branch) | subject | yes | | `lib/replace.cc` (callback replacer) | subject | yes | | `lib/replace.cc` (replacement scan) | replacement | yes | | `lib/split.cc` | subject | yes | | `lib/pattern.cc` `translateRegExp` (x2) | pattern | no | | `lib/pattern.cc` `escapeRegExp` | pattern | no | Three further callers were **not** vulnerable, because they use the result only to advance an index and never dereference past the end: `getUtf16PositionByCounter` in `lib/wrapped_re2.h` (clamps its return to the buffer size), `lib/match.cc` (the value feeds `RE2::Match`, which rejects `startpos > endpos`), and the `getMaxSubmatch` scan in `lib/replace.cc` (an overshoot just ends the loop). ## Proof of concept Each call returns more bytes than were supplied; the trailing bytes are heap contents and vary between runs. ```js const RE2 = require('re2'); const hex = buf => [...buf].map(b => b.toString(16).padStart(2, '0')).join(' '); // subject: 2 bytes in, 5 bytes out console.log(hex(new RE2('', 'g').replace(Buffer.from([0x41, 0xf0]), ''))); // 41 f0 61 7b eb <- last 3 bytes are adjacent heap memory // replacement argument console.log(hex(new RE2('A', 'g').replace(Buffer.from('A'), Buffer.from([0x42, 0xf0])))); // 42 f0 41 26 d6 // split console.log(new RE2('', 'g').split(Buffer.from([0x41, 0xf0])).map(hex)); // [ '41', 'f0 e2 e4 df' ] ``` `0xC2` (2-byte lead) and `0xE2` (3-byte lead) over-read 1 and 2 bytes respectively; `0xF0` over-reads 3. For the pattern path the over-read occurs in `translateRegExp` / `escapeRegExp`, which run before RE2 validates the pattern, but RE2 then rejects the malformed input, so the bytes are discarded rather than returned: ```js new RE2(Buffer.from([0xf0])); // SyntaxError: invalid UTF-8 — read already happened ``` ## Impact **Information disclosure (`replace`, `split`).** Up to 3 bytes of heap memory adjacent to the input buffer are returned to JavaScript per call. The read is repeatable, so an attacker who controls `Buffer` input and observes output can sample heap memory incrementally. What lands there depends on allocator layout and is not directly steerable, but it may include fragments of other buffers. **Out-of-bounds read (pattern compilation).** No disclosure path, since the malformed pattern is rejected — but the read is still undefined behavior and can fault if the buffer ends on a page boundary. Applications that pass only strings, or only well-formed UTF-8 buffers, are unaffected. The exposure matters most where `re2` is used as intended: running patterns or subjects derived from untrusted input. ## Suggested fix Clamp the inferred character size to the bytes that actually remain, at every site whose result indexes the buffer: ```cpp inline size_t getUtf8CharSize(char ch, size_t remaining) { size_t size = getUtf8CharSize(ch); return size < remaining ? size : remaining; } ``` This is O(1) and changes no algorithm's complexity. A truncated tail then round-trips as the bytes it really holds, which preserves the documented contract that `Buffer` input is passed through verbatim. Rejecting malformed UTF-8 in `Buffer` input would also close the hole, but is a breaking API change. ## Resolution Fixed in `[email protected]`. All seven read sites now clamp the character size to the remaining input, so a `Buffer` ending in a truncated multi-byte character round-trips as its own bytes instead of reading past the end. Regression tests cover the subject, replacement and pattern positions for 2-, 3- and 4-byte leads, including partially truncated sequences. **Remediation:** upgrade to `[email protected]` or later. **Workaround** (if you cannot upgrade): pass strings rather than `Buffer`s, or validate that `Buffer` input is well-formed UTF-8 before calling `replace`, `split`, or the `RE2` constructor — for example `Buffer.compare(Buffer.from(buf.toString('utf8')), buf) === 0`. Reported by [@OvOhao](https://github.com/OvOhao) in [#272](https://github.com/uhop/node-re2/issues/272).

### Impact If PDF.js is used to load a malicious PDF, and PDF.js is configured with `enableScripting` set to true (which is the default value) and no CSP for disallowing script-src, unrestricted attacker-controlled JavaScript will be executed in the context of the hosting domain. ### Patches ### Workarounds Set `enableScripting` to `false` or set a CSP.

When a custom `Safelist` permits certain raw-text elements, jsoup may incorrectly sanitize malformed HTML containing a tag name that ends in a control character. The tag may acquire the parsing behavior of a different element, causing content that should remain text to be emitted as active markup after serialization and potentially allowing XSS. jsoup’s built-in Safelists are unaffected. ## Patches Upgrade to jsoup 1.23.1. ## Workarounds Until upgrading, do not permit raw-text elements in custom Safelists used to clean untrusted HTML. ## Additional security considerations This fix addresses malformed tag-name handling only. Permitting raw-text elements in a custom `Safelist` does not make their contents inherently safe. For example, applications that permit `style` must apply appropriate CSS safeguards separately, because jsoup does not parse or sanitize CSS.

Craft CMS contains a missing authorization vulnerability in the assets/preview-thumb endpoint. A Control Panel user without permission to view a target private asset can call the endpoint with an attacker-controlled assetId and receive preview HTML containing a signed fallback transform preview link for that private asset, because no asset-view permission check is performed before preview generation. This affects versions >= 4.0.0-RC1, <= 4.17.7 and >= 5.0.0-RC1, <= 5.9.13, and is fixed in 4.17.8 and 5.9.14.

A vulnerability was detected in Craft CMS up to 4.18.0.1. Affected is the function actionReorderSets of the file src/controllers/GlobalsController.php of the component reorder-sets Endpoint. The manipulation results in authorization bypass. The attack can be executed remotely. Upgrading to version 4.18.1 is able to address this issue. The patch is identified as 9bd05c91e6a7e6da5e949ec41a31c220c059aa04. The affected component should be upgraded.

Craft CMS contains a stored cross-site scripting (XSS) vulnerability in the editableTable.twig component when using the 'Row Heading' column type. The application fails to sanitize input within row heading default values, allowing an attacker with an administrator account (with allowAdminChanges enabled) to inject arbitrary JavaScript that executes when another user views a page containing the affected table field. Affected versions are >= 4.5.0-beta.1 through 4.16.18 and >= 5.0.0-RC1 through 5.8.22; fixed in 4.16.19 and 5.8.23.

### Impact Affected versions of `league/commonmark` can have quadratic time complexity when parsing specially crafted Markdown lines. In practical terms, doubling the length of an affected line can make the parser perform roughly four times as much work. The parser identifies locations using character positions, but regular-expression matches report byte positions. These positions differ when a UTF-8 character uses more than one byte. Several parsing paths repeatedly rescan growing portions of the line to translate between the two positions. The Autolink extension can also copy and validate the remaining line at every URL-like prefix. In current 2.x releases, a single non-ASCII character anywhere on a line can place that whole line on the slower multibyte path. An attacker can combine it with a long run of leading whitespace or repeated Markdown punctuation, causing increasingly large rescans. When the Autolink extension is enabled, repeated URL-like prefixes provide another trigger, even on ASCII-only lines. Each trigger fits within one long line, so complex Markdown structure is unnecessary. An attacker who can submit Markdown for conversion can use a comparatively small request to consume disproportionate CPU time and allocation activity. Repeated or concurrent requests can occupy all available PHP workers and prevent legitimate requests from completing. The core paths affect `CommonMarkConverter`, `GithubFlavoredMarkdownConverter`, and custom environments. The autolink-specific path affects applications using `AutolinkExtension` or `GithubFlavoredMarkdownExtension`. Applications that process only trusted Markdown are not remotely exploitable. The impact is limited to availability: it does not disclose data, change rendered output, or bypass rendering restrictions. Settings such as `html_input` and `allow_unsafe_links` do not mitigate the issue because the expensive work occurs before rendering. ### Patches The issue is patched in `2.9.0` and later. Starting in that release, the parser records UTF-8 character-to-byte positions incrementally, converts ordered regular-expression match positions without restarting from the beginning of the line, and matches autolinks against the original line instead of copying every remaining suffix. The affected work then grows in direct proportion to the input size while preserving existing Markdown output and configuration behavior. Versions from `0.6.0` through `2.8.3` are affected. The 0.x and 1.x release lines are no longer supported, so their users must upgrade to `2.9.0` or later. ### Workarounds If you cannot upgrade immediately, reject or truncate inputs with excessively long individual lines before passing them to the converter. A total request-size limit is also useful, but a per-line limit is important because every demonstrated trigger fits on one line. Choose limits appropriate for the application and enforce them before Markdown parsing begins. Restricting conversion to trusted users, applying strict execution-time limits, rate-limiting requests, and limiting concurrent conversions can further reduce exposure, but these measures are not complete substitutes for upgrading. Disabling `AutolinkExtension` and avoiding `GithubFlavoredMarkdownExtension` removes the autolink-specific trigger, but the core multibyte parsing paths remain reachable in the standard parser. Existing nesting, delimiter, raw-HTML, and unsafe-link configuration options do not eliminate all affected paths. Applications that must continue processing untrusted Markdown should therefore enforce input limits even when autolinking is disabled.

Netty is an asynchronous, event-driven network application framework. Prior to versions 4.1.136.Final and 4.2.16.Final, ab attacker can force WebSocket upgrade via the lax V07 (or V08) handshaker by sending `Sec-WebSocket-Version: 7` and omitting `Connection: Upgrade` / `Upgrade: websocket` headers, completing a protocol switch that a proxy would not recognize as an Upgrade request and enabling HTTP request smuggling / protocol-confusion attacks. This issue has been fixed in versions 4.1.136.Final and 4.2.16.Final.

Netty is an asynchronous, event-driven network application framework. In versions prior to 4.1.136.Final and 4.2.16.Final, Netty's STOMP encoder ( StompSubframeEncoder ) does not escape or validate header values in  CONNECT  and  CONNECTED  frames, so raw newline ( \n ) characters in a header value are written directly to the wire, allowing an attacker who controls a header value to inject additional STOMP headers. This happens because the encoder intentionally skips escaping for CONNECT/CONNECTED frames per the STOMP 1.2 specification but never rejects the raw newlines, and since a broker parses each line as a separate header, an attacker controlling a value such as a user-supplied login or passcode can overwrite connection parameters or add authentication/role headers to bypass authentication or escalate privileges (the actual impact is broker-dependent). The issue is fixed in versions 4.1.136.Final and 4.2.16.Final.

Netty is an asynchronous, event-driven network application framework. In versions prior to 4.1.136.Final and 4.2.16.Final, Netty's HAProxy encoder ( HAProxyMessageEncoder ) writes AF_UNIX source and destination socket addresses into the HAProxy V1 text protocol without validating them for CRLF characters, so an attacker who controls an AF_UNIX address can inject  \r\n  sequences and split the single PROXY header into multiple lines. This is possible because the V1 protocol uses CRLF as its line terminator and, unlike IPv4/IPv6 addresses whose format checks implicitly reject CRLF, AF_UNIX addresses are only validated for length (up to 108 bytes), allowing a forged second PROXY header line that spoofs the client source/destination IP to a downstream server or load balancer. The issue is fixed in versions 4.1.136.Final and 4.2.16.Final.

## Summary The `AttributesExtension`'s `href`/`src` unsafe-link filter (`AttributesHelper::filterAttributes()`) can be bypassed by embedding control bytes in a `javascript:` URL that browsers discard before parsing the scheme. Two variants: - **Tab/newline inside the scheme** — a literal ASCII TAB (0x09), CR (0x0D), or LF (0x0A), e.g. `java<TAB>script:alert(1)`. Per the WHATWG URL Standard's "basic URL parser" step 3, browsers "remove all ASCII tab or newline from input". - **Leading C0 controls** — e.g. `<0x01>javascript:alert(1)`. Per step 1 of the same algorithm, browsers remove any leading or trailing C0 control or space. (A leading *space* alone does not bypass, because `parseAttributes()` already `trim()`s the value; other C0 bytes are not trimmed.) The filter is a literal anchored-prefix regex (`RegexHelper::isLinkPotentiallyUnsafe()` / `REGEX_UNSAFE_PROTOCOL`) that matches neither obfuscated form, so in both cases the browser still executes `javascript:alert(1)`. **This is confirmed reproducible even with `allow_unsafe_links => false` set** — i.e. even applications that have followed the library's own documented hardening guidance for untrusted input remain exploitable. This is a *sibling gap* in the same defense that CVE-2025-46734 (GHSA-3527-qv2q-pfvx) fixed in v2.7.0 — that fix made `href`/`src` respect `allow_unsafe_links`, but did not normalize control bytes before checking, so these obfuscation techniques were never covered. ## Vulnerability **Files**: - `src/Util/RegexHelper.php:69` (`REGEX_UNSAFE_PROTOCOL`), `:239-242` (`isLinkPotentiallyUnsafe()`) - `src/Extension/Attributes/Util/AttributesHelper.php:149-179` (`filterAttributes()`) **CWE**: CWE-79 (Improper Neutralization of Input During Web Page Generation / XSS) — primary - CWE-692 (Incomplete Denylist to Cross-Site Scripting) — the anchored-prefix denylist in `REGEX_UNSAFE_PROTOCOL` is incomplete. This is a composite of CWE-184 and CWE-79, so it captures the full "incomplete denylist → XSS" chain on its own. - CWE-86 (Improper Neutralization of Invalid Characters in Identifiers in Web Pages) — the specific evasion technique: control bytes embedded within the URI scheme identifier, which the browser strips before resolving it. ### Root Cause ```php // src/Util/RegexHelper.php public const REGEX_UNSAFE_PROTOCOL = '/^(?:javascript|vbscript|file|data):/i'; public static function isLinkPotentiallyUnsafe(string $url): bool { return \preg_match(self::REGEX_UNSAFE_PROTOCOL, $url) !== 0 && \preg_match(self::REGEX_SAFE_DATA_PROTOCOL, $url) === 0; } // src/Extension/Attributes/Util/AttributesHelper.php foreach ($attributes as $name => $value) { $attrNameLower = \strtolower($name); if (! $allowUnsafeLinks && ($attrNameLower === 'href' || $attrNameLower === 'src') && \is_string($value) && RegexHelper::isLinkPotentiallyUnsafe($value)) { unset($attributes[$name]); continue; } ... ``` The Attributes extension's own quote-value grammar (`PARTIAL_DOUBLEQUOTEDVALUE = '"[^"]*"'`) accepts any byte except `"` inside quotes, including raw tab/CR/LF and other C0 controls, and `parseAttributes()` only `trim()`s (leading/trailing, and only the default charlist `" \t\n\r\0\x0B"` — so a leading `\x01` survives). Critically, **the core Markdown link-destination path (`LinkParserHelper` → `UrlEncoder::unescapeAndEncode()`) percent-encodes every control byte before this same safety check ever runs — but the Attributes extension's `href`/`src` handling has no equivalent normalization step**, so the raw control byte reaches both the check and the final HTML output (`Xml::escape()` only escapes `& < > " '`, not tab/CR/LF, since they're legal bytes inside an HTML attribute). ### Attack Scenario 1. An application enables the (commonly-used) `AttributesExtension` and sets `allow_unsafe_links => false` — the project's own documented hardening step for untrusted input. 2. An attacker submits Markdown: `[Click me](javascript:alert(0)){href="java<TAB>script:alert(document.cookie)"}` (TAB is one literal 0x09 byte). 3. The library emits `<a href="java<TAB>script:alert(document.cookie)">Click me</a>` — `isLinkPotentiallyUnsafe()` doesn't match the tab-split scheme, so the filter takes no action. 4. A victim viewing/clicking the link has the browser strip the embedded TAB and execute `javascript:alert(document.cookie)` in the victim's session — stored XSS, cookie theft, account takeover potential. **Why the payload needs an unsafe core destination.** Step 2 above deliberately uses `[Click me](javascript:alert(0))` rather than a normal link. `LinkRenderer` overwrites `attrs['href']` with the node's own URL *unless* that URL is itself judged unsafe — so `[x](https://example.com){href="java<TAB>script:..."}` renders the harmless `href="https://example.com"`, and an empty destination `[x](){href="..."}` renders `href=""`. The attacker therefore supplies a core destination that the filter *does* catch, which suppresses the overwrite and lets the attribute-supplied `href` reach the final tag. This is no obstacle in practice — the attacker writes the entire Markdown document. Two related forms that are **not** exploitable, noted so the fix isn't over-scoped: - Attaching the attribute to a non-link block — `hi {href="java<TAB>script:alert(1)"}` — does bypass the filter and emits `<p href="java<TAB>script:alert(1)">`, but `href` on a `<p>` is inert: there is nothing to navigate. (An earlier draft of this report described this as a "simpler, unconditional variant" of the attack; it is a filter bypass, not an XSS.) - `<img src>` is unaffected, since `ImageRenderer` unconditionally overwrites `src` from the core URL regardless of the safety verdict. ### Recommended Fix Normalize inside `RegexHelper::isLinkPotentiallyUnsafe()` before testing, mirroring the WHATWG URL parser's own normalization. This covers both variants, fixes every call site at once (`LinkRenderer`, `ImageRenderer`, and any third-party callers), and needs no changes in the Attributes extension. ## Affected Versions **`>= 1.5.0, <= 2.8.3`** - every release that ships the `AttributesExtension`. Verified by installing each version and rendering the payloads with `allow_unsafe_links => false`. The attribute-value grammar (`PARTIAL_DOUBLEQUOTEDVALUE = '"[^"]*"'`) has accepted raw control bytes since the extension was introduced, and none of the intervening parser rewrites narrowed it. ## Prior Related Advisories GHSA-3527-qv2q-pfvx / CVE-2025-46734 fixed a different Attributes-extension XSS (unallowlisted `on*` handlers, `href`/`src` not respecting `allow_unsafe_links` at all) in v2.7.0. This issue bypasses the specific `href`/`src` protection that fix introduced (the control-byte normalization gap was not part of that fix) - but the obfuscated inputs also work on older versions.

Netty is an asynchronous, event-driven network application framework. Prior to versions 4.1.136.Final and 4.2.16.Final, the `Bzip2Decoder` handler in Netty's compression codec pipeline is vulnerable to a denial-of-service attack through a malformed bzip2 stream that permanently captures the event-loop thread in an infinite loop. The vulnerability exists in the run-length encoding (RLE) state machine within [`Bzip2BlockDecompressor.read()`]. This issue has been fixed in versions 4.1.136.Final and 4.2.16.Final.

Netty is an asynchronous, event-driven network application framework. Prior to versions 4.1.136.Final and 4.2.16.Final, Netty's HTTP/2-to-HTTP/1.x translation layer (`Http2StreamFrameToHttpObjectCodec` and `InboundHttp2ToHttpAdapter`) fails to deduplicate or validate `Host` headers when an HTTP/2 client supplies both the `:authority` pseudo-header and a literal `host` header in a single HEADERS frame. The translator maps `:authority` to `Host` and separately copies the literal `host` header, producing an `HttpRequest` object containing two `Host` headers with attacker-controlled differing values. This issue has been fixed in versions 4.1.136.Final and 4.2.16.Final.

### Impact Page breadcrumbs in the CMS are vulnerable to XSS when viewed using the page list view ### Reporter Fase Rais Baradika

Netty is an asynchronous, event-driven network application framework. Prior to versions 4.1.136.Final and 4.2.16.Final, `HttpContentEncoder` (the superclass of the production handler `HttpContentCompressor`) maintains a per-channel `ArrayDeque<CharSequence>` named `acceptEncodingQueue` that accumulates attacker-controlled data without any size limit. The queue is filled on the I/O thread for every inbound HTTP request and drained only when the application later writes a non-1xx response. This creates a resource exhaustion vulnerability when an attacker exploits HTTP/1.1 pipelining to flood the connection with requests faster than the application produces responses. This issue has been fixed in versions 4.1.136.Final and 4.2.16.Final.

Key exchange without entity authentication in the EMR SSH helper commands in Amazon AWS CLI before 1.45.28 and AWS CLI v2 before 2.35.3 might allow man-in-the-middle attackers to intercept SSHsessions and file transfers via network positioning between the client and the EMR cluster endpoint. To remediate this issue, users should upgrade to AWS CLI v1 1.45.28 or later, or AWS CLI v2 2.35.3 or later.

datamodel-code-generator generates Pydantic v2 models, dataclasses, TypedDict, and msgspec.Struct from OpenAPI, JSON Schema, GraphQL, Avro, Protobuf, and raw JSON, YAML, or CSV. From 0.17.0 until 0.60.2, datamodel-code-generator preserves attacker-controlled default_factory values in src/datamodel_code_generator/parser/jsonschema.py through JsonSchemaObject.init and get_field_extras and emits them into Field(default_factory=...) or field(default_factory=...), allowing Python expression execution when the generated model is imported. This issue is fixed in version 0.60.2.

datamodel-code-generator generates Pydantic v2 models, dataclasses, TypedDict, and msgspec.Struct from OpenAPI, JSON Schema, GraphQL, Avro, Protobuf, and raw JSON, YAML, or CSV. From 0.52.1 until 0.60.2, datamodel-code-generator interpolates validators from --extra-template-data in src/datamodel_code_generator/model/pydantic_v2/base_model.py through _process_validators into @field_validator decorators without safe validation, allowing Python code execution when the generated Pydantic v2 model is imported. This issue is fixed in version 0.60.2.

## Summary The Nx **self-hosted HTTP remote cache** extracts downloaded cache artifacts without constraining where files are written. A malicious — or on-path (MITM) — remote cache server can return a crafted tar archive whose entries escape the cache directory and write to arbitrary locations on the machine running Nx. This arbitrary file write can be escalated to remote code execution. The directly exploitable issue is the self-hosted HTTP remote cache. ## Affected Packages > [!IMPORTANT] > **Nx's default local cache and Nx Cloud are NOT affected.** The default local cache and Nx Cloud use separate cache retrieval and extraction mechanisms that does not have this vulnerability. Only workspaces that use a self-hosted remote cache (`NX_SELF_HOSTED_REMOTE_CACHE_SERVER`, `@nx/s3-cache`, etc.) are affected. Two self-hosted cache surfaces are affected: 1. **The built-in HTTP remote cache** (`NX_SELF_HOSTED_REMOTE_CACHE_SERVER`, in `nx`) — **fixed** in the patched release. 2. **The self-hosted cache packages** — `@nx/s3-cache`, `@nx/gcs-cache`, `@nx/azure-cache`, `@nx/shared-fs-cache` (and their `@nx/powerpack-*` predecessors) — the same flaw in their own extractor. **Deprecated** (CVE-2025-36852) and not patched; migrate off (see Remediation). The shared step that copies cached outputs into the workspace was also part of the exposure and is hardened in the patched `nx` release. ## Remediation **Upgrade to Nx `22.7.7` or `23.0.2` (or later).** The patched extractor is a drop-in — no configuration change is required. ### If you use the S3, GCS, Azure, or shared-filesystem cache packages `@nx/s3-cache`, `@nx/gcs-cache`, `@nx/azure-cache`, and `@nx/shared-fs-cache` (and their `@nx/powerpack-*` predecessors) are separately versioned packages and are **already deprecated** (see CVE-2025-36852). Upgrading `nx` hardens the shared restore step, but it does not fully secure these packages. The remediation for them is to **migrate off** — to Nx Cloud or the self-hosted OpenAPI/HTTP remote cache — per the deprecation guidance: https://nx.dev/docs/reference/deprecated/self-hosted-cache-packages ## Details When Nx retrieves an artifact from the self-hosted HTTP remote cache, it downloads a gzipped tar archive and extracts it. The extractor joined each untrusted tar entry name directly onto the output directory and unpacked it with `tar`'s **unguarded** `Entry::unpack()`, which performs no containment check: ```rust // vulnerable let path_on_disk = output_dir.join(entry_path); // entry_path is attacker-controlled fs::create_dir_all(path_on_disk.parent()…)?; entry.unpack(&path_on_disk)?; ``` In addition, restore now copies **only** the declared task outputs (never the whole cache directory), confined to the workspace root; parent directories are realized as real directories so a write can never traverse a symlink; declared outputs that resolve outside the workspace are rejected; and the malformed-input cases return errors instead of panicking. ## References - Fix: https://github.com/nrwl/nx/pull/36116 (merged) - TLS-verification warning follow-up: https://github.com/nrwl/nx/pull/36132 (merged) - Vulnerable extractor introduced in Nx 20.8.0: https://github.com/nrwl/nx/pull/30593 ## Credits - **Lidor B.**, Novee Security — Reporter - **Assaf Levkovich**, Novee Security — Reporter

### Impact Mermaid radar diagrams allow arbitrary large values for `ticks`, which can cause high CPU usage, freezing the webpage/JavaScript process for long periods of time, until the process is eventually killed due to OOM/running out of memory. #### Proof-of-concept ```txt radar-beta axis a, b curve c {1, 1} ticks 1000000000 ``` ### Patches _Has the problem been patched? What versions should users upgrade to?_ This problem has been patched by https://github.com/mermaid-js/mermaid/commit/59b22fad2b3bb04f87a476c84a8a2b24679e607e, which was released in [Mermaid v11.16.1](https://github.com/mermaid-js/mermaid/releases/tag/mermaid%4011.16.1) ### Workarounds _Is there a way for users to fix or remediate the vulnerability without upgrading?_ There are no known workarounds without updating to a patched version of mermaid. ### References _Are there any links users can visit to find out more?_ - https://github.com/mermaid-js/mermaid/commit/59b22fad2b3bb04f87a476c84a8a2b24679e607e - https://github.com/mermaid-js/mermaid/releases/tag/mermaid%4011.16.1

### Summary Mermaid's configuration setters (`mermaid.initialize`, `mermaidAPI.setConfig`, and `mermaidAPI.updateSiteConfig`) merge the caller-supplied configuration object into Mermaid's internal config using the `assignWithDepth` deep-merge helper that is vulnerable to prototype pollution. Because these APIs are intended to receive **trusted** configuration supplied by the application integrating Mermaid, Mermaid assesses the practical risk as **low**. The vulnerability is only reachable if an application forwards attacker-controlled data directly into one of these configuration entry points, which is outside their documented usage. User-controlled configuration (e.g. configuration in diagram code using `%%{init: {}}%%` or YAML frontmatter) are already protected from prototype pollution. ### Patches This has been patched in https://github.com/mermaid-js/mermaid/commit/2cd6dcf735533b323507e3e889ffdea870540b43 and released in [Mermaid v11.16.1](https://github.com/mermaid-js/mermaid/releases/tag/mermaid%4011.16.1). A backport has been made for the v10 branch in c34b07a0815842327e70794d69b0c8c5a1e2a956 and was released in [Mermaid v10.9.8](https://github.com/mermaid-js/mermaid/releases/tag/v10.9.8) ### Impact Mermaid believes it's unlikely that anybody is impacted, as these functions are configuration entry points expected to receive trusted, developer-controlled values as they can modify other security-relevant configuration. ### Workarounds Don't pass user-controlled data to the `mermaid.initialize`, `mermaidAPI.setConfig`, and `mermaidAPI.updateSiteConfig` functions. Instead, users can use `%%{init: {}}%%` or YAML frontmatter in diagrams. ### Reporters - [email protected] (Liyi), https://lzhou1110.github.io/ - [email protected] (Ziyue), https://zyy0530.github.io/ - [email protected] (Strick), https://str1ckl4nd.github.io/ - [email protected] (Maurice), http://maurice.busystar.org/ - [email protected] (Chenchen), https://7thparkk.github.io/

### Summary Mermaid does not fully restrict CSS to the rendered SVG subtree. Although selectors are prefixed with `#mermaid-X`, sibling (`~` and `+`) combinators can still escape the Mermaid container and inject styles to DOM elements adjacent to the diagram `<svg>`. **Most users of mermaid would not be affected by this**, as mermaid adds its `<svg>` as an only child of it's parent element. However, you may be affected if you manually insert the `<svg>` (or other elements) into the DOM yourself. ### Details Mermaid namespaces CSS through with a middleware intended to scope all rules to the diagram's SVG element. CSS nesting expands `& ~ * { ... }` to `#svgId ~ *`, which selects all sibling elements following the SVG in the DOM, outside the diagram boundary. ### Impact An attacker able to supply diagram source to a page (e.g., user-generated content rendered by Mermaid) could inject CSS rules affecting sibling elements to the diagram `<svg>` on the host page. This can be used for UI redressing, hiding content, conditional CSS-based probing, or phishing-style visual manipulation. JavaScript execution is not possible via this vector. ### Patches This has been patched in https://github.com/mermaid-js/mermaid/commit/12d472c9ed43f94814b110da8d7a9ae6dd5266ed and released in [Mermaid v11.16.1](https://github.com/mermaid-js/mermaid/releases/tag/mermaid%4011.16.1). A backport has been made for the v10 branch in 7e83f1533318b307764d961906a73377266f4c5e and was released in [Mermaid v10.9.8](https://github.com/mermaid-js/mermaid/releases/tag/v10.9.8) ### Workarounds If you are inserting the `<svg>` into the DOM yourself, you can wrap it in an element with no other children, e.g. `<div><svg>...</svg></div>` or `element.innerHTML = svg`. Alternatively, you can use `mermaid.run()` or `mermaid.initialize()` which will do this for you. Setting ["securityLevel": "sandbox"](https://mermaid.js.org/config/schema-docs/config.html#securitylevel) will also prevent this, or setting the [`secure`](https://mermaid.js.org/config/schema-docs/config.html#secure) config value in the mermaid config to avoid allowing diagrams to modify `fontFamily`, `themeCSS`, `altFontFamily`, and `themeVariables`. To test, you can try using a `themeCSS` with `& + * { /* my CSS here */}` and see if it's applied outside of your mermaid `<svg>`. ```mermaid-example --- config: themeCSS: |- & + * { background:red !important; width:100vw !important; height:100vh !important; position:fixed !important; inset:0 !important; } --- info ``` ### References - GHSA-87f9-hvmw-gh4p/CVE-2026-41159 (related vulnerability) - https://github.com/mermaid-js/mermaid/commit/12d472c9ed43f94814b110da8d7a9ae6dd5266ed - https://github.com/mermaid-js/mermaid/releases/tag/mermaid%4011.16.1 - https://github.com/mermaid-js/mermaid/commit/7e83f1533318b307764d961906a73377266f4c5e - https://github.com/mermaid-js/mermaid/releases/tag/v10.9.8

Rendering an untrusted `architecture-beta` diagram lets the diagram author write an arbitrary property with the value `horizontal` or `vertical` onto `Object.prototype`. A group id of `__proto__` is accepted as a valid parent. ### Impact Any code in the same realm that reads a property of that name from an arbitrary object, or enumerates an object with bare `for...in`, observes the injected value (which can only be the string `horizontal` or `vertical`. This may mean corrupted option/config defaults, bypassed truthiness checks, causing denial of service or logic corruption in the embedding application. Because the injected value cannot be an object or function, this is not directly exploitable for remote code execution. ### PoC ``` architecture-beta group mermaidPrototypePollutionMarker(cloud)[Marker] service a(server)[A] in __proto__ service b(server)[B] in mermaidPrototypePollutionMarker a:R -- L:b ``` The vulnerable write was introduced in commit [cb0a4703bdf01d47508bde1c08aa9a980d70bc20](https://github.com/mermaid-js/mermaid/commit/cb0a4703bdf01d47508bde1c08aa9a980d70bc20) and first shipped in `[email protected]`. The lines are unchanged in every release since. ### Patches This has been patched by https://github.com/mermaid-js/mermaid/commit/99af3fc35ef0a9a9c8c6314521344d67523ddccf, released in [Mermaid v11.16.1](https://github.com/mermaid-js/mermaid/releases/tag/mermaid%4011.16.1) ### Workarounds There are no known workarounds. Please update to a patched version. ### References _Are there any links users can visit to find out more?_ - https://github.com/mermaid-js/mermaid/commit/99af3fc35ef0a9a9c8c6314521344d67523ddccf - https://github.com/mermaid-js/mermaid/releases/tag/mermaid%4011.16.1

Contao is an Open Source CMS. In versions 5.7.0 through 5.7.6, an authenticated backend user who can access one job can request an attachment identifier containing ../ segments and make the job attachment download endpoint read a file from another job directory inside var/job-attachments. The controller authorizes only the jobUuid route parameter. The later attachment lookup joins that authorized job UUID with the attacker-controlled identifier, then passes the combined path to the virtual filesystem. VirtualFilesystem::resolve() canonicalizes the whole path and only rejects paths that escape the filesystem mount, so authorized-job/../victim-job/debug_log.csv becomes victim-job/debug_log.csv. This is a cross-job authorization bypass for known job attachment paths. It is not a practical brute-force against unknown jobs because job directories are UUID v4 values.

### Impact Mermaid XY Charts are vulnerable to an infinite loop DoS attack in the `setXAxisRangeData()`, when configuring an X-Axis with invalid parameters. As each loop appends an element to an array, this would generally only cause an `RangeError: Invalid array length` to appear after a few seconds, but may cause the page/JavaScript process to crash due to memory exhaustion, depending on the environment. #### Proof-of-concept ```txt xychart x-axis 1 --> 1 line [1, 2] ``` ### Patches This has been patched in https://github.com/mermaid-js/mermaid/commit/630aa7e5dd417e1f56bff2a1ce8df2c5ad08d289 and released in [Mermaid v11.16.1](https://github.com/mermaid-js/mermaid/releases/tag/mermaid%4011.16.1). A backport has been made for the v10 branch in ef60adc837d9d5107af21285f01e83dea309bd0a and was released in [Mermaid v10.9.8](https://github.com/mermaid-js/mermaid/releases/tag/v10.9.8) ### Workarounds There are no known workarounds. Please update to the latest version or apply the patch. ### References - https://github.com/mermaid-js/mermaid/commit/630aa7e5dd417e1f56bff2a1ce8df2c5ad08d289 - https://github.com/mermaid-js/mermaid/releases/tag/mermaid%4011.16.1 - https://github.com/mermaid-js/mermaid/commit/ef60adc837d9d5107af21285f01e83dea309bd0a - https://github.com/mermaid-js/mermaid/releases/tag/v10.9.8

datamodel-code-generator generates Pydantic v2 models, dataclasses, TypedDict, and msgspec.Struct from OpenAPI, JSON Schema, GraphQL, Avro, Protobuf, and raw JSON, YAML, or CSV. From 0.9.1 until 0.61.0, datamodel-code-generator silently dereferences attacker-controlled JSON Schema $ref HTTP or HTTPS URLs in src/datamodel_code_generator/parser/jsonschema.py through _get_ref_body, and the --allow-remote-refs gate can warn instead of blocking, allowing server-side request forgery through src/datamodel_code_generator/http.py. This issue is fixed in version 0.61.0.

datamodel-code-generator generates Pydantic v2 models, dataclasses, TypedDict, and msgspec.Struct from OpenAPI, JSON Schema, GraphQL, Avro, Protobuf, and raw JSON, YAML, or CSV. Prior to 0.62.0, datamodel-code-generator resolves JSON Schema $ref targets in src/datamodel_code_generator/parser/jsonschema.py through is_url and _get_ref_body without containing file:// or ../ traversal references to the input directory and without honoring --no-allow-remote-refs, allowing arbitrary local file reads. This issue is fixed in version 0.62.0.

datamodel-code-generator generates Pydantic v2 models, dataclasses, TypedDict, and msgspec.Struct from OpenAPI, JSON Schema, GraphQL, Avro, Protobuf, and raw JSON, YAML, or CSV. Prior to 0.63.0, datamodel-code-generator validates a URL host once in src/datamodel_code_generator/http.py through get_body, _validate_url_for_fetch, and _get_ips_from_host, but then lets httpx resolve the host again for the connection, allowing DNS rebinding to bypass allow_private_network=False and reach internal services. This issue is fixed in version 0.63.0.

Contao is an Open Source CMS. In versions 4.13.40 through 5.3.46 and 5.7.0-RC1 through 5.7.6, the crawler leaks auth credentials to external hosts. Contao's crawler tries to prevent confidential HTTP client options from being sent to external domains by creating a scoped client: full options for root page origins, cleaned options for everything else. The cleaner removes Cookie and Authorization headers, but it removes the non-Symfony option names basic_auth and bearer_auth instead of Symfony HttpClient's real auth_basic and auth_bearer options. When contao.crawl.default_http_client_options contains Basic or Bearer authentication for a protected staging/production site, those credentials remain in the "clean" client used for external links or configured additional URIs. An attacker who can get an external URL crawled, for example through a link on a crawled page while the broken-link checker is enabled, can receive the crawler credentials. This issue has been fixed in versions 5.3.47 and 5.7.7.

datamodel-code-generator generates Pydantic v2 models, dataclasses, TypedDict, and msgspec.Struct from OpenAPI, JSON Schema, GraphQL, Avro, Protobuf, and raw JSON, YAML, or CSV. From 0.11.6 until 0.64.0, datamodel-code-generator allows attacker-controlled x-python-import or customTypePath schema extensions to reach src/datamodel_code_generator/parser/jsonschema.py and generated import handling through Import.from_full_path and Imports.create_line in src/datamodel_code_generator/imports.py, allowing a newline to break out of an import statement and execute Python code when the generated model is imported. This issue is fixed in version 0.64.0.

JIT miscompilation in the JavaScript Engine: JIT component. This vulnerability was fixed in Firefox 153 and Thunderbird 153.

Vulnerability in the Oracle Applications Framework product of Oracle E-Business Suite (component: Web Utilities). Supported versions that are affected are 12.2.11-12.2.15. Easily exploitable vulnerability allows low privileged attacker with network access via HTTP to compromise Oracle Applications Framework. Successful attacks of this vulnerability can result in takeover of Oracle Applications Framework. CVSS 3.1 Base Score 8.8 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H).

### Impact The default ("automagic") form notification email rendered user-submitted values without escaping, allowing an unauthenticated form submitter to inject HTML into the notification emails sent to the configured recipients ### Patches This has been fixed in 5.74.3 and 6.24.2.

Vulnerability in the Oracle Applications Framework product of Oracle E-Business Suite (component: Web Utilities). Supported versions that are affected are 12.2.8-12.2.15. Easily exploitable vulnerability allows high privileged attacker with network access via HTTP to compromise Oracle Applications Framework. While the vulnerability is in Oracle Applications Framework, attacks may significantly impact additional products (scope change). Successful attacks of this vulnerability can result in takeover of Oracle Applications Framework. CVSS 3.1 Base Score 9.1 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H).

IBM Langflow OSS 1.0.0 through 1.10.3 could allow a remote authenticated attacker to execute arbitrary commands due to improper validation of the command field in MCP server configurations.

Netty is an asynchronous, event-driven network application framework. Prior to versions 4.1.136.Final and 4.2.16.Final, HttpPostRequestEncoder constructs multipart HTTP request bodies by directly concatenating user-supplied filenames and field names into Content-Disposition MIME headers without validating or sanitizing CRLF characters (\r\n). Since MIME headers are delimited by CRLF, an attacker who controls the filename can inject arbitrary MIME headers into the multipart body part. The root cause is that neither the encoder nor the FileUpload implementations' setFilename() methods, which only check for null, neutralize CRLF characters before the filename is embedded into the header. This issue has been fixed in versions 4.1.136.Final and 4.2.16.Final.

IBM Langflow OSS 1.0.0 through 1.10.3 Langflow could allow an authenticated attacker to read, modify, or expose sensitive host files via Docker-based MCP servers due to incomplete filtering of dangerous Docker volume-mount and device-mapping arguments.

### Impact Public frontend forms did not enforce the file upload restrictions that the Control Panel enforces, so an unauthenticated visitor could upload file types an administrator had intended to disallow through a form's `assets` or `files` field. For `assets` fields, files could be stored on a public, web-accessible disk. Statamic's global upload allowlist still applied, so executable types such as `.php` and `.html` remained blocked. ### Patches This has been fixed in 5.74.3 and 6.24.2.

IBM Langflow OSS 1.0.0 through 1.10.3 could allow a remote attacker to execute arbitrary code due to improper validation of configuration parameters.

IBM Langflow OSS 1.0.0 through 1.10.3 does not properly validate ownership in the deprecated POST /api/v1/build/{flow_id}/vertices endpoint, allowing an authenticated user to inject arbitrary graph data into a shared cache for any flow. This may result in cross-user cache pollution, unauthorized workflow execution, or denial of service.

IBM Langflow OSS 1.0.0 through 1.10.3 could allow a remote authenticated attacker to execute arbitrary code due to improper validation of Python code during AST-based security scanning.

IBM Langflow OSS 1.0.0 through 1.10.3, 1.0.0 through 1.10.3, 1.0.0 through 1.10.3, 1.0.0 through 1.10.3, 1.0.0 through 1.10.3, 1.0.0 through 1.10.3, and 1.0.0 through 1.10.3 could allow a remote authenticated attacker to execute arbitrary code due to improper validation of module imports.