Impact

Black provides a GitHub action for formatting code. This action supports an option, usepyproject: true, for reading the version of Black to use from the repository pyproject.toml. A malicious pull request could edit pyproject.toml to use a direct URL reference to a malicious repository. This could lead to arbitrary code execution in the context of the GitHub Action. Attackers could then gain access to secrets or permissions available in the context of the action.

Patches

Version 26.3.0 fixes this vulnerability by tightening the validation of the version field. Users who use the GitHub Action as psf/black@stable will automatically pick up this update.

Workarounds

Do not use the usepyproject: true option in the psf/black GitHub Action.

Authlib is a Python library which builds OAuth and OpenID Connect servers. Prior to 1.6.11, there is no CSRF protection on the cache feature in authlib.integrations.starletteclient.OAuth. This vulnerability is fixed in 1.6.11.

Summary The Python parser is vulnerable to a request smuggling vulnerability due to not parsing trailer sections of an HTTP request.

Impact If a pure Python version of aiohttp is installed (i.e. without the usual C extensions) or AIOHTTPNOEXTENSIONS is enabled, then an attacker may be able to execute a request smuggling attack to bypass certain firewalls or proxy protections.

----

Patch: https://github.com/aio-libs/aiohttp/commit/e8d774f635dc6d1cd3174d0e38891da5de0e2b6a

tar.Reader can allocate an unbounded amount of memory when reading a maliciously-crafted archive containing a large number of sparse regions encoded in the "old GNU sparse map" format.

Impact

Stored cross-site scripting (XSS) via crafted metric names in the Prometheus web UI:

Old React UI + New Mantine UI: When a user hovers over a chart tooltip on the Graph page, metric names containing HTML/JavaScript are injected into innerHTML without escaping, causing arbitrary script execution in the user's browser. Old React UI only: When a user opens the Metric Explorer (globe icon next to the PromQL expression input field), and a metric name containing HTML/JavaScript is rendered in the fuzzy search results, it is injected into innerHTML without escaping, causing arbitrary script execution in the user's browser. Old React UI only: When a user views a heatmap chart and hovers over a cell, the le label values of the underlying histogram buckets are interpolated into innerHTML without escaping. While le is conventionally a numeric bucket boundary, Prometheus does not enforce this — arbitrary UTF-8 strings are accepted as label values, allowing script injection via a crafted scrape target or remote write.

With Prometheus v3.x defaulting to UTF-8 metric and label name validation, characters like <, >, and " are now valid in metric names and labels, making this exploitable.

An attacker who can inject metrics (via a compromised scrape target, remote write, or OTLP receiver endpoint) can execute JavaScript in the browser of any Prometheus user who views the metric in the Graph UI. From the XSS context, an attacker could for example:

- Read /api/v1/status/config to extract sensitive configuration (although credentials / secrets are redacted by the server) - Call /-/quit to shut down Prometheus (only if --web.enable-lifecycle is set) - Call /api/v1/admin/tsdb/deleteseries to delete data (only if --web.enable-admin-api is set) - Exfiltrate metric data to an external server

Both the new Mantine UI and the old React UI are affected. The vulnerable code paths are:

- web/ui/mantine-ui/src/pages/query/uPlotChartHelpers.ts — tooltip innerHTML with unescaped labels.name - web/ui/react-app/src/pages/graph/GraphHelpers.ts — tooltip content with unescaped labels.name - web/ui/react-app/src/pages/graph/MetricsExplorer.tsx — fuzzy search results rendered via dangerouslySetInnerHTML without sanitization - web/ui/react-app/src/vendor/flot/jquery.flot.heatmap.js — heatmap tooltip with unescaped label values

Patches

A patch has been published in Prometheus 3.5.2 LTS and Prometheus 3.11.2. The fix applies escapeHTML() to all user-controlled values (metric names and label values) before inserting them into innerHTML. This advisory will be updated with the patched version once released.

Workarounds

- If using the remote write receiver (--web.enable-remote-write-receiver), ensure it is not exposed to untrusted sources. - If using the OTLP receiver (--web.enable-otlp-receiver), ensure it is not exposed to untrusted sources. - Ensure scrape targets are trusted and not under attacker control. - Do not enable admin / mutating API endpoints (e.g. --web.enable-admin-api or web.enable-lifecycle) in cases where you cannot prevent untrusted data from being ingested. - Users should avoid clicking untrusted links, especially those containing functions such as labelreplace, as they may generate poisoned label names and values.

