Hi!

On Mon, 14 Sep 2026 21:28, Clemens Lang said: (1) A RCE in gpgsm 2.4.9 when invoked as gpgsm --debug all --import bad.cert, with the bad.cert file at [1]. This is apparently a 0-day, Actually in all versions > 2.2 if you use --debug x509. The result is that you get garbled output on stderr. Using the certificates from their Git repo we have not been able to get more than a segv. That is obvious because the DER is used as printf format string. How it is possible to get a an RCE is not clear to me - at least not with the sample certificate. We need a real reproducers. Maybe the presentation used a custom build. It uses libgcrypt 1.12.4 which is not yet used in any binary we released.

This is the fix:

if (DBGX509) - logdebug(skider, skiderlen, "ski is:"); + logprinthex (skider, skiderlen, "ski is:");

We did not used -Wformat-nonliteral which would have caught it due to gcc problems and distros requiring -Werror. There is one other case where the wrong log function was used but that only affects a certain rare smartcard. BTW, the debug interface is subject to change at any time and should thus not to be used for production. (2) An integer underflow followed by a buffer overflow in libgcrypt’s RSASSA-PSS verification discussed in slides 38-45 of [2], fixed in libgcrypt commit 0d64fc2 [3] (also reported by somebody using Claude CommitDate: Wed Aug 5 14:11:03 2026 +0900

cipher:rsa: Fix verify RSA PSS verify. cipher/rsa-common.c (gcryrsapssverify): Validate EMLEN, before the allocation. -- This issue was found by Anthropic using Claude, and has been reviewed manually by David Korczynski from Ada Logics. Code) released in (apparently) libgcrypt 1.12.3 without a CVE assigned. The researcher(s) claim this can be used for RCE from the S/MIME verifier and GnuPG with a 53-bit preimage attack (they don’t We have no information about this except for the slides. We have not been contacted at all. But the bug used is anyway public for more than a month. From the orginal bug report:

Severity (our reading; we defer the final rating to you) -------------------------------------------------------- We assess the defect as High: an attacker-controlled out-of-bounds heap write (the content, the write length via the hash algorithm, and the underflow offset via the modulus size are all attacker-chosen) reached from the primary public verification API in a default (non-FIPS) build, before any signature parsing. We want to be candid about the deployment precondition, though: the trigger requires the application to verify against a public key whose size it has not vetted (raw signature/key-import-then-verify flows, protocol messages carrying a key). Major consumers such as GnuPG and GnuTLS reject toy-sized RSA keys before libgcrypt sees them, which limits real-world reach; the practical impact ceiling for those is bounded. We leave the final classification to you.

And our reply:

In normal use cases, before the call of gcrypkverify, the key is validated. That's my understanding. Perhaps, we will handle this bug, as a normal bug. (Please note that GnuPG does not use RSA PSS.)

Fixed in libgcrypt 1.12.3 released 2026-08-26

Shalom-Salam,

Werner

-- The pioneers of a warless world are the youth that refuse military service. - A. Einstein

Hi, On 13. Sep 2026, at 02:44, Sam James <sam () gentoo org> wrote:

They also mention another vulnerability in the slides that is in the talk but I've not seen that yet. A PoC is available in their repo [3]. I see two potential vulnerabilities discussed in this talk:

(1) A RCE in gpgsm 2.4.9 when invoked as gpgsm --debug all --import bad.cert, with the bad.cert file at [1]. This is apparently a 0-day, as they say it was not reported to GnuPG. I’m not sure how widely used this code is, and how many users regularly call gpgsm --import with untrusted inputs. The researcher(s) say "if you're here to write a patch for the calc pop: sm/certcheck.c:634 lol” for this problem, which may be a pointer to debugging it.

(2) An integer underflow followed by a buffer overflow in libgcrypt’s RSASSA-PSS verification discussed in slides 38-45 of [2], fixed in libgcrypt commit 0d64fc2 [3] (also reported by somebody using Claude Code) released in (apparently) libgcrypt 1.12.3 without a CVE assigned. The researcher(s) claim this can be used for RCE from the S/MIME verifier and GnuPG with a 53-bit preimage attack (they don’t say which hash algorithm, but I wouldn’t be surprised if SHA-1 is sufficient).

Personally, I’m not all that interested in (1), but (2) seems to be in code that’s widely used, and there should probably be a CVE assigned for it so we can track fixes and backports.

[1]: https://git.gay/49016/gpg-fail-aftermath/src/branch/main/pocs/bad.cert [2]: https://git.gay/49016/gpg-fail-aftermath/src/branch/main/slides.pdf [3]: https://gitlab.com/redhat-crypto/libgcrypt/libgcrypt-mirror/-/commit/0d64fc2

-- Clemens Lang RHEL Crypto Team Red Hat

The mpipowm function in Libgcrypt before 1.6.3 and GnuPG before 1.4.19 allows attackers to obtain sensitive information by leveraging timing differences when accessing a pre-computed table during modular exponentiation, related to a "Last-Level Cache Side-Channel Attack."

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.

DISPUTED In Libgcrypt 1.8.4, the C implementation of AES is vulnerable to a flush-and-reload side-channel attack because physical addresses are available to other processes. (The C implementation is used on platforms where an assembly-language implementation is unavailable.) NOTE: the vendor's position is that the issue report cannot be validated because there is no description of an attack.

DISPUTED cryptlib through 3.4.4 allows a memory-cache side-channel attack on DSA and ECDSA signatures, aka the Return Of the Hidden Number Problem or ROHNP. To discover a key, the attacker needs access to either the local machine or a different virtual machine on the same physical host. NOTE: the vendor does not include side-channel attacks within its threat model.

The mixing functions in the random number generator in Libgcrypt before 1.5.6, 1.6.x before 1.6.6, and 1.7.x before 1.7.3 and GnuPG before 1.4.21 make it easier for attackers to obtain the values of 160 bits by leveraging knowledge of the previous 4640 bits.

Libgcrypt before 1.6.5 does not properly perform elliptic-point curve multiplication during decryption, which makes it easier for physically proximate attackers to extract ECDH keys by measuring electromagnetic emanations.

Libgcrypt before 1.5.4, as used in GnuPG and other products, does not properly perform ciphertext normalization and ciphertext randomization, which makes it easier for physically proximate attackers to conduct key-extraction attacks by leveraging the ability to collect voltage data from exposed metal, a different vector than CVE-2013-4576.

GnuPG before 1.4.14, and Libgcrypt before 1.5.3 as used in GnuPG 2.0.x and possibly other products, allows local users to obtain private RSA keys via a cache side-channel attack involving the L3 cache, aka Flush+Reload.

Created attachment 629285 [details] patch to fix the buffer overflow

Description of problem: A buffer overflow in mcrypt version 2.6.8 and earlier due to long filenames. If a user were tricked into attempting to encrypt/decrypt specially crafted long filename(s), this flaw would cause a stack-based buffer overflow that could potentially lead to arbitrary code execution.

Note that this is caught by FORTIFYSOURCE, which renders this to being a crash-only bug on Fedora.

There are currently no upstream patches for this flaw.

Version-Release number of selected component (if applicable): mcrypt-2.6.8-9.el6 (possibly others too).

How reproducible: Run mcrypt with ~128 byte long file names.