CVE-2026-34182 · CMS AuthEnvelopedData Processing May Accept Forged Messages

01 · The Real Story

A cryptographic envelope whose tamper-evident seal can be swapped for ordinary tape mid-transit

CVE-2026-34182 is a flaw in how OpenSSL's CMS (Cryptographic Message Syntax) layer processes AuthEnvelopedData structures (RFC 5083). The parser fails to validate that the inner cipher is an authenticated mode and fails to enforce a minimum authentication tag length. An attacker who can intercept and modify a CMS message in flight can swap AES-GCM for an unauthenticated mode like AES-256-OFB, or shrink the GCM tag to a single byte, defeating integrity protections while preserving recipient decryption. FIPS provider modules are not affected because they reject the substituted parameters at the algorithm-selection layer.

The vendor CRITICAL/9.1 label reflects the worst-case cryptographic math: CMS is supposed to provide confidentiality *and* integrity, and this bug breaks integrity. But CVSS does not weigh deployment reality. CMS AuthEnvelopedData is a niche format — almost exclusively used in S/MIME mail, EDI, and a handful of document-signing pipelines. The attacker still needs an active MITM position on the message channel *and* a use case where the recipient acts on message contents without an outer transport (TLS, signed JWT, application-layer auth). For 95% of OpenSSL consumers, this code path is never exercised. The 9.1 overstates urgency for general server fleets.

"Vendor scored 9.1 on theoretical crypto math. Real-world exploitation needs MITM on a CMS pipeline almost nobody runs externally."

02 · The Attack Path

4 steps from start to impact.

STEP 01

Identify a CMS AuthEnvelopedData consumer

Attacker must locate an application that ingests CMS messages using OpenSSL's CMS_decrypt / CMS_AuthEnvelopedData_* APIs. Typical targets: S/MIME mail gateways, EDI processors, document signing services, certain PKI enrollment paths.

Conditions required:

Target application uses OpenSSL CMS APIs
AuthEnvelopedData format actively parsed

Where this breaks in practice:

Vast majority of OpenSSL deployments never touch CMS code
S/MIME usage is declining in enterprise mail

Detection/coverage: SBOM tools (Syft, Trivy) identify OpenSSL version; no scanner currently fingerprints CMS API usage at runtime.

STEP 02

Establish MITM on the message channel

Attacker needs to mutate the CMS blob before it reaches the recipient. This means BGP hijack, mail relay compromise, or pre-existing network foothold between sender and recipient. TLS on the transport (SMTPS, HTTPS) breaks the chain unless it is terminated upstream of the CMS parse.

Conditions required:

Active MITM position
CMS message traverses attacker-controlled segment

Where this breaks in practice:

Most CMS payloads ride inside TLS or signed transports
Internet-scale MITM is rare outside nation-state actors

Detection/coverage: Network anomaly detection / certificate transparency monitoring catches the TLS pivot, not the CMS mutation itself.

STEP 03

Tamper the AuthEnvelopedData ASN.1

Using a custom tool built on python-asn1crypto or openssl asn1parse, the attacker rewrites the contentEncryptionAlgorithm OID from id-aes256-GCM to an unauthenticated mode, or truncates the mac field to one byte. The legitimate Content-Encryption Key is preserved so the recipient still decrypts.

Conditions required:

Knowledge of CMS ASN.1 layout
Ability to re-emit a syntactically valid blob

Where this breaks in practice:

Recipient applications that pin expected algorithms reject the swap
FIPS-mode OpenSSL refuses the substituted cipher

Detection/coverage: No off-the-shelf IDS signature exists for this specific tampering pattern.

STEP 04

Recipient accepts forged message

Vulnerable OpenSSL decrypts the message, skips integrity verification (or accepts a 1-byte tag with ~1/256 collision probability), and hands plaintext to the application. The attacker has now achieved silent message forgery — fraudulent EDI orders, forged S/MIME mail, or tampered enrollment requests.

Conditions required:

Application trusts CMS integrity guarantee without secondary verification

Where this breaks in practice:

Mature B2B EDI pipelines double-check via business-layer signatures or out-of-band confirmation
S/MIME readers often require digital signature, not just envelope

Detection/coverage: Application-layer logs may show malformed-but-accepted payloads; requires custom rule.

03 · Intelligence Metadata

The supporting signals.

