httpd parks a request worker indefinitely on a malformed chunk size sent after the headers

httpd modauth directory protection bypassed by a doubled slash in the request path

httpd modauth directory protection bypassed by request path casing on case-insensitive filesystems

A Signed Length Overflow in Erlang/OTP's inet TCP Driver Overflows the Receive Buffer Into BEAM VM Memory From an Unauthenticated Peer

httpd function checkheader/3 rejects duplicate Content-Length (per CVE-2026-23941) but never checks for the TE+CL co-presence that RFC 9112 §6.3 identifies as a probable smuggling attempt. handlebody/3 frames by chunked and silently discards Content-Length. A CL-preferring front-end paired with chunked-preferring inets creates a classic CL.TE front-end/back-end desync.

This issue affects OTP from OTP 17.0 before OTP 27.3.4.17, from OTP 28.0 before OTP 28.5.0.6, and from OTP 29.0 before OTP 29.0.6, corresponding to inets from 5.10 before 9.3.2.7, from 9.4 before 9.6.2.3, and from 9.7 before 9.7.2. Whether OTP before OTP 17.0, corresponding to inets before 5.10, is affected is unknown.

Improper Validation of Specified Quantity in Input vulnerability in Erlang/OTP stdlib allows a remote attacker to degrade availability by supplying a URI whose port component is a very long run of digits.

uristring:getport/1 passes the port substring to binarytointeger/1 with no length bound, catching only error:badarg, so a syntactically valid port of up to roughly 1.26 million digits converts successfully and costs the calling process hundreds of milliseconds of arbitrary-precision arithmetic. The conversion is reached from every authority-parsing path in uristring:parse/1, including the host, registered-name, and IPv4 and IPv6 forms. parse/1 is the documented interface for parsing URIs, so any application that parses an attacker-supplied URI is exposed without further configuration. The conversion function is documented to accept integers of any size, so bounding the input is the caller's responsibility.

This issue affects OTP from OTP 21.0 before OTP 27.3.4.17, from OTP 28.0 before OTP 28.5.0.6, and from OTP 29.0 before OTP 29.0.6, corresponding to stdlib from 3.5 before 6.2.2.5, from 7.0 before 7.3.0.2, and from 8.0 before 8.0.4.

httpc memory exhaustion via unbounded response header accumulation

httpc does not bound server-supplied numeric header values before integer conversion

Allocation of Resources Without Limits or Throttling vulnerability in Erlang/OTP inets httpd allows an unauthenticated remote attacker to cause denial of service by opening and holding open a large number of connections. The maxclients option is documented to default to 150, and the inets hardening guide presents that limit as the first layer of denial-of-service defence, but a server that does not set it explicitly accepts an unlimited number of simultaneous connections. Establishing the connections is sufficient; no valid request and no authentication are required.

The accept gate in httpdmanager:handlenewconnection/4 reads the option with httpdutil:lookup/2, which returns undefined when the key is absent, rather than the three-argument form carrying the 150 default that the neighbouring getustate/2 uses. Erlang term ordering places every integer before every atom, so the Count =< Max guard holds for any connection count and the server never returns {reject, busy}. Each accepted connection occupies a worker process and a socket for as long as it is held, driving the node towards process, memory and file descriptor exhaustion. Servers that set maxclients explicitly are unaffected, because a configured value is applied as intended.

This issue affects OTP from OTP 17.0 before OTP 27.3.4.17, from OTP 28.0 before OTP 28.5.0.6, and from OTP 29.0 before OTP 29.0.6, corresponding to inets from 5.10 before 9.3.2.7, from 9.4 before 9.6.2.3, and from 9.7 before 9.7.2.

Allocation of resources without limits in Erlang/OTP publickey certificate path validation allows a remote unauthenticated attacker to cause denial of service by sending a crafted X.509 certificate chain during the TLS handshake.