Acknowledgements

Thanks to @gladiator9797 (Duc Anh Nguyen from TinyxLab) for reporting this.

go-ntlmssp is a Go package that provides NTLM/Negotiate authentication over HTTP. Prior to version 0.1.1, a malicious NTLM challenge message can causes an slice out of bounds panic, which can crash any Go process using ntlmssp.Negotiator as an HTTP transport. Version 0.1.1 patches the issue.

Apache Thrift: Node.js skip() recursion

Impact

Users who use Azure AD remote write with OAuth authentication are impacted.

The clientsecret field in the Azure AD remote write OAuth configuration (storage/remote/azuread) was typed as string instead of Secret. Prometheus redacts fields of type Secret when serving the configuration via the /-/config HTTP API endpoint. Because the field was a plain string, the Azure OAuth client secret was exposed in plaintext to any user or process with access to that endpoint.

Patches

The problem has been patched by changing ClientSecret in OAuthConfig to Secret. Users should upgrade to 3.11.3 or 3.5.3 LTS.

Workarounds

Users who can not upgrade can switch to Managed Identity or Workload Identity authentication for Azure AD remote write, which do not involve a client secret.

Impact

The remote read endpoint (/api/v1/read) does not validate the declared decoded length in a snappy-compressed request body before allocating memory. An unauthenticated attacker can send a small payload that causes a huge heap allocation per request. Under concurrent load this can exhaust available memory and crash the Prometheus process.

Patches Has the problem been patched? What versions should users upgrade to?

Fixed in 3.11.3 and 3.5.3 LTS. Users should upgrade to these versions or later.

Workarounds User who can not upgrade can place Prometheus behind a reverse proxy or firewall that requires authentication before requests reach /api/v1/read.

axios 1.7.2 allows SSRF via unexpected behavior where requests for path relative URLs get processed as protocol relative URLs.

Summary

A Path Traversal vulnerability exists when using non-default configuration options UPLOADDIR and UPLOADKEEPFILENAME=True. An attacker can write uploaded files to arbitrary locations on the filesystem by crafting a malicious filename.

Details

When UPLOADDIR is set and UPLOADKEEPFILENAME is True, the library constructs the file path using os.path.join(filedir, fname). Due to the behavior of os.path.join(), if the filename begins with a /, all preceding path components are discarded:

py os.path.join("/upload/dir", "/etc/malicious") == "/etc/malicious" This allows an attacker to bypass the intended upload directory and write files to arbitrary paths. Affected Configuration Projects are only affected if all of the following are true: - UPLOADDIR is set - UPLOADKEEPFILENAME is set to True - The uploaded file exceeds MAXMEMORYFILESIZE (triggering a flush to disk)

The default configuration is not vulnerable. Impact Arbitrary file write to attacker-controlled paths on the filesystem. Mitigation Upgrade to version 0.0.22, or avoid using UPLOADKEEPFILENAME=True in project configurations.

Summary

js-cookie's internal assign() helper copies properties with for...in + plain assignment. When the source object is produced by JSON.parse, the JSON object's "proto" member is an own enumerable property, so the for…in enumerates it and the target[key] = source[key] write triggers the Object.prototype.proto setter on the fresh target ({}). The result is a per-instance prototype hijack: Object.prototype itself is untouched, but the merged attributes object now inherits attacker-controlled keys.

Because the consuming set() function then enumerates the merged object with another for...in, every key the attacker placed on the polluted prototype lands in the resulting Set-Cookie string as an attribute pair. The attacker can set domain=, secure=, samesite=, expires=, and path= on cookies whose attributes the developer thought were locked down.

Impact

Any application that forwards a JSON-derived object as the attributes argument to Cookies.set, Cookies.remove, Cookies.withAttributes, or Cookies.withConverter is vulnerable. This is the standard pattern when cookie configuration comes from a backend:

js const cfg = await fetch('/config').then(r => r.json()); Cookies.set('session', token, cfg.cookieAttrs); // cfg.cookieAttrs influenced by attacker

A payload of {"proto":{"domain":"evil.example","secure":"false","samesite":"None"}} causes js-cookie to emit:

Set-Cookie: session=TOKEN; path=/; domain=evil.example; secure=false; samesite=None

