Improper Validation of Specified Quantity in Input vulnerability in Erlang/OTP snmp allows a remote attacker to degrade availability by sending an SNMP message containing a BER INTEGER whose length field is arbitrarily large.

snmppdus:decintegernotag/1 defaults its size limit to infinity, and dodecintegernotag/2 then accumulates the value across every declared byte with a recursive shift and bitwise or. Work grows superlinearly in the declared length because each operation acts on a progressively larger bignum. The size-limited variant decintegernotag/2 exists but is reached from only one call site, decsnmpversion/1, which bounds the version field to ten bytes; the request identifier, error status and index, generic and specific trap fields, engine boots and time, and every varbind value decoded by decvalue/1 all use the unbounded form. The decode runs before the PDU is processed, so no valid request is required beyond what the deployment demands to accept the message at all.

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 snmp from 4.25.1 before 5.18.2.1, from 5.19 before 5.20.2.2, and from 5.20.3 before 5.20.5. Whether OTP before OTP 17.0, corresponding to snmp before 4.25.1, is affected is unknown.

httpd applies no timeout while receiving a request body, parking a worker on a stalled client

Integer Underflow (Wrap or Wraparound) vulnerability in erlang otp erlang/otp (erts modules), erlang otp erts (erts modules) allows Forced Integer Overflow, Excessive Allocation. This vulnerability is associated with program files erts/emulator/beam/external.c, emulator/beam/external.c.

The BITBINARYEXT tag (77) handler in the External Term Format (ETF) decoder accepts an encoding with both length and trailing-bits fields set to zero. The subsequent computation of the bitstring size underflows an unsigned integer, producing a value of roughly 2^64 that is then passed as a memory allocation size. The allocator aborts the entire node with a message such as "Cannot allocate 2305843009213693951 bytes of memory (of type binary)".

The crash is a VM-level abort, not an Erlang-level exception. It cannot be intercepted by supervision trees, by try/catch, or by passing the [safe] option to binarytoterm/2 (which only restricts atom creation and does not perform structural validation of binary encodings).

Any application that decodes ETF from untrusted sources via binarytoterm/1,2 or enifbinarytoterm() is exposed. The Erlang distribution protocol also decodes incoming terms through the same code path, but distribution is expected to run on trusted networks per the OTP Secure Coding Guidelines (DSG-011).

This issue affects OTP from OTP 27.0 before OTP 29.0.4, OTP 28.5.0.4 and OTP 27.3.4.15, corresponding to erts from 15.0 before 17.0.4, 16.4.0.4 and 15.2.7.11.

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.

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.

Heap pointer corruption via signed/unsigned mismatch in LARGETUPLEEXT decoding in erts external term format decoder

Relative Path Traversal vulnerability in Erlang OTP (stdlib zip module) allows writing files outside the intended extraction directory via a crafted zip archive.

zip:unzip/1,2 and zip:extract/1,2 validate entry paths using zip:checkdirlevel/2, which tracks directory depth as a running integer counter: .. decrements it, normal path components increment it. The caller rejects only paths where the final counter value is less than zero. A path such as ../x/y causes the counter to go negative mid-traversal then recover to zero, passing validation while resolving to a location outside the extraction directory when joined with the current working directory via addcwd.

This vulnerability is associated with program file lib/stdlib/src/zip.erl.

This issue affects OTP from OTP 27.1 before OTP 29.0.4, OTP 28.5.0.4 and OTP 27.3.4.15, corresponding to stdlib from 6.1 before 8.0.3, 7.3.0.1 and 6.2.2.4.

epmd permanent DoS via EMFILE on accept(2) in erts

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

Loop with Unreachable Exit Condition ('Infinite Loop') vulnerability in Erlang OTP ssh (sshsftpd module) allows an authenticated SFTP user to render an SFTP channel permanently unresponsive.

The handledata/4 function in sshsftpd contains a catch-all clause that accepts channel data of any type. When channel data with a non-zero type code (SSHMSGCHANNELEXTENDEDDATA) arrives with an empty pending buffer and a payload at or below the SFTP packet size limit, the clause tail-calls itself with identical arguments, creating an infinite loop.

The SFTP protocol operates exclusively on normal channel data (type 0). Extended data (non-zero type) is meaningless for SFTP and is never sent by conforming clients. However, the SSH protocol permits any channel participant to send extended data on an open channel, so an authenticated SFTP client can trigger the loop by sending SSHMSGCHANNELEXTENDEDDATA with any datatypecode and any non-empty payload at or below the size limit.

