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.
393 vulnerabilities reference this CWE, most recent first.
GHSA-5PGV-4JF4-9R43
Vulnerability from github – Published: 2026-04-18 06:30 – Updated: 2026-04-18 06:30In iTerm2 through 3.6.9, displaying a .txt file can cause code execution via DCS 2000p and OSC 135 data, if the working directory contains a malicious file whose name is valid output from the conductor encoding path, such as a pathname with an initial ace/c+ substring, aka "hypothetical in-band signaling abuse." This occurs because iTerm2 accepts the SSH conductor protocol from terminal output that does not originate from a legitimate conductor session.
{
"affected": [],
"aliases": [
"CVE-2026-41253"
],
"database_specific": {
"cwe_ids": [
"CWE-829"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-18T06:16:17Z",
"severity": "MODERATE"
},
"details": "In iTerm2 through 3.6.9, displaying a .txt file can cause code execution via DCS 2000p and OSC 135 data, if the working directory contains a malicious file whose name is valid output from the conductor encoding path, such as a pathname with an initial ace/c+ substring, aka \"hypothetical in-band signaling abuse.\" This occurs because iTerm2 accepts the SSH conductor protocol from terminal output that does not originate from a legitimate conductor session.",
"id": "GHSA-5pgv-4jf4-9r43",
"modified": "2026-04-18T06:30:14Z",
"published": "2026-04-18T06:30:14Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41253"
},
{
"type": "WEB",
"url": "https://github.com/gnachman/iTerm2/commit/a9e745993c2e2cbb30b884a16617cd5495899f86"
},
{
"type": "WEB",
"url": "https://blog.calif.io/p/mad-bugs-even-cat-readmetxt-is-not"
},
{
"type": "WEB",
"url": "https://iterm2.com/downloads.html"
},
{
"type": "WEB",
"url": "https://news.ycombinator.com/item?id=47809190"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-5QFP-R7Q3-257G
Vulnerability from github – Published: 2024-09-16 21:30 – Updated: 2024-09-18 18:30The HTTPD binary in multiple ZTE routers has a local file inclusion vulnerability in session_init function. The session -LUA- files are stored in the directory /var/lua_session, the function iterates on all files in this directory and executes them using the function dofile without any validation if it is a valid session file or not. An attacker who is able to write a malicious file in the sessions directory can get RCE as root.
{
"affected": [],
"aliases": [
"CVE-2024-45416"
],
"database_specific": {
"cwe_ids": [
"CWE-829"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-09-16T21:15:46Z",
"severity": "HIGH"
},
"details": "The HTTPD binary in multiple ZTE routers has a local file inclusion vulnerability in session_init function. The session -LUA- files are stored in the directory /var/lua_session, the function iterates on all files in this directory and executes them using the function dofile without any validation if it is a valid session file or not. An attacker who is able to write a malicious file in the sessions directory can get RCE as root.",
"id": "GHSA-5qfp-r7q3-257g",
"modified": "2024-09-18T18:30:51Z",
"published": "2024-09-16T21:30:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45416"
},
{
"type": "WEB",
"url": "https://wr3nchsr.github.io/zte-multiple-routers-httpd-vulnerabilities-advisory"
}
],
"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-5QPJ-QFQ5-R2H7
Vulnerability from github – Published: 2023-02-09 21:30 – Updated: 2023-02-21 21:30Improper access control vulnerability in WindowManagerService prior to SMR Feb-2023 Release 1 allows attackers to take a screen capture.
{
"affected": [],
"aliases": [
"CVE-2023-21440"
],
"database_specific": {
"cwe_ids": [
"CWE-829"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-02-09T19:15:00Z",
"severity": "MODERATE"
},
"details": "Improper access control vulnerability in WindowManagerService prior to SMR Feb-2023 Release 1 allows attackers to take a screen capture.",
"id": "GHSA-5qpj-qfq5-r2h7",
"modified": "2023-02-21T21:30:19Z",
"published": "2023-02-09T21:30:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-21440"
},
{
"type": "WEB",
"url": "https://security.samsungmobile.com/securityUpdate.smsb?year=2023\u0026month=02"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-5WX6-MG75-V57R
Vulnerability from github – Published: 2026-06-26 23:18 – Updated: 2026-06-26 23:18Summary
Keep build approval for opaque dependency sources byte-exact for GHSA-5wx6-mg75-v57r / CAND-PNPM-123.
Merged upstream commit bf1b731ee6 fixed the original name-only approval bypass by making build policy consume the resolved dependency identity. One collision remained: the generic peer-suffix normalizer also stripped parenthesized text from git, URL, tarball, file, and other opaque locators. Approval for one source string could therefore authorize a different attacker-controlled source whose locator normalized to the same value.
Security boundary
- Registry dependency identities still normalize legitimate peer suffixes and retain patch hashes.
- Git, URL, tarball, file, directory, and otherwise opaque identities must match the complete resolved locator byte for byte.
- Explicit denials use the same normalization as approvals.
- Ignored-build output preserves the exact opaque identity, so the key pnpm asks a user to approve is the key policy later checks.
- TypeScript pnpm and pacquet implement the same distinction between registry and opaque identities.
Exploit replay
- With
allowBuildsapprovingfoo@https://host/pkg.tgz, the upstream implementation also acceptedfoo@https://host/pkg.tgz(evil)because both passed through peer-suffix removal. - An independent review found a second Rust-only form:
foo@https://host/pkg@1.0.0(good)andfoo@https://host/pkg@1.0.0(evil)collided because the parser selected the final@and misclassified the opaque URL as a registry package. - A final review found the same parser hazard in source-only locators ending in a semver-looking tail: approval for
https://host/pkg@1.0.0could collapsehttps://host/pkg@1.0.0(evil). - The final patch rejects all three collision forms, applies the same exactness to deny rules, accepts exact opaque keys as positive controls, and continues to accept registry packages approved without their peer suffixes.
Files changed
building/policy/src/index.tsandbuilding/policy/test/index.tsnormalize only parsed registry identities and retain exact opaque keys.pacquet/crates/package-manager/src/build_modules.rspasses snapshot identities to policy, matches TypeScript package-separator parsing, and preserves opaque locators.pacquet/crates/package-manager/src/build_modules/tests.rscovers exact approval and denial, all three collision forms, ignored-build output, and registry peer compatibility..changeset/quiet-opaque-build-identities.mdrecords patch releases for@pnpm/building.policyandpnpm.
Commands run
$ jest building/policy/test/index.ts --runInBand
16 passed
$ cargo test -p pacquet-package-manager build_modules::tests -- --nocapture
49 passed
$ cargo fmt --all -- --check
PASS
$ git diff --check 84bb4b1a046f3a659de1c9aab1d45dcf814124ce...HEAD
PASS
Validation
- The TypeScript policy suite passed all 16 tests.
- The final pacquet build-policy suite passed all 49 tests.
- The new Rust regression reproduced the extra-
@collision before the additive fix and passed afterward. - Exact opaque approval and denial, source-only semver-tail collision rejection, registry peer normalization, and ignored-build reporting all have paired tests.
- ESLint passed on the changed TypeScript source and test files.
- Rust formatting and diff checks passed; the branch is clean and consists of three focused security commits plus additive merges of upstream through
84bb4b1a046f3a659de1c9aab1d45dcf814124ce. - The focused TypeScript suite and ESLint ran directly through the installed harness. The isolated project build cannot resolve workspace packages without a local install, and the configured registry gateway returns HTTP 403 while fetching
@pnpm/pacquet@0.11.2; no candidate-focused test failed.
Patches
10.34.2: https://github.com/pnpm/pnpm/commit/14bceb1e0b2a71f4f670774db261feb03f38ec23
11.5.3: https://github.com/pnpm/pnpm/commit/bf1b731ee6c0ea98709e671ff0f46bf654480ab8
Compatibility
Registry package approvals keep their existing form. Opaque dependencies that were approved through a normalized parenthesized variant must now use the exact key shown in pnpm's ignored-build output. This is the intended trust-boundary change; no package-resolution or artifact format changes.
CI note
GitHub intentionally does not run status checks on temporary private-fork pull requests. The complete policy suites, formatting, and diff checks above are the applicable validation: https://docs.github.com/code-security/security-advisories/collaborating-in-a-temporary-private-fork-to-resolve-a-security-vulnerability
Written by an agent (Codex, GPT-5).
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "pnpm"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "10.34.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "pnpm"
},
"ranges": [
{
"events": [
{
"introduced": "11.0.0"
},
{
"fixed": "11.5.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-55487"
],
"database_specific": {
"cwe_ids": [
"CWE-346",
"CWE-693",
"CWE-829"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-26T23:18:13Z",
"nvd_published_at": "2026-06-25T18:16:40Z",
"severity": "HIGH"
},
"details": "## Summary\n\nKeep build approval for opaque dependency sources byte-exact for GHSA-5wx6-mg75-v57r / CAND-PNPM-123.\n\nMerged upstream commit `bf1b731ee6` fixed the original name-only approval bypass by making build policy consume the resolved dependency identity. One collision remained: the generic peer-suffix normalizer also stripped parenthesized text from git, URL, tarball, file, and other opaque locators. Approval for one source string could therefore authorize a different attacker-controlled source whose locator normalized to the same value.\n\n## Security boundary\n\n- Registry dependency identities still normalize legitimate peer suffixes and retain patch hashes.\n- Git, URL, tarball, file, directory, and otherwise opaque identities must match the complete resolved locator byte for byte.\n- Explicit denials use the same normalization as approvals.\n- Ignored-build output preserves the exact opaque identity, so the key pnpm asks a user to approve is the key policy later checks.\n- TypeScript pnpm and pacquet implement the same distinction between registry and opaque identities.\n\n## Exploit replay\n\n- With `allowBuilds` approving `foo@https://host/pkg.tgz`, the upstream implementation also accepted `foo@https://host/pkg.tgz(evil)` because both passed through peer-suffix removal.\n- An independent review found a second Rust-only form: `foo@https://host/pkg@1.0.0(good)` and `foo@https://host/pkg@1.0.0(evil)` collided because the parser selected the final `@` and misclassified the opaque URL as a registry package.\n- A final review found the same parser hazard in source-only locators ending in a semver-looking tail: approval for `https://host/pkg@1.0.0` could collapse `https://host/pkg@1.0.0(evil)`.\n- The final patch rejects all three collision forms, applies the same exactness to deny rules, accepts exact opaque keys as positive controls, and continues to accept registry packages approved without their peer suffixes.\n\n## Files changed\n\n- `building/policy/src/index.ts` and `building/policy/test/index.ts` normalize only parsed registry identities and retain exact opaque keys.\n- `pacquet/crates/package-manager/src/build_modules.rs` passes snapshot identities to policy, matches TypeScript package-separator parsing, and preserves opaque locators.\n- `pacquet/crates/package-manager/src/build_modules/tests.rs` covers exact approval and denial, all three collision forms, ignored-build output, and registry peer compatibility.\n- `.changeset/quiet-opaque-build-identities.md` records patch releases for `@pnpm/building.policy` and `pnpm`.\n\n## Commands run\n\n```text\n$ jest building/policy/test/index.ts --runInBand\n16 passed\n$ cargo test -p pacquet-package-manager build_modules::tests -- --nocapture\n49 passed\n$ cargo fmt --all -- --check\nPASS\n$ git diff --check 84bb4b1a046f3a659de1c9aab1d45dcf814124ce...HEAD\nPASS\n```\n\n## Validation\n\n- The TypeScript policy suite passed all 16 tests.\n- The final pacquet build-policy suite passed all 49 tests.\n- The new Rust regression reproduced the extra-`@` collision before the additive fix and passed afterward.\n- Exact opaque approval and denial, source-only semver-tail collision rejection, registry peer normalization, and ignored-build reporting all have paired tests.\n- ESLint passed on the changed TypeScript source and test files.\n- Rust formatting and diff checks passed; the branch is clean and consists of three focused security commits plus additive merges of upstream through `84bb4b1a046f3a659de1c9aab1d45dcf814124ce`.\n- The focused TypeScript suite and ESLint ran directly through the installed harness. The isolated project build cannot resolve workspace packages without a local install, and the configured registry gateway returns HTTP 403 while fetching `@pnpm/pacquet@0.11.2`; no candidate-focused test failed.\n\n## Patches\n\n`10.34.2`: https://github.com/pnpm/pnpm/commit/14bceb1e0b2a71f4f670774db261feb03f38ec23\n`11.5.3`: https://github.com/pnpm/pnpm/commit/bf1b731ee6c0ea98709e671ff0f46bf654480ab8\n\n## Compatibility\n\nRegistry package approvals keep their existing form. Opaque dependencies that were approved through a normalized parenthesized variant must now use the exact key shown in pnpm\u0027s ignored-build output. This is the intended trust-boundary change; no package-resolution or artifact format changes.\n\n## CI note\n\nGitHub intentionally does not run status checks on temporary private-fork pull requests. The complete policy suites, formatting, and diff checks above are the applicable validation: https://docs.github.com/code-security/security-advisories/collaborating-in-a-temporary-private-fork-to-resolve-a-security-vulnerability\n\n---\nWritten by an agent (Codex, GPT-5).",
"id": "GHSA-5wx6-mg75-v57r",
"modified": "2026-06-26T23:18:14Z",
"published": "2026-06-26T23:18:13Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/pnpm/pnpm/security/advisories/GHSA-5wx6-mg75-v57r"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-55487"
},
{
"type": "WEB",
"url": "https://github.com/pnpm/pnpm/commit/bf1b731ee6c0ea98709e671ff0f46bf654480ab8"
},
{
"type": "PACKAGE",
"url": "https://github.com/pnpm/pnpm"
},
{
"type": "WEB",
"url": "https://github.com/pnpm/pnpm/releases/tag/v10.34.2"
},
{
"type": "WEB",
"url": "https://github.com/pnpm/pnpm/releases/tag/v11.5.3"
}
],
"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": "pnpm: Manifest identity spoof satisfies allowBuilds and runs attacker lifecycle"
}
GHSA-64F4-8H54-QF3G
Vulnerability from github – Published: 2024-06-10 18:31 – Updated: 2026-04-01 18:31Improper Control of Filename for Include/Require Statement in PHP Program ('PHP Remote File Inclusion') vulnerability in Melapress MelaPress Login Security allows PHP Remote File Inclusion.This issue affects MelaPress Login Security: from n/a through 1.3.0.
{
"affected": [],
"aliases": [
"CVE-2024-35650"
],
"database_specific": {
"cwe_ids": [
"CWE-829",
"CWE-98"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-06-10T16:15:15Z",
"severity": "MODERATE"
},
"details": "Improper Control of Filename for Include/Require Statement in PHP Program (\u0027PHP Remote File Inclusion\u0027) vulnerability in Melapress MelaPress Login Security allows PHP Remote File Inclusion.This issue affects MelaPress Login Security: from n/a through 1.3.0.",
"id": "GHSA-64f4-8h54-qf3g",
"modified": "2026-04-01T18:31:49Z",
"published": "2024-06-10T18:31:08Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35650"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/Wordpress/Plugin/melapress-login-security/vulnerability/wordpress-melapress-login-security-plugin-1-3-0-remote-file-inclusion-vulnerability?_s_id=cve"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/vulnerability/melapress-login-security/wordpress-melapress-login-security-plugin-1-3-0-remote-file-inclusion-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-66C8-RQ2C-RH44
Vulnerability from github – Published: 2022-05-13 01:50 – Updated: 2022-05-13 01:50playSMS through 1.4.2 allows Privilege Escalation through Daemon abuse.
{
"affected": [],
"aliases": [
"CVE-2018-18387"
],
"database_specific": {
"cwe_ids": [
"CWE-829"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-10-29T18:29:00Z",
"severity": "HIGH"
},
"details": "playSMS through 1.4.2 allows Privilege Escalation through Daemon abuse.",
"id": "GHSA-66c8-rq2c-rh44",
"modified": "2022-05-13T01:50:40Z",
"published": "2022-05-13T01:50:40Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-18387"
},
{
"type": "WEB",
"url": "https://github.com/TheeBlind/CVE-2018-18387"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-695J-C63M-MVXC
Vulnerability from github – Published: 2025-06-30 21:30 – Updated: 2025-10-22 00:33Sudo before 1.9.17p1 allows local users to obtain root access because /etc/nsswitch.conf from a user-controlled directory is used with the --chroot option.
{
"affected": [],
"aliases": [
"CVE-2025-32463"
],
"database_specific": {
"cwe_ids": [
"CWE-829"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-06-30T21:15:30Z",
"severity": "CRITICAL"
},
"details": "Sudo before 1.9.17p1 allows local users to obtain root access because /etc/nsswitch.conf from a user-controlled directory is used with the --chroot option.",
"id": "GHSA-695j-c63m-mvxc",
"modified": "2025-10-22T00:33:19Z",
"published": "2025-06-30T21:30:54Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-32463"
},
{
"type": "WEB",
"url": "https://www.vicarius.io/vsociety/posts/cve-2025-32463-mitigate-sudo-vulnerability"
},
{
"type": "WEB",
"url": "https://www.vicarius.io/vsociety/posts/cve-2025-32463-detect-sudo-vulnerability"
},
{
"type": "WEB",
"url": "https://www.suse.com/support/update/announcement/2025/suse-su-202502177-1"
},
{
"type": "WEB",
"url": "https://www.suse.com/security/cve/CVE-2025-32463.html"
},
{
"type": "WEB",
"url": "https://www.sudo.ws/security/advisories/chroot_bug"
},
{
"type": "WEB",
"url": "https://www.sudo.ws/security/advisories"
},
{
"type": "WEB",
"url": "https://www.sudo.ws/releases/changelog"
},
{
"type": "WEB",
"url": "https://www.stratascale.com/vulnerability-alert-CVE-2025-32463-sudo-chroot"
},
{
"type": "WEB",
"url": "https://www.secpod.com/blog/sudo-lpe-vulnerabilities-resolved-what-you-need-to-know-about-cve-2025-32462-and-cve-2025-32463"
},
{
"type": "WEB",
"url": "https://www.openwall.com/lists/oss-security/2025/06/30/3"
},
{
"type": "WEB",
"url": "https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2025-32463"
},
{
"type": "WEB",
"url": "https://ubuntu.com/security/notices/USN-7604-1"
},
{
"type": "WEB",
"url": "https://security-tracker.debian.org/tracker/CVE-2025-32463"
},
{
"type": "WEB",
"url": "https://iototsecnews.jp/2025/07/01/linux-sudo-chroot-vulnerability-enables-hackers-to-elevate-privileges-to-root"
},
{
"type": "WEB",
"url": "https://explore.alas.aws.amazon.com/CVE-2025-32463.html"
},
{
"type": "WEB",
"url": "https://bugs.gentoo.org/show_bug.cgi?id=CVE-2025-32463"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/cve-2025-32463"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-6FF5-R6P2-HM4H
Vulnerability from github – Published: 2023-11-03 12:30 – Updated: 2023-11-03 12:30A local file inclusion vulnerability has been found in WPN-XM Serverstack affecting version 0.8.6, which would allow an unauthenticated user to perform a local file inclusion (LFI) via the /tools/webinterface/index.php?page parameter by sending a GET request. This vulnerability could lead to the loading of a PHP file on the server, leading to a critical webshell exploit.
{
"affected": [],
"aliases": [
"CVE-2023-4591"
],
"database_specific": {
"cwe_ids": [
"CWE-829"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-11-03T12:15:08Z",
"severity": "HIGH"
},
"details": "A local file inclusion vulnerability has been found in WPN-XM Serverstack affecting version 0.8.6, which would allow an unauthenticated user to perform a local file inclusion (LFI) via the /tools/webinterface/index.php?page parameter by sending a GET request. This vulnerability could lead to the loading of a PHP file on the server, leading to a critical webshell exploit.",
"id": "GHSA-6ff5-r6p2-hm4h",
"modified": "2023-11-03T12:30:32Z",
"published": "2023-11-03T12:30:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-4591"
},
{
"type": "WEB",
"url": "https://www.incibe.es/en/incibe-cert/notices/aviso/multiple-vulnerabilities-wpn-xm-serverstack"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-6HJW-MPPG-6486
Vulnerability from github – Published: 2022-05-24 17:05 – Updated: 2022-05-24 17:05If an image had not loaded correctly (such as when it is not actually an image), it could be dragged and dropped cross-domain, resulting in a cross-origin information leak. This vulnerability affects Firefox < 71.
{
"affected": [],
"aliases": [
"CVE-2019-17014"
],
"database_specific": {
"cwe_ids": [
"CWE-829"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-01-08T22:15:00Z",
"severity": "MODERATE"
},
"details": "If an image had not loaded correctly (such as when it is not actually an image), it could be dragged and dropped cross-domain, resulting in a cross-origin information leak. This vulnerability affects Firefox \u003c 71.",
"id": "GHSA-6hjw-mppg-6486",
"modified": "2022-05-24T17:05:49Z",
"published": "2022-05-24T17:05:49Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-17014"
},
{
"type": "WEB",
"url": "https://bugzilla.mozilla.org/show_bug.cgi?id=1322864"
},
{
"type": "WEB",
"url": "https://www.mozilla.org/security/advisories/mfsa2019-36"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-6M5Q-CC57-2MJ6
Vulnerability from github – Published: 2025-08-14 15:30 – Updated: 2025-08-14 15:30Untrusted data inclusion in pg_dump in PostgreSQL allows a malicious superuser of the origin server to inject arbitrary code for restore-time execution as the client operating system account running psql to restore the dump, via psql meta-commands. pg_dumpall is also affected. pg_restore is affected when used to generate a plain-format dump. This is similar to MySQL CVE-2024-21096. Versions before PostgreSQL 17.6, 16.10, 15.14, 14.19, and 13.22 are affected.
{
"affected": [],
"aliases": [
"CVE-2025-8714"
],
"database_specific": {
"cwe_ids": [
"CWE-829"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-08-14T13:15:37Z",
"severity": "HIGH"
},
"details": "Untrusted data inclusion in pg_dump in PostgreSQL allows a malicious superuser of the origin server to inject arbitrary code for restore-time execution as the client operating system account running psql to restore the dump, via psql meta-commands. pg_dumpall is also affected. pg_restore is affected when used to generate a plain-format dump. This is similar to MySQL CVE-2024-21096. Versions before PostgreSQL 17.6, 16.10, 15.14, 14.19, and 13.22 are affected.",
"id": "GHSA-6m5q-cc57-2mj6",
"modified": "2025-08-14T15:30:43Z",
"published": "2025-08-14T15:30:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-8714"
},
{
"type": "WEB",
"url": "https://www.postgresql.org/support/security/CVE-2025-8714"
}
],
"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"
}
]
}
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.