CWE-347
AllowedImproper Verification of Cryptographic Signature
Abstraction: Base · Status: Draft
The product does not verify, or incorrectly verifies, the cryptographic signature for data.
1128 vulnerabilities reference this CWE, most recent first.
GHSA-9MV3-2CWR-P262
Vulnerability from github – Published: 2026-04-23 14:55 – Updated: 2026-04-24 19:59Executive Summary:
A bug in Microsoft.AspNetCore.DataProtection 10.0.0-10.0.6 NuGet packages can give an attacker the opportunity to execute an Elevation of Privilege attack by forging authentication cookies, and also allows some protected payloads to be decrypted.
If an attacker used forged payloads to authenticate as a privileged user during the vulnerable window, they may have induced the application to issue legitimately-signed tokens (session refresh, API key, password reset link, etc.) to themselves. Those tokens remain valid after upgrading to 10.0.7 unless the DataProtection key ring is rotated.
This is comparable in capability to MS10-070, which exploited a similar padding-oracle condition in ASP.NET's legacy encryption infrastructure.
Announcement
Announcement for this issue can be found at https://github.com/dotnet/announcements/issues/395
CVSS Details
- Version: 3.1
- Severity: Important
- Score: 9.1
- Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
- Weakness: CWE-347: Improper Verification of Cryptographic Signature
Affected Platforms
- Platforms: All
- Architectures: All
Affected Packages
The vulnerability affects some Microsoft .NET projects if they use any of affected package versions listed below
ASP.NET Core 10
| Package name | Affected version | Patched version |
|---|---|---|
| Microsoft.AspNetCore.DataProtection | >=10.0.0, <=10.0.6 | 10.0.7 |
Advisory FAQ
How do I know if I am affected?
Primary affected configuration (10.0.6 on net10.0)
You are affected if ALL of the following are true:
- Your application referenced
Microsoft.AspNetCore.DataProtectionversion 10.0.6 from NuGet (directly or transitively via, e.g.,Microsoft.AspNetCore.DataProtection.StackExchangeRedis,.EntityFrameworkCore,.AzureKeyVault,.AzureStorage,.Redis), AND The affected 10.0.6 NuGet binary was actually loaded at runtime. This happens when either the application does NOT target the Microsoft.NET.Sdk.Web NOR has a Microsoft.AspNetCore.App framework reference either directly or transitively UNLESS you opt out of PrunePackageReference which is enabled by default in .NET 10. - The application ran on Linux, macOS, or any non-Windows operating system.
Secondary affected configuration (10.0.x on net462 / netstandard2.0)
You are also affected if:
- Your application or library referenced
Microsoft.AspNetCore.DataProtectionversions 10.0.0 through 10.0.6 from NuGet, AND - The build consumed the
net462ornetstandard2.0target framework asset of that package. This occurs when your application does not targetnet10.0and consumes the package (e.g.net8.0,net9.0,net481for mono, etc.). This combination is unusual because 10.0 NuGet packages are generally intended for use with .NET 10.
This secondary population is much smaller and is expected to primarily consist of:
- Desktop or server applications on .NET Framework that happen to use the ASP.NET Core DataProtection NuGet package.
- Libraries that target netstandard2.0 and reference the 10.0 DataProtection package.
These configurations use the same managed authenticated encryptor code path on all operating systems (the CNG path is only available on the net10.0 asset), so the Windows exception below does not apply to them.
Not affected
- Your application runs on Windows
- Your application runs framework-dependent on
net10.0and your installed ASP.NET Core shared framework version is ≥ your PackageReference version ofMicrosoft.AspNetCore.DataProtection. In this case the (correct) shared framework copy is loaded and the NuGet copy is not used. For example, shared framework 10.0.6 + PackageReference 10.0.6 is safe; shared framework 10.0.5 + PackageReference 10.0.6 is not. - Your application uses
Microsoft.AspNetCore.DataProtection8.0.x or 9.0.x from NuGet, on any target framework, any operating system, any shared framework version. The defective code path was introduced during 10.0 development and was never backported to the 8.0 or 9.0 servicing branches. - Your application never referenced any affected version of the package.
How do I fix the issue?
-
Upgrade
Microsoft.AspNetCore.DataProtectionto 10.0.7 or later and redeploy. This fixes the validation routine. Any forged payloads produced during the vulnerable window (which necessarily carried all-zero HMAC bytes) will be rejected by the corrected code. -
Rotate the DataProtection key ring if your application was affected and served internet-exposed endpoints during the vulnerable window. This invalidates any legitimately-signed tokens the application may have issued to attackers during that period.
Example using the built-in key manager:
```csharp // Run once, from an application with access to the same key ring. // Replace the cutoff with a timestamp just before you deployed 10.0.6. var services = new ServiceCollection() .AddDataProtection() // ... your existing repository / protection configuration ... .Services .BuildServiceProvider();
var keyManager = services.GetRequiredService(); keyManager.RevokeAllKeys( revocationDate: DateTimeOffset.UtcNow, // revoke all keys currently in the ring reason: "CVE-TBD: DataProtection 10.0.6 validation bypass"); ```
RevokeAllKeys marks every existing key as revoked; a new key is auto-generated on the next protect operation. All users will need to sign in again, all antiforgery tokens will be reissued, etc.
If you can be more surgical — for instance, you know no key older than T was used by an affected process — use RevokeKey(Guid keyId, string reason) instead to revoke only the keys that were active during the vulnerable window.
- Audit application-level long-lived artifacts that were created during the vulnerable window and carry identity or capability. These survive key rotation and must be rotated at the application layer:
- API keys, refresh tokens, or access tokens stored in your database and issued via a protected endpoint.
- Password reset links or email-confirmation tokens that were emitted during the window and have not yet expired.
- Any other persistent capability that an authenticated request could have caused your application to issue.
If your application does not issue such long-lived artifacts via authenticated endpoints, key rotation alone is sufficient.
Recommended
-
Audit plaintext stored inside protected payloads. If your application stores long-lived secrets (database connection strings, third-party API keys, etc.) inside
IDataProtector.Protectoutput, treat those secrets as potentially disclosed and rotate them at their respective sources. -
Review web server logs for anomalous request volume against endpoints that accept protected payloads (auth cookies, antiforgery tokens, state parameters). The padding-oracle attack requires many requests per byte recovered — orders of magnitude more than normal traffic for that endpoint. Sustained high-volume traffic with varying cookie/query-parameter values against a single authenticated endpoint during the vulnerable window is a strong indicator.
Other Information
Reporting Security Issues
If you have found a potential security issue in a supported version of .NET, please report it to the Microsoft Security Response Center (MSRC) via the MSRC Researcher Portal. Further information can be found in the MSRC Report an Issue FAQ.
Security reports made through MSRC may qualify for the Microsoft .NET Bounty. Details of the Microsoft .NET Bounty Program including terms and conditions are at https://aka.ms/corebounty.
Support
You can ask questions about this issue on GitHub in the .NET GitHub organization. The main ASP.NET Core repo is located at https://github.com/dotnet/aspnetcore. The Announcements repo (https://github.com/dotnet/Announcements) will contain this bulletin as an issue and will include a link to a discussion issue. You can ask questions in the linked discussion issue.
Disclaimer
The information provided in this advisory is provided "as is" without warranty of any kind. Microsoft disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. In no event shall Microsoft Corporation or its suppliers be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages, even if Microsoft Corporation or its suppliers have been advised of the possibility of such damages. Some states do not allow the exclusion or limitation of liability for consequential or incidental damages so the foregoing limitation may not apply.
External Links
Revisions
V1.0 (April 21, 2026): Advisory published.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 10.0.6"
},
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.AspNetCore.DataProtection"
},
"ranges": [
{
"events": [
{
"introduced": "10.0.0"
},
{
"fixed": "10.0.7"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-40372"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-23T14:55:41Z",
"nvd_published_at": "2026-04-21T20:16:59Z",
"severity": "CRITICAL"
},
"details": "## Executive Summary: \n\nA bug in `Microsoft.AspNetCore.DataProtection` 10.0.0-10.0.6 NuGet packages can give an attacker the opportunity to execute an Elevation of Privilege attack by forging authentication cookies, and also allows some protected payloads to be decrypted.\n\nIf an attacker used forged payloads to authenticate as a privileged user during the vulnerable window, they may have induced the application to issue **legitimately-signed** tokens (session refresh, API key, password reset link, etc.) to themselves. Those tokens remain valid after upgrading to 10.0.7 unless the DataProtection key ring is rotated.\n\nThis is comparable in capability to [MS10-070](https://learn.microsoft.com/en-us/security-updates/SecurityBulletins/2010/ms10-070), which exploited a similar padding-oracle condition in ASP.NET\u0027s legacy encryption infrastructure.\n\n## Announcement\n\nAnnouncement for this issue can be found at https://github.com/dotnet/announcements/issues/395\n\n## CVSS Details\n\n- **Version:** 3.1\n- **Severity:** Important\n- **Score:** 9.1\n- **Vector:** CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N\n- **Weakness:** CWE-347: Improper Verification of Cryptographic Signature\n\n## Affected Platforms\n\n- **Platforms:** All\n- **Architectures:** All\n\n## \u003ca name=\"affected-packages\"\u003e\u003c/a\u003eAffected Packages\nThe vulnerability affects some Microsoft .NET projects if they use any of affected package versions listed below\n\n### \u003ca name=\"ASP.NET Core 10\"\u003e\u003c/a\u003eASP.NET Core 10\nPackage name | Affected version | Patched version\n------------ | ---------------- | -------------------------\n[Microsoft.AspNetCore.DataProtection](https://www.nuget.org/packages/Microsoft.AspNetCore.DataProtection) | \u003e=10.0.0, \u003c=10.0.6 | 10.0.7\n\n## Advisory FAQ\n\n### \u003ca name=\"how-affected\"\u003e\u003c/a\u003eHow do I know if I am affected?\n \n#### Primary affected configuration (10.0.6 on `net10.0`)\n \nYou are **affected** if ALL of the following are true:\n \n- Your application referenced `Microsoft.AspNetCore.DataProtection` version 10.0.6 from NuGet (directly or transitively via, e.g., `Microsoft.AspNetCore.DataProtection.StackExchangeRedis`, `.EntityFrameworkCore`, `.AzureKeyVault`, `.AzureStorage`, `.Redis`), AND\nThe affected 10.0.6 NuGet binary was actually loaded at runtime. This happens when either the application does NOT target the Microsoft.NET.Sdk.Web NOR has a Microsoft.AspNetCore.App framework reference either directly or transitively UNLESS you opt out of PrunePackageReference which is enabled by default in .NET 10. \n- The application ran on Linux, macOS, or any non-Windows operating system.\n \n#### Secondary affected configuration (10.0.x on `net462` / `netstandard2.0`)\n\nYou are also affected if:\n \n- Your application or library referenced `Microsoft.AspNetCore.DataProtection` versions 10.0.0 through 10.0.6 from NuGet, AND\n- The build consumed the `net462` or `netstandard2.0` target framework asset of that package. This occurs when your application does not target `net10.0` and consumes the package (e.g. `net8.0`, `net9.0`, `net481` for mono, etc.). This combination is unusual because 10.0 NuGet packages are generally intended for use with .NET 10.\n \nThis secondary population is much smaller and is expected to primarily consist of:\n- Desktop or server applications on .NET Framework that happen to use the ASP.NET Core DataProtection NuGet package.\n- Libraries that target `netstandard2.0` and reference the 10.0 DataProtection package.\n \nThese configurations use the same managed authenticated encryptor code path on all operating systems (the CNG path is only available on the `net10.0` asset), so the Windows exception below does not apply to them.\n \n#### Not affected\n \n- Your application runs on **Windows** \n- Your application runs **framework-dependent** on `net10.0` and your installed ASP.NET Core shared framework version is **\u2265** your PackageReference version of `Microsoft.AspNetCore.DataProtection`. In this case the (correct) shared framework copy is loaded and the NuGet copy is not used. For example, shared framework 10.0.6 + PackageReference 10.0.6 is safe; shared framework 10.0.5 + PackageReference 10.0.6 is not.\n- Your application uses `Microsoft.AspNetCore.DataProtection` **8.0.x or 9.0.x** from NuGet, on any target framework, any operating system, any shared framework version. The defective code path was introduced during 10.0 development and was never backported to the 8.0 or 9.0 servicing branches.\n- Your application never referenced any affected version of the package.\n\n### \u003ca name=\"how-fix\"\u003e\u003c/a\u003eHow do I fix the issue?\n\n1. **Upgrade `Microsoft.AspNetCore.DataProtection` to 10.0.7 or later** and redeploy. This fixes the validation routine. Any forged payloads produced during the vulnerable window (which necessarily carried all-zero HMAC bytes) will be rejected by the corrected code.\n \n2. **Rotate the DataProtection key ring** if your application was affected and served internet-exposed endpoints during the vulnerable window. This invalidates any legitimately-signed tokens the application may have issued to attackers during that period.\n \n Example using the built-in key manager:\n \n ```csharp\n // Run once, from an application with access to the same key ring.\n // Replace the cutoff with a timestamp just before you deployed 10.0.6.\n var services = new ServiceCollection()\n .AddDataProtection()\n // ... your existing repository / protection configuration ...\n .Services\n .BuildServiceProvider();\n \n var keyManager = services.GetRequiredService\u003cIKeyManager\u003e();\n keyManager.RevokeAllKeys(\n revocationDate: DateTimeOffset.UtcNow, // revoke all keys currently in the ring\n reason: \"CVE-TBD: DataProtection 10.0.6 validation bypass\");\n ```\n \n `RevokeAllKeys` marks every existing key as revoked; a new key is auto-generated on the next protect operation. All users will need to sign in again, all antiforgery tokens will be reissued, etc.\n \n If you can be more surgical \u2014 for instance, you know no key older than `T` was used by an affected process \u2014 use `RevokeKey(Guid keyId, string reason)` instead to revoke only the keys that were active during the vulnerable window.\n \n3. **Audit application-level long-lived artifacts** that were created during the vulnerable window and carry identity or capability. These survive key rotation and must be rotated at the application layer:\n - API keys, refresh tokens, or access tokens stored in your database and issued via a protected endpoint.\n - Password reset links or email-confirmation tokens that were emitted during the window and have not yet expired.\n - Any other persistent capability that an authenticated request could have caused your application to issue.\n \n If your application does not issue such long-lived artifacts via authenticated endpoints, key rotation alone is sufficient.\n \n### Recommended\n \n4. **Audit plaintext stored inside protected payloads.** If your application stores long-lived secrets (database connection strings, third-party API keys, etc.) inside `IDataProtector.Protect` output, treat those secrets as potentially disclosed and rotate them at their respective sources.\n \n5. **Review web server logs** for anomalous request volume against endpoints that accept protected payloads (auth cookies, antiforgery tokens, state parameters). The padding-oracle attack requires many requests per byte recovered \u2014 orders of magnitude more than normal traffic for that endpoint. Sustained high-volume traffic with varying cookie/query-parameter values against a single authenticated endpoint during the vulnerable window is a strong indicator.\n\n## Other Information\n\n### Reporting Security Issues\n\nIf you have found a potential security issue in a supported version of .NET, please report it to the Microsoft Security Response Center (MSRC) via the [MSRC Researcher Portal](https://msrc.microsoft.com/report/vulnerability/new). Further information can be found in the MSRC [Report an Issue FAQ](https://www.microsoft.com/msrc/faqs-report-an-issue).\n\nSecurity reports made through MSRC may qualify for the Microsoft .NET Bounty. Details of the Microsoft .NET Bounty Program including terms and conditions are at https://aka.ms/corebounty.\n\n### Support\n\nYou can ask questions about this issue on GitHub in the .NET GitHub organization. The main ASP.NET Core repo is located at https://github.com/dotnet/aspnetcore. The Announcements repo (https://github.com/dotnet/Announcements) will contain this bulletin as an issue and will include a link to a discussion issue. You can ask questions in the linked discussion issue.\n\n### Disclaimer\n\nThe information provided in this advisory is provided \"as is\" without warranty of any kind. Microsoft disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. In no event shall Microsoft Corporation or its suppliers be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages, even if Microsoft Corporation or its suppliers have been advised of the possibility of such damages. Some states do not allow the exclusion or limitation of liability for consequential or incidental damages so the foregoing limitation may not apply.\n\n### External Links\n\n[CVE-2026-40372]( https://www.cve.org/CVERecord?id=CVE-2026-40372)\n\n### Revisions\n\nV1.0 (April 21, 2026): Advisory published.",
"id": "GHSA-9mv3-2cwr-p262",
"modified": "2026-04-24T19:59:43Z",
"published": "2026-04-23T14:55:41Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/dotnet/aspnetcore/security/advisories/GHSA-9mv3-2cwr-p262"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-40372"
},
{
"type": "WEB",
"url": "https://github.com/dotnet/announcements/issues/395"
},
{
"type": "PACKAGE",
"url": "https://github.com/dotnet/aspnetcore"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-40372"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Microsoft Security Advisory CVE-2026-40372 \u2013 ASP.NET Core Elevation of Privilege"
}
GHSA-9P6F-V932-MFXM
Vulnerability from github – Published: 2022-05-14 00:58 – Updated: 2022-05-14 00:58GNOME Evolution through 3.28.2 is prone to OpenPGP signatures being spoofed for arbitrary messages using a specially crafted email that contains a valid signature from the entity to be impersonated as an attachment.
{
"affected": [],
"aliases": [
"CVE-2018-15587"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-02-11T17:29:00Z",
"severity": "MODERATE"
},
"details": "GNOME Evolution through 3.28.2 is prone to OpenPGP signatures being spoofed for arbitrary messages using a specially crafted email that contains a valid signature from the entity to be impersonated as an attachment.",
"id": "GHSA-9p6f-v932-mfxm",
"modified": "2022-05-14T00:58:54Z",
"published": "2022-05-14T00:58:54Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-15587"
},
{
"type": "WEB",
"url": "https://bugzilla.gnome.org/show_bug.cgi?id=796424"
},
{
"type": "WEB",
"url": "https://github.com/RUB-NDS/Johnny-You-Are-Fired"
},
{
"type": "WEB",
"url": "https://github.com/RUB-NDS/Johnny-You-Are-Fired/blob/master/paper/johnny-fired.pdf"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2019/04/msg00027.html"
},
{
"type": "WEB",
"url": "https://seclists.org/bugtraq/2019/Jun/7"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/3998-1"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2019/dsa-4457"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2019-05/msg00047.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2019-05/msg00061.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2019-06/msg00024.html"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/152703/Johnny-You-Are-Fired.html"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2019/Apr/38"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2019/04/30/4"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-9P8X-F768-WP2G
Vulnerability from github – Published: 2025-03-14 17:14 – Updated: 2025-03-16 21:34Impact
An attacker may be able to exploit this vulnerability to bypass authentication or authorization mechanisms in systems that rely on xml-crypto for verifying signed XML documents. The vulnerability allows an attacker to modify a valid signed XML message in a way that still passes signature verification checks. For example, it could be used to alter critical identity or access control attributes, enabling an attacker with a valid account to escalate privileges or impersonate another user.
Patches
All versions <= 6.0.0 are affected. Please upgrade to version 6.0.1.
If you are still using v2.x or v3.x please upgrade to the associated patch version.
Indicators of Compromise
When logging XML payloads, check for the following indicators. If the payload includes encrypted elements, ensure you analyze the decrypted version for a complete assessment. (If encryption is not used, analyze the original XML document directly). This applies to various XML-based authentication and authorization flows, such as SAML Response payloads.
Multiple SignedInfo Nodes
There should not be more than one SignedInfo node inside a Signature. If you find multiple SignedInfo nodes, it could indicate an attack.
<Signature>
<SomeNode>
<SignedInfo>
<Reference URI="somefakereference">
<DigestValue>forgeddigestvalue</DigestValue>
</Reference>
</SignedInfo>
</SomeNode>
<SignedInfo>
<Reference URI="realsignedreference">
<DigestValue>realdigestvalue</DigestValue>
</Reference>
</SignedInfo>
</SignedInfo>
</Signature>
Code to test
Pass in the decrypted version of the document
decryptedDocument = ... // yours to implement
// This check is per-Signature node, not per-document
const signedInfoNodes = xpath.select(".//*[local-name(.)='SignedInfo']", signatureNode);
if (signedInfoNodes.length === 0) {
// Not necessarily a compromise, but invalid. Should contain exactly one SignedInfo node
// Yours to implement
}
if (signedInfoNodes.length > 1) {
// Compromise detected, yours to implement
}
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "xml-crypto"
},
"ranges": [
{
"events": [
{
"introduced": "4.0.0"
},
{
"fixed": "6.0.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "xml-crypto"
},
"ranges": [
{
"events": [
{
"introduced": "3.0.0"
},
{
"fixed": "3.2.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "xml-crypto"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.1.6"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-29774"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": true,
"github_reviewed_at": "2025-03-14T17:14:23Z",
"nvd_published_at": "2025-03-14T17:15:52Z",
"severity": "CRITICAL"
},
"details": "# Impact\nAn attacker may be able to exploit this vulnerability to bypass authentication or authorization mechanisms in systems that rely on xml-crypto for verifying signed XML documents. The vulnerability allows an attacker to modify a valid signed XML message in a way that still passes signature verification checks. For example, it could be used to alter critical identity or access control attributes, enabling an attacker with a valid account to escalate privileges or impersonate another user.\n\n# Patches\nAll versions \u003c= 6.0.0 are affected. Please upgrade to version 6.0.1.\n\nIf you are still using v2.x or v3.x please upgrade to the associated patch version.\n\n# Indicators of Compromise\n\nWhen logging XML payloads, check for the following indicators. If the payload includes encrypted elements, ensure you analyze the decrypted version for a complete assessment. (If encryption is not used, analyze the original XML document directly). This applies to various XML-based authentication and authorization flows, such as SAML Response payloads.\n\n### Multiple SignedInfo Nodes\nThere should not be more than one SignedInfo node inside a Signature. If you find multiple SignedInfo nodes, it could indicate an attack.\n\n```xml\n\u003cSignature\u003e\n \u003cSomeNode\u003e\n \u003cSignedInfo\u003e\n \u003cReference URI=\"somefakereference\"\u003e\n \u003cDigestValue\u003eforgeddigestvalue\u003c/DigestValue\u003e\n \u003c/Reference\u003e\n \u003c/SignedInfo\u003e\n \u003c/SomeNode\u003e\n \u003cSignedInfo\u003e\n \u003cReference URI=\"realsignedreference\"\u003e\n \u003cDigestValue\u003erealdigestvalue\u003c/DigestValue\u003e\n \u003c/Reference\u003e\n \u003c/SignedInfo\u003e\n \u003c/SignedInfo\u003e\n\u003c/Signature\u003e\n```\n\n### Code to test\n\nPass in the decrypted version of the document\n```js\ndecryptedDocument = ... // yours to implement\n\n// This check is per-Signature node, not per-document\nconst signedInfoNodes = xpath.select(\".//*[local-name(.)=\u0027SignedInfo\u0027]\", signatureNode);\n\nif (signedInfoNodes.length === 0) {\n // Not necessarily a compromise, but invalid. Should contain exactly one SignedInfo node\n // Yours to implement\n}\n\nif (signedInfoNodes.length \u003e 1) {\n // Compromise detected, yours to implement\n}\n```",
"id": "GHSA-9p8x-f768-wp2g",
"modified": "2025-03-16T21:34:47Z",
"published": "2025-03-14T17:14:23Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/node-saml/xml-crypto/security/advisories/GHSA-9p8x-f768-wp2g"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-29774"
},
{
"type": "WEB",
"url": "https://github.com/node-saml/xml-crypto/commit/28f92218ecbb8dcbd238afa4efbbd50302aa9aed"
},
{
"type": "WEB",
"url": "https://github.com/node-saml/xml-crypto/commit/886dc63a8b4bb5ae1db9f41c7854b171eb83aa98"
},
{
"type": "WEB",
"url": "https://github.com/node-saml/xml-crypto/commit/8ac6118ee7978b46aa56b82cbcaa5fca58c93a07"
},
{
"type": "PACKAGE",
"url": "https://github.com/node-saml/xml-crypto"
},
{
"type": "WEB",
"url": "https://github.com/node-saml/xml-crypto/releases/tag/v2.1.6"
},
{
"type": "WEB",
"url": "https://github.com/node-saml/xml-crypto/releases/tag/v3.2.1"
},
{
"type": "WEB",
"url": "https://github.com/node-saml/xml-crypto/releases/tag/v6.0.1"
},
{
"type": "WEB",
"url": "https://workos.com/blog/samlstorm"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "xml-crypto Vulnerable to XML Signature Verification Bypass via Multiple SignedInfo References"
}
GHSA-9PF8-H538-2P8J
Vulnerability from github – Published: 2022-05-24 17:41 – Updated: 2022-05-24 17:41An improper verification of cryptographic signature vulnerability exists in the Palo Alto Networks Prisma Cloud Compute console. This vulnerability enables an attacker to bypass signature validation during SAML authentication by logging in to the Prisma Cloud Compute console as any authorized user. This issue impacts: All versions of Prisma Cloud Compute 19.11, Prisma Cloud Compute 20.04, and Prisma Cloud Compute 20.09; Prisma Cloud Compute 20.12 before update 1. Prisma Cloud Compute SaaS version is not impacted by this vulnerability.
{
"affected": [],
"aliases": [
"CVE-2021-3033"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-02-10T18:15:00Z",
"severity": "CRITICAL"
},
"details": "An improper verification of cryptographic signature vulnerability exists in the Palo Alto Networks Prisma Cloud Compute console. This vulnerability enables an attacker to bypass signature validation during SAML authentication by logging in to the Prisma Cloud Compute console as any authorized user. This issue impacts: All versions of Prisma Cloud Compute 19.11, Prisma Cloud Compute 20.04, and Prisma Cloud Compute 20.09; Prisma Cloud Compute 20.12 before update 1. Prisma Cloud Compute SaaS version is not impacted by this vulnerability.",
"id": "GHSA-9pf8-h538-2p8j",
"modified": "2022-05-24T17:41:52Z",
"published": "2022-05-24T17:41:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3033"
},
{
"type": "WEB",
"url": "https://security.paloaltonetworks.com/CVE-2021-3033"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-9QR4-RPFH-F5GV
Vulnerability from github – Published: 2022-05-24 17:33 – Updated: 2022-05-24 17:33Acrobat Reader DC versions 2020.012.20048 (and earlier), 2020.001.30005 (and earlier) and 2017.011.30175 (and earlier) for macOS are affected by a signature verification bypass that could result in local privilege escalation. Exploitation of this issue requires user interaction in that a victim must open a malicious file.
{
"affected": [],
"aliases": [
"CVE-2020-24429"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-11-05T20:15:00Z",
"severity": "HIGH"
},
"details": "Acrobat Reader DC versions 2020.012.20048 (and earlier), 2020.001.30005 (and earlier) and 2017.011.30175 (and earlier) for macOS are affected by a signature verification bypass that could result in local privilege escalation. Exploitation of this issue requires user interaction in that a victim must open a malicious file.",
"id": "GHSA-9qr4-rpfh-f5gv",
"modified": "2022-05-24T17:33:13Z",
"published": "2022-05-24T17:33:13Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-24429"
},
{
"type": "WEB",
"url": "https://helpx.adobe.com/security/products/acrobat/apsb20-67.html"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-9R9H-RJVP-WRFF
Vulnerability from github – Published: 2022-05-24 17:46 – Updated: 2022-05-24 17:46Union Pay up to 3.3.12, for iOS mobile apps, contains a CWE-347: Improper Verification of Cryptographic Signature vulnerability, allows attackers to shop for free in merchants' websites and mobile apps, via a crafted authentication code (MAC) which is generated based on a secret key which is NULL.
{
"affected": [],
"aliases": [
"CVE-2020-36285"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-04-06T16:15:00Z",
"severity": "HIGH"
},
"details": "Union Pay up to 3.3.12, for iOS mobile apps, contains a CWE-347: Improper Verification of Cryptographic Signature vulnerability, allows attackers to shop for free in merchants\u0027 websites and mobile apps, via a crafted authentication code (MAC) which is generated based on a secret key which is NULL.",
"id": "GHSA-9r9h-rjvp-wrff",
"modified": "2022-05-24T17:46:35Z",
"published": "2022-05-24T17:46:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-36285"
},
{
"type": "WEB",
"url": "https://www.dropbox.com/s/6smwnbrp0kgsgrc/poc_code.py?dl=0"
},
{
"type": "WEB",
"url": "https://www.dropbox.com/s/czbkdr73tclq2nr/UnionPay_Vulnerability_Report.txt?dl=0"
},
{
"type": "WEB",
"url": "http://mobitec.ie.cuhk.edu.hk/cve_2020"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-9RCX-W9PG-PVF5
Vulnerability from github – Published: 2022-05-13 01:46 – Updated: 2022-05-13 01:46The auto-update feature of Open Embedded Linux Entertainment Center (OpenELEC) 6.0.3, 7.0.1, and 8.0.4 uses neither encrypted connections nor signed updates. A man-in-the-middle attacker could manipulate the update packages to gain root access remotely.
{
"affected": [],
"aliases": [
"CVE-2017-6445"
],
"database_specific": {
"cwe_ids": [
"CWE-311",
"CWE-347"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-03-05T20:59:00Z",
"severity": "HIGH"
},
"details": "The auto-update feature of Open Embedded Linux Entertainment Center (OpenELEC) 6.0.3, 7.0.1, and 8.0.4 uses neither encrypted connections nor signed updates. A man-in-the-middle attacker could manipulate the update packages to gain root access remotely.",
"id": "GHSA-9rcx-w9pg-pvf5",
"modified": "2022-05-13T01:46:35Z",
"published": "2022-05-13T01:46:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-6445"
},
{
"type": "WEB",
"url": "https://tech.feedyourhead.at/content/openelec-cve-2017-6445-revisited"
},
{
"type": "WEB",
"url": "https://tech.feedyourhead.at/content/openelec-remote-code-execution-vulnerability-through-man-in-the-middle"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/96580"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-9RFG-V8G9-9367
Vulnerability from github – Published: 2026-05-26 23:38 – Updated: 2026-06-11 13:30As told on Discord earlier, multiple projects are affected, and we would like to coordinate. For now, we are aiming at a May 6th release date, but this is not set in stone yet.
Summary
An attacker can make use of JSON-LD features to restructure a JSON-LD document that would change how Fedify interprets it without changing its Linked Data Signature, allowing them to alter a third-party signed activity they have received.
Details
The vulnerability essentially boils down to the signature being on the canonical RDF graph representation of the JSON-LD document, and JSON-LD offering many ways to represent the same graph.
One of the issues is that by taking a signed Activity with an embedded object, an attacker can move the top-level Activity to a @graph property and move the activity's object to the top-level. Such a transformation preserves the signature and changes how the payload is interpreted by pretty much all ActivityPub implementations, making them process the object and ignore the formely-top-level activity. This can be used when the graph contains an embedded activity. In Mastodon, that is the case of { "type": "Undo", "object": { "type": "Announce" } }, but other implementations may sign other activities that can be exploited in the same way.
The @reverse keyword can also be used to change the shape of a JSON-LD document without changing the underlying graph, and could be used in a similar way to reverse an Activity and its object.
Another problematic feature is @included, which can be used to “move” properties outside of the normal tree, effectively making them invisible to most ActivityPub implementations, while, again, preserving the signature. This allows removing statuses or actor properties once a signed Create or Update activity is received.
Given that we have seen no use of @graph, @included or @reverse in ActivityPub payloads and that they are very complex to handle correctly (the only JSON-LD API functions that “normalize” @included and @reverse are flattening and framing, which both lose the root node), we have decided to reject them, and recommend you do so as well.
Detection of @graph, @included and @reverse should happen after compacting the incoming activity to your context, as aliases can be used for those keywords.
Additionally, after a quick scan of Fedify's source code, I could not verify that JSON-LD documents with a verified Linked Data Signature were compacted against your local JSON-LD context. Not doing that allows an attacker to rename aliases to non-standard names and use non-mapped aliases to replace existing values, while still leaving the signature intact. This allows an attacker to essentially replace arbitrary portions of any signed JSON-LD document and completely forge any activity while still passing verification. A similar issue was fixed in Mastodon a few years ago: https://github.com/mastodon/mastodon/pull/17426.
Impact
The impact is difficult to assess as this depends on the types of activities that are actually signed and processed in the wild.
The @included keyword allows “removing” arbitrary attributes, thus allowing replaying Create and Update activities while stripping away any attribute, such as content or metadata, which can lead to integrity and availability issues, although confidentiality issues are unlikely.
The @graph and @reverse keywords allow changing the root activity, which in the case of Mastodon allows sending an Announce from a Undo { Announce }, but might have wider consequences depending on what various servers sign.
The lack of compacting can allow rewriting any activity arbitrarily, thus leading to major integrity, availability, and possibly confidentiality issues (e.g. by replacing an actor's inbox).
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "@fedify/fedify"
},
"ranges": [
{
"events": [
{
"introduced": "2.2.0"
},
{
"fixed": "2.2.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "@fedify/fedify"
},
"ranges": [
{
"events": [
{
"introduced": "2.1.0"
},
{
"fixed": "2.1.14"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "@fedify/fedify"
},
"ranges": [
{
"events": [
{
"introduced": "2.0.0"
},
{
"fixed": "2.0.18"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "@fedify/fedify"
},
"ranges": [
{
"events": [
{
"introduced": "1.10.0"
},
{
"fixed": "1.10.10"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "@fedify/fedify"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.9.11"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-42462"
],
"database_specific": {
"cwe_ids": [
"CWE-1289",
"CWE-180",
"CWE-347",
"CWE-436"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-26T23:38:37Z",
"nvd_published_at": "2026-06-10T22:16:57Z",
"severity": "HIGH"
},
"details": "As told on Discord earlier, multiple projects are affected, and we would like to coordinate. For now, we are aiming at a May 6th release date, but this is not set in stone yet.\n\n### Summary\n\nAn attacker can make use of JSON-LD features to restructure a JSON-LD document that would change how Fedify interprets it without changing its Linked Data Signature, allowing them to alter a third-party signed activity they have received.\n\n### Details\n\nThe vulnerability essentially boils down to the signature being on the canonical RDF graph representation of the JSON-LD document, and JSON-LD offering many ways to represent the same graph.\n\nOne of the issues is that by taking a signed `Activity` with an embedded `object`, an attacker can move the top-level `Activity` to a `@graph` property and move the activity\u0027s `object` to the top-level. Such a transformation preserves the signature and changes how the payload is interpreted by pretty much all ActivityPub implementations, making them process the object and ignore the formely-top-level activity. This can be used when the graph contains an embedded activity. In Mastodon, that is the case of `{ \"type\": \"Undo\", \"object\": { \"type\": \"Announce\" } }`, but other implementations may sign other activities that can be exploited in the same way.\n\nThe `@reverse` keyword can also be used to change the shape of a JSON-LD document without changing the underlying graph, and could be used in a similar way to reverse an `Activity` and its `object`.\n\nAnother problematic feature is `@included`, which can be used to \u201cmove\u201d properties outside of the normal tree, effectively making them invisible to most ActivityPub implementations, while, again, preserving the signature. This allows removing statuses or actor properties once a signed `Create` or `Update` activity is received.\n\nGiven that we have seen no use of `@graph`, `@included` or `@reverse` in ActivityPub payloads and that they are very complex to handle correctly (the only JSON-LD API functions that \u201cnormalize\u201d `@included` and `@reverse` are flattening and framing, which both lose the root node), we have decided to reject them, and recommend you do so as well.\n\nDetection of `@graph`, `@included` and `@reverse` should happen after compacting the incoming activity to your context, as aliases can be used for those keywords.\n\nAdditionally, after a quick scan of Fedify\u0027s source code, I could not verify that JSON-LD documents with a verified Linked Data Signature were compacted against your local JSON-LD context. Not doing that allows an attacker to rename aliases to non-standard names and use non-mapped aliases to replace existing values, while still leaving the signature intact. This allows an attacker to essentially replace arbitrary portions of any signed JSON-LD document and completely forge any activity while still passing verification. A similar issue was fixed in Mastodon a few years ago: https://github.com/mastodon/mastodon/pull/17426.\n\n### Impact\n\nThe impact is difficult to assess as this depends on the types of activities that are actually signed and processed in the wild.\n\nThe `@included` keyword allows \u201cremoving\u201d arbitrary attributes, thus allowing replaying `Create` and `Update` activities while stripping away any attribute, such as content or metadata, which can lead to integrity and availability issues, although confidentiality issues are unlikely.\n\nThe `@graph` and `@reverse` keywords allow changing the root activity, which in the case of Mastodon allows sending an `Announce` from a `Undo { Announce }`, but might have wider consequences depending on what various servers sign.\n\nThe lack of compacting can allow rewriting any activity arbitrarily, thus leading to major integrity, availability, and possibly confidentiality issues (e.g. by replacing an actor\u0027s `inbox`).",
"id": "GHSA-9rfg-v8g9-9367",
"modified": "2026-06-11T13:30:30Z",
"published": "2026-05-26T23:38:37Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/fedify-dev/fedify/security/advisories/GHSA-9rfg-v8g9-9367"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42462"
},
{
"type": "PACKAGE",
"url": "https://github.com/fedify-dev/fedify"
},
{
"type": "WEB",
"url": "https://github.com/fedify-dev/fedify/releases/tag/2.2.3"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:H/A:L",
"type": "CVSS_V3"
}
],
"summary": "Fedify has an LD-Signature Bypass via JSON-LD Named-Graph Restructuring"
}
GHSA-9V6R-G5CX-H6FG
Vulnerability from github – Published: 2023-05-18 12:30 – Updated: 2023-05-18 12:30Local privilege escalation due to unrestricted loading of unsigned libraries. The following products are affected: Acronis Cyber Protect Home Office (Windows) before build 40208.
{
"affected": [],
"aliases": [
"CVE-2022-4418"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-05-18T10:15:09Z",
"severity": "HIGH"
},
"details": "Local privilege escalation due to unrestricted loading of unsigned libraries. The following products are affected: Acronis Cyber Protect Home Office (Windows) before build 40208.",
"id": "GHSA-9v6r-g5cx-h6fg",
"modified": "2023-05-18T12:30:15Z",
"published": "2023-05-18T12:30:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-4418"
},
{
"type": "WEB",
"url": "https://security-advisory.acronis.com/advisories/SEC-4729"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-9V8J-X534-2FX3
Vulnerability from github – Published: 2025-12-08 21:30 – Updated: 2025-12-12 21:52Summary
Ruby-saml up to and including 1.12.4, there is an authentication bypass vulnerability because of an incomplete fix for CVE-2025-25292. ReXML and Nokogiri parse XML differently, the parsers can generate entirely different document structures from the same XML input. That allows an attacker to be able to execute a Signature Wrapping attack. The vulnerability does not affect the version 1.18.0.
Impact
That allows an attacker to be able to execute a Signature Wrapping attack and bypass the authentication
{
"affected": [
{
"package": {
"ecosystem": "RubyGems",
"name": "ruby-saml"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.18.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-66567"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": true,
"github_reviewed_at": "2025-12-08T21:30:56Z",
"nvd_published_at": "2025-12-09T16:18:21Z",
"severity": "CRITICAL"
},
"details": "### Summary\n\nRuby-saml up to and including 1.12.4, there is an authentication bypass vulnerability because of an incomplete fix for CVE-2025-25292. ReXML and Nokogiri parse XML differently, the parsers can generate entirely different document structures from the same XML input. That allows an attacker to be able to execute a Signature Wrapping attack. The vulnerability does not affect the version 1.18.0.\n\n### Impact\nThat allows an attacker to be able to execute a Signature Wrapping attack and bypass the authentication",
"id": "GHSA-9v8j-x534-2fx3",
"modified": "2025-12-12T21:52:23Z",
"published": "2025-12-08T21:30:56Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/SAML-Toolkits/ruby-saml/security/advisories/GHSA-9v8j-x534-2fx3"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-66567"
},
{
"type": "WEB",
"url": "https://github.com/SAML-Toolkits/ruby-saml/commit/e9c1cdbd0f9afa467b585de279db0cbd0fb8ae97"
},
{
"type": "PACKAGE",
"url": "https://github.com/SAML-Toolkits/ruby-saml"
},
{
"type": "ADVISORY",
"url": "https://github.com/advisories/GHSA-754f-8gm6-c4r2"
},
{
"type": "WEB",
"url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/ruby-saml/CVE-2025-66567.yml"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Ruby-saml has a SAML authentication bypass due to namespace handling (parser differential)"
}
No mitigation information available for this CWE.
CAPEC-463: Padding Oracle Crypto Attack
An adversary is able to efficiently decrypt data without knowing the decryption key if a target system leaks data on whether or not a padding error happened while decrypting the ciphertext. A target system that leaks this type of information becomes the padding oracle and an adversary is able to make use of that oracle to efficiently decrypt data without knowing the decryption key by issuing on average 128*b calls to the padding oracle (where b is the number of bytes in the ciphertext block). In addition to performing decryption, an adversary is also able to produce valid ciphertexts (i.e., perform encryption) by using the padding oracle, all without knowing the encryption key.
CAPEC-475: Signature Spoofing by Improper Validation
An adversary exploits a cryptographic weakness in the signature verification algorithm implementation to generate a valid signature without knowing the key.