Cloudanix VulnDB

CVE-2025-47934

None

CVSS

—

EPSS

0.6%

Published

May 19, 2025

CISA due date

—

Cloudanix analysis

Monitor only SSVC: Track

A library used to check digital signatures on encrypted messages could be tricked into saying a tampered message was genuine, allowing attackers to substitute different content while the check still passes.

Exploitation
Remote Unauthenticated
Attacker needs
None
Complexity
Low
Impact
Data Tampering
Component
Library
Class
Cryptographic Weakness
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

A maliciously modified inline-signed or signed-and-encrypted OpenPGP message causes openpgp.verify or openpgp.decrypt (with verificationKeys) to return a successful signature verification result paired with attacker-chosen data instead of the originally signed content.

Why it matters to the business

Organizations relying on OpenPGP.js for message integrity checks may accept tampered data as authentic, undermining trust in signed communications and potentially enabling unauthorized data substitution in workflows that process inline or signed-and-encrypted messages.

How an attack unfolds

An attacker obtains one valid signature (inline or detached) and the corresponding plaintext, then crafts a new inline-signed message or signed-and-encrypted message containing arbitrary data. When the victim processes the crafted message with the affected library, the verification functions incorrectly report the signature as valid for the attacker-supplied data.

How to fix it

Upgrade openpgpjs/openpgpjs to the commit b9edc546a7f933d732aeb41e36840c3751787433 (versions 5.11.3 or 6.1.1). If immediate upgrade is not possible, implement the provided workarounds: extract signatures and verify them as detached signatures using openpgp.readMessage followed by openpgp.verify with a freshly created message, or perform decryption without verificationKeys then separately verify the returned signatures against the decrypted data.

How to confirm the fix worked

Confirm the library version reports 5.11.3 or newer (or commit b9edc546a7f933d732aeb41e36840c3751787433). Test with a known-good inline-signed message containing modified payload to ensure verification now fails. Review code paths that call openpgp.verify or openpgp.decrypt with verificationKeys for inline messages.

Typical attack path

  1. Obtain a legitimate signature and the data it covers
  2. Construct an inline-signed or signed-and-encrypted message embedding the attacker's chosen payload with the stolen signature
  3. Deliver the crafted message to the target application
  4. Trigger openpgp.verify or openpgp.decrypt with verificationKeys on the message
  5. Receive a successful verification result paired with the attacker's payload

How to detect it

Review application logs for calls to openpgp.verify or openpgp.decrypt on messages that were later found to contain unexpected content. Examine message processing code and any stored OpenPGP artifacts for signs of inline-signed messages that were accepted despite content mismatches.

What your security team should do

  • Prioritize upgrade to the fixed commit across all environments using OpenPGP.js for signature verification
  • Audit applications for use of openpgp.verify and openpgp.decrypt with inline or signed-and-encrypted messages
  • Apply the documented workarounds where upgrades cannot be completed immediately
  • Monitor upstream for any additional patches or advisory updates

The record

OpenPGP.js is a JavaScript implementation of the OpenPGP protocol. Startinf in version 5.0.1 and prior to versions 5.11.3 and 6.1.1, a maliciously modified message can be passed to either `openpgp.verify` or `openpgp.decrypt`, causing these functions to return a valid signature verification result while returning data that was not actually signed. This flaw allows signature verifications of inline (non-detached) signed messages (using `openpgp.verify`) and signed-and-encrypted messages (using `openpgp.decrypt` with `verificationKeys`) to be spoofed, since both functions return extracted data that may not match the data that was originally signed. Detached signature verifications are not affected, as no signed data is returned in that case. In order to spoof a message, the attacker needs a single valid message signature (inline or detached) as well as the plaintext data that was legitimately signed, and can then construct an inline-signed message or signed-and-encrypted message with any data of the attacker's choice, which will appear as legitimately signed by affected versions of OpenPGP.js. In other words, any inline-signed message can be modified to return any other data (while still indicating that the signature was valid), and the same is true for signed+encrypted messages if the attacker can obtain a valid signature and encrypt a new message (of the attacker's choice) together with that signature. The issue has been patched in versions 5.11.3 and 6.1.1. Some workarounds are available. When verifying inline-signed messages, extract the message and signature(s) from the message returned by `openpgp.readMessage`, and verify the(/each) signature as a detached signature by passing the signature and a new message containing only the data (created using `openpgp.createMessage`) to `openpgp.verify`. When decrypting and verifying signed+encrypted messages, decrypt and verify the message in two steps, by first calling `openpgp.decrypt` without `verificationKeys`, and then passing the returned signature(s) and a new message containing the decrypted data (created using `openpgp.createMessage`) to `openpgp.verify`.

Affected packages

Ecosystem Package Introduced Fixed
npm openpgp 5.0.1 5.11.3
npm openpgp 6.0.0-alpha.0 6.1.1
Chainguard kibana-8 0 8.18.2-r0
Chainguard kibana-8-bitnami 0 8.18.2-r0
Chainguard kibana-8-iamguarded 0 8.18.2-r0
Chainguard kibana-9 0 9.0.2-r0
Chainguard kibana-9-bitnami 0 9.0.2-r0
Chainguard kibana-9-iamguarded 0 9.0.2-r0
Chainguard renovate 0 40.26.1-r0
Wolfi renovate 0 40.26.1-r0

Related vulnerabilities