The targeted sshsftpd process enters an infinite tail-recursive loop. It never processes another message, its message queue grows without bound, and it can only be stopped by killing the process. BEAM's reduction-based scheduler preemption continues to function, so other processes on the node are not starved, but each stuck channel process consumes its full CPU time share continuously and accumulates unbounded message queue memory. Opening many channels amplifies the CPU and memory impact.

Erlang/OTP SSH configurations using the default maxchannels setting (infinity) allow an authenticated user to open unlimited channels per connection, amplifying the attack without requiring multiple TCP connections or authentications.

No file contents, credentials, or write access are obtainable through this issue. The impact is limited to denial of service on targeted SFTP channels, with secondary CPU degradation and memory growth.

This vulnerability is associated with program file lib/ssh/src/sshsftpd.erl and program routine sshsftpd:handledata/4.

This issue affects OTP from OTP 17.0 before OTP 29.0.3, OTP 28.5.0.3 and OTP 27.3.4.14, corresponding to ssh from 3.0.1 before 6.0.2, 5.5.2.2 and 5.2.11.9.

The Erlang/OTP ssl application does not validate that the PSK identity list and binder list carried in a TLS 1.3 ClientHello pre-shared key extension have equal length before passing them to the session ticket handler. In tlshandshake13:handlepresharedkey/3, an OfferedPreSharedKeys record with a mismatched number of identities and binders is forwarded directly to tlsserversessionticket:use/4, which crashes the session ticket handler process.

An unauthenticated remote attacker can send a single crafted ClientHello to a TLS 1.3 server with session tickets enabled (stateful or stateless mode) and permanently disrupt session ticket handling on that listener. New TLS 1.3 handshakes complete but subsequently crash when the server attempts to issue a session ticket, effectively making TLS 1.3 unusable on the affected listener until the ssl application is restarted. TLS 1.2 connections are not affected.

This issue affects OTP from OTP 22.2 before OTP 29.0.3, OTP 28.5.0.3 and OTP 27.3.4.14, corresponding to ssl from 9.5 before 11.7.3, 11.6.0.3 and 11.2.12.10.

DTLS server cookie bypass during startup window due to empty initial cookie secret

Observable Response Discrepancy vulnerability in Erlang OTP ssh (sshsftpd module) allows an authenticated SFTP user to enumerate the existence of files and directories outside the configured root directory.

The SSHFXPREALPATH handler in sshsftpd calls relatefilename/3 with Canonicalize=false, unlike every other SFTP operation handler. This allows .. components in the requested path to bypass the iswithinroot/2 check without being resolved. The un-canonicalized path then enters resolvesymlinks/2, which walks up the directory tree above the configured root and issues readlink() syscalls on arbitrary filesystem paths.

An authenticated SFTP client can exploit this by sending a REALPATH request with a crafted traversal path. The server response differs depending on whether the target path exists on the host filesystem (SSHFXPNAME when the path resolves successfully, SSHFXNOSUCHFILE when it does not). This creates a path-existence oracle that an attacker can use to enumerate the filesystem structure outside the configured root, including the existence of sensitive files, directories, and mount points.

The vulnerability leaks only the existence of paths. No file contents, credentials, or write access are obtainable through this issue alone. The information gained may assist further attacks when combined with other vulnerabilities.

This vulnerability is associated with program files lib/ssh/src/sshsftpd.erl and program routine sshsftpd:handleop/4.

This issue affects OTP from OTP 17.0 before OTP 29.0.3, OTP 28.5.0.3 and OTP 27.3.4.14, corresponding to ssh from 3.0.1 before 6.0.2, 5.5.2.2 and 5.2.11.9.

Stack-based Buffer Overflow vulnerability in Erlang OTP erts (inetdrv) allows an unauthenticated remote attacker to crash the BEAM VM by sending a crafted SCTP ERROR chunk.

The sctpparseerrorchunk function in erts/emulator/drivers/common/inetdrv.c parses SCTP ERROR chunks and writes cause codes into a fixed-size stack-allocated ErlDrvTermData spec[] array without checking bounds. A remote attacker who has established an SCTP association to a listening port can send a single crafted SCTP ERROR chunk containing enough cause codes to overflow the stack buffer, crashing the VM. The attacker can only write 16-bit values interleaved with a fixed tag, so the overflow does not provide a controlled return address, limiting exploitation to Denial of Service.

A crafted SCTP ERROR chunk may also leak bits and pieces of Erlang VM memory into the received error packet observed by the Erlang process. Such data is already readable by the user running the Erlang VM, so the disclosure scope is limited.

