|
|
Log in / Subscribe / Register

A critical GnuPG security update

There is a new GnuPG update for a "critical security bug" in recent GnuPG releases.

A crafted CMS (S/MIME) EnvelopedData message carrying an oversized wrapped session key can cause a stack buffer overflow in gpg-agent during the PKDECRYPT--kem=CMS handling. This can easily be used for a DoS but, worse, the memory corruption can very likley also be used to mount a remote code execution attack. The bug was introduced while changing an internal API to the FIPS required KEM API.

Only versions 2.5.13 through 2.5.16 are affected.

From:  Werner Koch via Gnupg-devel <gnupg-devel-AT-gnupg.org>
To:  gnupg-announce-AT-gnupg.org
Subject:  [Announce] GnuPG and Gpg4win Security Advisory (T8044)
Date:  Tue, 27 Jan 2026 17:49:42 +0100
Message-ID:  <877bt30zmh.fsf__27969.912246202$1769532728$gmane$org@jacob.g10code.de>
Cc:  info-gnu-AT-gnu.org

Hello!

We are pleased to announce the availability of a new GnuPG release:
version 2.5.17.  This version fixes a *critical security bug* in
versions 2.5.13 to 2.5.16.  We also released a new Gpg4win version and
updated Debian packages.


Impact
======

These versions are affected:

 - GnuPG 2.5.16          (released 2025-12-30)
 - GnuPG 2.5.15          (released 2025-12-29)
 - GnuPG 2.5.14          (released 2025-11-19)
 - GnuPG 2.5.13          (released 2025-10-22)
 - Gpg4win 5.0.0         (released 2026-01-14)
 - Gpg4win 5.0.0-beta479 (released 2026-01-02)
 - Gpg4win 5.0.0-beta476 (released 2025-12-22)
 - Gpg4win 5.0.0-beta395 (released 2025-10-22)

All other versions are not affected.

A crafted CMS (S/MIME) EnvelopedData message carrying an oversized
wrapped session key can cause a stack buffer overflow in gpg-agent
during the PKDECRYPT--kem=CMS handling.  This can easily be used for a
DoS but, worse, the memory corruption can very likley also be used to
mount a remote code execution attack.  The bug was introduced while
changing an internal API to the FIPS required KEM API.

A CVE-id has not been assigned.  We track this bug as T8044 under
https://dev.gnupg.org/T8044.  This vulnerability was discovered by:
OpenAI Security Research.  Their report was received on 2026-01-18;
fixed versions released 2026-01-27.


Solution
========

If an affected GnuPG version is used please update ASAP to the new
version 2.5.17.

If an affected version of Gpg4win is used please update ASAP to the new
version 5.0.1.

If an immediate update is not possible please remove the gpgsm or
gpgsm.exe binary; this way the bug can't be remotely triggered.



Noteworthy changes in version 2.5.17 (2026-01-27)
=================================================
         [compared to version 2.5.16]

  * agent: Fix stack buffer overflow when using gpgsm and KEM.  This
    was introduced with 2.5.13; see above.  [T8044]

  * tpm: Fix possible buffer overflow in PKDECRYPT.  [T8045]

  * gpg: Fix possible NULL-deref with overlong signature packets. [T8049]

  * gpg: New export-option "keep-expired-subkeys".  [T7990]

  * gpgsm: Make multiple search patterns work with keyboxd.  [T8026]

  * agent: Add accelerator keys for "Wrong" and "Correct".  [T8055]

  * dirmngr: Help detection of bad keyserver configurations.  [T7730]

  Release-info: https://dev.gnupg.org/T7996



Getting the Software
====================

Please follow the instructions found at <https://gnupg.org/download/> or
read on:

GnuPG may be downloaded from one of the GnuPG mirror sites or direct
from its primary file server.  The list of mirrors can be found at
<https://gnupg.org/download/mirrors.html>.  Note that GnuPG is not
available at ftp.gnu.org.

The GnuPG source code compressed using BZIP2 and its OpenPGP signature
are available here:

 https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.5.17.tar.bz2 (8113k)
 https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.5.17.tar.bz2.sig

An installer for Windows without any graphical frontend except for a
very minimal Pinentry tool is available here:

 https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.5.17_2026... (5573k)
 https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.5.17_2026...

