Skip to main content
VulnerabilityPublished

CVE-2025-15618: MOCK Business::OnlinePayment::StoredTransaction · Use of Cryptographically Weak Pseudo-Random Number Generator

Affects MOCK Business::OnlinePayment::StoredTransactionSource CVE Database V5

0
Compare

Not known to be exploited · CVSS 9.1 Critical.

Data as of 30 Oct 2026, 11:52 UTC

CVSS 3.1 base score
9.1Critical
How severe the flaw is on the 0–10 CVSS scale.

Contested

Critical score, yet low EPSS after six months
EPSS
0.3% chance of exploitation in 30 days – higher than 26% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 31 Mar 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponized: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 30 Oct 2026.

What to do

Affected software

ProductAffectedFixed in
MOCKBusiness::OnlinePayment::StoredTransactionAffected
  • <=0.01
Fixed in–

AI-suggested

To mitigate this vulnerability, organizations should immediately cease using Business::OnlinePayment::StoredTransaction versions up to 0.01 for encrypting sensitive data. Developers should update the module to use a cryptographically secure pseudo-random number generator (CSPRNG), such as those provided by Perl's Crypt::PRNG or the operating system's secure random sources (e.g., /dev/urandom or Crypt::Random). The key derivation process should employ modern, secure algorithms like HKDF or PBKDF2 with appropriate salts and iteration counts instead of MD5 hashing. Additionally, organizations should audit stored encrypted data and consider re-encrypting with securely generated keys. Implementing comprehensive logging and monitoring for unusual access patterns to payment data can help detect exploitation attempts. Finally, educating developers on secure cryptographic practices and regularly reviewing third-party dependencies for vulnerabilities is essential to prevent similar issues.

Description

Business::OnlinePayment::StoredTransaction versions through 0.01 for Perl uses an insecure secret key. Business::OnlinePayment::StoredTransaction generates a secret key by using a MD5 hash of a single call to the built-in rand function, which is unsuitable for cryptographic use. This key is intended for encrypting credit card transaction data.

References

Community reviews

Loading reviews…