GnuPG
CVE-2025-68973
HIGH
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessSupply crafted ASCII-armored message
-
ExploitVictim runs gpg to decode/verify
-
ExecutionTrigger double-increment in armor_filter copy loop
-
ImpactLeak uninitialized buffer memory into output
Vulnerability Assessment
| Weakness |
CWE
|
| Exploitation Conditions | Exploitation requires a vulnerable GnuPG to process an attacker-crafted OpenPGP ASCII-armored input through the de-armor path (armor_filter in g10/armor.c); the flaw is in the buffer-copy loop that fills the decode output. Concretely limiting factors: AV:L means the malicious armored data must be processed locally (e.g., a file, message, or piped input handed to gpg), AC:H means the specific buffer state that surfaces the double-increment/uninitialized-read must be reliably reached (non-trivial), and in practice a victim must actually run gpg against the attacker-supplied armored data. No non-default feature toggle is required - the armor decoder is a standard code path - but the high complexity and local processing requirement meaningfully constrain real-world exploitation. |
| Impact | The CVSS base score is 7.0 (HIGH), but the vector tells a more measured story: AV:L (local) and AC:H (high attack complexity) mean this is not a remotely-triggerable, point-and-click flaw - it requires GnuPG to locally process attacker-supplied data and the memory-handling condition to be reliably hit. The exploitation-probability signals strongly reinforce low urgency: EPSS is 0.02% (4th percentile), it is NOT listed in CISA KEV, and no public exploit is flagged in the input. The counterweight is that this flaw received significant public security-research attention (the gpg.fail/memcpy writeup, the 39C3 CCC talk 'To Sign or Not to Sign', oss-security, and HN threads), so technical detail is widely available even if no weaponized PoC is tracked. Note a conflicting metadata signal: the CVSS vector claims full-triad impact (C:H/I:H/A:H) while the tag set labels this 'Information Disclosure' - the source-diff root cause (a double-increment in the ASCII-armor copy loop leaking uninitialized buffer memory) is most consistent with a confidentiality/memory-disclosure primary impact, so the I:H/A:H ratings may be generous. Also note a PR discrepancy: NVD assigns PR:L, but supplying a crafted armored message to a victim's gpg realistically needs no attacker privileges (PR:N) - verify intended threat model with the vendor. Net: real but low-priority; patch on the normal maintenance cycle rather than as an emergency. |
| Exploit ScenarioDerived | An attacker crafts a malicious OpenPGP ASCII-armored message and delivers it to a victim, who decrypts or verifies it with a vulnerable gpg. The double-increment bug in the armor decoder (g10/armor.c) advances the output index twice per iteration, causing uninitialized heap buffer contents to be emitted into the decoded output - a memory-disclosure condition. No public exploit is flagged in the input, though the flaw was detailed in public research (gpg.fail/memcpy, 39C3); AV:L/AC:H means exploitation is local and non-trivial to trigger reliably. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv2 – Oct 13, 2026
GnuPG ships a memory-handling flaw in its OpenPGP ASCII-armor decoder that a remote attacker can trigger only by getting a victim to locally process a crafted armored input (a file, message, or piped stream handed to gpg), where a buffer-copy loop can over-run or read past the intended output buffer. The assessed vector (CVSS:3.1/AV:L/AC:H/PR:N/UI:R, base 7.0 HIGH) reflects a real but constrained impact: local processing is required, the vulnerable buffer state is difficult to reach reliably, and the victim must actually run gpg against the attacker-supplied data, while NVD's own vector is even more conservative (AV:L/AC:H/PR:L). Alpine Linux fixed the packaged issue in gnupg 2.4.9-r0 and upstream fixed the code in the commit that shipped with GnuPG 2.2.51; EPSS is negligible at 0.02% (4th percentile) and no public exploit identified at time of analysis.
Earlier versions of this analysis (1)
GnuPG on Alpine Linux was patched in package version 2.4.9-r0, addressing an unspecified vulnerability tracked as CVE-2025-68973. The nature of the vulnerability - including attack vector, impact class, and affected functionality - is not disclosed in available intelligence sources. No CVSS score, CWE classification, or technical description has been published, making independent severity assessment impossible at this time. No public exploit or CISA KEV listing has been identified.
RemediationAI
Vendor-released patch: GnuPG 2.2.51 on the upstream 2.2.x branch, and Alpine Linux package gnupg 2.4.9-r0 (run apk upgrade gnupg and restart any services that invoke gpg); Debian LTS users should apply the fixes from the Debian LTS advisory. If immediate upgrade is not possible, reduce exposure by refusing to feed untrusted ASCII-armored data to gpg - pre-parse or convert armored input with an independent tool (for example OpenSSL or Python's PGP libraries) before invoking gpg, and prefer raw binary OpenPGP packets, which bypass the ASCII-armor decode path entirely; the trade-off is that you lose GnuPG's own armor/CRC validation and must trust the converting tool. Blocking or sanitizing automated pipelines that pipe attacker-influenced mail, keyserver dumps, or downloaded .asc files straight into gpg removes the practical attack surface, since the assessed vector requires local processing of attacker-supplied armored data (AV:L) with high attack complexity (AC:H) and user interaction (UI:R), and EPSS indicates very low exploitation likelihood. Keep GnuPG current on all branches, as the same commit also added defensive assertions in iobuf.c aimed at catching related filter-contract bugs.
Affects your stack
Find out whether the stacks and servers you run are on an affected version.
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The defect lives in the ASCII-armor filter of GnuPG's I/O layer, specifically the buffer-copy loop in g10/armor.c that fills decoded output from afx->buffer. The pre-fix code incremented the destination index twice for every copied byte (once in the loop's increment expression and once in the assignment itself), a duplicate-operation pattern that CWE-675 captures and that lets the write index advance faster than the bounds check, producing an out-of-bounds write and potentially an uninitialized or stale read. The upstream fix (commit 115d138ba599328005c5321c0ef9f00355838ca9) removes the redundant increment so the copy advances one byte per iteration; the same commit adds a logging assertion in common/iobuf.c underflow_target to catch filters that return more data than they were asked for, indicating the project treats this class as a filter-contract bug. The affected CPE, cpe:2.3:a:gnupg:gnupg:*:*:*:*:-:*:*:*, is unscoped, so every GnuPG release before the fix branches are patched should be treated as affected, and packaging layers (Alpine Linux, Debian LTS) carry their own patched builds. Because the flawed code is in the standard de-armor path, no non-default feature toggle is required - but the input must be ASCII-armored and must be processed by a vulnerable GnuPG instance, and the specific buffer state that surfaces the bad write is hard to hit consistently, matching the AC:H rating.
Know when Gnupg gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
Local processing of crafted armored input (AV:L); triggering the buffer bug reliably is complex (AC:H); attacker needs no privileges but a victim must process the input (PR:N/UI:R); primary impact is memory disclosure.
Primary rating from NVD.
CVSS VectorNVD
Lifecycle Timeline
2DescriptionNVD
Alpine Linux: gnupg fixed in 2.4.9-r0
Executive ViewAI
GnuPG, widely used for encryption, signing, and software supply-chain verification, contains a high-severity memory-handling flaw in its OpenPGP ASCII-armor decoder. Exploitation requires a user to locally process a crafted armored input, and no public exploit identified at time of analysis, but a successful trigger could crash cryptographic operations or expose unintended memory contents. Leadership should prioritize patching because GnuPG underpins secure communications and trusted software distribution across the organization.
Apply vendor patch.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.
Affected Products (CPE)NVD
Remote code execution and denial of service in GnuPG before 2.5.17 stem from a stack-based buffer overflow in gpg-agent
GnuPG version 2.1.12 - 2.2.11 contains a Cross ite Request Forgery (CSRF) vulnerability in dirmngr that can result in At
cipher/elgamal.c in Libgcrypt through 1.8.2, when used to encrypt messages directly, improperly encodes plaintexts, whic
Stack-based buffer overflow in GnuPG's tpm2daemon (versions before 2.5.17) allows a local attacker to corrupt the daemon
GnuPG 2.2.21 and 2.2.22 (and Gpg4win 3.1.12) has an array overflow, leading to a crash or possibly unspecified other imp
Interaction between the sks-keyserver code through 1.2.0 of the SKS keyserver network, and GnuPG through 2.2.16, makes i
GnuPG through 2.3.6, in unusual situations where an attacker possesses any secret-key information from a victim's keyrin
The read_block function in g10/import.c in GnuPG 1.4.x before 1.4.13 and 2.0.x through 2.0.19, when importing a key, all
The ElGamal implementation in Libgcrypt before 1.9.4 allows plaintext recovery because, during interaction between two c
Libksba before 1.6.3 is prone to an integer overflow vulnerability in the CRL signature parser. Rated critical severity
Integer underflow in the ksba_oid_to_str function in Libksba before 1.3.2, as used in GnuPG, allows remote attackers to
Libgcrypt before 1.7.10 and 1.8.x before 1.8.3 allows a memory-cache side-channel attack on ECDSA signatures that can be
NVD
CVE.org
EPSS
GitHub
Exploit-DB