CVE-2025-67897 Sequoia OpenPGP DoS Fix 2.1.0

Sequoia’s OpenPGP library contains a denial-of-service bug tracked as CVE-2025-67897: the library’s aes_key_unwrap routine panics when it’s fed an abnormally short ciphertext, allowing a remote attacker to crash any application that attempts to decrypt a specially crafted OpenPGP message containing a malformed PKESK or SKESK packet.

Background / Overview​

Sequoia is a modern, Rust-based OpenPGP implementation and library used as a drop-in cryptographic component for applications and distributions across platforms — including Linux and Windows backends — and is intended to provide safe, idiomatic OpenPGP primitives to client software. The project exposes low-level and higher-level APIs and can be compiled with multiple cryptographic backends. The vulnerability, published and assigned CVE-2025-67897, affects Sequoia versions earlier than 2.1.0. The root cause is a length-handling error in the aes_key_unwrap function: when a ciphertext is shorter than expected the function triggers a subtraction underflow and ultimately causes a panic — in debug builds the underflow panics directly, and in release builds the resulting negative value is cast to an unsigned size and used to allocate a vector, producing a huge allocation request that fails and leads to a runtime panic. The project’s commit log summarizing the fix explicitly documents the underflow and the attacker-supplied PKESK/SKESK vector used to trigger it. Several public vulnerability trackers and distribution advisories list the issue, report the assigned CVSS score and the recommended remediation (update to Sequoia 2.1.0 or later), and enumerate packaged instances where the vulnerable crate may ship in distributions. These include the National Vulnerability Database (NVD), Debian’s security tracker, Ubuntu’s CVE pages, and the RustSec / GitHub advisory records.

---

What exactly is broken: aes_key_unwrap, PKESK and SKESK​

AES key unwrap in OpenPGP​

OpenPGP messages commonly wrap a session key (the symmetric key used for message payload encryption) inside one or more Encrypted Session Key (ESK) packets. There are two common ESK flavors:

• PKESK (Public-Key Encrypted Session Key Packet) — a session key encrypted to a recipient’s public key.
• SKESK (Symmetric-Key Encrypted Session Key Packet) — a session key encrypted using a passphrase.

These packet types are defined by the OpenPGP specification (RFC 4880 / updated in more recent work) and precede the encrypted data packet containing the message ciphertext. A recipient first extracts and unwraps the session key material from the appropriate ESK packet and then uses that session key to decrypt the message body.

The software error​

The vulnerable code path is the AES key unwrap routine that processes wrapped AES key blobs extracted from PKESK or SKESK packets. If the wrapped key blob is shorter than the minimum expected size, the function performed arithmetic that allowed a signed subtraction to underflow. The underflowed negative value was then used (after an implicit conversion) as a usize argument to allocate a buffer. On most platforms this produced a request for an astronomically large allocation that the allocator refused, inducing a panic and terminating the application. In debug builds the subtraction underflow was caught directly and panicked earlier in the control path. The commit that fixed this behavior explicitly describes both the underflow and its practical consequences.

---

Scope, severity and exploitability​

• Affected versions: Sequoia before 2.1.0 — upgrade to 2.1.0 or later to receive the fix. Distribution trackers list the fixed package versions; for example, Debian marks rust-sequoia-openpgp as fixed in the 2.1.0 package snapshot and Ubuntu lists the issue with a Medium priority.
• CVE and scoring: MITRE / NVD entries publish the vulnerability and list a CVSS v3.1 vector of AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:N/A:H (base score 5.3 — Medium), reflecting a remotely-triggerable availability impact that requires user interaction and non-trivial crafting.
• Impact: Denial of Service (crash) only — the vulnerability does not directly leak private material or alter cryptographic integrity. The core impact is the ability of a remote actor to make a recipient application crash while parsing/decrypting a maliciously-formed message. Public advisories categorize this as an availability issue (DoS) and associate the weakness with CWE-195 (Signed to Unsigned Conversion Error).
• Exploitability: while the attack is remote, it requires an attacker to deliver an OpenPGP encrypted message containing a specially malformed PKESK or SKESK packet and depends on the target application automatically attempting to decrypt or otherwise processing the packet (this constitutes the user interaction requirement in the CVSS vector). Several vulnerability scanners and vulnerability feeds note no public proof-of-concept exploit is available at the time of publication, and many distributions are treating this as a medium-severity DoS that should be mitigated by upgrading. Administrators should assume an exploit is plausible and act accordingly.

