Common Weakness Enumeration

CWE-347

Allowed

Improper 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:43
VLAI
Summary
sm-crypto Affected by Signature Malleability in SM2-DSA
Details

Summary

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

Show details on source website

{
  "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:30
VLAI
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.

Show details on source website

{
  "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:33
VLAI
Summary
jsonwebtoken vulnerable to signature validation bypass due to insecure default algorithm in jwt.verify()
Details

Overview

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.

Show details on source website

{
  "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:06
VLAI
Summary
Message Signature Bypass in openpgp
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.

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

Show details on source website

{
  "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:53
VLAI
Summary
motionEye: LFI → pass‑the‑hash admin → unsafe restore → unauth action exec (RCE)
Details

Summary

A multi‑stage chain in motionEye leads to remote code execution. The chain combines:

  1. Arbitrary file read (LFI) via the picture download endpoint for local motion cameras using absolute paths.
  2. Pass‑the‑hash admin auth due to accepting request signatures computed with password hashes.
  3. Unsafe config restore that extracts attacker‑controlled tarballs into CONF_PATH.
  4. 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.pydownload() (local motion camera branch) - motioneye/motioneye/mediafiles.pyget_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.pyget_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.pyrestore()

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.pypost()

Issue: No authentication decorator is present. It executes <action>_<camera_id> found in CONF_PATH with subprocess.Popen.


Exploit Chain (Detailed)

  1. Create or find a local motion camera id (local motion cameras are required for the vulnerable LFI path).
  2. LFI via picture download:
  3. Request: /picture/<id>/download/<absolute_path>
  4. Example: /picture/1/download/%2Fetc%2Fhosts
  5. Result: Arbitrary file read.
  6. Read admin hash from /etc/motioneye/motion.conf:
  7. Contains @admin_password <SHA1_HASH>.
  8. Pass‑the‑hash admin:
  9. Compute signature for /config/restore?_username=admin using the hash as key.
  10. Admin access is accepted with hash‑based signatures.
  11. Restore malicious tar:
  12. Upload a tar containing lock_<id> (or any action) as an executable.
  13. File is written into CONF_PATH by restore.
  14. Trigger unauth action:
  15. POST /action/<id>/lock
  16. 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>/download is reachable:
  • Unauth if @normal_password is 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

  1. Block absolute paths in get_media_content() and get_media_path().
  2. Remove hash‑based signature acceptance; only accept signatures computed with plaintext passwords.
  3. Harden restore: reject absolute paths, .., symlinks, non‑regular files.
  4. Require authentication on ActionHandler (admin‑only).
Show details on source website

{
  "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:11
VLAI
Summary
Improper Verification of Cryptographic Signature in starkbank-ecdsa
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.

Show details on source website

{
  "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:17
VLAI
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.

Show details on source website

{
  "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:30
VLAI
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.

Show details on source website

{
  "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:31
VLAI
Details

Vulnerability of package name verification being bypassed in the HwIms module. Impact: Successful exploitation of this vulnerability will affect availability.

Show details on source website

{
  "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:22
VLAI
Summary
AEADs/ascon-aead: Plaintext exposed in decrypt_in_place_detached even on tag verification failure
Details

Summary

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).

Show details on source website

{
  "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.