GHSA-mpwr-8vm7-h73f: Anthropic Python PBMAC1 flaw

Q: Is GHSA-mpwr-8vm7-h73f actively exploited?

No confirmed active exploitation of GHSA-mpwr-8vm7-h73f has been reported, but organizations should still patch proactively.

Q: How to fix GHSA-mpwr-8vm7-h73f?

Upgrade go-pkcs12 to version 0.7.2 or later, where the PBMAC1 key-length check is enforced correctly. Audit any Go services (including AI/ML infrastructure) for use of `Decode`, `DecodeChain`, `DecodeTrustStore`, or `ToPEM` from go-pkcs12, and confirm whether they treat successful decoding as an authentication signal for untrusted-sourced files — if so, treat pre-patch versions as a trust-boundary bypass, not just a library bug. As a compensating control, avoid decoding PKCS#12 files from untrusted or unauthenticated sources until patched. Detection: run `go list -m all` or SCA tooling across Go services to identify go-pkcs12 versions < 0.7.2.

Q: What systems are affected by GHSA-mpwr-8vm7-h73f?

This vulnerability affects the following AI/ML architecture patterns: model serving, agent frameworks.

Q: What is the CVSS score for GHSA-mpwr-8vm7-h73f?

No CVSS score has been assigned yet.

CISO Take

go-pkcs12, a Go library with 6,417 downstream dependents, incorrectly accepts PKCS#12 files encoded with the wrong password because it fails to reject excessively short PBMAC1 keys — the same class of flaw independently found in OpenSSL as CVE-2026-34181. This matters wherever password verification on a PKCS#12 bundle is treated as an authentication or integrity check: an attacker who can supply or tamper with a PKCS#12 file (certificate/key store, mTLS bundle, service credential) could get it accepted even without knowing the real password, undermining trust boundaries built around that check. There is no CISA KEV listing, no public exploit, and no EPSS data, and exploitation requires the victim to decode a PKCS#12 file from an untrusted source rather than any network-facing trigger, so this is not an actively-exploited or high-urgency issue. CISOs running Go services — including any AI/ML infrastructure written in Go that uses go-pkcs12 for mTLS or credential bundling — should upgrade to 0.7.2 and audit whether any workflow relies on `Decode`/`DecodeChain`/`DecodeTrustStore`/`ToPEM` password checks as an authentication control for untrusted input; services that only decode PKCS#12 files from trusted sources are unaffected.

Sources: NVD GitHub Advisory OpenSSF

What is the risk?

Medium severity, low urgency. No CVSS vector, no EPSS score, not in CISA KEV, no public exploit or Nuclei template exists. Exploitability requires the attacker to control or tamper with a PKCS#12 file that the victim application decodes and to have the victim rely on the (bypassable) password check as an authentication gate — a fairly narrow precondition. Impact when triggered is an authentication/integrity bypass on certificate or credential material, which can be consequential in mTLS or service-identity contexts even though direct code execution is not implied.

How does the attack unfold?

Craft malicious PKCS#12 file

Attacker builds a PKCS#12 bundle with an incorrect password but a short/weak PBMAC1 key that the vulnerable decoder mishandles.

Submit to vulnerable decoder

The crafted file is passed to a Go service using go-pkcs12's Decode/DecodeChain/DecodeTrustStore/ToPEM functions, e.g. an mTLS-authenticated endpoint in front of an AI service.

Authentication/integrity bypass

The service incorrectly accepts the file as valid despite the wrong password, bypassing the intended credential check.

Downstream trust abuse

Attacker leverages the falsely-trusted certificate/credential material to access or impersonate within the service, potentially reaching AI infrastructure gated by that mTLS/credential layer.

AML.T0012

Craft malicious PKCS#12 file

Attacker builds a PKCS#12 bundle with an incorrect password but a short/weak PBMAC1 key that the vulnerable decoder mishandles.

Submit to vulnerable decoder

The crafted file is passed to a Go service using go-pkcs12's Decode/DecodeChain/DecodeTrustStore/ToPEM functions, e.g. an mTLS-authenticated endpoint in front of an AI service.

Authentication/integrity bypass

The service incorrectly accepts the file as valid despite the wrong password, bypassing the intended credential check.

Downstream trust abuse

Attacker leverages the falsely-trusted certificate/credential material to access or impersonate within the service, potentially reaching AI infrastructure gated by that mTLS/credential layer.

AML.T0012

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
Anthropic Python	go	>= 0.6.0, < 0.7.2	`0.7.2`
3.9K 6.1K dependents Pushed 9d ago 90% patched ~14d to patch Full package profile →

Do you use Anthropic Python? You're affected.

How severe is it?

CVSS 3.1

N/A

EPSS

N/A

Exploitation Status

No known exploitation

Sophistication

Moderate

What should I do?

1 step

Upgrade go-pkcs12 to version 0.7.2 or later, where the PBMAC1 key-length check is enforced correctly. Audit any Go services (including AI/ML infrastructure) for use of Decode, DecodeChain, DecodeTrustStore, or ToPEM from go-pkcs12, and confirm whether they treat successful decoding as an authentication signal for untrusted-sourced files — if so, treat pre-patch versions as a trust-boundary bypass, not just a library bug. As a compensating control, avoid decoding PKCS#12 files from untrusted or unauthenticated sources until patched. Detection: run go list -m all or SCA tooling across Go services to identify go-pkcs12 versions < 0.7.2.

