Peter Ullrich

XML injection occurs in the Saxy XML encoder because the `Saxy.Encoder.cdata/1` function serializes `{:cdata, characters}` nodes by wrapping characters between `<![CDATA[` and `]]>` without neutralizing the payload. While other paths escape XML metacharacters, the CDATA path does not handle the `]]>` substring, which is the only way to terminate a CDATA section. An attacker can provide untrusted text containing `]]>` to terminate the section prematurely, allowing subsequent input to be parsed as XML markup. This enables the injection of arbitrary sibling elements and attributes into the document structure. This issue impacts services generating SOAP envelopes, RSS, Atom feeds, sitemaps, SVG, or XML exports from user-supplied content. The vulnerability is triggered when using `Saxy.XML.cdata/1` in conjunction with `Saxy.encode!/2` or `Saxy.encode to iodata!/2`.

The XML encoder fails to validate or escape the target and content of processing instructions, writing them verbatim into the output document. Because the sequence `?>` terminates a processing instruction, an attacker can use this sequence to close the construct prematurely and inject arbitrary elements, attributes, and further processing instructions into the serialized document. This occurs because the encoder concatenates fields without checking them against XML specification constraints. The `Saxy.XML.processing instruction/2` function is a public builder that allows this flaw to be inherited. This can lead to XML injection, resulting in forged records, injected stylesheets, or active content when the output is processed by a downstream parser or browser. The issue is triggered when a `{:processing instruction, name, content}` node is passed to `Saxy.encode!/2` or `Saxy.encode to iodata!/2` using untrusted input.

An XML injection issue exists in the encoder of Saxy. The `Saxy.Encoder` fails to neutralize the `--` sequence within XML comment content because the `escape comment/2` function returns the comment binary unchanged in every clause and only appends a space if the comment ends in a single `-`. Consequently, neither an interior `--` nor a full `-->` is escaped or rejected before the encoder wraps the content in delimiters. When an application serializes attacker-controlled text as a comment via `Saxy.XML.comment/1` or a raw `{:comment, text}` simple form child, an attacker can prematurely close the comment using `-->` to inject arbitrary sibling markup into the serialized document. This allows for stored cross-site scripting when the document is rendered as HTML or SVG, or data forgery when consumed by another XML processor. This issue only affects applications that serialize untrusted text using `Saxy.encode!/2` or `Saxy.encode to iodata!/2`.

Improper validation of specified quantity in input within the Elixir standard library's `JSON` module allows an unauthenticated attacker to cause a denial of service through CPU and memory exhaustion by supplying a specially crafted JSON document. The functions `JSON.decode/1` and `JSON.decode!/1` use `erlang:binary to integer/1` to convert integer literals without bounding their length. Consequently, an integer literal with one million digits consumes 100 to 300 times more CPU than a string of the same length, and literals exceeding approximately 1.29 million digits trigger a `SystemLimitError`. Applications generated by `phx.new` are particularly susceptible as they decode request bodies using `Plug.Parsers` before routing and authentication occur.

An unauthenticated remote attacker can exhaust server memory by sending a request body composed of numerous 1-byte DATA frames. The issue occurs in the HTTP/2 request body reader where the `do read data/5` function in `lib/bandit/http2/stream.ex` stores every DATA frame payload as an individual list element until the read operation returns. Because the `:length` option of `read body/2` tracks the total number of bytes rather than the number of frames, a high volume of small frames creates significant memory overhead per byte. This effect is amplified when frames are interleaved across up to 500 concurrent streams per connection. This issue affects any route where the Plug reads the request body, including those using `Plug.Parsers` for POST, PUT, and PATCH requests.

An inefficient algorithmic complexity issue in the HTTP/2 implementation allows an unauthenticated remote attacker to exhaust server CPU resources. By opening thousands of streams that block on the connection send window and subsequently sending small SETTINGS or connection-level WINDOW UPDATE frames, an attacker can force the server to perform quadratic O(n²) list operations. This occurs because the `do pending sends/2` function in `lib/bandit/http2/connection.ex` retries every queued send and removes entries using `List.delete/2`, causing the server to walk the entire queue of blocked sends for each frame. The impact is amplified because `max concurrent streams` defaults to `:infinity`, allowing the attacker to control the number of blocked streams.

An inconsistent interpretation of HTTP requests, known as HTTP Request/Response Smuggling, exists in the HTTP/1.1 chunked body reader. This allows an unauthenticated remote attacker to smuggle a second request past a front-end proxy by using a chunk extension containing a bare LF (Line Feed). The issue occurs in the `lib/bandit/http1/socket.ex` file, where the chunked reader accepts the chunk-size line up to the first CRLF and discards content after the `;` character without validating it against the RFC 9112 `chunk-ext` grammar. Consequently, control bytes like bare LF and bare CR are permitted. If a front-end proxy treats a bare LF as a line ending, it may interpret the stream as a single request, while Bandit interprets it as a separate pipelined request, potentially bypassing proxy access controls. This issue only affects deployments using a front-end proxy that treats a bare LF as a line ending and forwards chunked bodies unchanged.

