A 2008 Debian Bug Still Signs Corporate Email

In August 2026, a badkeys scan of nearly 10 million DKIM keys revealed 1,302 generated by a broken OpenSSL package in Debian (CVE-2008-0166). To DNS, these look like ordinary keys. However, their private counterparts are completely public. In 2024, a security researcher used one such compromised key to sign emails as a legitimate certificate company. Here is why anyone can look up these private keys, how they survived 18 years, and how to test your own domain.

Predictable Keys

Starting in 2006 (Debian package version 0.9.8c-1), a patch in Debian and Ubuntu broke OpenSSL's random number generator, an issue formally disclosed in Debian Advisory DSA-1571.

badkeys: "Effectively, this meant that the process id (PID) was the only source of randomness."

Because process IDs on those systems only ranged from 0 to 32,767, the total number of key variations, even factoring in OpenSSL versions, architecture, and seed files, remained tiny. Pre-computing every possible key was trivial.

The badkeys project hosts these vulnerable private keys in a public repository for standard sizes (1024 to 4096 bits). If a DKIM public key matches a known vulnerable fingerprint, its private key is a simple lookup away.

Nothing Enforces DKIM Key Rotation

A DKIM key exists as a standard DNS TXT record without a built-in expiration date.

While RFC 6376 (§3.3.3) notes that keys "can be replaced on a regular basis," and M3AAWG best practices recommend rotating them at least every six months, no technical mechanism enforces these guidelines.

The initial DKIM standard was finalized in 2007 while Debian was still distributing the broken package.

Hanno Böck, lead researcher: "DKIM has no requirement to rotate keys. It appears that a sizeable number of companies configured DKIM TXT records in 2007 and never changed them."

Shared Infrastructure Amplifies the Risk

During Böck's 2024 audit, 777 DKIM records relied on the exact same weak key, and most of them were CNAMEs pointing to a single email provider.

By using a CNAME, each customer delegated key generation to the provider and inherited the provider's vulnerable key.

When Böck attempted to report the flaw to the contact listed in the provider's security.txt file, the notification bounced:

The bounce message: "the group you tried to contact (security) may not exist, or you may not have permission to post messages to the group."

The key was eventually replaced, but only after a significant delay.

Spoofed Mail Can Inherit Brand Logos

BIMI displays brand logos next to verified inbox messages, a standard supported by Gmail. Gmail requires a Verified or Common Mark Certificate alongside a DMARC policy of quarantine or reject at pct=100.

Under current BIMI specifications, inbox providers evaluate BIMI only after a message passes DMARC. Because a valid DKIM signature satisfies DMARC requirements, a stolen DKIM key is all an attacker needs.

Hanno Böck: "The BIMI spec is written in a way that there is no cryptographic connection between the certificate and the DKIM key. As soon as one is able to sign a mail with DKIM, it passes BIMI."

To prove the flaw, Böck successfully signed a test email using a compromised key from a real certificate authority. Supporting inboxes displayed the authority's official logo alongside his forged message.

This specific exploit targets domains configured for BIMI. However, forged emails to standard domains will still pass DKIM validation silently.

In a September 2026 survey of 206,348 active Korean domains, only 4,245 (2.1%) published the strict DMARC policies necessary for Gmail BIMI support.

Audit Your DKIM Keys

1. Locate your key selector. Check your sent email headers for the s= attribute within the DKIM-Signature header.

2. Install badkeys. Install version 0.0.11 or newer (requires dnspython) and update the blocklist:

   pip3 install badkeys dnspython
   badkeys --update-bl
   

3. Scan your public record. Run the scan with the -a flag. A result containing blocklist/debianssl indicates a vulnerable key.

   badkeys -a --dkim-dns <selector>._domainkey.<yourdomain>
   

4. Remediate matching keys. Generate a new key under a fresh selector. If your record uses a CNAME, contact your mail service provider to issue a replacement.

5. Remove legacy selectors. Audit DNS zones and prune unused selectors. As Böck warned the mailop community: "Attackers do not care if you use that key."

When was your organization's DKIM key last rotated?

References

1. badkeys — DKIM scan 2026-08-11 (scan run 11–19 August 2026)
2. Hanno Böck — 16 years of CVE-2008-0166 - Debian OpenSSL Bug - Breaking DKIM and BIMI in 2024 (first published 12 May 2024, last updated 4 January 2025)
3. Hanno Böck, mailop mailing list — DKIM key security scan results (28 August 2026)
4. Debian — DSA-1571-1 openssl: predictable random number generator (13 May 2008)
5. badkeys — Debian OpenSSL bug (CVE-2008-0166)
6. badkeys — debianopenssl: private keys vulnerable to the Debian OpenSSL bug
7. RFC Editor — RFC 6376: DomainKeys Identified Mail (DKIM) Signatures (September 2011)
8. M3AAWG — DKIM Key Rotation Best Common Practices (revised March 2019)
9. IETF — Brand Indicators for Message Identification (BIMI), draft-brand-indicators-for-message-identification-14 (1 May 2026)
10. Google Workspace Admin Help — Set up BIMI (read 15 September 2026)
11. badkeys — badkeys on GitHub (latest release 0.0.20, 20 August 2026)
12. Panke — Email spoofing: we tested 10,000+ Korean domains (1 September 2026)