CVE-2025-68973: 
NixOS vulnerability analysis and mitigation

CVE-2025-68973 is an out-of-bounds write vulnerability in GnuPG's ASCII armor parser, caused by a double-increment logic error in the armor_filter function within g10/armor.c. The bug, introduced in 1999, causes an index variable to be incremented twice where only one increment is intended, resulting in memory corruption when processing specially crafted input. It affects GnuPG versions through 2.4.8 (fixed in 2.4.9) and through 2.2.50 for the ExtendedLTS branch (fixed in 2.2.51). The vulnerability was publicly disclosed on December 28, 2025, and carries a CVSS v3.1 base score of 7.0 (High) (Feedly, GnuPG Commit).

The root cause is a logic error (CWE-675: Multiple Operations on Resource in Single-Operation Context; CWE-787: Out-of-bounds Write) in the armor_filter function in g10/armor.c. The vulnerable code path contains a for loop where both the output buffer index n and the source buffer position afx->buffer_pos are incremented via n++ in the loop condition and buf[n++] = afx->buffer[afx->buffer_pos++] in the body — resulting in n being incremented twice per iteration. This causes every other byte in the output buffer to be uninitialized garbage and can write data beyond the intended buffer boundary. The code path is only reachable with specially crafted input, and the upstream commit notes that no fuzzing had previously triggered it (GnuPG Commit, oss-security). The fix removes the erroneous n++ from the loop increment expression, leaving only the body-level increment.

Successful exploitation could allow a local attacker with low privileges to trigger memory corruption in GnuPG's armor parsing code, potentially leading to arbitrary code execution or system compromise. The vulnerability affects confidentiality, integrity, and availability at a high level, as arbitrary code execution in the context of the GnuPG process could expose private keys, allow tampering with cryptographic operations, or crash the application. Downstream products incorporating GnuPG — including IBM CICS TX, IBM Netezza Appliance, IBM API Connect, IBM Instana, Oracle Linux, Red Hat Enterprise Linux, Debian, Ubuntu, SUSE, and Splunk AppDynamics agents — are also affected (Feedly, IBM Advisory).

As of the time of disclosure, there is no public proof-of-concept exploit and no evidence of active in-the-wild exploitation (Feedly Executive Summary). The EPSS score is approximately 0.012% (0.000120), indicating a very low probability of exploitation in the near term. The vulnerability requires local access with low privileges and high attack complexity, limiting its immediate risk. It is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. A test case using base64+gzipped crafted input was provided in the upstream fix commit to demonstrate uninitialized memory access under Valgrind (GnuPG Commit).

1. Reconnaissance: Identify systems running GnuPG versions prior to 2.4.9 (or prior to 2.2.51 for ExtendedLTS) with local access available.
2. Craft malicious input: Prepare a specially crafted ASCII-armored PGP message that triggers the double-increment code path in armor_filter. The upstream commit provides a base64+gzipped test payload that demonstrates uninitialized memory access.
3. Trigger the vulnerability: Feed the crafted armored input to GnuPG (e.g., via gpg --decrypt or gpg --verify) as a low-privileged local user, causing the armor_filter function to write out-of-bounds data into the I/O buffer.
4. Achieve memory corruption: The double-increment causes every other byte in the output buffer to contain uninitialized data, potentially corrupting adjacent memory structures.
5. Escalate to code execution: With a carefully crafted payload and knowledge of memory layout, an attacker may be able to control the corrupted memory region to redirect execution flow and achieve arbitrary code execution in the GnuPG process context (GnuPG Commit, oss-security).

• Logs: GnuPG error output referencing "invalid armor" or corrupt input when processing armored messages; unexpected crashes or segmentation faults in the gpg process.
• Process: Unusual child processes spawned by gpg or gpg2; gpg processes consuming abnormal memory or crashing unexpectedly.
• File System: Unexpected files written to directories where GnuPG operates, particularly if output file paths are manipulated; core dump files (core) generated by the gpg process.
• Network: Outbound connections from systems where GnuPG is used in automated pipelines, following processing of externally sourced armored data (may indicate post-exploitation activity).

The primary remediation is to upgrade GnuPG to version 2.4.9 or later (stable branch) or 2.2.51 or later (ExtendedLTS branch). The fix is a one-line change in g10/armor.c removing the erroneous double-increment in the armor_filter loop (GnuPG Commit). Major Linux distributions have released updated packages: Red Hat (RHSA-2026:0697, RHSA-2026:0719, RHSA-2026:0728, and others), Debian, Ubuntu, SUSE, Slackware, Fedora, Oracle Linux, and Amazon Linux 2. Downstream vendors including IBM (CICS TX, Netezza, API Connect, Instana) and Splunk (AppDynamics agents) have also released patches (IBM Advisory, Splunk Advisory). As a workaround where patching is not immediately possible, restrict local user access to systems running vulnerable GnuPG versions and avoid processing untrusted armored input.

The vulnerability was part of a broader batch of GnuPG security issues disclosed via the gpg.fail website and the oss-security mailing list in late December 2025, which attracted significant community attention (oss-security). Security researchers on Mastodon and Bluesky noted the disclosure, and the CISA published a vulnerability bulletin (SB25-363) referencing the issue. The GnuPG maintainer acknowledged the bug dates back to 1999 and was introduced during a major rewrite of armor.c, noting in the commit message that "memory corruption can never be tolerated as it always has the potential for remote code execution" (GnuPG Commit). Multiple Linux distribution security teams responded promptly with updated packages across January–February 2026.