CWE-494
AllowedDownload of Code Without Integrity Check
Abstraction: Base · Status: Draft
The product downloads source code or an executable from a remote location and executes the code without sufficiently verifying the origin and integrity of the code.
364 vulnerabilities reference this CWE, most recent first.
GHSA-662P-52HX-CMH2
Vulnerability from github – Published: 2026-10-09 17:08 – Updated: 2026-10-09 17:08Summary
The self-upgrade downloads the release binary and its checksum (*.tar.gz and *.tar.gz.digest)
through the SAME endpoint (version.GetUrl(), which is github_proxy or, by default, the project's
cloud.nginxui.com mirror), and verifies the binary ONLY by comparing it to that digest:
digestFileContent == DigestSHA512(tarName). Both the binary and the digest come from the same
origin, and there is NO cryptographic signature / public-key verification. The downloaded binary then
replaces the running executable (selfupdate.CommitBinary) and the process restarts, so the binary
runs as the nginx-ui user (typically root).
Because integrity rests only on a digest fetched from the same place as the binary, anyone who
controls that download path can substitute a malicious binary plus a matching digest and obtain code
execution as root on the next upgrade. Additionally, the github_proxy setting accepts http://
URLs, so the binary+digest can be fetched over cleartext.
Affected code
internal/version/url.go GetUrl(path)=<github_proxy or cloud.nginxui.com>/<path>— used for BOTH the binary and the digest.internal/upgrader/upgrade.go DownloadLatestRelease: digest URL and binary URL are both wrapped withGetUrl(), fetched, and checked withdigestFileContent == DigestSHA512(tarName). No signature verification anywhere ininternal/upgrader/.selfupdate.CommitBinarythen replaces the running binary; the process restarts.settings/http.go:GithubProxyaccepts any URL (binding:"omitempty,url"), includinghttp://.
Attack scenarios
A. Compromised mirror / CDN (primary). By default the binary+digest are routed through
cloud.nginxui.com. If that mirror (or the GitHub release CDN) is compromised — or DNS/BGP is
hijacked — it can serve a malicious binary + matching digest to EVERY instance that upgrades,
yielding root RCE fleet-wide. No nginx-ui credentials are needed by the attacker (they control the
mirror). A binary signature would prevent this.
B. HTTP proxy + on-path MITM. Operators behind GitHub-restricted networks are the intended users of
github_proxy; the field accepts http://, so the binary+digest are fetched in cleartext. An
attacker on the network path (rogue gateway / ARP spoofing / malicious Wi-Fi / compromised router)
substitutes a malicious binary + matching digest -> root RCE on the next upgrade.
C. (mechanism demonstration) An authenticated user sets github_proxy to a server they control and
triggers the upgrade. This is how the PoC below proves the mechanism; note that in nginx-ui (no
role separation) such a user is admin-equivalent, so on its own this path is self-inflicted — it
is included only to demonstrate that an unsigned attacker binary is accepted and executed.
Proof of Concept (live, official image uozi/nginx-ui:2.3.11) — mechanism
An attacker HTTP server serves any *.tar.gz -> a malicious tarball (whose nginx-ui is a script
that writes a marker as whoever runs it) and any *.digest -> the SHA-512 of that tarball.
1. Set the download origin to the attacker server (here via github_proxy; in scenarios A/B this is
instead a compromised mirror / MITM): POST /api/settings with
http.github_proxy = http://ATTACKER:8890 -> 200. The field accepts the http URL.
2. Trigger the upgrade: WS GET /api/upgrade/perform, send {"channel":"stable"}.
3. Observed:
- The attacker server received BOTH
GET /https://github.com/.../nginx-ui-linux-64.tar.gz.digest and .../nginx-ui-linux-64.tar.gz
(over cleartext http).
- WS: "Downloading latest release" -> "Performing core upgrade" -> restart. The attacker tarball's
digest matched (attacker supplied both) -> integrity check PASSED, no signature checked.
- Inside the container: /tmp/UPGRADE_PWNED = UPGRADE_RCE_EXECUTED uid=0 -> the malicious binary
replaced nginx-ui and EXECUTED AS ROOT.
Impact
Root code execution on upgrade. Realistically reached by compromising the trusted download source (mirror/CDN, scenario A — fleet-wide) or by MITM of a cleartext http proxy (scenario B). A cryptographic signature on the release binary would prevent all of these.
Honest scope / caveats
- Live-verified: the integrity-bypass MECHANISM — an unsigned binary plus a same-origin digest is accepted and executed as root, and the binary+digest are fetched over cleartext http when an http proxy is configured. This was demonstrated via scenario C (attacker-controlled proxy).
- NOT staged (threat-model assumptions, not PoC artifacts): actually compromising
cloud.nginxui.com/ the GitHub CDN (scenario A), and performing a real on-path MITM intercept (scenario B). These are standard attacker capabilities, marked here as analysis. - The upgrade is operator-triggered (UI:R). The default flow uses HTTPS to
cloud.nginxui.com+GitHub plus the digest, so this is not "zero integrity" — the gap is the absence of a signature, which matters when the source is compromised or the transport is cleartext (http proxy).
Suggested fix
Verify the release binary against a cryptographic signature with a public key pinned in the nginx-ui
binary (or a digest fetched over an independent, pinned channel), not a digest from the same origin
as the binary. Reject http:// for github_proxy (require https). Consider treating github_proxy
as a protected setting.
Dedup / novelty
Distinct from CVE-2026-42238 (unauthenticated backup-restore RCE) and CVE-2026-33026 (backup tampering); this is the self-UPGRADE binary path. No existing nginx-ui CVE/GHSA covers upgrade integrity (checked osv.dev and the GitHub advisory database). Appears novel.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/0xJacky/Nginx-UI"
},
"ranges": [
{
"events": [
{
"introduced": "1.9.10-0.20250517140552-daee3ac7ade1"
},
{
"fixed": "1.9.10-0.20260728114330-580585516dd8"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-107812"
],
"database_specific": {
"cwe_ids": [
"CWE-494"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-09T17:08:21Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "## Summary\nThe self-upgrade downloads the release binary and its checksum (`*.tar.gz` and `*.tar.gz.digest`)\nthrough the SAME endpoint (`version.GetUrl()`, which is `github_proxy` or, by default, the project\u0027s\n`cloud.nginxui.com` mirror), and verifies the binary ONLY by comparing it to that digest:\n`digestFileContent == DigestSHA512(tarName)`. Both the binary and the digest come from the same\norigin, and there is NO cryptographic signature / public-key verification. The downloaded binary then\nreplaces the running executable (`selfupdate.CommitBinary`) and the process restarts, so the binary\nruns as the nginx-ui user (typically root).\n\nBecause integrity rests only on a digest fetched from the same place as the binary, anyone who\ncontrols that download path can substitute a malicious binary plus a matching digest and obtain code\nexecution as root on the next upgrade. Additionally, the `github_proxy` setting accepts `http://`\nURLs, so the binary+digest can be fetched over cleartext.\n\n## Affected code\n- `internal/version/url.go GetUrl(path)` = `\u003cgithub_proxy or cloud.nginxui.com\u003e/\u003cpath\u003e` \u2014 used for\n BOTH the binary and the digest.\n- `internal/upgrader/upgrade.go DownloadLatestRelease`: digest URL and binary URL are both wrapped\n with `GetUrl()`, fetched, and checked with `digestFileContent == DigestSHA512(tarName)`. No\n signature verification anywhere in `internal/upgrader/`.\n- `selfupdate.CommitBinary` then replaces the running binary; the process restarts.\n- `settings/http.go`: `GithubProxy` accepts any URL (`binding:\"omitempty,url\"`), including `http://`.\n\n## Attack scenarios\nA. Compromised mirror / CDN (primary). By default the binary+digest are routed through\n `cloud.nginxui.com`. If that mirror (or the GitHub release CDN) is compromised \u2014 or DNS/BGP is\n hijacked \u2014 it can serve a malicious binary + matching digest to EVERY instance that upgrades,\n yielding root RCE fleet-wide. No nginx-ui credentials are needed by the attacker (they control the\n mirror). A binary signature would prevent this.\nB. HTTP proxy + on-path MITM. Operators behind GitHub-restricted networks are the intended users of\n `github_proxy`; the field accepts `http://`, so the binary+digest are fetched in cleartext. An\n attacker on the network path (rogue gateway / ARP spoofing / malicious Wi-Fi / compromised router)\n substitutes a malicious binary + matching digest -\u003e root RCE on the next upgrade.\nC. (mechanism demonstration) An authenticated user sets `github_proxy` to a server they control and\n triggers the upgrade. This is how the PoC below proves the mechanism; note that in nginx-ui (no\n role separation) such a user is admin-equivalent, so on its own this path is self-inflicted \u2014 it\n is included only to demonstrate that an unsigned attacker binary is accepted and executed.\n\n## Proof of Concept (live, official image uozi/nginx-ui:2.3.11) \u2014 mechanism\nAn attacker HTTP server serves any `*.tar.gz` -\u003e a malicious tarball (whose `nginx-ui` is a script\nthat writes a marker as whoever runs it) and any `*.digest` -\u003e the SHA-512 of that tarball.\n1. Set the download origin to the attacker server (here via `github_proxy`; in scenarios A/B this is\n instead a compromised mirror / MITM): `POST /api/settings` with\n `http.github_proxy = http://ATTACKER:8890` -\u003e 200. The field accepts the http URL.\n2. Trigger the upgrade: WS `GET /api/upgrade/perform`, send `{\"channel\":\"stable\"}`.\n3. Observed:\n - The attacker server received BOTH\n `GET /https://github.com/.../nginx-ui-linux-64.tar.gz.digest` and `.../nginx-ui-linux-64.tar.gz`\n (over cleartext http).\n - WS: \"Downloading latest release\" -\u003e \"Performing core upgrade\" -\u003e restart. The attacker tarball\u0027s\n digest matched (attacker supplied both) -\u003e integrity check PASSED, no signature checked.\n - Inside the container: `/tmp/UPGRADE_PWNED` = `UPGRADE_RCE_EXECUTED uid=0` -\u003e the malicious binary\n replaced nginx-ui and EXECUTED AS ROOT.\n\n## Impact\nRoot code execution on upgrade. Realistically reached by compromising the trusted download source\n(mirror/CDN, scenario A \u2014 fleet-wide) or by MITM of a cleartext http proxy (scenario B). A\ncryptographic signature on the release binary would prevent all of these.\n\n## Honest scope / caveats\n- Live-verified: the integrity-bypass MECHANISM \u2014 an unsigned binary plus a same-origin digest is\n accepted and executed as root, and the binary+digest are fetched over cleartext http when an http\n proxy is configured. This was demonstrated via scenario C (attacker-controlled proxy).\n- NOT staged (threat-model assumptions, not PoC artifacts): actually compromising `cloud.nginxui.com`\n / the GitHub CDN (scenario A), and performing a real on-path MITM intercept (scenario B). These are\n standard attacker capabilities, marked here as analysis.\n- The upgrade is operator-triggered (UI:R). The default flow uses HTTPS to `cloud.nginxui.com`+GitHub\n plus the digest, so this is not \"zero integrity\" \u2014 the gap is the absence of a signature, which\n matters when the source is compromised or the transport is cleartext (http proxy).\n\n## Suggested fix\nVerify the release binary against a cryptographic signature with a public key pinned in the nginx-ui\nbinary (or a digest fetched over an independent, pinned channel), not a digest from the same origin\nas the binary. Reject `http://` for `github_proxy` (require https). Consider treating `github_proxy`\nas a protected setting.\n\n## Dedup / novelty\nDistinct from CVE-2026-42238 (unauthenticated backup-restore RCE) and CVE-2026-33026 (backup\ntampering); this is the self-UPGRADE binary path. No existing nginx-ui CVE/GHSA covers upgrade\nintegrity (checked osv.dev and the GitHub advisory database). Appears novel.",
"id": "GHSA-662p-52hx-cmh2",
"modified": "2026-10-09T17:08:21Z",
"published": "2026-10-09T17:08:21Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/0xJacky/nginx-ui/security/advisories/GHSA-662p-52hx-cmh2"
},
{
"type": "WEB",
"url": "https://github.com/0xJacky/nginx-ui/commit/580585516dd87a8b176bcdac258db70c3b64b7ec"
},
{
"type": "PACKAGE",
"url": "https://github.com/0xJacky/nginx-ui"
},
{
"type": "WEB",
"url": "https://github.com/0xJacky/nginx-ui/releases/tag/v2.5.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Nginx UI: Self-upgrade runs an unsigned binary verified only by a same-origin digest \u2192 RCE via a compromised mirror or MITM"
}
GHSA-6662-6W2G-G564
Vulnerability from github – Published: 2022-12-20 21:30 – Updated: 2025-04-17 15:32An exploitable firmware modification vulnerability was discovered on the Netgear WNR2000v1 router. An attacker can conduct a MITM (Man-in-the-Middle) attack to modify the user-uploaded firmware image and bypass the CRC check, allowing attackers to execute arbitrary code or cause a Denial of Service (DoS). This affects v1.2.3.7 and earlier.
{
"affected": [],
"aliases": [
"CVE-2022-46423"
],
"database_specific": {
"cwe_ids": [
"CWE-494"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-12-20T20:15:00Z",
"severity": "HIGH"
},
"details": "An exploitable firmware modification vulnerability was discovered on the Netgear WNR2000v1 router. An attacker can conduct a MITM (Man-in-the-Middle) attack to modify the user-uploaded firmware image and bypass the CRC check, allowing attackers to execute arbitrary code or cause a Denial of Service (DoS). This affects v1.2.3.7 and earlier.",
"id": "GHSA-6662-6w2g-g564",
"modified": "2025-04-17T15:32:31Z",
"published": "2022-12-20T21:30:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-46423"
},
{
"type": "WEB",
"url": "https://hackmd.io/%40slASVrz_SrW7NQCsunofeA/BktKl8ZDo"
},
{
"type": "WEB",
"url": "https://hackmd.io/@slASVrz_SrW7NQCsunofeA/BktKl8ZDo"
},
{
"type": "WEB",
"url": "https://www.netgear.com/about/security"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-678V-QCHW-37JR
Vulnerability from github – Published: 2022-05-19 00:00 – Updated: 2022-05-28 00:00The Zoom Client for Meetings for Windows before version 5.10.0 and Zoom Rooms for Conference Room for Windows before version 5.10.0, fails to properly check the installation version during the update process. This issue could be used in a more sophisticated attack to trick a user into downgrading their Zoom client to a less secure version.
{
"affected": [],
"aliases": [
"CVE-2022-22786"
],
"database_specific": {
"cwe_ids": [
"CWE-494"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-05-18T16:15:00Z",
"severity": "HIGH"
},
"details": "The Zoom Client for Meetings for Windows before version 5.10.0 and Zoom Rooms for Conference Room for Windows before version 5.10.0, fails to properly check the installation version during the update process. This issue could be used in a more sophisticated attack to trick a user into downgrading their Zoom client to a less secure version.",
"id": "GHSA-678v-qchw-37jr",
"modified": "2022-05-28T00:00:26Z",
"published": "2022-05-19T00:00:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-22786"
},
{
"type": "WEB",
"url": "https://explore.zoom.us/en/trust/security/security-bulletin"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-67GM-Q459-3C6J
Vulnerability from github – Published: 2025-12-08 09:30 – Updated: 2025-12-08 09:30Denial of service (DoS) vulnerability in the office service. Impact: Successful exploitation of this vulnerability may affect availability.
{
"affected": [],
"aliases": [
"CVE-2025-66331"
],
"database_specific": {
"cwe_ids": [
"CWE-494"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-12-08T09:15:47Z",
"severity": "LOW"
},
"details": "Denial of service (DoS) vulnerability in the office service. Impact: Successful exploitation of this vulnerability may affect availability.",
"id": "GHSA-67gm-q459-3c6j",
"modified": "2025-12-08T09:30:19Z",
"published": "2025-12-08T09:30:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-66331"
},
{
"type": "WEB",
"url": "https://consumer.huawei.com/en/support/bulletin/2025/12"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-689V-W733-WRV5
Vulnerability from github – Published: 2023-12-05 12:30 – Updated: 2023-12-05 12:30Multiple data integrity vulnerabilities exist in the package hash checking functionality of Buildroot 2023.08.1 and Buildroot dev commit 622698d7847. A specially crafted man-in-the-middle attack can lead to arbitrary command execution in the builder.This vulnerability is related to the aufs package.
{
"affected": [],
"aliases": [
"CVE-2023-45838"
],
"database_specific": {
"cwe_ids": [
"CWE-494"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-12-05T12:15:43Z",
"severity": "HIGH"
},
"details": "Multiple data integrity vulnerabilities exist in the package hash checking functionality of Buildroot 2023.08.1 and Buildroot dev commit 622698d7847. A specially crafted man-in-the-middle attack can lead to arbitrary command execution in the builder.This vulnerability is related to the `aufs` package.",
"id": "GHSA-689v-w733-wrv5",
"modified": "2023-12-05T12:30:45Z",
"published": "2023-12-05T12:30:45Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-45838"
},
{
"type": "WEB",
"url": "https://talosintelligence.com/vulnerability_reports/TALOS-2023-1844"
},
{
"type": "WEB",
"url": "https://www.talosintelligence.com/vulnerability_reports/TALOS-2023-1844"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2023/12/11/1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-689X-PHC2-9P4M
Vulnerability from github – Published: 2022-01-05 00:00 – Updated: 2025-10-22 00:32A download of code without integrity check vulnerability in the "execute restore src-vis" command of FortiOS before 7.0.3 may allow a local authenticated attacker to download arbitrary files on the device via specially crafted update packages.
{
"affected": [],
"aliases": [
"CVE-2021-44168"
],
"database_specific": {
"cwe_ids": [
"CWE-494"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-01-04T13:15:00Z",
"severity": "HIGH"
},
"details": "A download of code without integrity check vulnerability in the \"execute restore src-vis\" command of FortiOS before 7.0.3 may allow a local authenticated attacker to download arbitrary files on the device via specially crafted update packages.",
"id": "GHSA-689x-phc2-9p4m",
"modified": "2025-10-22T00:32:27Z",
"published": "2022-01-05T00:00:59Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-44168"
},
{
"type": "WEB",
"url": "https://fortiguard.com/psirt/FG-IR-21-201"
},
{
"type": "WEB",
"url": "https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2021-44168"
}
],
"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"
}
]
}
GHSA-6954-GGJW-F22G
Vulnerability from github – Published: 2025-10-16 21:31 – Updated: 2025-10-16 21:31The ConnectWise Automate Agent does not fully verify the authenticity of files downloaded from the server, such as updates, dependencies, and integrations. This creates a risk where an on-path attacker could perform a man-in-the-middle attack and substitute malicious files for legitimate ones by impersonating a legitimate server. This risk is mitigated when HTTPS is enforced and is related to CVE-2025-11492.
{
"affected": [],
"aliases": [
"CVE-2025-11493"
],
"database_specific": {
"cwe_ids": [
"CWE-494"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-16T19:15:32Z",
"severity": "HIGH"
},
"details": "The ConnectWise Automate Agent does not fully verify the authenticity of files downloaded from the server, such as updates, dependencies, and integrations. This creates a risk where an on-path attacker could perform a man-in-the-middle attack and substitute malicious files for legitimate ones by impersonating a legitimate server. This risk is mitigated when HTTPS is enforced and is related to CVE-2025-11492.",
"id": "GHSA-6954-ggjw-f22g",
"modified": "2025-10-16T21:31:15Z",
"published": "2025-10-16T21:31:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-11493"
},
{
"type": "WEB",
"url": "https://www.connectwise.com/company/trust/security-bulletins/connectwise-automate-2025.9-security-fix"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-6FPF-RGCX-JMRX
Vulnerability from github – Published: 2023-02-02 15:30 – Updated: 2025-03-26 21:30An exploitable firmware modification vulnerability was discovered in WNR612v2 Wireless Routers firmware version 1.0.0.3 and earlier. The data integrity of the uploaded firmware image is ensured with a fixed checksum number. Therefore, an attacker can conduct a MITM attack to modify the user-uploaded firmware image and bypass the checksum verification.
{
"affected": [],
"aliases": [
"CVE-2023-23110"
],
"database_specific": {
"cwe_ids": [
"CWE-494"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-02-02T15:17:00Z",
"severity": "HIGH"
},
"details": "An exploitable firmware modification vulnerability was discovered in WNR612v2 Wireless Routers firmware version 1.0.0.3 and earlier. The data integrity of the uploaded firmware image is ensured with a fixed checksum number. Therefore, an attacker can conduct a MITM attack to modify the user-uploaded firmware image and bypass the checksum verification.",
"id": "GHSA-6fpf-rgcx-jmrx",
"modified": "2025-03-26T21:30:34Z",
"published": "2023-02-02T15:30:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-23110"
},
{
"type": "WEB",
"url": "https://hackmd.io/%40slASVrz_SrW7NQCsunofeA/BkBPIeGco"
},
{
"type": "WEB",
"url": "https://hackmd.io/%40slASVrz_SrW7NQCsunofeA/H1lIcXbco"
},
{
"type": "WEB",
"url": "https://hackmd.io/%40slASVrz_SrW7NQCsunofeA/HyZRxmb9s"
},
{
"type": "WEB",
"url": "https://hackmd.io/%40slASVrz_SrW7NQCsunofeA/S1BNhbWqi"
},
{
"type": "WEB",
"url": "https://hackmd.io/%40slASVrz_SrW7NQCsunofeA/S1qWglM5o"
},
{
"type": "WEB",
"url": "https://hackmd.io/%40slASVrz_SrW7NQCsunofeA/S1t47Ebqj"
},
{
"type": "WEB",
"url": "https://hackmd.io/%40slASVrz_SrW7NQCsunofeA/SJCGkb-9o"
},
{
"type": "WEB",
"url": "https://hackmd.io/%40slASVrz_SrW7NQCsunofeA/r1Z4BX-5i"
},
{
"type": "WEB",
"url": "https://hackmd.io/%40slASVrz_SrW7NQCsunofeA/ryjVZz-5s"
},
{
"type": "WEB",
"url": "https://hackmd.io/@slASVrz_SrW7NQCsunofeA/SJCGkb-9o"
},
{
"type": "WEB",
"url": "https://www.netgear.com/about/security"
}
],
"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:H",
"type": "CVSS_V3"
}
]
}
GHSA-6PFP-2FQC-3JH4
Vulnerability from github – Published: 2026-03-02 09:30 – Updated: 2026-03-02 09:30IDExpert Windows Logon Agent developed by Changing has a Remote Code Execution vulnerability, allowing unauthenticated remote attackers to force the system to download arbitrary DLL files from a remote source and execute them.
{
"affected": [],
"aliases": [
"CVE-2026-3000"
],
"database_specific": {
"cwe_ids": [
"CWE-494"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-02T07:16:23Z",
"severity": "CRITICAL"
},
"details": "IDExpert Windows Logon Agent developed by Changing has a Remote Code Execution vulnerability, allowing unauthenticated remote attackers to force the system to download arbitrary DLL files from a remote source and execute them.",
"id": "GHSA-6pfp-2fqc-3jh4",
"modified": "2026-03-02T09:30:30Z",
"published": "2026-03-02T09:30:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-3000"
},
{
"type": "WEB",
"url": "https://www.changingtec.com/news_detail.jsp?item_id=348"
},
{
"type": "WEB",
"url": "https://www.twcert.org.tw/en/cp-139-10741-daed4-2.html"
},
{
"type": "WEB",
"url": "https://www.twcert.org.tw/tw/cp-132-10740-b2eb2-1.html"
}
],
"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"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/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"
}
]
}
GHSA-6QW7-34QQ-R69V
Vulnerability from github – Published: 2026-05-28 21:32 – Updated: 2026-05-28 21:32A firmware update mechanism in the affected charging controller fails to validate the authenticity of firmware packages delivered through the device's management interface. Because cryptographic signatures are not verified, an attacker with the ability to interfere with or impersonate the management channel could cause the device to install an unauthorized firmware package. This condition could allow execution of unauthorized code with high privileges on the device.
{
"affected": [],
"aliases": [
"CVE-2026-9037"
],
"database_specific": {
"cwe_ids": [
"CWE-494"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-28T20:16:27Z",
"severity": "CRITICAL"
},
"details": "A firmware update mechanism in the affected charging controller fails to validate the authenticity of firmware packages delivered through the device\u0027s management interface. Because cryptographic signatures are not verified, an attacker with the ability to interfere with or impersonate the management channel could cause the device to install an unauthorized firmware package. This condition could allow execution of unauthorized code with high privileges on the device.",
"id": "GHSA-6qw7-34qq-r69v",
"modified": "2026-05-28T21:32:04Z",
"published": "2026-05-28T21:32:04Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-9037"
},
{
"type": "WEB",
"url": "https://www.cisa.gov/news-events/ics-advisories/icsa-26-148-08"
}
],
"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: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"
}
]
}
Mitigation MIT-42
Perform proper forward and reverse DNS lookups to detect DNS spoofing.
Mitigation
- Encrypt the code with a reliable encryption scheme before transmitting.
- This will only be a partial solution, since it will not detect DNS spoofing and it will not prevent your code from being modified on the hosting site.
Mitigation MIT-4
Strategy: Libraries or Frameworks
- Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid [REF-1482].
- Speficially, it may be helpful to use tools or frameworks to perform integrity checking on the transmitted code.
- When providing the code that is to be downloaded, such as for automatic updates of the software, then use cryptographic signatures for the code and modify the download clients to verify the signatures. Ensure that the implementation does not contain CWE-295, CWE-320, CWE-347, and related weaknesses.
- Use code signing technologies such as Authenticode. See references [REF-454] [REF-455] [REF-456].
Mitigation MIT-17
Strategy: Environment Hardening
Run your code using the lowest privileges that are required to accomplish the necessary tasks [REF-76]. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations.
Mitigation MIT-22
Strategy: Sandbox or Jail
- Run the code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which files can be accessed in a particular directory or which commands can be executed by the software.
- OS-level examples include the Unix chroot jail, AppArmor, and SELinux. In general, managed code may provide some protection. For example, java.io.FilePermission in the Java SecurityManager allows the software to specify restrictions on file operations.
- This may not be a feasible solution, and it only limits the impact to the operating system; the rest of the application may still be subject to compromise.
- Be careful to avoid CWE-243 and other weaknesses related to jails.
CAPEC-184: Software Integrity Attack
An attacker initiates a series of events designed to cause a user, program, server, or device to perform actions which undermine the integrity of software code, device data structures, or device firmware, achieving the modification of the target's integrity to achieve an insecure state.
CAPEC-185: Malicious Software Download
An attacker uses deceptive methods to cause a user or an automated process to download and install dangerous code that originates from an attacker controlled source. There are several variations to this strategy of attack.
CAPEC-186: Malicious Software Update
An adversary uses deceptive methods to cause a user or an automated process to download and install dangerous code believed to be a valid update that originates from an adversary controlled source.
CAPEC-187: Malicious Automated Software Update via Redirection
An attacker exploits two layers of weaknesses in server or client software for automated update mechanisms to undermine the integrity of the target code-base. The first weakness involves a failure to properly authenticate a server as a source of update or patch content. This type of weakness typically results from authentication mechanisms which can be defeated, allowing a hostile server to satisfy the criteria that establish a trust relationship. The second weakness is a systemic failure to validate the identity and integrity of code downloaded from a remote location, hence the inability to distinguish malicious code from a legitimate update.
CAPEC-533: Malicious Manual Software Update
An attacker introduces malicious code to the victim's system by altering the payload of a software update, allowing for additional compromise or site disruption at the victim location. These manual, or user-assisted attacks, vary from requiring the user to download and run an executable, to as streamlined as tricking the user to click a URL. Attacks which aim at penetrating a specific network infrastructure often rely upon secondary attack methods to achieve the desired impact. Spamming, for example, is a common method employed as an secondary attack vector. Thus the attacker has in their arsenal a choice of initial attack vectors ranging from traditional SMTP/POP/IMAP spamming and its varieties, to web-application mechanisms which commonly implement both chat and rich HTML messaging within the user interface.
CAPEC-538: Open-Source Library Manipulation
Adversaries implant malicious code in open source software (OSS) libraries to have it widely distributed, as OSS is commonly downloaded by developers and other users to incorporate into software development projects. The adversary can have a particular system in mind to target, or the implantation can be the first stage of follow-on attacks on many systems.
CAPEC-657: Malicious Automated Software Update via Spoofing
An attackers uses identify or content spoofing to trick a client into performing an automated software update from a malicious source. A malicious automated software update that leverages spoofing can include content or identity spoofing as well as protocol spoofing. Content or identity spoofing attacks can trigger updates in software by embedding scripted mechanisms within a malicious web page, which masquerades as a legitimate update source. Scripting mechanisms communicate with software components and trigger updates from locations specified by the attackers' server. The result is the client believing there is a legitimate software update available but instead downloading a malicious update from the attacker.
CAPEC-662: Adversary in the Browser (AiTB)
An adversary exploits security vulnerabilities or inherent functionalities of a web browser, in order to manipulate traffic between two endpoints.
CAPEC-691: Spoof Open-Source Software Metadata
An adversary spoofs open-source software metadata in an attempt to masquerade malicious software as popular, maintained, and trusted.
CAPEC-692: Spoof Version Control System Commit Metadata
An adversary spoofs metadata pertaining to a Version Control System (VCS) (e.g., Git) repository's commits to deceive users into believing that the maliciously provided software is frequently maintained and originates from a trusted source.
CAPEC-693: StarJacking
An adversary spoofs software popularity metadata to deceive users into believing that a maliciously provided package is widely used and originates from a trusted source.
CAPEC-695: Repo Jacking
An adversary takes advantage of the redirect property of directly linked Version Control System (VCS) repositories to trick users into incorporating malicious code into their applications.