---

Real-world scenarios and risk profile​

Likely attack vectors​

• E-mail clients and automated mail processors that auto-decrypt incoming OpenPGP-encrypted messages. If an attacker sends a crafted encrypted message to a victim whose mail reader uses Sequoia for decryption, the moment the client attempts to unwrap the session key the panic can crash the process. This could be weaponized to produce selective denial-of-service against specific users or services.
• Servers or microservices that accept encrypted data over network APIs and use Sequoia to decrypt inbound payloads (for example, encrypted backups, secure message queues, or automated ingestion tasks). A single crafted payload could crash a service process and interrupt availability.
• Any application embedding Sequoia via language bindings (C/Python) or FFI: panics that unwind through an FFI boundary can be problematic and sometimes lead to process termination depending on configuration.

Practical difficulty and prerequisites​

• The attack requires constructing an otherwise valid OpenPGP message where the ESK packet’s wrapped-key field is deliberately truncated or manipulated in a way that still allows the message parser to reach the vulnerable code path. Achieving that requires care and non-trivial knowledge of OpenPGP packet formatting and the encryption wrapper used by the target. That contributes to the Attack Complexity: High rating in CVSS.
• The attack also typically depends on the recipient application attempting to decrypt the payload (manual or automatic). Many users manually reject suspicious encrypted blobs; however, many automated services and some clients will process incoming encrypted messages without additional prompting. The user interaction qualifier in the CVSS vector captures that operational requirement.

Windows impact​

Sequoia is cross-platform and supports Windows via several backends (e.g., Windows CNG or other crypto backends), and it exposes resilient APIs for application developers. Therefore, Windows applications that bundle Sequoia (either directly as a Rust dependency or indirectly via FFI or bindings) may be affected. Distributions and package managers on Windows are less likely to ship Sequoia by default than Linux, but desktop/mail clients built with Sequoia or services using it on Windows are potentially impacted and should be reviewed.

---

The fix and timeline​

The Sequoia project fixed the root cause with a targeted change to the OpenPGP implementation — the specific commit resolves the subtraction underflow and ensures safer handling of too-short ciphertexts. The commit message documents the behavior (debug underflow vs release allocator failure), the attacker vector (crafted PKESK/SKESK), and credits the reporter. Upgrading to the patched release (2.1.0 or later) is the definitive fix provided by the project. Distribution trackers and security advisories (Debian, Ubuntu, NVD, RustSec, GitHub Advisory database) subsequently enumerated the CVE and recommended upgrades; Debian and some distributions already show the package fixed in their unstable/testing branches and mark older packaged versions as vulnerable. System administrators should check their distribution’s rust-sequoia-openpgp package version and apply vendor fixes where available.

---

Recommended mitigations — immediate and medium-term​

The practical guidance for sysadmins, developers, and product owners follows two tracks: immediate mitigation and durable hardening.

Immediate actions (apply now)​

• Upgrade Sequoia: Deploy the vendor-supplied patch by updating to Sequoia 2.1.0 or later wherever Sequoia is used directly. If your distribution provides a patched package (for example Debian unstable/sid has rust-sequoia-openpgp at 2.1.0-1), install that package.
• Update dependent applications: If you consume third-party software that bundles Sequoia (mail clients, services, libraries), update those applications when a vendor patch is released. Where a patch is not yet available, consider applying distribution-level mitigations (e.g., temporary filters or process isolation).
• Isolate decryption processing: Run decryption in a separate process or container that can be restarted without affecting the core service. If the decryption process crashes, the supervisor can restart it and avoid taking down the main service.
• Monitoring and scanning: Use vulnerability scanners to detect the presence of the vulnerable Sequoia crate in your environment. Scan mail servers and services for packages that embed Sequoia and prioritize them for patching. Several scanners and vendor advisories already include checks for CVE-2025-67897.

Application-level mitigations and hardening​

• Validate packet lengths early: Implement strict validation of packet lengths before attempting to unwrap keys. Defensive checks that ensure minimum viable ciphertext sizes are a proven pattern for preventing length-related underflows.
• Don’t auto-decrypt untrusted streams: If feasible, require explicit user action (or an administrative policy) before decrypting messages from new or untrusted senders.
• Catch and contain panics where appropriate: In Rust applications, consider using std::panic::catch_unwind around untrusted parsing/decryption code to prevent a panic from unwinding out of the decryption thread and taking the whole process down. Note: catch_unwind only catches unwinding panics and will not catch panics in binaries compiled with panic = "abort". Use this option with an understanding of the runtime configuration.
• Process isolation and least privilege: Run decryption with the least privileges necessary; drop network and file privileges and execute within a sandbox where possible. Use supervisor processes that can restart crashed workers.
• Fuzzing and input-hardening: Expand fuzzing coverage for ESK parsing and key unwrap codepaths. The Sequoia project already emphasizes tests and memory-safety, but structured fuzz targets around ESK/PKESK/SKESK semantics can head off future regressions.

