Featured image of post MITRE Withdraws from CVE Program: Implications and the Transition to an Independent Foundation
General Knowledge

MITRE Withdraws from CVE Program: Implications and the Transition to an Independent Foundation

Kali Linux lost its signing key, halting updates for all users. What happened, how they fixed it, and what it means for open-source security.

Timeline of Events

  • April 18, 2025: Kali developers froze the rolling repository after discovering the signing key was lost. As CSO Online reported, the Kali repo was frozen on April 18 when a new signing key was created. (The freeze meant no new package uploads occurred until the issue was addressed.)
  • April 28, 2025: Offensive Security posted a public advisory titled “A New Kali Linux Archive Signing Key.” The blog warned “apt update is going to fail for pretty much everyone”. It explained that the old key had been lost (not compromised) and a new key (ID ED65462EC8D5E4C5) was rolled out. Users were instructed to manually download the new key (with a wget command) to /usr/share/keyrings/kali-archive-keyring.gpg to restore update capability.
  • April 29, 2025: Media outlets and cybersecurity news sites published summaries. For example, ZeroDaily noted “On April 28, 2025, the Kali Linux team announced that they lost access to their previous repository signing key,” and that “the repository is now signed with the new key, and the freeze has been lifted”. BleepingComputer and other outlets echoed the key details and fix instructions.
  • Late April 2025: Updated installation images were released. Kali published “refreshed installation media labeled 2025.1c” (identical to the prior release except for the new keyring) and weekly builds from ISO 2025-W17 onward with the new key included. These images allow users to reinstall a system that already has the correct signing key, avoiding manual intervention.
  • May 2025: The repository was “unfrozen” and package updates resumed with the new key. By early May, Kali’s archive was being signed with the new key (as announced). Users who installed the new key or new images could update normally.

Impact on Users

The immediate effect was that all existing Kali installations lost the ability to verify and install updates from the official repo. Attempts to run sudo apt update began to fail with errors like:

Err:1 https://http.kali.org/kali kali-rolling InRelease Sub-process /usr/bin/sqv returned an error code (1), error message: Missing key 827C8569F2518CC677FECA1AED65462EC8D5E4C5, which is needed to verify signature.

This error occurs because the old repository key (ID 827C8569F2518CC677FECA1AED65462EC8D5E4C5) was no longer used to sign package indexes, and without the new key in their keyring, systems could not validate updates. As ZeroDaily summarized, “All Kali Linux users must update the archive signing key immediately. Failure to act will result in broken updates and potential security risks.”. In practical terms, affected users could not install any new packages or security patches until they updated the key. This left systems stuck on older, potentially vulnerable software. Security researchers warned that unattended, unpatched systems might remain exposed if the key was not updated.

Because the old key was not compromised, no malicious packages were introduced; nevertheless, the inability to update was a significant disruption. Many users saw update failures on the weekend of April 28–29, leading to confusion. Offensive Security noted that, since the repo had been frozen before the announcement, “nobody was impacted yet” at the time of freezing. However, once the freeze ended, “in the coming days, nearly every Kali system will fail to update” unless the user took action. In short, this key loss effectively halted security maintenance for the distro until resolved, posing a moderate risk of unpatched vulnerabilities.

Offensive Security’s Mitigation Efforts