A timing side channel in the pure-Erlang Curve25519 fallback allows the recovery of a long-term X25519 private key. The implementation uses a recursive Montgomery ladder in the `jose jwa x25519:curve25519/2` function, where operations such as `jose jwa x25519:montgomery add/3` and `jose jwa x25519:montgomery double/1` rely on value-dependent Erlang bignum arithmetic. Consequently, the execution time of public entry points including `jose jwa x25519:scalarmult/2`, `jose jwa x25519:x25519/2`, `jose jwa x25519:x25519 base/1`, and `jose jwa x25519:sk to pk/1` varies based on the private key. This is exploitable when a service decrypts attacker-supplied ECDH-ES (JWE) messages via `JOSE.JWK.box decrypt ecdh es/2`, which calls `jose jwa curve25519:x25519 shared secret/2`. An attacker measuring decryption timing can recover the private key bit by bit, compromising data confidentiality and authenticity.

An improper handling of highly compressed data, known as data amplification, allows a remote attacker to exhaust a node's memory using a small crafted JWE token. The `jose jwe zip:uncompress/2` function in `src/jwe/jose jwe zip.erl` decompresses DEFLATE-compressed plaintext of a JWE containing the `zip: DEF` header by calling `zlib:inflate/2` on the attacker-controlled stream without bounds on output size or inflation ratio. This can cause a few-kilobyte token to inflate into hundreds of megabytes or gigabytes. Decompression occurs automatically during decryption via `jose jwe:block decrypt/2` (or `JOSE.JWE.block decrypt/2` in Elixir) before the payload is inspected. Using asymmetric key-management algorithms like RSA-OAEP or ECDH-ES, an attacker only needs the recipient's public key to craft the token, requiring no authentication. This can crash the BEAM and cause a denial of service.

The `jose jwa pkcs1` module contains a Bleichenbacher padding oracle in its pure-Erlang RSAES-PKCS1-v1 5 decryption. The function `eme pkcs1 decode/2` returns the recovered message for valid PKCS#1 v1.5 padding but returns a distinct error otherwise. Additionally, `rsaes pkcs1 decrypt/2` returns `{error, {badsize, }}` upon length check failure. The implementation lacks implicit-rejection countermeasures, failing to substitute a deterministic pseudo-random plaintext during padding failures, which leaks a padding-conformance signal. Furthermore, the use of non-blinded `crypto:mod pow/3` in the `dp/2` function allows the padding check to be distinguishable via timing attacks, even if error values are normalized. An unauthenticated attacker with the public RSA key can submit ciphertexts to a decryption endpoint that unwraps RSA1 5 JWE keys or calls `decrypt private/3` with `rsa pkcs1 padding` to recover plaintext, such as content-encryption keys, or forge signatures using adaptive chosen-ciphertext queries. This issue is only triggered when the `crypto fallback` option is enabled and the OTP runtime lacks native RSA1 5 decryption.

The `jose jwk:shared secret/2` function (exposed in Elixir as `JOSE.JWK.shared secret/2`) is used to derive an ECDH shared secret from two JSON Web Keys (JWKs). A flaw exists where the function only matches when both JWKs have the same key type (`kty`) module. If the key types differ, such as an EC key and an RSA key, the fallback clause re-invokes the function with identical arguments, creating an unbounded tail-recursive loop. This loop consumes 100% of an Erlang scheduler's CPU. An attacker providing a specially crafted JWK can trigger this behavior, and repeated requests can exhaust all available schedulers, leading to a denial of service.

An unauthenticated remote attacker can exhaust server memory by sending DATA frames that exceed the advertised receive window in the HTTP/2 implementation. The attacker can request a response larger than the 65,535-byte initial window and withhold `WINDOW UPDATE`, causing the stream process to block while sending and stop reading. Subsequently, flooding small DATA frames on that stream causes every frame to be queued in the stream's mailbox until the BEAM node runs out of memory. This occurs because `Bandit.HTTP2.Connection.handle frame/3` forwards DATA frames to the stream process without consulting the receive window, and `Bandit.HTTP2.FlowControl.compute recv window/2` replenishes the window as data arrives rather than as it is consumed, failing to trigger a `FLOW CONTROL ERROR` upon violation.

An unauthenticated remote attacker can hold stream processes open indefinitely in the HTTP/2 request body reader. This occurs because the `do read data/4` function in `lib/bandit/http2/stream.ex` resets the `read timeout` countdown whenever a WINDOW UPDATE or an empty SETTINGS frame is received. Since these frames do not deliver body data but still end the wait period, a client can send these 9-byte frames repeatedly to keep `read body` blocked. This allows the attacker to occupy the stream process and any resources held by the application during the read operation across multiple streams and connections.