The source used to build this installer for 64-bit Windows is available as

 https://gnupg.org/ftp/gcrypt/gnupg/gnupg-w32-2.5.17_20260... (15M)
 https://gnupg.org/ftp/gcrypt/gnupg/gnupg-w32-2.5.17_20260...

 This source tarball may also be used to download all required libraries
 at once to build a Unix version on any modern system.  See the included
 README.


Debian Packages
===============

We also provide new Debian style packages for a couple of Debian
variants.  See https://repos.gnupg.org/deb/gnupg/trixie/ or use the menu
to switch to other distros/releases.  It may take a view hours before
the new packages show up.  If you encounter other packaging problems
please report them to the gnupg-devel mailing list.


Windows Installer
=================

A new version of Gpg4win (5.0.1), our full featured Windows installer,
including this version of GnuPG, the Kleopatra GUI, and a PDF reader has
also been released.  Head over to https://gpg4win.org/


Checking the Integrity
======================

In order to check that the version of GnuPG which you are going to
install is an original and unmodified one, you can do it in one of
the following ways:

 * If you already have a version of GnuPG installed, you can simply
   verify the supplied signature.  For example to verify the signature
   of the file gnupg-2.5.17.tar.bz2 you would use this command:

     gpg --verify gnupg-2.5.17.tar.bz2.sig gnupg-2.5.17.tar.bz2

   This checks whether the signature file matches the source file.
   You should see a message indicating that the signature is good and
   made by one or more of the release signing keys.  Make sure that
   this is a valid key, either by matching the shown fingerprint
   against a trustworthy list of valid release signing keys or by
   checking that the key has been signed by trustworthy other keys.
   See the end of this mail for information on the signing keys.

 * If you are not able to use an existing version of GnuPG, you have
   to verify the SHA-1 checksum.  On Unix systems the command to do
   this is either "sha1sum" or "shasum".  Assuming you downloaded the
   file gnupg-2.5.17.tar.bz2, you run the command like this:

     sha1sum gnupg-2.5.17.tar.bz2

   and check that the output matches the next line:

ee0bc59eadf258b6d92131911b5dca6cabc89419  gnupg-2.5.17.tar.bz2
8826ff58e245c9700391fefff34afe775300e7cd  gnupg-w32-2.5.17_20260127.tar.xz
31ac31fe8f5b4f3e3ae8e5e6a70c967a59f66e63  gnupg-w32-2.5.17_20260127.exe


Internationalization
====================

This version of GnuPG has support for 26 languages with Chinese, Czech,
Dutch, French, Georgian, German, Italian, Japanese, Norwegian, Polish,
Portuguese, Russian, Swedish, Turkish, and Ukrainian being almost
completely translated.


Documentation and Support
=========================

The file gnupg.info has the complete reference manual of the system.
Separate man pages are included as well but they miss some of the
details available only in the manual.  The manual is also available
online at

  https://gnupg.org/documentation/manuals/gnupg/

or can be downloaded as PDF at

  https://gnupg.org/documentation/manuals/gnupg.pdf

You may also want to search the GnuPG mailing list archives or ask on
the gnupg-users mailing list for advise on how to solve problems.  Most
of the new features are around for several years and thus enough public
experience is available.  https://wiki.gnupg.org has user contributed
information around GnuPG and relate software.

If you are using cleartext signatures in your application please read
https://gnupg.org/blog/20251226-cleartext-signatures.html .

In case of build problems specific to this release please first check
https://dev.gnupg.org/T7996 for updated information.  We are sorry that
due to ongoing DoS on this service, you may end up at a "is under
maintenance page".

Please consult the archive of the gnupg-users mailing list before
reporting a bug: https://gnupg.org/documentation/mailing-lists.html.
We suggest to send bug reports for a new release to this list in favor
of filing a bug at https://bugs.gnupg.org.  If you need commercial
support go to https://gnupg.com or https://gnupg.org/service.html.

If you are a developer and you need a certain feature for your project,
please do not hesitate to bring it to the gnupg-devel mailing list for
discussion.


Thanks
======

Since 2001 maintenance and development of GnuPG is done by g10 Code GmbH
and has mostly been financed by donations.  A team of full-time employed
developers and contractors are working exclusively on GnuPG and related
software like Libgcrypt, GPGME, Kleopatra, Okular, and Gpg4win.

