In libexpat before 2.8.1, the computational complexity of attribute name collision checks allows a denial of service via moderately sized crafted XML input.

Summary

Missing Release of Resource after Effective Lifetime vulnerability in Erlang/OTP inets httpd allows an unauthenticated remote attacker to cause denial of service by sending valid request headers with a large Content-Length and then stalling before the body is complete.

httpdrequesthandler:handleinfo/2 cancels the request timeout as soon as a parse step succeeds, which includes the headers, and the clause that handles a decoder asking for more data re-arms the socket with {active, once} without setting any further timer. httpdrequest:wholebody/2 returns such a continuation whenever the bytes received are fewer than the announced Content-Length, so a well-formed request that stops mid-body leaves the worker waiting indefinitely. The periodic byte-rate check that would reclaim it is armed only when minimumbytespersecond is configured, which it is not by default. Repeating this across connections occupies every worker permitted by maxclients and denies service to legitimate clients at negligible bandwidth cost.

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

Workarounds

Set minimumbytespersecond in the httpd configuration, for example {minimumbytespersecond, 200}. This arms a periodic byte-rate check that terminates a connection which has stopped delivering data, reclaiming the parked worker. The check is disabled by default. Place a reverse proxy in front of httpd that enforces its own body-read timeout, such as clientbodytimeout in nginx. Restrict access to the server to trusted clients where the deployment allows it.

Summary

Signed to Unsigned Conversion Error and Out-of-bounds Write vulnerability in Erlang OTP erts allows an attacker who can supply a crafted Erlang external term format (ETF) binary to binarytoterm/1 to corrupt the BEAM heap pointer and crash the virtual machine.

When decoding a LARGETUPLEEXT term, the validation pass decodedsize() in erts/emulator/beam/external.c reads the 32-bit arity field as unsigned (getuint32()), while the decode pass decterm() reads the same field as a signed 32-bit integer (getint32()) into an int. An arity wire value of 0x80000000 passes validation as 2147483648 but decodes as -2147483648, so the subsequent hp += n moves the heap allocation pointer backward. Neither pass enforces the runtime tuple-arity limit MAXARITYVAL. The result is an out-of-bounds heap write; in practice the VM detects an impossible heap size and aborts, denying service. The required padding is large when uncompressed but the compressed-ETF envelope shrinks it to a small payload on the wire.

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

Summary

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 27.3.4.15, OTP 28.5.0.4, and OTP 29.0.4, corresponding to ssl from 10.2 before 11.2.12.11, 11.6.0.4, and 11.7.4.

Summary

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 27.3.4.15, OTP 28.5.0.4, and OTP 29.0.4, corresponding to publickey from 1.15 before 1.17.1.5, 1.20.3.4, and 1.21.4.

Summary

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, OTP 28.5.0.6, and OTP 29.0.6, corresponding to stdlib from 3.5 before 6.2.2.5, 7.3.0.2, and 8.0.4.

Summary

httpd has never implemented obs-fold (RFC 2616 §2.2 / RFC 7230 §3.2.4 header continuation lines). Every CRLF followed by a non-CRLF octet unconditionally starts a new header. This missing feature became a security concern as the understanding of HTTP request smuggling attacks evolved.

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

Summary

Improper Validation of Specified Quantity in Input vulnerability in Erlang/OTP eldap allows a malicious or compromised LDAP server to degrade availability by returning a referral URL whose port component is a very long run of digits.

eldap:parseport/2 passes the port substring straight to listtointeger/1 with no length bound. The surrounding try ... catch only rejects a value that fails to parse, so a syntactically valid port of up to roughly 1.26 million digits converts successfully and costs the caller hundreds of milliseconds of arbitrary-precision arithmetic per referral. The conversion function itself is documented to accept integers of any size, so bounding the input is the caller's responsibility. Reaching the flaw requires the application to pass a server-supplied referral to eldap:parseldapurl/1, which eldap never calls itself: referral strings are returned to the caller unparsed.