---

Developer guidance: long-term fixes and lessons learned​

This vulnerability is a textbook example of how integer arithmetic and signed/unsigned conversions in the presence of input length assumptions can cascade into runtime failures, even in a memory-safe language like Rust. Rust’s strong safety guarantees prevent classic memory corruption in many cases, but panics — especially those caused by integer underflow or by unvalidated length arithmetic — remain possible.
Key developer takeaways:

• Always validate externally-sourced lengths before performing arithmetic that drives allocations or slice/index operations.
• Prefer explicit error returns over unchecked arithmetic when parsing untrusted binary formats; use Result-based APIs to propagate parse failures rather than allowing a panic to occur.
• Apply defensive conversions: avoid implicit signed-to-unsigned casts where a negative sentinel value could be misinterpreted as a giant positive usize.
• Test both debug and release builds: behavior in debug and release builds can diverge — for example, debug builds trap underflows while release builds may proceed with wrapping arithmetic and different allocator behavior. Unit tests and fuzz tests should run in both build modes.
• Consider runtime options: document how the application is compiled (panic=unwind vs abort) and whether catch_unwind is used. Relying solely on catch_unwind is insufficient; combine it with other defenses like process isolation. Rust documentation warns that catch_unwind will not catch abort-style panics.

---

What administrators should audit right now​

• Inventory: identify all applications and packages that link to or embed sequoia-openpgp. Include Rust crates, language bindings, C/Python FFI layers, and packaged binaries (system packages and third-party vendors). Use your OS package manager and dependency scanners to discover vulnerable versions.
• Patch status: confirm whether vendor-provided packages have been updated to Sequoia 2.1.0. If the package is not yet updated in your distribution’s stable channel, follow the vendor advisory, apply upstream patches, or compile a patched version and deploy it in a controlled manner.
• Exposure: prioritize services that automatically decrypt inbound messages and mail readers that auto-process encrypted mail as high-risk. Where possible, temporarily disable auto-decrypt features on high-exposure gateways until patched.
• Logging: enable or increase monitoring and logging for abnormal crashes in decryption processes. Sudden increases in crashes after receiving encrypted messages should be treated as high-priority incidents.

---

Caveats and unverifiable claims​

• There are no confirmed reports of in-the-wild exploitation or publicly available proof-of-concept exploit code for CVE-2025-67897 at the time this article is published; vulnerability feeds and Nessus plugins indicate no known exploit but consider the lack of PoC as provisional. Administrators should operate under the assumption that exploitation is feasible given the public technical details and apply the recommended updates.
• Exact downstream impact depends on how Sequoia is used by each application. End-user exposure varies: many desktop users are safe if their mail client doesn’t auto-decrypt from untrusted sources, while heavily automated server environments and mail-processing pipelines face greater risk.

---

Quick checklist: patch, isolate, monitor​

• Patch Sequoia to 2.1.0 (or later) everywhere the crate is used.
• If patching is delayed: isolate decryption, run decryption in supervised sandboxed processes, and disable automatic decryption of untrusted messages.
• Add parse-length validation for PKESK/SKESK and other ESK entries in your own code.
• Monitor crash logs for unexpected panics in components that perform OpenPGP decryption.
• Run dependency scans periodically and subscribe to vendor advisories for downstream software that bundles Sequoia.

---

Conclusion​

CVE-2025-67897 is a practical reminder that even memory-safe ecosystems can furnish unexpected denial-of-service vectors when format parsing and arithmetic combine with untrusted input. The Sequoia team issued a targeted fix in the openpgp component to prevent a subtraction underflow in aes_key_unwrap, and distributors and advisory databases have cataloged the issue and recommended an update to Sequoia 2.1.0. Operators and developers should prioritize updates, apply defensive parsing and process isolation, and treat untrusted encrypted content with caution until all affected deployments are patched.

---

---

Source: MSRC Security Update Guide - Microsoft Security Response Center