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, this meant that 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 enables multiple analysts to share and synchronize binary analysis through centralized repositories, making the integrity of its authentication system directly relevant to the security of sensitive reverse engineering work.
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 resides in the PKIAuthenticationModule.authenticate() method, which handles authentication when Ghidra Server is running in PKI mode (the -a2 flag). Under 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 performing 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. Although Ghidra Server in PKI mode enforces mutual TLS with needClientAuth=true at the transport layer, there is no binding between the certificate presented during the SSL/TLS handshake and the certificate submitted at the application layer via SignatureCallback. The source code itself acknowledges this limitation with 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 providing a valid cryptographic signature over the server's challenge token, the attacker provides null (empty) signature bytes.
-
Verification bypass:
PKIAuthenticationModule.authenticate()encounters the null check, determinessigBytesis null, and skips the entire signature verification block. -
DN resolution and session grant: The method proceeds to resolve 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
The requirements for exploitation are modest in organizational environments:
| 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 due to 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. This spans from the initial open source release in March 2019 through version 12.0.4 (released March 4, 2026), representing 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 their exposure.
Vendor Security History
Ghidra has experienced multiple publicly disclosed security vulnerabilities over its lifetime:
| 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, with the highest impact being code execution via remote access.
The NSA's response to CVE-2026-52754 was notably thorough. Rather than applying a minimal patch, the team refactored the entire PKI framework across 41 files (+1,169 / -1,285 lines), migrating logic into new hardened classes (PKIUtils, DefaultSSLContextInitializer, DefaultTrustManagerFactory) to ensure the null signature bypass pattern cannot recur in any subsystem. The fix was developed in collaboration with Oceanit software engineers.
An interesting aspect of this vulnerability's discovery: the null signature technique was initially identified by Claude (Anthropic's AI assistant) during research by the MAD Bugs project. The reporter credited in the official advisory is @jro-calif, and the finder is Sean Nejad (@allsmog). This represents a notable instance 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)



