CVE-2026-118986 in CallBackery
Summary
by MITRE • 10/30/2026
CallBackery versions before 0.62.0 for Perl allow session cookie forgery via a signing secret generated with rand().
The secret that signs session cookies is built from two calls to the built-in rand(), which is seeded with 32 bits. The secret therefore has at most 2**32 possible values, and one signed cookie is enough to test each candidate offline.
An attacker who obtains a single session cookie can recover the secret and sign cookies for any user, including an administrator.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/30/2026
The vulnerability in CallBackery versions prior to 0.62.0 represents a critical failure in cryptographic key management due to the use of insufficient entropy sources for generating signing secrets. The application relies on Perl's built-in rand() function to construct the secret used for signing session cookies, which is essential for ensuring the integrity and authenticity of user sessions. Specifically, the implementation utilizes two calls to this pseudo-random number generator, resulting in a combined seed space derived from 32 bits of entropy. This design choice fundamentally undermines the security model because modern cryptographic standards require secrets with significantly higher entropy levels to resist brute-force attacks. The use of rand() is particularly problematic as it was historically designed for statistical simulations rather than cryptographic purposes and lacks the necessary unpredictability required for secure key generation.
From a technical perspective, the core flaw lies in the limited size of the keyspace available to an attacker. With only 32 bits of entropy, there are at most four billion possible secret values. This is computationally trivial to exhaust using modern hardware capabilities. An adversary who intercepts or obtains a single valid signed session cookie can leverage this information to perform an offline brute-force attack against the signing algorithm. By testing each candidate key from the 32-bit space against the known plaintext and signature of the stolen cookie, the attacker can quickly identify the correct secret. Once the secret is recovered, the attacker gains the ability to forge valid signatures for any session token without needing further access to the server or additional user credentials.
The operational impact of this vulnerability is severe, leading directly to a complete compromise of authentication mechanisms and potential full account takeover. Since the signing key allows an attacker to create arbitrary signed cookies, they can impersonate any user within the system. This includes escalating privileges by forging session tokens for administrative accounts, thereby bypassing access controls entirely. The attack does not require network interception if the victim's cookie is exposed through other means such as cross-site scripting or log leakage, but even in a purely remote context where cookies are transmitted over encrypted channels, the weakness of the key generation process remains exploitable once any single token is observed. This aligns with CWE-330, which classifies this issue under the use of insufficiently random values, and maps to MITRE ATT&CK technique T1528, indicating that an attacker can obtain application access tokens through weak cryptographic implementations or key management failures.
To mitigate this vulnerability, immediate updates to CallBackery version 0.62.0 or later are required, as the developers have addressed the underlying issue by replacing the insecure random number generator with a cryptographically secure alternative. In environments where upgrading is not immediately feasible, administrators should enforce frequent rotation of session secrets and ensure that any secret generation process utilizes operating-system-level entropy sources such as /dev/urandom on Unix-like systems or CryptGenRandom on Windows. It is also critical to audit the codebase for other instances where Perl's rand() might be used in security-sensitive contexts. Implementing strict input validation and monitoring for anomalous session activity can provide additional layers of defense, although these measures do not replace the need for fixing the root cause by employing robust cryptographic primitives compliant with current industry standards like NIST SP 800-131A regarding key strength requirements.