During RFC 5280 policy processing in publickey:pkixpathvalidation/3, the certificate policy tree maintained by pubkeypolicytree grows without an upper bound. When a certificate chain contains M policies per certificate and K certificates, the tree grows on the order of M^K nodes because pubkeypolicytree:addleaves/2 and pubkeypolicytree:addleafsiblings/2 extend the tree per policy per certificate. A modest chain with many policies per certificate is enough to pin BEAM schedulers and exhaust the node's memory, taking down the entire VM. The attacker only needs to be able to present a certificate chain to the victim, which is the normal precondition for a TLS handshake, so exploitation succeeds against any incoming or outgoing TLS connection that validates the peer's chain (the default for SSL/TLS clients and mutual-TLS servers).

This is the same vulnerability class as OpenSSL's X509verifycert policy tree DoS.

This vulnerability is associated with program files lib/publickey/src/pubkeypolicytree.erl and program routines pubkeypolicytree:addleaves/2 and pubkeypolicytree:addleafsiblings/2.

This issue affects OTP from OTP 26.2 before OTP 29.0.4, OTP 28.5.0.4 and OTP 27.3.4.15, corresponding to publickey from 1.15 before 1.21.4, 1.20.3.4 and 1.17.1.5.

Classic buffer overflow in the Erlang/OTP megaco flex scanner C driver allows a remote unauthenticated attacker to corrupt the driver's memory (and potentially achieve remote code execution or a denial-of-service crash) by sending a single text-encoded H.248/Megaco message containing an oversized property parm name.

When tokenizing a Local/Remote descriptor, mfsloadpropertygroups extracts the attacker-controlled property name (bounded only by the message length) and, when no value follows, formats it into a fixed 512-byte errormsg field of the MfsErlDrvData struct using an unchecked sprintf call. Names longer than roughly 452 bytes overflow into the immediately following struct fields (textbuf, textptr, termspec, termspecsize, termspecindex), overwriting live pointers and counters with attacker-chosen bytes. Subsequent scanner code writes and frees through the corrupted pointers, producing arbitrary write and arbitrary free primitives inside the BEAM VM process, which can be leveraged for remote code execution. On builds compiled with FORTIFYSOURCE the overflow is detected at runtime and terminates the process with SIGABRT, resulting in denial of service.

The overflow occurs in the flex scanner before any grammar or Megaco-level authentication processing, so exploitation requires only network reachability to the megaco transport port on a node configured with {scanner, flex}.

This vulnerability is associated with program files lib/megaco/src/flex/megacoflexscannerdrv.flex.src and program routines mfsloadpropertygroups.

This issue affects OTP from OTP 17.0 before OTP 27.3.4.15, from OTP 28.0 before OTP 28.5.0.4, and from OTP 29.0 before OTP 29.0.4, corresponding to megaco from 3.17.1 before 4.7.2.2, from 4.8 before 4.8.3.1, and from 4.9 before 4.9.1. Whether OTP before OTP 17.0, corresponding to megaco before 3.17.1, is affected is unknown.

The Erlang/OTP ssl TLS 1.2 (and earlier) and DTLS client does not verify that the cipher suite selected by the server in ServerHello was among the suites offered by the client in ClientHello. The client-side tlshandshake:hello/5 handler validates the negotiated protocol version and the downgrade sentinel but hands the server-chosen suite directly to sslhandshake:handleserverhelloextensions/9, which installs it without a membership check. The TLS 1.3 client path performs this check (per RFC 8446), so it is not affected.

An on-path attacker between the client and the intended server can respond with a ServerHello selecting an anonymous key exchange suite such as TLSDHanon or TLSECDHanon that the client never offered. Anonymous suites do not require the server to present a certificate, so the entire verifypeer and cacerts configuration is bypassed: the attacker completes the handshake with its own ephemeral parameters, no certificate is validated, no hostname is checked, and ssl:connect returns {ok, Socket}. All subsequent application traffic is readable and modifiable by the attacker.

