In GnuPG before 2.5.17, a crafted CMS (S/MIME) EnvelopedData message carrying an oversized wrapped session key can cause a stack-based buffer overflow in gpg-agent during PKDECRYPT--kem=CMS handling. This can easily be leveraged for denial of service; however, there is also memory corruption that could lead to remote code execution.
CVE-2026-118131
A bug found in libksba, the library used by GnuPG for parsing the ASN.1 structures as used by S/MIME. The bug affects all versions of Libksba before 1.6.2 and may be used for remote code execution.
https://www.gnupg.org/blog/20221017-pepe-left-the-ksba.html https://dev.gnupg.org/T6230 https://dev.gnupg.org/rK4b7d9cd4a018898d7714ce06f3faf2626c14582b https://lwn.net/Articles/911467/
GnuPG version 2.1.12 - 2.2.11 contains a Cross ite Request Forgery (CSRF) vulnerability in dirmngr that can result in Attacker controlled CSRF, Information Disclosure, DoS. This attack appear to be exploitable via Victim must perform a WKD request, e.g. enter an email address in the composer window of Thunderbird/Enigmail. This vulnerability appears to have been fixed in after commit 4a4bb874f63741026bd26264c43bb32b1099f060.
In GnuPG before 2.5.17, a stack-based buffer overflow exists in tpm2daemon during handling of the PKDECRYPT command for TPM-backed RSA and ECC keys.
In GnuPG before 2.4.9, armorfilter in g10/armor.c has two increments of an index variable where one is intended, leading to an out-of-bounds write for crafted input. (For ExtendedLTS, 2.2.51 and later are fixed versions.)
GnuPG before version 2.2.8 does not properly sanitize original filenames of signed or encrypted messages allowing for the insertion of line feeds and other control characters. An attacker could exploit this by injecting such characters to craft status messages and fake the validity of signatures.
External Reference:
https://lists.gnupg.org/pipermail/gnupg-announce/2018q2/000425.html
Upstream Issue:
https://dev.gnupg.org/T4012
Upstream Patches:
https://dev.gnupg.org/rG2326851c60793653069494379b16d84e4c10a0ac https://dev.gnupg.org/rG210e402acd3e284b32db1901e43bf1470e659e49 https://dev.gnupg.org/rG13f135c7a252cc46cff96e75968d92b6dc8dce1b
GnuPG 2.2.4 and 2.2.5 does not enforce a configuration in which key certification requires an offline master Certify key, which results in apparently valid certifications that occurred only with access to a signing subkey.
A flaw was found in the way certificate signatures could be forged using collisions found in the SHA-1 algorithm. An attacker could use this weakness to create forged certificate signatures. This issue affects GnuPG versions before 2.2.18.
Interaction between the sks-keyserver code through 1.2.0 of the SKS keyserver network, and GnuPG through 2.2.16, makes it risky to have a GnuPG keyserver configuration line referring to a host on the SKS keyserver network. Retrieving data from this network may cause a persistent denial of service, because of a Certificate Spamming Attack.
In GnuPG through 2.4.8, armorfilter in g10/armor.c has two increments of an index variable where one is intended, leading to an out-of-bounds write for crafted input.
In GnuPG before 2.5.17, a stack-based buffer overflow exists in tpm2daemon during handling of the PKDECRYPT command for TPM-backed RSA and ECC keys.
Heap-based buffer overflow in the askoutfilename function in openfile.c for GnuPG (gpg) 1.4 and 2.0, when running interactively, might allow attackers to execute arbitrary code via messages with "C-escape" expansions, which cause the makeprintablestring function to return a longer string than expected while constructing a prompt.
GnuPG through 2.3.6, in unusual situations where an attacker possesses any secret-key information from a victim's keyring and other constraints (e.g., use of GPGME) are met, allows signature forgery via injection into the status line.
In GnuPG through 2.4.8, if a signed message has \f at the end of a plaintext line, an adversary can construct a modified message that places additional text after the signed material, such that signature verification of the modified message succeeds (although an "invalid armor" message is printed during verification). This is related to use of \f as a marker to denote truncation of a long plaintext line.
In GnuPG before 2.5.17, a long signature packet length causes parsesignature to return success with sig->data[] set to a NULL value, leading to a denial of service (application crash).
The integrity check feature in OpenPGP, when handling a message that was encrypted using cipher feedback (CFB) mode, allows remote attackers to recover part of the plaintext via a chosen-ciphertext attack when the first 2 bytes of a message block are known, and an oracle or other mechanism is available to determine whether an integrity check failed.
parse-packet.c in GnuPG (gpg) 1.4.3 and 1.9.20, and earlier versions, allows remote attackers to cause a denial of service (gpg crash) and possibly overwrite memory via a message packet with a large length (long user ID string), which could lead to an integer overflow, as demonstrated using the --no-armor option.
Integer overflow in parsecomment in GnuPG (gpg) 1.4.4 allows remote attackers to cause a denial of service (segmentation fault) via a crafted message.
GnuPG 1.4.6 and earlier and GPGME before 1.1.4, when run from the command line, does not visually distinguish signed and unsigned portions of OpenPGP messages with multiple components, which might allow remote attackers to forge the contents of a message without detection.
In GnuPG before 2.5.5, if a user chooses to import a certificate with certain crafted subkey data that lacks a valid backsig or that has incorrect usage flags, the user loses the ability to verify signatures made from certain other signing keys, aka a "verification DoS."
Libgcrypt before 1.6.3 and GnuPG before 1.4.19 does not implement ciphertext blinding for Elgamal decryption, which allows physically proximate attackers to obtain the server's private key by determining factors using crafted ciphertext and the fluctuations in the electromagnetic field during multiplication.
GnuPG can be made to spin on a relatively small input by (for example) crafting a public key with thousands of signatures attached, compressed down to just a few KB; see $URL and the surrounding email threads for more details and test-cases.
The reporter has some proposed patches at https://dev.gnupg.org/D556 (and in oss-security / gnupg-devel threads); mostly these flag/reject compressed packets and indeterminate-length packets in contexts where they make no sense and arguably are not within the spec (certificates, keys, detached signatures).
GnuPG can be made to spin on a relatively small input by (for example) crafting a public key with thousands of signatures attached, compressed down to just a few KB; see $URL and the surrounding email threads for more details and test-cases.
The reporter has some proposed patches at https://dev.gnupg.org/D556 (and in oss-security / gnupg-devel threads); mostly these flag/reject compressed packets and indeterminate-length packets in contexts where they make no sense and arguably are not within the spec (certificates, keys, detached signatures).
USN-3675-1 fixed a vulnerability in GnuPG 2 for Ubuntu 18.04 LTS and Ubuntu 17.10. This update provides the corresponding update for GnuPG 2 in Ubuntu 16.04 LTS and Ubuntu 14.04 LTS. Original advisory details: Marcus Brinkmann discovered that during decryption or verification, GnuPG did not properly filter out terminal sequences when reporting the original filename. An attacker could use this to specially craft a file that would cause an application parsing GnuPG output to incorrectly interpret the status of the cryptographic operation reported by GnuPG.
https://gpg.fail lists many vulnerabilities in GnuPG, one of which allows remote code execution. All are zero-days to the best of my knowledge. -- Sincerely, Demi Marie Obenour (she/her/hers)
On Sat, Dec 27, 2025 at 07:29:53PM -0500, Demi Marie Obenour wrote: https://gpg.fail lists many vulnerabilities in GnuPG, one of which allows remote code execution. All are zero-days to the best of my knowledge. Thanks. I wish this were brought in here by the researchers, but since it was not and since we require actual content here (not just links), let me take care of this now. The website has it nicely formatted, so I also include the HTML versions, which brings the message to just below the maximum of 1 MiB here. Who knows how long this website will stay up, but oss-security archives will probably exist decades later.
The website currently says: Slides, pocs and patches soon!
"in the hurry of leaving i forgot the sites src at home, sorry, had to rewrite the whole thing. expect a nicer site by tomorrow. im patching as we speak." - crackticker (<- to blame)
1. Multiple Plaintext Attack on Detached PGP Signatures in GnuPG 2. GnuPG Accepts Path Separators and Path Traversals in Literal Data "Filename" Field 3. Cleartext Signature Plaintext Truncated for Hash Calculation 4. Encrypted message malleability checks are incorrectly enforced causing plaintext recovery attacks 5. Memory Corruption in ASCII-Armor Parsing 6. Trusted comment injection (minisign) 7. Cleartext Signature Forgery in the NotDashEscaped header implementation in GnuPG 8. OpenPGP Cleartext Signature Framework Susceptible to Format Confusion 9. GnuPG Output Fails To Distinguish Signature Verification Success From Message Content 10. Cleartext Signature Forgery in GnuPG 11. Radix64 Line-Truncation Enabling Polyglot Attacks 12. GnuPG may downgrade digest algorithm to SHA1 during key signature checking 13. GnuPG Trust Packet Parsing Enables Adding Arbitrary Subkeys 14. Trusted comment Injection (minisign) Each of the above 14 vulnerabilities has its own web page. I attach 14 text (converted with ELinks at width 80) and 14 HTML files corresponding to them.
Also included on the website is the talk video (49 minutes).
This disclosure was part of the below 39C3 talk:
https://fahrplan.events.ccc.de/congress/2025/fahrplan/event/to-sign-or-not-to-sign-practical-vulnerabilities-i To sign or not to sign: Practical vulnerabilities in GPG & friends Day 1 17:15 One en Security Dec. 27, 2025 17:15-18:15
Might contain zerodays. https://gpg.fail/ From secure communications to software updates: PGP implementations such as GnuPG ubiquitously relied on to provide cryptographic assurances. Many applications from secure communications to software updates fundamentally rely on these utilities. Since these have been developed for decades, one might expect mature codebases, a multitude of code audit reports, and extensive continuous testing. When looking into various PGP-related codebases for some personal use cases, we found these expectations not met, and discovered multiple vulnerabilities in cryptographic utilities, namely in GnuPG, Sequoia PGP, age, and minisign. The vulnerabilities have implementation bugs at their core, for example in parsing code, rather than bugs in the mathematics of the cryptography itself. A vulnerability in a parser could for example lead to a confusion about what data was actually signed, allowing attackers without the private key of the signer to swap the plain text. As we initially did not start with the intent of conducting security research, but rather were looking into understanding some internals of key management and signatures for personal use, we also discuss the process of uncovering these bugs. Furthermore, we touch on the role of the OpenPGP specification, and the disclosure process.
Beyond the underlying mathematics of cryptographic algorithms, there is a whole other layer of implementation code, assigning meaning to the processed data. For example, a signature verification operation both needs robust cryptography and assurance that the verified data is indeed the same as was passed into the signing operation. To facilitate the second part, software such as GnuPG implement parsing and processing code of a standardized format. Especially when implementing a feature rich and evolving standard, there is the risk of ambivalent specification, and classical implementation bugs.
The impact of the vulnerabilities we found reaches from various signature verification bypasses, breaking encryption in transit and encryption at rest, undermining key signatures, to exploitable memory corruption vulnerabilities.
Speakers of this event 49016 does many computer adjacent things; it has a talent for breaking them, and occasionally does security research for good in its free time.
Liam is motivated by understanding programs in depth: taking a program that runs and making it dance. Alexander
On 12/27/25 22:27, Solar Designer wrote: On Sat, Dec 27, 2025 at 07:29:53PM -0500, Demi Marie Obenour wrote: https://gpg.fail lists many vulnerabilities in GnuPG, one of which allows remote code execution. All are zero-days to the best of my knowledge. Thanks. I wish this were brought in here by the researchers, but since it was not and since we require actual content here (not just links), let me take care of this now. The website has it nicely formatted, so I also include the HTML versions, which brings the message to just below the maximum of 1 MiB here. Who knows how long this website will stay up, but oss-security archives will probably exist decades later.
The website currently says: Slides, pocs and patches soon!
"in the hurry of leaving i forgot the sites src at home, sorry, had to rewrite the whole thing. expect a nicer site by tomorrow. im patching as we speak." - crackticker (<- to blame)
1. Multiple Plaintext Attack on Detached PGP Signatures in GnuPG 2. GnuPG Accepts Path Separators and Path Traversals in Literal Data "Filename" Field 3. Cleartext Signature Plaintext Truncated for Hash Calculation 4. Encrypted message malleability checks are incorrectly enforced causing plaintext recovery attacks 5. Memory Corruption in ASCII-Armor Parsing 6. Trusted comment injection (minisign) 7. Cleartext Signature Forgery in the NotDashEscaped header implementation in GnuPG 8. OpenPGP Cleartext Signature Framework Susceptible to Format Confusion 9. GnuPG Output Fails To Distinguish Signature Verification Success From Message Content 10. Cleartext Signature Forgery in GnuPG 11. Radix64 Line-Truncation Enabling Polyglot Attacks 12. GnuPG may downgrade digest algorithm to SHA1 during key signature checking 13. GnuPG Trust Packet Parsing Enables Adding Arbitrary Subkeys 14. Trusted comment Injection (minisign) Each of the above 14 vulnerabilities has its own web page. I attach 14 text (converted with ELinks at width 80) and 14 HTML files corresponding to them.
Comments on a first reading: Item 1: Multiple Plaintext Attack on Detached PGP Signatures in GnuPG
Item 3: Cleartext Signature Plaintext Truncated for Hash Calculation
Item 5: Memory Corruption in ASCII-Armor Parsing
This is a serious memory-safety error in GPG.
Item 6: Trusted comment injection (minisign)
From Message Content
Item 10: Cleartext Signature Forgery in GnuPG Item 11: Radix64 Line-Truncation Enabling Polyglot Attacks
Item 13: GnuPG Trust Packet Parsing Enables Adding Arbitrary Subkeys
Keyrings are trusted stores, so this is more of a documentation problem. Item 14: Trusted comment Injection (minisign) -- Jacob
Most of them are about unreliably displaying what was actually signed and vertified.
The RCE bug was actually fixed as they already state in their slides.
https://github.com/gpg/gnupg/commit/ad0c6c33c3d6fe7ff7cc8c2e73d02ead5788e5b3
The overall status is not good though. In total (in their slides): - 1 fixed - 1 mitigated - 3 unreleased patches in Git - 7 unpatched - 2 wontfox status.
Regards
Demi Marie Obenour <demiobenour () gmail com> writes: https://gpg.fail lists many vulnerabilities in GnuPG, one of which allows remote code execution.
All are zero-days to the best of my knowledge. In 2.5.14:
commit 115d138ba599328005c5321c0ef9f00355838ca9 Author: Werner Koch <wk () gnupg org> AuthorDate: Thu Oct 23 11:36:04 2025 +0200 Commit: Werner Koch <wk () gnupg org> CommitDate: Thu Oct 23 11:37:59 2025 +0200
gpg: Fix possible memory corruption in the armor parser.
g10/armor.c (armorfilter): Fix faulty double increment.
common/iobuf.c (underflowtarget): Assert that the filter implementations behave well. --
This fixes a bug in a code path which can only be reached with special crafted input data and would then error out at an upper layer due to corrupt input (every second byte in the buffer is unitialized garbage). No fuzzing has yet hit this case and we don't have a test case for this code path. However memory corruption can never be tolerated as it always has the protential for remode code execution.
Reported-by: 8b79fe4dd0581c1cd000e1fbecba9f39e16a396a Fixes-commit: c27c7416d5148865a513e007fb6f0a34993a6073 which fixed Fixes-commit: 7d0efec7cf5ae110c99511abc32587ff0c45b14f
In 2.5.13:
commit 8abc320f2a75d6c7339323a3cff8a8489199f49f Author: Werner Koch <wk () gnupg org> AuthorDate: Wed Oct 22 12:39:15 2025 +0200 Commit: Werner Koch <wk () gnupg org> CommitDate: Wed Oct 22 12:39:15 2025 +0200
gpg: Error out on unverified output for non-detached signatures.
g10/mainproc.c (doprocpackets): Never reset the any.data flag. --
Fixes-commit: 3b1b6f9d98b38480ba2074158fa640b881cdb97e Updates-commit: 69384568f66a48eff3968bb1714aa13925580e9f Reported-by: 8b79fe4dd0581c1cd000e1fbecba9f39e16a396a
commit 8abc320f2a75d6c7339323a3cff8a8489199f49f Author: Werner Koch <wk () gnupg org> AuthorDate: Wed Oct 22 12:39:15 2025 +0200 Commit: Werner Koch <wk () gnupg org> CommitDate: Wed Oct 22 12:39:15 2025 +0200
gpg: Error out on unverified output for non-detached signatures.
g10/mainproc.c (doprocpackets): Never reset the any.data flag.
commit db9705ef594d5a2baf0e95e13cf6170b621dfc51 Author: Werner Koch <wk () gnupg org> AuthorDate: Wed Oct 22 11:19:55 2025 +0200 Commit: Werner Koch <wk () gnupg org> CommitDate: Wed Oct 22 11:20:10 2025 +0200
gpg: Avoid potential downgrade to SHA1 in 3rd party key signatures.
But it isn't clear to me what... the mapping between all of the vulnerabilities listed on the website is vs GnuPG commits (unfortunately no CVE identifiers yet either); GnuPG bug tracker links map to commits or vulnerabilities; whether these fixes are complete for a specific vulnerability or not.
The relevant public bugs I'm aware of for GnuPG are: https://dev.gnupg.org/T7909 https://dev.gnupg.org/T7900 https://dev.gnupg.org/T7902 https://dev.gnupg.org/T7903 but some linked therein are still marked private.
Finally, to end the dump of what I know so far: Werner Koch has published a response to the cleartext signature vulnerabilities: https://gnupg.org/blog/20251226-cleartext-signatures.html.
sam