Bytes::Random::Secure::Tiny CVE-2026-11702

Exploitation requires the target application to initialize a Bytes::Random::Secure::Tiny object BEFORE calling fork() and to reuse that single object across child processes - the classic preforking server pattern; applications that create the generator per-process after forking, or that never fork, are not affected. The attacker further needs to observe enough output from one process to predict the identical stream other processes produce. Limiting factors: it depends entirely on this non-default-by-accident coding pattern, requires the module's output to be used for security-relevant secrets, and threaded (non-fork) deployments are explicitly out of scope since a new thread keeps the same $$.

Signals are mixed and should not be over-weighted by the 7.5/High CVSS alone. The NVD vector (AV:N/AC:L/PR:N/UI:N/C:H) treats this as a trivially network-exploitable confidentiality break, but that framing is generous: exploitation is contingent on a specific victim coding pattern - instantiating the generator before forking - and on an attacker being able to observe and predict one worker's output to anticipate another's, which is closer to high attack complexity than low. EPSS (0.16%, percentile 5%) and the absence of KEV listing or any POC reinforce that real-world opportunistic exploitation is unlikely; the practical risk is concentrated in applications that both use this module in the vulnerable init-before-fork pattern and rely on its output for security tokens. This is a genuine cryptographic correctness defect worth patching, but it is a 'deployment-dependent, predict-the-stream' issue rather than a drop-everything, mass-exploited bug. Note a data inconsistency: one of the referenced CVE records is CVE-2026-41564, which should be verified against the intended advisory.

A preforking Perl web application creates one Bytes::Random::Secure::Tiny generator at startup, then forks N workers that each serve requests; because every worker inherited identical PRNG state, an attacker who obtains the session token issued by their own worker can predict the tokens other workers issue to other users. No public POC is identified, but the prediction is deterministic once the shared seed's output is observed, making session hijacking or secret forgery feasible against a vulnerable deployment.