CVE-2026-34182, OpenSSL CMS Validation Bypass and Message Integrity Risk

CVE-2026-34182 is an OpenSSL vulnerability in the processing of Cryptographic Message Syntax AuthEnvelopedData. The failure is narrow enough that it should not be described as a universal OpenSSL or TLS compromise, but serious enough that systems accepting untrusted CMS messages need focused remediation.

Two validation failures are involved. First, affected OpenSSL releases can accept a non-authenticated cipher where AuthEnvelopedData requires authenticated encryption. Second, they can accept an authentication tag that has been reduced to a single byte. The first condition can cause CMS_decrypt() to report success without enforcing the integrity guarantee expected from AuthEnvelopedData. The second reduces a message-integrity decision to a value with only 256 possible outcomes.

OpenSSL published CVE-2026-34182 on June 9, 2026 and assigned it Moderate severity. The affected supported branches are OpenSSL 4.0 before 4.0.1, 3.6 before 3.6.3, 3.5 before 3.5.7, 3.4 before 3.4.6, and 3.0 before 3.0.21. OpenSSL 1.1.1 and 1.0.2 are not affected by this specific issue. (openssl-library.org)

The operational question is not simply whether an application contains OpenSSL. It is whether an attacker-controlled or low-trust CMS AuthEnvelopedData object can reach a vulnerable decryption path, and whether the application exposes enough output, timing, status, or business behavior to reveal whether a forged message was accepted.

The vulnerability in one page

Question	Practical answer
What is vulnerable	OpenSSL CMS processing of AuthEnvelopedData
根本原因	Insufficient validation of the selected content cipher and AEAD tag length
First attack path	Substitute a non-AEAD cipher, such as AES-256-OFB, while preserving valid recipient key-wrapping data
Second attack path	Reduce the authentication tag to one byte and repeatedly guess a value that will be accepted
Main security impact	Message-integrity bypass and, under oracle conditions, key-equivalent functionality for a captured content-encryption key
Required reachability	The target must parse and decrypt attacker-influenced CMS AuthEnvelopedData
Additional condition for the first path	The attacker needs a legitimate message addressed to the victim and a distinguishable response or effect
Additional condition for the second path	The attacker generally needs repeated submissions and a way to recognize acceptance
OpenSSL severity	中程度
CVSS displayed by NVD	CISA-ADP CVSS 3.1 score 9.1 Critical
Fixed releases	4.0.1, 3.6.3, 3.5.7, 3.4.6, and 3.0.21
Explicitly unaffected releases	OpenSSL 1.1.1 and 1.0.2
FIPS status	OpenSSL states that its FIPS modules are not affected because the relevant CMS code is outside the module boundary
Primary response	Patch, confirm CMS reachability, enforce AEAD-only algorithms, validate tag lengths, and prevent plaintext use before authentication succeeds

NVD currently shows no NIST-authored CVSS assessment for the record, but it displays a CISA-ADP CVSS 3.1 score of 9.1 with the vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N. That score represents a high-impact abstract scenario. It does not establish that every network service containing an affected OpenSSL library is remotely exploitable. (NVD)

The distinction matters. A public S/MIME gateway that automatically decrypts inbound CMS messages is materially different from a web server that uses the same OpenSSL release only for ordinary TLS handshakes. Both may have the library installed, but only one may expose the vulnerable CMS operation to untrusted input.

Why AuthEnvelopedData exists

Cryptographic Message Syntax is a general container format used to sign, encrypt, authenticate, and package data. It underlies technologies and workflows including S/MIME and several PKI-oriented message formats. CMS is not a single encryption scheme. It is a structured ASN.1 format containing algorithm identifiers, recipient information, encrypted content, optional attributes, and integrity data.

Traditional CMS EnvelopedData provides encrypted content for one or more recipients. A sender generates a content-encryption key, encrypts the content with that key, and then wraps the content-encryption key separately for each recipient. Each recipient uses a private key or another key-management mechanism to recover the content-encryption key.

AuthEnvelopedData adds an essential property: authenticated encryption. The format is intended to provide confidentiality and integrity together. A recipient should learn the plaintext only when the encrypted content and authenticated attributes pass verification.

RFC 5083 defines the structure with fields that include:

AuthEnvelopedData
├── version
├── originatorInfo
├── recipientInfos
├── authEncryptedContentInfo
│   ├── contentType
│   ├── contentEncryptionAlgorithm
│   └── encryptedContent
├── authAttrs
├── mac
└── unauthAttrs

について recipientInfos collection identifies how the content-encryption key, often abbreviated CEK, is made available to authorized recipients. The authEncryptedContentInfo field describes the encrypted content and the algorithm used to protect it. The mac field carries the authentication value produced by the authenticated-encryption operation.

RFC 5083 states that the recipient must verify integrity before releasing information, especially plaintext. If integrity verification fails, the plaintext must be destroyed. This requirement is not optional hardening. It is part of the security definition of the content type. (IETFデータトラッカー)

A correct receiving path therefore looks like this:

Receive CMS object
        ↓
Parse outer ASN.1 structure
        ↓
Select the intended RecipientInfo
        ↓
Recover the content-encryption key
        ↓
Validate the content-encryption algorithm
        ↓
Validate algorithm parameters and tag length
        ↓
Decrypt into protected temporary storage
        ↓
Verify the authentication tag
        ↓
Release or commit plaintext only after success

The order is important. Recovering a CEK proves only that the message contains recipient information that the target can process. It does not prove that the encrypted content is authentic, that the algorithm identifier is acceptable, or that the ciphertext has not been changed.

CVE-2026-34182 breaks the expected boundary between key recovery and authenticated content acceptance. A valid wrapped CEK can be retained while other fields are changed in ways that remove or weaken authentication.

How authenticated encryption should constrain the parser

Authenticated-encryption algorithms combine encryption with an integrity check. AES-GCM and AES-CCM are examples supported for CMS AuthEnvelopedData by RFC 5084. The algorithms produce ciphertext and an authentication tag, also called an integrity check value.

A receiver needs all of the following to be correct:

• The algorithm identifier must designate an authenticated-encryption algorithm.
• The key must be valid for that algorithm.
• The nonce or IV must satisfy the algorithm and protocol requirements.
• The authentication tag must have an allowed length.
• The received tag must match the value computed from the key, ciphertext, and authenticated data.
• No plaintext may be treated as valid before tag verification succeeds.

These are semantic constraints. An ASN.1 object can be syntactically well formed while still violating them. A generic decoder may successfully read an object identifier, an integer, an octet string, and some encrypted bytes. The security layer must then reject combinations that do not make sense for AuthEnvelopedData.

Consider an object that declares itself to be AuthEnvelopedData but selects AES-OFB as its content cipher. The parser may be able to initialize AES-OFB and transform ciphertext into bytes. That does not make the message authenticated. OFB is a stream-like confidentiality mode and does not provide an authentication tag.

Similarly, an AES-GCM object with a one-byte authentication value may be parseable, but the tag is far too short to provide the security required by the CMS profile. RFC 5084 defines AES-GCM ICV lengths of 12, 13, 14, 15, or 16 octets. For AES-CCM, the allowed values are 4, 6, 8, 10, 12, 14, and 16 octets. A one-byte value belongs to neither valid set. (IETFデータトラッカー)

The vulnerable OpenSSL path did not enforce those boundaries strongly enough.

The validation gap inside OpenSSL

OpenSSL’s official description says CMS processing failed to perform sufficient validation on two attacker-influenced fields:

1. The content cipher selected for AuthEnvelopedData.
2. The length of the AEAD authentication tag.

Those are separate validation failures, but both have the same deeper cause: the parser proceeded with a cryptographic operation without first proving that the supplied parameters preserved the security contract of AuthEnvelopedData.

In the non-AEAD case, affected code could accept a cipher that provides encryption without authentication. OpenSSL would attempt to decrypt the content even though the selected mode could not validate the AuthEnvelopedData MAC in the required manner.

