Introduction
A seven-year-old authentication bypass in NSA's Ghidra Server allowed any user holding a valid CA-signed certificate to silently impersonate other users, including administrators, by submitting a null cryptographic signature during PKI authentication. For organizations using Ghidra Server's collaborative reverse-engineering capabilities with PKI mode enabled, the cryptographic identity verification protecting shared analysis repositories was effectively optional.
Ghidra is the NSA's free, open-source software reverse-engineering framework, released publicly in March 2019 as an alternative to commercial tools like IDA Pro. It has been widely adopted across government agencies, defense contractors, academic institutions, and private-sector security teams. The Ghidra Server component lets multiple analysts share and synchronize binary analysis through centralized repositories, so the security of sensitive reverse-engineering work depends directly on the integrity of its authentication system.
Technical Information
CVE-2026-52754 is classified under CWE-347: Improper Verification of Cryptographic Signature. The vulnerability carries a CVSS v3.1 base score of 8.8 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) and a CVSS v4.0 score of 8.7 from VulnCheck.
Root Cause: Conditional Signature Verification
The vulnerability is in the PKIAuthenticationModule.authenticate() method, which handles authentication when Ghidra Server runs in PKI mode (the -a2 flag). In normal operation, this module implements a challenge-response protocol: the server sends a random 64-byte token, the client signs it with their private key, and the server verifies the signature against the client's public certificate.
The flaw is a conditional null check in the verification logic. The code checks if (sigBytes != null) before it performs signature verification. When an attacker supplies null signature bytes, the entire verification block is skipped. Execution falls through to the Distinguished Name (DN) lookup, which resolves the certificate's subject DN to a username and authenticates the session as that user without any cryptographic proof of identity.
This pattern is directly analogous to JWT null signature attacks, where omitting or nullifying the signature field causes verification logic to accept unsigned tokens.
The Missing TLS-to-Application Binding
A fundamental design gap compounds the vulnerability. Ghidra Server in PKI mode enforces mutual TLS with needClientAuth=true at the transport layer, but nothing binds the certificate presented during the SSL/TLS handshake to the certificate submitted at the application layer via SignatureCallback. The source code acknowledges this limitation in a comment noting there is "no way to obtain PKI credentials used when authenticating SSL connection with client."
This decoupling is what makes impersonation possible. The attacker authenticates at the TLS layer with their own legitimate certificate, then presents a completely different certificate (the victim's) at the application layer.
Step-by-Step Exploitation Flow
-
TLS handshake: The attacker connects to the Ghidra Server and completes the mutual TLS handshake using their own valid CA-signed certificate. This satisfies the transport layer's
needClientAuth=truerequirement. -
Certificate substitution: At the application layer, the attacker submits the target user's public X.509 certificate via the
SignatureCallbackmechanism. Public certificates are not secrets in PKI deployments and are readily available. -
Null signature injection: Instead of a valid cryptographic signature over the server's challenge token, the attacker provides null (empty) signature bytes.
-
Verification bypass:
PKIAuthenticationModule.authenticate()reaches the null check, finds thatsigBytesis null, and skips the entire signature verification block. -
DN resolution and session grant: The method resolves the target certificate's subject Distinguished Name to a username and authenticates the session as the impersonated user.
-
Post-exploitation: The attacker now operates with the victim's full permissions. If the target is an administrator, the attacker can rewrite repository access controls, exfiltrate shared reverse-engineering databases, or permanently delete analysis data.
Prerequisites
In organizational environments, the requirements for exploitation are modest:
| Requirement | Detail |
|---|---|
| Network access | Attacker must reach the Ghidra Server's network port |
| Valid CA-signed certificate | Any certificate signed by the same CA trusted by the Ghidra Server |
| PKI authentication mode | Server must be running with -a2 |
| Target user's public certificate | The public X.509 certificate of the user to impersonate (not a secret) |
| Victim's private key | Not required, because of the null signature bypass |
In enterprise environments where CA certificates are issued to all employees or contractors, the barrier to exploitation is low.
Affected Systems and Versions
All versions of Ghidra prior to 12.1 are affected. That covers everything from the initial open-source release in March 2019 through version 12.0.4 (released March 4, 2026), approximately seven years of deployments.
The vulnerability is specific to Ghidra Server instances running in PKI authentication mode, enabled with the -a2 command-line flag. Servers running in password-based authentication mode (-a1) are not affected by this specific vulnerability.
Any organization that has ever deployed Ghidra Server with PKI authentication should evaluate its exposure.
Vendor Security History
Ghidra has had multiple publicly disclosed security vulnerabilities:
| Identifier | Description | Severity | Affected Versions |
|---|---|---|---|
| CVE-2026-52754 | PKI null signature authentication bypass | High (8.8) | All versions before 12.1 |
| CVE-2026-4946 | Improper processing of annotation directives in binary data | Not specified | Versions before 12.0.3 |
| 2019 XXE flaw | XML External Entity injection enabling remote code execution | Critical | Early versions |
A cybersecurity help security bulletin (SB20260515104) documents 9 total vulnerabilities in Ghidra and lists code execution via remote access as the highest impact.
The NSA's response to CVE-2026-52754 went well beyond a minimal patch. The team refactored the entire PKI framework across 41 files (+1,169 / -1,285 lines) and moved the logic into new hardened classes (PKIUtils, DefaultSSLContextInitializer, DefaultTrustManagerFactory) so that the null signature bypass pattern cannot recur in any subsystem. Oceanit software engineers collaborated on the fix.
Claude (Anthropic's AI assistant) initially identified the null signature technique during research by the MAD Bugs project. The official advisory credits @jro-calif as the reporter and Sean Nejad (@allsmog) as the finder. It is a notable case of AI-assisted vulnerability discovery in a government-developed security tool.
References
- GitHub Security Advisory: GHSA-5wxq-7qpv-65p2
- VulnCheck Advisory: Ghidra Authentication Bypass via Null Signature
- GP-6155 Refactor of PKI framework support (Commit 78729379)
- Ghidra 12.1 Release Commit (79d8f164)
- MAD Bugs: Claude Found an Auth Bypass in NSA's Ghidra Server
- Ghidra Security Overview (GitHub)
- SB20260515104: Multiple Vulnerabilities in Ghidra
- Oceanit: Software Engineers Help Fix Vulnerability in NSA Cybersecurity Tool
- CISA Known Exploited Vulnerabilities Catalog
- NSA Ghidra Official Page
- Ghidra (Wikipedia)



