CVE-2026-13575 in HTTP::Session
Summary
by MITRE • 11/01/2026
HTTP::Session versions before 0.54 for Perl allow memcached command injection via unfiltered session ids in HTTP::Session::Store::CHI.
The session id from the client's cookie reaches the CHI cache unchanged. The sibling HTTP::Session::Store::Memcached rejects ids that contain control characters, but the CHI store has no such check, and CHI does not escape keys for its memcached drivers.
With a memcached driver, a CR and LF in the session id end the cache command early, and the server reads the bytes after them as further commands.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 11/02/2026
The vulnerability identified in HTTP::Session versions prior to 0.54 represents a critical security flaw within the Perl web application framework ecosystem, specifically affecting the interaction between session management modules and backend caching systems. This issue is rooted in the implementation of HTTP::Session::Store::CHI, which serves as an interface for storing session data using the CHI cache abstraction layer. When utilizing memcached as the underlying storage driver, the system fails to properly sanitize or validate input received from client-side cookies before passing it into the cache key structure. This lack of validation allows attackers to inject arbitrary commands directly into the memcached protocol stream by manipulating the session identifier contained in HTTP cookies. The core technical failure lies in the disparity between different store implementations within the module; while HTTP::Session::Store::Memcached explicitly rejects identifiers containing control characters, its sibling implementation using CHI does not perform this check and relies on CHI to handle key escaping for memcached drivers. However, CHI itself does not escape keys when communicating with memcached servers, leaving a direct injection path open.
From a technical perspective, the exploitation of this vulnerability leverages the structure of the Memcached text protocol, which uses carriage return (CR) and line feed (LF) characters to delimit commands. Because the session ID is used directly as part of the cache key without sanitization, an attacker can embed CR and LF sequences within the cookie value. When these values are processed by CHI and sent to the memcached server, the embedded control characters prematurely terminate the intended SET or GET command. The subsequent bytes in the request stream are then interpreted by the memcached server as new commands rather than part of the original key data. This mechanism effectively allows an unauthenticated remote attacker to execute arbitrary memcached commands on the backend infrastructure. Such actions could include retrieving sensitive session data from other users, deleting critical cache entries to cause denial of service, or potentially leveraging further vulnerabilities within the application logic that relies on cached state for security decisions.
The operational impact of this vulnerability is severe due to its potential for remote code execution and data exfiltration through the caching layer. Since memcached often holds session tokens, authentication states, and other sensitive user information, an attacker who successfully injects commands can manipulate or extract this data without needing direct database access. Furthermore, if the application logic assumes that cached values are trustworthy and unmodified by external parties, command injection could lead to broader system compromise depending on how the retrieved or modified cache entries influence subsequent application behavior. This flaw aligns with CWE-78 Improper Neutralization of Special Elements used in an OS Command (OS Injection) as it involves injecting commands into a backend service via user-controllable input. It also maps to ATT&CK technique T1504 Weak or Compromised Cache, where attackers manipulate cache storage to disrupt availability or steal information.
Mitigation strategies must focus on immediate patching and defensive coding practices. The primary remediation is to upgrade HTTP::Session to version 0.54 or later, which addresses the validation gap in CHI stores by ensuring that session identifiers are properly sanitized before being passed to the cache layer. In environments where upgrading is not immediately feasible, developers should implement a custom store wrapper that explicitly filters out control characters such as CR and LF from any input derived from client cookies before it reaches the caching mechanism. Additionally, network-level controls can be employed to restrict direct access to memcached ports from web server hosts if possible, although this is often impractical in tightly coupled architectures. Regular security audits of session management implementations are recommended to ensure that all data flowing into cache keys undergoes rigorous validation against expected character sets and lengths.