CWE-829
AllowedInclusion of Functionality from Untrusted Control Sphere
Abstraction: Base · Status: Incomplete
The product imports, requires, or includes executable functionality (such as a library) from a source that is outside of the intended control sphere.
395 vulnerabilities reference this CWE, most recent first.
GHSA-CVW4-C69G-7V7M
Vulnerability from github – Published: 2024-07-02 21:20 – Updated: 2024-07-05 21:27Note
On Thursday, June 27, 2024, Cloudflare and Namecheap intervened at a domain level to ensure polyfill.io and its subdomains could not resolve to the compromised service, rendering this vulnerability unexploitable.
The following sections describe this vulnerability prior to the domain level intervention, when it was still exploitable.
Impact
fides.js, a client-side script used to interact with the consent management features of Fides, used the polyfill.io domain in a very limited edge case, when it detected a legacy browser such as IE11 that did not support the fetch standard.
On June 25th, 2024, Sansec published the following regarding the polyfill.io domain.
The polyfill.js is a popular open source library to support older browsers. 100K+ sites embed it using the cdn.polyfill.io domain... However, in February this year, a Chinese company bought the domain and the Github account. Since then, this domain was caught injecting malware on mobile devices via any site that embeds cdn.polyfill.io.
Therefore it was possible for users of legacy, pre-2017 browsers who navigate to a page serving fides.js to download and execute malicious scripts from the compromised domain.
No exploitation of fides.js via polyfill.io has been identified at this time, but other script developers who use https://cdn.polyfill.io/v2/polyfill.min.js have reported redirects to malicious websites.
Patches
The vulnerability has been patched in Fides version 2.39.1. Users are advised to upgrade to this version or later to secure their systems against this threat.
Workarounds
Prior to the domain level intervention, there were no server-side workarounds and the confidentiality, integrity, and availability impacts of this vulnerability were high.
Clients could ensure they were not affected by using a modern browser that supported the fetch standard. caniuse.com/fetch estimates that 97.52% of browser users use a browser that supports the fetch standard.
References
- https://sansec.io/research/polyfill-supply-chain-attack
- https://github.com/ethyca/fides/pull/5026/
- https://fetch.spec.whatwg.org/
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "ethyca-fides"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.39.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-38537"
],
"database_specific": {
"cwe_ids": [
"CWE-829"
],
"github_reviewed": true,
"github_reviewed_at": "2024-07-02T21:20:07Z",
"nvd_published_at": "2024-07-02T20:15:05Z",
"severity": "LOW"
},
"details": "### Note\n\nOn Thursday, June 27, 2024, Cloudflare and Namecheap intervened at a domain level to ensure `polyfill.io` and its subdomains could not resolve to the compromised service, rendering this vulnerability **unexploitable**.\n\nThe following sections describe this vulnerability prior to the domain level intervention, when it was still exploitable.\n\n### Impact\n\n`fides.js`, a client-side script used to interact with the consent management features of Fides, used the `polyfill.io` domain in a very limited edge case, when it detected a legacy browser such as IE11 that did not support the fetch standard.\n\nOn June 25th, 2024, Sansec published the following regarding the `polyfill.io` domain.\n\n\u003e The polyfill.js is a popular open source library to support older browsers. 100K+ sites embed it using the cdn.polyfill.io domain... However, in February this year, a Chinese company bought the domain and the Github account. Since then, this domain was caught injecting malware on mobile devices via any site that embeds cdn.polyfill.io.\n\nTherefore it was possible for users of legacy, pre-2017 browsers who navigate to a page serving `fides.js` to download and execute malicious scripts from the compromised domain.\n\nNo exploitation of `fides.js` via `polyfill.io` has been identified at this time, but other script developers who use `https://cdn.polyfill.io/v2/polyfill.min.js` have reported redirects to malicious websites.\n\n### Patches\nThe vulnerability has been patched in Fides version `2.39.1`. Users are advised to upgrade to this version or later to secure their systems against this threat.\n\n### Workarounds\n\nPrior to the domain level intervention, there were no server-side workarounds and the confidentiality, integrity, and availability impacts of this vulnerability were high. \n\nClients could ensure they were not affected by using a modern browser that supported the fetch standard. caniuse.com/fetch estimates that 97.52% of browser users use a browser that supports the fetch standard.\n\n### References\n- https://sansec.io/research/polyfill-supply-chain-attack\n- https://github.com/ethyca/fides/pull/5026/\n- https://fetch.spec.whatwg.org/",
"id": "GHSA-cvw4-c69g-7v7m",
"modified": "2024-07-05T21:27:24Z",
"published": "2024-07-02T21:20:07Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/ethyca/fides/security/advisories/GHSA-cvw4-c69g-7v7m"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38537"
},
{
"type": "WEB",
"url": "https://github.com/ethyca/fides/pull/5026"
},
{
"type": "WEB",
"url": "https://github.com/ethyca/fides/commit/868c4d629760572192bd61db34f5a4458ed12005"
},
{
"type": "WEB",
"url": "https://fetch.spec.whatwg.org"
},
{
"type": "PACKAGE",
"url": "https://github.com/ethyca/fides"
},
{
"type": "WEB",
"url": "https://sansec.io/research/polyfill-supply-chain-attack"
}
],
"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"
}
],
"summary": "Inclusion of Untrusted polyfill.io Code Vulnerability in fides.js"
}
GHSA-CVXM-645Q-P574
Vulnerability from github – Published: 2026-06-19 19:35 – Updated: 2026-06-19 19:35Impact
containerd's CRI checkpoint import process contains a vulnerability where it fails to validate the image references specified within a checkpoint image's configuration. An attacker with permissions to create pods can use a crafted checkpoint image to force containerd to pull a malicious image and assign it an arbitrary local tag, thereby poisoning the node's local image cache. Subsequently, if other pods on the same node attempt to use the poisoned tag with an IfNotPresent (or Never) pull policy, they will unknowingly execute the attacker's malicious image instead of the legitimate one. This can lead to a compromise of the affected pods, allowing the attacker to execute arbitrary code under the victim pod's identity.
Patches
This bug has been fixed in the following containerd versions:
- 2.3.2
- 2.2.5
- 2.1.9
Users should update to these versions to resolve the issue.
Workarounds
Users should only allow trusted images to be pulled.
Credits
The containerd project would like to thank Henry Beberman (@hbeberman) of Microsoft, the GKE Security Team using Gemini, Anthropic Research, in collaboration with Claude, and Robert Prast (@robertprast) who independently discovered and responsibly disclosed this issue in accordance with the containerd security policy.
For more information
If you have any questions or comments about this advisory:
- Open an issue in containerd
- Email us at security@containerd.io
To report a security issue in containerd: * Report a new vulnerability * Email us at security@containerd.io
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/containerd/containerd/v2"
},
"ranges": [
{
"events": [
{
"introduced": "2.1.0"
},
{
"fixed": "2.1.9"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/containerd/containerd/v2"
},
"ranges": [
{
"events": [
{
"introduced": "2.2.0"
},
{
"fixed": "2.2.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/containerd/containerd/v2"
},
"ranges": [
{
"events": [
{
"introduced": "2.3.0"
},
{
"fixed": "2.3.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-50195"
],
"database_specific": {
"cwe_ids": [
"CWE-345",
"CWE-829"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-19T19:35:23Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## Impact\ncontainerd\u0027s CRI checkpoint import process contains a vulnerability where it fails to validate the image references specified within a checkpoint image\u0027s configuration. An attacker with permissions to create pods can use a crafted checkpoint image to force containerd to pull a malicious image and assign it an arbitrary local tag, thereby poisoning the node\u0027s local image cache. Subsequently, if other pods on the same node attempt to use the poisoned tag with an `IfNotPresent` (or `Never`) pull policy, they will unknowingly execute the attacker\u0027s malicious image instead of the legitimate one. This can lead to a compromise of the affected pods, allowing the attacker to execute arbitrary code under the victim pod\u0027s identity.\n\n## Patches\nThis bug has been fixed in the following containerd versions:\n\n* 2.3.2\n* 2.2.5\n* 2.1.9\n\nUsers should update to these versions to resolve the issue.\n## Workarounds\nUsers should only allow trusted images to be pulled.\n\n## Credits\nThe containerd project would like to thank Henry Beberman (@hbeberman) of Microsoft, the GKE Security Team using Gemini, Anthropic Research, in collaboration with Claude, and Robert Prast (@robertprast) who independently discovered and responsibly disclosed this issue in accordance with the [containerd security policy](https://github.com/containerd/project/blob/main/SECURITY.md).\n\n## For more information\nIf you have any questions or comments about this advisory:\n\n* Open an issue in [containerd](https://github.com/containerd/containerd/issues/new/choose)\n* Email us at [security@containerd.io](mailto:security@containerd.io)\n\nTo report a security issue in containerd:\n* [Report a new vulnerability](https://github.com/containerd/containerd/security/advisories/new)\n* Email us at [security@containerd.io](mailto:security@containerd.io)",
"id": "GHSA-cvxm-645q-p574",
"modified": "2026-06-19T19:35:23Z",
"published": "2026-06-19T19:35:23Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/containerd/containerd/security/advisories/GHSA-cvxm-645q-p574"
},
{
"type": "PACKAGE",
"url": "https://github.com/containerd/containerd"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:L/VA:N/SC:H/SI:H/SA:L",
"type": "CVSS_V4"
}
],
"summary": "containerd: CRI checkpoint import allows local image tag poisoning"
}
GHSA-CVXW-G73W-J934
Vulnerability from github – Published: 2024-04-09 15:30 – Updated: 2024-04-09 15:30A command execution vulnerability exists in the tddpd enable_test_mode functionality of Tp-Link AC1350 Wireless MU-MIMO Gigabit Access Point (EAP225 V3) v5.1.0 Build 20220926 and Tp-Link N300 Wireless Access Point (EAP115 V4) v5.0.4 Build 20220216. A specially crafted series of network requests can lead to arbitrary command execution. An attacker can send a sequence of unauthenticated packets to trigger this vulnerability.This vulnerability impacts uclited on the EAP115(V4) 5.0.4 Build 20220216 of the N300 Wireless Gigabit Access Point.
{
"affected": [],
"aliases": [
"CVE-2023-49134"
],
"database_specific": {
"cwe_ids": [
"CWE-77",
"CWE-829"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-04-09T15:15:29Z",
"severity": "HIGH"
},
"details": "A command execution vulnerability exists in the tddpd enable_test_mode functionality of Tp-Link AC1350 Wireless MU-MIMO Gigabit Access Point (EAP225 V3) v5.1.0 Build 20220926 and Tp-Link N300 Wireless Access Point (EAP115 V4) v5.0.4 Build 20220216. A specially crafted series of network requests can lead to arbitrary command execution. An attacker can send a sequence of unauthenticated packets to trigger this vulnerability.This vulnerability impacts `uclited` on the EAP115(V4) 5.0.4 Build 20220216 of the N300 Wireless Gigabit Access Point.",
"id": "GHSA-cvxw-g73w-j934",
"modified": "2024-04-09T15:30:37Z",
"published": "2024-04-09T15:30:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-49134"
},
{
"type": "WEB",
"url": "https://talosintelligence.com/vulnerability_reports/TALOS-2023-1862"
},
{
"type": "WEB",
"url": "https://www.talosintelligence.com/vulnerability_reports/TALOS-2023-1862"
}
],
"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-F26X-PR96-VW86
Vulnerability from github – Published: 2018-10-16 17:43 – Updated: 2024-05-15 06:25Spring Framework, versions 5.0.x prior to 5.0.7 and 4.3.x prior to 4.3.18 and older unsupported versions, allows web applications to enable cross-domain requests via JSONP (JSON with Padding) through AbstractJsonpResponseBodyAdvice for REST controllers and MappingJackson2JsonView for browser requests. Both are not enabled by default in Spring Framework nor Spring Boot, however, when MappingJackson2JsonView is configured in an application, JSONP support is automatically ready to use through the "jsonp" and "callback" JSONP parameters, enabling cross-domain requests.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.springframework:spring-core"
},
"ranges": [
{
"events": [
{
"introduced": "5.0.0.RELEASE"
},
{
"fixed": "5.0.7.RELEASE"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.springframework:spring-core"
},
"ranges": [
{
"events": [
{
"introduced": "4.3.0.RELEASE"
},
{
"fixed": "4.3.18.RELEASE"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2018-11040"
],
"database_specific": {
"cwe_ids": [
"CWE-829"
],
"github_reviewed": true,
"github_reviewed_at": "2020-06-16T21:33:24Z",
"nvd_published_at": "2018-06-25T15:29:00Z",
"severity": "MODERATE"
},
"details": "Spring Framework, versions 5.0.x prior to 5.0.7 and 4.3.x prior to 4.3.18 and older unsupported versions, allows web applications to enable cross-domain requests via JSONP (JSON with Padding) through AbstractJsonpResponseBodyAdvice for REST controllers and MappingJackson2JsonView for browser requests. Both are not enabled by default in Spring Framework nor Spring Boot, however, when MappingJackson2JsonView is configured in an application, JSONP support is automatically ready to use through the \"jsonp\" and \"callback\" JSONP parameters, enabling cross-domain requests.",
"id": "GHSA-f26x-pr96-vw86",
"modified": "2024-05-15T06:25:53Z",
"published": "2018-10-16T17:43:45Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-11040"
},
{
"type": "WEB",
"url": "https://github.com/spring-projects/spring-framework/commit/874859493bbda59739c38c7e52eb3625f247b93a"
},
{
"type": "WEB",
"url": "https://github.com/spring-projects/spring-framework/commit/b80c13b722bb207ddf43f53a007ee3ddc1dd2e26"
},
{
"type": "ADVISORY",
"url": "https://github.com/advisories/GHSA-f26x-pr96-vw86"
},
{
"type": "PACKAGE",
"url": "https://github.com/spring-projects/spring-framework"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2021/04/msg00022.html"
},
{
"type": "WEB",
"url": "https://pivotal.io/security/cve-2018-11040"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpujan2020.html"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpujul2020.html"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpuoct2021.html"
},
{
"type": "WEB",
"url": "https://www.oracle.com/technetwork/security-advisory/cpuapr2019-5072813.html"
},
{
"type": "WEB",
"url": "https://www.oracle.com/technetwork/security-advisory/cpujan2019-5072801.html"
},
{
"type": "WEB",
"url": "https://www.oracle.com/technetwork/security-advisory/cpujul2019-5072835.html"
},
{
"type": "WEB",
"url": "http://www.oracle.com/technetwork/security-advisory/cpuoct2018-4428296.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Moderate severity vulnerability that affects org.springframework:spring-core"
}
GHSA-F29J-VF7H-F9G9
Vulnerability from github – Published: 2022-05-05 00:28 – Updated: 2024-04-03 23:53{
"affected": [],
"aliases": [
"CVE-2013-1945"
],
"database_specific": {
"cwe_ids": [
"CWE-829"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-10-31T20:15:00Z",
"severity": "LOW"
},
"details": "ruby193 uses an insecure LD_LIBRARY_PATH setting.",
"id": "GHSA-f29j-vf7h-f9g9",
"modified": "2024-04-03T23:53:58Z",
"published": "2022-05-05T00:28:57Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2013-1945"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2013-1945"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-F62H-6JMM-8R9R
Vulnerability from github – Published: 2026-03-16 15:30 – Updated: 2026-06-08 18:31A DLL search order hijacking vulnerability in Thermalright TR-VISION HOME on Windows (64-bit) allows a local attacker to escalate privileges via DLL side-loading. The application loads certain dynamic-link library (DLL) dependencies using the default Windows search order, which includes directories that may be writable by non-privileged users.\n\n\n\nBecause these directories can be modified by unprivileged users, an attacker can place a malicious DLL with the same name as a legitimate dependency in a directory that is searched before trusted system locations. When the application is executed, which is always with administrative privileges, the malicious DLL is loaded instead of the legitimate library.\n\n\n\nThe application does not enforce restrictions on DLL loading locations and does not verify the integrity or digital signature of loaded libraries. As a result, attacker-controlled code may be executed within the security context of the application, allowing arbitrary code execution with elevated privileges.\n\n\n\nSuccessful exploitation requires that an attacker place a crafted malicious DLL in a user-writable directory that is included in the application's DLL search path and then cause the affected application to be executed. Once loaded, the malicious DLL runs with the same privileges as the application.\n\n\n\nThis issue affects \nTR-VISION HOME versions up to and including 2.0.5.
{
"affected": [],
"aliases": [
"CVE-2026-4255"
],
"database_specific": {
"cwe_ids": [
"CWE-829"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-16T14:20:19Z",
"severity": "HIGH"
},
"details": "A DLL search order hijacking vulnerability in Thermalright TR-VISION HOME on Windows (64-bit) allows a local attacker to escalate privileges via DLL side-loading. The application loads certain dynamic-link library (DLL) dependencies using the default Windows search order, which includes directories that may be writable by non-privileged users.\\n\\n\\n\\nBecause these directories can be modified by unprivileged users, an attacker can place a malicious DLL with the same name as a legitimate dependency in a directory that is searched before trusted system locations. When the application is executed, which is always with administrative privileges, the malicious DLL is loaded instead of the legitimate library.\\n\\n\\n\\nThe application does not enforce restrictions on DLL loading locations and does not verify the integrity or digital signature of loaded libraries. As a result, attacker-controlled code may be executed within the security context of the application, allowing arbitrary code execution with elevated privileges.\\n\\n\\n\\nSuccessful exploitation requires that an attacker place a crafted malicious DLL in a user-writable directory that is included in the application\u0027s DLL search path and then cause the affected application to be executed. Once loaded, the malicious DLL runs with the same privileges as the application.\\n\\n\\n\\nThis issue affects\u00a0\\nTR-VISION HOME\u00a0\u00a0versions up to and including 2.0.5.",
"id": "GHSA-f62h-6jmm-8r9r",
"modified": "2026-06-08T18:31:40Z",
"published": "2026-03-16T15:30:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-4255"
},
{
"type": "WEB",
"url": "https://www.thermalright.com/support/download"
}
],
"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"
},
{
"score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/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-F77V-9VPC-6PJM
Vulnerability from github – Published: 2026-05-08 18:34 – Updated: 2026-05-08 18:34Impact
The runWidget function in src/app/widgets/load-widget.js constructs a file path by directly concatenating user‑supplied widget identifiers without any sanitisation:
const file = `widget-${widgetId}.js`
const widget = require(path.join(__dirname, file))
Because runWidget is exposed to the renderer process via an asynchronous IPC handler with no input validation, an attacker who achieves JavaScript execution inside the renderer (for example, through a malicious plugin or a cross‑site scripting flaw in the built‑in webview) can abuse a path traversal (../) to load and execute an arbitrary JavaScript file anywhere on the victim’s filesystem. This gives the attacker local code execution with the full privileges of the electerm process, leading to complete system compromise.
Patches
Fixed in version >= 3.7.16
Workarounds
Until a patch is released:
- Do not install or run untrusted plugins.
- Avoid loading arbitrary web content inside electerm’s embedded webview (for example, disable any features that fetch and display remote HTML).
- Run electerm in a sandboxed environment (e.g., with bubblewrap on Linux, AppArmor/SELinux profiles, or Windows sandboxed app execution) to limit the impact of any code execution.
Resources
- electerm GitHub Repository
- electerm Security Policy
- Vulnerability details originally reported by external researcher (PoC confirmed on v3.7.9, Win10).
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "electerm"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.7.16"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-43940"
],
"database_specific": {
"cwe_ids": [
"CWE-22",
"CWE-829"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-08T18:34:20Z",
"nvd_published_at": "2026-05-08T04:16:23Z",
"severity": "CRITICAL"
},
"details": "### Impact\nThe `runWidget` function in `src/app/widgets/load-widget.js` constructs a file path by directly concatenating user\u2011supplied widget identifiers without any sanitisation:\n\n```javascript\nconst file = `widget-${widgetId}.js`\nconst widget = require(path.join(__dirname, file))\n```\n\nBecause `runWidget` is exposed to the renderer process via an asynchronous IPC handler with no input validation, an attacker who achieves JavaScript execution inside the renderer (for example, through a malicious plugin or a cross\u2011site scripting flaw in the built\u2011in webview) can abuse a **path traversal** (`../`) to load and execute an arbitrary JavaScript file anywhere on the victim\u2019s filesystem. This gives the attacker local code execution with the full privileges of the electerm process, leading to complete system compromise.\n\n### Patches\n\nFixed in version \u003e= 3.7.16\n\n### Workarounds\nUntil a patch is released:\n- Do not install or run untrusted plugins.\n- Avoid loading arbitrary web content inside electerm\u2019s embedded webview (for example, disable any features that fetch and display remote HTML).\n- Run electerm in a sandboxed environment (e.g., with `bubblewrap` on Linux, AppArmor/SELinux profiles, or Windows sandboxed app execution) to limit the impact of any code execution.\n\n### Resources\n- [electerm GitHub Repository](https://github.com/electerm/electerm)\n- [electerm Security Policy](https://github.com/electerm/electerm/security)\n- Vulnerability details originally reported by external researcher (PoC confirmed on v3.7.9, Win10).",
"id": "GHSA-f77v-9vpc-6pjm",
"modified": "2026-05-08T18:34:20Z",
"published": "2026-05-08T18:34:20Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/electerm/electerm/security/advisories/GHSA-f77v-9vpc-6pjm"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43940"
},
{
"type": "PACKAGE",
"url": "https://github.com/electerm/electerm"
},
{
"type": "WEB",
"url": "https://github.com/electerm/electerm/releases/tag/v3.7.16"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Electerm runWidget has a path traversal that leads to arbitrary code execution"
}
GHSA-F9P9-JV2M-5P2J
Vulnerability from github – Published: 2023-03-23 03:30 – Updated: 2023-03-28 21:30XunRuiCMS v4.3.3 to v4.5.1 vulnerable to PHP file write and CMS PHP file inclusion, allows attackers to execute arbitrary php code, via the add function in cron.php.
{
"affected": [],
"aliases": [
"CVE-2022-30037"
],
"database_specific": {
"cwe_ids": [
"CWE-829"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-03-23T02:15:00Z",
"severity": "HIGH"
},
"details": "XunRuiCMS v4.3.3 to v4.5.1 vulnerable to PHP file write and CMS PHP file inclusion, allows attackers to execute arbitrary php code, via the add function in cron.php.",
"id": "GHSA-f9p9-jv2m-5p2j",
"modified": "2023-03-28T21:30:18Z",
"published": "2023-03-23T03:30:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-30037"
},
{
"type": "WEB",
"url": "https://weltolk.github.io/p/xunruicms-v4.3.3-to-v4.5.1-backstage-code-injection-vulnerabilityfile-write-and-file-inclusion"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-F9XH-5XH7-49G5
Vulnerability from github – Published: 2022-05-13 01:50 – Updated: 2022-05-13 01:50An issue was discovered on KONE Group Controller (KGC) devices before 4.6.5. Unauthenticated Local File Inclusion and File modification is possible through the open HTTP interface by modifying the name parameter of the file endpoint, aka KONE-02.
{
"affected": [],
"aliases": [
"CVE-2018-15486"
],
"database_specific": {
"cwe_ids": [
"CWE-829"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-09-07T22:29:00Z",
"severity": "CRITICAL"
},
"details": "An issue was discovered on KONE Group Controller (KGC) devices before 4.6.5. Unauthenticated Local File Inclusion and File modification is possible through the open HTTP interface by modifying the name parameter of the file endpoint, aka KONE-02.",
"id": "GHSA-f9xh-5xh7-49g5",
"modified": "2022-05-13T01:50:09Z",
"published": "2022-05-13T01:50:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-15486"
},
{
"type": "WEB",
"url": "https://www.kone.com/en/vulnerability.aspx"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/149252/KONE-KGC-4.6.4-DoS-Code-Execution-LFI-Bypass.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-FF6C-W6QF-7XQC
Vulnerability from github – Published: 2026-05-07 02:06 – Updated: 2026-06-08 23:18Summary
The CSS Parser gem does not validate HTTPS connections, allowing a Man-in-the-Middle (MITM) attacker to inject or modify CSS content when stylesheets are loaded via HTTPS. The connection is established with OpenSSL::SSL::VERIFY_NONE, meaning any HTTPS certificate—even entirely untrusted—will be accepted without validation.
Details
In lib/css_parser/parser.rb, the HTTP client sets:
https://github.com/premailer/css_parser/blob/3f91e8db7547fac50ab50cb7f9920f785f722740/lib/css_parser/parser.rb#L646
http.verify_mode = OpenSSL::SSL::VERIFY_NONE
As a result, the library does not validate the authenticity of HTTPS connections and does not protect against man-in-the-middle attacks. Any attacker in a position to intercept network traffic can inject or modify CSS loaded via HTTPS URLs without detection or warning.
PoC
- Set up a test Ruby project that uses the CSS Parser gem and loads an external stylesheet over HTTPS.
- Use a local proxy (such as mitmproxy or Burp Suite) to intercept outgoing HTTPS requests.
- Present a fake self-signed certificate to the client.
- Inject custom CSS into the intercepted HTTPS response.
The request will succeed and the injected CSS will be delivered to the application, as the connection is not validated.
References
https://github.com/premailer/css_parser/issues/185
Impact
Applications using CSS Parser to load remote stylesheets over HTTPS are vulnerable to CSS injection and content manipulation, regardless of the trust status of the remote server. All users who use CSS Parser to fetch external CSS over HTTPS may be impacted.
Credit
This vulnerability was uncovered by @JLLeitschuh of the @braze-inc security team.
{
"affected": [
{
"package": {
"ecosystem": "RubyGems",
"name": "css_parser"
},
"ranges": [
{
"events": [
{
"introduced": "2.0.0"
},
{
"fixed": "2.1.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "RubyGems",
"name": "css_parser"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.22.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-44312"
],
"database_specific": {
"cwe_ids": [
"CWE-295",
"CWE-829"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-07T02:06:49Z",
"nvd_published_at": "2026-05-14T17:16:22Z",
"severity": "MODERATE"
},
"details": "### Summary\n\nThe CSS Parser gem does not validate HTTPS connections, allowing a Man-in-the-Middle (MITM) attacker to inject or modify CSS content when stylesheets are loaded via HTTPS. The connection is established with `OpenSSL::SSL::VERIFY_NONE`, meaning any HTTPS certificate\u2014even entirely untrusted\u2014will be accepted without validation.\n\n### Details\n\nIn `lib/css_parser/parser.rb`, the HTTP client sets:\nhttps://github.com/premailer/css_parser/blob/3f91e8db7547fac50ab50cb7f9920f785f722740/lib/css_parser/parser.rb#L646\n\n```ruby\nhttp.verify_mode = OpenSSL::SSL::VERIFY_NONE\n```\n\nAs a result, the library does not validate the authenticity of HTTPS connections and does not protect against man-in-the-middle attacks. Any attacker in a position to intercept network traffic can inject or modify CSS loaded via HTTPS URLs without detection or warning.\n\n### PoC\n\n1. Set up a test Ruby project that uses the CSS Parser gem and loads an external stylesheet over HTTPS.\n2. Use a local proxy (such as mitmproxy or Burp Suite) to intercept outgoing HTTPS requests.\n3. Present a fake self-signed certificate to the client.\n4. Inject custom CSS into the intercepted HTTPS response.\n \nThe request will succeed and the injected CSS will be delivered to the application, as the connection is not validated.\n\n### References\n \nhttps://github.com/premailer/css_parser/issues/185\n\n### Impact\n\nApplications using CSS Parser to load remote stylesheets over HTTPS are vulnerable to CSS injection and content manipulation, regardless of the trust status of the remote server. All users who use CSS Parser to fetch external CSS over HTTPS may be impacted.\n\n### Credit\n\nThis vulnerability was uncovered by @JLLeitschuh of the @braze-inc security team.",
"id": "GHSA-ff6c-w6qf-7xqc",
"modified": "2026-06-08T23:18:03Z",
"published": "2026-05-07T02:06:49Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/premailer/css_parser/security/advisories/GHSA-ff6c-w6qf-7xqc"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44312"
},
{
"type": "WEB",
"url": "https://github.com/premailer/css_parser/issues/185"
},
{
"type": "WEB",
"url": "https://github.com/premailer/css_parser/commit/35e689c904225add78e0c488cf04bad052666449"
},
{
"type": "WEB",
"url": "https://github.com/premailer/css_parser/commit/e0c95d5abe91b237becb90ff316531a6547ada18"
},
{
"type": "PACKAGE",
"url": "https://github.com/premailer/css_parser"
},
{
"type": "WEB",
"url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/css_parser/CVE-2026-44312.yml"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "CSS Parser: Improper Certificate Validation allows MITM injection of remote CSS content"
}
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].
Mitigation MIT-21.1
Strategy: Enforcement by Conversion
- When the set of acceptable objects, such as filenames or URLs, is limited or known, create a mapping from a set of fixed input values (such as numeric IDs) to the actual filenames or URLs, and reject all other inputs.
- For example, ID 1 could map to "inbox.txt" and ID 2 could map to "profile.txt". Features such as the ESAPI AccessReferenceMap [REF-45] provide this capability.
Mitigation MIT-15
For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.
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.
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-5.1
Strategy: Input Validation
- Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
- When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."
- Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
- When validating filenames, use stringent allowlists that limit the character set to be used. If feasible, only allow a single "." character in the filename to avoid weaknesses such as CWE-23, and exclude directory separators such as "/" to avoid CWE-36. Use a list of allowable file extensions, which will help to avoid CWE-434.
- Do not rely exclusively on a filtering mechanism that removes potentially dangerous characters. This is equivalent to a denylist, which may be incomplete (CWE-184). For example, filtering "/" is insufficient protection if the filesystem also supports the use of "\" as a directory separator. Another possible error could occur when the filtering is applied in a way that still produces dangerous data (CWE-182). For example, if "../" sequences are removed from the ".../...//" string in a sequential fashion, two instances of "../" would be removed from the original string, but the remaining characters would still form the "../" string.
Mitigation MIT-34
Strategy: Attack Surface Reduction
- Store library, include, and utility files outside of the web document root, if possible. Otherwise, store them in a separate directory and use the web server's access control capabilities to prevent attackers from directly requesting them. One common practice is to define a fixed constant in each calling program, then check for the existence of the constant in the library/include file; if the constant does not exist, then the file was directly requested, and it can exit immediately.
- This significantly reduces the chance of an attacker being able to bypass any protection mechanisms that are in the base program but not in the include files. It will also reduce the attack surface.
Mitigation MIT-6
Strategy: Attack Surface Reduction
- Understand all the potential areas where untrusted inputs can enter your software: parameters or arguments, cookies, anything read from the network, environment variables, reverse DNS lookups, query results, request headers, URL components, e-mail, files, filenames, databases, and any external systems that provide data to the application. Remember that such inputs may be obtained indirectly through API calls.
- Many file inclusion problems occur because the programmer assumed that certain inputs could not be modified, especially for cookies and URL components.
Mitigation MIT-29
Strategy: Firewall
Use an application firewall that can detect attacks against this weakness. It can be beneficial in cases in which the code cannot be fixed (because it is controlled by a third party), as an emergency prevention measure while more comprehensive software assurance measures are applied, or to provide defense in depth [REF-1481].
CAPEC-175: Code Inclusion
An adversary exploits a weakness on the target to force arbitrary code to be retrieved locally or from a remote location and executed. This differs from code injection in that code injection involves the direct inclusion of code while code inclusion involves the addition or replacement of a reference to a code file, which is subsequently loaded by the target and used as part of the code of some application.
CAPEC-201: Serialized Data External Linking
An adversary creates a serialized data file (e.g. XML, YAML, etc...) that contains an external data reference. Because serialized data parsers may not validate documents with external references, there may be no checks on the nature of the reference in the external data. This can allow an adversary to open arbitrary files or connections, which may further lead to the adversary gaining access to information on the system that they would normally be unable to obtain.
CAPEC-228: DTD Injection
An attacker injects malicious content into an application's DTD in an attempt to produce a negative technical impact. DTDs are used to describe how XML documents are processed. Certain malformed DTDs (for example, those with excessive entity expansion as described in CAPEC 197) can cause the XML parsers that process the DTDs to consume excessive resources resulting in resource depletion.
CAPEC-251: Local Code Inclusion
The attacker forces an application to load arbitrary code files from the local machine. The attacker could use this to try to load old versions of library files that have known vulnerabilities, to load files that the attacker placed on the local machine during a prior attack, or to otherwise change the functionality of the targeted application in unexpected ways.
CAPEC-252: PHP Local File Inclusion
The attacker loads and executes an arbitrary local PHP file on a target machine. The attacker could use this to try to load old versions of PHP files that have known vulnerabilities, to load PHP files that the attacker placed on the local machine during a prior attack, or to otherwise change the functionality of the targeted application in unexpected ways.
CAPEC-253: Remote Code Inclusion
The attacker forces an application to load arbitrary code files from a remote location. The attacker could use this to try to load old versions of library files that have known vulnerabilities, to load malicious files that the attacker placed on the remote machine, or to otherwise change the functionality of the targeted application in unexpected ways.
CAPEC-263: Force Use of Corrupted Files
This describes an attack where an application is forced to use a file that an attacker has corrupted. The result is often a denial of service caused by the application being unable to process the corrupted file, but other results, including the disabling of filters or access controls (if the application fails in an unsafe way rather than failing by locking down) or buffer overflows are possible.
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-549: Local Execution of Code
An adversary installs and executes malicious code on the target system in an effort to achieve a negative technical impact. Examples include rootkits, ransomware, spyware, adware, and others.
CAPEC-640: Inclusion of Code in Existing Process
The adversary takes advantage of a bug in an application failing to verify the integrity of the running process to execute arbitrary code in the address space of a separate live process. The adversary could use running code in the context of another process to try to access process's memory, system/network resources, etc. The goal of this attack is to evade detection defenses and escalate privileges by masking the malicious code under an existing legitimate process. Examples of approaches include but not limited to: dynamic-link library (DLL) injection, portable executable injection, thread execution hijacking, ptrace system calls, VDSO hijacking, function hooking, reflective code loading, and more.
CAPEC-660: Root/Jailbreak Detection Evasion via Hooking
An adversary forces a non-restricted mobile application to load arbitrary code or code files, via Hooking, with the goal of evading Root/Jailbreak detection. Mobile device users often Root/Jailbreak their devices in order to gain administrative control over the mobile operating system and/or to install third-party mobile applications that are not provided by authorized application stores (e.g. Google Play Store and Apple App Store). Adversaries may further leverage these capabilities to escalate privileges or bypass access control on legitimate applications. Although many mobile applications check if a mobile device is Rooted/Jailbroken prior to authorized use of the application, adversaries may be able to "hook" code in order to circumvent these checks. Successfully evading Root/Jailbreak detection allows an adversary to execute administrative commands, obtain confidential data, impersonate legitimate users of the application, and more.
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.
CAPEC-698: Install Malicious Extension
An adversary directly installs or tricks a user into installing a malicious extension into existing trusted software, with the goal of achieving a variety of negative technical impacts.