Elixir
Monthly
Unauthenticated remote CPU exhaustion in mtrudel Bandit's HTTP/2 server (versions before 1.14.0) is achievable by holding thousands of response streams blocked on the connection send window and then sending tiny SETTINGS or stream-0 WINDOW_UPDATE frames. Each such frame makes the server retry every blocked send via do_pending_sends/2, producing O(n²) list operations; the advisory's verified PoC measured 133 ms for a single 9-byte SETTINGS frame with 3,000 blocked streams. The issue is remotely exploitable without authentication or user interaction and is prioritized this_week; the supplied data does not confirm active exploitation, and a public proof-of-concept is included in the advisory.
Unbounded per-connection memory and CPU growth in the Elixir Bandit HTTP/2 server (0.3.6 up to 1.14.0) lets an unauthenticated remote client advertise a SETTINGS_HEADER_TABLE_SIZE of up to 2^32-1, which Bandit applies to its HPACK encoder table with no server-side cap; every response header is then stored into that oversized table and never evicted, so the encoding cost of each response grows linearly and the connection's total cost grows quadratically. No authentication or user interaction is required (PR:N/UI:N), the effect is purely availability (C:N/I:N/A:H, scored 8.7 under CVSS 4.0 and assessed as AV:N/AC:L/PR:N/UI:N/A:H under CVSS 3.1), and it only bites while a connection is kept alive and busy with cheap requests to endpoints whose response headers vary per request. It is not confirmed actively exploited (CISA KEV), but the vendor advisory documents a public proof-of-concept procedure; treat it as a this-week priority rather than an emergency, since capping requests per connection or upgrading to 1.14.0 removes the growth.
HTTP/2 resource-limit bypass in the Elixir Bandit web server (1.9.0 through 1.13.x) lets an unauthenticated remote client exceed the configured max_concurrent_streams and max_requests caps by packing multiple HEADERS frames into a single TCP write where one frame raises a StreamError, causing the handler to continue from pre-chunk connection state. Because stream counts, last_stream_id, rapid-reset timestamps and the HPACK decoder state are all rolled back while the already-started Plug calls keep running, an attacker can drive roughly five times the intended number of concurrent Plug invocations per connection (50 running against a limit of 10 in the reporter's test), exhausting server processes, CPU and memory. Impact is strictly availability - no confidentiality or integrity loss - HTTP/2 with a finite max_concurrent_streams is the default for Bandit's TLS/h2 listeners, no public exploit code is confirmed, and a vendor patch is available.
Unauthenticated remote denial of service in the Elixir HTTP server Bandit (mtrudel/bandit) from 0.1.0 before 1.14.0 lets a single remote attacker exhaust server memory and CPU with one HTTP/1.1 request whose chunked body is composed of a very large number of 1-byte chunks. Because the chunked reader keeps every chunk as its own cons cell and binary term until IO.iodata_to_binary/1 joins them, and the :length option of read_body/2 counts only data bytes, the vendor's reproduction shows 48 MB of 1-byte chunks growing one handler process to roughly 500 MB and consuming about 6 seconds of CPU - a ~48x amplification over the payload sent - and the amplification also occurs against routes that never call read_body, since ensure_completed/1 drains unread bodies on keep-alive connections. HTTP/1.1 is enabled by default, so any default deployment is exposed without authentication or user interaction; the vendor shipped a fix in 1.14.0, there are no reports of exploitation in CISA KEV and no independently confirmed public exploit code, though the advisory does publish detailed reproduction steps.
Unauthenticated remote attackers can consume disproportionate server CPU on Bandit (mtrudel/bandit, Elixir/Erlang) by sending a Content-Length value or a Host/:authority port composed of thousands of digits, which the header integer parser processes in quadratic time before any range check. Over HTTP/2 the cost is amplified because a 4,000-digit value can be stored once in the HPACK dynamic table and replayed cheaply across thousands of new streams; the advisory's proof-of-concept sent roughly 124 KB that kept the server busy for 27.9 seconds. Both HTTP/1 and HTTP/2 deployments are affected at default configuration, versions 1.0.0-pre.7 up to but not including 1.14.0. The advisory includes a public PoC reference that is not independently verified as working exploit code; there is no CISA KEV listing or other indication of active exploitation, and the vendor has released 1.14.0 as the fix.
Cross-tenant record takeover in the Ash framework (Elixir) for versions 1.22.0 up to 3.37.2: when a resource uses attribute multitenancy and exposes a create action with upsert? true that accepts the primary key (or upserts on an all_tenants? identity), an authenticated user of one tenant can supply another tenant's record ID and have that record updated, its full attribute set returned, and - with default upsert fields - its tenant attribute rewritten, moving the record into the attacker's tenant. Read and update policies do not run on the upsert path, and tenant-scoped create policies pass because the tenant on the request is the caller's own, so the only meaningful preconditions are that such an action is exposed and that the attacker knows or can enumerate a foreign key (for example a serial integer ID or an ID leaked through a shared link or export). The vendor has released a fix in ash 3.37.2; no public exploit code was identified at time of analysis, and the priority signal is to patch this week rather than an emergency response.
Hex, the package manager used by Elixir and Erlang projects, fails to properly scope its 'release-age cooldown' protection in versions 2.5.0 through 2.5.1, allowing an authenticated package owner to slip a freshly published, malicious release past the cooldown. The attacker must already hold package-owner permission on the target package, retire (or rely on a security advisory for) the release locked in the victim's mix.lock, and then wait for the victim to run mix deps.update - at which point Hex.RemoteConverger.build_cooldown_bypass/3 and unsafe_lock_bypass/1 lift the cooldown for every version of that package and its dependencies, so the new release is selected regardless of age. A secondary scoping defect causes the bypass to be keyed on package name alone, extending it to identically named packages in other repositories; cooldown configured through an organization dependency policy is not affected. This is a conditional supply-chain weakness rather than a broadly dangerous remote flaw, and no public exploit or in-the-wild activity has been identified at time of analysis. Patches are available from the vendor in Hex 2.5.2.
Memory-exhaustion denial of service in the elixir-protobuf library (protobuf) from 0.8.0 onward allows an unauthenticated remote attacker to crash an Elixir decoding process by supplying a deeply nested JSON document through Protobuf.JSON.decode/3, decode!/3, or from_decoded/3 when the target schema contains a self-referential or cyclic message type. Because the embedded-message clause of decode_singular/3 recurses once per nesting level without touching the decoder's depth counter, the recursion_limit option offers no protection and each level consumes a stack frame plus heap objects until the process runs out of memory; confidentiality and integrity are unaffected, only availability. Exploitation is unauthenticated and requires no user interaction, but is limited to applications that decode untrusted JSON into recursive message definitions, and no public exploit code has been identified at time of analysis (EPSS data not provided).
Ciphertext tampering in the Cloak Elixir encryption library (danielberkompas/cloak, all versions from 0.1.0-pre onward) lets anyone with write access to the encrypted store silently flip bits in stored ciphertext so that decryption returns an attacker-chosen plaintext of the same length. The affected code paths, Cloak.Ciphers.AES.CTR and Cloak.Ciphers.Deprecated.AES.CTR, encrypt with AES-256 in CTR mode and store the key tag, IV, and ciphertext with no MAC, and decrypt/2 validates only the key tag and a minimum length - so tampered data is returned as valid with no error. Exploitation requires write access to the ciphertext (the description cites SQL injection into the Ecto-backed database or a compromised replica) plus knowledge or a correct guess of the existing plaintext at the tampered offset, and the replacement value must be exactly the same length as the original; impact is integrity-only (VC:N/VA:N), with no public exploit identified at time of analysis. Note the vendor CVSS 4.0 score of 8.2 is driven entirely by VI:H, while an independent assessment applying CVSS 3.1 (AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N) rates the realistic risk considerably lower because an attacker must already control writes to the encrypted store and have plaintext knowledge.
Atom table exhaustion in the Ash framework (Elixir) allows an unauthenticated remote attacker to crash a BEAM node by supplying filter values for a publicly filterable :atom-typed attribute that is declared with the unsafe_to_atom?: true constraint. Each distinct attacker-controlled string is interned with String.to_atom/1; atoms are never garbage collected and the VM's atom table is fixed in size, so a flood of distinct values exhausts the table and terminates the node. The condition is version- and configuration-dependent: ash from 3.5.1 before 3.34.3 is affected, unsafe_to_atom?: true is not the default, and the vulnerable path is only reachable through a filter interface the attacker can query - AshPaperTrail meets that bar out of the box because its version resources expose a public, filterable version_action_name atom attribute with unsafe_to_atom?: true. A vendor patch is available in 3.34.3 and no public exploit code was identified at time of analysis.
Memory exhaustion denial-of-service in Elixir Mint affects versions 1.1.0 through 1.10.x and allows a malicious or compromised HTTP/2 server to force a client application to allocate roughly 1 GB per response by abusing HPACK indexed header fields and cookie handling, potentially exhausting the BEAM VM. The vulnerability requires the application to initiate an outbound HTTP/2 connection to an attacker-influenced endpoint (reverse-trust), and no public exploit code or confirmed active exploitation is identified at time of analysis. Downstream clients such as Finch and Req that use Mint are also affected when making outbound HTTP/2 requests to untrusted servers.
Improper JWT signature verification in Dashbit's nimble_zta (0.1.2 up to but not including 0.1.3) lets an unauthenticated remote attacker bypass authentication and impersonate an arbitrary Cloudflare service token in applications using the Cloudflare Zero Trust service-token strategy. Because verify_token/2 pattern-matches the {_, token, _s} tuple returned by JOSE.JWT.verify/2, the boolean signature-verification result is discarded and a forged JWT sent in the cf-access-jwt-assertion header is accepted as authenticated identity; the attacker only needs the expected iss claim plus the seven service-token claims (aud, common_name, exp, iat, iss, sub, type). No public exploit code has been identified at time of analysis, but the flaw is remotely reachable with no authentication or user interaction (assessed CVSS 3.1 base 9.3, scope changed) and is fixed in nimble_zta 0.1.3.
Session fixation in the Elixir/Phoenix authentication library ash_authentication (0.2.0 before 4.15.0, and 5.0.0-rc.0 before 5.0.0-rc.14) allows an attacker who has pre-planted a session identifier in a victim's browser to ride that identifier into the victim's authenticated session. AshAuthentication.Plug.Helpers.store_in_session/2 writes the authenticated subject into the existing session with Plug.Conn.put_session/3 and never calls Plug.Conn.configure_session(renew: true), so the identifier the visitor arrived with survives into their logged-in session through every authentication path, including the default success/4, the mix ash_authentication_phoenix.install AuthController, and remember-me auto-login; logout does not close the window because clear_session/2 ends with Plug.Conn.clear_session/1, which wipes contents but leaves the identifier intact, so a planted identifier survives a logout-then-login cycle. Exploitation is conditional rather than universal: it requires a server-side session store where a rotatable identifier exists (deployments on Phoenix's default signed-cookie session store are largely unaffected, as there is no identifier to fixate), a means of planting the session cookie in the victim's browser, and victim interaction to sign in. No public exploit was identified at time of analysis, although the upstream fix commits and their accompanying regression tests are public.
Session-swapping authentication bypass in the Elixir library AshAuthentication (versions 4.10.0 before 4.15.0 and 5.0.0-rc.0 before 5.0.0-rc.14) allows an attacker who can plant a remember-me cookie in a victim's browser to displace the victim's live authenticated session with one belonging to the attacker's own account, so anything the victim enters afterwards is captured under attacker-controlled state. The root cause is a guard/reader key mismatch: AshAuthentication.Plug.Helpers.sign_in_using_remember_me/3 checks the session for a '<subject_name>_token' key, but store_in_session/2 only writes that key when require_token_presence_for_authentication? is enabled and otherwise writes the bare subject name, leaving the already-signed-in short-circuit unreachable and the remember-me sign-in running on every request through the per-request browser pipeline plug. No public exploit code or confirmed active exploitation was identified at time of analysis, but exploitation is constrained by prerequisites - the attacker needs a remember-me token for their own account, a cookie-injection channel (shared/parent-domain cookie write, XSS, or on-path position), and subsequent victim interaction - which independent assessment reflects with CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N; vendor fixes are available in 4.15.0 and 5.0.0-rc.14.
Authentication bypass in the Elixir library ash_authentication lets an attacker who operates one federated identity-provider connection of a `dynamic_oidc` strategy be signed in as a local user whose identity row was created through a different IdP connection, because the intended per-connection namespacing of the `strategy` field never persists. Affected are versions 5.0.0-rc.10 through 5.0.0-rc.13 (fixed in 5.0.0-rc.14); the assessed vector is CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N, so the flaw is network-reachable and unauthenticated in the token-presentation sense, but real-world exploitation is tightly gated: the deployment must use `dynamic_oidc` with more than one identity-provider connection, the attacker must control (or have a trusted operator position on) one of those connections, and must be able to mint tokens with a chosen `sub` claim that collides with a target subject. No public exploit code was identified at time of analysis, and this CVE is not listed in CISA KEV; patch commits are already public, so the exposure window for unpatched, multi-connection deployments is the operational concern.
Account takeover in AshAuthentication (Elixir/Ash) 4.14.0 through 4.14.x and 5.0.0-rc.10 through 5.0.0-rc.13 lets unauthenticated remote attackers obtain a session for another user's account by linking their own OAuth2 provider identity to an account that was matched on an attribute other than email, and the same upsert rewrites the victim's email to the attacker's address so subsequent account recovery flows reach the attacker. Exploitation is conditional: the application must configure the OAuth2/Auth0/Apple strategy with a register-action upsert_identity that matches existing accounts on a non-email attribute, or use the registration_enabled? false sign-in path where accounts are matched by the sign-in action's read filter, and the attacker only needs control of a provider identity whose email_verified claim is true. No public exploit code has been identified at time of analysis and the issue is not confirmed as actively exploited (CISA KEV); vendor patches are available in 4.15.0 and 5.0.0-rc.14.
Password sign-in in AshAuthentication Phoenix (ash_authentication_phoenix 1.7.0 to <2.17.4 and 3.0.0-rc.0 to <3.0.0-rc.11, with the companion ash_authentication 3.10.5 to <4.15.0 and 5.0.0-rc.0 to <5.0.0-rc.14) places a freshly issued single-use sign-in token in the query string of a GET redirect to the sign_in_with_token route, so the live credential is written into the request line where it is retained by web server access logs, reverse-proxy logs, request telemetry and the victim's browser history. Anyone who can read those artifacts - and can replay the token before the legitimate redirect consumes it or it expires - can authenticate as the affected user. The exposure is only reachable when sign_in_tokens_enabled? is true and the password sign-in form is in use; the vendor rates it CVSS 4.0 7.2 (AV:L/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H) and our independent assessment aligns at CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N, indicating no public exploit identified at time of analysis rather than remotely exploitable default-configuration compromise.
Authentication bypass in the AshAuthentication library for Elixir/Ash lets an authenticated attacker who holds a valid sign-in token minted for one Ash resource replay it to be signed in as a user of a different resource, because the JWT 'sub' claim's path segment - the only portion recording which subject the token was issued for - is parsed with URI.parse/1 and thrown away, leaving only the query string. Affected are ash_authentication releases from 3.10.5 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.14, specifically the Password sign-in-with-token, WebAuthn sign-in and remember-me preparations; the magic-link sign-in path pins the subject against the resource and is not vulnerable. Exploitation is configuration-dependent - it requires two or more authenticated resources whose primary-key field names are identical (for example, both 'id') - and no public exploit code was identified at time of analysis.
An authenticated account-takeover primitive exists in the Elixir library AshAuthentication (ash_authentication) versions 0.5.0 through 4.14.x and 5.0.0-rc.0 through 5.0.0-rc.13: an attacker who can register their own account can replay the confirmation token generated for their own email change against a victim's record, causing the victim's address to be overwritten with the attacker's and confirmed_at to be stamped, after which a routine password reset hands over the account. Exploitation requires the application to use the Confirmation add-on with monitored fields (typically :email), the attacker's own registered account (authenticated, PR:L), and knowledge of the victim's record id (normally a UUID primary key); no action by the victim is required. The confirmation flow the library itself generates is not affected, and no public exploit code has been identified at time of analysis.
Server-Side Request Forgery protection bypass in the Elixir safeurl library (versions 0.1.0 and later) allows unauthenticated attackers who can influence a URL passed to SafeURL.get/validate_url to reach internal or reserved network destinations that the library is configured to block. The root cause is IPv4-only blocklist matching: a destination rejected as an IPv4 address is accepted when expressed as an IPv6 literal, IPv6 entries in the blocklist never match, and a hostname that resolves to no IPv4 address is accepted regardless of where it actually points; deployments using the library's allowlist (whitelist) option are not affected because unmatched addresses are rejected there. Exploitation requires an application running safeurl in its default blacklist/blocklist mode with attacker-influenced URLs; there is no public exploit identified at time of analysis, CISA KEV does not list this CVE, and EPSS is low at 0.46% (39th percentile), so urgency is driven by the defensive nature of the component rather than observed attack activity. CVSS is rated 9.0 by the CNA, with an independent assessment of CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:L/A:N reflecting high confidentiality impact, low integrity impact, and changed scope.
Unbounded recursion in the Elixir `protobuf` Hex package (versions >= 0.8.0, < 0.16.1) lets unauthenticated remote attackers take down any service that decodes untrusted protobuf bytes into a self-referential or cyclic message type, because each nested embedded message is decoded with a non-tail recursive call that retains a live stack and heap frame on the BEAM. A body of only a few KB to a few MB can nest an embedded field hundreds of thousands to millions of levels deep, consuming hundreds of MB of memory and seconds of CPU per request and pinning a scheduler, so a handful of concurrent requests can starve and crash the node. Publicly available exploit code exists, and the vendor has released a patch in 0.16.1 that enforces a configurable `:max_nesting_depth` defaulting to 100, matching Google's C++/Java reference implementations; exploitation is conditional on the target schema actually being recursive (reflected as CVSS 4.0 AT:P), so services decoding only flat message types are not affected despite the 8.2 base score.
Bandit, the pure-Elixir HTTP/WebSocket server, keeps running a WebSock application's handler code after the server has initiated a close, so a remote client that ignores the Close frame can still reach handle_in/2 and handle_info/2 with the state from the {:stop, ...} tuple. Versions 0.5.1 through 1.14.0 are affected (fixed in 1.14.0), and the practical impact lands on WebSock applications that use {:stop, ...} to enforce authorization - a client refused in init/1 after a failed token check, or a kicked/banned user (including Phoenix's :socket_drain path), can keep invoking sensitive actions until it sends Close, TCP drops, or the idle timeout fires, and each client frame resets that timeout. The vendor advisory includes a step-by-step proof-of-concept walkthrough; a public PoC reference exists, but it is not verified as working exploit code, and there is no confirmed active exploitation (CISA KEV).
Cross-tenant record disclosure in AshPostgres 0.38.0 through 2.15.1 lets an authenticated tenant user load destination records that are only related to a source record through another tenant's join rows, when a many_to_many or through relationship is loaded with a lateral join. The exposure is bounded: it requires the join resource (or a resource along the through path) to use Ash's :attribute multitenancy strategy and to actually hold rows for several tenants, plus a load path that triggers a lateral join via a per-record limit, offset or sort on the relationship; schema- or context-based multitenancy and non-lateral loads are not affected. No public exploit code was identified at time of analysis, the issue is not in CISA KEV, and the vendor-released fix is AshPostgres 2.15.2.
An incorrect authorization flaw in the Elixir Ash framework (versions 3.24.0 up to but not including 3.37.1) lets an authenticated client read destination records that are unrelated to the source record when a `through` relationship is loaded for a single record with a caller-controlled `limit: 1` and optional `offset`. The vulnerable path in `lateral_join?/4` skips the filter that ties the destination back to the source, so a client paging a field such as `teachers(limit: 1, offset: n)` through AshGraphql can walk through destination records that the destination's policies only permit when reached via that relationship. Exploitation requires an authenticated session and a deployment that exposes such a `through` relationship to caller-controlled paging while relying on `accessing_from` in destination read policies; no public exploit was identified at time of analysis, and the vendor has released a fix in 3.37.1.
Sensitive-value disclosure in Elixir's plug_crypto library allows a single unauthenticated request carrying a wrong-typed argument or a missing header to push the application's secret key base, a derived 32-byte encryption key, or the configured secret an API key is compared against into the Plug.Cowboy/Bandit error log and into crash_reason Logger metadata that error trackers forward. Applications on plug_crypto from 1.0.0 before 2.2.1, or on the bundled Plug.Crypto shipped in plug from 1.6.3 before 1.7.0, are affected; the request itself does not hand the secret to the attacker, so exploitation additionally depends on a separate party having read access to those logs or to the error tracker, which is why the assessed vector carries PR:H despite the unauthenticated trigger. No public exploit code was identified at time of analysis, and patched releases (plug_crypto 2.2.1, plug 1.7.0) are available from the vendor.
Bandit versions 0.6.0 up to (but not including) 1.13.0 pass an attacker-supplied authority from HTTP/1 absolute-form and authority-form request targets straight into conn.host and conn.port without validating it against the RFC 3986 host grammar, so an unauthenticated remote request such as 'GET http://good.example@evil.example/x HTTP/1.1' overrides the Host header that Bandit does check. The real-world impact is narrow and conditional: it only matters when the hosting Elixir/Phoenix application builds absolute URLs from conn.host/conn.port (Plug.Conn.request_url/1, Phoenix URL helpers) and then uses those URLs in a security-relevant way, and because message framing is untouched and no CR or LF byte can reach conn.host, it cannot be turned into request smuggling or CRLF/response-header injection. The vendor rates this CVSS 4.0 6.9 (Medium) with only low integrity impact (VI:L, no confidentiality or availability loss); no public exploit code or confirmed active exploitation has been identified at time of analysis (no public exploit identified at time of analysis).
Terminal-output injection in the Elixir Hex package manager (all versions from 0.0.1 up to, but not including, 2.5.2) allows a malicious package publisher or a hostile repository server to smuggle ANSI escape sequences and Unicode bidirectional overrides into what Mix prints, forging displayed URLs, package descriptions and suggested commands, hiding real output, or writing attacker-chosen text to the victim's clipboard via OSC 52. Exploitation is unauthenticated (CVSS:4.0 PR:N) but requires the victim to run one of the affected interactive Mix tasks - such as mix hex.info, mix hex.package search, mix hex.search, mix hex.user or mix hex.policy - against data the attacker controls, and it depends on the victim's terminal emulator interpreting the injected sequences; impact is confined to output forgery and clipboard manipulation, with no code execution, file access or privilege gain, and the assessed severity is low (CVSS 4.0 base 2.3). No public exploit code was identified at time of analysis and there is no indication of active exploitation; the vendor has released a fix in Hex 2.5.2.
Integrity-check bypass in the Hex package manager (hexpm hex) allows a compromised or attacker-controlled package mirror to substitute package contents when a developer runs `mix hex.package fetch PACKAGE VERSION --output -` and pipes standard output into an unpacker. The stdout code path writes the raw bytes returned by Hex.SCM.fetch/3 without the inner/outer checksum comparison that the default file-output path performs against the signed registry, and Hex's own diagnostics (a failed HTTP response body or an x-hex-message API warning) can likewise land on stdout as a tar archive ahead of any verified tarball. Hex versions from 0.20.2 up to but excluding 2.5.2 are affected; no public exploit code has been identified at time of analysis, and exploitation additionally requires a non-default mirror (HEX_MIRROR_URL or mirror_url) plus the specific stdout-piping command run by an unauthenticated remote attacker's victim, making this a genuine but conditionally gated supply-chain integrity flaw rather than a drop-everything emergency.
Improper certificate validation in Hex (the Elixir/Erlang package manager client, versions 0.20.2 through 2.5.1) allows a man-in-the-middle attacker to impersonate a Hex host under a narrow set of conditions: the attacker must intercept the victim's HTTPS traffic, must hold a certificate for the target host issued by a CA present in Hex's bundled CA store, and the victim must have pointed cacerts_path (HEX_CACERTS_PATH) at a custom store that deliberately excludes that CA. Under those preconditions the attacker can present a chain that reaches a bundled CA and have it accepted, defeating the operator's explicit trust configuration and potentially exposing package metadata, tarballs, and credentials transmitted to the impersonated host, although hostname verification still applies and reduces the attack surface. Assessed risk is medium (CVSS 4.0 base 5.9; CVSS 3.1 AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:L/A:N) and is constrained by the non-default configuration requirement and the privileged network position needed; no public exploit code has been identified at time of analysis and the issue is not in CISA KEV. A vendor patch is available in Hex 2.5.2.
Unauthenticated attackers can read internal Elixir terms from ash_typescript RPC error responses by deliberately provoking errors that the library's error builder has no dedicated clause for, affecting versions 0.1.0 through 0.19.0. Two RPC request paths trigger the leak: a struct-typed action argument carrying an invalid nested value that pushes a raw Ash.Type cast error into the builder, and field selection on a generic action returning a primitive that causes the full Ash.Info.Manifest.Type struct to be embedded into the response. The issue is a medium-severity CWE-209 information disclosure (CVSS 4.0 6.3; independent 3.1 assessment AV:N/AC:H/PR:N/UI:N/C:L), no public exploit code has been identified at time of analysis, and a vendor patch is available in ash_typescript 0.19.1.
Unbounded memory allocation in the ericmj/decimal Elixir library lets an attacker who controls the 'places' argument of Decimal.round/2 or Decimal.round/3 exhaust host memory and get the BEAM VM killed; all releases from 0.1.0 up to (but not including) 3.1.2 are affected. The function materialises the entire rounded result before the 34-digit default context precision is applied, so a single call such as Decimal.round(Decimal.new("1.5"), -50_000_000) allocates roughly 5.5 GB, while the oldest releases instead spin one loop iteration per decimal place and burn CPU in proportion to the argument. The official CVSS 4.0 base score is 6.9 (availability-only, VC:N/VI:N/VA:H), our independent assessment rates it CVSS 3.1 7.5 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, and no public exploit code or confirmed active exploitation was identified at time of analysis. Exposure is conditional: the vulnerability is only reachable when a consuming application forwards an unbounded, user-supplied scale or decimal-place count into round/2 or round/3 - the input limits previously added for CVE-2026-32686 explicitly do not cover the places argument.
Information disclosure in the Ash framework for Elixir (versions 2.6.0 up to but not including 3.34.6) lets an authenticated actor infer the existence and attribute values of related records they are not authorized to read. Because the aggregate code path (Ash.Actions.Aggregate.run/4) applied only the root resource's read policy and skipped the per-related-resource read policies that the normal read path enforces, a caller who can influence filter or sort input on Ash.count/2, Ash.exists/2, or Ash.aggregate/3 can probe conditions against hidden rows and recover their contents one query at a time. Concrete exposure paths named in the advisory are Ash.Query.filter_input/2, ash_lua scripts, and AshAi tools that expose count or exists results; the vendor rates this 6.0 under CVSS 4.0 and our independent assessment places it at CVSS 3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N, and no public exploit identified at time of analysis.
Incorrect type conversion in the BeamMCP (beam_mcp) Elixir library from 0.1.0 before 0.10.1 causes an authenticated MCP client's JSON boolean and null tool arguments to arrive at the host's dispatch function as the Elixir strings "true", "false" and "nil"; because a string is truthy in Elixir, a host that branches on truthiness - for example `if args.dry_run` or a `confirm: false` guard - evaluates a client-supplied false as though it were set. The same normalization applies to prompts/get arguments on versions 0.5.0 and later, while the practical impact is bounded: the client could have sent true directly, so only hosts or policy layers whose false branch diverges from their true branch are meaningfully affected, and an attacker must already be an authorized MCP client (CVSS 4.0 base 2.3; assessed CVSS 3.1 AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:N). No public exploit has been identified at time of analysis and CISA SSVC records no exploitation; a vendor-released patch (0.10.1) is available.
Authenticated MCP clients connected to a beam_mcp server in the 0.1.0 through 0.10.0 range can call tools (and prompts) with arguments that violate the JSON Schema the server itself advertised, because BeamMCP.Schema.validate/2 only enforced constraints on the top-level arguments object. The practical impact is limited to integrity (CVSS 3.1 base vector AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N, 5.3): a host whose dispatch code trusts the declared schema may act on out-of-range numbers, undeclared nested keys, or other forbidden values, and whatever that host does with the value determines the real blast radius. Exploitation requires an authorized MCP client connection (PR:L) plus a host that does not independently re-validate - no public exploit identified at time of analysis, CISA SSVC records Exploitation: none and Automatable: no, and no KEV listing exists. The issue is rated medium severity and low priority despite being network-reachable.
Insufficient password-hashing work factor in the Cloak.Ecto PBKDF2 field module causes hashes to be derived with roughly 18,750 times less computational effort than the configured parameters imply, letting anyone who already holds both the stored hash values and the configured :secret brute-force low-entropy plaintexts (such as email addresses) far more cheaply than the library promises. The affected code is cloak_ecto from 1.0.0-alpha.0 onward and cloak from 0.7.0 before 1.0.0-alpha.0; the vulnerable dump/1 callback passes config[:size] (default 32) into PBKDF2's iteration-count position, so each hash runs 32 rounds instead of the default 600,000. This is a post-compromise amplifier rather than a standalone remote exploit: it requires prior disclosure of the hash column and the application secret, and remains impractical against high-entropy values. No public exploit code was identified at time of analysis, and CISA KEV does not list this CVE; the CNA assigned CVSS 4.0 base 6.3 (medium), while our independent assessment rates it CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:L/I:N/A:N, reflecting the privileged prerequisites and confidentiality-only impact.
HTTP/1 response smuggling in the Elixir Mint client (0.1.0 through 1.10.x) allows a malicious or attacker-influenced origin server to desynchronize Mint from an upstream intermediary on a pooled keep-alive connection, so that bytes following a crafted response are parsed as the answer to a subsequent request, poisoning that request's response. The root cause is that Mint's message_body/1 selects chunked framing whenever 'chunked' is the FIRST coding in a Transfer-Encoding header (e.g. 'Transfer-Encoding: chunked, gzip') instead of requiring it to be the final coding, and additionally keeps the connection open after an HTTP/1.0 response - final or 1xx - that carries Transfer-Encoding with 'Connection: keep-alive', both contrary to RFC 9112. Exploitation is a reverse-trust scenario: the attacker must control or inject server response framing and the client must reuse an HTTP/1 connection; HTTP/2 and non-pooled connections are unaffected, and no public exploit code or active exploitation was identified at time of analysis. The issue is fixed in Mint 1.11.0.
Mutation XSS in the Elixir library LazyHTML 0.1.0 through 0.1.12 lets attacker-supplied markup slip past element and attribute allowlist filters and turn into live HTML when the filtered document is serialized for display. The defect is in LazyHTML.to_html/2 and LazyHTML.Tree.to_html/2, which decide whether to escape an element's text from the tag name alone, so a style or script element inside SVG or MathML foreign content is parsed with character references decoded yet serialized as an unescaped HTML raw-text element; encoded markup such as </style><img src=x onerror=...> inside <svg><style> therefore closes the element on re-parse and executes. Exploitation is unauthenticated and remote but conditional: the consumer application must parse untrusted HTML with lazy_html, filter the document or tree, and serialize the result to a victim who views it (user interaction required), which keeps real-world impact low (scope change, low confidentiality and integrity, no availability impact); no public exploit identified at time of analysis, and the vendor has shipped a fix in 0.1.13.
Improperly controlled modification of dynamically-determined object attributes in the Ash framework for Elixir (ash 2.17.15 through 3.33.10) lets a caller set private action arguments, declared with public?: false, on the bulk update and bulk destroy code paths. The affected matching logic in Ash.Actions.Destroy.Bulk.base_changeset/5 and Ash.Actions.Update.Bulk.base_changeset/5 compares every key of a caller-supplied parameter map against all of the action's arguments without checking public?, so any application that forwards end-user parameters into Ash.bulk_update/4 or Ash.bulk_destroy/4 (for example via AshJsonApi, AshGraphql, or a controller) can have a private argument injected; when that argument is referenced by an arg(...) template driving authorization, record ownership, or audit metadata, the result is an integrity violation or privilege escalation. The vendor has released a patch in 3.33.11 that requires public? in the bulk argument matching; no public exploit code has been identified at time of analysis, and the impact is conditional on the application both exposing a bulk action to untrusted input and using a security-relevant private argument.
Retained OAuth refresh tokens on hex.pm allow a user whose organization membership or session has ended to keep reading that organization's private packages and documentation tarballs. Refresh tokens are issued with the same issuer, audience and repository:<org> scope claims as access tokens, and the CDN that serves private repositories validates only the JWT signature and time claims, performing no membership lookup and unable to tell the two token types apart, so revocation takes effect only when the 30-day refresh token expires instead of at the 30-minute access-token lifetime. The actor must be an authenticated party who was a member when the token was granted, access is read-only and limited to organizations the account belonged to at grant time, and no public exploit has been identified at time of analysis; CVSS 4.0 base score is 2.3 (independent assessment CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N).
AshAuthentication's token-revocation action accepts forged JWTs without verifying their signature, letting an unauthenticated remote caller write arbitrary rows into the token resource or neutralise an existing revocation. Because the revocation record's expires_at is derived from the attacker-supplied exp claim, an attacker holding a copy of a genuine token can resubmit it with the real jti intact but a backdated exp, producing a revocation row that is already expired; once expunge_expired prunes it, the genuine token validates again through revoked? and logout-based invalidation is defeated. The weakness is confined to token-revocation state in ash_authentication 0.2.0 through 4.14.x and 5.0.0-rc.0 through 5.0.0-rc.13 (CVSS 6.9 per the CVSS 4.0 vector; an independent assessment scores it CVSS 3.1 5.3 with integrity-only impact and no confidentiality or availability loss), and no public exploit identified at time of analysis.
Log forgery in the AshAuthentication Elixir library allows any remote attacker who can reach an application's password-reset request action to inject arbitrary, attacker-controlled lines into the application's logs, including forged severity tags and messages that appear to originate from the application itself. Affected versions are ash_authentication 4.2.0 through 4.14.x and 5.0.0-rc.0 through 5.0.0-rc.13; the flaw is CWE-117 (improper output neutralization for logs) and is rated 6.3 under CVSS v4.0, with the independent assessment settling on CVSS 3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N - an integrity-only, low-impact issue rather than a high-priority emergency. Impact is confined to misleading or forged log records (no confidentiality or availability effect) and materializes only where logs are retained, reviewed, or fed into a SIEM/log-processing pipeline, which is the 'attack requirement beyond the attacker's control' reflected in the AT:P vector component; no public exploit has been identified at time of analysis, though the upstream fix commits are public.
OAuth2 login CSRF affects AshAuthentication, the authentication extension for the Ash framework in Elixir: the OAuth2 callback plug fails to delete the stored session_params value when an authorization attempt fails or is cancelled, so an attacker who learns that value can replay the callback and sign a victim into an attacker-controlled account. The flaw is reachable in ash_authentication 0.6.0 up to (but not including) 4.15.0, and in the 5.0.0-rc.0 through 5.0.0-rc.13 pre-releases, and requires the victim to be induced to replay the callback within the same session before the next request phase or session expiry consumes the value - unauthenticated but dependent on user interaction, per the assessed vector CVSS:3.1/AV:N/AC:H/PR:N/UI:R. Exploitation yields limited confidentiality and integrity impact (login CSRF onto an attacker's account rather than takeover of the victim's account), EPSS and KEV data were not provided, and no public exploit identified at time of analysis; vendor patches are available.
The audit-log add-on in AshAuthentication stores pseudonymised client IP addresses using an unkeyed SHA-256 over a salt concatenated with the IP, truncated to 16 hex characters, so anyone who can already read the audit store can reverse those values back to the original addresses. Exploitation requires two explicit prerequisites: ip_privacy_mode must be set to :hash (the DSL default is :none, so this is an opt-in), and the attacker must already hold read access to the audit log via a database dump, backup, replica, or reader account. Reversal is trivial when the salt is left at the library's published fallback constant 'default-salt-change-in-production', which is used silently with no warning; even a properly configured salt only reduces the problem to 'that salt must leak', after which exhaustive enumeration over the 2^32 IPv4 space is cheap. Per the authoritative assessment this is a low-priority information-disclosure issue (assessed CVSS 3.1 1.8, CWE-760) affecting only client IP addresses with no integrity or availability impact; no public exploit identified at time of analysis, and vendor-released patches exist in 4.15.0 and 5.0.0-rc.14.
The audit_log add-on in the Elixir library AshAuthentication (ash_authentication) writes the full actor record into each audit entry's extra_data field, so the user's hashed_password digest is stored alongside the audit trail in versions from 4.12.0 up to but not including 4.15.0, and from 5.0.0-rc.0 up to but not including 5.0.0-rc.2. There is no network-facing or attacker-triggered disclosure path: entries accumulate from ordinary authenticated activity controlled by benign code, and an attacker's own requests only deposit the attacker's own digest, so exploitation requires that the attacker already hold independent read access to the audit store (database credentials, an audit role, a backup, or a log shipper). The result is exposure of password hashes that support offline cracking of every active account whose actions were audited; the vector is local, high complexity, and privileged (per the assessment PR:H), making this a log-hygiene/defense-in-depth issue rather than an actively exploited one - no public exploit code or CISA KEV entry has been identified at time of analysis, and vendor patches are available.
An authorization bypass in the Ash framework (Elixir) lets authenticated, lower-privileged actors recover values they are not permitted to see by using filtered calculations or aggregates as a yes/no oracle. Ash field policies are designed to protect against filter-based disclosure by rewriting references to forbidden attributes into an expression that evaluates to nil, but prior to 3.33.4 that rewriting only matched Ash.Resource.* structs and not Ash.Query.Calculation or Ash.Query.Aggregate structs, so filters on those ran against real values. Any application that uses Ash.Policy.Authorizer with field policies on calculations or aggregates and exposes filter arguments (commonly via AshGraphql or AshJsonApi) is affected; no public exploit identified at time of analysis, and the disclosure is gradual - one probe at a time - with no integrity or availability impact.
Duplicate-submission gate bypass in the Tempo payment method of ZenHive mpp (versions 0.2.0 through 0.16.1) lets an unauthenticated remote client pass the pre-broadcast dedup reservation twice using a single signed transaction - once with recovery id v=27 and once with v=0 - because the reserve key is derived from the caller-supplied raw transaction hex rather than a canonical form of the transaction. The post-broadcast mark then writes the canonical hash key that the raw-keyed reserve never reads, so the two encodings never collide. Impact is real but bounded and conditional: a node that rejects nonce reuse fails closed and produces no harm, while a node that returns the canonical hash for an already-known transaction can issue a second valid Payment-Receipt for a single on-chain payment; confidentiality and availability are unaffected, and no public exploit code has been identified at time of analysis.
Uncontrolled recursion between Elixir's charlist inspection path and the error-message rescue clause in List.to_string/1 and List.to_charlist/1 can exhaust a BEAM node's memory when an attacker controls list data reaching those functions. A crafted list whose printable prefix exceeds the 4096-element printable_limit but which carries an invalid element beyond that threshold bypasses the ASCII classification check, triggers ArgumentError in IO.chardata_to_string/1, and then recurses infinitely through the rescue clause because the inner inspect/1 call is not in tail position - every frame is retained on the process heap. No public exploit has been identified at time of analysis; vendor-released patches are available as Elixir 1.18.5, 1.19.6, and 1.20.4.
Denial of service in Elixir's standard library Version module (versions 1.5.0 through 1.20.0) allows any caller passing an attacker-controlled version string to exhaust CPU and memory or crash the calling BEAM process. The five public entry points - Version.parse/1, Version.parse!/1, Version.match?/3, Version.compare/2, and Version.parse_requirement/1 - pass numeric version components to :erlang.binary_to_integer/1 without length bounds, triggering super-linear arbitrary-precision integer conversion; a single ~1 MB all-digit component suffices. Applications routinely invoke these functions on untrusted input (HTTP parameters, package metadata), making the effective attack surface broader than the CVSS AV:L classification implies. No public exploit has been identified at time of analysis, and the vulnerability is not listed in CISA KEV.
Elixir 0.8.0 uses Blowfish in CFB mode without constructing a unique initialization vector (IV), which makes it easier for context-dependent users to obtain sensitive information and decrypt the. Rated medium severity (CVSS 4.3), this vulnerability is remotely exploitable. No vendor patch available.
Unauthenticated remote CPU exhaustion in mtrudel Bandit's HTTP/2 server (versions before 1.14.0) is achievable by holding thousands of response streams blocked on the connection send window and then sending tiny SETTINGS or stream-0 WINDOW_UPDATE frames. Each such frame makes the server retry every blocked send via do_pending_sends/2, producing O(n²) list operations; the advisory's verified PoC measured 133 ms for a single 9-byte SETTINGS frame with 3,000 blocked streams. The issue is remotely exploitable without authentication or user interaction and is prioritized this_week; the supplied data does not confirm active exploitation, and a public proof-of-concept is included in the advisory.
Unbounded per-connection memory and CPU growth in the Elixir Bandit HTTP/2 server (0.3.6 up to 1.14.0) lets an unauthenticated remote client advertise a SETTINGS_HEADER_TABLE_SIZE of up to 2^32-1, which Bandit applies to its HPACK encoder table with no server-side cap; every response header is then stored into that oversized table and never evicted, so the encoding cost of each response grows linearly and the connection's total cost grows quadratically. No authentication or user interaction is required (PR:N/UI:N), the effect is purely availability (C:N/I:N/A:H, scored 8.7 under CVSS 4.0 and assessed as AV:N/AC:L/PR:N/UI:N/A:H under CVSS 3.1), and it only bites while a connection is kept alive and busy with cheap requests to endpoints whose response headers vary per request. It is not confirmed actively exploited (CISA KEV), but the vendor advisory documents a public proof-of-concept procedure; treat it as a this-week priority rather than an emergency, since capping requests per connection or upgrading to 1.14.0 removes the growth.
HTTP/2 resource-limit bypass in the Elixir Bandit web server (1.9.0 through 1.13.x) lets an unauthenticated remote client exceed the configured max_concurrent_streams and max_requests caps by packing multiple HEADERS frames into a single TCP write where one frame raises a StreamError, causing the handler to continue from pre-chunk connection state. Because stream counts, last_stream_id, rapid-reset timestamps and the HPACK decoder state are all rolled back while the already-started Plug calls keep running, an attacker can drive roughly five times the intended number of concurrent Plug invocations per connection (50 running against a limit of 10 in the reporter's test), exhausting server processes, CPU and memory. Impact is strictly availability - no confidentiality or integrity loss - HTTP/2 with a finite max_concurrent_streams is the default for Bandit's TLS/h2 listeners, no public exploit code is confirmed, and a vendor patch is available.
Unauthenticated remote denial of service in the Elixir HTTP server Bandit (mtrudel/bandit) from 0.1.0 before 1.14.0 lets a single remote attacker exhaust server memory and CPU with one HTTP/1.1 request whose chunked body is composed of a very large number of 1-byte chunks. Because the chunked reader keeps every chunk as its own cons cell and binary term until IO.iodata_to_binary/1 joins them, and the :length option of read_body/2 counts only data bytes, the vendor's reproduction shows 48 MB of 1-byte chunks growing one handler process to roughly 500 MB and consuming about 6 seconds of CPU - a ~48x amplification over the payload sent - and the amplification also occurs against routes that never call read_body, since ensure_completed/1 drains unread bodies on keep-alive connections. HTTP/1.1 is enabled by default, so any default deployment is exposed without authentication or user interaction; the vendor shipped a fix in 1.14.0, there are no reports of exploitation in CISA KEV and no independently confirmed public exploit code, though the advisory does publish detailed reproduction steps.
Unauthenticated remote attackers can consume disproportionate server CPU on Bandit (mtrudel/bandit, Elixir/Erlang) by sending a Content-Length value or a Host/:authority port composed of thousands of digits, which the header integer parser processes in quadratic time before any range check. Over HTTP/2 the cost is amplified because a 4,000-digit value can be stored once in the HPACK dynamic table and replayed cheaply across thousands of new streams; the advisory's proof-of-concept sent roughly 124 KB that kept the server busy for 27.9 seconds. Both HTTP/1 and HTTP/2 deployments are affected at default configuration, versions 1.0.0-pre.7 up to but not including 1.14.0. The advisory includes a public PoC reference that is not independently verified as working exploit code; there is no CISA KEV listing or other indication of active exploitation, and the vendor has released 1.14.0 as the fix.
Cross-tenant record takeover in the Ash framework (Elixir) for versions 1.22.0 up to 3.37.2: when a resource uses attribute multitenancy and exposes a create action with upsert? true that accepts the primary key (or upserts on an all_tenants? identity), an authenticated user of one tenant can supply another tenant's record ID and have that record updated, its full attribute set returned, and - with default upsert fields - its tenant attribute rewritten, moving the record into the attacker's tenant. Read and update policies do not run on the upsert path, and tenant-scoped create policies pass because the tenant on the request is the caller's own, so the only meaningful preconditions are that such an action is exposed and that the attacker knows or can enumerate a foreign key (for example a serial integer ID or an ID leaked through a shared link or export). The vendor has released a fix in ash 3.37.2; no public exploit code was identified at time of analysis, and the priority signal is to patch this week rather than an emergency response.
Hex, the package manager used by Elixir and Erlang projects, fails to properly scope its 'release-age cooldown' protection in versions 2.5.0 through 2.5.1, allowing an authenticated package owner to slip a freshly published, malicious release past the cooldown. The attacker must already hold package-owner permission on the target package, retire (or rely on a security advisory for) the release locked in the victim's mix.lock, and then wait for the victim to run mix deps.update - at which point Hex.RemoteConverger.build_cooldown_bypass/3 and unsafe_lock_bypass/1 lift the cooldown for every version of that package and its dependencies, so the new release is selected regardless of age. A secondary scoping defect causes the bypass to be keyed on package name alone, extending it to identically named packages in other repositories; cooldown configured through an organization dependency policy is not affected. This is a conditional supply-chain weakness rather than a broadly dangerous remote flaw, and no public exploit or in-the-wild activity has been identified at time of analysis. Patches are available from the vendor in Hex 2.5.2.
Memory-exhaustion denial of service in the elixir-protobuf library (protobuf) from 0.8.0 onward allows an unauthenticated remote attacker to crash an Elixir decoding process by supplying a deeply nested JSON document through Protobuf.JSON.decode/3, decode!/3, or from_decoded/3 when the target schema contains a self-referential or cyclic message type. Because the embedded-message clause of decode_singular/3 recurses once per nesting level without touching the decoder's depth counter, the recursion_limit option offers no protection and each level consumes a stack frame plus heap objects until the process runs out of memory; confidentiality and integrity are unaffected, only availability. Exploitation is unauthenticated and requires no user interaction, but is limited to applications that decode untrusted JSON into recursive message definitions, and no public exploit code has been identified at time of analysis (EPSS data not provided).
Ciphertext tampering in the Cloak Elixir encryption library (danielberkompas/cloak, all versions from 0.1.0-pre onward) lets anyone with write access to the encrypted store silently flip bits in stored ciphertext so that decryption returns an attacker-chosen plaintext of the same length. The affected code paths, Cloak.Ciphers.AES.CTR and Cloak.Ciphers.Deprecated.AES.CTR, encrypt with AES-256 in CTR mode and store the key tag, IV, and ciphertext with no MAC, and decrypt/2 validates only the key tag and a minimum length - so tampered data is returned as valid with no error. Exploitation requires write access to the ciphertext (the description cites SQL injection into the Ecto-backed database or a compromised replica) plus knowledge or a correct guess of the existing plaintext at the tampered offset, and the replacement value must be exactly the same length as the original; impact is integrity-only (VC:N/VA:N), with no public exploit identified at time of analysis. Note the vendor CVSS 4.0 score of 8.2 is driven entirely by VI:H, while an independent assessment applying CVSS 3.1 (AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N) rates the realistic risk considerably lower because an attacker must already control writes to the encrypted store and have plaintext knowledge.
Atom table exhaustion in the Ash framework (Elixir) allows an unauthenticated remote attacker to crash a BEAM node by supplying filter values for a publicly filterable :atom-typed attribute that is declared with the unsafe_to_atom?: true constraint. Each distinct attacker-controlled string is interned with String.to_atom/1; atoms are never garbage collected and the VM's atom table is fixed in size, so a flood of distinct values exhausts the table and terminates the node. The condition is version- and configuration-dependent: ash from 3.5.1 before 3.34.3 is affected, unsafe_to_atom?: true is not the default, and the vulnerable path is only reachable through a filter interface the attacker can query - AshPaperTrail meets that bar out of the box because its version resources expose a public, filterable version_action_name atom attribute with unsafe_to_atom?: true. A vendor patch is available in 3.34.3 and no public exploit code was identified at time of analysis.
Memory exhaustion denial-of-service in Elixir Mint affects versions 1.1.0 through 1.10.x and allows a malicious or compromised HTTP/2 server to force a client application to allocate roughly 1 GB per response by abusing HPACK indexed header fields and cookie handling, potentially exhausting the BEAM VM. The vulnerability requires the application to initiate an outbound HTTP/2 connection to an attacker-influenced endpoint (reverse-trust), and no public exploit code or confirmed active exploitation is identified at time of analysis. Downstream clients such as Finch and Req that use Mint are also affected when making outbound HTTP/2 requests to untrusted servers.
Improper JWT signature verification in Dashbit's nimble_zta (0.1.2 up to but not including 0.1.3) lets an unauthenticated remote attacker bypass authentication and impersonate an arbitrary Cloudflare service token in applications using the Cloudflare Zero Trust service-token strategy. Because verify_token/2 pattern-matches the {_, token, _s} tuple returned by JOSE.JWT.verify/2, the boolean signature-verification result is discarded and a forged JWT sent in the cf-access-jwt-assertion header is accepted as authenticated identity; the attacker only needs the expected iss claim plus the seven service-token claims (aud, common_name, exp, iat, iss, sub, type). No public exploit code has been identified at time of analysis, but the flaw is remotely reachable with no authentication or user interaction (assessed CVSS 3.1 base 9.3, scope changed) and is fixed in nimble_zta 0.1.3.
Session fixation in the Elixir/Phoenix authentication library ash_authentication (0.2.0 before 4.15.0, and 5.0.0-rc.0 before 5.0.0-rc.14) allows an attacker who has pre-planted a session identifier in a victim's browser to ride that identifier into the victim's authenticated session. AshAuthentication.Plug.Helpers.store_in_session/2 writes the authenticated subject into the existing session with Plug.Conn.put_session/3 and never calls Plug.Conn.configure_session(renew: true), so the identifier the visitor arrived with survives into their logged-in session through every authentication path, including the default success/4, the mix ash_authentication_phoenix.install AuthController, and remember-me auto-login; logout does not close the window because clear_session/2 ends with Plug.Conn.clear_session/1, which wipes contents but leaves the identifier intact, so a planted identifier survives a logout-then-login cycle. Exploitation is conditional rather than universal: it requires a server-side session store where a rotatable identifier exists (deployments on Phoenix's default signed-cookie session store are largely unaffected, as there is no identifier to fixate), a means of planting the session cookie in the victim's browser, and victim interaction to sign in. No public exploit was identified at time of analysis, although the upstream fix commits and their accompanying regression tests are public.
Session-swapping authentication bypass in the Elixir library AshAuthentication (versions 4.10.0 before 4.15.0 and 5.0.0-rc.0 before 5.0.0-rc.14) allows an attacker who can plant a remember-me cookie in a victim's browser to displace the victim's live authenticated session with one belonging to the attacker's own account, so anything the victim enters afterwards is captured under attacker-controlled state. The root cause is a guard/reader key mismatch: AshAuthentication.Plug.Helpers.sign_in_using_remember_me/3 checks the session for a '<subject_name>_token' key, but store_in_session/2 only writes that key when require_token_presence_for_authentication? is enabled and otherwise writes the bare subject name, leaving the already-signed-in short-circuit unreachable and the remember-me sign-in running on every request through the per-request browser pipeline plug. No public exploit code or confirmed active exploitation was identified at time of analysis, but exploitation is constrained by prerequisites - the attacker needs a remember-me token for their own account, a cookie-injection channel (shared/parent-domain cookie write, XSS, or on-path position), and subsequent victim interaction - which independent assessment reflects with CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N; vendor fixes are available in 4.15.0 and 5.0.0-rc.14.
Authentication bypass in the Elixir library ash_authentication lets an attacker who operates one federated identity-provider connection of a `dynamic_oidc` strategy be signed in as a local user whose identity row was created through a different IdP connection, because the intended per-connection namespacing of the `strategy` field never persists. Affected are versions 5.0.0-rc.10 through 5.0.0-rc.13 (fixed in 5.0.0-rc.14); the assessed vector is CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N, so the flaw is network-reachable and unauthenticated in the token-presentation sense, but real-world exploitation is tightly gated: the deployment must use `dynamic_oidc` with more than one identity-provider connection, the attacker must control (or have a trusted operator position on) one of those connections, and must be able to mint tokens with a chosen `sub` claim that collides with a target subject. No public exploit code was identified at time of analysis, and this CVE is not listed in CISA KEV; patch commits are already public, so the exposure window for unpatched, multi-connection deployments is the operational concern.
Account takeover in AshAuthentication (Elixir/Ash) 4.14.0 through 4.14.x and 5.0.0-rc.10 through 5.0.0-rc.13 lets unauthenticated remote attackers obtain a session for another user's account by linking their own OAuth2 provider identity to an account that was matched on an attribute other than email, and the same upsert rewrites the victim's email to the attacker's address so subsequent account recovery flows reach the attacker. Exploitation is conditional: the application must configure the OAuth2/Auth0/Apple strategy with a register-action upsert_identity that matches existing accounts on a non-email attribute, or use the registration_enabled? false sign-in path where accounts are matched by the sign-in action's read filter, and the attacker only needs control of a provider identity whose email_verified claim is true. No public exploit code has been identified at time of analysis and the issue is not confirmed as actively exploited (CISA KEV); vendor patches are available in 4.15.0 and 5.0.0-rc.14.
Password sign-in in AshAuthentication Phoenix (ash_authentication_phoenix 1.7.0 to <2.17.4 and 3.0.0-rc.0 to <3.0.0-rc.11, with the companion ash_authentication 3.10.5 to <4.15.0 and 5.0.0-rc.0 to <5.0.0-rc.14) places a freshly issued single-use sign-in token in the query string of a GET redirect to the sign_in_with_token route, so the live credential is written into the request line where it is retained by web server access logs, reverse-proxy logs, request telemetry and the victim's browser history. Anyone who can read those artifacts - and can replay the token before the legitimate redirect consumes it or it expires - can authenticate as the affected user. The exposure is only reachable when sign_in_tokens_enabled? is true and the password sign-in form is in use; the vendor rates it CVSS 4.0 7.2 (AV:L/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H) and our independent assessment aligns at CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N, indicating no public exploit identified at time of analysis rather than remotely exploitable default-configuration compromise.
Authentication bypass in the AshAuthentication library for Elixir/Ash lets an authenticated attacker who holds a valid sign-in token minted for one Ash resource replay it to be signed in as a user of a different resource, because the JWT 'sub' claim's path segment - the only portion recording which subject the token was issued for - is parsed with URI.parse/1 and thrown away, leaving only the query string. Affected are ash_authentication releases from 3.10.5 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.14, specifically the Password sign-in-with-token, WebAuthn sign-in and remember-me preparations; the magic-link sign-in path pins the subject against the resource and is not vulnerable. Exploitation is configuration-dependent - it requires two or more authenticated resources whose primary-key field names are identical (for example, both 'id') - and no public exploit code was identified at time of analysis.
An authenticated account-takeover primitive exists in the Elixir library AshAuthentication (ash_authentication) versions 0.5.0 through 4.14.x and 5.0.0-rc.0 through 5.0.0-rc.13: an attacker who can register their own account can replay the confirmation token generated for their own email change against a victim's record, causing the victim's address to be overwritten with the attacker's and confirmed_at to be stamped, after which a routine password reset hands over the account. Exploitation requires the application to use the Confirmation add-on with monitored fields (typically :email), the attacker's own registered account (authenticated, PR:L), and knowledge of the victim's record id (normally a UUID primary key); no action by the victim is required. The confirmation flow the library itself generates is not affected, and no public exploit code has been identified at time of analysis.
Server-Side Request Forgery protection bypass in the Elixir safeurl library (versions 0.1.0 and later) allows unauthenticated attackers who can influence a URL passed to SafeURL.get/validate_url to reach internal or reserved network destinations that the library is configured to block. The root cause is IPv4-only blocklist matching: a destination rejected as an IPv4 address is accepted when expressed as an IPv6 literal, IPv6 entries in the blocklist never match, and a hostname that resolves to no IPv4 address is accepted regardless of where it actually points; deployments using the library's allowlist (whitelist) option are not affected because unmatched addresses are rejected there. Exploitation requires an application running safeurl in its default blacklist/blocklist mode with attacker-influenced URLs; there is no public exploit identified at time of analysis, CISA KEV does not list this CVE, and EPSS is low at 0.46% (39th percentile), so urgency is driven by the defensive nature of the component rather than observed attack activity. CVSS is rated 9.0 by the CNA, with an independent assessment of CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:L/A:N reflecting high confidentiality impact, low integrity impact, and changed scope.
Unbounded recursion in the Elixir `protobuf` Hex package (versions >= 0.8.0, < 0.16.1) lets unauthenticated remote attackers take down any service that decodes untrusted protobuf bytes into a self-referential or cyclic message type, because each nested embedded message is decoded with a non-tail recursive call that retains a live stack and heap frame on the BEAM. A body of only a few KB to a few MB can nest an embedded field hundreds of thousands to millions of levels deep, consuming hundreds of MB of memory and seconds of CPU per request and pinning a scheduler, so a handful of concurrent requests can starve and crash the node. Publicly available exploit code exists, and the vendor has released a patch in 0.16.1 that enforces a configurable `:max_nesting_depth` defaulting to 100, matching Google's C++/Java reference implementations; exploitation is conditional on the target schema actually being recursive (reflected as CVSS 4.0 AT:P), so services decoding only flat message types are not affected despite the 8.2 base score.
Bandit, the pure-Elixir HTTP/WebSocket server, keeps running a WebSock application's handler code after the server has initiated a close, so a remote client that ignores the Close frame can still reach handle_in/2 and handle_info/2 with the state from the {:stop, ...} tuple. Versions 0.5.1 through 1.14.0 are affected (fixed in 1.14.0), and the practical impact lands on WebSock applications that use {:stop, ...} to enforce authorization - a client refused in init/1 after a failed token check, or a kicked/banned user (including Phoenix's :socket_drain path), can keep invoking sensitive actions until it sends Close, TCP drops, or the idle timeout fires, and each client frame resets that timeout. The vendor advisory includes a step-by-step proof-of-concept walkthrough; a public PoC reference exists, but it is not verified as working exploit code, and there is no confirmed active exploitation (CISA KEV).
Cross-tenant record disclosure in AshPostgres 0.38.0 through 2.15.1 lets an authenticated tenant user load destination records that are only related to a source record through another tenant's join rows, when a many_to_many or through relationship is loaded with a lateral join. The exposure is bounded: it requires the join resource (or a resource along the through path) to use Ash's :attribute multitenancy strategy and to actually hold rows for several tenants, plus a load path that triggers a lateral join via a per-record limit, offset or sort on the relationship; schema- or context-based multitenancy and non-lateral loads are not affected. No public exploit code was identified at time of analysis, the issue is not in CISA KEV, and the vendor-released fix is AshPostgres 2.15.2.
An incorrect authorization flaw in the Elixir Ash framework (versions 3.24.0 up to but not including 3.37.1) lets an authenticated client read destination records that are unrelated to the source record when a `through` relationship is loaded for a single record with a caller-controlled `limit: 1` and optional `offset`. The vulnerable path in `lateral_join?/4` skips the filter that ties the destination back to the source, so a client paging a field such as `teachers(limit: 1, offset: n)` through AshGraphql can walk through destination records that the destination's policies only permit when reached via that relationship. Exploitation requires an authenticated session and a deployment that exposes such a `through` relationship to caller-controlled paging while relying on `accessing_from` in destination read policies; no public exploit was identified at time of analysis, and the vendor has released a fix in 3.37.1.
Sensitive-value disclosure in Elixir's plug_crypto library allows a single unauthenticated request carrying a wrong-typed argument or a missing header to push the application's secret key base, a derived 32-byte encryption key, or the configured secret an API key is compared against into the Plug.Cowboy/Bandit error log and into crash_reason Logger metadata that error trackers forward. Applications on plug_crypto from 1.0.0 before 2.2.1, or on the bundled Plug.Crypto shipped in plug from 1.6.3 before 1.7.0, are affected; the request itself does not hand the secret to the attacker, so exploitation additionally depends on a separate party having read access to those logs or to the error tracker, which is why the assessed vector carries PR:H despite the unauthenticated trigger. No public exploit code was identified at time of analysis, and patched releases (plug_crypto 2.2.1, plug 1.7.0) are available from the vendor.
Bandit versions 0.6.0 up to (but not including) 1.13.0 pass an attacker-supplied authority from HTTP/1 absolute-form and authority-form request targets straight into conn.host and conn.port without validating it against the RFC 3986 host grammar, so an unauthenticated remote request such as 'GET http://good.example@evil.example/x HTTP/1.1' overrides the Host header that Bandit does check. The real-world impact is narrow and conditional: it only matters when the hosting Elixir/Phoenix application builds absolute URLs from conn.host/conn.port (Plug.Conn.request_url/1, Phoenix URL helpers) and then uses those URLs in a security-relevant way, and because message framing is untouched and no CR or LF byte can reach conn.host, it cannot be turned into request smuggling or CRLF/response-header injection. The vendor rates this CVSS 4.0 6.9 (Medium) with only low integrity impact (VI:L, no confidentiality or availability loss); no public exploit code or confirmed active exploitation has been identified at time of analysis (no public exploit identified at time of analysis).
Terminal-output injection in the Elixir Hex package manager (all versions from 0.0.1 up to, but not including, 2.5.2) allows a malicious package publisher or a hostile repository server to smuggle ANSI escape sequences and Unicode bidirectional overrides into what Mix prints, forging displayed URLs, package descriptions and suggested commands, hiding real output, or writing attacker-chosen text to the victim's clipboard via OSC 52. Exploitation is unauthenticated (CVSS:4.0 PR:N) but requires the victim to run one of the affected interactive Mix tasks - such as mix hex.info, mix hex.package search, mix hex.search, mix hex.user or mix hex.policy - against data the attacker controls, and it depends on the victim's terminal emulator interpreting the injected sequences; impact is confined to output forgery and clipboard manipulation, with no code execution, file access or privilege gain, and the assessed severity is low (CVSS 4.0 base 2.3). No public exploit code was identified at time of analysis and there is no indication of active exploitation; the vendor has released a fix in Hex 2.5.2.
Integrity-check bypass in the Hex package manager (hexpm hex) allows a compromised or attacker-controlled package mirror to substitute package contents when a developer runs `mix hex.package fetch PACKAGE VERSION --output -` and pipes standard output into an unpacker. The stdout code path writes the raw bytes returned by Hex.SCM.fetch/3 without the inner/outer checksum comparison that the default file-output path performs against the signed registry, and Hex's own diagnostics (a failed HTTP response body or an x-hex-message API warning) can likewise land on stdout as a tar archive ahead of any verified tarball. Hex versions from 0.20.2 up to but excluding 2.5.2 are affected; no public exploit code has been identified at time of analysis, and exploitation additionally requires a non-default mirror (HEX_MIRROR_URL or mirror_url) plus the specific stdout-piping command run by an unauthenticated remote attacker's victim, making this a genuine but conditionally gated supply-chain integrity flaw rather than a drop-everything emergency.
Improper certificate validation in Hex (the Elixir/Erlang package manager client, versions 0.20.2 through 2.5.1) allows a man-in-the-middle attacker to impersonate a Hex host under a narrow set of conditions: the attacker must intercept the victim's HTTPS traffic, must hold a certificate for the target host issued by a CA present in Hex's bundled CA store, and the victim must have pointed cacerts_path (HEX_CACERTS_PATH) at a custom store that deliberately excludes that CA. Under those preconditions the attacker can present a chain that reaches a bundled CA and have it accepted, defeating the operator's explicit trust configuration and potentially exposing package metadata, tarballs, and credentials transmitted to the impersonated host, although hostname verification still applies and reduces the attack surface. Assessed risk is medium (CVSS 4.0 base 5.9; CVSS 3.1 AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:L/A:N) and is constrained by the non-default configuration requirement and the privileged network position needed; no public exploit code has been identified at time of analysis and the issue is not in CISA KEV. A vendor patch is available in Hex 2.5.2.
Unauthenticated attackers can read internal Elixir terms from ash_typescript RPC error responses by deliberately provoking errors that the library's error builder has no dedicated clause for, affecting versions 0.1.0 through 0.19.0. Two RPC request paths trigger the leak: a struct-typed action argument carrying an invalid nested value that pushes a raw Ash.Type cast error into the builder, and field selection on a generic action returning a primitive that causes the full Ash.Info.Manifest.Type struct to be embedded into the response. The issue is a medium-severity CWE-209 information disclosure (CVSS 4.0 6.3; independent 3.1 assessment AV:N/AC:H/PR:N/UI:N/C:L), no public exploit code has been identified at time of analysis, and a vendor patch is available in ash_typescript 0.19.1.
Unbounded memory allocation in the ericmj/decimal Elixir library lets an attacker who controls the 'places' argument of Decimal.round/2 or Decimal.round/3 exhaust host memory and get the BEAM VM killed; all releases from 0.1.0 up to (but not including) 3.1.2 are affected. The function materialises the entire rounded result before the 34-digit default context precision is applied, so a single call such as Decimal.round(Decimal.new("1.5"), -50_000_000) allocates roughly 5.5 GB, while the oldest releases instead spin one loop iteration per decimal place and burn CPU in proportion to the argument. The official CVSS 4.0 base score is 6.9 (availability-only, VC:N/VI:N/VA:H), our independent assessment rates it CVSS 3.1 7.5 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, and no public exploit code or confirmed active exploitation was identified at time of analysis. Exposure is conditional: the vulnerability is only reachable when a consuming application forwards an unbounded, user-supplied scale or decimal-place count into round/2 or round/3 - the input limits previously added for CVE-2026-32686 explicitly do not cover the places argument.
Information disclosure in the Ash framework for Elixir (versions 2.6.0 up to but not including 3.34.6) lets an authenticated actor infer the existence and attribute values of related records they are not authorized to read. Because the aggregate code path (Ash.Actions.Aggregate.run/4) applied only the root resource's read policy and skipped the per-related-resource read policies that the normal read path enforces, a caller who can influence filter or sort input on Ash.count/2, Ash.exists/2, or Ash.aggregate/3 can probe conditions against hidden rows and recover their contents one query at a time. Concrete exposure paths named in the advisory are Ash.Query.filter_input/2, ash_lua scripts, and AshAi tools that expose count or exists results; the vendor rates this 6.0 under CVSS 4.0 and our independent assessment places it at CVSS 3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N, and no public exploit identified at time of analysis.
Incorrect type conversion in the BeamMCP (beam_mcp) Elixir library from 0.1.0 before 0.10.1 causes an authenticated MCP client's JSON boolean and null tool arguments to arrive at the host's dispatch function as the Elixir strings "true", "false" and "nil"; because a string is truthy in Elixir, a host that branches on truthiness - for example `if args.dry_run` or a `confirm: false` guard - evaluates a client-supplied false as though it were set. The same normalization applies to prompts/get arguments on versions 0.5.0 and later, while the practical impact is bounded: the client could have sent true directly, so only hosts or policy layers whose false branch diverges from their true branch are meaningfully affected, and an attacker must already be an authorized MCP client (CVSS 4.0 base 2.3; assessed CVSS 3.1 AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:N). No public exploit has been identified at time of analysis and CISA SSVC records no exploitation; a vendor-released patch (0.10.1) is available.
Authenticated MCP clients connected to a beam_mcp server in the 0.1.0 through 0.10.0 range can call tools (and prompts) with arguments that violate the JSON Schema the server itself advertised, because BeamMCP.Schema.validate/2 only enforced constraints on the top-level arguments object. The practical impact is limited to integrity (CVSS 3.1 base vector AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N, 5.3): a host whose dispatch code trusts the declared schema may act on out-of-range numbers, undeclared nested keys, or other forbidden values, and whatever that host does with the value determines the real blast radius. Exploitation requires an authorized MCP client connection (PR:L) plus a host that does not independently re-validate - no public exploit identified at time of analysis, CISA SSVC records Exploitation: none and Automatable: no, and no KEV listing exists. The issue is rated medium severity and low priority despite being network-reachable.
Insufficient password-hashing work factor in the Cloak.Ecto PBKDF2 field module causes hashes to be derived with roughly 18,750 times less computational effort than the configured parameters imply, letting anyone who already holds both the stored hash values and the configured :secret brute-force low-entropy plaintexts (such as email addresses) far more cheaply than the library promises. The affected code is cloak_ecto from 1.0.0-alpha.0 onward and cloak from 0.7.0 before 1.0.0-alpha.0; the vulnerable dump/1 callback passes config[:size] (default 32) into PBKDF2's iteration-count position, so each hash runs 32 rounds instead of the default 600,000. This is a post-compromise amplifier rather than a standalone remote exploit: it requires prior disclosure of the hash column and the application secret, and remains impractical against high-entropy values. No public exploit code was identified at time of analysis, and CISA KEV does not list this CVE; the CNA assigned CVSS 4.0 base 6.3 (medium), while our independent assessment rates it CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:L/I:N/A:N, reflecting the privileged prerequisites and confidentiality-only impact.
HTTP/1 response smuggling in the Elixir Mint client (0.1.0 through 1.10.x) allows a malicious or attacker-influenced origin server to desynchronize Mint from an upstream intermediary on a pooled keep-alive connection, so that bytes following a crafted response are parsed as the answer to a subsequent request, poisoning that request's response. The root cause is that Mint's message_body/1 selects chunked framing whenever 'chunked' is the FIRST coding in a Transfer-Encoding header (e.g. 'Transfer-Encoding: chunked, gzip') instead of requiring it to be the final coding, and additionally keeps the connection open after an HTTP/1.0 response - final or 1xx - that carries Transfer-Encoding with 'Connection: keep-alive', both contrary to RFC 9112. Exploitation is a reverse-trust scenario: the attacker must control or inject server response framing and the client must reuse an HTTP/1 connection; HTTP/2 and non-pooled connections are unaffected, and no public exploit code or active exploitation was identified at time of analysis. The issue is fixed in Mint 1.11.0.
Mutation XSS in the Elixir library LazyHTML 0.1.0 through 0.1.12 lets attacker-supplied markup slip past element and attribute allowlist filters and turn into live HTML when the filtered document is serialized for display. The defect is in LazyHTML.to_html/2 and LazyHTML.Tree.to_html/2, which decide whether to escape an element's text from the tag name alone, so a style or script element inside SVG or MathML foreign content is parsed with character references decoded yet serialized as an unescaped HTML raw-text element; encoded markup such as </style><img src=x onerror=...> inside <svg><style> therefore closes the element on re-parse and executes. Exploitation is unauthenticated and remote but conditional: the consumer application must parse untrusted HTML with lazy_html, filter the document or tree, and serialize the result to a victim who views it (user interaction required), which keeps real-world impact low (scope change, low confidentiality and integrity, no availability impact); no public exploit identified at time of analysis, and the vendor has shipped a fix in 0.1.13.
Improperly controlled modification of dynamically-determined object attributes in the Ash framework for Elixir (ash 2.17.15 through 3.33.10) lets a caller set private action arguments, declared with public?: false, on the bulk update and bulk destroy code paths. The affected matching logic in Ash.Actions.Destroy.Bulk.base_changeset/5 and Ash.Actions.Update.Bulk.base_changeset/5 compares every key of a caller-supplied parameter map against all of the action's arguments without checking public?, so any application that forwards end-user parameters into Ash.bulk_update/4 or Ash.bulk_destroy/4 (for example via AshJsonApi, AshGraphql, or a controller) can have a private argument injected; when that argument is referenced by an arg(...) template driving authorization, record ownership, or audit metadata, the result is an integrity violation or privilege escalation. The vendor has released a patch in 3.33.11 that requires public? in the bulk argument matching; no public exploit code has been identified at time of analysis, and the impact is conditional on the application both exposing a bulk action to untrusted input and using a security-relevant private argument.
Retained OAuth refresh tokens on hex.pm allow a user whose organization membership or session has ended to keep reading that organization's private packages and documentation tarballs. Refresh tokens are issued with the same issuer, audience and repository:<org> scope claims as access tokens, and the CDN that serves private repositories validates only the JWT signature and time claims, performing no membership lookup and unable to tell the two token types apart, so revocation takes effect only when the 30-day refresh token expires instead of at the 30-minute access-token lifetime. The actor must be an authenticated party who was a member when the token was granted, access is read-only and limited to organizations the account belonged to at grant time, and no public exploit has been identified at time of analysis; CVSS 4.0 base score is 2.3 (independent assessment CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N).
AshAuthentication's token-revocation action accepts forged JWTs without verifying their signature, letting an unauthenticated remote caller write arbitrary rows into the token resource or neutralise an existing revocation. Because the revocation record's expires_at is derived from the attacker-supplied exp claim, an attacker holding a copy of a genuine token can resubmit it with the real jti intact but a backdated exp, producing a revocation row that is already expired; once expunge_expired prunes it, the genuine token validates again through revoked? and logout-based invalidation is defeated. The weakness is confined to token-revocation state in ash_authentication 0.2.0 through 4.14.x and 5.0.0-rc.0 through 5.0.0-rc.13 (CVSS 6.9 per the CVSS 4.0 vector; an independent assessment scores it CVSS 3.1 5.3 with integrity-only impact and no confidentiality or availability loss), and no public exploit identified at time of analysis.
Log forgery in the AshAuthentication Elixir library allows any remote attacker who can reach an application's password-reset request action to inject arbitrary, attacker-controlled lines into the application's logs, including forged severity tags and messages that appear to originate from the application itself. Affected versions are ash_authentication 4.2.0 through 4.14.x and 5.0.0-rc.0 through 5.0.0-rc.13; the flaw is CWE-117 (improper output neutralization for logs) and is rated 6.3 under CVSS v4.0, with the independent assessment settling on CVSS 3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N - an integrity-only, low-impact issue rather than a high-priority emergency. Impact is confined to misleading or forged log records (no confidentiality or availability effect) and materializes only where logs are retained, reviewed, or fed into a SIEM/log-processing pipeline, which is the 'attack requirement beyond the attacker's control' reflected in the AT:P vector component; no public exploit has been identified at time of analysis, though the upstream fix commits are public.
OAuth2 login CSRF affects AshAuthentication, the authentication extension for the Ash framework in Elixir: the OAuth2 callback plug fails to delete the stored session_params value when an authorization attempt fails or is cancelled, so an attacker who learns that value can replay the callback and sign a victim into an attacker-controlled account. The flaw is reachable in ash_authentication 0.6.0 up to (but not including) 4.15.0, and in the 5.0.0-rc.0 through 5.0.0-rc.13 pre-releases, and requires the victim to be induced to replay the callback within the same session before the next request phase or session expiry consumes the value - unauthenticated but dependent on user interaction, per the assessed vector CVSS:3.1/AV:N/AC:H/PR:N/UI:R. Exploitation yields limited confidentiality and integrity impact (login CSRF onto an attacker's account rather than takeover of the victim's account), EPSS and KEV data were not provided, and no public exploit identified at time of analysis; vendor patches are available.
The audit-log add-on in AshAuthentication stores pseudonymised client IP addresses using an unkeyed SHA-256 over a salt concatenated with the IP, truncated to 16 hex characters, so anyone who can already read the audit store can reverse those values back to the original addresses. Exploitation requires two explicit prerequisites: ip_privacy_mode must be set to :hash (the DSL default is :none, so this is an opt-in), and the attacker must already hold read access to the audit log via a database dump, backup, replica, or reader account. Reversal is trivial when the salt is left at the library's published fallback constant 'default-salt-change-in-production', which is used silently with no warning; even a properly configured salt only reduces the problem to 'that salt must leak', after which exhaustive enumeration over the 2^32 IPv4 space is cheap. Per the authoritative assessment this is a low-priority information-disclosure issue (assessed CVSS 3.1 1.8, CWE-760) affecting only client IP addresses with no integrity or availability impact; no public exploit identified at time of analysis, and vendor-released patches exist in 4.15.0 and 5.0.0-rc.14.
The audit_log add-on in the Elixir library AshAuthentication (ash_authentication) writes the full actor record into each audit entry's extra_data field, so the user's hashed_password digest is stored alongside the audit trail in versions from 4.12.0 up to but not including 4.15.0, and from 5.0.0-rc.0 up to but not including 5.0.0-rc.2. There is no network-facing or attacker-triggered disclosure path: entries accumulate from ordinary authenticated activity controlled by benign code, and an attacker's own requests only deposit the attacker's own digest, so exploitation requires that the attacker already hold independent read access to the audit store (database credentials, an audit role, a backup, or a log shipper). The result is exposure of password hashes that support offline cracking of every active account whose actions were audited; the vector is local, high complexity, and privileged (per the assessment PR:H), making this a log-hygiene/defense-in-depth issue rather than an actively exploited one - no public exploit code or CISA KEV entry has been identified at time of analysis, and vendor patches are available.
An authorization bypass in the Ash framework (Elixir) lets authenticated, lower-privileged actors recover values they are not permitted to see by using filtered calculations or aggregates as a yes/no oracle. Ash field policies are designed to protect against filter-based disclosure by rewriting references to forbidden attributes into an expression that evaluates to nil, but prior to 3.33.4 that rewriting only matched Ash.Resource.* structs and not Ash.Query.Calculation or Ash.Query.Aggregate structs, so filters on those ran against real values. Any application that uses Ash.Policy.Authorizer with field policies on calculations or aggregates and exposes filter arguments (commonly via AshGraphql or AshJsonApi) is affected; no public exploit identified at time of analysis, and the disclosure is gradual - one probe at a time - with no integrity or availability impact.
Duplicate-submission gate bypass in the Tempo payment method of ZenHive mpp (versions 0.2.0 through 0.16.1) lets an unauthenticated remote client pass the pre-broadcast dedup reservation twice using a single signed transaction - once with recovery id v=27 and once with v=0 - because the reserve key is derived from the caller-supplied raw transaction hex rather than a canonical form of the transaction. The post-broadcast mark then writes the canonical hash key that the raw-keyed reserve never reads, so the two encodings never collide. Impact is real but bounded and conditional: a node that rejects nonce reuse fails closed and produces no harm, while a node that returns the canonical hash for an already-known transaction can issue a second valid Payment-Receipt for a single on-chain payment; confidentiality and availability are unaffected, and no public exploit code has been identified at time of analysis.
Uncontrolled recursion between Elixir's charlist inspection path and the error-message rescue clause in List.to_string/1 and List.to_charlist/1 can exhaust a BEAM node's memory when an attacker controls list data reaching those functions. A crafted list whose printable prefix exceeds the 4096-element printable_limit but which carries an invalid element beyond that threshold bypasses the ASCII classification check, triggers ArgumentError in IO.chardata_to_string/1, and then recurses infinitely through the rescue clause because the inner inspect/1 call is not in tail position - every frame is retained on the process heap. No public exploit has been identified at time of analysis; vendor-released patches are available as Elixir 1.18.5, 1.19.6, and 1.20.4.
Denial of service in Elixir's standard library Version module (versions 1.5.0 through 1.20.0) allows any caller passing an attacker-controlled version string to exhaust CPU and memory or crash the calling BEAM process. The five public entry points - Version.parse/1, Version.parse!/1, Version.match?/3, Version.compare/2, and Version.parse_requirement/1 - pass numeric version components to :erlang.binary_to_integer/1 without length bounds, triggering super-linear arbitrary-precision integer conversion; a single ~1 MB all-digit component suffices. Applications routinely invoke these functions on untrusted input (HTTP parameters, package metadata), making the effective attack surface broader than the CVSS AV:L classification implies. No public exploit has been identified at time of analysis, and the vulnerability is not listed in CISA KEV.
Elixir 0.8.0 uses Blowfish in CFB mode without constructing a unique initialization vector (IV), which makes it easier for context-dependent users to obtain sensitive information and decrypt the. Rated medium severity (CVSS 4.3), this vulnerability is remotely exploitable. No vendor patch available.