In the short-tag case, the selected algorithm remained an AEAD algorithm, but the attacker could lower the authentication strength to one byte. The message still appeared to use authenticated encryption, yet its integrity decision could be guessed with a probability of one in 256 per independent attempt.

The OpenSSL fix describes two corresponding changes:

• Reject non-AEAD ciphers when processing or creating AuthEnvelopedData.
• Reject AEAD tag lengths below four bytes or above sixteen bytes.

The relevant patch condition rejects taglen < 4 そして taglen > 16, and it adds an error path when authenticated CMS content uses a cipher that is not AEAD. (ギットハブ)

A simplified representation of the patched security logic is:

if (content_type_is_auth_enveloped) {
    if (!cipher_is_aead(selected_cipher)) {
        return CMS_ERROR_UNSUPPORTED_CONTENT_ENCRYPTION_ALGORITHM;
    }

    if (tag_length < 4 || tag_length > 16) {
        return CMS_ERROR_INVALID_AEAD_TAG_LENGTH;
    }
}

This pseudocode is not a replacement for the actual OpenSSL patch, but it captures the two validation boundaries.

The generic four-byte minimum deserves careful interpretation. RFC 5084 allows four-byte tags for AES-CCM, while AES-GCM in CMS requires at least twelve bytes. OpenSSL’s fix uses the lower generic limit because the common code is not algorithm-specific and because four bytes is sufficient to block the disclosed one-byte attack.

Applications with control over accepted CMS profiles should enforce the exact set allowed for each algorithm rather than relying only on a generic range:

AES-GCM allowed tag lengths: 12, 13, 14, 15, 16 bytes
AES-CCM allowed tag lengths: 4, 6, 8, 10, 12, 14, 16 bytes

That additional policy is defense in depth. Installing the official OpenSSL update remains the primary remediation.

Attack path one, replacing authenticated encryption with OFB

The first attack scenario in the OpenSSL advisory is more subtle than simply sending malformed ciphertext. It preserves the part of a legitimate message that allows the victim to recover the real content-encryption key.

A normal multi-recipient or single-recipient AuthEnvelopedData object contains a wrapped CEK in recipientInfos. For a certificate-based recipient, that CEK is protected so the intended recipient can recover it with the corresponding private key.

The official scenario begins with an on-path attacker capturing one legitimate AES-GCM AuthEnvelopedData message addressed to the victim. The attacker leaves recipientInfos byte-for-byte unchanged. Therefore, when the manipulated message reaches the victim, the victim’s private key still unwraps the genuine CEK.

The attacker changes the inner content-encryption algorithm identifier to AES-256-OFB and supplies an attacker-selected IV and ciphertext. In an affected OpenSSL release, the decryption path initializes AES-256-OFB under the genuine CEK, does not enforce the AuthEnvelopedData MAC as expected, and can return success from CMS_decrypt(). (seclists.org)

The flow can be represented as follows:

Legitimate sender
    │
    │ AuthEnvelopedData using AES-GCM
    ▼
On-path attacker captures message
    │
    ├── Keeps recipientInfos unchanged
    ├── Replaces AES-GCM OID with AES-256-OFB OID
    ├── Chooses a new IV
    └── Chooses new ciphertext
    ▼
Vulnerable recipient application
    │
    ├── Private key unwraps the genuine CEK
    ├── OpenSSL initializes OFB with that CEK
    ├── No meaningful AEAD tag validation occurs
    └── CMS_decrypt may return success
    ▼
Observable response or downstream behavior

Why does preserving recipientInfos matter? Without a valid wrapped CEK for the victim, the attacker would still need to defeat the recipient-key mechanism. By retaining that field, the attacker causes the victim to perform the sensitive key-recovery operation legitimately. The attack then targets how the recovered CEK is used.

OFB turns a block cipher into a keystream generator. Encryption and decryption combine the generated keystream with input bytes. Unlike GCM, OFB does not authenticate the ciphertext. An attacker cannot simply derive the CEK from one arbitrary decryption result, but a system that repeatedly processes attacker-chosen OFB inputs under the real CEK and reveals meaningful success or failure information can become a cryptographic oracle.

The official advisory calls the possible result “key-equivalent functionality” for the CEK. That phrase should not be inflated into claims that the attacker necessarily exports the victim’s private key or directly learns all long-term key material.

The narrower and more accurate interpretation is that the vulnerable application may perform operations for the attacker that should require knowledge of the CEK. Depending on the application’s validation logic and observable responses, that capability may let the attacker test or derive information about encrypted content, generate outputs accepted as having been processed under the real CEK, or otherwise obtain cryptographic power comparable to possessing that content key in the affected workflow.

The attack also has important boundaries:

• The official scenario requires a legitimate AuthEnvelopedData message addressed to the target.
• The attacker must preserve the valid recipient data.
• The target must process the manipulated object with a vulnerable OpenSSL version.
• The application must expose a useful success, failure, output, timing, or business signal.
• Practical exploitation depends on what the application does with the decrypted bytes.
• The CEK is generally message-scoped, not automatically the victim’s long-term private key.

These boundaries explain why package presence alone is not enough to establish exploitability. They do not make the issue harmless. A secure-message gateway that receives external content and exposes structured processing results can satisfy several conditions by design.

Attack path two, shrinking the tag to one byte

The second path retains an AEAD algorithm but changes the authentication-tag length.

An authentication tag is not decorative metadata. It is the value the recipient checks to determine whether the ciphertext and authenticated data match what the sender produced. When the tag is sufficiently long and the algorithm is used correctly, an attacker who lacks the key has a negligible chance of guessing a valid value.

A one-byte tag has only 256 possible values:

2^8 = 256

A random tag guess therefore has a probability of:

1 / 256 = 0.00390625

That is approximately 0.39 percent for each independent attempt.

The OpenSSL advisory says an attacker can reduce the tag length for an AuthEnvelopedData object to one byte, brute-force CMS decryption, and bypass integrity checks in applications that rely on CMS_decrypt() to reject modified content. (seclists.org)

The probability is small for one request but dangerous when the attacker can repeat the attempt. The chance of at least one success after n independent attempts is:

P(success after n attempts) = 1 - (255 / 256)^n

Approximate cumulative probabilities are:

Number of attempts	Probability of at least one random match
1	0.39%
10	3.84%
50	17.77%
100	32.39%
177	About 50%
256	About 63.28%
500	About 85.86%
1,000	About 98.00%

These values assume independent attempts and a one-byte uniformly distributed tag. Real application behavior may introduce additional constraints, but the table shows why one-byte authentication is not a meaningful integrity boundary.

The comparison becomes clearer across tag sizes:

Tag length	Possible values	Random match probability per attempt	Operational interpretation
1 byte	2^8	1 in 256	Feasible to guess when submissions can be repeated
2 bytes	2^16	1 in 65,536	Still too weak for high-volume adversarial input
4 bytes	2^32	1 in about 4.29 billion	Lower generic boundary used by the OpenSSL fix
12 bytes	2^96	1 in 2^96	Recommended CMS tag size and minimum allowed for CMS AES-GCM
16 bytes	2^128	1 in 2^128	Full 128-bit tag space

A successful random tag match is not necessarily useful by itself. The modified plaintext must also survive any application-level parsing and authorization checks. However, many automated systems treat successful cryptographic processing as a major trust decision. A message that passes CMS_decrypt() may be forwarded, parsed as structured data, imported, indexed, or used to trigger a workflow.

The relevant questions are therefore:

• Can an attacker submit the same logical message many times?
• Are failed messages rate-limited or deduplicated?
• Can the attacker identify success through an HTTP status, SMTP response, queue event, email notification, processing delay, or external side effect?
• Does a successful decryption cause the application to trust the content?
• Is the decrypted content parsed by a privileged component?
• Does the service preserve output from failed attempts?
• Can the attacker vary the tag without changing a message identifier used for replay protection?

Rate limiting and uniform responses can reduce practical exploitability, but they do not restore cryptographic integrity. A vulnerable implementation that accepts one-byte tags remains defective even when surrounded by operational controls.

What key-equivalent functionality means

The phrase “key-equivalent functionality” can be misunderstood in both directions.