This issue affects OTP from OTP 17.0 before OTP 27.3.4.17, OTP 28.5.0.6, and OTP 29.0.6, corresponding to eldap from 1.0.3 before 1.2.14.2, 1.2.16.1, and 1.3.1.

Summary

Path Equivalence vulnerability in Erlang/OTP inets httpd allows a remote unauthenticated attacker to read files inside a modauth protected directory by prefixing the request path with an extra slash.

httpdrequest:validateuri/1 normalises the request URI with uristring:normalize/1, which performs RFC 3986 dot-segment removal but does not collapse empty path segments, so a doubled slash survives. modalias:realname/3 concatenates the document root with that URI, and modauth:secretpath/3 then decides whether the result lies inside a protected directory block by running the configured directory path as an unanchored regular expression against it. The doubled slash breaks the contiguous substring the regex needs, so the request is treated as unprotected and no authentication challenge is issued, while modget opens the same path and the operating system collapses the doubled slash and returns the protected file. The same path mismatch also evades the per-path accounting in modsecurity.

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

Configurations

Only servers that protect a directory with modauth, by configuring a directory block with authentication requirements, are affected. A server that serves no authenticated directory has no protection for this issue to bypass.

Summary

Gracefulness code ignored cases that should be rejected, resulting in possible HTTP Request Smuggling opportunities.

This issue affects OTP from OTP 22.2 before OTP 27.3.4.17, OTP 28.5.0.6, and OTP 29.0.6, corresponding to inets from 7.1.2 before 9.3.2.7, 9.6.2.3, and 9.7.2.

Summary

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, OTP 28.5.0.6, and OTP 29.0.6, corresponding to inets from 5.10 before 9.3.2.7, 9.6.2.3, and 9.7.2. Whether OTP before OTP 17.0, corresponding to inets before 5.10, is affected is unknown.

Summary

An attacker that connects to an open Erlang TCP port that uses the inet driver with {packet,4} mode can use a signed overflow in an incorrect packet length calculation to overflow the receive buffer into the VM allocator area and beyond up to about 2 GB.

This would easily trash the allocated block's allocator metadata footer, and the next block, if any, and most likely cause the BEAM VM to crash. Utilizing this with precision enough to achieve Remote Code Execution would be extremely unfeasible.

This issue affects OTP from OTP 17.0 before OTP 27.3.4.17, OTP 28.5.0.6, and OTP 29.0.6, corresponding to erts from 6.0 before 15.2.7.13, 16.4.0.6, and 17.0.6. Whether OTP before OTP 17.0, corresponding to erts before 6.0, is affected is unknown.

Summary

The modauth module in OTP's inets httpd server, when configured with dets or mnesia authentication backends and multiple directory configuration blocks, collapses all directory blocks into a single shared user/group namespace. A user added to one protected directory is accepted as valid for all other protected directories on the same server instance.

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

Summary

The inets application HTTP server httpd fails to enforce a configured body-size limit on chunked request.

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

Summary

Improper Handling of Case Sensitivity vulnerability in Erlang/OTP inets httpd allows a remote unauthenticated attacker to read files inside a modauth protected directory by requesting them with different casing, on deployments whose filesystem is case-insensitive.

modauth:secretpath/3 decides whether a resolved filesystem path lies inside a protected directory block by running the configured directory path through re:run/3 without the caseless option. A request for /secret/file against a directory configured as /Secret therefore does not match, so the request is treated as unprotected and no authentication challenge is issued, while the filesystem resolves the differently cased path to the same file and modget serves it. Deployments on case-sensitive filesystems are unaffected, because there the filesystem itself rejects the mismatched casing.

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

Workarounds

Host the document root on a case-sensitive filesystem, where the mismatched casing does not resolve to the protected file. Place a reverse proxy in front of httpd that performs its own case-insensitive path matching for the protected paths, or that normalises request path casing before forwarding. Restrict access to the server to trusted clients where the deployment allows it.

Configurations

