Allocation of Resources Without Limits or Throttling vulnerability in Erlang/OTP ssh allows an authenticated remote attacker to exhaust node memory by repeatedly opening session channels that are never assigned a handler.

The "session" clause of sshconnection:handlemsg/4 checks only minimalremotemaxpacketsize before calling setupsession/5, which unconditionally builds a #channel{} record and stores it in the ETS channel cache. The maxchannels daemon option is consulted only by sshchannelsup:maxnumchannelsnotexceeded/2, which counts supervisor children, so a channel that never gets a shell, exec, or subsystem handler is invisible to the limit and setting the option to a finite value does not mitigate the attack. RFC 4254 section 5.1 permits many session channels per connection, and each record costs only a few hundred bytes, so a single authenticated connection can accumulate channels until the node runs out of memory and the emulator terminates, affecting every application on it. No file contents, credentials, or write access are obtainable.

This issue affects OTP from OTP 18.1.2 before OTP 27.3.4.18, OTP 28.5.0.7, and OTP 29.1.1, corresponding to ssh from 4.1.1 before 5.2.11.13, 5.5.2.6, and 6.0.6. Whether OTP before OTP 18.1.2, corresponding to ssh before 4.1.1, is affected is unknown.

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

Key Exchange without Entity Authentication vulnerability in Erlang/OTP ssl allows a peer that answers a TLS 1.3 client connection to impersonate the intended server. A presharedkey extension in the ServerHello that the client never offered causes the client to complete the handshake without validating the server's certificate, so ssl:connect returns {ok, Socket} against a peer holding no certificate, no private key and no prior session.

tlsclientconnection13:handleserverhello/2 passes the received extension to tlsgenconnection13:handleresumption/2, which sets resumption = true on its mere presence without checking that the client offered a PSK. tlshandshake13:getpresharedkey/4 meanwhile falls back to the all-zero "no PSK" value and keys the handshake with the ordinary non-PSK schedule, so the attacker's own ephemeral key suffices. The resumption flag then routes mayberesumption/1 straight to waitfinished, skipping the certificate-handling states, so certificate path validation, verifyfun, hostname verification, partialchain, CRL checking and OCSP stapling are all bypassed. The default client configuration is affected; clients restricted to TLS 1.2 are not.

This issue affects OTP from OTP 22.2 before OTP 27.3.4.18, OTP 28.5.0.7, and OTP 29.1.1, corresponding to ssl from 9.5 before 11.2.12.13, 11.6.0.6, and 11.7.7.

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.

Erlang Erlang/OTP SSH server contains a missing authentication for critical function vulnerability. This could allow an attacker to execute arbitrary commands without valid credentials, potentially leading to unauthenticated remote code execution (RCE). By exploiting a flaw in how SSH protocol messages are handled, a malicious actor could gain unauthorized access to affected systems. This vulnerability could affect various products that implement Erlang/OTP SSH server, including—but not limited to—Cisco, NetApp, and SUSE.

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.

XML External Entity (XXE) vulnerability in esaml (and its forks) allows an attacker to cause the system to read local files and incorporate their contents into processed SAML documents, and potentially perform SSRF via crafted SAML messages.

esaml parses attacker-controlled SAML messages using xmerlscan:string/2 before signature verification without disabling XML entity expansion. On Erlang/OTP versions before 27, Xmerl allows entities by default, enabling pre-signature XXE attacks. An attacker can cause the host to read local files (e.g., Kubernetes-mounted secrets) into the SAML document. If the attacker is not a trusted SAML SP, signature verification will fail and the document is discarded, but file contents may still be exposed through logs or error messages.

This issue affects all versions of esaml, including forks by arekinath, handnot2, and dropbox. Users running on Erlang/OTP 27 or later are not affected due to Xmerl defaulting to entities disabled.