An unauthenticated remote attacker can cause server memory exhaustion through a data amplification issue in the HTTP/2 implementation. By sending a small HPACK-compressed HEADERS block that stores a large `cookie` value in the HPACK dynamic table and references it tens of thousands of times, the attacker can force the server to allocate a massive binary. This occurs because `Bandit.HTTP2.Connection` only limits the compressed block size via `max header block size`, while the `max header list size` setting defaults to `:infinity`, failing to reject the expanded list. The function `combine cookie crumbs/1` in `lib/bandit/http2/stream.ex` then joins these references into a single large binary. Since `max concurrent streams` also defaults to `:infinity`, multiple concurrent streams can multiply this memory consumption, potentially crashing all applications on the BEAM node.

An unauthenticated remote attacker can cause unbounded growth of per-connection memory and CPU usage in the HTTP/2 implementation. This occurs because the software resizes its HPACK encoder table based on the `SETTINGS HEADER TABLE SIZE` advertised by the client without applying a server-side cap, allowing sizes up to 2^32-1 bytes. Since response headers with distinct values like `date` or `content-length` are indexed and not evicted, the table grows with every response. Consequently, the `lookup by header` function in the HPAX library scans the table linearly, resulting in O(N²) CPU cost for serving N responses on a single connection. The issue is located in the `Bandit.HTTP2.Connection` (`lib/bandit/http2/connection.ex`) where `remote settings.header table size` is passed to `HPAX.resize/2`, and the `encode headers` function encodes every response header as `:store`.

An issue in the WebSocket connection handling allows a remote client to continue executing handler code after the server has attempted to stop the connection. This occurs because when a callback returns `{:stop, ...}`, the `Bandit.WebSocket.Connection` process enters a `:closing` state but continues to process incoming data frames and messages. The functions `handle frame/3` and `handle info/3` do not verify the connection state, allowing frames to reach `handle in/2` and messages to reach `handle info/2` until the client sends a Close frame, the TCP connection drops, or an idle timeout occurs. This can lead to the bypass of authorization checks in `init/1` or the evasion of session terminations such as kicks or bans, potentially allowing unauthorized access to administrative actions.

An unauthenticated remote attacker can exhaust server memory and CPU resources by sending a request body composed of numerous 1-byte chunks. The issue exists in the HTTP/1.1 chunked body reader within `lib/bandit/http1/socket.ex`, which stores every chunk as an individual list cell and binary term until they are joined by the `IO.iodata to binary/1` function. Because the `:length` option of the `read body/2` function only counts data bytes and does not limit the total number of chunks, small chunks consume significantly more memory than their actual payload. This can occur even if the route does not explicitly read the body, as the `ensure completed/1` function drains unread bodies on keep-alive connections.

An improper cleanup process during thrown exceptions in the HTTP/2 handler allows an unauthenticated remote attacker to bypass per-connection resource limits. When a frame raises a `StreamError` during the processing of a TCP chunk, the `handle data/3` function in `Bandit.HTTP2.Handler` sends a RST STREAM and reverts the connection state to its condition before the chunk was processed. While streams opened by earlier frames in the chunk continue to execute their Plug calls, the internal bookkeeping—including stream counts, `last stream id`, rapid-reset timestamps, and the HPACK decoder state—is rolled back. Consequently, the `max concurrent streams`, `max requests`, and rapid-reset limiter fail to account for these active streams, allowing a client to exceed the configured concurrency limits and exhaust server CPU and memory resources.

An unauthenticated remote attacker can cause excessive server CPU consumption due to inefficient algorithmic complexity in the header integer parser. The function `Bandit.Headers.parse integer/2` in `lib/bandit/headers.ex` processes numbers one digit at a time without a limit on the digit count, allocating a new bignum at each step. This results in processing time that is quadratic relative to the length of the input. The issue is triggered by providing a `content-length` value or a `Host` or `:authority` port consisting of thousands of digits. This occurs on raw request input over HTTP/1 and HTTP/2 before any range checks are performed. In HTTP/2 environments, an attacker can use HPACK dynamic table storage to amplify the effect, sending a large value once and referencing it in subsequent streams to keep the server busy with minimal traffic.

An unauthenticated remote attacker can exhaust server memory through the WebSocket fragment reassembly process. The `Bandit.WebSocket.Connection` function checks the `max fragmented message size` variable against the received payload bytes but does not limit the total number of fragments. By sending a fragmented message consisting of numerous 1-byte continuation frames, an attacker can consume significantly more memory than the configured limit. For instance, a 1-byte fragment requires approximately 150 to 170 bytes of server memory. Additionally, sending Ping frames between fragments allows the connection to remain active beyond the idle timeout.