Overstatement would be claiming that CVE-2026-34182 directly reveals every recipient’s private key. The official advisory does not say that. The recipient private key is used to unwrap the legitimate CEK preserved in the captured recipientInfos. The described result concerns functionality equivalent to having that CEK in a selected message context.

Understatement would be treating the behavior as a harmless parser inconsistency. A target that carries out attacker-selected cryptographic operations under a secret CEK can expose capabilities that the attacker should not have. An oracle can sometimes turn a yes-or-no signal into progressive knowledge or allow the attacker to produce outputs accepted by the vulnerable system.

The practical impact depends on the oracle:

Observable behavior	Potential value to an attacker
Distinct success and failure status codes	Direct acceptance oracle
Different error text	Reveals which validation stage failed
Different response lengths	May distinguish parse, decrypt, and authentication outcomes
Timing differences	Can reveal whether key recovery or later processing occurred
Generated output file	Provides direct transformation results
Downstream webhook	Confirms acceptance through a business side effect
Queue or workflow state	Reveals that decrypted content reached another component
Email delivery or rejection	Gives a remote signal in S/MIME gateways
Parser-specific errors after decryption	Reveals properties of attacker-influenced plaintext

An application does not need to print the CEK for the behavior to be dangerous. It only needs to expose a reliable, repeatable relationship between attacker-controlled input and an operation performed under the secret key.

This is also why generic error handling is relevant but not sufficient. Removing a detailed error string may close one signal while leaving timing, output existence, downstream state, or retry behavior observable.

Moderate vendor severity and a 9.1 CVSS score

OpenSSL rates CVE-2026-34182 Moderate. NVD currently displays a CISA-ADP CVSS 3.1 base score of 9.1 Critical. NVD itself has not yet supplied a separate NIST score on the page. (openssl-library.org)

Security teams should not choose one label and discard the other. They answer different questions.

The CVSS vector describes a high-impact scenario with network access, low attack complexity, no required privileges, no user interaction, and high confidentiality and integrity effects. It is useful for representing the possible technical outcome when the vulnerable path is exposed.

A vendor severity rating can incorporate additional context that a base vector does not express well:

• Only CMS AuthEnvelopedData processing is affected.
• Many OpenSSL deployments do not use CMS at all.
• The first path requires a captured legitimate message for the recipient.
• Oracle value depends on observable application behavior.
• The tag-forgery path generally benefits from repeated attempts.
• The vulnerable operation may exist only in local or administrator-controlled workflows.
• A successful cryptographic bypass must still interact with application logic to produce a business impact.

The correct operational response is reachability-based prioritization.

優先順位	Environment	Recommended treatment
P1	Internet-facing or externally reachable CMS, S/MIME, or secure-message processing with automated decryption	Patch immediately, restrict input until patched, test negative cases, and review possible oracle signals
P2	Partner-facing or authenticated-user CMS ingestion that triggers automated workflows	Patch urgently, review authorization and replay controls, and verify output isolation
P3	Internal services or administrative tools that parse CMS from partially trusted sources	Patch in an accelerated maintenance window and document trust boundaries
P4	Systems with an affected library but no identified CMS, PKCS#7, or S/MIME processing path	Patch through normal security maintenance while preserving evidence of non-reachability
Not affected by this CVE	OpenSSL 1.1.1 or 1.0.2, or a downstream package with a confirmed backport	Record the supporting vendor evidence and suppress only the specific false positive

A Moderate vendor rating is not permission to delay remediation on a reachable mail gateway. A 9.1 score is not proof that every HTTPS endpoint is vulnerable. Both statements can be true.

Affected releases and fixed releases

OpenSSL lists the following supported release ranges as affected:

OpenSSL branch	影響を受けるバージョン	First fixed upstream version
4.0	4.0.0 before 4.0.1	4.0.1
3.6	3.6.0 before 3.6.3	3.6.3
3.5	3.5.0 before 3.5.7	3.5.7
3.4	3.4.0 before 3.4.6	3.4.6
3.0	3.0.0 before 3.0.21	3.0.21
1.1.1	Not affected by this issue	No CVE-specific update required
1.0.2	Not affected by this issue	No CVE-specific update required

These ranges come from the OpenSSL advisory and vulnerability record. (openssl-library.org)

Branches not listed in the supported-release table require special care. OpenSSL’s advisory notes that only currently supported releases were analyzed. Older 3.x branches that had already reached end of support should not be treated as safe merely because they do not appear in the fixed-version list. The correct action is to migrate unsupported branches to a supported, patched release or follow a downstream vendor’s maintained package guidance. (openssl-library.org)

Version comparison is also complicated by backports. Linux distributions frequently apply a security patch without changing the package to the exact upstream fixed version. A distribution package whose version begins with an older upstream number may still contain the fix.

For example, the following reasoning is unsafe:

Installed version says 3.0.17
Upstream fix is 3.0.21
Therefore the package must be vulnerable

A maintained distribution may have applied the relevant commit to its 3.0.17-based package and changed only the distribution revision. The authoritative status for that package comes from the distribution security advisory, changelog, or vulnerability tracker.

The reverse mistake is also common. Updating the operating system’s OpenSSL package does not patch:

• A statically linked application.
• A container image not rebuilt after the host update.
• A vendor appliance with its own firmware.
• An application that ships private libcrypto そして libssl copies.
• A language runtime or desktop application with bundled OpenSSL.
• A long-running process still mapping the previous library.
• A sidecar or job image built from an older base layer.

Security teams need package evidence and runtime evidence.

Systems most likely to be exposed

CVE-2026-34182 becomes relevant when untrusted or partially trusted CMS AuthEnvelopedData reaches a vulnerable OpenSSL processing path.

S/MIME mail systems

S/MIME uses CMS structures for encrypted and signed email. Potentially relevant components include:

• Desktop or mobile mail clients.
• Mail transfer or delivery systems that decrypt S/MIME.
• Secure email gateways.
• Journaling and archival products.
• Malware-scanning or data-loss-prevention systems.
• Mail-to-ticket and mail-to-workflow automation.
• S/MIME key escrow and recovery tools.
• Services that transform encrypted messages for browser access.

Not every S/MIME implementation uses the affected OpenSSL path. The relevant question is whether the product processes AuthEnvelopedData through an affected OpenSSL release.

CMS and PKCS#7 upload endpoints

Web applications and APIs sometimes accept .p7m, .p7c, .p7b, .cms, or related objects. File extensions are only hints, because CMS can be transported under many names and MIME types.

Relevant features include:

• Encrypted document upload.
• Secure form submission.
• Message exchange with government or regulated systems.
• Certificate enrollment and renewal.
• B2B message gateways.
• Electronic invoicing or document exchange.
• Import tools for encrypted configuration packages.
• Partner portals that accept signed or encrypted containers.

An upload endpoint may hand the content to a backend worker, a shell command, a library wrapper, or a commercial document-processing engine. The vulnerable library may therefore sit several components behind the visible HTTP endpoint.

PKI and certificate-management tooling

CMS appears in certificate and key-management environments. Relevant systems may include:

• Certificate authorities.
• Registration-authority services.
• Enrollment gateways.
• Hardware security module management software.
• Certificate lifecycle platforms.
• Key recovery services.
• Secure provisioning pipelines.
• Administrative tools that decrypt CMS packages.

The presence of certificate processing does not prove AuthEnvelopedData usage. Code and workflow inspection are still required.

Internal automation

Internal scripts are often overlooked because they are not obvious network services. Examples include:

openssl cms -decrypt ...
openssl smime -decrypt ...

A script may consume attachments from a mailbox, files from object storage, messages from a queue, or documents from a partner share. If an external party can influence those inputs, an “internal” script can still process adversarial content.

Commercial and embedded products

OpenSSL may be embedded in:

• Network appliances.
• Secure mail products.
• Document-management software.
• Backup or archival tools.
• Industrial gateways.
• Medical or financial messaging systems.
• Firmware update utilities.
• Device provisioning software.
• Enterprise middleware.

A product’s external version number may reveal nothing about the embedded OpenSSL build. Vendor advisories and software composition data are necessary.

