Skip to main content
No exploitation reportedFix available

CVE-2023-41037

No exploitation reported by the sources we read.

  • Published2023-08-29
  • Fixed in5.10.1 · 5.10.0 · 4.10.11
  • WeaknessCWE-347

Am I affected?

With a domain, we read the version its public headers and pages expose. A distribution build can carry the fix under an older number.

Description

OpenPGP.js is a JavaScript implementation of the OpenPGP protocol. In affected versions OpenPGP Cleartext Signed Messages are cryptographically signed messages where the signed text is readable without special tools. These messages typically contain a "Hash: ..." header declaring the hash algorithm used to compute the signature digest. OpenPGP.js up to v5.9.0 ignored any data preceding the "Hash: ..." texts when verifying the signature. As a result, malicious parties could add arbitrary text to a third-party Cleartext Signed Message, to lead the victim to believe that the arbitrary text was signed. A user or application is vulnerable to said attack vector if it verifies the CleartextMessage by only checking the returned `verified` property, discarding the associated `data` information, and instead _visually trusting_ the contents of the original message. Since `verificationResult.data` would always contain the actual signed data, users and apps that check this information are not vulnerable. Similarly, given a CleartextMessage object, retrieving the data using `getText()` or the `text` field returns only the contents that are considered when verifying the signature. Finally, re-armoring a CleartextMessage object (using `armor()` will also result in a "sanitised" version, with the extraneous text being removed. This issue has been addressed in version 5.10.1 (current stable version) which will reject messages when calling `openpgp.readCleartextMessage()` and in version 4.10.11 (legacy version) which will will reject messages when calling `openpgp.cleartext.readArmored()`. Users are advised to upgrade. Users unable to upgrade should check the contents of `verificationResult.data` to see what data was actually signed, rather than visually trusting the contents of the armored message.

Timeline

dates in UTC
  1. 2023-08-2917:15CVE publishedNVD

Versions per branch

OSV · NVD
Openpgpjs
BranchAffectedFixed in
5.x≥ 5.0.0, < 5.10.15.10.1
5.x≥ 5.0.0, < 5.10.05.10.0
4.10< 4.10.114.10.11

as publishedRanges as NVD and OSV publish them; a distribution’s build can be fixed under an older number.

Products declared by the CNA1 product

As GitHub_M, the CNA that assigned this CVE, declared them in the CVE record; versions as written.

  • openpgpjs
    Affected
    • = < 4.10.11no fix stated
    • = >= 5.0.0, < 5.10.1no fix stated

Source: the CNA record (CVE Program), © The MITRE Corporation,CVE Terms of UseCVE recordupdated 2023-08-29

Fix

  1. Update Openpgpjs to 5.10.1 · 5.10.0 · 4.10.11

Advisories and patches

Detection

Nuclei template
none so far
ProjectDiscovery
Exploit-DB
no entry
Exploit-DB
Proof of concept
Metasploit modules
none listed
Metasploit Framework

Sources

  • CISA-ADPSSVC decisionnone2024-09-30
  • CNACVSS 3.14.3known since 2026-10-23
  • NVDCVSS 3.14.3read 2026-10-23
  • CNAweakness (CWE)CWE-347known since 2026-10-23
  • FIRST EPSSEPSS score0.4 %2026-11-09
  • OSVaffected packages—
  • GitHub AdvisoriesadvisoryMODERATE2023-08-29

Identifiers

Technical details

CVSS v3 Vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N
Published
2023-08-29
Last Modified
2026-06-17
NVD status
Modified
GitHub Advisory
GHSA-ch3c-v47x-4pgp

Frequently asked questions

What is CVE-2023-41037?

OpenPGP.js is a JavaScript implementation of the OpenPGP protocol. In affected versions OpenPGP Cleartext Signed Messages are cryptographically signed messages where the signed text is readable without special tools. These messages typically contain a "Hash: ..." header declaring the hash algorithm used to compute the signature digest. OpenPGP.js up to v5.9.0 ignored any data preceding the "Hash: ..." texts when verifying the signature. As a result, malicious parties could add arbitrary text to a third-party Cleartext Signed Message, to lead the victim to believe that the arbitrary text was signed. A user or application is vulnerable to said attack vector if it verifies the CleartextMessage by only checking the returned `verified` property, discarding the associated `data` information, and instead _visually trusting_ the contents of the original message. Since `verificationResult.data` would always contain the actual signed data, users and apps that check this information are not vulnerable. Similarly, given a CleartextMessage object, retrieving the data using `getText()` or the `text` field returns only the contents that are considered when verifying the signature. Finally, re-armoring a CleartextMessage object (using `armor()` will also result in a "sanitised" version, with the extraneous text being removed. This issue has been addressed in version 5.10.1 (current stable version) which will reject messages when calling `openpgp.readCleartextMessage()` and in version 4.10.11 (legacy version) which will will reject messages when calling `openpgp.cleartext.readArmored()`. Users are advised to upgrade. Users unable to upgrade should check the contents of `verificationResult.data` to see what data was actually signed, rather than visually trusting the contents of the armored message.

Is CVE-2023-41037 actively exploited?

Active exploitation of CVE-2023-41037 has not been confirmed. Its EPSS score was 0.4% on 2026-11-09, the estimated probability of exploitation in the next 30 days.

What is the CVSS score for CVE-2023-41037?

CVE-2023-41037 has a CVSS v3 base score of 4.3 (MEDIUM severity), with vector string CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N.

Running openpgp? Hear about its next vulnerability

Surveillance reads the versions in your stack — a domain, a lockfile or a list — checks each CVE against the ranges its sources publish, and alerts you when one you run is exploited or enters CISA KEV. A version it cannot read stays « version not verified ».

No credit card required · No monthly cap on website lookups · 250 API requests/month

Sources for this record