Affected code

js // src/assign.mjs — full file export default function (target) { for (var i = 1; i < arguments.length; i++) { var source = arguments[i] for (var key in source) { // includes own enumerable 'proto' target[key] = source[key] // [[Set]] form - fires proto setter } } return target } Proof of concept

Node 22.11.0, no third-party deps:

Environment setup bash mkdir -p /tmp/jscookie-poc && cd /tmp/jscookie-poc npm init -y npm i js-cookie

PoC js ubuntu@kuber:/tmp/jscookie-poc$ cat poc.mjs let lastSetCookie = ''; globalThis.document = { get cookie() { return ''; }, set cookie(v) { lastSetCookie = v; } };

const { default: Cookies } = await import('js-cookie');

const attackerAttrs = JSON.parse( '{"proto":{"secure":"false","domain":"evil.com","samesite":"None","expires":-1}}' );

Cookies.set('session', 'TOKEN', attackerAttrs);

console.log('Set-Cookie that js-cookie wrote to document.cookie:'); console.log(lastSetCookie);

Execution: <img width="2614" height="1174" alt="cls-2026-05-14-01 44 39" src="https://github.com/user-attachments/assets/120df1fe-7e97-4ca3-904e-ab80d71ecf62" />

Suggested patch

diff --- a/src/assign.mjs +++ b/src/assign.mjs @@ export default function (target) { for (var i = 1; i < arguments.length; i++) { var source = arguments[i] - for (var key in source) { - target[key] = source[key] - } + for (var key in source) { + if (key === 'proto' || key === 'constructor' || key === 'prototype') continue + Object.defineProperty(target, key, { + value: source[key], + writable: true, + enumerable: true, + configurable: true, + }) + } } return target }

Equivalent one-liner alternative - iterate own names only and filter:

js for (const key of Object.getOwnPropertyNames(source)) { if (key === 'proto') continue target[key] = source[key] }

Impact

What kind of vulnerability is it?

It is a Denial of Service (DoS) vulnerability caused by CPU exhaustion. When serializing a specially crafted "array-like" object (an object that inherits from Array.prototype but has a very large length property), the process enters an intensive loop that consumes 100% CPU and hangs indefinitely.

Who is impacted?

Applications that use serialize-javascript to serialize untrusted or user-controlled objects are at risk. While direct exploitation is difficult, it becomes a high-priority threat if the application is also vulnerable to Prototype Pollution or handles untrusted data via YAML Deserialization, as these could be used to inject the malicious object.

Patches

Has the problem been patched?

Yes, the issue has been patched by replacing instanceof Array checks with Array.isArray() and using Object.keys() for sparse array detection.

What versions should users upgrade to?

Users should upgrade to v7.0.5 or later.

Workarounds

Is there a way for users to fix or remediate the vulnerability without upgrading?

There is no direct code-level workaround within the library itself. However, users can mitigate the risk by:

Validating and sanitizing all input before passing it to the serialize() function. Ensuring the environment is protected against Prototype Pollution. Upgrading to v7.0.5 as soon as possible.

Acknowledgements

Serialize JavaScript thanks Tomer Aberbach (@TomerAberbach) for discovering and privately disclosing this issue.

Impact

A bad regular expression is generated any time you have multiple sequential optional groups (curly brace syntax), such as {a}{b}{c}:z. The generated regex grows exponentially with the number of groups, causing denial of service.

Patches

Fixed in version 8.4.0.

Workarounds

Limit the number of sequential optional groups in route patterns. Avoid passing user-controlled input as route patterns.

React Router is a router for React. In versions 7.0.0 through 7.14.1, when using Framework Mode, a combination of steps could potentially allow unauthorized remote code execution (RCE) through external requests. This attack requires the application code to have an existing prototype pollution vulnerability, which can then be leveraged in a 2-step attack where the second step triggers unauthorized RCE on the remote server. This does not impact applications using Declarative Mode (<BrowserRouter>) or Data Mode (createBrowserRouter/<RouterProvider>). This is patched in version 7.14.2.

Summary

python-multipart has a denial of service vulnerability in multipart part header parsing. When parsing multipart/form-data, MultipartParser previously had no limit on the number of part headers or the size of an individual part header. An attacker could send a request with either many repeated headers without terminating the header block or a single very large header value, causing excessive CPU work before request rejection or completion.

