CVE-2026-25793 Overview
CVE-2026-25793 is a cryptographic vulnerability affecting Nebula, a scalable overlay networking tool developed by Slack. The vulnerability allows attackers to bypass blocklist entries by exploiting ECDSA Signature Malleability in P256 certificates. When using P256 certificates (which is not the default configuration), an attacker can create a copy of a blocked certificate with a different fingerprint, effectively evading security controls designed to prevent specific certificates from connecting to the network.
Critical Impact
Attackers can evade blocklist-based certificate revocation by manipulating ECDSA signatures to produce alternate valid fingerprints, potentially allowing unauthorized access to Nebula overlay networks.
Affected Products
- Nebula versions 1.7.0 through 1.10.2
- Systems configured to use P256 certificates (non-default configuration)
- Nebula overlay networks relying on certificate fingerprint blocklists for access control
Discovery Timeline
- February 6, 2026 - CVE CVE-2026-25793 published to NVD
- February 9, 2026 - Last updated in NVD database
Technical Details for CVE-2026-25793
Vulnerability Analysis
This vulnerability stems from improper verification of cryptographic signatures (CWE-347) in Nebula's certificate handling code. ECDSA signatures have a well-known property called signature malleability, where for any valid signature (r, s), the signature (r, -s mod n) is also mathematically valid. This means the same certificate can have multiple valid signature representations.
The core issue is that Nebula's blocklist mechanism relies on certificate fingerprints, which include the signature bytes. Since ECDSA signatures can exist in both "high-S" and "low-S" forms while remaining cryptographically valid, an attacker with a blocked certificate can compute the alternate signature form, resulting in a different fingerprint that is not present in the blocklist.
This attack requires network access and a valid (but blocked) P256 certificate. The attacker can leverage the mathematical properties of ECDSA to transform their certificate's signature, creating what is effectively a "clone" certificate that the Nebula system will accept despite the original being blocklisted.
Root Cause
The root cause is the failure to normalize ECDSA signatures to a canonical form before calculating certificate fingerprints. Prior to version 1.10.3, Nebula could generate signatures in either high-S or low-S form and validation accepted both. Since the fingerprint is calculated over the signature bytes, certificates with mathematically equivalent but bytewise different signatures produce different fingerprints, allowing blocklist evasion.
Attack Vector
The attack is network-based and requires the attacker to possess a P256 certificate that has been blocklisted. The attacker can:
- Take their blocklisted certificate with signature (r, s)
- Compute the alternate signature (r, -s mod n) (flipping between high-S and low-S form)
- Present the modified certificate to Nebula
- The fingerprint check passes since the alternate fingerprint is not in the blocklist
- Gain unauthorized access to the overlay network
// Security patch in cert/ca_pool.go - Merge commit from fork
return nil, err
}
+ // Pre nebula v1.10.3 could generate signatures in either high or low s form and validation
+ // of signatures allowed for either. Nebula v1.10.3 and beyond clamps signature generation to low-s form
+ // but validation still allows for either. Since a change in the signature bytes affects the fingerprint, we
+ // need to test both forms until such a time comes that we enforce low-s form on signature validation.
+ fp2, err := CalculateAlternateFingerprint(c)
+ if err != nil {
+ return nil, fmt.Errorf("could not calculate alternate fingerprint to verify: %w", err)
+ }
+ if fp2 != "" && ncp.IsBlocklisted(fp2) {
+ return nil, ErrBlockListed
+ }
+
cc := CachedCertificate{
Certificate: c,
InvertedGroups: make(map[string]struct{}),
Fingerprint: fp,
+ fingerprint2: fp2,
signerFingerprint: signer.Fingerprint,
}
Source: GitHub Commit Change Log
Detection Methods for CVE-2026-25793
Indicators of Compromise
- Certificate connection attempts where the fingerprint differs from known certificates but cryptographic validation succeeds
- Multiple connection attempts from the same identity using certificates with different fingerprints
- Blocklisted certificates appearing to successfully authenticate under alternate fingerprints
Detection Strategies
- Monitor Nebula logs for certificates that should be blocklisted but are being accepted
- Implement alerting on connection attempts from certificates with fingerprints that match the alternate (high-S or low-S) form of blocklisted certificates
- Audit P256 certificate usage across your Nebula deployment to identify at-risk configurations
Monitoring Recommendations
- Enable verbose logging on Nebula lighthouses and relay nodes to capture certificate fingerprints during authentication
- Create monitoring rules that correlate blocklist updates with subsequent connection patterns
- Review certificate issuance logs to track all certificates that should be revoked
How to Mitigate CVE-2026-25793
Immediate Actions Required
- Upgrade Nebula to version 1.10.3 or later immediately
- Review blocklists and add both high-S and low-S fingerprint variants for any blocked certificates if unable to upgrade immediately
- Audit network access logs for any suspicious authentication from previously blocklisted certificates
- Consider regenerating certificates using the default Ed25519 algorithm if P256 is not strictly required
Patch Information
The vulnerability has been patched in Nebula version 1.10.3. The fix introduces CalculateAlternateFingerprint() which computes both the high-S and low-S signature forms, checking the blocklist against both fingerprints. Additionally, new certificate signature generation is now clamped to low-S form for consistency. For detailed patch information, see the GitHub Security Advisory GHSA-69x3-g4r3-p962.
Workarounds
- Switch to the default Ed25519 certificate algorithm, which is not affected by this vulnerability
- Manually calculate and add both signature form fingerprints to your blocklist for each blocked certificate
- Implement network-level access controls as an additional layer of defense while planning upgrade
# Configuration example
# Upgrade Nebula to patched version
# Using package manager (example for systems with nebula packages)
apt-get update && apt-get install nebula=1.10.3
# Or download directly from GitHub releases
wget https://github.com/slackhq/nebula/releases/download/v1.10.3/nebula-linux-amd64.tar.gz
tar -xzf nebula-linux-amd64.tar.gz
sudo mv nebula /usr/local/bin/nebula
sudo systemctl restart nebula
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

