CVE-2026-41990

What it actually does

Libgcrypt before 1.12.2 contains a memory-corruption flaw in the Dilithium signing implementation. During signing operations, the library writes to a static array without an adequate bounds check. The data being written is not attacker-controlled, which limits exploitability, but the out-of-bounds write can still cause incorrect memory modification, process instability, or integrity impact in software that performs Dilithium signing through the affected library. The vulnerability is local in practical impact and requires a process to invoke the affected signing path.

Why it matters to the business

Organizations using affected versions of GnuPG Libgcrypt may experience reliability issues or limited integrity impact in applications that perform Dilithium cryptographic signing. Because the issue has a low EPSS score, no known public exploit maturity, is not in CISA KEV, and is not associated with ransomware activity, broad active exploitation is unlikely at this time. However, cryptographic libraries are commonly embedded across Linux distributions, package managers, security tooling, and downstream applications, so patching should be prioritized where Dilithium signing is enabled or where Libgcrypt is used in high-assurance signing workflows.

How an attack unfolds

An attacker would need the vulnerable Libgcrypt code to be present and a local or application-level path that causes the process to perform Dilithium signing. The attacker then triggers signing behavior that reaches the flawed static-array write. Because the overwritten data is not attacker-controlled and exploitation requires a specific cryptographic operation, the most realistic outcome is process instability, abnormal signing behavior, or limited corruption affecting integrity or availability rather than reliable arbitrary code execution. There is currently no indication of mature public exploitation, known threat actor use, KEV listing, or ransomware use for this vulnerability.

How to fix it

Upgrade Libgcrypt to version 1.12.2 or later. Where Libgcrypt is supplied by an operating-system distribution, apply the vendor security update rather than manually replacing shared libraries. Restart or redeploy applications that link against Libgcrypt so they load the patched library. If immediate patching is not possible, reduce exposure by disabling or avoiding Dilithium signing workflows in affected applications, restricting access to signing interfaces, and isolating systems that perform cryptographic signing. Because the issue is in a shared cryptographic library, inventory both directly installed packages and statically or privately bundled copies in applications, containers, appliances, and build images.

How to confirm the fix worked

Confirm the installed or bundled Libgcrypt version is 1.12.2 or later using package-manager queries, library version checks, and software bill of materials data. Validate that running processes have been restarted and are mapped to the patched shared library rather than an older deleted-on-disk copy. For containerized workloads, confirm base images and application images have been rebuilt from patched packages. Where feasible, run regression tests for GnuPG or application signing workflows, especially any Dilithium signing paths, to verify normal operation after upgrade. If using vendor backports, validate the vendor advisory states that the CVE is fixed even if the displayed upstream version remains below 1.12.2.

Typical attack path

1. Identify software or services linked against Libgcrypt before version 1.12.2.
2. Determine whether the application exposes or invokes Dilithium signing functionality.
3. Obtain a way to trigger the vulnerable signing operation locally or through an application workflow.
4. Cause the affected signing path to execute and reach the unchecked static-array write.
5. Leverage the resulting memory corruption for process disruption or limited integrity impact, depending on application behavior and runtime protections.

How to detect it

There are no known public exploitation indicators, named threat actor activity, KEV listing, or ransomware association for this vulnerability. Detection should focus on identifying exposure and looking for abnormal behavior in applications that use Libgcrypt for Dilithium signing. Review package inventories, SBOMs, container image manifests, and endpoint software inventories for Libgcrypt versions before 1.12.2. For possible prior exploitation or triggering, examine application logs, system journals, crash dumps, core files, EDR telemetry, and service supervisor logs for crashes or abnormal exits in GnuPG, gpg-agent, or applications linked to Libgcrypt during signing operations. Correlate crashes with requests or jobs that invoke post-quantum or Dilithium signing. Since the write does not use attacker-controlled data, there are no reliable payload strings or network signatures specific to exploitation.

• libgcrypt.so.20
• libgcrypt.so
• gpg-agent
• gpg
• SIGSEGV
• segmentation fault
• core dumped
• Dilithium
• ML-DSA

What your security team should do

• Inventory all systems, containers, appliances, and applications using GnuPG Libgcrypt, including bundled or statically linked copies.
• Prioritize upgrades to Libgcrypt 1.12.2 or vendor-patched builds on systems that perform cryptographic signing or expose signing functionality to users or automation.
• Restart affected services and long-running processes after patching to ensure the fixed library is loaded.
• Temporarily disable or restrict Dilithium signing workflows where patching cannot be completed promptly.
• Monitor vendor advisories for Linux distributions and products that embed Libgcrypt, as fixes may be delivered through backported packages.
• Because exploitation probability is currently low, handle through normal vulnerability-management SLAs unless the library is used in high-value signing infrastructure.