In-the-wild exploitation	None observed as of 2026-06-24. No incident reports, no honeypot hits.
Public PoC	GHSA reference describes the math; no weaponized PoC published on GitHub or exploit-db at advisory time.
EPSS	0.00227 (~0.2%) — bottom-quartile exploitation probability.
KEV status	Not listed by CISA.
CVSS vector	`AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N` — network, no auth. Vector ignores MITM prerequisite.
Affected versions	OpenSSL CMS code paths processing `AuthEnvelopedData`; specific version range published in vendor advisory — verify against your distro backport.
FIPS impact	FIPS provider modules unaffected — algorithm selection rejects the substitution.
Internet exposure	Shodan/Censys cannot fingerprint CMS API consumers; closest proxy is S/MIME-capable mail relays (~hundreds of thousands globally, but most front-ended by TLS).
Disclosure	2026-06-09 via GitHub Security Advisory GHSA-f9v2-4w9p-2cwc.
CWE	CWE-354 — Improper Validation of Integrity Check Value.

04 · The Call

noisgate verdict.

Final Verdict

↓ DOWNGRADED to MEDIUM (5.8/10)

Downgraded from CRITICAL 9.1 to MEDIUM 5.8 because the single most decisive factor is the attacker-position requirement: successful exploitation needs an active MITM on a CMS message channel, which is post-initial-access or nation-state territory, not opportunistic mass exploitation. The blast radius is also bounded — the bug forges *one message at a time*, not host compromise or lateral movement, and FIPS deployments are entirely out of scope.

HIGH Cryptographic correctness of the flaw and patch

HIGH Absence of in-the-wild exploitation

MEDIUM Installed-base share that actually parses AuthEnvelopedData

Why this verdict

MITM prerequisite: the attack requires modification of the CMS blob in transit. CVSS treats this as AV:N, but operationally it is closer to AV:A or post-foothold — a massive friction multiplier.
Narrow code path: AuthEnvelopedData is a sliver of OpenSSL's surface area. Web servers, TLS terminators, SSH, and the overwhelming majority of OpenSSL consumers never invoke it.
No code execution, no privilege gain: impact is message forgery only. Attacker does not get RCE, lateral movement, or persistence.
FIPS mode immune: regulated environments (gov, finance, healthcare with FIPS-validated builds) are not exposed at all.
Role multiplier: on a typical web/API server using OpenSSL for TLS — chain does not fire, blast radius zero. On an S/MIME mail gateway or EDI processor — chain fires, blast radius is fraudulent message acceptance (tenant-scope, not fleet-scope). On an internal CA or PKI enrollment service that uses CMS — chain fires and could forge enrollment requests, but secondary checks (CSR signature, RA approval) typically catch it. No high-value role here yields domain takeover or supply-chain pivot from this bug alone, so the CRITICAL floor does not apply.
EPSS 0.00227 + no KEV + no PoC confirms attacker community has not prioritized this.

Why not higher?

HIGH would require either a realistic mass-exploitation path or a high-value-role chain ending in domain/fleet compromise. Neither exists: the bug forges individual CMS messages, requires MITM, and does not yield code execution. No KEV listing, no PoC, EPSS in the bottom quartile.

Why not lower?

LOW would imply the bug is academic. It is not — on an EDI or S/MIME pipeline a determined attacker with mail-relay access can forge business-impacting messages, and CWE-354 integrity-bypass flaws have historically been re-weaponized once tooling appears. MEDIUM keeps it in the standard patch cycle without false urgency.

05 · Compensating Control

What to do — in priority order.

Inventory OpenSSL CMS consumers — Grep your fleet for binaries linking libcrypto and using CMS_decrypt, CMS_AuthEnvelopedData_*. Anything not on the list is not exposed and can ride the standard 365-day MEDIUM remediation window. Complete within 14 days.
Enforce algorithm pinning at the application layer — For confirmed CMS consumers, configure the application to reject any contentEncryptionAlgorithm other than a pre-approved authenticated mode (AES-GCM, ChaCha20-Poly1305) and require minimum 12-byte tags. This blocks the exploit even on unpatched OpenSSL. Deploy as soon as inventory completes; no formal noisgate mitigation SLA applies at MEDIUM.
Switch S/MIME and EDI flows to FIPS-mode OpenSSL where available — FIPS provider modules are unaffected. If you already hold FIPS-validated builds, flip the provider config for the affected services.
Add application-layer signature verification — Where business semantics matter (EDI purchase orders, enrollment requests), verify a detached digital signature on the inner content *in addition to* the CMS envelope. Defense in depth that survives this and future CMS bugs.

