CVE-2026-35199
Heap Buffer Overflow in SymCrypt XMSS^MT Signature Function
Publication date: 2026-04-06
Last updated on: 2026-04-16
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| microsoft | symcrypt | From 103.5.0 (inc) to 103.11.0 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-122 | A heap overflow condition is a buffer overflow, where the buffer that can be overwritten is allocated in the heap portion of memory, generally meaning that the buffer was allocated using a routine such as malloc(). |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
CVE-2026-35199 is a heap-based buffer overflow vulnerability in the SymCrypt library's SymCryptXmssSign function. The issue occurs because the function passes a 64-bit leaf count value to a helper function that only accepts a 32-bit parameter. For certain XMSS^MT parameter sets with a total tree height of 32 or greater, this causes the leaf count to be silently truncated to zero.
This truncation results in the allocation of a much smaller scratch buffer than needed, which leads to a heap buffer overflow when the function writes beyond the allocated buffer during signature computation.
Exploitation requires an application using SymCrypt to perform an XMSS^MT signature with an attacker-controlled parameter set, which is uncommon since signing is a private key operation and private keys must be trusted. Additionally, XMSS(^MT) signing is intended only for testing and should be performed within a Hardware Security Module (HSM) to ensure security.
How can this vulnerability impact me? :
This vulnerability can lead to a heap buffer overflow during signature computation, which may cause a crash or allow an attacker to execute arbitrary code with the privileges of the affected application.
However, exploitation is difficult because it requires the application to perform XMSS^MT signing with attacker-controlled parameters, which is uncommon due to the trusted nature of private keys and the intended use of XMSS(^MT) signing only within secure Hardware Security Modules.
The CVSS v3.1 base score of 6.1 reflects a moderate severity with local attack vector, low attack complexity, low privileges required, no user interaction, no confidentiality impact, low integrity impact, and high availability impact.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability occurs in the SymCrypt library's SymCryptXmssSign function when using XMSS^MT parameter sets with a total tree height of 32 or greater. Detection involves verifying the version of the SymCrypt library in use and checking if it is between versions 103.5.0 and before 103.11.0, where the vulnerability exists.
Since exploitation requires an application to perform XMSS^MT signing with attacker-controlled parameters, which is uncommon, detection should focus on identifying such usage patterns in your environment.
There are no specific commands provided in the available resources to detect this vulnerability directly on a network or system.
What immediate steps should I take to mitigate this vulnerability?
The primary mitigation step is to upgrade the SymCrypt library to version 103.11.0 or later, where this vulnerability has been fixed.
Additionally, ensure that XMSS(^MT) signing is only performed within a Hardware Security Module (HSM), as intended, to maintain cryptographic security and avoid misuse of attacker-controlled parameter sets.
Avoid allowing applications to perform XMSS^MT signing with attacker-controlled parameters, since signing is a private key operation and private keys must be trusted.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
The vulnerability affects the SymCrypt library's XMSS(^MT) signing functionality, which is not FIPS approved when performed outside of a Hardware Security Module (HSM). Since XMSS(^MT) signing should only be performed in an HSM to ensure cryptographic security, using it in software alone (as affected by this vulnerability) does not meet FIPS standards.
Because FIPS compliance is often a requirement for standards and regulations like HIPAA, this vulnerability could impact compliance if the affected signing is used outside of an HSM. However, the vulnerability itself requires an uncommon scenario where an attacker controls signing parameters, and signing is a private key operation that must be trusted by definition.
There is no direct mention of GDPR or other data protection regulations in relation to this vulnerability, nor explicit statements about data confidentiality impact, which is rated as none in the CVSS metrics.