Systems that are not automatically exposed

Several common observations are insufficient to prove CVE-2026-34182 exposure.

The server supports HTTPS

The vulnerability is in CMS AuthEnvelopedData processing, not the ordinary TLS record or handshake path. A service using OpenSSL only to terminate HTTPS is not automatically reachable through this flaw.

The application links to libcrypto

CMS code lives in the OpenSSL cryptographic library, but library linkage does not prove the application calls CMS_decrypt() or another relevant path.

The host has the openssl command installed

The command-line utility may exist even when no production workflow invokes openssl cms または openssl smime.

The application accepts certificates

Parsing an X.509 certificate is not the same operation as decrypting CMS AuthEnvelopedData.

A scanner found an affected package

Package detection is an important first step. It establishes potential presence, not input reachability, runtime linkage, or exploit conditions.

The service uses a FIPS provider

OpenSSL states that its FIPS modules are not affected because CMS processing is outside the FIPS module boundary. That does not establish that the surrounding non-FIPS CMS code in the application is patched. The operational implication is that “FIPS enabled” and “CVE-2026-34182 not reachable” are different claims. (seclists.org)

The application rejects malformed ASN.1

The malicious object may still be structurally parseable. The problem is insufficient semantic validation of an algorithm choice and authentication-tag length, not necessarily a basic DER decoding failure.

A reachability-first inventory workflow

A useful investigation separates component presence from vulnerable behavior.

Step one, record upstream and package versions

Start with local, authorized systems.

openssl version -a

On Debian or Ubuntu:

dpkg-query -W \
  -f='${binary:Package}\t${Version}\n' \
  'openssl' 'libssl*' 2>/dev/null

On RHEL, Fedora, Rocky Linux, or AlmaLinux:

rpm -qa | grep -E '^openssl($|-)|^openssl-libs($|-)'

On Alpine:

apk info -vv openssl libssl3 libcrypto3 2>/dev/null

The result should be compared with the operating-system vendor’s advisory, not only with the upstream table.

Step two, identify the library loaded by the application

For a dynamically linked Linux binary:

ldd /opt/example/bin/message-gateway \
  | grep -E 'libssl|libcrypto'

For ELF dependency declarations:

readelf -d /opt/example/bin/message-gateway \
  | grep -E 'NEEDED.*libssl|NEEDED.*libcrypto'

For a running Linux process:

pid="$(pgrep -n message-gateway)"
grep -E 'libssl|libcrypto' "/proc/${pid}/maps"

These checks answer different questions:

• ldd shows what the loader currently resolves for a binary.
• readelf shows declared shared-library dependencies.
• /proc/PID/maps shows what the running process has actually mapped.

A process started before an update may continue using the old library until restarted.

On macOS, a local binary can be inspected with:

otool -L /Applications/Example.app/Contents/MacOS/Example \
  | grep -E 'libssl|libcrypto'

Step three, search for CMS use

Search source code and deployment scripts for relevant APIs:

rg -n \
  'CMS_decrypt|CMS_ContentInfo|d2i_CMS|PEM_read_bio_CMS|SMIME_read_CMS|PKCS7_decrypt' \
  ./src ./services ./scripts

Search for command-line use:

rg -n \
  'openssl[[:space:]]+(cms|smime)|cms[[:space:]]+-decrypt|smime[[:space:]]+-decrypt' \
  ./deploy ./jobs ./scripts ./config

Search MIME and file-handling logic:

rg -n \
  'application/pkcs7-mime|application/pkcs7-signature|smime-type|\.p7m|\.p7c|\.cms' \
  ./src ./config

These patterns are indicators, not proof. Wrappers may hide the API name, and a library may invoke CMS functions internally.

Step four, follow the data path

For each possible CMS consumer, document:

Input source
    ↓
Authentication boundary
    ↓
File or message parser
    ↓
OpenSSL wrapper or command
    ↓
Output location
    ↓
Downstream parser
    ↓
Business action
    ↓
Externally observable result

The following questions determine priority:

• Can an unauthenticated external party supply the message?
• Can a customer, partner, or ordinary user supply it?
• Is the message accepted through email rather than HTTP?
• Does a worker automatically decrypt it?
• Can the sender retry?
• Does the response expose detailed errors?
• Is decrypted content written before all checks complete?
• Does a successful result trigger import, delivery, indexing, or execution?
• Is the output processed with higher privileges than the input-facing service?
• Are message identifiers used for replay prevention?

Step five, inspect container and image exposure

Checking the host is not enough.

For a locally available image:

docker run --rm --entrypoint sh example/message-gateway:approved \
  -lc '
    openssl version -a 2>/dev/null || true
    apk info -vv 2>/dev/null | grep -E "openssl|libssl|libcrypto" || true
    dpkg-query -W -f="${binary:Package}\t${Version}\n" 2>/dev/null \
      | grep -E "openssl|libssl" || true
    rpm -qa 2>/dev/null | grep -E "^openssl|^openssl-libs" || true
  '

The command is intended for an image owned or authorized by the tester. It does not determine reachability by itself.

Step six, create an evidence record

A defensible record should include:

Evidence field	例
Asset	mail-decrypt-worker-prod-03
Product or service owner	Messaging Security
OpenSSL package	Distribution package and revision
Runtime-loaded library	Resolved path and file hash
Relevant API	CMS_decrypt() through internal wrapper
Input trust	External S/MIME email
Automatic processing	はい
Observable result	SMTP disposition and delivery outcome
Patch status	Patched or pending
Restart status	Confirmed with process start time
Negative test	Non-AEAD and invalid-tag fixtures rejected
Plaintext handling	Temporary isolated file, deleted on failure
Residual risk	Replay behavior under review

For larger estates, authorized AI-assisted validation can help correlate package findings with real message-processing paths, but the output should remain evidence-driven and reviewable. 寡黙 describes agentic workflows built around traceable findings, while its analysis of CVE-2025-15467 provides a closely related example of why OpenSSL CMS reachability matters more than package presence alone. The same discipline applies here: identify the actual parser, constrain testing to authorized assets, and retain reproducible remediation evidence. (寡黙)

Safe educational PoC, why a one-byte tag fails

The following demonstration models only the probability problem created by a one-byte authentication tag. It does not generate CMS, invoke OpenSSL, use certificates, construct a malicious AuthEnvelopedData object, or communicate with any service.

It cannot be used as a payload against a real system.

The demonstration uses HMAC-SHA-256 as a familiar source of authentication values and truncates the result to one byte. HMAC is not the same construction as AES-GCM or AES-CCM, but a uniformly distributed one-byte authentication value has the same 1-in-256 random-guess property.

from __future__ import annotations

import hashlib
import hmac
import secrets
import statistics


def truncated_tag(key: bytes, message: bytes, length: int) -> bytes:
    """Return a deliberately truncated authentication tag."""
    if length < 1:
        raise ValueError("length must be at least one byte")

    full_tag = hmac.new(key, message, hashlib.sha256).digest()
    return full_tag[:length]


def guesses_until_match(expected_tag: bytes) -> int:
    """
    Randomly guess a tag until it matches.

    This function models probability only. It does not parse CMS,
    call OpenSSL, or send data anywhere.
    """
    attempts = 0

    while True:
        attempts += 1
        guess = secrets.token_bytes(len(expected_tag))

        if hmac.compare_digest(guess, expected_tag):
            return attempts


def run_experiment(trials: int = 1000) -> None:
    key = secrets.token_bytes(32)
    forged_message = b"toy-message-with-no-production-meaning"

    one_byte_tag = truncated_tag(
        key=key,
        message=forged_message,
        length=1,
    )

    results = [
        guesses_until_match(one_byte_tag)
        for _ in range(trials)
    ]

    print(f"Trials: {trials}")
    print(f"Mean guesses: {statistics.mean(results):.2f}")
    print(f"Median guesses: {statistics.median(results):.2f}")
    print(f"Fewest guesses: {min(results)}")
    print(f"Most guesses: {max(results)}")


if __name__ == "__main__":
    run_experiment()

