GHSA-mpwr-8vm7-h73f: Key Space Collapse and Authentication Bypass in go-pkcs12 PBMAC1 Decoding

The PKCS#12 standard, defined in RFC 7292 and updated in RFC 9579, provides an archive format for storing cryptographic objects such as private keys and certificates. To guarantee the integrity and authenticity of these sensitive structures, PKCS#12 files typically use a Password-Based Message Authentication Code (PBMAC) to verify that the file has not been altered. The library software.sslmate.com/src/go-pkcs12 implements these decoding features for Go applications, specifically via the Decode, DecodeChain, DecodeTrustStore, and ToPEM functions.

A critical vulnerability, tracked as GHSA-mpwr-8vm7-h73f and GO-2026-5052, exists in the library's handling of the Password-Based Message Authentication Code 1 (PBMAC1) integrity mechanism. The bug class is classified as CWE-354 (Improper Validation of Integrity Check Value). The flaw arises because the decoding functions fail to validate the KeyLength parameter specified within the PBKDF2 parameters of the PKCS#12 structure.

This vulnerability is mathematically and conceptually equivalent to the OpenSSL flaw CVE-2026-34181. When an application parses an untrusted PKCS#12 file containing a manipulated KeyLength parameter, it is possible for an attacker to achieve a successful integrity bypass. This allows the injecting of unauthorized certificates or keys without knowledge of the correct decryption password.

The root cause of GHSA-mpwr-8vm7-h73f lies in the trust placed in attacker-controlled metadata within the PKCS#12 container. When PBMAC1 is used for integrity protection, the standard specifies that a key must be derived from a user password using a Key Derivation Function, typically PBKDF2. The parameters for this derivation process, including the salt, iteration count, and target key length, are encoded in the ASN.1 structure of the PKCS#12 file itself.

In vulnerable versions of the go-pkcs12 library, the parser retrieves the KeyLength parameter from the PBKDF2 configuration block and passes it directly to the PBKDF2 key derivation algorithm without verifying its size or ensuring it meets a safe minimum threshold. An attacker can set this parameter to an extremely small value, such as 1 byte (8 bits), instead of the standard length of 20 bytes or more.

Setting KeyLength to 1 byte collapses the entropy of the derived key space from 2^160 or more possible values to just 256 possible keys (0x00 through 0xFF). When the target application processes the file, it executes the PBKDF2 function using the true user-supplied password, but the output is truncated to a single byte. Consequently, the Message Authentication Code (MAC) is computed using a 1-byte key, allowing a brute-force or probabilistic bypass because the attacker only needs to guess one of the 256 possible key values to forge a matching MAC.

The vulnerability exists within the PBMAC1 processing logic in mac.go. The library parses the PBKDF2 parameters and extracts the key length parameter to derive the HMAC key. Below is a comparison of the vulnerable and patched code paths.

// Vulnerable Code Path in mac.go
func doPBMAC1(algorithm pkix.AlgorithmIdentifier, message, password []byte) ([]byte, error) {
    // ...
    if kdfParams.KeyLength <= 0 {
        return nil, errors.New("pkcs12: PBMAC1 requires explicit KeyLength parameter in PBKDF2 parameters")
    }
    // The kdfParams.KeyLength is used directly without verifying if it is too small
    keyLen := kdfParams.KeyLength
 
    // Derive key using PBKDF2
    key := pbkdf2.Key(password, salt, iterations, keyLen, hashFunc)
    // ...
}

To remediate this issue, a check was introduced in commit 03c441f6b0267f695ca02464133c0b373bf4dd55 to reject keys shorter than 20 bytes, as recommended by RFC 9579. This prevents the key truncation attack.

// Patched Code Path in mac.go
func doPBMAC1(algorithm pkix.AlgorithmIdentifier, message, password []byte) ([]byte, error) {
    // ...
    if kdfParams.KeyLength <= 0 {
        return nil, errors.New("pkcs12: PBMAC1 requires explicit KeyLength parameter in PBKDF2 parameters")
    }
    // RFC 9579 RECOMMENDS rejecting key lengths less than 20; this is necessary to prevent possible authentication bypass
    if kdfParams.KeyLength < 20 {
        return nil, errors.New("pkcs12: PBMAC1 key length is too short")
    }
    keyLen := kdfParams.KeyLength
 
    // Derive key using PBKDF2
    key := pbkdf2.Key(password, salt, iterations, keyLen, hashFunc)
    // ...
}

By enforcing KeyLength >= 20, the library guarantees that the key used for the subsequent HMAC operation retains a high level of cryptographic strength. This successfully mitigates the key space collapse vector.

Exploitation of this vulnerability requires the attacker to construct a custom, unencrypted PKCS#12 payload containing forged credentials (such as an unauthorized Root CA or a specific private key). The attacker then serializes this payload alongside a manipulated PBMAC1 metadata block. Within the PBKDF2 parameter block, the attacker specifies a KeyLength of 1 byte.

Because the attacker does not know the actual password used by the target application, they must select an arbitrary 1-byte key guess, denoted as K_guess. The attacker then computes the HMAC of the forged payload using this 1-byte key and sets the resulting digest as the MAC value within the PKCS#12 file. When the target application decodes the file, it will derive its own 1-byte key K_actual using the correct password.

There is a 1-in-256 (approximately 0.39%) probability that K_actual matches K_guess because both are bounded to the exact same 1-byte range. If the values match, the computed HMAC matches the stored HMAC, and the library accepts the forged container as authentic. An attacker can repeatedly present files or exploit systems processing multiple automated inputs to bypass the validation.

The impact of a successful exploitation of GHSA-mpwr-8vm7-h73f is severe. By bypassing the password integrity check, an attacker can coerce an application into accepting arbitrary certificates and private keys. This can lead to a complete breakdown of trust controls within systems that rely on PKCS#12 files for authentication, identity propagation, or secure communication.

In scenarios where the application imports root certificates from PKCS#12 files to build trust stores, an attacker can install a malicious Root CA (MITRE ATT&CK T1553.004). This enables the interception and decryption of TLS traffic or the forging of software signatures. Alternatively, if the file is used to store client certificates, the attacker can impersonate authorized users or services, leading to unauthorized access.

The CVSS v3.1 score for the underlying cryptographic flaw (CVE-2026-34181) is 7.4 (High), reflecting high integrity and confidentiality impacts. Although the exploitation is probabilistic, the lack of operational complexity and the absence of required privileges make it a highly viable attack vector against automated data ingestion pipelines.

The primary remediation path is to upgrade the software.sslmate.com/src/go-pkcs12 library to version v0.7.2 or later. This version introduces the strict 20-byte minimum key length validation check on PBMAC1 parameters, neutralizing the key space collapse vulnerability. Developers can update their projects by running go get -u software.sslmate.com/src/go-pkcs12@v0.7.2 followed by go mod tidy.

If immediate upgrading is not feasible, organizations should implement input validation controls at the network perimeter or application boundary. PKCS#12 files from untrusted sources should be blocked or subjected to pre-parsing validation where the ASN.1 structure is inspected. Any container specifying a PBKDF2 key length of less than 20 bytes should be rejected immediately prior to decryption attempts.

Additionally, applications processing PKCS#12 archives should enforce strict rate-limiting and robust security auditing. Since a successful bypass has a low mathematical probability per attempt, an attacker must typically submit multiple files to achieve a successful verification. Monitoring and alerting on repeated PKCS#12 decryption or integrity failures can detect and mitigate active exploitation attempts in real time.