An exposed apt signing key and how to improve apt security

A leaked package key exposed a deeper apt problem

Cloudflare recently rotated the GPG signing key for pkg.cloudflareclient.com, its Linux package repository for WARP, after a bug bounty report revealed the private key had been exposed. Linux users who installed WARP from that repository should follow Cloudflare's updated instructions to rotate the trusted public key. The incident doesn't affect other Cloudflare products or WARP on mobile.

The more interesting fallout is what the review uncovered: the standard guidance for adding third-party Debian repositories is insecure, and most repositories on the internet are still repeating it. The conventional approach—download a key and pipe it into apt-key or drop it in /etc/apt/trusted.gpg.d/—makes that key a global trust root for every package source, not just the one you intended.

Why apt trusts what it trusts

Apt maintains a list of package sources and a set of trusted public keys to validate them. Historically, keys lived in a single keyring at /etc/apt/trusted.gpg; later versions also read individual key files from /etc/apt/trusted.gpg.d/.

When you run apt update, apt fetches an InRelease file from each source (or the older Release plus signature pair). This file contains metadata cryptographically binding every package in the repository and is signed by the repository owner's private key. Apt verifies that signature against a trusted root before updating the local package cache. That chain—signed metadata plus package hashes—is what prevents tampered packages from being installed.

The trust model breaks when keys are granted broader authority than they need. A key added via apt-key or trusted.gpg.d/ can validate any repository in the sources list. If that key's private half is compromised, an attacker with a valid signature can feed apt entirely fake repository metadata and packages.

One bad key turns every source into a vector

The attack scenario is straightforward. A stock Debian setup with default sources looks like this:

deb http://deb.debian.org/debian/ bullseye main non-free contrib
deb http://security.debian.org/debian-security bullseye-security main contrib non-free

Suppose you added a third-party key at some point, and that key was later compromised. Even if the associated repository is served over HTTPS, an active network attacker doesn't need to break TLS if any source in the list is reachable over plain HTTP—the default Debian sources still are. At a compromised Wi-Fi hotspot, an attacker intercepting the HTTP connection can masquerade as deb.debian.org, serve a forged InRelease signed with the leaked key, and advertise a malicious update to, say, bash. Apt will happily download and install it as root.

Restricting a key to a single source

The fix isn't complicated. Two steps keep a third-party key from being trusted globally:

1. Move the key out of /etc/apt/trusted.gpg and /etc/apt/trusted.gpg.d/. Placing it in /usr/share/keyrings/ with root-only write permissions prevents apt from using it to validate other repositories.
2. Edit the source file in /etc/apt/sources.list.d/ to reference that key explicitly using the signed-by option:

deb [signed-by=/usr/share/keyrings/cloudflare-client.gpg] https://pkg.cloudflareclient.com/ bullseye main

If the source line already includes architecture restrictions, append the signed-by option as an additional field:

deb [amd64 signed-by=/usr/share/keyrings/cloudflare-client.gpg] https://pkg.cloudflareclient.com/ bullseye main

Combined with HTTPS for repository access, this scoping significantly reduces the blast radius of a key compromise: an attacker who obtains the private key still can't sign metadata for any source that doesn't explicitly trust it.

Cloudflare has already updated its own repository instructions for WARP and its Cloudflare package repo to follow this pattern. Running apt-key list on most machines reveals keys trusted far more broadly than necessary—each one is worth reviewing and restricting. For anyone operating a Debian repository, the takeaway is to audit installation docs: if they tell users to curl a key into apt-key, there's a safer alternative that's just as easy to document.

RPM-based distributions like Fedora, CentOS, and RHEL also use a central trusted key store, but their default HTTPS-only update channels make them less exposed to this particular class of on-path attack.