CWE-22
Allowed-with-ReviewImproper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Abstraction: Base · Status: Stable
The product uses external input to construct a pathname that is intended to identify a file or directory that is located underneath a restricted parent directory, but the product does not properly neutralize special elements within the pathname that can cause the pathname to resolve to a location that is outside of the restricted directory.
13217 vulnerabilities reference this CWE, most recent first.
GHSA-787J-9HGF-JXJ6
Vulnerability from github – Published: 2022-05-02 03:49 – Updated: 2022-05-02 03:49Directory traversal vulnerability in src/http/modules/ngx_http_dav_module.c in nginx (aka Engine X) before 0.7.63, and 0.8.x before 0.8.17, allows remote authenticated users to create or overwrite arbitrary files via a .. (dot dot) in the Destination HTTP header for the WebDAV (1) COPY or (2) MOVE method.
{
"affected": [],
"aliases": [
"CVE-2009-3898"
],
"database_specific": {
"cwe_ids": [
"CWE-22"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2009-11-24T17:30:00Z",
"severity": "MODERATE"
},
"details": "Directory traversal vulnerability in src/http/modules/ngx_http_dav_module.c in nginx (aka Engine X) before 0.7.63, and 0.8.x before 0.8.17, allows remote authenticated users to create or overwrite arbitrary files via a .. (dot dot) in the Destination HTTP header for the WebDAV (1) COPY or (2) MOVE method.",
"id": "GHSA-787j-9hgf-jxj6",
"modified": "2022-05-02T03:49:46Z",
"published": "2022-05-02T03:49:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2009-3898"
},
{
"type": "WEB",
"url": "http://archives.neohapsis.com/archives/fulldisclosure/2009-09/0379.html"
},
{
"type": "WEB",
"url": "http://marc.info/?l=oss-security\u0026m=125897327321676\u0026w=2"
},
{
"type": "WEB",
"url": "http://marc.info/?l=oss-security\u0026m=125897425223039\u0026w=2"
},
{
"type": "WEB",
"url": "http://marc.info/?l=oss-security\u0026m=125900327409842\u0026w=2"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/36818"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/48577"
},
{
"type": "WEB",
"url": "http://security.gentoo.org/glsa/glsa-201203-22.xml"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2009/11/20/1"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2009/11/23/10"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-7884-GGPR-27RJ
Vulnerability from github – Published: 2023-01-23 06:30 – Updated: 2023-01-30 21:30An arbitrary file upload vulnerability in the /api/upload component of zdir v3.2.0 allows attackers to execute arbitrary code via a crafted .ssh file.
{
"affected": [],
"aliases": [
"CVE-2023-23314"
],
"database_specific": {
"cwe_ids": [
"CWE-22"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-01-23T05:15:00Z",
"severity": "HIGH"
},
"details": "An arbitrary file upload vulnerability in the /api/upload component of zdir v3.2.0 allows attackers to execute arbitrary code via a crafted .ssh file.",
"id": "GHSA-7884-ggpr-27rj",
"modified": "2023-01-30T21:30:22Z",
"published": "2023-01-23T06:30:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-23314"
},
{
"type": "WEB",
"url": "https://github.com/helloxz/zdir/issues/90"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-788G-CGCF-P4X6
Vulnerability from github – Published: 2022-05-02 00:00 – Updated: 2022-05-02 00:00Directory traversal vulnerability in the user_get_profile function in include/functions.inc.php in Coppermine Photo Gallery (CPG) 1.4.18 and earlier, when the charset is utf-8, allows remote attackers to include and execute arbitrary local files via a .. (dot dot) in the lang part of serialized data in an _data cookie.
{
"affected": [],
"aliases": [
"CVE-2008-3486"
],
"database_specific": {
"cwe_ids": [
"CWE-22"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2008-08-06T17:41:00Z",
"severity": "HIGH"
},
"details": "Directory traversal vulnerability in the user_get_profile function in include/functions.inc.php in Coppermine Photo Gallery (CPG) 1.4.18 and earlier, when the charset is utf-8, allows remote attackers to include and execute arbitrary local files via a .. (dot dot) in the lang part of serialized data in an _data cookie.",
"id": "GHSA-788g-cgcf-p4x6",
"modified": "2022-05-02T00:00:37Z",
"published": "2022-05-02T00:00:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2008-3486"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/44133"
},
{
"type": "WEB",
"url": "https://www.exploit-db.com/exploits/6178"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/31295"
},
{
"type": "WEB",
"url": "http://securityreason.com/securityalert/4108"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/30480"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-78F9-745F-278P
Vulnerability from github – Published: 2022-08-12 15:38 – Updated: 2022-08-12 15:38Impact
A partial Directory Traversal Vulnerability found in apoc.log.stream function of apoc plugins in Neo4j Graph database.
This issue allows a malicious actor to potentially break out of the expected directory. The impact is limited to sibling directories. For example, userControlled.getCanonicalPath().startsWith("/usr/out") will allow an attacker to access a directory with a name like /usr/outnot.
Patches
The users should aim to use the latest released version compatible with their Neo4j version. The minimum versions containing patch for this vulnerability are 4.4.0.8 and 4.3.0.7
Workarounds
If you cannot upgrade the library, you can control the allowlist of the functions that can be used in your system
For more information
If you have any questions or comments about this advisory: - Open an issue in neo4j-apoc-procedures - Email us at security@neo4j.com
Credits
We want to publicly recognise the contribution of Jonathan Leitschuh for reporting this issue.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.neo4j.procedure:apoc"
},
"ranges": [
{
"events": [
{
"introduced": "4.4.0.0"
},
{
"fixed": "4.4.0.8"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.neo4j.procedure:apoc"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.3.0.7"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-37423"
],
"database_specific": {
"cwe_ids": [
"CWE-22"
],
"github_reviewed": true,
"github_reviewed_at": "2022-08-12T15:38:33Z",
"nvd_published_at": "2022-08-12T15:15:00Z",
"severity": "MODERATE"
},
"details": "### Impact\nA partial Directory Traversal Vulnerability found in `apoc.log.stream` function of apoc plugins in Neo4j Graph database. \nThis issue allows a malicious actor to potentially break out of the expected directory. The impact is limited to sibling directories. For example, `userControlled.getCanonicalPath().startsWith(\"/usr/out\")` will allow an attacker to access a directory with a name like `/usr/outnot`.\n\n### Patches\nThe users should aim to use the latest released version compatible with their Neo4j version. The minimum versions containing patch for this vulnerability are 4.4.0.8 and 4.3.0.7\n\n### Workarounds\nIf you cannot upgrade the library, you can control the [allowlist of the functions](https://neo4j.com/docs/operations-manual/current/reference/configuration-settings/#config_dbms.security.procedures.allowlist) that can be used in your system\n\n\n### For more information\nIf you have any questions or comments about this advisory:\n- Open an issue in [neo4j-apoc-procedures](https://github.com/neo4j-contrib/neo4j-apoc-procedures)\n- Email us at [security@neo4j.com](mailto:security@neo4j.com)\n\n### Credits\nWe want to publicly recognise the contribution of [Jonathan Leitschuh](https://github.com/JLLeitschuh) for reporting this issue.\n ",
"id": "GHSA-78f9-745f-278p",
"modified": "2022-08-12T15:38:33Z",
"published": "2022-08-12T15:38:33Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/neo4j-contrib/neo4j-apoc-procedures/security/advisories/GHSA-78f9-745f-278p"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-37423"
},
{
"type": "WEB",
"url": "https://github.com/neo4j-contrib/neo4j-apoc-procedures/pull/3080"
},
{
"type": "WEB",
"url": "https://github.com/neo4j-contrib/neo4j-apoc-procedures/commit/d2f415c6f703bbc2cda4a753928821ff15d5c620"
},
{
"type": "WEB",
"url": "https://github.com/neo4j-contrib/neo4j-apoc-procedures/commit/fe9f8c77269f5a742585c1d62324eb70755de510"
},
{
"type": "PACKAGE",
"url": "https://github.com/neo4j-contrib/neo4j-apoc-procedures"
},
{
"type": "WEB",
"url": "https://neo4j.com/docs/aura/platform/apoc"
}
],
"schema_version": "1.4.0",
"severity": [],
"summary": "Neo4j Graph apoc plugins Partial Path Traversal Vulnerability"
}
GHSA-78FC-9688-W8XW
Vulnerability from github – Published: 2026-05-04 17:39 – Updated: 2026-05-08 19:25Affected Versions
version ≤ 2.7.8 (latest version at time of disclosure)
https://github.com/openmrs/openmrs-core
Impact
The endpoint POST /openmrs/ws/rest/v1/module is vulnerable to a path traversal (Zip Slip) attack. An authenticated attacker can upload a crafted .omod archive containing ZIP entries with directory traversal sequences. Upon automatic extraction by the server, the incomplete path validation in WebModuleUtil.startModule() fails to prevent entries such as web/module/../../../../malicious.jsp from being written outside the intended module directory. If the traversal target falls within the web application root (e.g., /usr/local/tomcat/webapps/openmrs/), the attacker achieves arbitrary file write and subsequent Remote Code Execution.
Notably, other extraction methods in the same codebase (ModuleUtil.expandJar(), TestInstallUtil.addZippedTestModules()) are properly protected with normalize().startsWith() checks — this vulnerability is an oversight where the same fix was not applied.
Furthermore, the module.allow_web_admin runtime property, which is intended to restrict administrators from managing modules via the web interface, only gates the Legacy UI controller entry point. The REST API endpoint POST /openmrs/ws/rest/v1/module does not check this property, allowing this restriction to be fully bypassed.
Steps to Reproduce
- Construct a malicious
.omodfile (which is a ZIP/JAR archive) containing a ZIP entry with a path traversal payload in its entry name, such asweb/module/../../../../<target_filename>. Upload this file toPOST /openmrs/ws/rest/v1/modulewith valid admin credentials via Basic Auth.
- The server parses and loads the module. During
WebModuleUtil.startModule(), entries underweb/module/are automatically extracted. The existing checkPaths.get(name).startsWith("..")only blocks entries beginning with.., so an entry starting withweb/module/passes the check. The../sequences in the remaining path cause the file to be written outside the intendedWEB-INF/view/module/directory — for example, into the web application root at/usr/local/tomcat/webapps/openmrs/.
- The traversed file is now accessible under the web application root. If the written file is a JSP script, accessing it via the browser triggers server-side execution, achieving RCE.
Root Cause Analysis
The vulnerability exists in WebModuleUtil.startModule() (web/src/main/java/org/openmrs/module/web/WebModuleUtil.java).
Vulnerable code:
Enumeration<JarEntry> entries = jarFile.entries();
while (entries.hasMoreElements()) {
JarEntry entry = entries.nextElement();
String name = entry.getName();
// ❌ Incomplete check — only blocks entries starting with ".."
if (Paths.get(name).startsWith("..")) {
throw new UnsupportedOperationException("...");
}
if (name.startsWith("web/module/")) {
String filepath = name.substring(11);
StringBuilder absPath = new StringBuilder(realPath + "/WEB-INF");
absPath.append("/view/module/");
absPath.append(mod.getModuleIdAsPath()).append("/").append(filepath);
// ❌ No normalize() or startsWith() boundary check before writing
File outFile = new File(absPath.toString().replace("/", File.separator));
outStream = new FileOutputStream(outFile, false);
inStream = jarFile.getInputStream(entry);
OpenmrsUtil.copyFile(inStream, outStream);
}
}
Why the check fails: For an entry named web/module/foo/../../../../evil.jsp, Paths.get(name) starts with web, not .., so the check passes. After name.substring(11), the filepath foo/../../../../evil.jsp is concatenated directly into the output path without normalization, resulting in a write outside the intended directory.
Correctly protected code in the same codebase:
ModuleUtil.expandJar():
// ✅ Correct — uses normalize().startsWith()
if (!parent.toPath().normalize().startsWith(docBase)) {
throw new UnsupportedOperationException("...");
}
TestInstallUtil.addZippedTestModules():
// ✅ Correct — uses normalize().startsWith()
if (!zipEntryFile.toPath().normalize().startsWith(moduleRepository.toPath().normalize())) {
throw new IOException("Bad zip entry");
}
The fix pattern is already known and applied elsewhere in the codebase. WebModuleUtil.startModule() is an oversight.
Bypass of module.allow_web_admin
The module.allow_web_admin property only restricts module operations at the Legacy UI layer (ModuleListController). The REST API endpoint does not consult this property:
Legacy UI: POST /admin/modules/moduleList.form → allowAdmin() check → [BLOCKED]
REST API: POST /ws/rest/v1/module → No allowAdmin() check → [ALLOWED]
↓
ModuleFactory.loadModule()
↓
WebModuleUtil.startModule() ← Zip Slip here, no allowAdmin check
↓
FileOutputStream.write() ← Arbitrary file write
Remediation
Add normalize().startsWith() boundary validation before writing, consistent with the existing pattern in ModuleUtil.expandJar():
File outFile = new File(absPath.toString().replace("/", File.separator));
// ✅ Add this check
if (!outFile.toPath().normalize().startsWith(
Paths.get(realPath, "WEB-INF").normalize())) {
throw new UnsupportedOperationException(
"Zip entry '" + name + "' would be written outside the allowed directory.");
}
Additionally, enforce the module.allow_web_admin restriction consistently across all module upload entry points, including the REST API.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.openmrs.web:openmrs-web"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "2.7.8"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.openmrs.web:openmrs-web"
},
"ranges": [
{
"events": [
{
"introduced": "2.8.0"
},
{
"last_affected": "2.8.5"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-40076"
],
"database_specific": {
"cwe_ids": [
"CWE-22"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-04T17:39:31Z",
"nvd_published_at": "2026-05-06T20:16:31Z",
"severity": "CRITICAL"
},
"details": "## Affected Versions\n\nversion \u2264 2.7.8 (latest version at time of disclosure)\n\nhttps://github.com/openmrs/openmrs-core\n\n## Impact\n\nThe endpoint `POST /openmrs/ws/rest/v1/module` is vulnerable to a path traversal (Zip Slip) attack. An authenticated attacker can upload a crafted `.omod` archive containing ZIP entries with directory traversal sequences. Upon automatic extraction by the server, the incomplete path validation in `WebModuleUtil.startModule()` fails to prevent entries such as `web/module/../../../../malicious.jsp` from being written outside the intended module directory. If the traversal target falls within the web application root (e.g., `/usr/local/tomcat/webapps/openmrs/`), the attacker achieves arbitrary file write and subsequent Remote Code Execution.\n\nNotably, other extraction methods in the same codebase (`ModuleUtil.expandJar()`, `TestInstallUtil.addZippedTestModules()`) are properly protected with `normalize().startsWith()` checks \u2014 this vulnerability is an oversight where the same fix was not applied.\n\nFurthermore, the `module.allow_web_admin` runtime property, which is intended to restrict administrators from managing modules via the web interface, only gates the Legacy UI controller entry point. The REST API endpoint `POST /openmrs/ws/rest/v1/module` does not check this property, allowing this restriction to be fully bypassed.\n\n## Steps to Reproduce\n\n1. Construct a malicious `.omod` file (which is a ZIP/JAR archive) containing a ZIP entry with a path traversal payload in its entry name, such as `web/module/../../../../\u003ctarget_filename\u003e`. Upload this file to `POST /openmrs/ws/rest/v1/module` with valid admin credentials via Basic Auth.\n\n\u003cimg width=\"1986\" height=\"1102\" alt=\"image\" src=\"https://github.com/user-attachments/assets/647f15de-7e8c-40b9-aba9-d4db5d2e0b52\" /\u003e\n\n\u003cimg width=\"2048\" height=\"1078\" alt=\"image\" src=\"https://github.com/user-attachments/assets/301412a0-e3b0-4afb-91c2-e9739de3080d\" /\u003e\n\n\n2. The server parses and loads the module. During `WebModuleUtil.startModule()`, entries under `web/module/` are automatically extracted. The existing check `Paths.get(name).startsWith(\"..\")` only blocks entries beginning with `..`, so an entry starting with `web/module/` passes the check. The `../` sequences in the remaining path cause the file to be written outside the intended `WEB-INF/view/module/` directory \u2014 for example, into the web application root at `/usr/local/tomcat/webapps/openmrs/`.\n\n\u003cimg width=\"1439\" height=\"141\" alt=\"image\" src=\"https://github.com/user-attachments/assets/4bda3b1e-a80e-42ed-af2b-a1da53e8db03\" /\u003e\n\n3. The traversed file is now accessible under the web application root. If the written file is a JSP script, accessing it via the browser triggers server-side execution, achieving RCE.\n\n\u003cimg width=\"1482\" height=\"300\" alt=\"image\" src=\"https://github.com/user-attachments/assets/61936002-78cd-4203-80f0-f0a8702b216c\" /\u003e\n\n## Root Cause Analysis\n\nThe vulnerability exists in `WebModuleUtil.startModule()` (`web/src/main/java/org/openmrs/module/web/WebModuleUtil.java`).\n\n### Vulnerable code:\n\n```java\nEnumeration\u003cJarEntry\u003e entries = jarFile.entries();\nwhile (entries.hasMoreElements()) {\n JarEntry entry = entries.nextElement();\n String name = entry.getName();\n\n // \u274c Incomplete check \u2014 only blocks entries starting with \"..\"\n if (Paths.get(name).startsWith(\"..\")) {\n throw new UnsupportedOperationException(\"...\");\n }\n\n if (name.startsWith(\"web/module/\")) {\n String filepath = name.substring(11);\n StringBuilder absPath = new StringBuilder(realPath + \"/WEB-INF\");\n absPath.append(\"/view/module/\");\n absPath.append(mod.getModuleIdAsPath()).append(\"/\").append(filepath);\n\n // \u274c No normalize() or startsWith() boundary check before writing\n File outFile = new File(absPath.toString().replace(\"/\", File.separator));\n outStream = new FileOutputStream(outFile, false);\n inStream = jarFile.getInputStream(entry);\n OpenmrsUtil.copyFile(inStream, outStream);\n }\n}\n```\n\n**Why the check fails:** For an entry named `web/module/foo/../../../../evil.jsp`, `Paths.get(name)` starts with `web`, not `..`, so the check passes. After `name.substring(11)`, the filepath `foo/../../../../evil.jsp` is concatenated directly into the output path without normalization, resulting in a write outside the intended directory.\n\n### Correctly protected code in the same codebase:\n\n**`ModuleUtil.expandJar()`:**\n\n```java\n// \u2705 Correct \u2014 uses normalize().startsWith()\nif (!parent.toPath().normalize().startsWith(docBase)) {\n throw new UnsupportedOperationException(\"...\");\n}\n```\n\n**`TestInstallUtil.addZippedTestModules()`:**\n\n```java\n// \u2705 Correct \u2014 uses normalize().startsWith()\nif (!zipEntryFile.toPath().normalize().startsWith(moduleRepository.toPath().normalize())) {\n throw new IOException(\"Bad zip entry\");\n}\n```\n\nThe fix pattern is already known and applied elsewhere in the codebase. `WebModuleUtil.startModule()` is an oversight.\n\n### Bypass of `module.allow_web_admin`\n\nThe `module.allow_web_admin` property only restricts module operations at the Legacy UI layer (`ModuleListController`). The REST API endpoint does not consult this property:\n\n```\nLegacy UI: POST /admin/modules/moduleList.form \u2192 allowAdmin() check \u2192 [BLOCKED]\nREST API: POST /ws/rest/v1/module \u2192 No allowAdmin() check \u2192 [ALLOWED]\n \u2193\n ModuleFactory.loadModule()\n \u2193\n WebModuleUtil.startModule() \u2190 Zip Slip here, no allowAdmin check\n \u2193\n FileOutputStream.write() \u2190 Arbitrary file write\n```\n\n## Remediation\n\nAdd `normalize().startsWith()` boundary validation before writing, consistent with the existing pattern in `ModuleUtil.expandJar()`:\n\n```java\nFile outFile = new File(absPath.toString().replace(\"/\", File.separator));\n\n// \u2705 Add this check\nif (!outFile.toPath().normalize().startsWith(\n Paths.get(realPath, \"WEB-INF\").normalize())) {\n throw new UnsupportedOperationException(\n \"Zip entry \u0027\" + name + \"\u0027 would be written outside the allowed directory.\");\n}\n```\n\nAdditionally, enforce the `module.allow_web_admin` restriction consistently across all module upload entry points, including the REST API.",
"id": "GHSA-78fc-9688-w8xw",
"modified": "2026-05-08T19:25:59Z",
"published": "2026-05-04T17:39:31Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/openmrs/openmrs-core/security/advisories/GHSA-78fc-9688-w8xw"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-40076"
},
{
"type": "PACKAGE",
"url": "https://github.com/openmrs/openmrs-core"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/",
"type": "CVSS_V4"
}
],
"summary": "OpenMRS Module Upload Vulnerable to Path Traversal (Zip Slip)"
}
GHSA-78FV-P8MJ-WXVM
Vulnerability from github – Published: 2025-12-24 00:30 – Updated: 2025-12-24 00:30Deciso OPNsense diag_backup.php filename Directory Traversal Arbitrary File Creation Vulnerability. This vulnerability allows network-adjacent attackers to create arbitrary files on affected installations of Deciso OPNsense. Authentication is required to exploit this vulnerability.
The specific flaw exists within the handling of backup configuration files. The issue results from the lack of proper validation of a user-supplied path prior to using it in file operations. An attacker can leverage this vulnerability to create files in the context of root. Was ZDI-CAN-28133.
{
"affected": [],
"aliases": [
"CVE-2025-13698"
],
"database_specific": {
"cwe_ids": [
"CWE-22"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-12-23T22:15:44Z",
"severity": "MODERATE"
},
"details": "Deciso OPNsense diag_backup.php filename Directory Traversal Arbitrary File Creation Vulnerability. This vulnerability allows network-adjacent attackers to create arbitrary files on affected installations of Deciso OPNsense. Authentication is required to exploit this vulnerability.\n\nThe specific flaw exists within the handling of backup configuration files. The issue results from the lack of proper validation of a user-supplied path prior to using it in file operations. An attacker can leverage this vulnerability to create files in the context of root. Was ZDI-CAN-28133.",
"id": "GHSA-78fv-p8mj-wxvm",
"modified": "2025-12-24T00:30:13Z",
"published": "2025-12-24T00:30:13Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-13698"
},
{
"type": "WEB",
"url": "https://github.com/opnsense/core/commit/cb15c935137d05c86a1e6cf12af877e9c32a23af"
},
{
"type": "WEB",
"url": "https://www.zerodayinitiative.com/advisories/ZDI-25-1022"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:A/AC:L/PR:H/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-78H7-FGQ9-625X
Vulnerability from github – Published: 2018-07-23 20:40 – Updated: 2023-09-11 16:38Affected versions of quickserver resolve relative file paths, resulting in a directory traversal vulnerability. A malicious actor can use this vulnerability to access files outside of the intended directory root, which may result in the disclosure of private files on the vulnerable system.
Example request:
GET /../../../../../../../../../../etc/passwd HTTP/1.1
host:foo
Recommendation
No patch is available for this vulnerability.
It is recommended that the package is only used for local development, and if the functionality is needed for production, a different package is used instead.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "quickserver"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "1.1.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2017-16196"
],
"database_specific": {
"cwe_ids": [
"CWE-22"
],
"github_reviewed": true,
"github_reviewed_at": "2020-06-16T21:22:07Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "Affected versions of `quickserver` resolve relative file paths, resulting in a directory traversal vulnerability. A malicious actor can use this vulnerability to access files outside of the intended directory root, which may result in the disclosure of private files on the vulnerable system.\n\n**Example request:**\n```http\nGET /../../../../../../../../../../etc/passwd HTTP/1.1\nhost:foo\n```\n\n\n## Recommendation\n\nNo patch is available for this vulnerability.\n\nIt is recommended that the package is only used for local development, and if the functionality is needed for production, a different package is used instead.",
"id": "GHSA-78h7-fgq9-625x",
"modified": "2023-09-11T16:38:49Z",
"published": "2018-07-23T20:40:14Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-16196"
},
{
"type": "WEB",
"url": "https://github.com/JacksonGL/NPM-Vuln-PoC/blob/master/directory-traversal/quickserver"
},
{
"type": "ADVISORY",
"url": "https://github.com/advisories/GHSA-78h7-fgq9-625x"
},
{
"type": "WEB",
"url": "https://www.npmjs.com/advisories/433"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Directory Traversal in quickserver"
}
GHSA-78JW-CRHQ-XF4R
Vulnerability from github – Published: 2022-05-17 01:22 – Updated: 2022-05-17 01:22Directory traversal vulnerability in unshield 1.0-1.
{
"affected": [],
"aliases": [
"CVE-2015-1386"
],
"database_specific": {
"cwe_ids": [
"CWE-22"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-08-28T15:29:00Z",
"severity": "HIGH"
},
"details": "Directory traversal vulnerability in unshield 1.0-1.",
"id": "GHSA-78jw-crhq-xf4r",
"modified": "2022-05-17T01:22:09Z",
"published": "2022-05-17T01:22:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2015-1386"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=1185717"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2015/01/27/27"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-78M5-JPMF-CH7V
Vulnerability from github – Published: 2022-12-05 23:34 – Updated: 2024-11-18 16:26Summary
Unsafe extracting using shutil.unpack_archive() from a remotely retrieved tarball may lead to writing the extracted file to an unintended destination.
Details
Extracting files using shutil.unpack_archive() from a potentially malicious tarball without validating that the destination file path is within the intended destination directory can cause files outside the destination directory to be overwritten.
The vulnerable code snippet is between L153..158.
response = requests.get(url, stream=True)
with open(zippath, "wb") as f:
f.write(response.raw.read())
shutil.unpack_archive(zippath, unzippedpath)
It seems that a remotely retrieved tarball which could be with the extension .tar.gz happens to be unpacked using shutil.unpack_archive() with no destination verification/limitation of the extracted files.
PoC
The PoC provided showcases the risk of extracting the non-harmless text file sim4n6.txt to a parent location rather than the current folder.
> tar --list -f archive.tar
tar: Removing leading `../../../' from member names
../../../sim4n6.txt
> python3
Python 3.10.6 (main, Nov 2 2022, 18:53:38) [GCC 11.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import shutil
>>> shutil.unpack_archive("archive.tar")
>>> exit()
> file ../../../sim4n6.txt
../../../sim4n6.txt: ASCII text
A Potential Attack Scenario
- An attacker may craft a malicious tarball with a filename path, such as
../../../../../../../../etc/passwd, and then serve the archive remotely, thus, providing a possibility to overwrite the system files.
Mitigation
Potential mitigation could be to:
- Use a safer module, like zipfile.
- Validate the location of the extracted files and discard those with malicious paths such as a relative path .. or absolute ones.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.1.7"
},
"package": {
"ecosystem": "PyPI",
"name": "guarddog"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.1.8"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-23530"
],
"database_specific": {
"cwe_ids": [
"CWE-22"
],
"github_reviewed": true,
"github_reviewed_at": "2022-12-05T23:34:43Z",
"nvd_published_at": "2022-12-16T23:15:00Z",
"severity": "LOW"
},
"details": "### Summary\n\nUnsafe extracting using `shutil.unpack_archive()` from a remotely retrieved tarball may lead to writing the extracted file to an unintended destination.\n\n### Details\n\nExtracting files using `shutil.unpack_archive()` from a potentially malicious tarball without validating that the destination file path is within the intended destination directory can cause files outside the destination directory to be overwritten. \n\nThe vulnerable code snippet is between [L153..158](https://github.com/DataDog/guarddog/blob/a1d064ceb09d39bb28deb6972bc0a278756ea91f/guarddog/scanners/package_scanner.py#L153..158). \n\n```python\nresponse = requests.get(url, stream=True)\n\nwith open(zippath, \"wb\") as f:\n f.write(response.raw.read())\n\nshutil.unpack_archive(zippath, unzippedpath)\n```\nIt seems that a remotely retrieved tarball which could be with the extension `.tar.gz` happens to be unpacked using `shutil.unpack_archive()` with no destination verification/limitation of the extracted files.\n\n### PoC\n\nThe PoC provided showcases the risk of extracting the non-harmless text file `sim4n6.txt` to a parent location rather than the current folder. \n\n```bash\n\u003e tar --list -f archive.tar\ntar: Removing leading `../../../\u0027 from member names\n../../../sim4n6.txt\n\n\u003e python3 \nPython 3.10.6 (main, Nov 2 2022, 18:53:38) [GCC 11.3.0] on linux\nType \"help\", \"copyright\", \"credits\" or \"license\" for more information.\n\u003e\u003e\u003e import shutil\n\u003e\u003e\u003e shutil.unpack_archive(\"archive.tar\")\n\u003e\u003e\u003e exit()\n\n\u003e file ../../../sim4n6.txt\n../../../sim4n6.txt: ASCII text\n```\n\n### A Potential Attack Scenario\n\n- An attacker may craft a malicious tarball with a filename path, such as `../../../../../../../../etc/passwd`, and then serve the archive remotely, thus, providing a possibility to overwrite the system files.\n\n### Mitigation\n\nPotential mitigation could be to:\n- Use a safer module, like `zipfile`.\n- Validate the location of the extracted files and discard those with malicious paths such as a relative path `..` or absolute ones. ",
"id": "GHSA-78m5-jpmf-ch7v",
"modified": "2024-11-18T16:26:28Z",
"published": "2022-12-05T23:34:43Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/DataDog/guarddog/security/advisories/GHSA-78m5-jpmf-ch7v"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-23530"
},
{
"type": "WEB",
"url": "https://github.com/DataDog/guarddog/commit/37c7d0767ba28f4df46117d478f97652594c491c"
},
{
"type": "PACKAGE",
"url": "https://github.com/DataDog/guarddog"
},
{
"type": "WEB",
"url": "https://github.com/DataDog/guarddog/blob/a1d064ceb09d39bb28deb6972bc0a278756ea91f/guarddog/scanners/package_scanner.py#L153..158"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/guarddog/PYSEC-2022-42993.yaml"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:L/I:L/A:L",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:L/VI:L/VA:L/SC:L/SI:L/SA:L",
"type": "CVSS_V4"
}
],
"summary": "GuardDog vulnerable to arbitrary file write when scanning a specially-crafted remote PyPI package"
}
GHSA-78QJ-MXW5-P7QP
Vulnerability from github – Published: 2026-01-07 18:30 – Updated: 2026-01-07 21:31Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') vulnerability in Wikimedia Foundation MediaWiki - CSS extension allows Path Traversal.This issue affects MediaWiki - CSS extension: 1.44, 1.43, 1.39.
{
"affected": [],
"aliases": [
"CVE-2026-0669"
],
"database_specific": {
"cwe_ids": [
"CWE-22"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-01-07T18:15:53Z",
"severity": "HIGH"
},
"details": "Improper Limitation of a Pathname to a Restricted Directory (\u0027Path Traversal\u0027) vulnerability in Wikimedia Foundation MediaWiki - CSS extension allows Path Traversal.This issue affects MediaWiki - CSS extension: 1.44, 1.43, 1.39.",
"id": "GHSA-78qj-mxw5-p7qp",
"modified": "2026-01-07T21:31:55Z",
"published": "2026-01-07T18:30:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-0669"
},
{
"type": "WEB",
"url": "https://gerrit.wikimedia.org/r/q/Ia15bf3f2e5a341868568492a736ac3dbf706c22e"
},
{
"type": "WEB",
"url": "https://phabricator.wikimedia.org/T401526"
}
],
"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"
}
]
}
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-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-20.1
Strategy: Input Validation
- Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.
- Use a built-in path canonicalization function (such as realpath() in C) that produces the canonical version of the pathname, which effectively removes ".." sequences and symbolic links (CWE-23, CWE-59). This includes:
- realpath() in C
- getCanonicalPath() in Java
- GetFullPath() in ASP.NET
- realpath() or abs_path() in Perl
- realpath() in PHP
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-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].
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-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-185] provide this capability.
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-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-39
- Ensure that error messages only contain minimal details that are useful to the intended audience and no one else. The messages need to strike the balance between being too cryptic (which can confuse users) or being too detailed (which may reveal more than intended). The messages should not reveal the methods that were used to determine the error. Attackers can use detailed information to refine or optimize their original attack, thereby increasing their chances of success.
- If errors must be captured in some detail, record them in log messages, but consider what could occur if the log messages can be viewed by attackers. Highly sensitive information such as passwords should never be saved to log files.
- Avoid inconsistent messaging that might accidentally tip off an attacker about internal state, such as whether a user account exists or not.
- In the context of path traversal, error messages which disclose path information can help attackers craft the appropriate attack strings to move through the file system hierarchy.
Mitigation MIT-16
Strategy: Environment Hardening
When using PHP, configure the application so that it does not use register_globals. During implementation, develop the application so that it does not rely on this feature, but be wary of implementing a register_globals emulation that is subject to weaknesses such as CWE-95, CWE-621, and similar issues.
CAPEC-126: Path Traversal
An adversary uses path manipulation methods to exploit insufficient input validation of a target to obtain access to data that should be not be retrievable by ordinary well-formed requests. A typical variety of this attack involves specifying a path to a desired file together with dot-dot-slash characters, resulting in the file access API or function traversing out of the intended directory structure and into the root file system. By replacing or modifying the expected path information the access function or API retrieves the file desired by the attacker. These attacks either involve the attacker providing a complete path to a targeted file or using control characters (e.g. path separators (/ or \) and/or dots (.)) to reach desired directories or files.
CAPEC-64: Using Slashes and URL Encoding Combined to Bypass Validation Logic
This attack targets the encoding of the URL combined with the encoding of the slash characters. An attacker can take advantage of the multiple ways of encoding a URL and abuse the interpretation of the URL. A URL may contain special character that need special syntax handling in order to be interpreted. Special characters are represented using a percentage character followed by two digits representing the octet code of the original character (%HEX-CODE). For instance US-ASCII space character would be represented with %20. This is often referred as escaped ending or percent-encoding. Since the server decodes the URL from the requests, it may restrict the access to some URL paths by validating and filtering out the URL requests it received. An attacker will try to craft an URL with a sequence of special characters which once interpreted by the server will be equivalent to a forbidden URL. It can be difficult to protect against this attack since the URL can contain other format of encoding such as UTF-8 encoding, Unicode-encoding, etc.
CAPEC-76: Manipulating Web Input to File System Calls
An attacker manipulates inputs to the target software which the target software passes to file system calls in the OS. The goal is to gain access to, and perhaps modify, areas of the file system that the target software did not intend to be accessible.
CAPEC-78: Using Escaped Slashes in Alternate Encoding
This attack targets the use of the backslash in alternate encoding. An adversary can provide a backslash as a leading character and causes a parser to believe that the next character is special. This is called an escape. By using that trick, the adversary tries to exploit alternate ways to encode the same character which leads to filter problems and opens avenues to attack.
CAPEC-79: Using Slashes in Alternate Encoding
This attack targets the encoding of the Slash characters. An adversary would try to exploit common filtering problems related to the use of the slashes characters to gain access to resources on the target host. Directory-driven systems, such as file systems and databases, typically use the slash character to indicate traversal between directories or other container components. For murky historical reasons, PCs (and, as a result, Microsoft OSs) choose to use a backslash, whereas the UNIX world typically makes use of the forward slash. The schizophrenic result is that many MS-based systems are required to understand both forms of the slash. This gives the adversary many opportunities to discover and abuse a number of common filtering problems. The goal of this pattern is to discover server software that only applies filters to one version, but not the other.