Offensive Security acted quickly to mitigate the outage. The key steps they took included:

  • New key generation and distribution: As soon as the old key was found lost, Kali’s team created a replacement signing key. The new key (fingerprint ED65462EC8D5E4C5) was signed by Kali developers and uploaded to Ubuntu’s OpenPGP keyserver network so others could verify it.

  • Freezing the archive: The repository was temporarily frozen (no package updates) beginning April 18 to prevent a split in signing. This meant new package uploads were paused until the new key was ready.

  • Updated package keyring: Offensive Security updated the kali-archive-keyring package. They published the new key in the official archive keyring (via https://archive.kali.org/archive-keyring.gpg), which contains both the old and new key for compatibility. Users were told to manually fetch this file:

    sudo wget https://archive.kali.org/archive-keyring.gpg \
     -O /usr/share/keyrings/kali-archive-keyring.gpg

    (Or use curl). After installing the new keyring, apt update would again succeed.

  • Verification guidance: The team advised verifying the downloaded keyring’s checksum (e.g. via sha1sum) to ensure authenticity. The published SHA1 was 603374c107a90a69d983dbcb4d31e0d6eedfc325.

  • Updated installation media: Kali released new ISOs (2025.1c) and live images that already include the new key. Offensive Security noted these are identical to prior releases except for the updated keyring. Using the new images avoids the manual step altogether. They also rebuilt specialized releases (NetHunter, VMs, Docker, WSL, etc.) with the new key embedded.

  • Preserving trust: Since the old key was lost but not compromised, the developers kept it in the keyring for historical verification and did not issue a revocation certificate for it. They made clear that if the key had been compromised, they would have revoked it. In this case, removing it wasn’t necessary.

These measures resolved the problem. By early May 2025, the Kali archive was signing packages with the new key and users who followed the instructions could update normally. The smoothness of the fix depended on users installing the new key: those who hadn’t done so remained unable to update.

Official Communications from Offensive Security

In their official blog and announcements, Kali’s developers took full responsibility. The Kali team wrote, “This is not only you, this is for everyone, and this is entirely our fault. We lost access to the signing key of the repository, so we had to create a new one.” They explained that the archive had been frozen since April 18 (no updates since then) to avoid impacting users, and that they would “unfreeze the repository this week, and [it’s] now signed with the new key.” The announcement also included a one-line fix:

sudo wget https://archive.kali.org/archive-keyring.gpg \
     -O /usr/share/keyrings/kali-archive-keyring.gpg

which users should run to install the new key.

OffSec emphasized that the old key had not been compromised. As the company noted, if the key had been stolen, they would have removed it and issued a revocation notice. In this case, they left the old key in place “so there is no breakage with packages signed with it”.

They also publicized the updated ISOs: “Just head to Get Kali and grab the latest images. You will notice that the version in the filenames is 2025.1c. These are the exact same images as [the April 2025 release], only the difference being the new keyring.” In short, the official messaging was transparent and straightforward: they acknowledged fault, provided a fix, and assured users that the situation had been contained.

User and Community Reactions

The incident drew attention on social media and forums, with mixed reactions. Many users were frustrated or amused by the error. On Reddit’s r/sysadmin, one commenter bluntly noted this was simply “because someone at Kali made a boo boo and they had to replace their archive signing key”. Another quipped that running Kali in production should be rare: “Why do you even have Kali systems that you’re trying to update in the first place? Those VMs should be ephemeral.” (A reaction implying Kali is often used temporarily.)

Some community members expressed embarrassment but also relief at Kali’s honesty. One commenter observed, “Embarrassing yes, but I’d 1000% rather use a product where people admit their mistakes rather than hide them.”. Others questioned technical details, asking what “lost access” actually meant (a genuine confusion about how one loses a private key). A few voiced general security concerns: for example, one noted “New keys generally pose a security threat… especially if they’re not signing the new key announcement with the old key they ‘lost.’”.

In general, the community absorbed the news pragmatically. Many quickly shared the one-line fix or updated their systems. Tutorials and FAQs (like this one) proliferated to help less experienced users apply the patch. There was no evidence of panic or malicious exploitation. The consensus was that, although the mistake was unacceptable, the transparent handling and easy fix meant the fallout was limited.

Broader Security Implications

This incident highlights important lessons for open-source projects and secure software distribution:

  • Trust in the supply chain: A signing key is a root-of-trust for an entire package repository. Losing it interrupts updates entirely. Had it been compromised by an attacker, the consequences could have been severe (malicious packages signed as official). The fact that Kali’s team preserved the keyring and expedited a new key rollout prevented such a scenario, but it underscores how critical key custody is for supply-chain security.
  • Human error is a risk: As cybersecurity experts note, such “blips” happen when keys or licenses are treated as “single-person” responsibilities. Kali’s incident repeated a similar mistake from 2018 (when their GPG key expired). Robert Beggs of DigitalDefence observed that losing keys is “very uncommon” and typically reflects a lack of central management for these assets. Open-source projects often lack formal governance structures, but this event shows they must adopt disciplined processes for key management akin to any enterprise.
  • Incident response and communication: Kali’s rapid disclosure and clear instructions were widely praised. The transparent tone (“entirely our fault… sorry for the inconvenience”) and readily available fix helped contain the issue. Insecure or vague handling could have eroded user trust. The incident reinforces that open communication and step-by-step guidance are vital when cryptographic trust is broken, even accidentally.
  • Operational continuity: Security keys and certificates should be treated as organizational assets. The advice given to CISOs applies here: “Stop thinking about this as a single person responsibility… Make sure there’s continuity of [object] management”. In practice, this means backups, shared access, and automated reminders for key expirations or key-rotation schedules.
  • Broader supply-chain risk: The Kali case received attention partly because Kali is a widely used security toolkit. It shows that if even security-focused projects slip up, the general open-source ecosystem could be vulnerable. Other distributions and package maintainers can learn from this: a broken key or expired certificate anywhere could similarly disrupt many users.

Recommendations for Maintainers

To prevent similar key-management failures, open-source projects should adopt rigorous practices:

  • Use subkeys and keep primaries offline: Follow PGP best practices: keep your primary signing key securely offline and use separate subkeys for routine signing tasks. This limits exposure of the master key. Ensure secure, encrypted backups of private keys.
  • Hardware security and backup: Store signing keys in tamper-resistant hardware (HSMs or secure USB tokens) where possible. Keep redundant backups (encrypted and split if needed) to prevent “losing” access. Ensure more than one trusted developer has a copy.
  • Centralized tracking and handover: Treat keys like any critical asset. Document who is responsible, and when keys expire or need rotation. Use calendars or key-management systems to alert well before expiration or mandatory rollovers. Plan for key ownership changes so someone else can step in if the primary custodian is unavailable.
  • Automated signing infrastructure: Consider setting up an automated signing server or CI/CD pipeline, so keys are used via a secure service account rather than a developer’s machine. This helps avoid accidental loss and ensures logs of signing activity.
  • Revocation and publication strategy: Always prepare a revocation certificate and consider making it available (e.g. on your website) in case a key is compromised. If a key is changed, publish the new key and its fingerprint via multiple channels (official site, social media, keyservers) so users can independently verify it, as Kali did via the Ubuntu keyserver.
  • Clear, multi-channel communication: In an incident, issue prompt advisories on multiple channels (blog, forums, social media) with concise instructions. Provide both technical details (commands, checksums) and lay explanations to reassure users.
  • Regular audits: Periodically review key management practices. Open a discussion with your user community about transparency (e.g. through a published roadmap or security policy) so that if things go wrong, users trust the process.
  • Avoid hard-coded keys: Do not embed private keys in code repositories or build scripts. (OWASP and others emphasize that keys should be obtained from secure key stores at runtime.)
  • Emphasize update reminders: Finally, encourage users to apply updates regularly. The 2018 Kali incident and this one both relied on users manually installing fixes. A culture of frequent updates reduces the pool of systems stuck on old keys.

By treating signing keys as critical security assets—with backups, oversight, and contingency plans—open-source projects can avoid the disruption seen in Kali Linux’s 2025 incident. The lessons learned here apply across the software supply chain: robust key management and transparent incident response are essential to maintain user trust and security in any project.

Sources :

© 2025 Senthorus Blog