elixir-plug CVE-2026-56813

Exploitation requires that the target application passes attacker-influenced data - such as a user-supplied username, locale preference, redirect path, or any other externally sourced value - directly into the value or optional attribute parameters (path, domain, same_site, extra) of Plug.Conn.put_resp_cookie/4. Applications that set only server-generated constants or values derived entirely from trusted internal sources in cookies are not vulnerable regardless of Plug version. HTTP response splitting is explicitly ruled out because Plug's existing header validation rejects CRLF and null bytes; only ;-delimited attribute injection is in scope. The CVSS 4.0 AT:P metric confirms this is a conditional vulnerability gated on the application's cookie-handling pattern, not universally exploitable against all Plug or Phoenix deployments.

The CNA-assigned CVSS 4.0 score of 2.1 (AV:L/AC:L/AT:P/PR:N/UI:N) appears to underrepresent network reachability: the practical attack path is HTTP-based, not local system access, suggesting AV:L may reflect conservative scoring of a server-side code-quality issue rather than directly network-exploitable behavior. The AT:P metric correctly captures the critical limiting factor - only applications routing attacker-controlled data into put_resp_cookie/4 parameters are exploitable, and this is not a default behavior. EPSS data is absent from the provided intelligence; no KEV listing and no referenced POC indicate no confirmed active exploitation at time of analysis. Integrity impact is low (cookie scope manipulation, session fixation) with no confidentiality or availability impact, consistent with the VI:L/SI:L CVSS 4.0 scoring. Real-world priority is primarily a code-audit question: teams should grep for put_resp_cookie calls that consume user input and upgrade to the patched version, but applications with server-generated static cookie values are not at risk regardless of Plug version.

An attacker registers an account with a crafted username such as alice; Domain=.attacker.com; Secure=false and triggers an application flow where that value is reflected into a session cookie via put_resp_cookie. Because Cookies.encode/2 interpolates the value without sanitizing ;, the resulting Set-Cookie header includes the injected Domain attribute, causing the victim's browser to store the cookie with widened domain scope. The attacker can then perform cookie tossing, presenting a forged session cookie to the legitimate server and achieving session fixation with no public POC confirmed at time of analysis.