This issue affects OTP from OTP 17.0 before 27.3.4.13, 28.5.0.2 and 29.0.2, corresponding to erts from 6.0 before 15.2.7.9, 16.4.0.2 and 17.0.2.

httpc leaks Authorization header to cross-origin redirect targets

Exposure of Sensitive Information to an Unauthorized Actor vulnerability in Erlang OTP ssh (sshsftpd module) allows File Discovery.

The SSHFXPREADLINK handler in sshsftpd sends the raw result of file:readlink/2 to the client without calling chrootfilename/2 to strip the backend root prefix. An authenticated SFTP client can create a symlink inside the chroot pointing to /; sshsftpd resolves the target to the absolute backend root and stores it on disk. Reading the symlink back via SSHFXPREADLINK returns that absolute path, for example /data/sftp, instead of the chrooted value /.

The information disclosed is the absolute filesystem path of the SFTP root directory and of any symlink targets within it. No file contents, credentials, or access to paths outside the root directory are obtainable through this issue alone.

This vulnerability is associated with program files lib/ssh/src/sshsftpd.erl.

This issue affects OTP from OTP 17.0 before OTP 29.0.2, OTP 28.5.0.2 and OTP 27.3.4.13, corresponding to ssh from 3.0.1 before 6.0.1, 5.5.2.1 and 5.2.11.8.

Distribution-over-TLS LAN allowlist silently bypassed due to sockname/peername confusion in inettlsdist

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

Observable Timing Discrepancy vulnerability in Erlang/OTP ssh (sshauth, sshoptions modules) allows unauthenticated remote username enumeration via timing side-channel in password authentication.

When the SSH daemon is configured with the userpasswords or password option, sshauth:checkpassword/3 performs a PBKDF2-SHA256 computation with 600,000 iterations (~300ms) for valid usernames, but returns immediately (~0ms) for invalid usernames via the sshoptions:getpasswordoption/2 path. This timing difference is detectable in a single authentication attempt and allows an unauthenticated attacker to distinguish valid from invalid usernames.

The userpasswords and password options are documented as intended for test purposes; the recommended alternative is pwdfun, which is not affected by this vulnerability.

This vulnerability is associated with program files lib/ssh/src/sshauth.erl and lib/ssh/src/sshoptions.erl.

This issue affects OTP from OTP 29.0 before OTP 29.0.2, corresponding to ssh from 6.0 before 6.0.1.

Stack buffer overflow in SCTP error cause parsing in inetdrv allows remote VM crash

Stack Buffer Overflow in eisprintterm at Very Large Integer

Improper Certificate Validation vulnerability in Erlang OTP publickey (pubkeycert and publickey modules) allows a DNS nameConstraints bypass via subject CommonName fallback in TLS hostname verification.

Two flaws combine to allow a subordinate CA whose DNS nameConstraints are restricted (e.g. permitted;DNS:allowed.example.com) to issue a leaf certificate that an OTP TLS client accepts as a valid identity for an out-of-scope hostname (e.g. victim.example.com):

First, pubkeycert:validatenames/6 in lib/publickey/src/pubkeycert.erl only checks SAN DNS entries against nameConstraints. Per RFC 5280, a permitted DNS subtree only restricts certificates that contain a DNS-typed name. A leaf with no subjectAltName therefore trivially satisfies any permitted;DNS:... constraint regardless of its subject commonName.

Second, publickey:pkixverifyhostname/3 in lib/publickey/src/publickey.erl falls back to the subject commonName when no subjectAltName is present, extracting id-at-commonName attributes as presented IDs and matching them against the reference hostname. The strict pkixverifyhostnamematchfun(https) matcher does not suppress this fallback.

The result is that path validation accepts a CN-only leaf under a DNS-constrained intermediate (no SAN means the nameConstraints are not triggered), and hostname verification then accepts it via the CN fallback. The bypass is reachable from stock ssl:connect with verifypeer, a trusted CA, SNI, and the canonical strict https hostname matcher.

This issue affects OTP from OTP 19.3 before OTP 26.2.5.21, 27.3.4.12, 28.5.0.1, and 29.0.1 corresponding to publickey from 1.4 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 (pubkeycert and publickey modules) allows a DNS nameConstraints bypass via subject CommonName fallback in TLS hostname verification.

Two flaws combine to allow a subordinate CA whose DNS nameConstraints are restricted (e.g. permitted;DNS:allowed.example.com) to issue a leaf certificate that an OTP TLS client accepts as a valid identity for an out-of-scope hostname (e.g. victim.example.com):

