plug_crypto CVE-2026-105963

Requires an Elixir application that (1) calls Plug.Crypto.verify/4 (reachable via Phoenix.Token.verify/4, which forwards the token unguarded, so a controller passing params["token"] is enough), Plug.Crypto.decrypt/4, or Plug.Crypto.secure_compare/2 with a request-controlled operand (e.g. comparing List.first(get_req_header(conn, "x-api-key")) against a configured secret); and (2) runs under an adapter that logs the crash frame with its arguments - Plug.Cowboy or Bandit - while that log or crash_reason metadata is forwarded to an error tracker or stored unencrypted. Triggering needs no authentication and no user interaction (a wrong-typed param like token[]=x, a JSON token value, or a simply missing x-api-key header that yields nil). The decisive limiting factor is that the triggering request does not disclose the secret to the attacker: a separate party must have read access to the logs or error tracker, which is why the vector uses PR:H despite the unauthenticated trigger. Applications on plug_crypto >=2.2.1 and plug >=1.7.0 are not affected.

The CVSS 4.0 base score of 5.1 (medium) with vector AV:N/AC:L/AT:N/PR:H/UI:N/VC:L reflects a genuine but constrained risk. An unauthenticated network request carrying a wrong-typed parameter is enough to trigger the leak (a low-complexity trigger), but the vendor scored PR:H because actually reading the leaked secret requires separate privileged access to the application logs or error tracker. This two-actor split is the central tension: the description states an 'unauthenticated remote attacker' can trigger the FunctionClauseError, yet the disclosed secret only reaches someone who can read log/error-tracker output, so the request alone does not hand the secret to the triggering attacker - verify how your logs are protected and forwarded before rating this as a remote-read issue. No EPSS score was provided and the CVE is not in CISA KEV, so there is no signal of active or widespread exploitation; the vuln.today decision label is 'this_month', consistent with scheduled patching rather than emergency response. Exploitation status: no public exploit identified at time of analysis (only advisory and patch-commit references are present, not exploit code). The factor that raises real-world stakes above the modest score is the sensitivity of the disclosed data - the secret key base is sufficient to mint session cookies and tokens under any salt - so environments that forward logs to third-party error trackers or store them unencrypted should prioritize the fix.

An attacker sends one unauthenticated request to a Phoenix/Plug application - for example 'token[]=x' in a query string so params["token"] becomes a list, a JSON body making it an integer or map, or simply omitting an 'x-api-key' header so secure_compare receives nil. The wrong-typed argument fails a Plug.Crypto function-head guard, the Erlang VM raises FunctionClauseError with the real argument values in the top stack frame, and Plug.Cowboy or Bandit write the secret key base (or the configured value an API key is compared against) into the error log and crash_reason Logger metadata. A party with read access to those logs or the forwarded error tracker then recovers the secret; no public exploit code was identified.