The Sequoia PGP team has rolled out version 2.1.0 of its OpenPGP library to fix a denial-of-service flaw that lets attackers crash email clients, servers, and any decryption-dependent application with one booby-trapped message. The vulnerability, tracked as CVE-2025-67897, centers on a subtraction underflow in the library’s AES key unwrap routine when it encounters an abnormally short ciphertext. If a target application attempts to decrypt an OpenPGP message containing a deliberately malformed PKESK or SKESK packet, the process panics and terminates immediately.

Microsoft’s Security Response Center published the advisory, and downstream projects including Debian and Ubuntu are already distributing the patched version. While there are no confirmed exploits in the wild, the public technical detail makes it a race to patch before attackers weaponize the flaw.

What Actually Got Fixed

The bug lives deep inside the OpenPGP decryption pipeline. When an encrypted message arrives, the recipient must first unwrap the session key—the symmetric key that encrypts the actual message payload. That session key travels inside an Encrypted Session Key (ESK) packet. Two flavors are common: PKESK (encrypted to a public key) and SKESK (encrypted with a passphrase).

Sequoia’s aes_key_unwrap function processes the wrapped AES key blob extracted from those packets. If that blob is shorter than the minimum expected size, the arithmetic that calculates a buffer length goes wrong. A signed subtraction underflows, yielding a negative value. In debug builds, Rust captures the underflow and panics immediately. In release builds, the negative value is cast to an unsigned usize, producing an astronomically large allocation request. The allocator refuses, and the program halts with a panic.

The fix—a targeted commit to the Sequoia OpenPGP crate—validates the input length before any arithmetic, sidesteps the underflow, and returns a proper error instead of crashing. Developers who inspect the commit log will see the explicit documentation of the underflow and the attacker-controlled PKESK/SKESK vector that triggers it. The patched release, Sequoia 2.1.0, is the definitive remediation. All earlier versions are vulnerable.

What It Means for You

The real-world impact splits sharply depending on how your organization uses OpenPGP encryption.

Home Users and Everyday Windows Users

If you use an email client that automatically decrypts incoming PGP messages—Thunderbird with Enigmail, Outlook with a third-party plugin, or any mail app that embeds Sequoia—you’re potentially at risk. A single email from a stranger containing a crafted encrypted payload could crash the client. Repeated crashes could make the application unusable until you remove or quarantine the message.

But there are important caveats: the attack requires the malicious message to reach your inbox and for the client to attempt decryption. Many users manually prompt decryption or have filters that quarantine unverified senders. The CVSS vector lists Attack Complexity as High and requires User Interaction, which means auto-decrypting gateways and services face a bigger threat than a cautious individual who doesn’t click “decrypt” on every suspicious email. Still, the fix is straightforward—update any software that bundles Sequoia.

System Administrators and IT Pros

Servers that auto-process encrypted data are the top concern. Think mail gateways that decrypt inbound PGP email for spam scanning, backup systems that receive encrypted backups, microservices that unwrap PGP payloads from APIs, or any automated ingestion pipeline. One corrupted message can crash the worker process. If that worker isn’t supervised or the crash cascades, you’re looking at service outages.

On Windows, the threat is real albeit less widespread than on Linux. Sequoia supports Windows CNG and other backends, so desktop applications and in-house services built with the library can also crash. Windows software tends not to ship Sequoia by default, but modern cross-platform mail apps, secure messaging tools, or custom enterprise clients may link it. Your inventory should include all applications that process PGP messages, regardless of OS.

Developers

If your Rust project depends on the sequoia-openpgp crate, bump the version to ≥2.1.0 immediately. If you’re consuming Sequoia through a language binding (C, Python, etc.), verify that the binding is rebuilt against the fixed library. The bug is a textbook integer underflow: an unchecked length leads to a panic even in a memory-safe language. Use this incident as a reminder to validate all externally sourced lengths before arithmetic, prefer Result over panic for parsing failures, and test both debug and release builds—behavior differs in critical ways.

How We Got Here

Sequoia is a modern, Rust-based OpenPGP implementation that many communities have adopted as a safer alternative to GPG’s aging C codebase. It provides low-level and high-level APIs, can compile with multiple crypto backends, and runs on Linux, Windows, and macOS. The project’s freshness and memory-safety promise made it attractive—but the complexity of the OpenPGP standard (RFC 4880 and successors) means parsing untrusted binary formats is always a minefield.

The vulnerability crept into the AES key unwrap path, a routine that has to handle wrapped key material from two different packet types (PKESK and SKESK) with varying lengths. No public timeline suggests how long the bug existed before discovery. The researcher who found it reported the issue privately, and the Sequoia team issued a patch before public disclosure. That responsible disclosure process kept things quiet until the advisory hit.

Now, multiple CVE databases and distribution trackers list the flaw. NVD gives it a CVSS v3.1 base score of 5.3 (Medium): network-accessible, high attack complexity, no privileges required, user interaction required, no confidentiality or integrity impact, but availability impact is high. Debian’s security tracker lists rust-sequoia-openpgp as fixed in version 2.1.0-1 in unstable/sid, and Ubuntu’s CVE page shows a medium priority.

What to Do Now

Patch Immediately

  • Direct Sequoia users: Update to Sequoia 2.1.0 or later. If you’re on a Linux distribution, pull the patched package from your vendor (e.g., Debian’s rust-sequoia-openpgp 2.1.0-1). For Windows, if you built the library from source, recompile against the fixed version; if you consume it via a third-party application, wait for the application vendor to release a hotfix.
  • Third-party applications: Check the change logs of your email client, backup tool, or any service that performs PGP decryption. Install updates as soon as they ship.
  • Dependency scanning: Run cargo audit or your organization’s vulnerability scanner to detect vulnerable sequoia-openpgp crates in your supply chain. Many scanners already include checks for CVE-2025-67897.

Short-Term Mitigations if You Can’t Patch Yet

  • Disable auto-decryption: Configure email gateways and message processors to require explicit manual decryption for all PGP messages, at least until patching completes.
  • Isolate decryption processes: Run decryption in a separate sandboxed process or container. If it crashes, a supervisor restarts it, and the main service keeps running. On Windows, you can use Job Objects or Windows Containers to contain the crash.
  • Catch panics (with caution): In your own Rust code, wrap untrusted decryption in std::panic::catch_unwind to prevent the panic from taking down the whole process. This works only if the binary is compiled with panic = 'unwind' (the default) and doesn’t guarantee recovery in all cases, but it’s a useful defense-in-depth measure.
  • Validate packet lengths early: Insert a check before calling the AES unwrap function: ensure the wrapped key blob meets the minimum size expected by the algorithm. This stops short ciphertexts from reaching the vulnerable routine even if the library isn’t yet updated.

Monitor and Audit

  • Monitor crash logs: Sudden spikes in decryption-service crashes after receiving encrypted messages should trigger an immediate investigation.
  • Inventory exposure: Identify every system that ingests PGP-encrypted data. Don’t forget internal tools, test environments, and legacy services that might use older Sequoia versions.

Outlook

Sequoia’s rapid patch cycle and transparent disclosure are commendable, but the vulnerability underscores a persistent challenge: even memory-safe languages can’t prevent logic bugs when parsing attacker-controlled binary formats. The OpenPGP ecosystem—with its many packet types, historical cruft, and complex key wrapping—remains a target-rich environment. Expect more fuzzing efforts and formal verification around these parsers in the coming months.

For now, apply the update, harden your decryption pipelines, and treat every encrypted message as potentially hostile until proven otherwise. This is one of those bugs where the fix is trivial, but the damage from a well-timed crash can be severe.