CVE-2026-75870 in Punk
Summary
by MITRE • 08/22/2026
Punk versions before 0.18 for Perl allow session cookie forgery via an empty default HMAC key when a session is declared without a secret.
The session keyword freezes its options onto the application as given: it does not require a secret, warn, or refuse to start when one is absent. The cookie read and the write-back both default that key to the empty string, so a declaration with no secret option, or with an undefined or empty one, signs and verifies with a zero-length HMAC-SHA256 key.
An attacker who knows the cookie format can then mint one offline carrying any contents the session holds, such as a user identifier or a role. Nothing marks the misconfiguration at runtime: cookies are well formed and sessions round-trip as expected.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/22/2026
The vulnerability identified in Perl Punk versions prior to 0.18 represents a critical failure in cryptographic key management within the session handling mechanism, specifically classified under CWE-327 which denotes the use of a broken or risky cryptographic algorithm due to weak implementation practices. The core technical flaw stems from the design decision where the session keyword freezes its configuration options onto the application without enforcing mandatory security parameters such as a secret key for HMAC signing. When a developer declares a session without providing an explicit secret, or provides one that is undefined or empty, the system defaults this cryptographic key to an empty string rather than raising a warning or refusing initialization. This behavior creates a scenario where the integrity verification process relies on an HMAC-SHA256 operation using a zero-length key, which fundamentally undermines the security guarantees provided by the hash-based message authentication code algorithm.
From an operational perspective, this misconfiguration allows for complete session cookie forgery with minimal effort from an attacker. Because the signing and verifying processes both utilize the same empty default key, any party that understands the structure of the Punk session cookies can generate valid signatures offline without access to server-side secrets or computational resources typically required to break strong encryption. An adversary can craft a malicious cookie containing arbitrary data, such as elevated user identifiers, administrative roles, or other sensitive state information, and submit it to the application. The server will accept this forged token because its signature validates correctly against the empty key used during creation. This bypasses authentication controls entirely, allowing unauthorized access to protected resources and potentially leading to full account takeover depending on how session data is mapped to user privileges within the specific web framework implementation.
The impact of this vulnerability extends beyond simple privilege escalation; it also facilitates persistent identity spoofing and potential data integrity violations across all sessions that rely on default configurations. Since there are no runtime markers or warnings indicating that a weak key is in use, security audits may overlook these instances if they do not explicitly inspect the session initialization code for missing secret parameters. Cookies generated under this condition appear well-formed to standard validation logic, and sessions round-trip as expected from the application's perspective, making detection through automated scanning tools difficult without specific knowledge of the underlying cryptographic weakness. This lack of visibility means that applications deployed with default settings remain vulnerable indefinitely unless manually corrected by developers who are aware of the requirement for a strong, random secret key.
Mitigation strategies must focus on enforcing strict configuration policies and updating to patched versions where this behavior has been addressed. The primary remediation is to upgrade Punk to version 0.18 or later, which likely introduces safeguards against empty keys or mandates explicit secret provision during session initialization. For environments unable to immediately patch, developers should audit all session declarations to ensure a strong, randomly generated secret key is explicitly provided and never left undefined or empty. Implementing defense-in-depth measures such as input validation on cookie contents can provide limited additional protection but does not resolve the root cause of weak cryptographic signing. Furthermore, security teams should incorporate checks for missing critical configuration parameters into their static analysis tools to prevent similar misconfigurations in other frameworks that may exhibit analogous weaknesses. This incident highlights the importance of failing securely by refusing operation when essential security prerequisites are unmet rather than defaulting to insecure states.