CVE-2026-41989

What it actually does

CVE-2026-41989 is a heap-based buffer overflow in Libgcrypt versions before 1.12.2 when processing crafted ECDH ciphertext through gcry_pk_decrypt. An attacker who can supply malicious ciphertext to software that invokes this decryption path may corrupt heap memory, causing process crashes and denial of service. Depending on allocator behavior, build hardening, and how the calling application handles decrypted data, memory corruption could also affect process integrity, although public exploit maturity is currently reported as none and the CVSS vector indicates local attack conditions with high complexity.

Why it matters to the business

Applications and services that rely on Libgcrypt for ECDH decryption can become unstable or unavailable if they process maliciously crafted ciphertext. This may disrupt encrypted messaging, file encryption/decryption workflows, package or artifact verification pipelines, embedded appliances, or security tools built on GnuPG/Libgcrypt. The current EPSS score is low and stable, the issue is not in CISA KEV, and no ransomware use is reported, so broad exploitation pressure appears limited; however, Libgcrypt is a widely reused cryptographic library, so exposure may exist indirectly through packaged applications and statically linked software.

How an attack unfolds

An attacker first identifies software that uses vulnerable Libgcrypt versions before 1.12.2 and can be made to call gcry_pk_decrypt on attacker-controlled ECDH ciphertext. The attacker then crafts malformed ECDH ciphertext intended to trigger incorrect heap handling inside the decryption routine. The payload is delivered through whatever input path the application accepts, such as a local encrypted file, message, token, IPC input, batch-processing queue, or protocol data handled by a local component. When the vulnerable code processes the ciphertext, heap memory corruption occurs. In the most likely outcome, the application crashes, producing a denial of service. In less common or highly target-specific circumstances, the corrupted memory state could affect application integrity if the attacker can reliably shape heap layout and bypass platform mitigations.

How to fix it

Upgrade Libgcrypt to version 1.12.2 or later, or install the operating-system/vendor security update that backports the fix. Because cryptographic libraries are often bundled or statically linked, also update or rebuild applications that embed Libgcrypt rather than dynamically linking to the system library. Restart affected services and long-running processes after updating so they load the patched library. If immediate patching is not possible, reduce exposure by disabling processing of untrusted ECDH ciphertext where feasible, isolating batch decryption jobs, applying service supervisors with restart limits, enforcing memory-safety hardening such as ASLR and allocator checks, and restricting who can submit encrypted inputs to vulnerable components.

How to confirm the fix worked

Confirm deployed Libgcrypt versions are 1.12.2 or later, or that the installed vendor package includes the relevant backported patch. Validate using package-manager queries such as dpkg -l, rpm -q, apk info, or equivalent vendor tooling; library checks such as pkg-config --modversion libgcrypt; and application inventory for statically bundled copies of libgcrypt.so or libgcrypt.a. After patching, restart dependent services and verify running processes are mapped to the updated library, for example by checking lsof, /proc/<pid>/maps, or platform-specific module inventory. Where safe test cases are available from the vendor or upstream project, run regression tests that exercise ECDH decryption and confirm malformed ciphertext no longer crashes the process.

Typical attack path

1. Identify an application, command-line tool, service, or embedded component that uses Libgcrypt before 1.12.2.
2. Confirm the target processes ECDH ciphertext using Libgcrypt's gcry_pk_decrypt path.
3. Create a malformed ECDH ciphertext object designed to trigger the heap overflow condition.
4. Deliver the crafted ciphertext through an accepted local input path, such as a file, message, job, IPC payload, or local protocol request.
5. Wait for the vulnerable application to decrypt or parse the ciphertext.
6. Cause heap corruption that results in process crash, service interruption, or potential application-state corruption.

How to detect it

To determine whether exploitation may have occurred, review logs and forensic artifacts from applications that use Libgcrypt and process ECDH ciphertext or encrypted inputs. Focus on crashes, core dumps, abnormal exits, watchdog restarts, and allocator-corruption messages after processing untrusted encrypted files, messages, or local protocol data. Useful sources include system journals, syslog, kernel logs, application logs, crash reporters, container runtime logs, endpoint telemetry, and core dump stores. Look for segmentation faults or aborts in processes mapped to libgcrypt, stack traces containing gcry_pk_decrypt, gcry_mpi, or ECDH-related routines, and repeated crashes triggered by similarly timed input submissions. Network indicators are generally not reliable because exploitation depends on the calling application and the ciphertext format; correlate suspicious encrypted-input submissions with process crashes instead. There are no known public exploit signatures, KEV listing, or named threat actors reported for this issue in the supplied data.

• gcry_pk_decrypt
• libgcrypt.so
• libgcrypt.a
• libgcrypt fatal error
• Segmentation fault
• segfault at
• malloc(): corrupted
• malloc(): invalid size
• double free or corruption
• free(): invalid pointer
• heap-buffer-overflow
• AddressSanitizer: heap-buffer-overflow
• core dumped
• Aborted (core dumped)
• ECDH ciphertext
• ecdh

What your security team should do

• Inventory systems, containers, appliances, and application packages that include GnuPG/Libgcrypt, especially those handling encrypted files, messages, or local decryption workflows.
• Prioritize upgrade to Libgcrypt 1.12.2 or vendor-patched packages for internet-adjacent processing pipelines, shared multi-user systems, automated decryption services, and security-sensitive infrastructure.
• Check for statically linked or bundled Libgcrypt copies in third-party products, containers, and internally built software; rebuild or obtain updated releases where necessary.
• Review crash telemetry and system logs for recent unexplained crashes in applications linked against Libgcrypt, particularly around ECDH decryption or encrypted input processing.
• Add monitoring for repeated segmentation faults, allocator corruption messages, or core dumps involving libgcrypt or applications that consume untrusted encrypted data.
• If patching is delayed, restrict untrusted ciphertext submission paths and isolate decryption workloads with least privilege, sandboxing, and resource limits.