Eric Meadows-Jönsson

9 exploits Active since Feb 2026
CVE-2026-48861 WRITEUP LOW WRITEUP
CRLF injection in HTTP/1 request line via unvalidated method in Mint
Improper Neutralization of CRLF Sequences ('CRLF Injection') vulnerability in elixir-mint Mint allows HTTP Request Splitting and HTTP Request Smuggling. In lib/mint/http1/request.ex, the encode_request_line/2 function splices the caller-supplied method and target arguments directly into the HTTP/1 request line without any character validation: [method, ?\s, target, " HTTP/1.1\r\n"]. An application that forwards attacker-controlled input as the HTTP method or target to Mint.HTTP.request/5 is therefore exposed to request-line CRLF injection: the attacker can terminate the request line early, inject arbitrary headers, and smuggle an entirely separate pipelined HTTP request onto the same TCP connection. Mint 1.7.0 introduced validate_request_target/2, which rejects CRLF and other control characters in the target by default and closes the path/query vector unless the caller opts out via skip_target_validation: true. The method field remains unvalidated, so the method-based injection is exploitable under the default Mint configuration on all versions. This issue affects mint: from 0.1.0 before 1.9.0.
CVE-2026-48862 WRITEUP HIGH WRITEUP
Unbounded conn.streams growth in Mint HTTP/2 client via unenforced PUSH_PROMISE concurrency
Allocation of Resources Without Limits or Throttling vulnerability in elixir-mint Mint allows attacker-controlled HTTP/2 servers to exhaust memory in a Mint client via PUSH_PROMISE flooding. In lib/mint/http2.ex, Mint.HTTP2.decode_push_promise_headers_and_add_response/5 inserts a :reserved_remote entry into conn.streams for every promised stream ID. The neighbouring Mint.HTTP2.assert_valid_promised_stream_id/2 only verifies that the promised ID is even and not already present; client_settings.max_concurrent_streams is not consulted at promise time. The concurrency cap is only checked when the response HEADERS for the promised stream arrive, so a server that emits PUSH_PROMISE frames and withholds the matching HEADERS never trips that check. HTTP/2 server push is accepted by default (client_settings.enable_push defaults to true). A single long-lived HTTP/2 connection to a hostile server lets that server pin one conn.streams entry per PUSH_PROMISE frame it sends, with no upper bound, until the client process runs out of memory. This issue affects mint: from 0.2.0 before 1.9.0.
CVE-2026-49753 WRITEUP MEDIUM WRITEUP
HTTP response smuggling in Mint HTTP/1 client via lenient Content-Length parsing
Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') vulnerability in elixir-mint Mint allows attacker-controlled HTTP/1 servers to desynchronise response framing on shared connections. Mint's HTTP/1 Content-Length parser, Mint.HTTP1.Parse.content_length_header/1 in lib/mint/http1/parse.ex, parses the header value with Integer.parse/1, which accepts an optional + or - sign prefix. The length >= 0 guard rejects negatives, but inputs such as +0 or +123 are returned as valid lengths. RFC 7230 specifies Content-Length = 1*DIGIT, with no sign character permitted. A fronting proxy or load balancer that strictly enforces the grammar will reject or reframe a header like Content-Length: +0, while Mint silently treats it as zero. When Mint reuses the socket (keep-alive, pipelining, or any pooled connection shared across requesters), the parser disagreement is a response-smuggling primitive: the proxy delimits the body one way, Mint another, and bytes from one response get attributed to the next. Where the same Mint connection is shared across trust boundaries, an attacker-controlled upstream can leak bytes into a different consumer's response stream. This issue affects mint: from 0.1.0 before 1.9.0.
CVE-2026-49754 WRITEUP HIGH WRITEUP
HTTP/2 CONTINUATION flood in Mint client via unbounded header-block accumulation
Allocation of Resources Without Limits or Throttling vulnerability in elixir-mint Mint allows attacker-controlled HTTP/2 servers to exhaust memory in a Mint client (HTTP/2 CONTINUATION flood). When Mint's HTTP/2 receive path observes a HEADERS frame without the END_HEADERS flag, the unparsed header-block fragment is parked in conn.headers_being_processed, and every subsequent CONTINUATION frame on that stream is appended to the accumulator. Nothing in the receive path caps the accumulator: there is no per-stream size limit, no CONTINUATION frame-count limit, and max_header_list_size is only enforced on outgoing requests, never on inbound header blocks (its default is :infinity). A malicious or compromised HTTP/2 server can stream an endless sequence of CONTINUATION frames (each up to the peer-advertised SETTINGS_MAX_FRAME_SIZE) and drive the client's iolist to arbitrary size, causing memory exhaustion and BEAM process death. A single connection to an attacker-controlled HTTP/2 endpoint is sufficient. This issue affects mint: from 0.1.0 before 1.9.0.
CVE-2026-32686 WRITEUP MEDIUM WRITEUP
Unbounded exponent in decimal enables unauthenticated DoS
Uncontrolled Resource Consumption vulnerability in ericmj decimal allows unauthenticated remote Denial of Service. The decimal library does not bound the exponent on parsed input. Storing a decimal with a very large exponent (e.g. Decimal.new("1e1000000000")) is accepted without error. Subsequent calls to arithmetic functions (Decimal.add/2, Decimal.sub/2, Decimal.div/2), Decimal.to_string/2 with :normal or :xsd format, Decimal.to_integer/1, Decimal.round/3, or Decimal.compare/3 with a threshold allocate memory proportional to the exponent value, which can exhaust available memory and crash the BEAM VM. Any application that accepts user-supplied decimal input and subsequently performs arithmetic, rounding, conversion to integer, or string formatting on it is exposed. A single malicious request is sufficient to cause an out-of-memory crash. This issue affects decimal: from 0.1.0 before 3.0.0.
CVE-2026-32148 WRITEUP MEDIUM WRITEUP
Lockfile checksums not verified in Hex allows dependency integrity bypass
Insufficient Verification of Data Authenticity vulnerability in hexpm hex (Hex.RemoteConverger module) allows dependency integrity bypass via unverified lockfile checksums. Hex stores checksums for dependencies in the mix.lock file to ensure reproducible and integrity-checked builds. However, Hex.RemoteConverger.verify_resolved/2 never executes checksum verification because the lock data returned by Hex.Utils.lock/1 uses string-based dependency names, while the verification logic compares against atom-based names. This type mismatch causes the verification code path to be silently skipped. Checksums are still validated when packages are initially downloaded from the registry, but mismatches between the lockfile and resolved dependencies are not detected. An attacker who can influence cached packages (e.g., via local cache poisoning or a compromised registry) can provide modified dependency contents that will be accepted without detection. The mix.lock file is silently rewritten with the checksum values from the registry, erasing evidence of tampering. This issue affects hex: from 0.16.0 before 2.4.2.
CVSS 5.9
CVE-2026-23940 WRITEUP MEDIUM WRITEUP
hexpm < 495f01607d3eae4aed7ad09b2f54f31ec7a7df01 - Denial of Service via Oversized Package Upload
Uncontrolled Resource Consumption vulnerability in hexpm hexpm/hexpm allows Excessive Allocation. Publishing an oversized package can cause Hex.pm to run out of memory while extracting the uploaded package tarball. This can terminate the affected application instance and result in a denial of service for package publishing and potentially other package-processing functionality. This issue affects hexpm: before 495f01607d3eae4aed7ad09b2f54f31ec7a7df01; hex.pm: before 2026-03-10.
CVSS 6.5
CVE-2026-21621 WRITEUP MEDIUM WRITEUP
hexpm hexpm/hexpm - Privilege Escalation
Incorrect Authorization vulnerability in hexpm hexpm/hexpm ('Elixir.HexpmWeb.API.OAuthController' module) allows Privilege Escalation. An API key created with read-only permissions (domain: "api", resource: "read") can be escalated to full write access under specific conditions. When exchanging a read-only API key via the OAuth client_credentials grant, the resource qualifier is ignored. The resulting JWT receives the broad "api" scope instead of the expected "api:read" scope. This token is therefore treated as having full API access. If an attacker is able to obtain a victim's read-only API key and a valid 2FA (TOTP) code for the victim account, they can use the incorrectly scoped JWT to create a new full-access API key with unrestricted API permissions that does not expire by default and can perform write operations such as publishing, retiring, or modifying packages. This vulnerability is associated with program files lib/hexpm_web/controllers/api/oauth_controller.ex and program routines 'Elixir.HexpmWeb.API.OAuthController':validate_scopes_against_key/2. This issue affects hexpm: from 71829cb6f6559bcceb1ef4e43a2fb8cdd3af654b before 71c127afebb7ed7cc637eb231b98feb802d62999.
CVSS 5.3
CVE-2026-21619 WRITEUP HIGH WRITEUP
hex_core < 0.12.1, hex < 2.3.2, rebar3 < 3.27.0 - Resource Consumption & Untrusted Data Deserialization
Uncontrolled Resource Consumption, Deserialization of Untrusted Data vulnerability in hexpm hex_core (hex_api modules), hexpm hex (mix_hex_api modules), erlang rebar3 (r3_hex_api modules) allows Object Injection, Excessive Allocation. This vulnerability is associated with program files src/hex_api.erl, src/mix_hex_api.erl, apps/rebar/src/vendored/r3_hex_api.erl and program routines hex_core:request/4, mix_hex_api:request/4, r3_hex_api:request/4. This issue affects hex_core: from 0.1.0 before 0.12.1; hex: from 2.3.0 before 2.3.2; rebar3: from 3.9.1 before 3.27.0.
CVSS 7.5