BillionMail EUVD-2026-102507

No special conditions beyond running a default BillionMail instance at version 4.9 or earlier with its shipped configuration: the JWT signing key is computed from configuration constants distributed in the project's config.yaml, so standard installations are vulnerable out of the box with no attacker authentication (PR:N) and no user interaction. Exploitation requires the /api/unsubscribe, /api/unsubscribe_new, or /api/subscribe/confirm endpoints to be network-reachable, and to target a specific victim the attacker needs the relevant contact/subscription identifier (e.g. email address). The practical limiting factor is impact scope - only unsubscribe/subscribe-confirm subscription state can be manipulated, not authentication, code execution, or stored data.

This is a genuine but moderate-priority issue rather than a critical one. The CVSS 4.0 base score of 6.9 (medium) is consistent with the attack profile: AV:N/AC:L/AT:N/PR:N/UI:N means a remote, unauthenticated attacker can exploit default installations with low complexity and no user interaction, because the JWT signing key is deterministically derivable from configuration constants shipped in the repository (config.yaml) and consumed by jwt.go. However, impact is deliberately scoped low - VC:N (no confidentiality loss), with VI:L and VA:L - reflecting that forged tokens only manipulate subscription state (deactivating contacts, forcing confirmed subscriptions), not code execution, data theft, or account takeover. No EPSS score and no CISA KEV entry are present in the input, so there is no signal of active or widespread exploitation; this reads as a researcher-disclosed flaw (reported by VulnCheck) rather than an observed in-the-wild campaign. A detailed public technical writeup (hackmd) documents how to compute the key, which materially lowers the practical barrier even though no packaged exploit is flagged in the input. Net: patch promptly on any internet-facing BillionMail deployment because exploitation is trivial and unauthenticated, but the limited integrity/availability impact keeps this below the urgency of an RCE or authentication bypass.

An attacker reads BillionMail's publicly shipped configuration constants, reconstructs the deterministic JWT signing key, and forges valid unsubscribe or subscribe-confirm tokens for arbitrary contacts. They then POST the forged tokens to /api/unsubscribe, /api/unsubscribe_new, or /api/subscribe/confirm to deactivate legitimate contacts or force confirmed subscriptions. A public technical writeup already details the key-derivation and forgery method, so the exploitation path is low-complexity, remote, and unauthenticated.