Yordis Prieto

An allocation of resources without limits or throttling allows a denial of service via unbounded atom creation from attacker-influenced binary input. The `Guardian.Plug.Keys` module derives connection and session namespace keys by passing arbitrary binaries to the `String.to atom/1` function. Specifically, the `base key/1` function in `lib/guardian/plug/keys.ex` converts binaries into atoms, and the helpers `claims key/1`, `resource key/1`, and `token key/1` create additional atoms. Similarly, `key from other/1` converts regex-captured binaries through `String.to atom/1`. High-level entry points, such as `Guardian.Plug.current token(conn, key: key)`, pass caller-supplied keys directly into these functions. Because `String.to atom/1` creates a new atom for every unseen binary and atoms are not garbage collected, the BEAM atom table (which has a default limit of approximately 1,048,576 entries) can be exhausted. If an application routes untrusted data, such as a tenant identifier or request header, into a Guardian key via the `key` parameter, an attacker can send a stream of varied input to consume the atom table and crash the BEAM node, affecting all applications running on it.

An allocation of resources without limits or throttling allows a denial of service via unbounded atom creation from attacker-controlled binary input. The `Guardian.Permissions.AtomEncoding` encoder processes permission scopes by passing arbitrary binaries to the `String.to atom/1` function. When the `encode/3` function in `lib/guardian/permissions/atom encoding.ex` is called with a list, the `encode value/3` binary clause calls `String.to atom(value)` without an allow-list check, discarding the `perm set` argument. Because `String.to atom/1` creates a new atom for every unseen binary and atoms are not garbage collected, the BEAM atom table (limited to approximately 1,048,576 entries) can be exhausted. An attacker providing varied input through request bodies or JWT claims can trigger a `system limit` crash of the BEAM node, affecting all applications running on it.

An allocation of resources without limits or throttling in the `Guardian.Permissions` module allows a denial of service via BEAM atom-table exhaustion. The `Guardian.Permissions` mixin installs a public `encode permissions!/1` function that calls `String.to atom(to string(k))` for each key of a supplied map before validation. In the `do encode permissions!/2` function, the integer-value clause bypasses validation against the configured permission set, allowing keys with integer values to be interned as new atoms. Since atoms are not garbage collected and the BEAM atom table has a fixed size, an attacker who can influence a permission map passed to `encode permissions!/1` or `encode permissions into claims!/2` can exhaust the table, crashing the BEAM node and all running services. This issue is associated with the file `lib/guardian/permissions.ex` and the functions `encode permissions!/1`, `encode permissions into claims!/2`, and `do encode permissions!/2`.

Improper verification of cryptographic signatures allows an unauthenticated attacker to revoke a victim's session using a forged token. The `Guardian.revoke/3` function in `lib/guardian.ex` uses `peek/1` to decode tokens, which only performs base64-decoding of the JWT header and payload without verifying the signature. These unverified claims are then passed to the token module's revoke callback and the `on revoke` callback, which can mutate state. An attacker who knows or guesses identifying claim values such as `jti` or `sub` can forge a JWT and submit it to endpoints that use `Guardian.revoke/3`, leading to a denial of service where the victim's legitimate session is evicted. This occurs when the token module mutates state based on these claims, such as in whitelist deletions or blacklist insertions.

An improper handling of highly compressed data allows a denial of service via a decompression bomb in HTTP response bodies. When `Tesla.Middleware.DecompressResponse` or `Tesla.Middleware.Compression` is used in a middleware pipeline, response bodies are decompressed eagerly without a size limit. The `decompress body/2` function passes the entire response body to `:zlib.gunzip/1` or `:zlib.unzip/1` without capping the output size. Furthermore, the `compression algorithms/1` function splits the `content-encoding` header by commas, and `decompress body/2` recurses for each token. A server providing a `content-encoding` header with multiple gzip tokens can trigger recursive decompression passes, causing exponential data amplification where a small network payload expands into gigabytes of BEAM heap (the memory area used by the Erlang virtual machine), leading to memory exhaustion and crashing or freezing the calling process.

Improper encoding or escaping of output allows multipart part header injection through unescaped `Content-Disposition` parameter values. The function `part headers for disposition()` interpolates disposition parameters without validating carriage return (`r`), line feed (` `), or double-quote characters. These values are received from the caller via `add field()` (the `name` parameter), `add file()` (the `filename` parameter), and `add file content()` (the `filename` parameter and other disposition options). A double-quote character can close a quoted parameter prematurely, while `r ` sequences can terminate the `Content-Disposition` header to start a new forged header or end the header block to prepend bytes to the part body. Additionally, the default filename path in `add file()` uses `Path.basename()`, which does not strip carriage returns or line feeds.

Improper handling of case sensitivity in `Tesla.Middleware.FollowRedirects` allows credential leakage to third-party origins during cross-origin redirects. The middleware attempts to strip security-sensitive headers by comparing them against a lowercase filter list containing `authorization` and `host`. However, because Tesla preserves header keys exactly as provided by the caller without normalization, headers using canonical casing, such as `Authorization`, do not match the lowercase filter and are forwarded to the redirect destination. An attacker who can control the `Location:` response—via their own endpoint, a redirect-open upstream, or a compromised origin—can capture bearer tokens or other authorization materials. This occurs when the application uses `Tesla.Middleware.FollowRedirects` and sets headers with non-lowercase keys.

Improper neutralization of CRLF (Carriage Return and Line Feed) sequences in HTTP headers allows for HTTP header injection. The function `Tesla.Multipart.add content type param/2` appends caller-supplied strings to the multipart `content type params` list without validating for `r` or ` ` characters. Subsequently, the `Tesla.Multipart.headers/1` function joins these parameters verbatim to construct the outgoing Content-Type header. An attacker providing a parameter containing `r ` can split the header line, enabling the injection of arbitrary headers into the outbound HTTP request. This issue affects applications that forward untrusted input, such as user-supplied charset or parameter strings, into the `Tesla.Multipart.add content type param/2` function. This can lead to forging outbound request headers or potential request smuggling against the upstream server.

An issue in Tesla.Adapter.Mint allows for a denial of service via atom table exhaustion. The function `open conn/2` converts the URL scheme of outgoing requests into a BEAM atom using `String.to atom(uri.scheme)` without allow-list validation. BEAM atoms are permanent entries that are not garbage-collected and are limited to a bounded table of approximately 1,048,576 entries. An attacker capable of influencing the request URL—through application-level URL-forwarding features like webhooks, proxies, or importers, or via a Location header when `Tesla.Middleware.FollowRedirects` is active—can create a new atom for each request by varying the scheme string. Once the atom table is full, the virtual machine crashes, resulting in a complete application shutdown.