This issue affects OTP from OTP 17.0 before OTP 27.3.4.15, from OTP 28.0 before OTP 28.5.0.4, and from OTP 29.0 before OTP 29.0.4, corresponding to ssl from 5.3.4 before 11.2.12.11, from 11.3 before 11.6.0.4, and from 11.7 before 11.7.4. Whether OTP before OTP 17.0, corresponding to ssl before 5.3.4, is affected is unknown.

The Erlang/OTP ssl application does not detect cycles when reconstructing an incomplete peer certificate chain during a TLS or DTLS handshake. In sslcertificate:handleincompletechain/5, the received chain is passed to sslcertificate:buildcertificatechain/5, which walks issuer relationships via sslcertificate:docertificatechain/7 with no cycle detection and no depth limit. When the peer supplies two mutually cross-signed certificates in unordered form (A issues B, B issues A), the issuer lookup alternates between the two certificates and the pair of functions recurses indefinitely, growing the call stack and chain accumulator without bound.

An unauthenticated remote attacker can send a crafted certificate chain in a TLS or DTLS Certificate handshake message to exhaust available memory and crash the BEAM node. Only a TCP connection and a partial handshake are required; no authentication or completed handshake is needed, and both TLS/DTLS servers and clients are affected when processing peer certificate messages.

This issue affects OTP from OTP 23.2 before OTP 29.0.4, OTP 28.5.0.4 and OTP 27.3.4.15, corresponding to ssl from 10.2 before 11.7.4, 11.6.0.4 and 11.2.12.11.

Improper Enforcement of Message Integrity During Transmission in a Communication Channel vulnerability in Erlang/OTP ssl (tlsgenconnection module) allows a network-positioned attacker to inject unauthenticated plaintext that the TLS client application later treats as authenticated server data.

The function tlsgenconnection:handleprotocolrecord/3 rejects APPLICATIONDATA records that arrive in pre-handshake states when the TLS endpoint acts as a server, but does not apply the same check when the endpoint acts as a client. A network-positioned attacker can send plaintext APPLICATIONDATA records to the client during the handshake. The records are buffered and, once the handshake completes successfully, delivered to the application as if they were authenticated post-handshake data. The attacker cannot observe the client's response or steer the connection, so the impact is limited to blind injection of unauthenticated bytes. The injection window is wider for TLS versions prior to TLS 1.3 than for TLS 1.3.

This vulnerability is associated with program file lib/ssl/src/tlsgenconnection.erl.

TLS 1.3 is affected starting with OTP 22.0, when TLS 1.3 support was added.

This issue affects OTP from OTP 17.0 before OTP 27.3.4.14, from OTP 28.0 before OTP 28.5.0.3, and from OTP 29.0 before OTP 29.0.3, corresponding to ssl from 5.3.4 before 11.2.12.10, from 11.3 before 11.6.0.3, and from 11.7 before 11.7.3. Whether OTP before OTP 17.0, corresponding to ssl before 5.3.4, is affected is unknown.

DTLS listener crash via race condition in dtlspacketdemux causes denial of service for all sessions

ftp client PASV response IP not validated against control peer, enabling SSRF and FTP bounce attacks

Improper Following of a Certificate's Chain of Trust vulnerability in Erlang OTP publickey (pubkeycert module) allows a non-CA certificate to be accepted as an intermediate issuer, enabling certificate chain forgery.

In lib/publickey/src/pubkeycert.erl, pubkeycert:validateextensions/7 contains two flaws that together allow a certificate with basicConstraints cA:false and no keyUsage extension to be used as an intermediate issuer in a chain passed to publickey:pkixpathvalidation/3: the cA:false clause recurses into the remaining extensions without rejecting the certificate when it is in issuer position, and the keyUsage check only fires when the extension is present, so a certificate lacking keyUsage entirely bypasses the keyCertSign enforcement.

