Hi,
The following vulnerabilities were published for erlang.
CVE-2026-55951[0]:
| The Erlang/OTP httpc HTTP client does not enforce a limit on the
| total size of response headers received from a server. The
| max_header_size option defaults to nolimit, and
| httpc_response:parse_headers/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, 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.
CVE-2026-59696[1]:
| 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. uri_string:get_port/1 passes the port substring to
| binary_to_integer/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
| uri_string: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.
CVE-2026-66835[2]:
| Path Equivalence vulnerability in Erlang/OTP inets httpd allows a
| remote unauthenticated attacker to read files inside a mod_auth
| protected directory by prefixing the request path with an extra
| slash. httpd_request:validate_uri/1 normalises the request URI with
| uri_string:normalize/1, which performs RFC 3986 dot-segment removal
| but does not collapse empty path segments, so a doubled slash
| survives. mod_alias:real_name/3 concatenates the document root with
| that URI, and mod_auth:secret_path/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 mod_get 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 mod_security. 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.
CVE-2026-69664[3]:
| 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 a request with a chunked body
| whose chunk-size line is not a hexadecimal number. The worker
| serving the connection is never released and no timeout reclaims it,
| so repeating the request across connections occupies every available
| worker and denies service to legitimate clients. No authentication
| is required and the default configuration is affected. The chunk-
| size line must arrive in a write separate from the headers. When the
| body accompanies the headers, httpd_request_handler:handle_body/3
| calls http_chunk:decode/3 inside a try ... catch throw:Error, so the
| {error, {chunk_size, _}} thrown by http_chunk:decode_size/4 is
| answered with 400 Bad Request. When the chunk size arrives later,
| the decoder is resumed through a bare catch in
| httpd_request_handler:handle_info/2, which converts the throw into a
| return value rather than raising it; the resulting error tuple is
| then treated as the next decoder continuation, the socket is re-
| armed, and the worker waits for data that never comes. The request
| timeout has already been cancelled at the point the headers were
| accepted, and the periodic byte-rate check is only armed when
| minimum_bytes_per_second is configured, which it is not by default.
| This issue affects OTP from OTP 18.1.4 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 6.0.3 before 9.3.2.7, from 9.4 before
| 9.6.2.3, and from 9.7 before 9.7.2.
CVE-2026-70399[4]:
| 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 max_clients 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
| httpd_manager:handle_new_connection/4 reads the option with
| httpd_util:lookup/2, which returns undefined when the key is absent,
| rather than the three-argument form carrying the 150 default that
| the neighbouring get_ustate/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 max_clients 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.
CVE-2026-70405[5]:
| 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. snmp_pdus:dec_integer_notag/1 defaults its
| size limit to infinity, and do_dec_integer_notag/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 dec_integer_notag/2 exists but is reached from only
| one call site, dec_snmp_version/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 dec_value/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.
CVE-2026-70409[6]:
| 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:parse_port/2 passes
| the port substring straight to list_to_integer/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:parse_ldap_url/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, from OTP 28.0 before
| OTP 28.5.0.6, and from OTP 29.0 before OTP 29.0.6, corresponding to
| eldap from 1.0.3 before 1.2.14.2, from 1.2.15 before 1.2.16.1, and
| from 1.3 before 1.3.1.
CVE-2026-71380[7]:
| 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.
| httpd_request_handler:handle_info/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.
| httpd_request:whole_body/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 minimum_bytes_per_second is configured, which it is
| not by default. Repeating this across connections occupies every
| worker permitted by max_clients and denies service to legitimate
| clients at negligible bandwidth cost. 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.
CVE-2026-73270[8]:
| Improper Handling of Case Sensitivity vulnerability in Erlang/OTP
| inets httpd allows a remote unauthenticated attacker to read files
| inside a mod_auth protected directory by requesting them with
| different casing, on deployments whose filesystem is case-
| insensitive. mod_auth:secret_path/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
| mod_get 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, 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.
CVE-2026-73276[9]:
| 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, from OTP 28.0 before
| OTP 28.5.0.6, and from OTP 29.0 before OTP 29.0.6, corresponding to
| inets from 7.1.2 before 9.3.2.7, from 9.4 before 9.6.2.3, and from
| 9.7 before 9.7.2.
CVE-2026-73812[10]:
| httpd function check_header/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. handle_body/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.
CVE-2026-74835[11]:
| 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, 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.
CVE-2026-74994[12]:
| The mod_auth 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, 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.
CVE-2026-75538[13]:
| 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, from OTP 28.0 before
| OTP 28.5.0.6, and from OTP 29.0 before OTP 29.0.6, corresponding to
| erts from 6.0 before 15.2.7.13, from 16.0 before 16.4.0.6, and from
| 17.0 before 17.0.6. Whether OTP before OTP 17.0, corresponding to
| erts before 6.0, is affected is unknown.
If you fix the vulnerabilities please also make sure to include the
CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.
For further information see:
[0] https://security-tracker.debian.org/tracker/CVE-2026-55951
https://www.cve.org/CVERecord?id=CVE-2026-55951
[1] https://security-tracker.debian.org/tracker/CVE-2026-59696
https://www.cve.org/CVERecord?id=CVE-2026-59696
[2] https://security-tracker.debian.org/tracker/CVE-2026-66835
https://www.cve.org/CVERecord?id=CVE-2026-66835
[3] https://security-tracker.debian.org/tracker/CVE-2026-69664
https://www.cve.org/CVERecord?id=CVE-2026-69664
[4] https://security-tracker.debian.org/tracker/CVE-2026-70399
https://www.cve.org/CVERecord?id=CVE-2026-70399
[5] https://security-tracker.debian.org/tracker/CVE-2026-70405
https://www.cve.org/CVERecord?id=CVE-2026-70405
[6] https://security-tracker.debian.org/tracker/CVE-2026-70409
https://www.cve.org/CVERecord?id=CVE-2026-70409
[7] https://security-tracker.debian.org/tracker/CVE-2026-71380
https://www.cve.org/CVERecord?id=CVE-2026-71380
[8] https://security-tracker.debian.org/tracker/CVE-2026-73270
https://www.cve.org/CVERecord?id=CVE-2026-73270
[9] https://security-tracker.debian.org/tracker/CVE-2026-73276
https://www.cve.org/CVERecord?id=CVE-2026-73276
[10] https://security-tracker.debian.org/tracker/CVE-2026-73812
https://www.cve.org/CVERecord?id=CVE-2026-73812
[11] https://security-tracker.debian.org/tracker/CVE-2026-74835
https://www.cve.org/CVERecord?id=CVE-2026-74835
[12] https://security-tracker.debian.org/tracker/CVE-2026-74994
https://www.cve.org/CVERecord?id=CVE-2026-74994
[13] https://security-tracker.debian.org/tracker/CVE-2026-75538
https://www.cve.org/CVERecord?id=CVE-2026-75538
Regards,
Salvatore