CWE-347
AllowedImproper Verification of Cryptographic Signature
Abstraction: Base · Status: Draft
The product does not verify, or incorrectly verifies, the cryptographic signature for data.
1264 vulnerabilities reference this CWE, most recent first.
GHSA-MHC4-QQ83-FMRR
Vulnerability from github – Published: 2026-05-06 23:15 – Updated: 2026-05-06 23:15Summary
The AxonFlow SDK's WebhookSubscription (or equivalent) type did not expose the HMAC-SHA256 signing key returned by the platform's CreateWebhook endpoint. Without access to the secret through the typed SDK API, callers had no path to verify the X-AxonFlow-Signature header on incoming webhook deliveries. Affected callers had two unsatisfactory options:
- Skip signature verification entirely — accepting any payload from any source that knew the webhook URL.
- Hand-parse the raw HTTP JSON response to extract the secret, bypassing the type-safe SDK surface.
This advisory is filed across all four AxonFlow SDKs (Go, Python, TypeScript, Java) because the same defect and the same fix landed in each.
Affected versions
Versions 5.6.1 and below.
Impact
A webhook receiver using the SDK's typed API to handle inbound deliveries had no path to authenticate the source of incoming payloads. An attacker who learned the webhook URL — through misconfiguration, log leakage, observable network traffic during setup, or any other discovery channel — could forge webhook deliveries indistinguishable from legitimate ones, causing the receiving application to act on fabricated events (e.g. simulated approval-granted callbacks, simulated policy-decision callbacks, simulated step-completion callbacks).
Remediation
Upgrade to the patched version listed in Vulnerabilities below. The signing key is now exposed on the WebhookSubscription response type returned by CreateWebhook. Implementations should:
- Persist the secret returned by
CreateWebhooksecurely (it is only returned once, at create time). - On each incoming webhook delivery, compute
HMAC-SHA256(secret, raw_body)and compare it in constant time against theX-AxonFlow-Signatureheader. - Reject any delivery whose signature does not match.
Credit
Identified by AxonFlow internal security review during the April 2026 quality-freeze epic.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/getaxonflow/axonflow-sdk-go/v5"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.7.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-345",
"CWE-347"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-06T23:15:38Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## Summary\n\nThe AxonFlow SDK\u0027s `WebhookSubscription` (or equivalent) type did not expose the HMAC-SHA256 signing key returned by the platform\u0027s `CreateWebhook` endpoint. Without access to the secret through the typed SDK API, callers had no path to verify the `X-AxonFlow-Signature` header on incoming webhook deliveries. Affected callers had two unsatisfactory options:\n\n1. Skip signature verification entirely \u2014 accepting any payload from any source that knew the webhook URL.\n2. Hand-parse the raw HTTP JSON response to extract the secret, bypassing the type-safe SDK surface.\n\nThis advisory is filed across all four AxonFlow SDKs (Go, Python, TypeScript, Java) because the same defect and the same fix landed in each.\n\n## Affected versions\n\nVersions 5.6.1 and below.\n\n## Impact\n\nA webhook receiver using the SDK\u0027s typed API to handle inbound deliveries had no path to authenticate the source of incoming payloads. An attacker who learned the webhook URL \u2014 through misconfiguration, log leakage, observable network traffic during setup, or any other discovery channel \u2014 could forge webhook deliveries indistinguishable from legitimate ones, causing the receiving application to act on fabricated events (e.g. simulated approval-granted callbacks, simulated policy-decision callbacks, simulated step-completion callbacks).\n\n## Remediation\n\nUpgrade to the patched version listed in Vulnerabilities below. The signing key is now exposed on the `WebhookSubscription` response type returned by `CreateWebhook`. Implementations should:\n\n1. Persist the secret returned by `CreateWebhook` securely (it is only returned once, at create time).\n2. On each incoming webhook delivery, compute `HMAC-SHA256(secret, raw_body)` and compare it in constant time against the `X-AxonFlow-Signature` header.\n3. Reject any delivery whose signature does not match.\n\n## Credit\n\nIdentified by AxonFlow internal security review during the April 2026 quality-freeze epic.",
"id": "GHSA-mhc4-qq83-fmrr",
"modified": "2026-05-06T23:15:38Z",
"published": "2026-05-06T23:15:38Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/getaxonflow/axonflow-sdk-go/security/advisories/GHSA-mhc4-qq83-fmrr"
},
{
"type": "PACKAGE",
"url": "https://github.com/getaxonflow/axonflow-sdk-go"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "axonflow-sdk-go: Webhook signing-key (HMAC-SHA256) not exposed by SDK type, preventing signature verification"
}
GHSA-MHFM-4H29-4R45
Vulnerability from github – Published: 2024-07-02 21:32 – Updated: 2024-07-02 21:32Improper verification of signature in FilterProvider prior to SMR Jul-2024 Release 1 allows local attackers to execute privileged behaviors. User interaction is required for triggering this vulnerability.
{
"affected": [],
"aliases": [
"CVE-2024-20892"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-07-02T10:15:04Z",
"severity": "MODERATE"
},
"details": "Improper verification of signature in FilterProvider prior to SMR Jul-2024 Release 1 allows local attackers to execute privileged behaviors. User interaction is required for triggering this vulnerability.",
"id": "GHSA-mhfm-4h29-4r45",
"modified": "2024-07-02T21:32:12Z",
"published": "2024-07-02T21:32:12Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-20892"
},
{
"type": "WEB",
"url": "https://security.samsungmobile.com/securityUpdate.smsb?year=2024\u0026month=07"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:N/UI:R/S:U/C:L/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-MHR8-VXV5-M5V8
Vulnerability from github – Published: 2022-05-24 16:47 – Updated: 2024-04-04 00:51There is a digital signature verification bypass vulnerability in AR1200, AR1200-S, AR150, AR160, AR200, AR2200, AR2200-S, AR3200, SRG1300, SRG2300 and SRG3300 Huawei routers. The vulnerability is due to the affected software improperly verifying digital signatures for the software image in the affected device. A local attacker with high privilege may exploit the vulnerability to bypass integrity checks for software images and install a malicious software image on the affected device.
{
"affected": [],
"aliases": [
"CVE-2019-5300"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-06-04T19:29:00Z",
"severity": "MODERATE"
},
"details": "There is a digital signature verification bypass vulnerability in AR1200, AR1200-S, AR150, AR160, AR200, AR2200, AR2200-S, AR3200, SRG1300, SRG2300 and SRG3300 Huawei routers. The vulnerability is due to the affected software improperly verifying digital signatures for the software image in the affected device. A local attacker with high privilege may exploit the vulnerability to bypass integrity checks for software images and install a malicious software image on the affected device.",
"id": "GHSA-mhr8-vxv5-m5v8",
"modified": "2024-04-04T00:51:40Z",
"published": "2022-05-24T16:47:10Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-5300"
},
{
"type": "WEB",
"url": "https://www.huawei.com/en/psirt/security-advisories/huawei-sa-20190320-01-ar-en"
}
],
"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-MJ4X-WCXF-HM8X
Vulnerability from github – Published: 2018-07-31 18:13 – Updated: 2023-08-25 23:55The json-jwt rubygem version >= 0.5.0 && < 1.9.4 contains a CWE-347: Improper Verification of Cryptographic Signature vulnerability in Decryption of AES-GCM encrypted JSON Web Tokens that can result in Attacker can forge a authentication tag. This attack appear to be exploitable via network connectivity. This vulnerability appears to have been fixed in 1.9.4 and later.
{
"affected": [
{
"package": {
"ecosystem": "RubyGems",
"name": "json-jwt"
},
"ranges": [
{
"events": [
{
"introduced": "0.5.1"
},
{
"fixed": "1.9.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2018-1000539"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": true,
"github_reviewed_at": "2020-06-16T21:46:30Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "The json-jwt rubygem version \u003e= 0.5.0 \u0026\u0026 \u003c 1.9.4 contains a CWE-347: Improper Verification of Cryptographic Signature vulnerability in Decryption of AES-GCM encrypted JSON Web Tokens that can result in Attacker can forge a authentication tag. This attack appear to be exploitable via network connectivity. This vulnerability appears to have been fixed in 1.9.4 and later.",
"id": "GHSA-mj4x-wcxf-hm8x",
"modified": "2023-08-25T23:55:12Z",
"published": "2018-07-31T18:13:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-1000539"
},
{
"type": "WEB",
"url": "https://github.com/nov/json-jwt/pull/62"
},
{
"type": "WEB",
"url": "https://github.com/nov/json-jwt/commit/a3b2147f0f6d9aca653e7a30e453d3a92b33413f"
},
{
"type": "PACKAGE",
"url": "https://github.com/nov/json-jwt"
},
{
"type": "WEB",
"url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/json-jwt/CVE-2018-1000539.yml"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2018/dsa-4283"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Json-jwt did not verify the cryptographic signature for data"
}
GHSA-MMV5-G2HF-R8CF
Vulnerability from github – Published: 2022-10-10 19:00 – Updated: 2025-06-09 15:31An issue was discovered in D-Bus before 1.12.24, 1.13.x and 1.14.x before 1.14.4, and 1.15.x before 1.15.2. An authenticated attacker can cause dbus-daemon and other programs that use libdbus to crash when receiving a message with certain invalid type signatures.
{
"affected": [],
"aliases": [
"CVE-2022-42010"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-10-10T00:15:00Z",
"severity": "MODERATE"
},
"details": "An issue was discovered in D-Bus before 1.12.24, 1.13.x and 1.14.x before 1.14.4, and 1.15.x before 1.15.2. An authenticated attacker can cause dbus-daemon and other programs that use libdbus to crash when receiving a message with certain invalid type signatures.",
"id": "GHSA-mmv5-g2hf-r8cf",
"modified": "2025-06-09T15:31:34Z",
"published": "2022-10-10T19:00:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-42010"
},
{
"type": "WEB",
"url": "https://gitlab.freedesktop.org/dbus/dbus/-/issues/418"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/E4CO7N226I3X5FNBR2MACCH6TS764VJP"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/ND74SKN56BCYL3QLEAAB6E64UUBRA5UG"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/SQCSLMCK2XGX23R2DKW2MSAICQAK6MT2"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/E4CO7N226I3X5FNBR2MACCH6TS764VJP"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/ND74SKN56BCYL3QLEAAB6E64UUBRA5UG"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/SQCSLMCK2XGX23R2DKW2MSAICQAK6MT2"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/202305-08"
},
{
"type": "WEB",
"url": "https://www.openwall.com/lists/oss-security/2022/10/06/1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-MP2X-RXHG-987G
Vulnerability from github – Published: 2022-09-03 00:00 – Updated: 2022-09-09 00:00Possible authentication bypass due to improper order of signature verification and hashing in the signature verification call in Snapdragon Auto, Snapdragon Compute, Snapdragon Connectivity, Snapdragon Consumer IOT, Snapdragon Industrial IOT, Snapdragon Mobile, Snapdragon Voice & Music, Snapdragon Wearables
{
"affected": [],
"aliases": [
"CVE-2021-35097"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-09-02T12:15:00Z",
"severity": "MODERATE"
},
"details": "Possible authentication bypass due to improper order of signature verification and hashing in the signature verification call in Snapdragon Auto, Snapdragon Compute, Snapdragon Connectivity, Snapdragon Consumer IOT, Snapdragon Industrial IOT, Snapdragon Mobile, Snapdragon Voice \u0026 Music, Snapdragon Wearables",
"id": "GHSA-mp2x-rxhg-987g",
"modified": "2022-09-09T00:00:56Z",
"published": "2022-09-03T00:00:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-35097"
},
{
"type": "WEB",
"url": "https://www.qualcomm.com/company/product-security/bulletins/august-2022-bulletin"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-MP5P-GQ8Q-GCGG
Vulnerability from github – Published: 2022-05-24 17:26 – Updated: 2025-11-04 21:30NCR SelfServ ATMs running APTRA XFS 05.01.00 do not properly validate softare updates for the bunch note acceptor (BNA), enabling an attacker with physical access to internal ATM components to restart the host computer and execute arbitrary code with SYSTEM privileges because while booting, the update process looks for CAB archives on removable media and executes a specific file without first validating the signature of the CAB archive.
{
"affected": [],
"aliases": [
"CVE-2020-10126"
],
"database_specific": {
"cwe_ids": [
"CWE-305",
"CWE-347"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-08-21T21:15:00Z",
"severity": "HIGH"
},
"details": "NCR SelfServ ATMs running APTRA XFS 05.01.00 do not properly validate softare updates for the bunch note acceptor (BNA), enabling an attacker with physical access to internal ATM components to restart the host computer and execute arbitrary code with SYSTEM privileges because while booting, the update process looks for CAB archives on removable media and executes a specific file without first validating the signature of the CAB archive.",
"id": "GHSA-mp5p-gq8q-gcgg",
"modified": "2025-11-04T21:30:24Z",
"published": "2022-05-24T17:26:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-10126"
},
{
"type": "WEB",
"url": "https://kb.cert.org/vuls/id/815655"
},
{
"type": "WEB",
"url": "https://www.kb.cert.org/vuls/id/815655"
},
{
"type": "WEB",
"url": "https://www.ncr.com/content/dam/ncrcom/content-type/documents/NCR_Security_Alert-2018-13_APTRA_XFS_"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-MP9M-RQ8W-3XM6
Vulnerability from github – Published: 2026-07-29 21:31 – Updated: 2026-07-29 21:31Autel MaxiCharger AC Elite Home Software Update Improper Verification of Cryptographic Signature Arbitrary Code Execution Vulnerability. This vulnerability allows physically present attackers to execute arbitrary code on affected installations of Autel MaxiCharger AC Elite Home EV chargers. Authentication is not required to exploit this vulnerability.
The specific flaw exists within the handling of software updates. The issue results from the lack of proper validation of a user-supplied software update image. An attacker can leverage this vulnerability to execute code in the context of the device. Was ZDI-CAN-29062.
{
"affected": [],
"aliases": [
"CVE-2026-13305"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-29T21:17:46Z",
"severity": "MODERATE"
},
"details": "Autel MaxiCharger AC Elite Home Software Update Improper Verification of Cryptographic Signature Arbitrary Code Execution Vulnerability. This vulnerability allows physically present attackers to execute arbitrary code on affected installations of Autel MaxiCharger AC Elite Home EV chargers. Authentication is not required to exploit this vulnerability.\n\nThe specific flaw exists within the handling of software updates. The issue results from the lack of proper validation of a user-supplied software update image. An attacker can leverage this vulnerability to execute code in the context of the device. Was ZDI-CAN-29062.",
"id": "GHSA-mp9m-rq8w-3xm6",
"modified": "2026-07-29T21:31:01Z",
"published": "2026-07-29T21:31:01Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-13305"
},
{
"type": "WEB",
"url": "https://www.zerodayinitiative.com/advisories/ZDI-26-433"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:P/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-MPH8-9V29-PM42
Vulnerability from github – Published: 2026-05-06 23:16 – Updated: 2026-05-06 23:16Summary
The AxonFlow SDK's WebhookSubscription (or equivalent) type did not expose the HMAC-SHA256 signing key returned by the platform's CreateWebhook endpoint. Without access to the secret through the typed SDK API, callers had no path to verify the X-AxonFlow-Signature header on incoming webhook deliveries. Affected callers had two unsatisfactory options:
- Skip signature verification entirely — accepting any payload from any source that knew the webhook URL.
- Hand-parse the raw HTTP JSON response to extract the secret, bypassing the type-safe SDK surface.
This advisory is filed across all four AxonFlow SDKs (Go, Python, TypeScript, Java) because the same defect and the same fix landed in each.
Affected versions
Versions 5.6.0 and below.
Impact
A webhook receiver using the SDK's typed API to handle inbound deliveries had no path to authenticate the source of incoming payloads. An attacker who learned the webhook URL — through misconfiguration, log leakage, observable network traffic during setup, or any other discovery channel — could forge webhook deliveries indistinguishable from legitimate ones, causing the receiving application to act on fabricated events (e.g. simulated approval-granted callbacks, simulated policy-decision callbacks, simulated step-completion callbacks).
Remediation
Upgrade to the patched version listed in Vulnerabilities below. The signing key is now exposed on the WebhookSubscription response type returned by CreateWebhook. Implementations should:
- Persist the secret returned by
CreateWebhooksecurely (it is only returned once, at create time). - On each incoming webhook delivery, compute
HMAC-SHA256(secret, raw_body)and compare it in constant time against theX-AxonFlow-Signatureheader. - Reject any delivery whose signature does not match.
Credit
Identified by AxonFlow internal security review during the April 2026 quality-freeze epic.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "@axonflow/sdk"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.0.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-345",
"CWE-347"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-06T23:16:24Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## Summary\n\nThe AxonFlow SDK\u0027s `WebhookSubscription` (or equivalent) type did not expose the HMAC-SHA256 signing key returned by the platform\u0027s `CreateWebhook` endpoint. Without access to the secret through the typed SDK API, callers had no path to verify the `X-AxonFlow-Signature` header on incoming webhook deliveries. Affected callers had two unsatisfactory options:\n\n1. Skip signature verification entirely \u2014 accepting any payload from any source that knew the webhook URL.\n2. Hand-parse the raw HTTP JSON response to extract the secret, bypassing the type-safe SDK surface.\n\nThis advisory is filed across all four AxonFlow SDKs (Go, Python, TypeScript, Java) because the same defect and the same fix landed in each.\n\n## Affected versions\n\nVersions 5.6.0 and below.\n\n## Impact\n\nA webhook receiver using the SDK\u0027s typed API to handle inbound deliveries had no path to authenticate the source of incoming payloads. An attacker who learned the webhook URL \u2014 through misconfiguration, log leakage, observable network traffic during setup, or any other discovery channel \u2014 could forge webhook deliveries indistinguishable from legitimate ones, causing the receiving application to act on fabricated events (e.g. simulated approval-granted callbacks, simulated policy-decision callbacks, simulated step-completion callbacks).\n\n## Remediation\n\nUpgrade to the patched version listed in Vulnerabilities below. The signing key is now exposed on the `WebhookSubscription` response type returned by `CreateWebhook`. Implementations should:\n\n1. Persist the secret returned by `CreateWebhook` securely (it is only returned once, at create time).\n2. On each incoming webhook delivery, compute `HMAC-SHA256(secret, raw_body)` and compare it in constant time against the `X-AxonFlow-Signature` header.\n3. Reject any delivery whose signature does not match.\n\n## Credit\n\nIdentified by AxonFlow internal security review during the April 2026 quality-freeze epic.",
"id": "GHSA-mph8-9v29-pm42",
"modified": "2026-05-06T23:16:24Z",
"published": "2026-05-06T23:16:24Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/getaxonflow/axonflow-sdk-typescript/security/advisories/GHSA-mph8-9v29-pm42"
},
{
"type": "PACKAGE",
"url": "https://github.com/getaxonflow/axonflow-sdk-typescript"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "axonflow-sdk-typescript: Webhook signing-key (HMAC-SHA256) not exposed by SDK type, preventing signature verification"
}
GHSA-MQ36-523M-X7VV
Vulnerability from github – Published: 2026-08-20 18:35 – Updated: 2026-08-20 18:35Summary A missing nonce verification in the UserNameIdentityToken authentication handler allows an unauthenticated remote attacker to forge a password token that extracts as an empty string, and to replay captured authentication tokens across sessions.
Affected versions: <= 2.165.0 Tested version: 2.165.0 CVSS Score: 8.1 (High) CVSS Vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:L CWE: CWE-347 Improper Verification of Cryptographic Signature
Root Cause
In packages/node-opcua-server/source/opcua_server.ts at line 1886-1887, after RSA-OAEP decrypting the UserNameIdentityToken password blob, the server reads a 4-byte little-endian length field and extracts buff[4 : 4+length] as the password. It never verifies that the trailing bytes equal session.nonce.
This has two consequences:
-
Forged empty password: An attacker who retrieves the server's public key via an unauthenticated
GetEndpointscall can craft a token where the 4-byte length field equalsserverNonce.length(32). The server computeslength = 32 - 32 = 0and callsisValidUser(username, ""). Any account that accepts an empty password is compromised. -
Unconditional replay attack: Because nonce binding is structurally absent, any captured UserNameIdentityToken ciphertext can be replayed in a different session unconditionally.
The impact is compounded by a second issue: when the channel uses SecurityMode=None, verifyClientSignature returns true unconditionally (security_policy.ts:697-700), bypassing the channel-level signature check entirely.
Proof of Concept (logic, no exploit code)
1. GetEndpoints (unauthenticated) → retrieve server public key and RSA token policy
2. OpenSecureChannel (SecurityMode=None)
3. CreateSession
4. Craft plaintext: [0x20, 0x00, 0x00, 0x00] (readUInt32LE = 32 = serverNonce.length)
5. RSA-OAEP encrypt with server public key → 256-byte ciphertext
6. ActivateSession with crafted UserNameIdentityToken
7. Server decrypts → length = 32 - 32 = 0 → password = ""
8. isValidUser(username, "") is called
Dynamically confirmed: decryption produces password = "" with no error and no nonce verification.
Suggested Fix
After decrypting the password blob, verify that buff.slice(4 + passwordLength) equals session.nonce before extracting the password. Reject the token if verification fails.
I am following a 90-day responsible disclosure policy. I am happy to provide additional technical details under embargo. Please confirm receipt at your earliest convenience.
Reporter: Stanley Tobias Discovery date: 2026-03-23
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "node-opcua"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "2.165.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-54155"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-20T18:35:33Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "**Summary**\nA missing nonce verification in the UserNameIdentityToken authentication handler allows an unauthenticated remote attacker to forge a password token that extracts as an empty string, and to replay captured authentication tokens across sessions.\n\n**Affected versions:** \u003c= 2.165.0\n**Tested version:** 2.165.0\n**CVSS Score:** 8.1 (High)\n**CVSS Vector:** CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:L\n**CWE:** CWE-347 Improper Verification of Cryptographic Signature\n\n---\n\n**Root Cause**\n\nIn `packages/node-opcua-server/source/opcua_server.ts` at line 1886-1887, after RSA-OAEP decrypting the UserNameIdentityToken password blob, the server reads a 4-byte little-endian length field and extracts `buff[4 : 4+length]` as the password. It never verifies that the trailing bytes equal `session.nonce`.\n\nThis has two consequences:\n\n1. **Forged empty password:** An attacker who retrieves the server\u0027s public key via an unauthenticated `GetEndpoints` call can craft a token where the 4-byte length field equals `serverNonce.length` (32). The server computes `length = 32 - 32 = 0` and calls `isValidUser(username, \"\")`. Any account that accepts an empty password is compromised.\n\n2. **Unconditional replay attack:** Because nonce binding is structurally absent, any captured UserNameIdentityToken ciphertext can be replayed in a different session unconditionally.\n\nThe impact is compounded by a second issue: when the channel uses `SecurityMode=None`, `verifyClientSignature` returns `true` unconditionally (security_policy.ts:697-700), bypassing the channel-level signature check entirely.\n\n---\n\n**Proof of Concept (logic, no exploit code)**\n\n```\n1. GetEndpoints (unauthenticated) \u2192 retrieve server public key and RSA token policy\n2. OpenSecureChannel (SecurityMode=None)\n3. CreateSession\n4. Craft plaintext: [0x20, 0x00, 0x00, 0x00] (readUInt32LE = 32 = serverNonce.length)\n5. RSA-OAEP encrypt with server public key \u2192 256-byte ciphertext\n6. ActivateSession with crafted UserNameIdentityToken\n7. Server decrypts \u2192 length = 32 - 32 = 0 \u2192 password = \"\"\n8. isValidUser(username, \"\") is called\n```\n\nDynamically confirmed: decryption produces `password = \"\"` with no error and no nonce verification.\n\n---\n\n**Suggested Fix**\n\nAfter decrypting the password blob, verify that `buff.slice(4 + passwordLength)` equals `session.nonce` before extracting the password. Reject the token if verification fails.\n\n---\n\nI am following a 90-day responsible disclosure policy. I am happy to provide additional technical details under embargo. Please confirm receipt at your earliest convenience.\n\nReporter: Stanley Tobias\nDiscovery date: 2026-03-23",
"id": "GHSA-mq36-523m-x7vv",
"modified": "2026-08-20T18:35:33Z",
"published": "2026-08-20T18:35:33Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/node-opcua/node-opcua/security/advisories/GHSA-mq36-523m-x7vv"
},
{
"type": "PACKAGE",
"url": "https://github.com/node-opcua/node-opcua"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:L",
"type": "CVSS_V3"
}
],
"summary": "node-opcua missing nonce verification in UserNameIdentityToken authentication"
}
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.