Monero GUI Fix Rejects Revoked OpenPGP Signing Subkeys

Monero GUI developers have merged a change to how the wallet selects OpenPGP signing subkeys when checking software updates. PR #4770 rejects subkeys marked as revoked and uses the newest binding signature to decide whether a subkey may sign data. The change addresses which keys the verifier accepts.

The pull request merged on November 9, 2026, at 20:43 UTC. The latest stable GUI release checked for this article, v0.18.5.4, still contains the earlier selection logic. A merge into the development branch does not update an installed wallet. We checked release status on November 10 UTC.

Signing permission and revocation

An OpenPGP certificate can contain a primary key and subkeys. A binding signature associates a subkey with that certificate and can specify its permitted uses. Revocation records tell software to stop accepting the key for that purpose.

Those records matter even when a signature's mathematics checks out. An old signing key can still produce a mathematically valid signature after its owner revokes it. Verification must also enforce the rules governing that key.

Monero GUI's updater code loads maintainer certificates bundled with the application. It uses the keys selected from those certificates to verify signatures on release-hash information. It is not importing an arbitrary key supplied by a download server for each update.

An attacker who alters a download would still need a signature that the bundled trust store accepts.

Later certificate records could not change the decision

The v0.18.5.4 parser considers the first signature packet following a subkey. If that record is a binding that permits signing, it adds the RSA subkey to the accepted keys. It then stops tracking that subkey, so later signature packets cannot change that decision.

Consider a certificate containing a subkey, an older signing authorization and a later revocation. Under that selection logic, the earlier authorization can admit the subkey before the parser reads the revocation. A later binding that removes signing permission presents a related problem. This example illustrates the code's selection behavior.

The merged code instead examines the associated signature packets before deciding whether to keep a subkey. A subkey-revocation packet prevents selection. Among binding signatures, it chooses the one with the newest creation timestamp and checks that binding's signing flag. Marker and Trust packets no longer interrupt that sequence.

Attacker prerequisites and other update checks

We also inspected the public certificates bundled through the GUI's pinned Monero dependency. The binaryfate, fluffypony and luigi1111 files each contain one subkey binding and no subkey-revocation packet. The stable tag and reviewed development commit use the same dependency revision. This packet inspection did not find the conflicting records used in the example above. It does not establish the current status of certificates distributed elsewhere.

The relevant prerequisite is an otherwise usable signing subkey in a certificate the application already trusts. To misuse that key for a malicious signature, an attacker would need its private signing material. This parser issue does not provide that private key.

Other updater checks also matter. In the reviewed development code, the updater requires signatures attributed to two different bundled maintainers, checks the selected release hash against DNS-provided information, and compares downloaded data with its expected hash. Describing this parser change as a complete update-verification bypass would ignore those checks. These observations come from the updater code, not from a demonstrated end-to-end attack.

The inspected description, reviews and comments do not report exploitation. They do not establish a stolen maintainer key or compromised Monero release.

The verifier still has a defined scope

The change reads revocation and binding records from the certificate the application supplies. It does not add a service that retrieves fresh revocations from the internet. An old application with an old bundled certificate cannot learn a later revocation merely because this parser exists in a newer development commit.

The source also retains a TODO for public-key expiration, certification and cryptographic verification of subkey binding signatures. Reading binding metadata is not the same as applying every OpenPGP certificate-validation rule. That limitation matters when assessing what this patch establishes. It does not justify treating arbitrary, untrusted certificate material as safe input to a general-purpose trust system.

Review, tests and release availability

Selsta approved the reviewed commit before the merge. At our check, GitHub reported eight successful checks and one cancelled macOS ARM bundle check for that head commit. The two-file PR does not add regression tests for the changed selection behavior, so successful builds alone leave its edge cases unverified.

We compared the changed parser with the tagged stable source and inspected its updater caller. We did not compile the GUI or reproduce a malicious-update chain. We have not established the first release containing the earlier parser behavior. The checked stable certificates do not demonstrate an exploitable revoked-subkey case, and we did not identify a patched stable release.

Users can follow the official Monero download-verification guide when installing software. It explains checking signing-key fingerprints, signatures and file hashes. Investigate a verification failure before installing the software. This article concerns software authenticity, separate from the payment and spend proofs discussed in our transaction-proof verification report.