A typical run will produce a mean near 256, but individual trials vary widely. Some guesses succeed immediately. Others take hundreds or thousands of attempts. That variation is expected because the number of guesses follows a geometric distribution.

The median is lower than the mean. Approximately 177 independent attempts are enough to reach about a 50 percent cumulative chance of at least one match:

from __future__ import annotations


def cumulative_success_probability(
    attempts: int,
    tag_bytes: int,
) -> float:
    possibilities = 2 ** (8 * tag_bytes)
    miss_probability = 1 - (1 / possibilities)

    return 1 - (miss_probability ** attempts)


for attempts in (1, 10, 50, 100, 177, 256, 500, 1000):
    probability = cumulative_success_probability(
        attempts=attempts,
        tag_bytes=1,
    )

    print(
        f"{attempts:4d} attempts: "
        f"{probability * 100:6.2f}%"
    )

The security lesson is not that all 256 values must be tried in a fixed sequence. The lesson is that reducing a tag to one byte destroys the margin that makes random forgery infeasible.

For comparison, randomly guessing a valid 12-byte tag requires matching one value in a space of 2^96 possibilities. Even extremely high request volumes do not make that comparable to a one-byte tag.

This PoC deliberately omits the dangerous parts:

• No malicious ASN.1 construction.
• No algorithm OID replacement.
• No valid recipient data.
• No captured encrypted message.
• No decryption oracle.
• No network requests.
• No automated target testing.
• No production certificates.
• No attempt to bypass an actual application.

Its purpose is to help defenders explain why tag-length validation is a cryptographic requirement rather than a cosmetic parser check.

Local validation without weaponizing the flaw

A responsible regression test does not require publishing a production-ready exploit.

The objective is to prove three properties in an isolated environment:

1. AuthEnvelopedData selecting a non-AEAD cipher is rejected.
2. AuthEnvelopedData with an invalidly short authentication tag is rejected.
3. No plaintext is committed or used when validation fails.

Use controlled fixtures

Fixtures should be generated or reviewed internally and stored in a restricted test repository. They should contain:

• Test-only certificates.
• Test-only private keys.
• Synthetic plaintext.
• No production identities.
• No customer data.
• No reusable production message.
• A clear expected result.
• A cryptographic hash recorded in the test manifest.

A manifest might look like:

fixtures:
  - name: valid-aes-gcm-auth-enveloped
    sha256: "REPLACE_WITH_INTERNAL_TEST_HASH"
    expected_result: accept
    contains_sensitive_data: false

  - name: invalid-non-aead-auth-enveloped
    sha256: "REPLACE_WITH_INTERNAL_TEST_HASH"
    expected_result: reject
    contains_sensitive_data: false

  - name: invalid-one-byte-tag
    sha256: "REPLACE_WITH_INTERNAL_TEST_HASH"
    expected_result: reject
    contains_sensitive_data: false

The intentionally malformed files are not included here. That keeps the example focused on defensive test structure rather than transferable exploitation material.

Inspect a local CMS object

For an authorized DER fixture:

openssl cms \
  -cmsout \
  -print \
  -inform DER \
  -in ./fixtures/approved-sample.der

For lower-level ASN.1 inspection:

openssl asn1parse \
  -inform DER \
  -in ./fixtures/approved-sample.der \
  -i

These commands help identify the CMS content type, algorithm identifiers, parameters, and field layout. They do not establish that the application’s own wrapper applies the same validation.

Keep output transactional

Never send decryption output directly into a downstream parser merely because a command has started producing bytes.

A safer shell pattern is:

#!/usr/bin/env sh

set -eu

input_file="./fixtures/approved-sample.der"
recipient_cert="./lab/recipient-cert.pem"
recipient_key="./lab/recipient-key.pem"
verified_output="./lab-output/verified-content.bin"

umask 077

temporary_output="$(mktemp ./lab-output/.cms-decrypt.XXXXXX)"

cleanup() {
    rm -f "$temporary_output"
}

trap cleanup EXIT INT TERM

if openssl cms \
    -decrypt \
    -inform DER \
    -in "$input_file" \
    -recip "$recipient_cert" \
    -inkey "$recipient_key" \
    -out "$temporary_output"
then
    mv "$temporary_output" "$verified_output"
    trap - EXIT INT TERM
    printf '%s\n' "CMS validation succeeded"
else
    printf '%s\n' "CMS validation failed" >&2
    exit 1
fi

The key behavior is not the exact command syntax. It is the commit boundary:

• Output goes to a restrictive temporary file.
• No consumer receives the file while validation is unresolved.
• Failure deletes the temporary output.
• Success moves the completed output into its final location.
• Downstream processing begins only after the command returns success.

RFC 5083’s requirement to verify integrity before releasing plaintext supports this design. (IETFデータトラッカー)

Compare old and fixed builds

An internal test matrix should include:

Test	Vulnerable build expected result	Fixed build expected result
Valid approved AuthEnvelopedData	Success	Success
AuthEnvelopedData with non-AEAD cipher	May proceed incorrectly	Failure
AuthEnvelopedData with one-byte tag	May reach weak validation path	Failure
Corrupted full-length tag	Failure	Failure
Wrong recipient	Failure without useful external distinction	Failure without useful external distinction
Failed validation output retained	いいえ	いいえ
Failed validation sent downstream	いいえ	いいえ

The purpose is regression assurance, not exploitation. Tests should run against local binaries, disposable containers, or isolated staging services owned by the organization.

Detection signals that matter

There is no universal network signature that proves exploitation of CVE-2026-34182 across every product. CMS can be transported over email, HTTP, message queues, file shares, or proprietary protocols. It may also be nested inside MIME or another container.

Detection is strongest when the application records security-relevant CMS metadata.

信号	なぜそれが重要なのか	Recommended response
Non-AEAD algorithm in AuthEnvelopedData	Directly conflicts with the authenticated-encryption content type	Reject before decryption and alert
Tag length below policy	Indicates malformed or intentionally weakened authentication	Reject and record algorithm plus length
AES-GCM tag outside 12 to 16 bytes	Violates the CMS AES-GCM profile	Reject before processing content
AES-CCM tag outside its allowed set	Violates the CMS AES-CCM profile	Reject before processing content
Repeated near-identical messages with changing tag bytes	Consistent with tag guessing or parser probing	Rate-limit, correlate, and investigate
Sudden increase in CMS failures	May indicate fuzzing, malformed traffic, or a broken integration	Group by source and sample hash
Distinct external errors for key, cipher, tag, and content failures	Can provide an oracle	Normalize external responses
Temporary plaintext after failure	Violates safe release behavior	Delete, investigate, and fix output handling
Downstream parser activity following CMS failure	Indicates a broken transaction boundary	Stop the workflow and review affected records
Old OpenSSL mapped by a running process	Patch may be installed but inactive	Restart or redeploy the process
Unexpected openssl cms または openssl smime process execution	May reveal undocumented CMS automation	Identify the owner and input source
Multiple recipient-processing anomalies	May interact with other CMS oracle conditions	Review certificate selection and error handling

Useful log fields include:

{
  "event_type": "cms_decryption",
  "content_type": "authEnvelopedData",
  "content_algorithm_oid": "redacted-or-normalized-oid",
  "content_algorithm_name": "AES-GCM",
  "tag_length_bytes": 16,
  "recipient_count": 1,
  "recipient_match": true,
  "integrity_result": "success",
  "plaintext_committed": true,
  "source_trust_zone": "external-email",
  "fixture_or_message_sha256": "hash-only",
  "correlation_id": "internal-request-id",
  "openssl_runtime_version": "vendor-package-version"
}

Do not log:

• Recipient private keys.
• Recovered CEKs.
• Passwords.
• Full plaintext.
• Full sensitive ciphertext without a retention need.
• Unredacted personal email content.
• Raw secrets from OpenSSL error contexts.

A hash of the original message can help group repeated attempts without storing another full copy of sensitive content.

External responses should be boring

A public response should not reveal whether failure occurred during:

• Recipient selection.
• Private-key unwrapping.
• Cipher initialization.
• Tag-length validation.
• Tag comparison.
• Plaintext parsing.
• Business authorization.

Internally, those distinctions are valuable. Externally, they may create an oracle.

A generic response can be paired with a detailed internal event:

External:
The secure message could not be processed.

Internal:
Rejected AuthEnvelopedData before decryption because
AES-GCM tag length was one byte.

Uniform text alone is not enough. Status code, body length, timing, retry behavior, email disposition, and downstream side effects should also be reviewed.

Patch and mitigation plan

Upgrade supported upstream branches

Use at least:

• OpenSSL 4.0.1 for the 4.0 branch.
• OpenSSL 3.6.3 for the 3.6 branch.
• OpenSSL 3.5.7 for the 3.5 branch.
• OpenSSL 3.4.6 for the 3.4 branch.
• OpenSSL 3.0.21 for the 3.0 branch.

These are the fixed upstream releases identified by OpenSSL. (openssl-library.org)

For distribution packages and commercial products, install the vendor’s fixed package or firmware even when its displayed upstream base version differs.

Restart everything that loaded the old library

After updating:

pid="$(pgrep -n message-gateway)"
grep -E 'libssl|libcrypto' "/proc/${pid}/maps"
ps -p "$pid" -o pid,lstart,cmd

Compare the process start time with the update. For immutable infrastructure, rebuild and redeploy rather than mutating only the host.

Restrict exposed CMS ingestion when patching is delayed

Temporary controls may include:

• Disable external AuthEnvelopedData processing.
• Queue messages without decrypting them.
• Restrict submissions to authenticated partners.
• Route processing to a patched service.
• Require manual review for high-value workflows.
• Block unsupported algorithms at an upstream parser.
• Enforce strict tag-length policy before decryption.
• Limit repeated submissions.
• Deduplicate identical message bodies.
• Disable automatic business actions based on decrypted content.

These measures reduce exposure but do not replace the OpenSSL fix.

Enforce an algorithm allowlist

Applications that know their approved CMS profile should not accept arbitrary algorithms merely because OpenSSL recognizes them.

A conceptual policy could be:

cms_auth_enveloped_policy:
  allowed_content_encryption_algorithms:
    - aes-128-gcm
    - aes-192-gcm
    - aes-256-gcm
    - aes-128-ccm
    - aes-192-ccm
    - aes-256-ccm

  allowed_tag_lengths:
    aes-gcm:
      - 12
      - 13
      - 14
      - 15
      - 16

    aes-ccm:
      - 4
      - 6
      - 8
      - 10
      - 12
      - 14
      - 16

  reject_unknown_algorithms: true
  reject_missing_parameters: true
  release_plaintext_only_after_authentication: true

An organization may choose a narrower policy, such as requiring a 16-byte GCM tag for newly generated messages while retaining selected lengths for compatibility.

Make failure atomic

A secure service should behave as though failed decryption produced no plaintext.

Conceptual application logic:

from __future__ import annotations

from pathlib import Path
from tempfile import NamedTemporaryFile
from typing import Callable


class CmsValidationError(Exception):
    pass


def process_authenticated_cms(
    encrypted_message: bytes,
    decrypt_and_verify: Callable[[bytes, Path], bool],
    publish_verified_file: Callable[[Path], None],
) -> None:
    """
    Decrypt to protected temporary storage and publish only after
    the cryptographic operation reports complete success.
    """
    temporary_path: Path | None = None

    try:
        with NamedTemporaryFile(
            prefix="cms-pending-",
            delete=False,
        ) as temporary_file:
            temporary_path = Path(temporary_file.name)

        verified = decrypt_and_verify(
            encrypted_message,
            temporary_path,
        )

        if not verified:
            raise CmsValidationError(
                "CMS integrity verification failed"
            )

        publish_verified_file(temporary_path)
        temporary_path = None

    finally:
        if temporary_path is not None:
            temporary_path.unlink(missing_ok=True)

In a real implementation, the temporary location should have restrictive permissions, encryption and retention controls appropriate to the data, and protection against other processes opening the file before commit.

Retest negative cases

A patch should not be closed based only on the package manager reporting success.

検証する：

• Runtime library version.
• Service restart.
• Non-AEAD AuthEnvelopedData rejection.
• Invalid tag-length rejection.
• Corrupted normal-length tag rejection.
• No plaintext retained on failure.
• No detailed external failure distinction.
• No business action on failed validation.
• Successful processing of known-good messages.
• Compatibility with approved partners.

Application hardening beyond the library update

CVE-2026-34182 exposes an architectural problem that appears repeatedly in cryptographic software: applications often trust a low-level decryption result more broadly than the result justifies.

Treat algorithm identifiers as attacker-controlled input

An algorithm OID inside an incoming message is data supplied by the message author or modifier. It should not automatically select any algorithm available in the local cryptographic provider.

The application should ask:

• Is this algorithm valid for this CMS content type?
• Is it approved by organizational policy?
• Are its parameters present?
• Are the parameters within protocol constraints?
• Is the algorithm deprecated?
• Is the combination interoperable with the expected sender profile?

“OpenSSL supports it” is not the same as “the protocol permits it here.”

Separate decryption from trust

A successful decryption operation can mean only that bytes were transformed. It does not automatically prove:

• The sender’s identity.
• The sender’s authorization.
• The freshness of the message.
• The absence of replay.
• The business validity of the content.
• The safety of parsing the content.
• The correctness of attached metadata.
• Approval for a requested transaction.

A safer state model is:

RECEIVED
  ↓
STRUCTURE_VALIDATED
  ↓
RECIPIENT_SELECTED
  ↓
CRYPTOGRAPHICALLY_AUTHENTICATED
  ↓
SENDER_IDENTITY_RESOLVED
  ↓
REPLAY_CHECKED
  ↓
AUTHORIZED
  ↓
BUSINESS_SCHEMA_VALIDATED
  ↓
COMMITTED

No downstream component should infer オーソライズド merely from a low-level CMS_decrypt() success result.

Supply the intended recipient context

OpenSSL’s CMS_decrypt() documentation recommends providing the recipient certificate when using the private key. Without it, OpenSSL may need to try possible recipients, and recipient-selection behavior has security consequences. The same documentation warns that the CMS_DEBUG_DECRYPT flag can expose applications, especially automated gateways, to attack. (docs.openssl.org)

Applications should:

• Identify the expected recipient before decryption when possible.
• Provide the associated certificate.
• Avoid debug behavior in production.
• Normalize errors exposed to remote parties.
• Record internal diagnostic detail securely.
• Test messages with multiple RecipientInfo entries.

Enforce replay controls

AuthEnvelopedData integrity does not by itself prove freshness. A valid old message may still be replayed.

Depending on the protocol, replay controls can use:

• Unique message identifiers.
• Signed timestamps.
• Sequence numbers.
• Transaction IDs.
• Sender-specific counters.
• Database uniqueness constraints.
• Short acceptance windows.
• Business-level idempotency keys.

Replay protection also makes repeated tag guessing harder to operationalize, though it is not a substitute for correct tag validation.

Delay content parsing

Decrypted bytes may contain:

• MIME.
• XML.
• JSON.
• Compressed archives.
• Office documents.
• Executable content.
• Certificate structures.
• Commands or workflow instructions.

Do not feed those bytes to another parser until authentication succeeds. Otherwise, an integrity failure in the outer layer may still expose the inner parser to attacker-influenced content.

Use one final commit point

High-value actions should occur only after every required check succeeds.

例を挙げよう：

• Importing a certificate.
• Updating a key.
• Creating a payment instruction.
• Opening a support ticket with privileged metadata.
• Delivering an email.
• Publishing a document.
• Triggering a deployment.
• Enabling a device configuration.
• Advancing a regulated workflow.

A database transaction, atomic file rename, or queue publication can serve as the commit point. Before it, the data is untrusted and disposable.

FIPS, downstream packages, and embedded copies

OpenSSL says its FIPS modules are not affected by CVE-2026-34182. The reason is boundary-specific: CMS processing occurs outside the OpenSSL FIPS module. (seclists.org)