First, pubkeycert:validatenames/6 in lib/publickey/src/pubkeycert.erl only checks SAN DNS entries against nameConstraints. Per RFC 5280, a permitted DNS subtree only restricts certificates that contain a DNS-typed name. A leaf with no subjectAltName therefore trivially satisfies any permitted;DNS:... constraint regardless of its subject commonName.

Second, publickey:pkixverifyhostname/3 in lib/publickey/src/publickey.erl falls back to the subject commonName when no subjectAltName is present, extracting id-at-commonName attributes as presented IDs and matching them against the reference hostname. The strict pkixverifyhostnamematchfun(https) matcher does not suppress this fallback.

The result is that path validation accepts a CN-only leaf under a DNS-constrained intermediate (no SAN means the nameConstraints are not triggered), and hostname verification then accepts it via the CN fallback. The bypass is reachable from stock ssl:connect with verifypeer, a trusted CA, SNI, and the canonical strict https hostname matcher.

This issue affects OTP from OTP 19.3 before OTP 26.2.5.21, 27.3.4.12, 28.5.0.1, and 29.0.1 corresponding to publickey from 1.4 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 forged OCSP responses signed with an expired responder certificate to be accepted as valid.

OCSP response verification in pubkeyocsp:verifyresponse/5 and pubkeyocsp:isauthorizedresponder/3 in lib/publickey/src/pubkeyocsp.erl does not check the validity period (notBefore/notAfter) of the OCSP responder certificate. An attacker who has obtained the private key of an expired CA-designated OCSP responder certificate can forge OCSP responses that Erlang/OTP accepts as valid.

This affects TLS clients using OCSP stapling via the ssl application: a malicious or compromised server can present a revoked TLS certificate together with a forged OCSP response signed by an expired responder key, and the client will accept the revoked certificate as valid. It also affects applications calling publickey:pkixocspvalidate/5 directly, where the impact depends on the use case — server-side client certificate validation using this API may allow authentication bypass with a revoked client certificate.

This issue affects OTP from OTP 27.0 before OTP 29.0.1, OTP 28.5.0.1 and OTP 27.3.4.12, corresponding to publickey from 1.16 before 1.21.1, 1.20.3.1 and 1.17.1.3.

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.

End of life: 5/11/2029, Latest version: 29.0.6

Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') vulnerability in Erlang OTP ssh (sshsftpd module) allows an authenticated SFTP user to modify file attributes outside the configured chroot directory.

The SFTP daemon (sshsftpd) stores the raw, user-supplied path in file handles instead of the chroot-resolved path. When SSHFXPFSETSTAT is issued on such a handle, file attributes (permissions, ownership, timestamps) are modified on the real filesystem path, bypassing the root directory boundary entirely.

Any authenticated SFTP user on a server configured with the root option can modify file attributes of files outside the intended chroot boundary. The prerequisite is that a target file must exist on the real filesystem at the same relative path. Note that this vulnerability only allows modification of file attributes; file contents cannot be read or altered through this attack vector.

If the SSH daemon runs as root, this enables direct privilege escalation: an attacker can set the setuid bit on any binary, change ownership of sensitive files, or make system configuration world-writable.

This vulnerability is associated with program files lib/ssh/src/sshsftpd.erl and program routines sshsftpd:doopen/4 and sshsftpd:handleop/4.

This issue affects OTP from OTP 17.0 before OTP 28.4.3, OTP 27.3.4.11 and OTP 26.2.5.20, corresponding to ssh from 3.0.1 before 5.5.3, 5.2.11.7 and 5.1.4.15.

Incorrect Authorization vulnerability in Erlang OTP (inets modules) allows unauthenticated access to CGI scripts protected by directory rules when served via scriptalias.

When scriptalias maps a URL prefix to a directory outside DocumentRoot, modauth evaluates directory-based access controls against the DocumentRoot-relative path while modcgi executes the script at the ScriptAlias-resolved path. This path mismatch allows unauthenticated access to CGI scripts that directory rules were meant to protect.

This vulnerability is associated with program files lib/inets/src/httpserver/modalias.erl, lib/inets/src/httpserver/modauth.erl, and lib/inets/src/httpserver/modcgi.erl.

This issue affects OTP from OTP 17.0 until OTP 28.4.2, 27.3.4.10 and 26.2.5.19 corresponding to inets from 5.10 until 9.6.2, 9.3.2.4 and 9.1.0.6.