Xclow3N

When `http.Transport` sends an HTTP/1 CONNECT request containing a non-empty `Request.Body`, the body is written directly to the connection without framing following the request headers. If the server responds to the CONNECT request with a non-2xx keep-alive response, the connection is returned to the idle pool. Since CONNECT requests are not expected to have a request body, the server may treat the remaining body bytes as a subsequent pipelined HTTP/1.1 request. This results in a desynchronized pooled connection, causing the next user of that connection to receive the response intended for the injected request. In reverse proxies, such as `httputil.ReverseProxy`, that utilize a shared `Transport`, this behavior can lead to cross-user response poisoning.

An unauthenticated remote attacker can cause a denial of service by sending a complete LDAP operation followed by the initial bytes of an incomplete LDAPMessage on the same connection. This sequence forces the server to assign the connection to a second worker thread before the first worker's result is flushed. The second worker then blocks until the `nsslapd-ioblocktimeout` is reached while holding the connection mutex, which prevents the delivery of the completed operation's result. By repeating this process across a small number of connections relative to the configured worker-thread pool size, an attacker can exhaust the entire pool under default configurations, denying service to all clients, including anonymous and authenticated users via plaintext and TLS.

A flaw exists where the server fails to discard plaintext bytes buffered from a client connection during StartTLS negotiation. This allows an on-path attacker to inject a crafted LDAP message that is processed after the TLS upgrade. Due to a messageID collision, the response to the injected message is delivered to the client instead of the response to the client's own pending operation. Consequently, a client application may incorrectly treat a failed authentication (bind) attempt as successful.

An unauthenticated HTTP/2 client can exploit the way the proxy forwards data for configured non-WebSocket HTTP upgrades before the upstream accepts them. By placing a complete HTTP/1.1 request within extended CONNECT data, the attacker can cause the proxy to downgrade the request and write the data unframed to a keep-alive HTTP/1.1 upstream. This results in a smuggled response remaining queued in the shared pool, which can then be received by a different downstream client. This issue does not affect WebSocket upgrades, plain CONNECT, disabled backend keep-alive, per-downstream pools, or configurations where `max requests per connection` is set to 1.

An inconsistent interpretation of HTTP requests, known as HTTP Request/Response Smuggling, occurs on serverless-plugin routes. This allows an attacker to manipulate the request stream so that other clients receive responses chosen by the attacker or responses intended for other users.

Authenticated users can perform server-side request forgery (SSRF) by submitting crafted URLs. This issue occurs within the `fetch url()` function of the `ScenarioImport` class, allowing attackers to make arbitrary HTTP requests. This can be used to probe internal network services, enumerate ports through error signatures, and access cloud metadata endpoints to retrieve sensitive credentials.

The software contains two Server-Side Request Forgery (SSRF) issues. SSRF is a flaw that allows an attacker to induce the server-side application to make requests to an unintended location, potentially accessing internal resources or bypassing network restrictions.

Netty incorrectly parses quoted strings in HTTP/1.1 chunked transfer encoding extension values, enabling request smuggling attacks. Specifically, Netty terminates chunk header parsing at carriage return/newline characters within quoted strings instead of rejecting the request as malformed. This creates a parsing differential between Netty and RFC-compliant parsers. The root cause is that Netty does not validate that carriage return/line feed bytes are forbidden inside chunk extensions before the terminating carriage return/line feed. A request containing carriage return/line feed bytes within a chunk extension value should be rejected outright as invalid. This issue can lead to request smuggling, cache poisoning, access control bypass, and session hijacking.

Name of the Vulnerable Software and Affected Versions Apache Tomcat versions 11.0.0-M1 through 11.0.18, 10.1.0-M1 through 10.1.52, 9.0.0.M1 through 9.0.115, 8.5.0 through 8.5.100, and 7.0.0 through 7.0.109 Description An inconsistent interpretation of HTTP requests ('HTTP Request/Response Smuggling') exists in Apache Tomcat due to an invalid chunk extension. This can potentially allow an attacker to smuggle requests, leading to unexpected behavior or security breaches. Recommendations Upgrade to version 11.0.20 Upgrade to version 10.1.52 Upgrade to version 9.0.116

The HTTP/1.1 parser incorrectly handles quoted strings within chunked transfer encoding extension values. Specifically, the parser terminates chunk header parsing when it encounters a carriage return and line feed (CRLF) sequence inside a quoted string instead of treating it as a parsing error. This behavior allows an attacker to inject smuggled HTTP requests, which can lead to cache poisoning, access control bypass, and session hijacking.

The go-mail library improperly handles `mail.Address` values when passed to the SMTP client’s `MAIL FROM` or `RCPT TO` commands. This can lead to incorrect address routing or ESMTP parameter smuggling. Successful exploitation requires the user’s code to allow arbitrary mail address input. The issue stems from using the raw `Address` value instead of the `String()` method, which properly escapes and quotes mail addresses. Specifically, a crafted mail address like `"toni.tester@example.com> ORCPT=admin@admin.com"@example.com` could be misinterpreted by the SMTP server, potentially routing mail to unintended recipients or allowing the injection of additional SMTP commands.