Two conditions must both hold. The server must protect a directory with modauth, by configuring a directory block with authentication requirements, and the document root must sit where the operating system resolves paths case-insensitively, which is the default on Windows and on macOS. Deployments whose path resolution is case-sensitive are unaffected.

Summary

Time-of-check Time-of-use (TOCTOU) race condition vulnerability in Erlang/OTP ssl (dtlspacketdemux module) allows an unauthenticated remote attacker to crash all active DTLS sessions on a listener.

A DTLS server listener uses a single shared dtlspacketdemux genserver process to route incoming UDP datagrams to the correct connection handler. When a DTLS client reconnects rapidly from the same source address and port (sending multiple ClientHello messages in quick succession), a race condition in the demux's internal gbtrees key-value store causes a {keyexists, {old, Client}} crash, terminating the demux process. Because the demux is shared across all DTLS associations on that listener, its crash immediately kills every active DTLS session, not just the attacker's.

The attack is pre-authentication: the attacker only needs to send UDP datagrams containing valid ClientHello messages from the same source IP and port before the intermediate DOWN monitor message is processed by the genserver. No credentials, no completed handshake, and no special configuration are required, and the crash can be repeated indefinitely to create a persistent denial of service for all clients of that listener.

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

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

Configurations

The application must accept incoming DTLS connections via ssl:listen/2 with a UDP-based transport. TLS-only deployments are not affected.

Summary

The Erlang/OTP httpc HTTP client does not enforce a limit on the total size of response headers received from a server. The maxheadersize option defaults to nolimit, and httpcresponse:parseheaders/6 accumulates every header into a list before the length check runs (which only fires after the terminating CRLF CRLF is received).

A malicious or compromised HTTP server can send an arbitrarily large number of headers, or headers with very large values, causing the client process to allocate unbounded memory until the system runs out of memory or the BEAM VM crashes. A proof-of-concept server sending 100,000 headers of roughly 4000 bytes each caused the client VM to allocate over 13 GB of memory in under 30 seconds.

Any application using httpc:request/4,5 to connect to untrusted servers is affected. No authentication is required: any server the client connects to (including via a redirect or man-in-the-middle) can trigger the exhaustion.

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

Workarounds

Restrict httpc to trusted servers only, and avoid using it to fetch resources from arbitrary or user-supplied URLs. Apply operating-system memory limits (cgroups,ulimit) to contain the blast radius of a runaway client process. Use an alternative HTTP client library that enforces a response header size limit.

Summary

Server-Side Request Forgery (SSRF) vulnerability in Erlang/OTP ftp (ftpinternal module) allows FTP bounce attacks and SSRF via an unvalidated PASV response IP address.

The ftpinternal:handlectrlresult/2 PASV handler (mode=passive, ipfamily=inet, ftpextension=false) extracts the IP address from the server's 227 response and passes it directly to gentcp:connect/4 without validating it against the control connection peer address. The adjacent EPSV handlers correctly call peername(CSock) to derive the IP from the control connection, but the PASV handler does not. A malicious or compromised FTP server can redirect the client's data connection to an arbitrary internal host and port. On read operations (ftp:ls/1,2, ftp:nlist/1,2, ftp:recv/2,3), data from the redirected target is returned to the caller. On write operations (ftp:send/2,3, ftp:append/2,3), file content is sent to the redirected target. This enables SSRF against internal hosts, cloud metadata endpoints, and FTP bounce attacks against third-party hosts.

The vulnerable path is the default configuration (mode=passive, ipfamily=inet, ftpextension=false). RFC 2577 section 3 explicitly recommends validating the PASV response IP against the control connection peer.

The ftp application is deprecated and scheduled for removal in OTP-30.

This vulnerability is associated with program files lib/inets/src/ftp/ftpinternal.erl (inets 5.10.4 through 6.5, OTP 17.4 through 20.3) and lib/ftp/src/ftpinternal.erl (ftp 1.0 and later, OTP 21.0 and later).