That statement supports two conclusions:

1. The validated cryptographic module itself does not contain the affected CMS implementation.
2. An application using the FIPS module may still use vulnerable CMS code outside that boundary.

The second conclusion is an operational inference from the architecture. Teams should not close the CVE solely because an application reports that the FIPS provider is active.

A complete inventory should distinguish:

レイヤー	Verification question
FIPS provider	Is the validated provider enabled and correctly configured
OpenSSL core and CMS code	Is the surrounding OpenSSL build patched
Application wrapper	Does it enforce algorithm and parameter policy
Input boundary	Can untrusted parties submit CMS content
Output boundary	Is plaintext withheld until authentication succeeds
Product package	Has the vendor confirmed remediation
Runtime process	Has the patched binary or library actually been loaded

Downstream packages require similar precision. A vendor may backport the exact security fix. Conversely, a product may remain vulnerable even after the host package is updated because it contains a private copy.

SBOM data can help locate copies, but it should be supplemented with:

• File hashes.
• Runtime maps.
• Container digests.
• Package changelogs.
• Vendor VEX statements.
• Firmware release notes.
• Process restart evidence.
• Application-level negative tests.

Related OpenSSL CVEs and the broader lesson

CVE-2026-34182 belongs to a broader class of failures in which secure cryptographic primitives are undermined by parser behavior, parameter validation, API semantics, or observable error handling.

CVE	Relevant component	Main condition	Principal impact	Shared lesson
CVE-2025-15467	CMS AuthEnvelopedData and EnvelopedData AEAD parsing	Oversized attacker-controlled IV copied into a fixed stack buffer before authentication	Crash and possible remote code execution	Reachable CMS parsing code can be more important than general OpenSSL presence
CVE-2026-34181	PKCS#12 PBMAC1 validation	Attacker specifies a one-byte HMAC key	Forged certificate and private-key containers may be accepted with a 1-in-256 probability	Authentication parameters must have minimum security strength
CVE-2026-34182	CMS AuthEnvelopedData	Non-AEAD cipher accepted or AEAD tag reduced to one byte	Integrity bypass and possible key-equivalent oracle functionality	The parser must preserve the security contract of the content type
CVE-2026-42768	CMS_decrypt() そして PKCS7_decrypt()	Specific multi-recipient and observable error or output conditions	Bleichenbacher-style oracle using the victim’s RSA key	Decryption errors and output differences can become cryptographic oracles
CVE-2026-45445	AES-OCB through the EVP_Cipher() one-shot path	Application uses an API path that discards the supplied IV	Nonce reuse, loss of confidentiality, and possible universal forgery	Correct algorithms fail when parameters or API state are mishandled

CVE-2025-15467

CVE-2025-15467 is a stack buffer overflow in OpenSSL CMS AuthEnvelopedData or EnvelopedData parsing. A crafted AEAD IV can exceed a fixed-size destination, causing an out-of-bounds stack write before authentication or tag verification. NVD says the result may be denial of service or potentially remote code execution. The flaw matters most where untrusted CMS or PKCS#7 content reaches the affected parser. (NVD)

Its relationship to CVE-2026-34182 is the parser surface. Both vulnerabilities punish teams that equate “OpenSSL installed” with a complete exposure assessment. One is a memory-safety failure; the other undermines authenticated-message validation. Both require defenders to find actual CMS-processing paths.

CVE-2026-34181

CVE-2026-34181 concerns PKCS#12 files using PBMAC1. OpenSSL says a service can accept a container configured with an HMAC key of only one byte, allowing a forged certificate and private key to be accepted with a probability of one in 256. (openssl-library.org)

The object format and validation path differ from CVE-2026-34182, but the security lesson is nearly identical: attacker-controlled parameters cannot be allowed to reduce authentication to eight bits.

CVE-2026-42768

CVE-2026-42768 affects CMS_decrypt() そして PKCS7_decrypt() under particular multi-recipient and observable-response conditions. OpenSSL describes Bleichenbacher-style oracle variants that could let an attacker use a vulnerable application to decrypt or sign with the victim’s RSA key. OpenSSL rated it Low because it considered remotely exploitable applications satisfying the required conditions very unlikely. (openssl-library.org)

The relevance to CVE-2026-34182 is not that the exploits are identical. It is that application-visible differences matter. A cryptographic library can attempt to reduce oracle behavior, but a wrapper that exposes detailed errors, partial output, or business side effects may recreate a useful signal.

CVE-2026-45445

CVE-2026-45445 affects AES-OCB when an application drives the cipher through the public EVP_Cipher() one-shot interface. OpenSSL says the application-supplied IV can be ignored, leading to effective nonce reuse, confidentiality loss, and possible universal forgery when the same path computes the tag. (openssl-library.org)

This comparison shows why algorithm names alone do not prove security. AES-OCB, AES-GCM, and AES-CCM are authenticated-encryption designs, but secure outcomes still depend on correct nonce handling, parameter validation, API use, and tag enforcement.

Worked example, an S/MIME gateway

The following is an illustrative scenario, not a report of a known breach.

A company operates an inbound S/MIME gateway with these characteristics:

• External senders can deliver encrypted mail.
• A worker uses OpenSSL 3.0.20.
• The worker calls an internal wrapper around CMS_decrypt().
• Successful decryption causes the message body to be forwarded to a document-classification service.
• The gateway returns different SMTP dispositions for recipient failure, decryption failure, and accepted content.
• Failed output is written to a temporary directory for troubleshooting.
• The directory is cleaned once per day.
• The service is marked “FIPS enabled.”
• The host package was updated, but the worker runs in an older container image.

This environment should be treated as high priority.

Why it is reachable

The input comes from external email and reaches CMS processing automatically. Unlike a TLS-only service, the affected message format is part of the product’s intended function.

Why the version is affected

OpenSSL 3.0.20 is below the upstream fixed 3.0.21 release. The container image must be checked independently of the host.

Why the response may be an oracle

Different SMTP dispositions can reveal which processing stage failed. Even when the response text is generic, delivery behavior or timing may show whether the content reached the next stage.

Why temporary output matters

The once-daily cleanup means failed plaintext-like output may persist and could be inspected or consumed by another process. RFC 5083 requires plaintext to be withheld and destroyed when integrity verification fails. (IETFデータトラッカー)

Why FIPS does not close the issue

The OpenSSL FIPS module is not affected, but CMS processing is outside that module boundary. The application still needs a patched surrounding OpenSSL build.

Correct remediation sequence

1. Stop or queue externally supplied S/MIME processing if a rapid patch cannot be deployed safely.
2. Rebuild the worker image with a vendor-fixed package or OpenSSL 3.0.21 or later in the supported branch.
3. Redeploy every worker and verify the runtime-loaded library.
4. Enforce AEAD-only ciphers for AuthEnvelopedData.
5. Enforce algorithm-specific tag lengths.
6. Replace externally distinguishable cryptographic errors with a uniform failure.
7. Preserve detailed internal reason codes in restricted logs.
8. Write output to a restrictive temporary location.
9. Delete output immediately on any failure.
10. Publish plaintext to the classifier only after complete authentication.
11. Run approved positive and negative fixtures.
12. Review logs for repeated malformed messages and unusual failure clusters.
13. Update the SBOM and remediation record.
14. Test replay handling and duplicate-message controls.

Evidence required to close the issue

A credible closure record should contain:

• Updated container digest.
• Package advisory or upstream-version evidence.
• Runtime libcrypto path and hash.
• Worker restart or deployment timestamp.
• Test result showing rejection of non-AEAD AuthEnvelopedData.
• Test result showing rejection of a one-byte tag.
• Test result showing no output survives failure.
• Test result showing successful processing of an approved message.
• External-response comparison confirming uniform behavior.
• Owner approval for the remaining CMS policy.

That record is more meaningful than a scanner status changing from red to green.

Common triage mistakes

Treating every OpenSSL deployment as equally exploitable

This produces noise. The vulnerable code is CMS-specific. Prioritize services that actually parse and decrypt AuthEnvelopedData.

