CVE-2026-57062

What it actually does

CVE-2026-57062 is a low-severity cryptographic parsing flaw in GnuPG gpgsm CMS handling through version 2.5.20. When processing CMS data encrypted or authenticated with AES-GCM, gpgsm accepts an aes-ICVlen value of 4 bytes even though the CMS AES-GCM integrity check value length is expected to be 12 bytes. Accepting a shortened authentication tag weakens integrity validation and may allow malformed CMS content to be treated as valid under narrow conditions. The assessed impact is limited to integrity, requires local access and high attack complexity, and does not directly expose confidentiality or availability according to the provided CVSS vector.

Why it matters to the business

Organizations that rely on GnuPG/gpgsm to validate signed or encrypted CMS/S/MIME-style content could make trust decisions on data whose integrity checks are weaker than intended. The practical risk is low because exploitation requires local conditions, high complexity, and there is no known active exploitation or KEV listing; however, systems using gpgsm in automated document, email, package, or workflow validation pipelines should still patch to avoid accepting non-conformant cryptographic messages.

How an attack unfolds

An attacker would need a path to provide CMS-formatted content to a process that invokes gpgsm, such as a local workflow, mail-processing tool, document validation process, or other automation that parses CMS objects. The attacker crafts a CMS AES-GCM structure with an invalidly short aes-ICVlen value of 4 bytes. Vulnerable versions of gpgsm may accept this shortened authentication tag instead of enforcing the expected 12-byte value. If the crafted content passes downstream validation logic, the attacker may be able to influence the integrity of processed content in a limited way. There is no indication from the provided data of public exploit maturity, ransomware use, named threat actor activity, or broad exploitation in the wild.

How to fix it

Upgrade GnuPG to a version newer than 2.5.20 once a vendor-fixed release is available through the operating system, package manager, or upstream distribution channel. Because no exact fixed versions were provided, track the relevant vendor advisory for GnuPG/gpgsm and apply the first release that explicitly corrects CMS AES-GCM aes-ICVlen validation. Where immediate patching is not possible, reduce exposure by limiting which local users and automated workflows can submit CMS content to gpgsm, rejecting CMS AES-GCM objects with unexpected authentication tag lengths before they reach gpgsm, and avoiding trust decisions based solely on vulnerable gpgsm parsing results.

How to confirm the fix worked

Confirm installed GnuPG versions with commands such as `gpgsm --version`, `gpg --version`, or package-manager inventory and verify that gpgsm is not version 2.5.20 or older unless the distribution has backported the fix. Review vendor package changelogs for an explicit CMS AES-GCM or aes-ICVlen validation fix. If feasible, test with a benign CMS AES-GCM sample containing aes-ICVlen set to 4 bytes and confirm the patched parser rejects it. Inventory automated mail, document, signing, encryption, and validation pipelines to determine where gpgsm is invoked and confirm those systems are updated or otherwise protected.

Typical attack path

1. Identify a local or workflow-accessible process that uses vulnerable GnuPG gpgsm CMS parsing through version 2.5.20.
2. Craft CMS content using AES-GCM with aes-ICVlen set to 4 bytes instead of the expected 12 bytes.
3. Deliver the crafted CMS object to the vulnerable parser through a file, message, automation job, or local processing path.
4. Rely on vulnerable gpgsm behavior to accept the non-conformant AES-GCM integrity check length.
5. Attempt to cause downstream systems or users to trust or process content whose cryptographic integrity assurance is weaker than expected.

How to detect it

There are no widely established exploitation indicators for this issue and the provided intelligence shows no known exploit maturity, KEV listing, ransomware use, or named threat actor activity. To investigate possible prior exploitation, review systems that process CMS or S/MIME content with gpgsm. Useful log sources include mail gateway logs, document-processing workflow logs, application logs that invoke gpgsm, shell history, EDR process telemetry, file access logs, and package/runtime inventories. Look for gpgsm processing of untrusted CMS inputs, repeated parsing failures followed by successful processing, unusual locally created CMS files, or command lines invoking gpgsm against attacker-controlled file paths. For deeper forensics, preserve suspicious CMS artifacts and inspect ASN.1/CMS structures for AES-GCM parameters where aes-ICVlen is encoded as 4 bytes rather than the expected 12 bytes.

• gpgsm --decrypt
• gpgsm --verify
• gpgsm --server
• gpgsm --version
• aes-ICVlen
• id-aes128-GCM
• id-aes192-GCM
• id-aes256-GCM
• gpgsm: encrypted data
• gpgsm: decryption failed
• gpgsm: invalid packet
• gpgsm: unsupported algorithm
• gpgsm: problem parsing CMS object

What your security team should do

• Inventory systems and applications that use GnuPG gpgsm for CMS or S/MIME parsing, especially automated validation pipelines.
• Prioritize patching on systems where untrusted users, files, or messages can reach gpgsm-based CMS processing.
• Monitor distribution advisories and upgrade to the first vendor-supported GnuPG release that fixes AES-GCM CMS aes-ICVlen validation beyond version 2.5.20.
• Where patching is delayed, restrict local access to workflows that invoke gpgsm and add pre-validation to reject CMS AES-GCM objects with 4-byte integrity check values.
• Treat this as a low-priority patching item compared with remotely exploitable or actively exploited vulnerabilities, but include it in routine cryptographic tooling updates.
• Review logs and workflow histories for unusual CMS/S/MIME parsing errors, unexpected acceptance of malformed messages, or attacker-supplied CMS content processed by gpgsm.