CVE-2026-22866
RSA Signature Forgery in ENS RSASHA Algorithms Enables Domain Hijacking
Publication date: 2026-02-25
Last updated on: 2026-03-13
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| ens.domains | ethereum_name_service | to 1.6.2 (inc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-347 | The product does not verify, or incorrectly verifies, the cryptographic signature for data. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
[{'type': 'paragraph', 'content': 'CVE-2026-22866 is a vulnerability in the Ethereum Name Service (ENS) DNSSEC Oracle contracts, specifically in the RSASHA256Algorithm and RSASHA1Algorithm contracts. These contracts fail to properly validate the PKCS#1 v1.5 padding structure when verifying RSA signatures. Instead of fully validating the padding, they only check if the last 32 (for SHA-256) or 20 (for SHA-1) bytes of the decrypted signature match the expected hash.'}, {'type': 'paragraph', 'content': "This incomplete validation enables Bleichenbacher's 2006 signature forgery attack, which exploits RSA keys with a low public exponent (e=3). Two ENS-supported top-level domains (.cc and .name) use RSA keys with e=3 for their Key Signing Keys (KSKs). Because of this vulnerability, attackers can forge signatures and fraudulently claim any domain under these TLDs on ENS without actual DNS ownership."}, {'type': 'paragraph', 'content': 'The vulnerability arises because the contracts do not check the full PKCS#1 v1.5 padding structure, allowing an attacker to create a forged signature that passes verification. A patch was merged to fix this by implementing full PKCS#1 v1.5 padding validation and updating the contracts accordingly.'}] [3, 1]
How can this vulnerability impact me? :
This vulnerability allows attackers to fraudulently claim ENS domains under the affected top-level domains (.cc and .name) without owning the corresponding DNS records. This means an attacker can impersonate domain owners by forging RSA signatures, potentially redirecting users or services to malicious addresses.
Such unauthorized claims can lead to loss of trust, phishing attacks, or unauthorized control over ENS names, which are used as human-readable identifiers on the Ethereum blockchain.
The exploit is feasible and relatively low cost, requiring approximately 100,000 gas (~$5 USD), making it accessible to attackers.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
I don't know
How can this vulnerability be detected on my network or system? Can you suggest some commands?
Detection of this vulnerability involves verifying whether the ENS DNSSEC Oracle contracts (specifically RSASHA256Algorithm and RSASHA1Algorithm) are vulnerable to RSA signature forgery due to missing PKCS#1 v1.5 padding validation.
A practical approach is to run the provided proof-of-vulnerability test scripts (PoV.sh and PoVNew.sh) from the ENS contracts repository. These scripts demonstrate the full attack chain exploiting the vulnerability and can confirm if the system is vulnerable by checking if forged signatures are accepted.
Commands to run these tests typically involve executing the shell scripts in an environment configured with the ENS contracts and dependencies. For example:
- Run `./PoV.sh` or `./PoVNew.sh` in the repository environment to test for the vulnerability.
Additionally, after deploying the patched contracts, running these tests again should result in failure, indicating the vulnerability is mitigated.
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation steps include deploying the patched versions of the vulnerable contracts and reconfiguring the ENS DNSSEC implementation to use these updated contracts.
- Deploy updated contracts for RSASHA256Algorithm, RSASHA1Algorithm, and P256SHA256Algorithm that properly validate PKCS#1 v1.5 padding.
- Update the DNSSECImpl contract by calling `setAlgorithm(uint8,address)` to point to the newly deployed, patched algorithm contracts.
- Ensure contract ownership is securely managed, typically transferring ownership to a multisig controlled by the Security Council for deployment and then back to the DAO multisig after verification.
After deployment, run the provided proof-of-vulnerability tests to confirm that the exploit no longer succeeds.
These steps prevent attackers from fraudulently claiming ENS domains under affected TLDs (.cc and .name) by closing the RSA signature forgery attack vector.