This issue affects OTP from OTP 17.4 before OTP 27.3.4.13, OTP 28.5.0.2, and OTP 29.0.2, corresponding to inets from 5.10.4 before 7.0, and ftp from 1.0 before 1.2.3.1, 1.2.4.1, and 1.2.6.

Workarounds

Pass {ftpextension, true} to ftp:open/2 to use EPSV instead of PASV. Alternatively, pass {mode, active} to use active mode, or pass {ipfamily, inet6} to force IPv6, both of which bypass the vulnerable PASV path.

Configurations

The vulnerable path is active under the default configuration: mode=passive, ipfamily=inet, and ftpextension=false are all defaults for ftp:open/2.

Summary

Use of Default Cryptographic Key vulnerability in Erlang/OTP ssl (DTLS server) allows predictable DTLS cookie computation during the startup window, enabling source address verification bypass.

On DTLS server startup, dtlsserverconnection:initialhello/3 initializes previouscookiesecret to the empty binary (<<>>) instead of a random value. Because HMAC with an empty key is deterministic, anyone who observes the plaintext ClientHello can compute dtlshandshake:cookie(<<>>, IP, Port, Hello) and forge a valid DTLS cookie before the first rotation of the cookie secret. The DTLS cookie (RFC 6347 §4.2.1) is a denial-of-service mitigation that prevents spoofed source IPs from forcing the server to allocate state and perform expensive cryptographic operations; it is not an authentication mechanism. During the window from server startup until the first secret rotation (0 to 15 seconds), an attacker who can observe the plaintext ClientHello can bypass the source address verification, enabling DTLS handshake amplification with spoofed source addresses.

This vulnerability is associated with program file lib/ssl/src/dtlsserverconnection.erl and program routine dtlsserverconnection:initialhello/3.

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

Summary

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 27.3.4.14, OTP 28.5.0.3, and OTP 29.0.3, corresponding to ssh from 3.0.1 before 5.2.11.9, 5.5.2.2, and 6.0.2. Whether OTP before OTP 17.0, corresponding to ssh before 3.0.1, is affected is unknown.

Workarounds

Set the maxchannels daemon option to a finite value (e.g., {maxchannels, 10}) to limit the number of channels an attacker can open per connection. Set the maxsessions daemon option to limit total concurrent SSH connections to the daemon. Use external process monitoring to detect and kill sshsftpd processes with abnormally high reduction counts and growing message queues. Ensure that the SFTP server port is not reachable from untrusted machines.

Summary

Improper Handling of Exceptional Conditions vulnerability in Erlang OTP erts (epmd) allows an unauthenticated remote attacker to permanently terminate the Erlang Port Mapper Daemon (epmd) via connection slot exhaustion.

The doaccept function in erts/epmd/src/epmdsrv.c calls epmdcleanupexit() when accept(2) returns EMFILE (per-process file descriptor limit reached) or ENFILE (system-wide file descriptor limit reached), rather than treating these as recoverable conditions. An attacker can exhaust epmd's file descriptor slots by holding many TCP connections open while periodically sending a single byte to reset the idle timeout, then causing accept(2) to return EMFILE, which kills the daemon. epmd has no per-source-IP connection cap, making the attack feasible from a single source.

On Debian/Ubuntu default packaging the impact is amplified: the systemd unit inherits a low file descriptor soft limit, and repeated daemon deaths trigger systemd's start-rate-limit, permanently failing both epmd.service and epmd.socket and requiring manual operator intervention to recover.

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

Workarounds

Restrict epmd to loopback only by adding a systemd socket override: set ListenStream= (empty, to clear), then ListenStream=127.0.0.1:4369 and ListenStream=[::1]:4369 in /etc/systemd/system/epmd.socket.d/override.conf. On systemd-managed systems, raise the file descriptor limit and configure automatic restart by adding LimitNOFILE=65536 and Restart=always with a suitable RestartSec in /etc/systemd/system/epmd.service.d/override.conf. Restrict network access to TCP port 4369 via firewall rules to trusted hosts only.

