EUVD-2026-39640
GHSA-r57w-h3mc-4jrv
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
Predictable secrets can be exploited remotely (AV:N) but only when the app uses the pre-fork/functional pattern and the attacker correlates streams, raising complexity (AC:H); high confidentiality impact, no integrity/availability effect.
Primary rating from Vendor (CPANSec).
CVSS VectorVendor: CPANSec
Lifecycle Timeline
4DescriptionCVE.org
Bytes::Random::Secure versions through 0.29 for Perl share internal state across forked processes.
When an object is initialised before forking, or when the functional interface is used, then the internal state for the PRNG is shared across processes and identical random streams will be produced.
Secrets generated in multiprocess applications are predictable across processes.
AnalysisAI
Predictable secret generation in the Perl module Bytes::Random::Secure (versions through 0.29) occurs because the module fails to detect process forks, causing parent and child processes to share identical PRNG internal state. Applications that instantiate a generator object before fork()ing - or that use the module's functional (procedural) interface - will emit identical random streams across processes, making session tokens, keys, salts, and other secrets predictable across workers. No public exploit is identified at time of analysis, and EPSS is low (0.16%, 6th percentile); CPANSec reported it and an upstream fix is available.
Technical ContextAI
Bytes::Random::Secure is a CPAN module that wraps a CSPRNG (Math::Random::ISAAC seeded via Crypt::Random::Seed) to provide cryptographically secure random bytes for Perl applications. The flaw is a classic CWE-335 (Incorrect Usage of Seeds / improper PRNG re-seeding) condition tied to Unix process forking: when a process calls fork(), the child inherits an exact copy of the parent's memory, including the already-seeded ISAAC state. Because the module cached the RNG object (the internal _RNG handle) without tracking the process ID that created it, both processes continued advancing from the identical seeded state and therefore produced the same byte sequence. The PR diff confirms the root cause and fix: the patch records $self->{_pid} = $$ at build/instantiation and re-instantiates the RNG whenever $$ (current PID) no longer matches the stored PID, forcing a fresh re-seed in each forked child.
RemediationAI
Apply the upstream fix that adds fork/PID detection so the RNG is re-seeded in each child process; the patch is published at https://security.metacpan.org/patches/B/Bytes-Random-Secure/0.29/CVE-2026-11625-r1.patch and corresponds to pull request https://github.com/daoswald/Bytes-Random-Secure/pull/4 - upgrade to the patched release once it is published to CPAN (a fix is available per vendor advisory, though a specific tagged release version is not stated in the provided data, so verify the fixed version on MetaCPAN before pinning). As an immediate code-level workaround without upgrading, do not instantiate Bytes::Random::Secure objects before forking and avoid the functional interface in preforking servers: create a new generator (or call srand-equivalent re-seed) inside each child after fork, accepting the minor cost of per-child seeding entropy; alternatively, rotate to a fork-safe CSPRNG source for secret generation. Track remediation against the issue and PR at https://github.com/daoswald/Bytes-Random-Secure/issues/3 and https://github.com/daoswald/Bytes-Random-Secure/pull/4.
Integer overflow in the Bytes library versions 1.2.1 through 1.11.0 allows attackers to corrupt the BytesMut capacity va
Predictable secret generation in the Perl module Bytes::Random::Secure::Tiny (versions through 1.011) occurs because a P
Same technique Information Disclosure
View allVendor StatusVendor
SUSE
Severity: ImportantShare
External POC / Exploit Code
Leaving vuln.today