Fortunately, and this is still not common with free software, we have
established a way of financing the development while keeping all our
software free and freely available for everyone.  Our model is similar
to the way RedHat manages RHEL and Fedora: Except for the actual binary
of the MSI installer for Windows and client specific configuration
files, all the software is available under the GNU GPL and other Open
Source licenses.  Thus customers may even build and distribute their own
version of the software as long as they do not use our trademarks
GnuPG Desktop® or GnuPG VS-Desktop®.

We like to thank all the nice people who are helping the GnuPG project,
be it testing, coding, translating, suggesting, auditing, administering
the servers, spreading the word, answering questions on the mailing
lists, or helped with donations.

*Thank you all*

   Your GnuPG hackers


p.s.
This is an announcement only mailing list.  Please send replies only to
the gnupg-users at gnupg.org mailing list.

* List of Release Signing Keys:
  To guarantee that a downloaded GnuPG version has not been tampered by
  malicious entities we provide signature files for all tarballs and
  binary versions.  The keys are also signed by the long term keys of
  their respective owners.  Current releases are signed by one or more
  of these four keys:

    ed25519 2020-08-24 [SC] [expires: 2030-06-30]
    6DAA 6E64 A76D 2840 571B  4902 5288 97B8 2640 3ADA
    Werner Koch (dist signing 2020)

    ed25519 2021-05-19 [SC] [expires: 2027-04-04]
    AC8E 115B F73E 2D8D 47FA  9908 E98E 9B2D 19C6 C8BD
    Niibe Yutaka (GnuPG Release Key)

    rsa3072 2025-05-09 [SC] [expires: 2033-03-03]
    3B76 1AE4 E63B F351 9CE7  D63B ECB6 64CB E133 2EEF
    Alexander Kulbartsch (GnuPG Release Key)

    brainpoolP256r1 2021-10-15 [SC] [expires: 2029-12-31]
    02F3 8DFF 731F F97C B039  A1DA 549E 695E 905B A208
    GnuPG.com (Release Signing Key 2021)

  The keys are available at https://gnupg.org/signature_key.html and in
  any recently released GnuPG tarball in the file g10/distsigkey.gpg .
  Note that this mail has been signed by a different key.