Any party holding an end-entity certificate with basicConstraints cA:false and no keyUsage extension, issued by any CA in the victim's trust store, can use that certificate's private key to sign forged leaf certificates for arbitrary identities. publickey:pkixpathvalidation/3 accepts the resulting chain, and by extension every TLS or mTLS endpoint built on the OTP ssl application that relies on the default verifier is affected, including server identity verification on the client side and client certificate verification on mTLS servers.

This issue affects OTP from OTP 17.0 before OTP 26.2.5.21, 27.3.4.12, 28.5.0.1, and 29.0.1 corresponding to publickey from 0.22 before 1.15.1.7, 1.17.1.3, 1.20.3.1, and 1.21.1.

Improper Certificate Validation vulnerability in Erlang OTP publickey (pubkeyocsp module) allows OCSP designated-responder authorization bypass via missing signature verification.

The OCSP response validation in publickey:pkixocspvalidate/5 does not verify that a CA-designated responder certificate was cryptographically signed by the issuing CA. Instead, it only checks that the responder certificate's issuer name matches the CA's subject name and that the certificate has the OCSPSigning extended key usage. An attacker who can intercept or control OCSP responses can create a self-signed certificate with a matching issuer name and the OCSPSigning EKU, and use it to forge OCSP responses that mark revoked certificates as valid.

This affects SSL/TLS clients using OCSP stapling, which may accept connections to servers with revoked certificates, potentially transmitting sensitive data to compromised servers. Applications using the publickey:pkixocspvalidate/5 API directly are also affected, with impact depending on usage context.

This vulnerability is associated with program files lib/publickey/src/pubkeyocsp.erl and program routines pubkeyocsp:isauthorizedresponder/3.

This issue affects OTP from OTP 27.0 until OTP 28.4.2 and 27.3.4.10 corresponding to publickey from 1.16 until 1.20.3 and 1.17.1.2, and ssl from 11.2 until 11.5.4 and 11.2.12.7.

Generation of Predictable Numbers or Identifiers vulnerability in Erlang/OTP kernel (inetres, inetdb modules) allows DNS Cache Poisoning.

The built-in DNS resolver (inetres) uses a sequential, process-global 16-bit transaction ID for UDP queries and does not implement source port randomization. Response validation relies almost entirely on this ID, making DNS cache poisoning practical for an attacker who can observe one query or predict the next ID. This conflicts with RFC 5452 recommendations for mitigating forged DNS answers.

inetres is intended for use in trusted network environments and with trusted recursive resolvers. Earlier documentation did not clearly state this deployment assumption, which could lead users to deploy the resolver in environments where spoofed DNS responses are possible.

This vulnerability is associated with program files lib/kernel/src/inetdb.erl and lib/kernel/src/inetres.erl.

This issue affects OTP from OTP 17.0 before OTP 28.4.2, OTP 27.3.4.10 and OTP 26.2.5.19, corresponding to kernel from 3.0 before 10.6.2, 10.2.7.4 and 9.2.4.11.

Inconsistent Interpretation of HTTP Requests ('HTTP Request Smuggling') vulnerability in Erlang OTP (inets httpd module) allows HTTP Request Smuggling.

This vulnerability is associated with program files lib/inets/src/httpserver/httpdrequest.erl and program routines httpdrequest:parseheaders/7.

The server does not reject or normalize duplicate Content-Length headers. The earliest Content-Length in the request is used for body parsing while common reverse proxies (nginx, Apache httpd, Envoy) honor the last Content-Length value. This violates RFC 9112 Section 6.3 and allows front-end/back-end desynchronization, leaving attacker-controlled bytes queued as the start of the next request.

This issue affects OTP from OTP 17.0 before OTP 28.4.1, OTP 27.3.4.9 and OTP 26.2.5.18, corresponding to inets from 5.10 before 9.6.1, 9.3.2.3 and 9.1.0.5.

Hi all,

