CWE-347
AllowedImproper Verification of Cryptographic Signature
Abstraction: Base · Status: Draft
The product does not verify, or incorrectly verifies, the cryptographic signature for data.
1120 vulnerabilities reference this CWE, most recent first.
GHSA-QV7W-V773-3XQM
Vulnerability from github – Published: 2026-01-21 16:13 – Updated: 2026-01-22 15:43Summary
A signature malleability vulnerability exists in the SM2 signature verification logic of the sm-crypto library. An attacker can derive a new valid signature for a previously signed message from an existing signature.
Credit
This vulnerability was discovered by: - XlabAI Team of Tencent Xuanwu Lab - Atuin Automated Vulnerability Discovery Engine
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "sm-crypto"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.3.14"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-23967"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": true,
"github_reviewed_at": "2026-01-21T16:13:35Z",
"nvd_published_at": "2026-01-22T03:15:47Z",
"severity": "HIGH"
},
"details": "### Summary\n\nA signature malleability vulnerability exists in the SM2 signature verification logic of the sm-crypto library. An attacker can derive a new valid signature for a previously signed message from an existing signature.\n\n### Credit\n\nThis vulnerability was discovered by:\n- XlabAI Team of Tencent Xuanwu Lab\n- Atuin Automated Vulnerability Discovery Engine",
"id": "GHSA-qv7w-v773-3xqm",
"modified": "2026-01-22T15:43:21Z",
"published": "2026-01-21T16:13:35Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/JuneAndGreen/sm-crypto/security/advisories/GHSA-qv7w-v773-3xqm"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23967"
},
{
"type": "PACKAGE",
"url": "https://github.com/JuneAndGreen/sm-crypto"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "sm-crypto Affected by Signature Malleability in SM2-DSA"
}
GHSA-QW5Q-44P2-MFCM
Vulnerability from github – Published: 2022-05-24 16:45 – Updated: 2023-03-24 18:30A vulnerability in the Image Signature Verification feature of Cisco NX-OS Software could allow an authenticated, local attacker with administrator-level credentials to install a malicious software image on an affected device. The vulnerability exists because software digital signatures are not properly verified during CLI command execution. An attacker could exploit this vulnerability to install an unsigned software image on an affected device.
{
"affected": [],
"aliases": [
"CVE-2019-1811"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-05-15T23:29:00Z",
"severity": "HIGH"
},
"details": "A vulnerability in the Image Signature Verification feature of Cisco NX-OS Software could allow an authenticated, local attacker with administrator-level credentials to install a malicious software image on an affected device. The vulnerability exists because software digital signatures are not properly verified during CLI command execution. An attacker could exploit this vulnerability to install an unsigned software image on an affected device.",
"id": "GHSA-qw5q-44p2-mfcm",
"modified": "2023-03-24T18:30:20Z",
"published": "2022-05-24T16:45:55Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-1811"
},
{
"type": "WEB",
"url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20190515-nxos-sisv2"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/108425"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-QWPH-4952-7XR6
Vulnerability from github – Published: 2022-12-22 03:32 – Updated: 2025-02-13 18:33Overview
In versions <=8.5.1 of jsonwebtoken library, lack of algorithm definition and a falsy secret or key in the jwt.verify() function can lead to signature validation bypass due to defaulting to the none algorithm for signature verification.
Am I affected?
You will be affected if all the following are true in the jwt.verify() function:
- a token with no signature is received
- no algorithms are specified
- a falsy (e.g. null, false, undefined) secret or key is passed
How do I fix it?
Update to version 9.0.0 which removes the default support for the none algorithm in the jwt.verify() method.
Will the fix impact my users?
There will be no impact, if you update to version 9.0.0 and you don’t need to allow for the none algorithm. If you need 'none' algorithm, you have to explicitly specify that in jwt.verify() options.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "jsonwebtoken"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "9.0.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-23540"
],
"database_specific": {
"cwe_ids": [
"CWE-287",
"CWE-327",
"CWE-347"
],
"github_reviewed": true,
"github_reviewed_at": "2022-12-22T03:32:59Z",
"nvd_published_at": "2022-12-22T19:15:00Z",
"severity": "MODERATE"
},
"details": "# Overview\n\nIn versions \u003c=8.5.1 of jsonwebtoken library, lack of algorithm definition and a falsy secret or key in the `jwt.verify()` function can lead to signature validation bypass due to defaulting to the `none` algorithm for signature verification.\n\n# Am I affected?\nYou will be affected if all the following are true in the `jwt.verify()` function:\n- a token with no signature is received\n- no algorithms are specified \n- a falsy (e.g. null, false, undefined) secret or key is passed \n\n# How do I fix it?\n \nUpdate to version 9.0.0 which removes the default support for the none algorithm in the `jwt.verify()` method. \n\n# Will the fix impact my users?\n\nThere will be no impact, if you update to version 9.0.0 and you don\u2019t need to allow for the `none` algorithm. If you need \u0027none\u0027 algorithm, you have to explicitly specify that in `jwt.verify()` options.",
"id": "GHSA-qwph-4952-7xr6",
"modified": "2025-02-13T18:33:13Z",
"published": "2022-12-22T03:32:59Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/auth0/node-jsonwebtoken/security/advisories/GHSA-qwph-4952-7xr6"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-23540"
},
{
"type": "WEB",
"url": "https://github.com/auth0/node-jsonwebtoken/commit/e1fa9dcc12054a8681db4e6373da1b30cf7016e3"
},
{
"type": "PACKAGE",
"url": "https://github.com/auth0/node-jsonwebtoken"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20240621-0007"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:H/A:L",
"type": "CVSS_V3"
}
],
"summary": "jsonwebtoken vulnerable to signature validation bypass due to insecure default algorithm in jwt.verify()"
}
GHSA-QWQC-28W3-FWW6
Vulnerability from github – Published: 2019-08-23 21:42 – Updated: 2021-08-17 22:06Versions of openpgp prior to 4.2.0 are vulnerable to Message Signature Bypass. The package fails to verify that a message signature is of type text. This allows an attacker to to construct a message with a signature type that only verifies subpackets without additional input (such as standalone or timestamp). For example, an attacker that captures a standalone signature packet from a victim can construct arbitrary signed messages that would be verified correctly.
Recommendation
Upgrade to version 4.2.0 or later.
If you are upgrading from a version <4.0.0 it is highly recommended to read the High-Level API Changes section of the openpgp 4.0.0 release: https://github.com/openpgpjs/openpgpjs/releases/tag/v4.0.0
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.1.2"
},
"package": {
"ecosystem": "npm",
"name": "openpgp"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.2.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2019-9153"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": true,
"github_reviewed_at": "2019-08-23T21:40:54Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "Versions of `openpgp` prior to 4.2.0 are vulnerable to Message Signature Bypass. The package fails to verify that a message signature is of type `text`. This allows an attacker to to construct a message with a signature type that only verifies subpackets without additional input (such as `standalone` or `timestamp`). For example, an attacker that captures a `standalone` signature packet from a victim can construct arbitrary signed messages that would be verified correctly.\n\n\n## Recommendation\n\nUpgrade to version 4.2.0 or later.\nIf you are upgrading from a version \u003c4.0.0 it is highly recommended to read the `High-Level API Changes` section of the `openpgp` 4.0.0 release: https://github.com/openpgpjs/openpgpjs/releases/tag/v4.0.0",
"id": "GHSA-qwqc-28w3-fww6",
"modified": "2021-08-17T22:06:12Z",
"published": "2019-08-23T21:42:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-9153"
},
{
"type": "WEB",
"url": "https://github.com/openpgpjs/openpgpjs/pull/797/commits/327d3e5392a6f59a4270569d200c7f7a2bfc4cbc"
},
{
"type": "WEB",
"url": "https://github.com/openpgpjs/openpgpjs/pull/816"
},
{
"type": "WEB",
"url": "https://github.com/openpgpjs/openpgpjs/releases/tag/v4.2.0"
},
{
"type": "WEB",
"url": "https://sec-consult.com/en/blog/advisories/multiple-vulnerabilities-in-openpgp-js"
},
{
"type": "WEB",
"url": "https://snyk.io/vuln/SNYK-JS-OPENPGP-460248"
},
{
"type": "WEB",
"url": "https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/Studies/Mailvelope_Extensions/Mailvelope_Extensions_pdf.html#download=1"
},
{
"type": "WEB",
"url": "https://www.npmjs.com/advisories/1160"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/154191/OpenPGP.js-4.2.0-Signature-Bypass-Invalid-Curve-Attack.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Message Signature Bypass in openpgp"
}
GHSA-QXVG-H7Q2-HCXH
Vulnerability from github – Published: 2026-06-23 18:53 – Updated: 2026-06-23 18:53Summary
A multi‑stage chain in motionEye leads to remote code execution. The chain combines:
- Arbitrary file read (LFI) via the picture download endpoint for local motion cameras using absolute paths.
- Pass‑the‑hash admin auth due to accepting request signatures computed with password hashes.
- Unsafe config restore that extracts attacker‑controlled tarballs into
CONF_PATH. - Unauthenticated action execution via
/action/<id>/<action>.
If the normal user password is unset, the chain becomes unauthenticated RCE. If a normal password exists, a normal user can still achieve admin escalation and RCE.
Affected Code (motionEye repo)
1) LFI (absolute path) — picture/<id>/download
Files:
- motioneye/motioneye/handlers/picture.py → download() (local motion camera branch)
- motioneye/motioneye/mediafiles.py → get_media_content()
Issue: get_media_content() only blocks .. and then joins target_dir with path. Absolute paths (e.g. /etc/hosts) bypass the join and are read directly.
2) Pass‑the‑hash admin auth
File: motioneye/motioneye/handlers/base.py → get_current_user()
Issue: The signature check allows signatures computed using the admin password hash (SHA1) as the key. If the hash is leaked (via LFI), admin access can be obtained without the plaintext password.
3) Unsafe restore (tar extraction)
File: motioneye/motioneye/config.py → restore()
Issue: tar zxC CONF_PATH is used on user‑supplied data without sanitizing entries. A crafted tar can drop executable files into CONF_PATH.
4) Unauthenticated action execution
File: motioneye/motioneye/handlers/action.py → post()
Issue: No authentication decorator is present. It executes <action>_<camera_id> found in CONF_PATH with subprocess.Popen.
Exploit Chain (Detailed)
- Create or find a local motion camera id (local motion cameras are required for the vulnerable LFI path).
- LFI via picture download:
- Request:
/picture/<id>/download/<absolute_path> - Example:
/picture/1/download/%2Fetc%2Fhosts - Result: Arbitrary file read.
- Read admin hash from
/etc/motioneye/motion.conf: - Contains
@admin_password <SHA1_HASH>. - Pass‑the‑hash admin:
- Compute signature for
/config/restore?_username=adminusing the hash as key. - Admin access is accepted with hash‑based signatures.
- Restore malicious tar:
- Upload a tar containing
lock_<id>(or any action) as an executable. - File is written into
CONF_PATHby restore. - Trigger unauth action:
- POST
/action/<id>/lock - The server executes the injected file.
Proof of Execution (Observed Output)
In local testing, the injected action created a marker file:
/tmp/meye_rce_ok
Verification command:
docker exec -it motioneye ls -la /tmp | grep meye_rce_ok
Example output:
-rw-r--r-- 1 root root 0 ... /tmp/meye_rce_ok
Preconditions / Requirements
- At least one local motion camera exists (e.g.,
netcam_url,videodevice). picture/<id>/downloadis reachable:- Unauth if
@normal_passwordis empty (default in some installs). - Auth required if normal password is set (attacker needs normal creds).
Impact
- Unauth RCE (normal password unset).
- Authenticated RCE (normal user → admin → RCE).
- Arbitrary file read on server filesystem.
- Full compromise of motionEye process account.
Suggested Fixes
- Block absolute paths in
get_media_content()andget_media_path(). - Remove hash‑based signature acceptance; only accept signatures computed with plaintext passwords.
- Harden restore: reject absolute paths,
.., symlinks, non‑regular files. - Require authentication on
ActionHandler(admin‑only).
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "motioneye"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.44.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-22",
"CWE-269",
"CWE-306",
"CWE-347",
"CWE-434"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-23T18:53:04Z",
"nvd_published_at": null,
"severity": "CRITICAL"
},
"details": "## Summary\nA multi\u2011stage chain in motionEye leads to remote code execution. The chain combines:\n\n1. **Arbitrary file read (LFI)** via the picture download endpoint for **local motion cameras** using absolute paths.\n2. **Pass\u2011the\u2011hash admin auth** due to accepting request signatures computed with password hashes.\n3. **Unsafe config restore** that extracts attacker\u2011controlled tarballs into `CONF_PATH`.\n4. **Unauthenticated action execution** via `/action/\u003cid\u003e/\u003caction\u003e`.\n\nIf the **normal user password is unset**, the chain becomes **unauthenticated RCE**. If a normal password exists, a **normal user** can still achieve **admin escalation and RCE**.\n\n---\n\n## Affected Code (motionEye repo)\n\n### 1) LFI (absolute path) \u2014 `picture/\u003cid\u003e/download`\n**Files:**\n- `motioneye/motioneye/handlers/picture.py` \u2192 `download()` (local motion camera branch)\n- `motioneye/motioneye/mediafiles.py` \u2192 `get_media_content()`\n\n**Issue:** `get_media_content()` only blocks `..` and then joins `target_dir` with `path`. Absolute paths (e.g. `/etc/hosts`) bypass the join and are read directly.\n\n### 2) Pass\u2011the\u2011hash admin auth\n**File:** `motioneye/motioneye/handlers/base.py` \u2192 `get_current_user()`\n\n**Issue:** The signature check allows signatures computed using the **admin password hash** (SHA1) as the key. If the hash is leaked (via LFI), admin access can be obtained without the plaintext password.\n\n### 3) Unsafe restore (tar extraction)\n**File:** `motioneye/motioneye/config.py` \u2192 `restore()`\n\n**Issue:** `tar zxC CONF_PATH` is used on user\u2011supplied data without sanitizing entries. A crafted tar can drop executable files into `CONF_PATH`.\n\n### 4) Unauthenticated action execution\n**File:** `motioneye/motioneye/handlers/action.py` \u2192 `post()`\n\n**Issue:** No authentication decorator is present. It executes `\u003caction\u003e_\u003ccamera_id\u003e` found in `CONF_PATH` with `subprocess.Popen`.\n\n---\n\n## Exploit Chain (Detailed)\n\n1. **Create or find a local motion camera id** (local motion cameras are required for the vulnerable LFI path).\n2. **LFI via picture download**:\n - Request: `/picture/\u003cid\u003e/download/\u003cabsolute_path\u003e`\n - Example: `/picture/1/download/%2Fetc%2Fhosts`\n - Result: Arbitrary file read.\n3. **Read admin hash** from `/etc/motioneye/motion.conf`:\n - Contains `@admin_password \u003cSHA1_HASH\u003e`.\n4. **Pass\u2011the\u2011hash admin**:\n - Compute signature for `/config/restore?_username=admin` using the **hash** as key.\n - Admin access is accepted with hash\u2011based signatures.\n5. **Restore malicious tar**:\n - Upload a tar containing `lock_\u003cid\u003e` (or any action) as an executable.\n - File is written into `CONF_PATH` by restore.\n6. **Trigger unauth action**:\n - POST `/action/\u003cid\u003e/lock`\n - The server executes the injected file.\n\n---\n\n## Proof of Execution (Observed Output)\nIn local testing, the injected action created a marker file:\n\n```\n/tmp/meye_rce_ok\n```\n\nVerification command:\n```\ndocker exec -it motioneye ls -la /tmp | grep meye_rce_ok\n```\nExample output:\n```\n-rw-r--r-- 1 root root 0 ... /tmp/meye_rce_ok\n```\n\n---\n\n## Preconditions / Requirements\n\n- At least **one local motion camera** exists (e.g., `netcam_url`, `videodevice`).\n- `picture/\u003cid\u003e/download` is reachable:\n - **Unauth** if `@normal_password` is empty (default in some installs).\n - **Auth required** if normal password is set (attacker needs normal creds).\n\n---\n\n## Impact\n- **Unauth RCE** (normal password unset).\n- **Authenticated RCE** (normal user \u2192 admin \u2192 RCE).\n- Arbitrary file read on server filesystem.\n- Full compromise of motionEye process account.\n\n---\n\n## Suggested Fixes\n1. **Block absolute paths** in `get_media_content()` and `get_media_path()`.\n2. **Remove hash\u2011based signature acceptance**; only accept signatures computed with plaintext passwords.\n3. **Harden restore**: reject absolute paths, `..`, symlinks, non\u2011regular files.\n4. **Require authentication** on `ActionHandler` (admin\u2011only).",
"id": "GHSA-qxvg-h7q2-hcxh",
"modified": "2026-06-23T18:53:04Z",
"published": "2026-06-23T18:53:04Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/motioneye-project/motioneye/security/advisories/GHSA-qxvg-h7q2-hcxh"
},
{
"type": "PACKAGE",
"url": "https://github.com/motioneye-project/motioneye"
}
],
"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:H",
"type": "CVSS_V3"
}
],
"summary": "motionEye: LFI \u2192 pass\u2011the\u2011hash admin \u2192 unsafe restore \u2192 unauth action exec (RCE)"
}
GHSA-R28H-X6HV-2FQ3
Vulnerability from github – Published: 2021-11-10 20:48 – Updated: 2025-01-20 16:11The verify function in the Stark Bank Java ECDSA library (ecdsa-java) 1.0.0 fails to check that the signature is non-zero, which allows attackers to forge signatures on arbitrary messages.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "com.starkbank.ellipticcurve:starkbank-ecdsa"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.0.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2021-43570"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": true,
"github_reviewed_at": "2021-11-10T18:25:02Z",
"nvd_published_at": "2021-11-09T22:15:00Z",
"severity": "CRITICAL"
},
"details": "The verify function in the Stark Bank Java ECDSA library (ecdsa-java) 1.0.0 fails to check that the signature is non-zero, which allows attackers to forge signatures on arbitrary messages.",
"id": "GHSA-r28h-x6hv-2fq3",
"modified": "2025-01-20T16:11:28Z",
"published": "2021-11-10T20:48:00Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-43570"
},
{
"type": "WEB",
"url": "https://github.com/starkbank/ecdsa-java/pull/16"
},
{
"type": "WEB",
"url": "https://github.com/starkbank/ecdsa-java/commit/ed22e484186d6c66d3686bfe39d01bdbabf219b6"
},
{
"type": "PACKAGE",
"url": "https://github.com/starkbank/ecdsa-java"
},
{
"type": "WEB",
"url": "https://github.com/starkbank/ecdsa-java/releases/tag/v1.0.1"
},
{
"type": "WEB",
"url": "https://research.nccgroup.com/2021/11/08/technical-advisory-arbitrary-signature-forgery-in-stark-bank-ecdsa-libraries"
}
],
"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:H",
"type": "CVSS_V3"
}
],
"summary": "Improper Verification of Cryptographic Signature in starkbank-ecdsa"
}
GHSA-R2F7-JGHR-R7X9
Vulnerability from github – Published: 2022-05-24 19:17 – Updated: 2022-05-24 19:17It is possible for an attacker to manipulate the timestamp of signed documents. All versions of Apache OpenOffice up to 4.1.10 are affected. Users are advised to update to version 4.1.11. See CVE-2021-25634 for the LibreOffice advisory.
{
"affected": [],
"aliases": [
"CVE-2021-41831"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-10-11T08:15:00Z",
"severity": "MODERATE"
},
"details": "It is possible for an attacker to manipulate the timestamp of signed documents. All versions of Apache OpenOffice up to 4.1.10 are affected. Users are advised to update to version 4.1.11. See CVE-2021-25634 for the LibreOffice advisory.",
"id": "GHSA-r2f7-jghr-r7x9",
"modified": "2022-05-24T19:17:14Z",
"published": "2022-05-24T19:17:14Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-41831"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/ra74d5057cdc781a36286a83e8bcbc90a7678f030ae73339c35dfc4f9%40%3Cusers.openoffice.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rc5c277cb83e335696657c5f27da1d1e2b5cb48346b0b55415a233757@%3Cannounce.apache.org%3E"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-R2G9-49RQ-6P4C
Vulnerability from github – Published: 2022-05-01 02:05 – Updated: 2024-02-08 21:30Cisco 7940/7960 Voice over IP (VoIP) phones do not properly check the Call-ID, branch, and tag values in a NOTIFY message to verify a subscription, which allows remote attackers to spoof messages such as the "Messages waiting" message.
{
"affected": [],
"aliases": [
"CVE-2005-2181"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2005-07-11T04:00:00Z",
"severity": "MODERATE"
},
"details": "Cisco 7940/7960 Voice over IP (VoIP) phones do not properly check the Call-ID, branch, and tag values in a NOTIFY message to verify a subscription, which allows remote attackers to spoof messages such as the \"Messages waiting\" message.",
"id": "GHSA-r2g9-49rq-6p4c",
"modified": "2024-02-08T21:30:31Z",
"published": "2022-05-01T02:05:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2005-2181"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/21260"
},
{
"type": "WEB",
"url": "http://marc.info/?l=bugtraq\u0026m=112067698624686\u0026w=2"
},
{
"type": "WEB",
"url": "http://pentest.tele-consulting.com/advisories/05_07_06_voip-phones.txt"
},
{
"type": "WEB",
"url": "http://www.securitytracker.com/alerts/2005/Jul/1014406.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-R382-73HV-R5J2
Vulnerability from github – Published: 2024-04-08 09:31 – Updated: 2024-08-01 15:31Vulnerability of package name verification being bypassed in the HwIms module. Impact: Successful exploitation of this vulnerability will affect availability.
{
"affected": [],
"aliases": [
"CVE-2023-52538"
],
"database_specific": {
"cwe_ids": [
"CWE-347",
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-04-08T09:15:08Z",
"severity": "CRITICAL"
},
"details": "Vulnerability of package name verification being bypassed in the HwIms module.\nImpact: Successful exploitation of this vulnerability will affect availability.",
"id": "GHSA-r382-73hv-r5j2",
"modified": "2024-08-01T15:31:37Z",
"published": "2024-04-08T09:31:13Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52538"
},
{
"type": "WEB",
"url": "https://consumer.huawei.com/en/support/bulletin/2024/3"
},
{
"type": "WEB",
"url": "https://device.harmonyos.com/en/docs/security/update/security-bulletins-202403-0000001667644725"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-R38M-44FW-H886
Vulnerability from github – Published: 2025-03-03 20:22 – Updated: 2025-03-03 20:22Summary
In decrypt_in_place_detached, the decrypted ciphertext (which is the correct ciphertext) is exposed even if the tag is incorrect.
Details
This is because in decrypt_inplace in asconcore.rs, tag verification causes an error to be returned with the plaintext contents still in buffer. The root cause of this vulnerability is similar to https://github.com/RustCrypto/AEADs/security/advisories/GHSA-423w-p2w9-r7vq
PoC
use ascon_aead::Tag;
use ascon_aead::{Ascon128, Key, Nonce};
use ascon_aead::aead::{AeadInPlace, KeyInit};
fn main() {
let key = Key::<Ascon128>::from_slice(b"very secret key.");
let cipher = Ascon128::new(key);
let nonce = Nonce::<Ascon128>::from_slice(b"unique nonce 012"); // 128-bits; unique per message
let mut buffer: Vec<u8> = Vec::new(); // Buffer needs 16-bytes overhead for authentication tag
buffer.extend_from_slice(b"plaintext message");
// Encrypt `buffer` in-place detached, replacing the plaintext contents with ciphertext
cipher.encrypt_in_place_detached(nonce, b"", &mut buffer).expect("encryption failure!");
// Decrypt `buffer` in-place with the wrong tag, ignoring the decryption error
let _ = cipher.decrypt_in_place_detached(nonce, b"", &mut buffer, Tag::<Ascon128>::from_slice(b"\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"));
assert_eq!(&buffer, b"plaintext message");
}
Impact
If a program continues to use the result of decrypt_in_place_detached after a decryption failure, the result will be unauthenticated. This may permit some forms of chosen ciphertext attacks (CCAs).
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.4.2"
},
"package": {
"ecosystem": "crates.io",
"name": "ascon_aead"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.4.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-27498"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": true,
"github_reviewed_at": "2025-03-03T20:22:19Z",
"nvd_published_at": "2025-03-03T17:15:16Z",
"severity": "MODERATE"
},
"details": "### Summary\nIn `decrypt_in_place_detached`, the decrypted ciphertext (which is the correct ciphertext) is exposed even if the tag is incorrect.\n\n### Details\nThis is because in [decrypt_inplace](https://github.com/RustCrypto/AEADs/blob/8cda109f1128c4c7953a0bb0f53e1056d537e462/ascon-aead/src/asconcore.rs#L350-L364) in asconcore.rs, tag verification causes an error to be returned with the plaintext contents still in `buffer`. The root cause of this vulnerability is similar to https://github.com/RustCrypto/AEADs/security/advisories/GHSA-423w-p2w9-r7vq\n\n### PoC\n```rust\nuse ascon_aead::Tag;\nuse ascon_aead::{Ascon128, Key, Nonce};\nuse ascon_aead::aead::{AeadInPlace, KeyInit};\n\nfn main() {\n\n let key = Key::\u003cAscon128\u003e::from_slice(b\"very secret key.\");\n let cipher = Ascon128::new(key);\n\n let nonce = Nonce::\u003cAscon128\u003e::from_slice(b\"unique nonce 012\"); // 128-bits; unique per message\n\n let mut buffer: Vec\u003cu8\u003e = Vec::new(); // Buffer needs 16-bytes overhead for authentication tag\n buffer.extend_from_slice(b\"plaintext message\");\n\n // Encrypt `buffer` in-place detached, replacing the plaintext contents with ciphertext\n cipher.encrypt_in_place_detached(nonce, b\"\", \u0026mut buffer).expect(\"encryption failure!\");\n \n // Decrypt `buffer` in-place with the wrong tag, ignoring the decryption error\n let _ = cipher.decrypt_in_place_detached(nonce, b\"\", \u0026mut buffer, Tag::\u003cAscon128\u003e::from_slice(b\"\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\"));\n\n assert_eq!(\u0026buffer, b\"plaintext message\");\n}\n```\n### Impact\nIf a program continues to use the result of `decrypt_in_place_detached` after a decryption failure, the result will be unauthenticated. This may permit some forms of chosen ciphertext attacks (CCAs).",
"id": "GHSA-r38m-44fw-h886",
"modified": "2025-03-03T20:22:19Z",
"published": "2025-03-03T20:22:19Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/RustCrypto/AEADs/security/advisories/GHSA-r38m-44fw-h886"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-27498"
},
{
"type": "WEB",
"url": "https://github.com/RustCrypto/AEADs/commit/d1d749ba57e38e65b0e037cd744d0b17f7254037"
},
{
"type": "PACKAGE",
"url": "https://github.com/RustCrypto/AEADs"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:L/AC:H/AT:N/PR:N/UI:A/VC:L/VI:H/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "AEADs/ascon-aead: Plaintext exposed in decrypt_in_place_detached even on tag verification failure"
}
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.