CVE-2026-34181

What it actually does

This is a cryptographic input-validation flaw in OpenSSL PKCS#12 processing. When a PKCS#12 file uses the PBMAC1 integrity mechanism, OpenSSL may accept attacker-controlled certificate and private-key material if the file specifies an extremely weak HMAC key, such as a one-byte key. In services that treat possession of the correct PKCS#12 password as proof that the file is authentic, an unauthenticated network attacker can submit forged, unencrypted PKCS#12 files and has an approximately 1-in-256 chance per attempt of getting a forged certificate/private key accepted. The OpenSSL FIPS modules are not affected because the vulnerable code is outside the FIPS module boundary.

Why it matters to the business

Systems that import or process user-supplied PKCS#12 files could be tricked into trusting an attacker-controlled identity, certificate, or private key. This can lead to account impersonation, unauthorized access, fraudulent signing or authentication, and compromise of workflows that depend on certificate-based identity. Exploitation is probabilistic and higher complexity, EPSS is currently low and stable, and the issue is not listed in CISA KEV or associated with known ransomware use, but organizations with certificate enrollment, device onboarding, client-certificate authentication, or PKCS#12 upload features should treat affected exposed services as higher priority.

How an attack unfolds

An attacker identifies a service that accepts PKCS#12/PFX files from remote users and relies on the PKCS#12 password or MAC validation to authenticate the submitted certificate bundle. The attacker constructs an unencrypted PKCS#12 file using PBMAC1 for integrity and deliberately weak MAC parameters, including a one-byte HMAC key. The file contains a certificate and private key controlled by the attacker but crafted to appear acceptable to the target workflow. Because acceptance is probabilistic, the attacker may submit multiple variants or repeated attempts until OpenSSL accepts one. If accepted, the service imports or trusts the attacker-controlled certificate/private key, allowing the attacker to impersonate a user, enroll a fraudulent identity, or access resources protected by certificate-based authentication.

How to fix it

Upgrade OpenSSL to a vendor-fixed version as soon as one is available for the affected distribution, appliance, application runtime, container image, or embedded product. No exact fixed version was provided in the input, so track the relevant OpenSSL and operating-system vendor advisories and apply the first patched package released for this issue. Where immediate patching is not possible, reduce exposure by rejecting user-supplied PKCS#12 files that use PBMAC1, rejecting unencrypted PKCS#12 files, enforcing strict MAC parameter validation, requiring strong MAC key derivation parameters, rate-limiting PKCS#12 import attempts, and avoiding workflows where a PKCS#12 password alone proves identity or authorization. Independently validate certificate identity, issuer, chain, key usage, extended key usage, ownership, and enrollment authorization before trusting imported certificates. FIPS module use alone should not be assumed to protect the surrounding application unless the vulnerable non-FIPS PKCS#12 parsing path is not used.

How to confirm the fix worked

Inventory applications, services, containers, appliances, and libraries that link to or package OpenSSL and perform PKCS#12/PFX parsing. Confirm whether they accept externally supplied .p12 or .pfx files and whether PBMAC1 is allowed. Validate remediation by checking the OpenSSL package/library version against the vendor advisory for this issue and by running application-level negative tests with PKCS#12 files using PBMAC1, unencrypted storage, and weak MAC parameters; patched or mitigated systems should reject them consistently. Confirm that certificate import workflows validate identity and authorization independently of PKCS#12 MAC success. Review service configuration, CI images, base containers, and statically linked binaries because OpenSSL may be bundled outside the operating-system package manager.

Typical attack path

1. Find an internet-facing or otherwise reachable application, API, gateway, enrollment portal, or service that accepts PKCS#12/PFX uploads or imports.
2. Confirm or infer that the backend uses affected OpenSSL PKCS#12 parsing and treats PKCS#12 password/MAC validation as an authenticity check.
3. Prepare an unencrypted PKCS#12 file using PBMAC1 integrity with deliberately weak MAC parameters, including a one-byte HMAC key.
4. Embed attacker-controlled certificate and private-key material in the PKCS#12 file.
5. Submit the crafted file repeatedly or through automated workflow attempts because successful acceptance occurs with approximately 1-in-256 probability.
6. If the file is accepted, use the imported certificate/private key to impersonate the intended identity, complete enrollment, authenticate, sign data, or gain access to protected services.

How to detect it

Look for evidence around PKCS#12/PFX import, enrollment, certificate upload, and client-certificate provisioning workflows. Relevant sources include application upload logs, API gateway logs, authentication logs, certificate enrollment/audit logs, certificate authority logs, web server access logs, WAF logs, EDR file-create telemetry, object-storage access logs, and container/application stdout logs. Hunt for repeated uploads of .p12 or .pfx files from the same source, many failed imports followed by one success, PBMAC1 usage, unencrypted PKCS#12 files, unusually weak MAC or HMAC parameters, and imported certificates whose subject, SAN, issuer, fingerprint, key usage, or private-key association does not match the expected account or enrollment policy. Because there are no known public exploit campaigns or KEV listing in the supplied data, prioritize anomaly-based detection over threat-actor-specific indicators. If suspicious files are available, inspect them offline with safe tooling to identify PBMAC1 and MAC parameters, and compare accepted certificates against authorized certificate inventories and revocation records.

• PBMAC1
• 1.2.840.113549.1.5.14
• .p12
• .pfx
• PKCS#12
• PFX
• MacData
• HMAC key length: 1
• key length 1
• unencrypted PKCS#12
• MAC: PBMAC1
• PKCS12_parse

What your security team should do

• Prioritize systems that accept PKCS#12/PFX uploads from untrusted users, partners, devices, or public networks, especially certificate enrollment and client-certificate authentication workflows.
• Patch OpenSSL through the operating-system, application, appliance, container, and language-runtime supply chain as soon as vendor-fixed builds are available.
• Temporarily block or quarantine PKCS#12 files using PBMAC1, unencrypted PKCS#12 files, and files with weak or unusual MAC parameters.
• Add rate limits, duplicate-submission detection, and alerting around PKCS#12 import endpoints because exploitation may require repeated attempts.
• Require independent authorization checks before accepting a submitted certificate/private key, including issuer, chain, subject/SAN ownership, key usage, and enrollment policy validation.
• Search historical logs for repeated failed or borderline PKCS#12 import attempts, unusual PBMAC1 usage, and certificate imports followed by unexpected authentication success.
• Reissue, revoke, or disable certificates imported through suspicious PKCS#12 workflows until their provenance is verified.
• Monitor OpenSSL and downstream vendor advisories for exact fixed package versions because no fixed version was provided in the supplied metadata.