* Debian Package Signing Key:
  The new Debian style packages are signed using this key:

  ed25519 2025-07-08 [SC] [expires: 2035-07-14]
  3209 7B71 9B37 45D6 E61D DA1B 85C4 5AE3 E1A2 B355
  GnuPG.org Package Signing Key <package-maintainers@gnupg.org>

  See the package website (https://repos.gnupg.org/deb/gnupg) for a list
  of supported distributions and a download link for the key.

-- 
Arguing that you don't care about the right to privacy because you have
nothing to hide is no different from saying you don't care about free
speech because you have nothing to say.                - Edward Snowden




Attachment: openpgp-digital-signature.asc (type=application/pgp-signature)

-----BEGIN PGP SIGNATURE-----

iJ8EARYKAEcWIQSHd0YfKgdOvEgNNZQZzByeCFsQegUCaXjsphsUgAAAAAAEAA5t
YW51MiwyLjUrMS4xMSwyLDINHHdrQGdudXBnLm9yZwAKCRAZzByeCFsQekUGAQC1
pA+RRDDOQ+xvT7K+NFpC0m4jIXXauqD6KZl9Y1rUtgD7BZ9tNJpmUmiJAXafrsYj
1UzcHa/YSExaM5FR5/MqRgc=
=frcX
-----END PGP SIGNATURE-----



Attachment: None (type=text/plain)

_______________________________________________
Gnupg-announce mailing list
Gnupg-announce@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-announce




Attachment: None (type=text/plain)

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-devel

to post comments

Note on the provided Debian packages

Posted Jan 27, 2026 19:02 UTC (Tue) by gwolf (subscriber, #14632) [Link] (5 responses)

The GnuPG announcement has a section on “Debian Packages”. Please note that GnuPG is packaged _in_ Debian, but the Debian maintainers have chosen not to package the 2.5 branch of GnuPG. If you download the package following the instructions this announcement includes, you will switch away from a standards-abiding OpenPGP implementation to one that will surely cause interoperability problems, due to the GnuPG author's decision to steer away from the OpenPGP standard and fork into what they call “LibrePGP”.

Note on the provided Debian packages

Posted Jan 27, 2026 19:13 UTC (Tue) by NYKevin (subscriber, #129325) [Link] (4 responses)

Since Debian chooses not to package 2.5, is it safe to assume that Debian users (who are using the Debian-provided packages) are not affected?

Note on the provided Debian packages

Posted Jan 27, 2026 19:23 UTC (Tue) by gwolf (subscriber, #14632) [Link] (1 responses)

The Debian Package Tracker ( https://tracker.debian.org/pkg/gnupg2 ) mentions CVE-2025-68972 affects the version of GnuPG currently in unstable and testing (Sid and Forky). This CVE has been dealt with in the version in the stable (13, Trixie) release ( https://tracker.debian.org/news/1703011/accepted-gnupg2-2... ), and backported to oldstable (12, Bookworm) and oldoldstable (11, Buster).

Note on the provided Debian packages

Posted Jan 28, 2026 9:35 UTC (Wed) by cortana (subscriber, #24596) [Link]

The security bug tracker is a bit better for tracking CVEs and the Debian releases that contain vulnerable/fixed packages:

https://security-tracker.debian.org/tracker/source-packag...

Note on the provided Debian packages

Posted Jan 27, 2026 19:26 UTC (Tue) by gwolf (subscriber, #14632) [Link] (1 responses)

Oh, but silly me — the article addresses a bug for which “a CVE-id has not been assigned.” So my answer is misguided, sorry for the noise!
Anyway, the list of versions affected by this issue are all within the 2.5.x series, so... No, the packages in Debian should not be affected, AFAICT.

Note on the provided Debian packages

Posted Jan 29, 2026 13:45 UTC (Thu) by santiago (subscriber, #105758) [Link]

FTR and posterity: this issue is CVE-2026-24881.

One of the worst UI ever

Posted Jan 27, 2026 21:44 UTC (Tue) by cyperpunks (subscriber, #39406) [Link] (10 responses)

GnuPG is a real pain to use, the user interface is just horrible.

If the software logic is mirrored by the ui the internals must be a messy pile of cr*p.

It's impossible to trust such thing. Using archaic C to write software in 2026 should plain and simple be forbidden.

One of the worst UI ever

Posted Jan 28, 2026 9:44 UTC (Wed) by lmartelli (subscriber, #11755) [Link] (4 responses)

GnuPG was first released 1997-12-20 (see https://www.gnupg.org/download/release_notes.html), when C/C++ was the obvious/default choice to start any software project like this.

One of the worst UI ever

Posted Jan 28, 2026 15:39 UTC (Wed) by Heretic_Blacksheep (subscriber, #169992) [Link] (3 responses)

But not the only choice in 1997. There were better languages and tooling even in 1997 like Ada, but tribal/religious arguments poopooed them similar to the nasty back and forth between C zealots and other systems oriented languages today.

One of the worst UI ever

Posted Jan 28, 2026 16:01 UTC (Wed) by anselm (subscriber, #2796) [Link]

To be fair, in 1997 gcc was very widespread but the Ada frontend to gcc wasn't. Irrespective of the relative merits of Ada vs. C as programming languages, if you wanted wide portability for a tool like GnuPG, then C was at least a very strong contender because C compilers were a lot easier to come by than Ada compilers.

One of the worst UI ever

Posted Jan 28, 2026 16:22 UTC (Wed) by farnz (subscriber, #17727) [Link]

Ada's major fault back in 1999 (when I looked at it for work purposes) was the lack of a decent, Free (or even cheap) compiler. GNAT didn't become a decent Ada compiler until 2004 or so.

It was literally priced out of the market at the time - Keil's C compiler for Infineon C16x, while awful, was the same price for a company-wide licence as the cheapest Ada compiler I could find, and that would have been an add-on to VxWorks.

One of the worst UI ever

Posted Jan 31, 2026 14:31 UTC (Sat) by apoelstra (subscriber, #75205) [Link]

The problem that leads many cryptography libraries to use C, even in modern times, is that C gives you tooling to write constant-time code -- no runtime, obscene pointer semantics that make it possible to prevent compiler assumptions about pointer access ordering or aliasing (and extensions for explicit fences and the like); the ability to write zero-heap-allocation code; low-level debuggers and dissemblers; and of course, inline assembler.

C is arguably awful at each individual thing I listed, but it has them all, and to the extent that some of them are a black art, there exist people with decades of experience working with popular compilers to achieve them.

Now, maybe gnupg could've written its core secret-data-handling crypto algorithms in C (or assembler) and used FFI bindings to use a nicer language for everything else. But then you'd need a language and toolchain that can mix well with C.

One of the worst UI ever

Posted Jan 28, 2026 13:40 UTC (Wed) by hmh (subscriber, #3838) [Link] (2 responses)

Please hold anything doing dependency-hell / supply-chain-hell to the same standard.

In both cases (C and dependency-hell language ecosystems), proper discipline (which DOES include strong linting and static checking, etc) goes a long way to avoid the pitfalls.

I do think "C" should be kept away from inexperienced, lazy, or vibe-coders though. And I certainly agree there are much better choices for new projects/greenfield, unless the requirements force you towards C/C++ (typically on small embedded).

One of the worst UI ever

Posted Jan 29, 2026 8:58 UTC (Thu) by taladar (subscriber, #68407) [Link] (1 responses)

We should reconsider the use of the term "dependency hell", especially if people just use it as a synonym for "large number of dependencies" because a lot of languages with small numbers of dependencies have small numbers because the cost of starting a new dependency is high due to bad tooling and as a result each dependency is huge and contains a lot of code any given user of that dependency does not use and that nobody has touched for years.

This is just a worse way to structure the same amount of dependency code because we can't easily talk about individual parts of the code in dependencies.

One of the worst UI ever

Posted Jan 29, 2026 13:43 UTC (Thu) by ptime (subscriber, #168171) [Link]

I would consider having boost as your only dependency a great example of being in hell

One of the worst UI ever

Posted Feb 2, 2026 17:22 UTC (Mon) by cytochrome (subscriber, #58718) [Link] (1 responses)

"the internals must be a messy pile of cr*p." Have you looked at the internals? Do you have some examples you could share or constructive advice/PRs to provide to the developers?

One of the worst UI ever

Posted Feb 2, 2026 18:48 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

It's pretty much a certainty that any GNU C code written before 2010-s is a mess. GPG is no exception. E.g. look at this: https://github.com/gpg/gnupg/blob/987c6a398a9505399b2c25a...

Static buffers with manual length calculation, stpcpy, juggling pointers in security-critical code. What could possibly go wrong?

Why even bother with FIPS?

Posted Jan 28, 2026 9:13 UTC (Wed) by mirabilos (subscriber, #84359) [Link]

I see it as cause for so many problems in so many softwares over the years, and it’s only needed by the american government anyway.

awful TPM fix

Posted Jan 28, 2026 10:24 UTC (Wed) by johill (subscriber, #25196) [Link] (3 responses)

Some of this might be baked into the TPM APIs, but e.g. the TPM fix still seems awful to me.

No mention of sizeof(), even if it seems that something like 

 if (len > sizeof(VAL_2B (inPoint.point.x, buffer))
    return GPG_ERR_TOO_LARGE;
should be sufficient to avoid the memcpy() overflow, and the TPM must be doing input validation as well, so shouldn't that be sufficient? For the Intel stack I checked and point.x.buffer is that size (TPM2_MAX_ECC_KEY_BYTES).

Also, it seems that even simple static checkers could have found this, so don't they use those, or at least not with TPM enabled?

awful TPM fix

Posted Jan 28, 2026 11:02 UTC (Wed) by dd9jn (✭ supporter ✭, #4459) [Link] (2 responses)

> the TPM fix still seems awful to me.

I agree but it is the best solution we could do with less risk of a regression. The whole TPM API is a total mess and worse, there are actually two implementations (IBM and Intel) we need to support. Fortunately, exploiting the bug needs access to the local socket and if you have this access it is anyway game-over.

I also wonder why the static analyzers didn't find that bug or at least the even more obvious one from 1999 in armor.c (T7906) which has actually seen several Coverity runs.

Why are TPMs so hard?

Posted Jan 31, 2026 3:13 UTC (Sat) by DemiMarie (subscriber, #164188) [Link] (1 responses)

What makes TPMs so hard to use? Is it that the underlying hardware is complex of necessity?

Why are TPMs so hard?

Posted Feb 2, 2026 14:00 UTC (Mon) by johill (subscriber, #25196) [Link]

It looks to me more like the libraries are a mess, you have to use two different ones, and they don't have the same APIs even though the API was kind of meant to be speced?

But the argument is a bit besides the point - I gave two lines that I'm pretty sure (only checked one of the two cases for exact bytes count) do an equivalent check without an ifdef maze...


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds