The gpg.fail aftermath: On responsible disclosure, GPG, and the state of security in 2026 [32:37]
14 points by dzwdz
14 points by dzwdz
In 2025, I [the speaker] found and disclosed a bunch of vulnerabilities in GPG, the most used PGP implementation, and held a talk at 39c3 about it. Some of the bugs ended up getting fixed. This talk describes the adventure and aftermath of getting there, shows some novel ones, and talks about the state of security in 2026. May contain zero-days =)
Until May 2025, I liked PGP, and the GNU Privacy Guard. I poked at it in my free time a lot. One day, that suddenly changed, when I flew too close to the sun and ended up uncovering a vulnerability that allows you to easily spoof a PGP signature when opened naively with the GPG tool.
Fast-forward a couple of months, the one vulnerability turned into several independent ones, up to memory corruption in the basic PGP message parser, affecting almost all PGP-related workflows.
I disclosed these a few weeks before 39c3 in December 2025. And while some of the vulnerabilities - like the memory corruption in the message parser - got addressed properly, this was not the case for all of them.
For example, one of the first vulnerabilities I found, that was used for the introduction hook in the 39c3 talk, remains unpatched to this day. Instead of being fixed with code, Werner Koch - the main developer of GnuPG - published a blog post declaring the widely-used feature being "harmful"; while they had weeks in advance, they published this on day one of 39c3, not even giving us time to respond.
Several disgruntled comments followed, but a good portion of the flaws are still not addressed, as I will demonstrate live in the talk. This specific demonstration will not utilize any zero-day vulnerabilities (those come next); we will be showing how much of an issue the footguns (that they refuse to address) at hand really are.
Additionally, I will present a few novel vulnerabilities on GPG. Not quite the bombshells as last time, but some nifty bugs that should never have made it into production in the first place, but to demonstrate the state of the GnuPG codebase.
The talk closes with some general commentary about the state of security and responsible disclosure, and touch on the topic of AI/LLMs in security (with some of the gpg.fail vulnerabilities as examples); what this means for security researchers, ordinary people and software developers (spoiler: neither end users nor security researchers are doomed).
Links to some of the things referenced in the talk:
Thanks for sharing and working on this; I read the slides but haven't had the opportunity to watch the video yet. Edit: finished the talk; very nice!
I'm really glad a lot of the ecosystem has moved over to Sequoia; hopefully we're not too far off from GPG being dethroned as the primary OpenPGP implementation. I entirely missed the "Sequoias need for churn" blog post from last year, it's pretty ridiculous!
I'm still making my way through this, but with regard to...
Last correctly signed commit from 2024 and so on, this assumes GitHub's 'verified' button is the correct way to assess signatures.
I don't ever rely on that (sure, some might) and check with git log --show-signature and some other such bits. I would expect anyone seriously checking whether GnuPG commits are signed to do that or something similar rather than rely on the UI, which could mislead as to which key was used.
I try to keep my own keys on various forges up-to-date but I may well forget, especially for ones that are project-specific (self-hosted GitLab).
We use PGP heavily in Gentoo for example, all commits must be signed on most of our repositories, but not all developers upload keys to GitHub. Possibly even "many" don't.
But apparently nobody ever bothered to check if the signatures actually work…
I'd be a bit worried if someone took the GitHub UI as sign of it working, to be fair!
Wow, what a clown show - if you don’t care about responsible disclosure (a perfectly reasonable position to take as unpaid maintainers), then that should be made clear.
It allows researchers who do care to contact downstream distributors first, rather than risking this kind of nonsense.
It also means downstream users are better able to quantify the zero day risks they face from using your code.