ZeroHour
DashboardNewsCVEsExploitsIncidentsAIBriefAnalyticsEntitiesWatchlistIOCsAsk the feedSourcesFeeds & APIKiosk mode

Search: “gpg.fail”

9 items

Searchkeywordsmart Sortlatesthotimportancerelevance
DomainAllCyberAIWindow24h3d7d30dAllIn the wildImportant onlyShow duplicates
CategoryAllResearch 5Vulnerability 4
SeverityAllcritical 0high 1medium 2low 2info 4

Retrospective by 'gpg.fail' authors

Authors of the gpg.fail GnuPG vulnerability set published a retrospective with talk recording, slides, and a repo PoC.

Sam James shares that the researchers behind the 'gpg.fail' set of GnuPG vulnerabilities have published a retrospective, including a talk recording and slides. The slides appear to mention an additional vulnerability not yet widely reviewed, and a proof-of-concept is available in their repository. This follows earlier discussion of the gpg.fail findings on oss-security.

oss-securityupdated · 1h agofirst · 3d agoResearch 8 sources1

Re: Retrospective by 'gpg.fail' authors

oss-security follow-up to a gpg.fail authors' retrospective argues that GnuPG's unmaintained, forgotten code is a security liability and should be deleted.

On the oss-security mailing list, Soatok Dreamseeker responds to a retrospective published by the gpg.fail authors, asking why unmaintained code is retained and stating that forgotten, unmaintained code is a liability and effectively unmaintained by definition. The visible reply addresses Werner Koch and concerns GnuPG code maintenance. No specific CVE, flaw, or exploitation is described in this snippet.

oss-security · 1h agoVulnerability 8 sources

Re: Retrospective by 'gpg.fail' authors

GnuPG maintainer Werner Koch responds on oss-security to a gpg.fail retrospective covering 2003-era GnuPG code.

On oss-security, GnuPG lead developer Werner Koch replied to a retrospective published by the gpg.fail authors, citing a December 2003 commit in GnuPG's gettime.c affecting asctimestamp and printf format attributes in util.h. The excerpt contains no new CVE identifiers or exploitation evidence, and appears to revisit long-standing historical GnuPG code paths discussed by the retrospective's authors.

oss-securityupdated · 1h agofirst · 3h agoResearch 8 sources

Re: Retrospective by 'gpg.fail' authors

GnuPG's Werner Koch says gpg.fail samples only crash GnuPG via DER-as-printf format string in --debug x509; RCE claim remains unproven.

Werner Koch replied to the gpg.fail retrospective, noting that GnuPG versions above 2.2 produce garbled stderr or crash when the project's certificates are used with --debug x509 because DER data is passed as a printf format string. Testing the certificates from the researchers' Git repo yielded only a segfault, not demonstrated code execution. Koch states how remote code execution would be achieved is unclear and asks for a real reproducer.

oss-securityupdated · 1h agofirst · 1d agoVulnerability 8 sources

Re: Retrospective by 'gpg.fail' authors

Unreported 0-day RCE in gpgsm 2.4.9 disclosed via gpg.fail talk, triggered by importing a malicious certificate with --debug options.

A retrospective by the gpg.fail authors revealed a remote code execution vulnerability in gpgsm 2.4.9, triggered when invoked as "gpgsm --debug all --import" with a malicious certificate file. The researchers did not report the issue to GnuPG, leaving it unpatched as an apparent 0-day. Exposure appears limited since it requires importing untrusted certificates with debug options enabled.

oss-securityupdated · 1h agofirst · 1d agoVulnerability 8 sources

Re: Retrospective by 'gpg.fail' authors

Peter Gutmann replies to gpg.fail retrospective, pointing to PGP's arbitrary packet format as root of many past vulnerabilities.

Peter Gutmann posted a follow-up on oss-security referencing an Hacker News discussion of the gpg.fail authors' retrospective. The thread argues that a recurring source of severe PGP vulnerabilities is the format's permissive packet system, where a PGP message is a practically arbitrary stream of packets. This is discussion and retrospective analysis rather than a new disclosure.

oss-securityupdated · 1h agofirst · 3d agoResearch 8 sources4

The gpg.fail aftermath: On responsible disclosure, GPG, and the state of security in 2026 [32:37]

A conference talk recounts GPG vulnerability disclosures, notes several GnuPG flaws remain unpatched, and demonstrates novel bugs live.

A researcher who disclosed multiple GnuPG vulnerabilities before 39c3 in December 2025 reports that several flaws, including one allowing spoofed PGP signatures, remain unpatched. Memory corruption in the basic PGP message parser was properly fixed, but GnuPG maintainer Werner Koch declared a widely-used feature 'harmful' instead of patching it. The talk presents additional novel GPG vulnerabilities and commentary on responsible disclosure and LLMs in security.

Lobsters · security · 4d agoResearch

Re: Retrospective by 'gpg.fail' authors

Sam James replies to GnuPG author Werner Koch that upstream may freely adopt stricter -W compiler warnings, while distros should avoid blanket -Werror.

This is an oss-security mailing list reply by Sam James (Gentoo toolchain maintainer) to Werner Koch in the thread on the 'gpg.fail' authors' retrospective about GnuPG. James states that upstream projects like GnuPG should feel free to enable whatever -W* warning flags they need. He adds that distributions should not use -Werror indiscriminately, allowing narrow exceptions such as -Werror=format-security, and may reject warning-driven bugs that do not reflect real issues. No new CVE or vulnerability details are disclosed in this reply.

oss-securityupdated · 1h agofirst · 13h agoVulnerability 8 sources

Re: Retrospective by 'gpg.fail' authors

GPG exploitation talk author clarifies a format-string 0day enabling code execution via printf %n writes and a polyglot PEM certificate payload.

Lexi Groves, author of the gpg.fail talk, clarified on oss-security that the first finding was an actual zero-day: a classic printf injection using %n for memory writes, with multiple X.509 certificates in one PEM file to re-enter and defeat ASLR before calling execv@plt. The payload executed the certificate itself, a polyglot file made by inserting a shebang and bash command into the PEM. A second finding was hash-collided by another party before the author could exploit it.

oss-securityupdated · 1h agofirst · 17h agoResearch 8 sources