An absolute-path traversal flaw has been found in the Erlang/OTP standard-library ZIP routines zip:unzip/1,2 and zip:extract/1,2. If the caller does not supply the memory option, archive entries whose file names start with "/" are written to disk verbatim. An attacker can therefore create or overwrite arbitrary files writable by the Erlang VM. The issue is tracked as CVE-2025-4748.

Affected releases

17.0 up to 28.0.0 (fixed in 28.0.1) 27.x up to 27.3.4 (fixed in 27.3.4.1) 26.x up to 26.2.5 (fixed in 26.2.5.13)

Impact

When the zip module is used to extract files to disk and the archive is maliciously corrupted by including absolute file paths, the zip module would extract them as absolute paths instead of stripping the leading /, drive or device letter.

This vulnerability is associated with program files lib/stdlib/src/zip.erl and program routines zip:unzip/1, zip:unzip/2, zip:extract/1, zip:extract/2 unless the memory option is passed.

Mitigation / Fix

Upgrade to one of the fixed releases listed above, or cherry-pick the upstream patch. The patch is available in unified diff form at:

https://patch-diff.githubusercontent.com/raw/erlang/otp/pull/9941.patch

Until you can upgrade, you have two work-arounds:

1. Pass the memory option and perform your own validation before writing files to disk. 2. Call zip:listdir/1 first, reject archives that contain absolute paths, then proceed with extraction.

Credits

Reported by Wander Nauta Patch by Lukas Backström Reviewed by Björn Gustavsson

References

Vendior advisory: https://github.com/erlang/otp/security/advisories/GHSA-9g37-pgj9-wrhc CNA Advisory: https://cna.erlef.org/cves/cve-2025-4748.html CVE record: https://cve.org/CVERecord?id=CVE-2025-4748 Patch PR: https://github.com/erlang/otp/pull/9941

Best Regards, Jonatan Männchen CISO @ Erlang Ecosystem Foundation

Hi all, Details

Client Server

-------Version Banner------->       <-------Version Banner-------        ------SSHMSGKEXINIT------->       <------SSHMSGKEXINIT--------        ----SSHMSGCHANNELOPEN---->        --SSHMSGCHANNELREQUEST---> Client Server

--------Version Banner------->       <-------Version Banner--------       -------SSHMSGKEXINIT------->       <------SSHMSGKEXINIT--------       -----SSHMSGCHANNELOPEN---->       ---SSHMSGCHANNELREQUEST--->       ----SSHMSGKEXECDHINIT---->       <----SSHMSGKEXECDHREPLY---       <-------SSHMSGNEWKEYS-------       --------SSHMSGNEWKEYS------>       <---SSHMSGCHANNELSUCCESS---       <-----SSHMSGCHANNELDATA----       <-----SSHMSGCHANNELEOF-----       <---SSHMSGCHANNELREQUEST---       <----SSHMSGCHANNELCLOSE---- Best regards,

Fabian Bäumer

M. Sc. Fabian Bäumer

Chair for Network and Data Security Ruhr University Bochum Universitätsstr. 150, Building MC 4/145 44780 Bochum Germany

Am 16.04.2025 um 19:28 schrieb Fabian Bäumer: Hi all, Am I affected? Impact Mitigation Advisory Best regards,

Fabian Bäumer

Hi all, Am I affected? Impact Mitigation Advisory Best regards,

Fabian Bäumer

-- M. Sc. Fabian Bäumer

Chair for Network and Data Security Ruhr University Bochum Universitätsstr. 150, Building MC 4/145 44780 Bochum Germany

OTP is a set of Erlang libraries, which consists of the Erlang runtime system, a number of ready-to-use components mainly written in Erlang, and a set of design principles for Erlang programs. A regression was introduced into the ssl application of OTP starting at OTP-25.3.2.8, OTP-26.2, and OTP-27.0, resulting in a server or client verifying the peer when incorrect extended key usage is presented (i.e., a server will verify a client if they have server auth ext key usage and vice versa).