Summary

Improper Handling of Highly Compressed Data (Compression Bomb) vulnerability in Erlang OTP ssh (sshtransport modules) allows Denial of Service via Resource Depletion.

The SSH transport layer advertises legacy zlib compression by default and inflates attacker-controlled payloads pre-authentication without any size limit, enabling reliable memory exhaustion DoS.

Two compression algorithms are affected:

zlib: Activates immediately after key exchange, enabling unauthenticated attacks zlib@openssh.com: Activates post-authentication, enabling authenticated attacks

Each SSH packet can decompress ~255 MB from 256 KB of wire data (1029:1 amplification ratio). Multiple packets can rapidly exhaust available memory, causing OOM kills in memory-constrained environments.

This vulnerability is associated with program files lib/ssh/src/sshtransport.erl and program routines sshtransport:decompress/2, sshtransport:handlepacketpart/4.

This issue affects OTP from OTP 17.0 before OTP 26.2.5.18, OTP 27.3.4.9, and OTP 28.4.1, corresponding to ssh from 3.0.1 before 5.1.4.14, 5.2.11.6, and 5.5.1.

Workarounds

Best workaround - Disable all compression:

erlang {preferredalgorithms, [{compression, ['none']}]}

Alternative mitigations (less secure):

Disable only pre-auth zlib compression (authenticated users can still exploit via zlib@openssh.com):

erlang {modifyalgorithms, [{rm, [{compression, ['zlib']}]}]}

Limit concurrent sessions (reduces attack surface but does not prevent exploitation):

erlang {maxsessions, N} % Cap total concurrent sessions (default is infinity)

Configurations

The SSH server or client must advertise zlib or zlib@openssh.com compression. Both are enabled by default. With zlib, the attack is pre-authentication; with zlib@openssh.com, authentication is required first.

Summary

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 26.2.5.20, OTP 27.3.4.11, and OTP 28.4.3, corresponding to ssh from 3.0.1 before 5.1.4.15, 5.2.11.7, and 5.5.2. Whether OTP before OTP 17.0, corresponding to ssh before 3.0.1, is affected is unknown.

Workarounds

Do not use the root option in sshsftpd:subsystemspec/1, and instead rely on OS-level chroot or container isolation to confine SFTP users. Ensure the Erlang VM is not running as a privileged OS user. Running the VM as an unprivileged user limits the impact of this vulnerability, since attribute modifications are constrained by that user's OS-level permissions.

Configurations

The SFTP subsystem must be configured with the root option in sshsftpd:subsystemspec/1. The root option is not set by default.

Summary

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, OTP 27.3.4.12, OTP 28.5.0.1, and OTP 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.

Workarounds

The verifyfun option in the ssl application can be used to ensure that TLS connections fail if the end-entity certificate is missing the subjectAltName extension or has no domain name. Do not use a verifyfun that accepts the namenotpermitted error.

Summary

Allocation of Resources Without Limits or Throttling vulnerability in Erlang OTP ssh (sshsftp modules) allows Excessive Allocation, Resource Leak Exposure.

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

This issue affects OTP from OTP 17.0 before OTP 26.2.5.15, OTP 27.3.4.3, and OTP 28.0.3, corresponding to ssh from 3.0.1 before 5.1.4.12, 5.2.11.3, and 5.3.3.

Workarounds

Disable sftp limiting number of maxsessions allowed for sshd, so exploiting becomes more complicated

Configurations

The SFTP subsystem must be enabled on the SSH server and the SSH port must be reachable by the attacker. SFTP is enabled by default unless explicitly disabled by setting {subsystems, []} in the SSH daemon configuration.

Summary

Allocation of Resources Without Limits or Throttling vulnerability in Erlang OTP ssh (sshsftp modules) allows Excessive Allocation, Resource Leak Exposure.

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

