CVE-2026-111367 in BillionMail
Summary
by MITRE • 10/16/2026
BillionMail through 4.9 contains a hard-coded cryptographic key vulnerability that allows unauthenticated attackers to forge unsubscribe and subscribe-confirm JWTs by computing the key from shipped configuration constants. Attackers can submit forged tokens to /api/unsubscribe, /api/unsubscribe_new, or /api/subscribe/confirm to deactivate any contact or force confirmed subscriptions.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/16/2026
The vulnerability identified in BillionMail versions up to 4.9 represents a critical failure in cryptographic key management that fundamentally undermines the integrity of authentication and authorization mechanisms within the application. At its core, this flaw is classified as CWE-798: Use of Hard-coded Credentials, where sensitive security material such as signing keys for JSON Web Tokens (JWTs) are embedded directly into the source code or configuration files rather than being generated dynamically at runtime or stored in a secure key management system. This architectural decision exposes the cryptographic secret to any individual with access to the application's deployment artifacts, including compiled binaries, configuration scripts, or version control repositories. Because the key is derived from shipped configuration constants that are static and predictable, it lacks entropy and secrecy, rendering the security boundary provided by JWT signing effectively non-existent for external actors who can inspect these files.
From a technical perspective, JSON Web Tokens rely on asymmetric or symmetric cryptography to ensure that claims within the token have not been tampered with during transit. In this specific instance, the application uses HMAC-based signatures where the secret key is known because it is hardcoded into the software distribution. An unauthenticated attacker can reverse-engineer these constants from the deployed environment to reconstruct the exact signing key used by the server. Once the attacker possesses this key, they are no longer bound by the limitations of being an external observer; they gain the ability to arbitrarily generate valid JWTs for any user or action without needing legitimate credentials. This capability allows the adversary to craft tokens that appear authentic to the backend API endpoints because the signature verification process will pass successfully using the stolen key.
The operational impact of this vulnerability is severe and directly affects the availability and integrity of email subscription services managed by BillionMail. By forging unsubscribe confirmations, an attacker can target specific contact identifiers embedded in valid-looking JWTs sent to endpoints such as /api/unsubscribe or /api/unsubscribe_new. This results in the unauthorized deactivation of legitimate user subscriptions, causing service disruption for intended recipients who suddenly stop receiving critical communications. Conversely, by crafting forged subscribe-confirm tokens and submitting them to /api/subscribe/confirm, an attacker can force unwanted confirmations on arbitrary email addresses. This leads to spamming issues where victims are added to mailing lists without their consent, potentially exposing the organization to compliance violations regarding unsolicited commercial email regulations such as CAN-SPAM or GDPR. The ability to manipulate these states at scale means that a single compromised instance could be used to disrupt communication channels for thousands of users simultaneously.
This vulnerability aligns with several entries in the MITRE ATT&CK framework, specifically T1078: Valid Accounts and T1529: System Shutdown or Reboot if viewed through the lens of service disruption, though more accurately it falls under privilege escalation via token forgery which is often associated with T1499: Endpoint Denial of Service when used to disrupt services. The root cause maps directly to CWE-798 as noted previously, and also touches upon CWE-320: Key Exchange Using Incorrect Hash Function if the derivation process involves weak hashing algorithms alongside the hardcoding issue. To mitigate this risk immediately, organizations must rotate all JWT signing keys across their BillionMail instances. However, a permanent fix requires refactoring the application to generate unique, high-entropy cryptographic keys for each deployment instance at runtime or during initialization from a secure operating system entropy source like /dev/urandom. These keys should never be stored in plaintext within configuration files accessible via version control or file systems readable by non-root users. Additionally implementing strict input validation and rate limiting on subscription endpoints can provide defense-in-depth, although it does not replace the need for proper key management practices to ensure true authentication integrity.