Checking only public HTTPS endpoints

The relevant parser may be in a mail gateway, background worker, PKI service, desktop application, or partner integration.

Assuming no Web route means no remote input

Email, object storage, queues, shared folders, and file-transfer systems can all carry attacker-influenced CMS objects.

Treating FIPS use as proof of safety

The FIPS module status does not establish the status of CMS code outside the module boundary.

Updating the host but not containers

A container continues to use its image libraries unless rebuilt or updated through an intentional image process.

Updating the package but not restarting the process

A running service can retain mappings to the old shared library.

Relying only on openssl version

The command may report a different installation from the library loaded by the application.

Treating decryption success as sender authentication

CMS decryption, integrity, signer identity, certificate trust, authorization, and business approval are separate decisions.

Logging sensitive plaintext for debugging

Detailed security telemetry is valuable, but raw decrypted content can create a second incident.

Testing production with a transferable exploit

A safe regression test needs controlled fixtures and expected failure behavior, not a reusable attack package aimed at live services.

Believing rate limiting fixes the cryptography

Rate limiting may reduce repeated guessing. It does not make a one-byte tag secure or prevent the non-AEAD substitution path.

Ignoring successful malformed-message processing

A malformed message that returns success but produces unusable data is still significant. The cryptographic trust boundary has failed even when a later parser rejects the content.

Suppressing the CVE based only on application owner statements

Statements such as “we do not use CMS” should be supported by code search, runtime evidence, vendor documentation, or test results.

Primary engineering resources

• OpenSSL security advisory: The authoritative source for the two attack scenarios, affected branches, fixed versions, FIPS status, and reporter information. (seclists.org)
• NVD record for CVE-2026-34182: Useful for the current CISA-ADP CVSS vector and consolidated references to the OpenSSL patches. (NVD)
• RFC 5083: Defines AuthEnvelopedData and requires integrity verification before plaintext is released. (IETFデータトラッカー)
• RFC 5084: Defines CMS use of AES-CCM and AES-GCM, including permitted authentication-tag lengths. (IETFデータトラッカー)
• オープンSSL CMS_decrypt() documentation: Describes recipient handling, return values, and oracle-related cautions for automated gateways. (docs.openssl.org)

Frequently asked questions

Does CVE-2026-34182 affect normal HTTPS websites?

• Not through ordinary TLS processing alone. The vulnerable operation is CMS AuthEnvelopedData processing, not the standard HTTPS handshake or TLS record path.
• An HTTPS application can still be exposed if it provides an upload or API feature that sends attacker-controlled CMS content to CMS_decrypt() or an equivalent vulnerable path.
• Library presence is only the first signal. Confirm whether the application handles CMS, PKCS#7, S/MIME, or encrypted message containers.
• Background services matter. A public Web request may place a file into a queue that is later processed by a vulnerable worker.

Which OpenSSL versions should be upgraded?

• OpenSSL 4.0: Upgrade to 4.0.1 or later in the supported branch.
• OpenSSL 3.6: Upgrade to 3.6.3 or later.
• OpenSSL 3.5: Upgrade to 3.5.7 or later.
• OpenSSL 3.4: Upgrade to 3.4.6 or later.
• OpenSSL 3.0: Upgrade to 3.0.21 or later.
• OpenSSL 1.1.1 and 1.0.2: OpenSSL identifies them as not affected by this specific vulnerability.
• Distribution packages: Follow the operating-system vendor’s fixed package revision because the patch may be backported.
• Unsupported branches: Move to a supported branch rather than interpreting omission from the advisory as proof of safety. (openssl-library.org)

Why does OpenSSL call the vulnerability Moderate when NVD displays 9.1 Critical?

• OpenSSL’s rating considers practical context. The vulnerable CMS path is not active in every application using OpenSSL.
• The first scenario has meaningful prerequisites. It involves a legitimate message for the victim, manipulation of that message, and an observable application response or effect.
• The second scenario benefits from repeated attempts. A one-byte tag gives a 1-in-256 probability per independent guess.
• CVSS represents a high-impact abstract case. The CISA-ADP vector assumes network reachability, no privileges, no user interaction, and high confidentiality and integrity impact.
• Use reachability to prioritize. An external S/MIME gateway may deserve emergency handling even though the vendor label is Moderate. A TLS-only host may be lower priority even when a scanner imports the 9.1 score. (NVD)

Does enabling the OpenSSL FIPS provider remove the risk?

• No, not by itself.
• OpenSSL says the FIPS modules are not affected because CMS processing occurs outside the module boundary.
• The surrounding OpenSSL CMS implementation still matters. An application can use a FIPS provider for cryptographic operations while calling vulnerable non-module CMS code.
• Verify the complete runtime. Check the OpenSSL build, shared libraries, application wrapper, and CMS input path.
• Keep FIPS evidence separate from CVE evidence. Compliance mode and parser patch status answer different questions. (seclists.org)

How can I tell whether an application uses CMS AuthEnvelopedData?

• Search source code にとって CMS_decrypt, d2i_CMS, SMIME_read_CMS, CMS_ContentInfo, and related wrappers.
• Search scripts にとって openssl cms そして openssl smime.
• Inspect accepted content types たとえば application/pkcs7-mime.
• Review S/MIME features, secure-message imports, encrypted document handling, PKI workflows, and partner exchanges.
• Trace background processing. Uploaded or emailed content may be decrypted by a worker rather than the front-end service.
• Inspect local approved samples と openssl cms -cmsout -print.
• Ask the product vendor for a CVE-specific advisory or VEX statement when the implementation is closed source.
• Confirm with a safe negative test in an isolated environment rather than relying only on documentation.

Can a WAF or IDS reliably block CVE-2026-34182?

• Not universally. CMS can arrive over HTTP, SMTP, queues, file transfer, or proprietary channels.
• A WAF can help when the only reachable path is a known HTTP upload endpoint and strict content policy is possible.
• A mail gateway can inspect CMS metadata before forwarding messages to the vulnerable service.
• Application-layer validation is stronger. Reject non-AEAD algorithms and invalid tag lengths before decryption.
• Behavioral monitoring is useful. Watch for repeated near-identical messages, abnormal tag lengths, and failure spikes.
• Network controls are temporary defenses. They do not replace the patched OpenSSL implementation.

What should be tested after installing the patch?

• Runtime version: Confirm the application loaded the fixed library.
• Service lifecycle: Verify all old workers, containers, and long-running processes were replaced or restarted.
• Positive compatibility: Confirm a known-good approved AuthEnvelopedData message still succeeds.
• Non-AEAD rejection: Confirm AuthEnvelopedData cannot select OFB or another unauthenticated mode.
• Short-tag rejection: Confirm a one-byte authentication tag fails before content is trusted.
• Normal integrity rejection: Confirm a modified full-length tag also fails.
• Output isolation: Confirm no plaintext remains or reaches downstream systems after failure.
• Error consistency: Compare status, body, timing, delivery, and side effects across failure types.
• Replay controls: Confirm duplicate messages do not trigger repeated high-value actions.
• Evidence retention: Save package, runtime, fixture-hash, test-result, and restart evidence.

Final assessment

CVE-2026-34182 is a failure to preserve the meaning of authenticated encryption inside OpenSSL CMS processing. A vulnerable receiver can accept a cipher that provides no authentication or accept an authentication tag so short that forgery becomes practical through repeated guesses.

The flaw should not be generalized into a claim that every OpenSSL-powered TLS service is compromised. Exposure depends on whether untrusted AuthEnvelopedData reaches the affected code and whether the surrounding application reveals a useful result. That narrower scope is a reason to investigate intelligently, not a reason to postpone remediation.

Patch the affected OpenSSL branches, verify the library used by the running process, and find the real CMS ingestion paths. Then enforce AEAD-only algorithms, algorithm-specific parameter rules, uniform external failures, replay controls, and a hard transaction boundary that prevents plaintext from being released before integrity verification succeeds.

The most important closure evidence is not a package-version screenshot. It is proof that the application now rejects the malformed security states that CVE-2026-34182 previously allowed.