inets in Erlang possibly 22.1 and earlier follows RFC 3875 section 4.1.18 and therefore does not protect applications from the presence of untrusted client data in the HTTP_PROXY environment variable, which might allow remote attackers to redirect an application's outbound HTTP traffic to an arbitrary proxy server via a crafted Proxy header in an HTTP request, aka an "httpoxy" issue.
Erlang/OTP Rebar3 version 3.7.0 through 3.7.5 contains a Signing oracle vulnerability in Package registry verification that can result in Package modifications not detected, allowing code execution. This attack appears to be exploitable via Victim fetches packages from malicious/compromised mirror. This vulnerability appears to have been fixed in 3.8.0.
The Erlang otp TLS server answers with different TLS alerts to different error types in the RSA PKCS #1 1.5 padding. This allows an attacker to decrypt content or sign messages with the server's private key (this is a variation of the Bleichenbacher attack).
An issue was discovered in Erlang/OTP 18.x. Erlang's generation of compiled regular expressions is vulnerable to a heap overflow. Regular expressions using a malformed extpattern can indirectly specify an offset that is used as an array index. This ordinal permits arbitrary regions within the erts_alloc arena to be both read and written to.
Erlang/OTP before 18.0-rc1 does not properly check CBC padding bytes when terminating connections, which makes it easier for man-in-the-middle attackers to obtain cleartext data via a padding-oracle attack, a variant of CVE-2014-3566 (aka POODLE).
The random number generator in the Crypto application before 2.0.2.2, and SSH before 2.0.5, as used in the Erlang/OTP ssh library before R14B03, uses predictable seeds based on the current time, which makes it easier for remote attackers to guess DSA host and SSH session keys.
lib/crypto/c_src/crypto_drv.c in erlang does not properly check the return value from the OpenSSL DSA_do_verify function, which might allow remote attackers to bypass validation of the certificate chain via a malformed SSL/TLS signature, a similar vulnerability to CVE-2008-5077. NOTE: a package maintainer disputes this issue, reporting that there is a proper check within the only code that uses the applicable part of crypto_drv.c, and thus "this report is invalid.