This issue affects OTP from OTP 17.0 before OTP 26.2.5.15, OTP 27.3.4.3, and OTP 28.0.3, corresponding to ssh from 3.0.1 before 5.1.4.12, 5.2.11.3, and 5.3.3.

Workarounds

Disable sftp limiting number of maxsessions allowed for sshd, so exploiting becomes more complicated

Configurations

The SFTP subsystem must be enabled on the SSH server and the SSH port must be reachable by the attacker. SFTP is enabled by default unless explicitly disabled by setting {subsystems, []} in the SSH daemon configuration.

Summary

Allocation of Resources Without Limits or Throttling vulnerability in Erlang OTP ssh (sshsftp modules) allows Excessive Allocation, Flooding.

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

This issue affects OTP from OTP 17.0 before OTP 26.2.5.15, OTP 27.3.4.3, and OTP 28.0.3, corresponding to ssh from 3.0.1 before 5.1.4.12, 5.2.11.3, and 5.3.3.

Workarounds

disabling SFTP limiting number of maxsessions allowed for sshd, so exploiting becomes more complicated

Configurations

The SFTP subsystem must be enabled on the SSH server and the SSH port must be reachable by the attacker. SFTP is enabled by default unless explicitly disabled by setting {subsystems, []} in the SSH daemon configuration.

Summary

Uncontrolled Resource Consumption vulnerability in Erlang OTP ssh (sshsftp modules) allows Excessive Allocation, Flooding.

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

This issue affects OTP from OTP 17.0 before OTP 26.2.5.15, OTP 27.3.4.3, and OTP 28.0.3, corresponding to ssh from 3.0.1 before 5.1.4.12, 5.2.11.3, and 5.3.3.

Workarounds

set option parallellogin to false reduce maxsessions option

Summary

Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') vulnerability in Erlang OTP (sshsftpd module) allows Path Traversal.

This vulnerability is associated with program files lib/ssh/src/sshsftpd.erl and program routines sshsftpd:iswithinroot/2.

The SFTP server uses string prefix matching via lists:prefix/2 rather than proper path component validation when checking if a path is within the configured root directory. This allows authenticated users to access sibling directories that share a common name prefix with the configured root directory. For example, if root is set to /home/user1, paths like /home/user10 or /home/user1backup would incorrectly be considered within the root.

This issue affects OTP from OTP 17.0 before OTP 26.2.5.18, OTP 27.3.4.9, and OTP 28.4.1, corresponding to ssh from 3.0.1 before 5.1.4.14, 5.2.11.6, and 5.5.1. Whether OTP before OTP 17.0, corresponding to ssh before 3.0.1, is affected is unknown.

Workarounds

Use OS-level chroot to run the Erlang VM/SFTP server process in an isolated filesystem environment. Ensure that no sensitive or precious data is readable or writable by the OS user running the Erlang VM. Ensure that the SFTP server port is not reachable from untrusted machines. Use directory naming conventions that avoid common prefixes (e.g., /home/users/alice/ instead of /home/user1/).

Configurations

The SFTP subsystem must be enabled on the SSH server, the SSH port must be reachable by the attacker, and a root directory must be configured. This is the case when sshsftpd is included in the subsystems option with a root parameter and there exist sibling directories sharing the same name prefix as the root.

Summary

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 26.2.5.18, OTP 27.3.4.9, and OTP 28.4.1, corresponding to inets from 5.10 before 9.1.0.5, 9.3.2.3, and 9.6.1. Whether OTP before OTP 17.0, corresponding to inets before 5.10, is affected is unknown.

Workarounds

Configure frontend proxy to reject requests with duplicate Content-Length headers. Disable HTTP keep-alive on httpd by adding {keepalive, false} to httpd configuration. Note: This impacts performance for clients making multiple requests. Deploy a Web Application Firewall (WAF) configured to reject requests with multiple Content-Length headers.

Configurations

The inets httpd server must be deployed behind a reverse proxy that honors a different Content-Length header than httpd (e.g., last vs. first). HTTP keep-alive must be enabled (the default).