How is it classified?

Auth Bypass Inference

Which compliance frameworks are affected?

This CVE is relevant to:

NIST AI RMF

GOVERN-3.2 - Third-party risk management

OWASP LLM Top 10

LLM03 - Supply Chain Vulnerabilities

Frequently Asked Questions

What is GHSA-mpwr-8vm7-h73f?

go-pkcs12, a Go library with 6,417 downstream dependents, incorrectly accepts PKCS#12 files encoded with the wrong password because it fails to reject excessively short PBMAC1 keys — the same class of flaw independently found in OpenSSL as CVE-2026-34181. This matters wherever password verification on a PKCS#12 bundle is treated as an authentication or integrity check: an attacker who can supply or tamper with a PKCS#12 file (certificate/key store, mTLS bundle, service credential) could get it accepted even without knowing the real password, undermining trust boundaries built around that check. There is no CISA KEV listing, no public exploit, and no EPSS data, and exploitation requires the victim to decode a PKCS#12 file from an untrusted source rather than any network-facing trigger, so this is not an actively-exploited or high-urgency issue. CISOs running Go services — including any AI/ML infrastructure written in Go that uses go-pkcs12 for mTLS or credential bundling — should upgrade to 0.7.2 and audit whether any workflow relies on `Decode`/`DecodeChain`/`DecodeTrustStore`/`ToPEM` password checks as an authentication control for untrusted input; services that only decode PKCS#12 files from trusted sources are unaffected.

Is GHSA-mpwr-8vm7-h73f actively exploited?

No confirmed active exploitation of GHSA-mpwr-8vm7-h73f has been reported, but organizations should still patch proactively.

How to fix GHSA-mpwr-8vm7-h73f?

Upgrade go-pkcs12 to version 0.7.2 or later, where the PBMAC1 key-length check is enforced correctly. Audit any Go services (including AI/ML infrastructure) for use of `Decode`, `DecodeChain`, `DecodeTrustStore`, or `ToPEM` from go-pkcs12, and confirm whether they treat successful decoding as an authentication signal for untrusted-sourced files — if so, treat pre-patch versions as a trust-boundary bypass, not just a library bug. As a compensating control, avoid decoding PKCS#12 files from untrusted or unauthenticated sources until patched. Detection: run `go list -m all` or SCA tooling across Go services to identify go-pkcs12 versions < 0.7.2.

What systems are affected by GHSA-mpwr-8vm7-h73f?

This vulnerability affects the following AI/ML architecture patterns: model serving, agent frameworks.

What is the CVSS score for GHSA-mpwr-8vm7-h73f?

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

model servingagent frameworks

Compliance Controls Affected

NIST AI RMF: GOVERN-3.2

OWASP LLM Top 10: LLM03

What are the technical details?

Original Advisory

`Decode`, `DecodeChain`, `DecodeTrustStore`, and `ToPEM` can incorrectly accept PKCS#12 files which were encoded with the wrong password, due to a failure to reject excessively-short PBMAC1 keys. Users who decode PKCS#12 files from untrusted sources and rely on the password for authentication can be tricked into accepting malicious PKCS#12 files. Users who only decode PKCS#12 files from trusted sources are not affected. Thanks to Pavol Žáčik (Red Hat) and Alex Gaynor (Anthropic) for finding and reporting the same issue in OpenSSL ([CVE-2026-34181](https://openssl-library.org/news/vulnerabilities/#CVE-2026-34181)).

Exploitation Scenario

An attacker crafts a malicious PKCS#12 file encoded with an incorrect or attacker-chosen password but exploits the weak/short PBMAC1 key handling so the file is nonetheless accepted as valid by a vulnerable go-pkcs12 decode call. If a target service — for example, a Go-based mTLS gateway sitting in front of an AI inference API or model-serving cluster — uses PKCS#12 password verification as an authentication gate for uploaded certificate bundles, the attacker submits the crafted file and is incorrectly authenticated or trusted, bypassing the intended password check without ever knowing the legitimate credential.

Weaknesses (CWE)

CWE-20 Improper Input Validation Primary

CWE-20 — Improper Input Validation: The product receives input or data, but it does not validate or incorrectly validates that the input has the properties that are required to process the data safely and correctly.

[Architecture and Design] Consider using language-theoretic security (LangSec) techniques that characterize inputs using a formal language and build "recognizers" for that language. This effectively requires parsing to be a distinct layer that effectively enforces a boundary between raw input and internal data representations, instead of allowing parser code to be scattered throughout the program, where it could be subject to errors or inconsistencies that create weaknesses. [REF-1109] [REF-1110] [REF-1111]
[Architecture and Design] Use an input validation framework such as Struts or the OWASP ESAPI Validation API. Note that using a framework does not automatically address all input validation problems; be mindful of weaknesses that could arise from misusing the framework itself (CWE-1173).

Source: MITRE CWE corpus.