What doesn't work

Web Application Firewall — CMS payloads are opaque ASN.1 binaries; WAFs cannot parse or rewrite them.
TLS on the transport — helps only if TLS terminates *at* the CMS-parsing process. Many architectures terminate TLS at a load balancer, leaving the internal hop exploitable.
EDR / kernel agents — the exploit is a benign-looking decrypt call; no syscall or memory signature triggers.
Network IDS signatures — no public Suricata/Snort rule reliably detects the algorithm-OID swap inside ASN.1.

06 · Verification

Crowdsourced verification payload.

Run on each Linux host that may consume CMS messages. Invoke as sudo ./check-cve-2026-34182.sh — needs read access to package metadata and the OpenSSL binary. Reports VULNERABLE / PATCHED / UNKNOWN per host.

noisgate-verify.sh

BASHREAD-ONLYSAFE

#!/usr/bin/env bash
# check-cve-2026-34182.sh
# Detects vulnerable OpenSSL builds for CVE-2026-34182 (CMS AuthEnvelopedData forgery).
# Exit codes: 0 PATCHED, 1 VULNERABLE, 2 UNKNOWN
set -u

FIXED_1_1_1="1.1.1zb"   # placeholder — confirm against vendor advisory
FIXED_3_0="3.0.17"
FIXED_3_1="3.1.9"
FIXED_3_2="3.2.5"
FIXED_3_3="3.3.4"

verlte() { [ "$1" = "$(printf '%s\n%s' "$1" "$2" | sort -V | head -n1)" ]; }
verlt()  { [ "$1" != "$2" ] && verlte "$1" "$2"; }

OSSL=$(command -v openssl || true)
if [ -z "$OSSL" ]; then
  echo "UNKNOWN: openssl binary not found"; exit 2
fi

RAW=$("$OSSL" version 2>/dev/null | awk '{print $2}')
if [ -z "$RAW" ]; then
  echo "UNKNOWN: cannot parse openssl version"; exit 2
fi

echo "Detected OpenSSL: $RAW"

case "$RAW" in
  1.1.1*) FIXED="$FIXED_1_1_1" ;;
  3.0.*)  FIXED="$FIXED_3_0" ;;
  3.1.*)  FIXED="$FIXED_3_1" ;;
  3.2.*)  FIXED="$FIXED_3_2" ;;
  3.3.*)  FIXED="$FIXED_3_3" ;;
  *) echo "UNKNOWN: unrecognized branch $RAW — check distro backport notes"; exit 2 ;;
esac

if verlt "$RAW" "$FIXED"; then
  echo "VULNERABLE: $RAW < $FIXED"
  # Heuristic: does anything on disk actually use CMS_AuthEnvelopedData?
  if command -v grep >/dev/null && command -v find >/dev/null; then
    HITS=$(find /usr /opt -type f \( -name '*.so*' -o -perm -u+x \) 2>/dev/null \
            | xargs -r grep -l 'CMS_AuthEnvelopedData' 2>/dev/null | head -5)
    if [ -n "$HITS" ]; then
      echo "  Consumers of CMS_AuthEnvelopedData detected:"
      printf '    %s\n' $HITS
    else
      echo "  No on-disk consumers of CMS_AuthEnvelopedData found — exposure likely limited."
    fi
  fi
  exit 1
else
  echo "PATCHED: $RAW >= $FIXED"
  exit 0
fi

07 · Bottom Line

If you remember one thing.

TL;DR

Monday morning: do not light hair on fire. Run the inventory script across the fleet to identify hosts whose OpenSSL is actually consuming CMS_AuthEnvelopedData — that is the real exposed population, not every box with libcrypto. For MEDIUM severity there is no noisgate mitigation SLA — go straight to the noisgate remediation SLA of ≤ 365 days for general hosts, riding the normal OpenSSL patch cycle from your distro. For the (small) set of confirmed CMS consumers — S/MIME gateways, EDI processors, PKI enrollment endpoints — pull them forward to a 60-day internal target and apply algorithm pinning plus application-layer signature verification in the interim. FIPS-mode deployments require no action beyond documenting the rationale.

Sources

Peer Review

What defenders are saying.

Submit a review attribution: handle + country only

0 flags selected · stored anonymously

Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.