Impact

Applications that parse attacker-controlled multipart/form-data with affected versions of python-multipart can experience CPU exhaustion. ASGI applications using Starlette, FastAPI, or other frameworks that invoke python-multipart may have worker or event-loop delays while processing malicious upload requests.

Details

The affected parser states are HEADERFIELDSTART, HEADERFIELD, HEADERVALUESTART, HEADERVALUE, and HEADERVALUEALMOSTDONE. The issue can be triggered by:

- A multipart part with an oversized individual header value. - A multipart part with many repeated header lines or an unterminated header block.

Both variants are addressed by enforcing default parser limits for maximum header count and maximum header size.

Mitigation

Upgrade to python-multipart 0.0.27 or later.

If upgrading is not immediately possible, reduce exposure by enforcing request body size limits at the server, proxy, or framework layer. This is only a mitigation; affected versions of python-multipart still parse multipart part headers without the default header count and header size limits.

Summary

resolvePartial() in the Handlebars runtime resolves partial names via a plain property lookup on options.partials without guarding against prototype-chain traversal. When Object.prototype has been polluted with a string value whose key matches a partial reference in a template, the polluted string is used as the partial body and rendered without HTML escaping, resulting in reflected or stored XSS.

Description

The root cause is in lib/handlebars/runtime.js inside resolvePartial() and invokePartial():

javascript // Vulnerable: plain bracket access traverses Object.prototype partial = options.partials[options.name];

hasOwnProperty is never checked, so if Object.prototype has been seeded with a key whose name matches a partial reference in the template (e.g. widget), the lookup succeeds and the polluted string is returned. The runtime emits a prototype-access warning, but the partial is still resolved and its content is inserted into the rendered output unescaped. This contradicts the documented security model and is distinct from CVE-2021-23369 and CVE-2021-23383, which addressed data property access rather than partial template resolution.

Prerequisites for exploitation: 1. The target application must be vulnerable to prototype pollution (e.g. via qs, minimist, or any querystring/JSON merge sink). 2. The attacker must know or guess the name of a partial reference used in a template.

Proof of Concept

javascript const Handlebars = require('handlebars');

// Step 1: Prototype pollution (via qs, minimist, or another vector) Object.prototype.widget = '<img src=x onerror="alert(document.domain)">';

// Step 2: Normal template that references a partial const template = Handlebars.compile('<div>Welcome! {{> widget}}</div>');

// Step 3: Render — XSS payload injected unescaped const output = template({}); // Output: <div>Welcome! <img src=x onerror="alert(document.domain)"></div>

The runtime prints a prototype access warning claiming "access has been denied," but the partial still resolves and returns the polluted value.

Workarounds

- Apply Object.freeze(Object.prototype) early in application startup to prevent prototype pollution. Note: this may break other libraries. - Use the Handlebars runtime-only build (handlebars/runtime), which does not compile templates and reduces the attack surface.

Impact What kind of vulnerability is it? Who is impacted?

SseStream.transform() interpolates message.type and message.id directly into Server-Sent Events text protocol output without sanitizing newline characters (\r, \n). Since the SSE protocol treats both \r and \n as field delimiters and \n\n as event boundaries, an attacker who can influence these fields through upstream data sources can inject arbitrary SSE events, spoof event types, and corrupt reconnection state. Spring Framework's own security patch (6e97587) validates these same fields (id, event) for the same reason.

Actual impact:

- Event spoofing: Attacker forges SSE events with arbitrary event: types, causing client-side EventSource.addEventListener() callbacks to fire for wrong event types. - Data injection: Attacker injects arbitrary data: payloads, potentially triggering XSS if the client renders SSE data as HTML without sanitization. - Reconnection corruption: Attacker injects id: fields, corrupting the Last-Event-ID header on reconnection, causing the client to miss or replay events. - Attack precondition: Requires the developer to map user-influenced data to the type or id fields of SSE messages. Direct HTTP request input does not reach these fields without developer code bridging the gap. - Patches Has the problem been patched? What versions should users upgrade to?

Patched in @nestjs/core@11.1.18

GHSA-fw9q-39r9-c252: Prototype Pollution via Incomplete Lodash set() Guard in langsmith-sdk

Severity: Medium (CVSS ~5.6) Status: Fixed in 0.5.18

---

Summary

