Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐘
🐘 Packagist
Not in CISA KEV
HIGH severity

GHSA-4v26-v6cg-g6f9 robrichards/xmlseclibs

HIGHFix: robrichards/xmlseclibs@03062be

GHSA-4v26-v6cg-g6f9 is a high-severity (CVSS 8.2) CWE-354 vulnerability in robrichards/xmlseclibs. A fix is available for robrichards/xmlseclibs — see the affected versions and patch details below.

xmlseclibs: Missing AES-GCM Authentication Tag Validation on Encrypted Nodes Allows for Unauthorized Decryption

Also known asCVE-2026-32313
Published
Mar 13, 2026
Updated
Sep 10, 2026
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Sep 21, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

Proof-of-concept exploit code exists

  • CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
  • CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.

Exploitation and automatability from CISA’s SSVC triage for GHSA-4v26-v6cg-g6f9.

EPSS Exploitation Probability

via FIRST.org ↗
0.2%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs5th percentile — riskier than 5% of all scored CVEsHighest risk

EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.

How urgent is this, really

GHSA-4v26-v6cg-g6f9 plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.

Where this sits among everything scored

Of 377,636 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.

Real-World Exposure

1 pkg affected
🐘robrichards/xmlseclibs

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Packagist packages — download data is not available via public APIs for these ecosystems.

Description

Summary

XML nodes encrypted with either aes-128-gcm, aes-192-gcm, or aes-256-gcm lack validation of the authentication tag length. An attacker can use this to brute-force an authentication tag, recover the GHASH key, and decrypt the encrypted nodes. It also allows to forge arbitrary ciphertexts without knowing the encryption key.

Details

When decrypting with either aes-128-gcm, aes-192-gcm, or aes-256-gcm here, the $authTag is set from a substr(), but never has its length validated (it should be validated with something like strlen($authTag) == self::AUTHTAG_LENGTH). For that reason, a shorter than expected data blob will allow for the $authTag to have as short a tag as only one byte (see PHP's documentation).

See this example:

function test($data) {
    $ivSize = 12;
    $tagSize = 16;

    $iv = substr($data, 0, $ivSize);
    $data = substr($data, $ivSize);
    $offset = 0 - $tagSize;
    $tag = substr($data, $offset);
    $ct = substr($data, 0, $offset);

    echo 'IV: "' . $iv . '"' . PHP_EOL;
    echo 'Tag: "' . $tag . '"' . PHP_EOL;
    echo 'CT: "' . $ct . '"' . PHP_EOL;
}

/* Outputs:
php > test('myNonceNoncet');
IV: "myNonceNonce"
Tag: "t"
CT: ""
php > test('myNonceNonceta');
IV: "myNonceNonce"
Tag: "ta"
CT: ""
php > test('myNonceNoncetag');
IV: "myNonceNonce"
Tag: "tag"
CT: ""
*/

With a legit ciphertext in hand, this is enough to recover the GHASH key. With that key, any authenticated tags can be computed offline which allows for decryption of the ciphertext and forgery of arbitrary ciphertexts.

PoC

  1. Setup a server expecting XML with an encrypted assertion
  2. Create an XML document with an encrypted assertion (encrypted with aes-256-gcm)

Note: The steps from 3 to 6 are implemented in this exploit script: nonce_reuse_with_fmt_val_oracle.py. You can run the script with sage -python nonce_reuse_with_fmt_val_oracle.py -s 'url-encoded_and_base64-encoded_samlresponse'

  1. Take the content of the <xenc:CipherValue> node and apply the following modifications
    1. Base64-decode the content
    2. Take the first 12 bytes and save them as the nonce
    3. Take the last 16 bytes and save them as the tag
    4. Now brute-force the tag of an empty ciphertext
      1. Loop through all 256 possible byte values (let's call that byte_tag_attempt)
      2. Concatenate together the nonce and the byte_tag_attempt
      3. Base64-encode the result
      4. Replace the content of the <xenc:CipherValue> node with this result
      5. On http errors 500, we learn that the tag is valid
      6. Do the same for the next byte of the tag until all 16 bytes have been brute-forced
  2. With this new tag and the empty ciphertext, compute the GHASH key (the way to do this has been described in this blog post)
  3. Use this GHASH key to compute authentication tags offline for arbitrary ciphertexts
  4. Decryption is done by observing XML parsing errors that occur after modifying the ciphertext, those can be seen as http errors 500

poc.webm

Impact

The general impact is:

  • XML nodes encrypted with AES-GCM can be decrypted by observing parsing differences
  • XML nodes encrypted with AES-GCM can be modified to decrypt to an arbitrary value
  • The GCM internal GHASH key can be recovered

In cases where the encryption key is embedded in the XML and is encrypted with the Service Provider's public key (like often done with SAML), the last two items don't have a big impact. This is because:

  • With the Service Provider's public key, an arbitrary ciphertext can be created with a known symmetric key
  • The symmetric keys are generated on the fly every time the IdP creates a new SAMLResponse

In any case, secrets that are embedded in the XML, whether coming from an IdP, or from another scheme, can be decrypted.

Important: If static symmetric keys are used, as the GHASH key could have leaked, you must rotate those keys.

References

For additional information on the issue, you can refer to this blog post about the OpenSSL issue and how it can be exploited.

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🐘Packagistrobrichards/xmlseclibsall versions3.1.5composer require robrichards/xmlseclibs:^3.1.5

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for robrichards/xmlseclibs, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update robrichards/xmlseclibs to 3.1.5 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-4v26-v6cg-g6f9 is resolved across your whole dependency graph.

  3. Workarounds

    If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

  4. How O3 protects you

    O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like GHSA-4v26-v6cg-g6f9 can be triaged on real exposure rather than presence alone.

Tailored to GHSA-4v26-v6cg-g6f9. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

### Summary XML nodes encrypted with either aes-128-gcm, aes-192-gcm, or aes-256-gcm lack validation of the authentication tag length. An attacker can use this to brute-force an authentication tag, recover the [GHASH key](https://en.wikipedia.org/wiki/Galois/Counter_Mode#:~:text=%29%20is%20the-,hash%20key,-%2C%20a%20string%20of), and decrypt the encrypted nodes. It also allows to forge arbitrary ciphertexts without knowing the encryption key. ### Details When decrypting with either aes-128-gcm, aes-192-gcm, or aes-256-gcm [here](https://github.com/robrichards/xmlseclibs/blob/2bdfd742624d739df
O3 Security · Impact-Aware SCA

Is GHSA-4v26-v6cg-g6f9 in your dependencies?

O3 Security finds GHSA-4v26-v6cg-g6f9 across Packagist dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.

GHSA-4v26-v6cg-g6f9: robrichards/xmlseclibs | O3 Security