Talks
The gpg.fail aftermath: On responsible disclosure, GPG, and the state of security in 2026
MRMCD 2026 · Recording · YouTube · Slides · PoC files & sources
In 2025, I 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).
To sign or not to sign: Practical vulnerabilities in GPG & friends (gpg.fail)
39c3 2025 · Recording · YouTube · Slides · Website
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.
Wenn der Verkehrsverbund zu transparent ist
MRMCD 2025 · Recording · YouTube (has translated subtitles)
How to get from Google to a small data leak, how to escalate a small data leak into a large one, and how to handle it properly.
In this talk, we show how a large public transport association was a little too transparent and how we dealt with it.
Pwning the entire Nix ecosystem
NixCon 2024 · Recording
Security research project that was done entirely on the 3-day conference, from finding the vulnerability, registering the talk and writing & presenting the slides, with the first joke, then serious motto "nixcon doesn't have a CTF so we made our own". Involved mostly CI security vulnerabilities, and traditional UNIX CLI exploitation to get a R/W primitive on the entire OS infrastructure of NixOS