The LangSmith JavaScript/TypeScript SDK (langsmith) contains an incomplete prototype pollution fix in its internally vendored lodash set() utility. The baseAssignValue() function only guards against the proto key, but fails to prevent traversal via constructor.prototype. This allows an attacker who controls keys in data processed by the createAnonymizer() API to pollute Object.prototype, affecting all objects in the Node.js process.

---

Affected Products

| Product | Affected Versions | Component | |---------|-------------------|-----------| | langsmith (npm) | <= 0.5.17 | js/src/utils/lodash/baseAssignValue.ts, js/src/anonymizer/index.ts | | langchain-ai/langsmith-sdk | GitHub main branch (as of 2026-03-24) | JS/TypeScript SDK |

Not affected: The Python SDK (langsmith on PyPI) does not use lodash or an equivalent pattern.

---

Root Cause

The SDK vendors an internal copy of lodash's set() function at js/src/utils/lodash/. The baseAssignValue() function at baseAssignValue.ts:11 implements a guard for prototype pollution:

typescript function baseAssignValue(object: Record<string, any>, key: string, value: any) { if (key === "proto") { Object.defineProperty(object, key, { configurable: true, enumerable: true, value: value, writable: true, }); } else { object[key] = value; // ← No guard for "constructor" or "prototype" keys } }

This blocks proto pollution but does not block the constructor.prototype traversal path. When set() is called with a path like "constructor.prototype.polluted":

1. castPath() splits it into ["constructor", "prototype", "polluted"] 2. baseSet() iterates: obj.constructor → Object → Object.prototype 3. assignValue(Object.prototype, "polluted", value) calls baseAssignValue() 4. Key is "polluted" (not "proto"), so the guard is bypassed 5. Object.prototype.polluted = value — all objects are polluted

---

Attack Vector via Anonymizer

The createAnonymizer() API (importable as langsmith/anonymizer) processes data by:

1. Extracting string nodes — extractStringNodes() walks an object recursively and builds dotted paths from keys 2. Applying regex replacements — If a string value matches a configured pattern, the node is marked for update (anonymizer/index.ts:95) 3. Writing back with set() — set(mutateValue, node.path, node.value) writes the replaced value back (anonymizer/index.ts:123)

An attacker who controls keys in data being anonymized can construct a nested object where the path resolves to constructor.prototype.X:

javascript { wrapper: { "constructor.prototype.isAdmin": "contains-secret-pattern" } }

extractStringNodes() produces path "wrapper.constructor.prototype.isAdmin". When the replacement triggers and set() writes back, it traverses up to Object.prototype.

Although createAnonymizer() uses deepClone() at anonymizer/index.ts:62 (JSON.parse(JSON.stringify(data))), the prototype chain traversal escapes the clone boundary because clone.wrapper.constructor resolves to the global Object constructor, not a cloned copy.

---

Proof of Concept

javascript import { createAnonymizer } from "langsmith/anonymizer";

const anonymizer = createAnonymizer([ { pattern: "secret", replace: "[REDACTED]" } ]);

console.log("BEFORE:", ({}).isAdmin); // undefined

const maliciousInput = { wrapper: { "constructor.prototype.isAdmin": "this-is-secret-data" } };

anonymizer(maliciousInput);

console.log("AFTER:", ({}).isAdmin); // "this-is-[REDACTED]-data" console.log("Array:", [].isAdmin); // "this-is-[REDACTED]-data"

function checkAccess(user) { if (user.isAdmin) return "ACCESS GRANTED"; return "ACCESS DENIED"; } console.log(checkAccess({ name: "bob" })); // "ACCESS GRANTED" ← BYPASSED

---

Impact

Prototype pollution in a Node.js process can enable:

1. Authentication bypass — if (user.isAdmin) checks succeed on all objects 2. Remote Code Execution — Exploitable in template engines (Pug, EJS, Handlebars, Nunjucks) via polluted prototype properties that reach eval()/Function() sinks 3. Denial of Service — Overwriting toString, valueOf, or hasOwnProperty on all objects 4. Data exfiltration — Polluting serialization methods to inject attacker-controlled values

---

Remediation

In baseAssignValue.ts, extend the guard to cover constructor and prototype keys:

typescript function baseAssignValue(object, key, value) { if (key === "proto" || key === "constructor" || key === "prototype") { Object.defineProperty(object, key, { configurable: true, enumerable: true, value, writable: true, }); } else { object[key] = value; } }

As defense in depth, extractStringNodes() in anonymizer/index.ts should also sanitize or reject path segments matching constructor or prototype before passing them to set().

---

Timeline

| Date | Event | |------|-------| | 2026-03-24 | Initial report submitted | | 2026-04-09 | Vendor confirmed; fixed in 0.5.18 |

---

Credits

Reported by: OneThing4101

Authorization bypass via certificate bag manipulation in sigstore/timestamp-authority verifier

An authorization bypass vulnerability exists in sigstore/timestamp-authority verifier (timestamp-authority/v2/pkg/verification): VerifyTimestampResponse function correctly verifies the certificate chain but when the TSA specific constraints are verified in VerifyLeafCert, the first non-CA certificate from the PKCS#7 certificate bag is used instead of the leaf certificate from the certificate chain. An attacker can exploit this by prepending a forged certificate to the certificate bag while the message is signed with an authorized key. The library validates the signature using the one certificate but performs authorization checks on the another, allowing an attacker to bypass some authorization controls.

This vulnerability does not apply to timestamp-authority service, only to users of timestamp-authority/v2/pkg/verification package.

This vulnerability does not apply to sigstore-go even though it is a user of timestamp-authority/v2/pkg/verification: Providing TSACertificate option to VerifyTimestampResponse fully mitigates the issue.

Patches

The issue will be fixed in timestamp-authority 2.0.6

Workarounds

Users of VerifyTimestampResponse can use the TSACertificate option to specify the exact certificate they expect to be used: this fully mitigates the issue.

References

This issue was found after reading CVE-2026-33753 / GHSA-3xxc-pwj6-jgrj (originally reported by @Jaynornj and @Pr00fOf3xpl0it)

Summary

A denial of service vulnerability exists when parsing crafted multipart/form-data requests with large preamble or epilogue sections.

Details

Two inefficient multipart parsing paths could be abused with attacker-controlled input.

Before the first multipart boundary, the parser handled leading CR and LF bytes inefficiently while searching for the start of the first part. After the closing boundary, the parser continued processing trailing epilogue data instead of discarding it immediately. As a result, parsing time could grow with the size of crafted data placed before the first boundary or after the closing boundary.

Impact

An attacker can send oversized malformed multipart bodies that consume excessive CPU time during request parsing, reducing request-handling capacity and delaying legitimate requests. This issue degrades availability but does not typically result in a complete denial of service for the entire application.

Mitigation

Upgrade to version 0.0.26 or later, which skips ahead to the next boundary candidate when processing leading CR/LF data and immediately discards epilogue data after the closing boundary.

Summary A flaw in netty's parsing of chunk extensions in HTTP/1.1 messages with chunked encoding can lead to request smuggling issues with some reverse proxies.

Details When encountering a newline character (LF) while parsing a chunk extension, netty interprets the newline as the end of the chunk-size line regardless of whether a preceding carriage return (CR) was found. This is in violation of the HTTP 1.1 standard which specifies that the chunk extension is terminated by a CRLF sequence (see the RFC).

This is by itself harmless, but consider an intermediary with a similar parsing flaw: while parsing a chunk extension, the intermediary interprets an LF without a preceding CR as simply part of the chunk extension (this is also in violation of the RFC, because whitespace characters are not allowed in chunk extensions). We can use this discrepancy to construct an HTTP request that the intermediary will interpret as one request but netty will interpret as two (all lines ending with CRLF, notice the LFs in the chunk extension):

POST /one HTTP/1.1 Host: localhost:8080 Transfer-Encoding: chunked

48;\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\n0

POST /two HTTP/1.1 Host: localhost:8080 Transfer-Encoding: chunked

0

The intermediary will interpret this as a single request. Once forwarded to netty, netty will interpret it as two separate requests. This is a problem, because attackers can then the intermediary, as well as perform standard request smuggling attacks against other live users (see this Portswigger article).

Impact This is a request smuggling issue which can be exploited for bypassing front-end access control rules as well as corrupting the responses served to other live clients.

The impact is high, but it only affects setups that use a front-end which: 1. Interprets LF characters (without preceding CR) in chunk extensions as part of the chunk extension. 2. Forwards chunk extensions without normalization.

Disclosure

- This vulnerability was disclosed on June 18th, 2025 here: https://w4ke.info/2025/06/18/funky-chunks.html

Discussion Discussion for this vulnerability can be found here: - https://github.com/netty/netty/issues/15522 - https://github.com/JLLeitschuh/unCVEed/issues/1

Credit

- Credit to @JeppW for uncovering this vulnerability. - Credit to @JLLeitschuh at Socket for coordinating the vulnerability disclosure.

Impact

There is a denial of service vulnerability in React Server Components.

React recommends updating immediately.

The vulnerability exists in versions 19.0.0, 19.0.1 19.1.0, 19.1.1, 19.1.2, 19.2.0 and 19.2.1 of:

- react-server-dom-webpack - react-server-dom-parcel - react-server-dom-turbopack

These issues are present in the patches published last week.

Patches

Fixes were back ported to versions 19.0.2, 19.1.3, and 19.2.2.

If you are using any of the above packages please upgrade to any of the fixed versions immediately.

If your app’s React code does not use a server, your app is not affected by this vulnerability. If your app does not use a framework, bundler, or bundler plugin that supports React Server Components, your app is not affected by this vulnerability.

References

See the blog post for more information and upgrade instructions.

Impact Using either of the two parsers in the default configuration (with resolveentities=True) allows untrusted XML input to read local files.

Patches lxml 6.1.0 changes the default to resolveentities='internal', thus disallowing local file access by default.

Workarounds Setting the resolveentities option explicitly to resolveentities='internal' or resolveentities=False disables the local file access.

Resources Original report: https://bugs.launchpad.net/lxml/+bug/2146291

The default option was changed to resolveentities='internal' for the normal XML and HTML parsers in lxml 5.0. The default was not changed for iterparse() and ETCompatXMLParser() at the time. lxml 6.1 makes the safe option the default for all parsers.

IBM Concert 1.0.0 through 2.3.1 could allow a remote attacker to perform unauthorized actions using man in the middle techniques due to improper certificate validation.

IBM Concert

The orjson.dumps function in orjson thru 3.11.4 does not limit recursion for deeply nested JSON documents.

Impact

The default configuration of startStandaloneServer from @apollo/server/standalone is vulnerable to Denial of Service (DoS) attacks through specially crafted request bodies with exotic character set encodings.

This issue does not affect users that use @apollo/server as a dependency for integration packages, like @as integrations/express5 or @as-integrations/next, only direct usage of startStandaloneServer.

Who is impacted

Users directly using startStandaloneServer from @apollo/server/standalone.

This issue affects Apollo Server from v5.0.0 through v5.3.x.

It also affects all releases of the end-of-life major versions v4, v3, and v2. Although Apollo Server v4 is EOL and Apollo no longer commits to providing support or updates for it, a fix for it was released in v4.13.0. Apollo Server v3 and v2 are no longer updated, as they have been EOL since 2024 and 2023 respectively.

Patches

Patches for this issue are released as @apollo/server versions 5.4.0 and 4.13.0.

In accordance with RFC 7159, these versions now only accept request bodies encoded in UTF-8, UTF-16 (LE or BE), or UTF-32 (LE or BE). Any other character set will be rejected with a 415 Unsupported Media Type error. Note that the more recent JSON RFC, [RFC 8259 (https://datatracker.ietf.org/doc/html/rfc8259#section-8.1), is more strict and will only allow UTF-8. Since this is a minor release, we have chosen to remain compatible with the more permissive RFC 7159 for now. In a future major release, the restriction may be tightened further to only allow UTF-8.

Workarounds

Users of apollo-server v2 or v3 that cannot upgrade for some reason could switch from the standalone apollo-server package to an integration package like apollo-server-express or apollo-server-koa and set up their own server. Please note that these old packages are generally EOL and do not receive any more support or bug fixes. This can only be seen as a short-term workaround. Updating to @apollo/server v5 should be a priority.

Description

The RecursiveUrlLoader class in @langchain/community is a web crawler that recursively follows links from a starting URL. Its preventOutside option (enabled by default) is intended to restrict crawling to the same site as the base URL.

The implementation used String.startsWith() to compare URLs, which does not perform semantic URL validation. An attacker who controls content on a crawled page could include links to domains that share a string prefix with the target (e.g., https://example.com.attacker.com passes a startsWith check against https://example.com), causing the crawler to follow links to attacker-controlled or internal infrastructure.

Additionally, the crawler performed no validation against private or reserved IP addresses. A crawled page could include links targeting cloud metadata services (169.254.169.254), localhost, or RFC 1918 addresses, and the crawler would fetch them without restriction.

Impact

An attacker who can influence the content of a page being crawled (e.g., by placing a link on a public-facing page, forum, or user-generated content) could cause the crawler to:

- Fetch cloud instance metadata (AWS, GCP, Azure), potentially exposing IAM credentials and session tokens - Access internal services on private networks (10.x, 172.16.x, 192.168.x) - Connect to localhost services - Exfiltrate response data via attacker-controlled redirect chains

This is exploitable in any environment where RecursiveUrlLoader runs on infrastructure with access to cloud metadata or internal services — which includes most cloud-hosted deployments.

Resolution

Two changes were made:

1. Origin comparison replaced. The startsWith check was replaced with a strict origin comparison using the URL API (new URL(link).origin === new URL(baseUrl).origin). This correctly validates scheme, hostname, and port as a unit, preventing subdomain-based bypasses.

2. SSRF validation added to all fetch operations. A new URL validation module (@langchain/core/utils/ssrf) was introduced and applied before every outbound fetch in the crawler. This blocks requests to: - Cloud metadata endpoints: 169.254.169.254, 169.254.170.2, 100.100.100.200, metadata.google.internal, and related hostnames - Private IP ranges: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 127.0.0.0/8, 169.254.0.0/16 - IPv6 equivalents: ::1, fc00::/7, fe80::/10 - Non-HTTP/HTTPS schemes (file:, ftp:, javascript:, etc.)

Cloud metadata endpoints are unconditionally blocked and cannot be overridden.

Workarounds

Users who cannot upgrade immediately should avoid using RecursiveUrlLoader on untrusted or user-influenced content, or should run the crawler in a network environment without access to cloud metadata or internal services.

Summary The arrayLimit option in qs does not enforce limits for comma-separated values when comma: true is enabled, allowing attackers to cause denial-of-service via memory exhaustion. This is a bypass of the array limit enforcement, similar to the bracket notation bypass addressed in GHSA-6rw7-vpxm-498p (CVE-2025-15284).

Details When the comma option is set to true (not the default, but configurable in applications), qs allows parsing comma-separated strings as arrays (e.g., ?param=a,b,c becomes ['a', 'b', 'c']). However, the limit check for arrayLimit (default: 20) and the optional throwOnLimitExceeded occur after the comma-handling logic in parseArrayValue, enabling a bypass. This permits creation of arbitrarily large arrays from a single parameter, leading to excessive memory allocation.

Vulnerable code (lib/parse.js: lines ~40-50): js if (val && typeof val === 'string' && options.comma && val.indexOf(',') -1) {     return val.split(','); }

if (options.throwOnLimitExceeded && currentArrayLength = options.arrayLimit) {     throw new RangeError('Array limit exceeded. Only ' + options.arrayLimit + ' element' + (options.arrayLimit === 1 ? '' : 's') + ' allowed in an array.'); }

return val; The split(',') returns the array immediately, skipping the subsequent limit check. Downstream merging via utils.combine does not prevent allocation, even if it marks overflows for sparse arrays.This discrepancy allows attackers to send a single parameter with millions of commas (e.g., ?param=,,,,,,,,...), allocating massive arrays in memory without triggering limits. It bypasses the intent of arrayLimit, which is enforced correctly for indexed (a[0]=) and bracket (a[]=) notations (the latter fixed in v6.14.1 per GHSA-6rw7-vpxm-498p).

PoC Test 1 - Basic bypass: npm install qs

js const qs = require('qs');

const payload = 'a=' + ','.repeat(25); // 26 elements after split (bypasses arrayLimit: 5) const options = { comma: true, arrayLimit: 5, throwOnLimitExceeded: true };

try {   const result = qs.parse(payload, options);   console.log(result.a.length); // Outputs: 26 (bypass successful) } catch (e) {   console.log('Limit enforced:', e.message); // Not thrown } Configuration: - comma: true - arrayLimit: 5 - throwOnLimitExceeded: true

Expected: Throws "Array limit exceeded" error. Actual: Parses successfully, creating an array of length 26.

Impact Denial of Service (DoS) via memory exhaustion.