CWE-23
AllowedRelative Path Traversal
Abstraction: Base · Status: Draft
The product uses external input to construct a pathname that should be within a restricted directory, but it does not properly neutralize sequences such as ".." that can resolve to a location that is outside of that directory.
778 vulnerabilities reference this CWE, most recent first.
GHSA-48RR-FH2M-HHJH
Vulnerability from github – Published: 2024-11-18 06:30 – Updated: 2024-11-18 06:30The DVC from TRCore has a Path Traversal vulnerability, allowing unauthenticated remote attackers to exploit this vulnerability to read arbitrary system files.
{
"affected": [],
"aliases": [
"CVE-2024-11309"
],
"database_specific": {
"cwe_ids": [
"CWE-22",
"CWE-23"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-11-18T06:15:04Z",
"severity": "HIGH"
},
"details": "The DVC from TRCore has a Path Traversal vulnerability, allowing unauthenticated remote attackers to exploit this vulnerability to read arbitrary system files.",
"id": "GHSA-48rr-fh2m-hhjh",
"modified": "2024-11-18T06:30:36Z",
"published": "2024-11-18T06:30:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-11309"
},
{
"type": "WEB",
"url": "https://www.twcert.org.tw/en/cp-139-8243-3d818-2.html"
},
{
"type": "WEB",
"url": "https://www.twcert.org.tw/tw/cp-132-8242-384a1-1.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-48X2-6PR9-2JJF
Vulnerability from github – Published: 2026-06-19 21:42 – Updated: 2026-06-19 21:42Summary
EnvironmentManager.restore(env, backupId) computes the backup path with join(envDir, '.backups', backupId) and only checks that this path exists. It does not resolve the result or verify that it remains under data/<env>/.backups.
A caller can pass a traversal backup ID such as ../../../outside/source-dir to restore files from an arbitrary directory into the target environment data directory. Confirmed in Network-AI 5.12.1.
Details
restore() builds backupPath directly from caller-controlled backupId:
restore(env: EnvName, backupId: string): RestoreResult {
const envDir = this.getDataDir(env);
const backupsDir = join(envDir, '.backups');
const backupPath = join(backupsDir, backupId);
if (!existsSync(backupPath)) {
throw new Error(`Backup '${backupId}' not found for environment '${env}'`);
}
this.backup(env);
const files = this._collectBackupFiles(backupPath);
let restored = 0;
for (const rel of files) {
if (rel === '_manifest.json') continue;
const src = join(backupPath, rel);
const dst = join(envDir, rel);
try {
mkdirSync(join(envDir, rel.includes('/') ? rel.substring(0, rel.lastIndexOf('/')) : '.'), { recursive: true });
copyFileSync(src, dst);
restored++;
} catch { /* skip */ }
}
return { backupId, env, filesRestored: restored };
}
There is no resolved containment check that ensures backupPath remains under backupsDir.
Default CLI reachability exists through network-ai env backup restore --env <env> --backup <id>.
Affected source evidence:
lib/env-manager.ts:474-499— vulnerable restore path construction and copy.bin/cli.ts:441-458— default CLI exposes restore with caller-controlled--backup.
PoC
This PoC uses only temporary directories and restores trust_levels.json from an external directory into data/dev:
TMP=$(mktemp -d)
TMPBASE="$TMP" node -r ts-node/register/transpile-only - <<'TS'
const { EnvironmentManager } = require('./lib/env-manager');
const fs = require('fs');
const path = require('path');
const base = process.env.TMPBASE;
const data = path.join(base, 'data');
const source = path.join(base, 'outside', 'secret-src');
fs.mkdirSync(source, { recursive: true });
fs.writeFileSync(path.join(source, 'trust_levels.json'), '{"leaked":true}');
const mgr = new EnvironmentManager(data, {
chain: ['dev', 'st'],
gates: { dev: 'auto', st: 'auto' },
});
mgr.init('dev');
const backupId = path.relative(path.join(data, 'dev', '.backups'), source);
const result = mgr.restore('dev', backupId);
const restored = fs.readFileSync(path.join(data, 'dev', 'trust_levels.json'), 'utf8');
console.log(JSON.stringify({ backupId, filesRestored: result.filesRestored, restored }, null, 2));
fs.rmSync(base, { recursive: true, force: true });
TS
Observed result includes backupId: "../../../outside/secret-src", filesRestored: 1, and restored content {"leaked":true}.
Impact
A caller that can invoke backup restore can copy arbitrary readable directories into data/<env>, subject to process filesystem permissions. This can stage sensitive files into environment data/backup locations, overwrite environment configuration files if matching filenames exist, and break environment isolation. No RCE chain was confirmed.
Resolution (maintainer)
Fixed in v5.12.2 (commit a59c13a). Install: npm install network-ai@5.12.2 — published to npm with provenance.
restore() now validates backupId against /^[\w\-]+$/ and asserts dirname(resolve(join(backupsDir, backupId))) === resolve(backupsDir) before touching the filesystem. Backup IDs containing path separators or .. are rejected, so a crafted ID can no longer copy directories from outside .backups/ into the environment.
All 3,269 tests pass against the patched build. Thanks to @sondt99 for the responsible disclosure.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 5.12.1"
},
"package": {
"ecosystem": "npm",
"name": "network-ai"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.12.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-22",
"CWE-23"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-19T21:42:38Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Summary\n`EnvironmentManager.restore(env, backupId)` computes the backup path with `join(envDir, \u0027.backups\u0027, backupId)` and only checks that this path exists. It does not resolve the result or verify that it remains under `data/\u003cenv\u003e/.backups`.\n\nA caller can pass a traversal backup ID such as `../../../outside/source-dir` to restore files from an arbitrary directory into the target environment data directory. Confirmed in Network-AI 5.12.1.\n\n### Details\n`restore()` builds `backupPath` directly from caller-controlled `backupId`:\n\n```ts\nrestore(env: EnvName, backupId: string): RestoreResult {\n const envDir = this.getDataDir(env);\n const backupsDir = join(envDir, \u0027.backups\u0027);\n const backupPath = join(backupsDir, backupId);\n\n if (!existsSync(backupPath)) {\n throw new Error(`Backup \u0027${backupId}\u0027 not found for environment \u0027${env}\u0027`);\n }\n\n this.backup(env);\n\n const files = this._collectBackupFiles(backupPath);\n let restored = 0;\n for (const rel of files) {\n if (rel === \u0027_manifest.json\u0027) continue;\n const src = join(backupPath, rel);\n const dst = join(envDir, rel);\n try {\n mkdirSync(join(envDir, rel.includes(\u0027/\u0027) ? rel.substring(0, rel.lastIndexOf(\u0027/\u0027)) : \u0027.\u0027), { recursive: true });\n copyFileSync(src, dst);\n restored++;\n } catch { /* skip */ }\n }\n\n return { backupId, env, filesRestored: restored };\n}\n```\n\nThere is no resolved containment check that ensures `backupPath` remains under `backupsDir`.\n\nDefault CLI reachability exists through `network-ai env backup restore --env \u003cenv\u003e --backup \u003cid\u003e`.\n\nAffected source evidence:\n\n- `lib/env-manager.ts:474-499` \u2014 vulnerable restore path construction and copy.\n- `bin/cli.ts:441-458` \u2014 default CLI exposes restore with caller-controlled `--backup`.\n\n### PoC\nThis PoC uses only temporary directories and restores `trust_levels.json` from an external directory into `data/dev`:\n\n```bash\nTMP=$(mktemp -d)\nTMPBASE=\"$TMP\" node -r ts-node/register/transpile-only - \u003c\u003c\u0027TS\u0027\nconst { EnvironmentManager } = require(\u0027./lib/env-manager\u0027);\nconst fs = require(\u0027fs\u0027);\nconst path = require(\u0027path\u0027);\nconst base = process.env.TMPBASE;\nconst data = path.join(base, \u0027data\u0027);\nconst source = path.join(base, \u0027outside\u0027, \u0027secret-src\u0027);\n\nfs.mkdirSync(source, { recursive: true });\nfs.writeFileSync(path.join(source, \u0027trust_levels.json\u0027), \u0027{\"leaked\":true}\u0027);\n\nconst mgr = new EnvironmentManager(data, {\n chain: [\u0027dev\u0027, \u0027st\u0027],\n gates: { dev: \u0027auto\u0027, st: \u0027auto\u0027 },\n});\n\nmgr.init(\u0027dev\u0027);\nconst backupId = path.relative(path.join(data, \u0027dev\u0027, \u0027.backups\u0027), source);\nconst result = mgr.restore(\u0027dev\u0027, backupId);\nconst restored = fs.readFileSync(path.join(data, \u0027dev\u0027, \u0027trust_levels.json\u0027), \u0027utf8\u0027);\n\nconsole.log(JSON.stringify({ backupId, filesRestored: result.filesRestored, restored }, null, 2));\nfs.rmSync(base, { recursive: true, force: true });\nTS\n```\n\nObserved result includes `backupId: \"../../../outside/secret-src\"`, `filesRestored: 1`, and restored content `{\"leaked\":true}`.\n\n### Impact\nA caller that can invoke backup restore can copy arbitrary readable directories into `data/\u003cenv\u003e`, subject to process filesystem permissions. This can stage sensitive files into environment data/backup locations, overwrite environment configuration files if matching filenames exist, and break environment isolation. No RCE chain was confirmed.\n\n\n---\n\n### Resolution (maintainer)\n\n**Fixed in [v5.12.2](https://github.com/Jovancoding/Network-AI/releases/tag/v5.12.2) (commit `a59c13a`).** Install: `npm install network-ai@5.12.2` \u2014 published to npm with provenance.\n\n`restore()` now validates `backupId` against `/^[\\w\\-]+$/` and asserts `dirname(resolve(join(backupsDir, backupId))) === resolve(backupsDir)` before touching the filesystem. Backup IDs containing path separators or `..` are rejected, so a crafted ID can no longer copy directories from outside `.backups/` into the environment.\n\nAll 3,269 tests pass against the patched build. Thanks to @sondt99 for the responsible disclosure.",
"id": "GHSA-48x2-6pr9-2jjf",
"modified": "2026-06-19T21:42:38Z",
"published": "2026-06-19T21:42:38Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/Jovancoding/Network-AI/security/advisories/GHSA-48x2-6pr9-2jjf"
},
{
"type": "WEB",
"url": "https://github.com/Jovancoding/Network-AI/commit/a59c13a1f0ce0e8a0779a90343eef92fac5ab4c3"
},
{
"type": "PACKAGE",
"url": "https://github.com/Jovancoding/Network-AI"
},
{
"type": "WEB",
"url": "https://github.com/Jovancoding/Network-AI/releases/tag/v5.12.2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Network-AI: EnvironmentManager.restore() backup ID path traversal copies arbitrary directories into environment data"
}
GHSA-48X7-56R4-GHVR
Vulnerability from github – Published: 2023-02-09 18:30 – Updated: 2023-02-16 21:30Relative Path Traversal vulnerability in YugaByte, Inc. Yugabyte Managed (PlatformReplicationManager.Java modules) allows Path Traversal. This vulnerability is associated with program files PlatformReplicationManager.Java. This issue affects Yugabyte Managed: from 2.0 through 2.13.
{
"affected": [],
"aliases": [
"CVE-2023-0745"
],
"database_specific": {
"cwe_ids": [
"CWE-22",
"CWE-23"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-02-09T17:15:00Z",
"severity": "CRITICAL"
},
"details": "Relative Path Traversal vulnerability in YugaByte, Inc. Yugabyte Managed (PlatformReplicationManager.Java modules) allows Path Traversal. This vulnerability is associated with program files PlatformReplicationManager.Java. This issue affects Yugabyte Managed: from 2.0 through 2.13.",
"id": "GHSA-48x7-56r4-ghvr",
"modified": "2023-02-16T21:30:26Z",
"published": "2023-02-09T18:30:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-0745"
},
{
"type": "WEB",
"url": "https://www.yugabyte.com"
}
],
"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"
}
]
}
GHSA-49PV-GWXP-532R
Vulnerability from github – Published: 2025-09-17 18:39 – Updated: 2025-09-26 16:14Summary
A Local File Inclusion (LFI) issue was identified in the esm.sh service URL handling. An attacker could craft a request that causes the server to read and return files from the host filesystem (or other unintended file sources).
Severity: High — LFI can expose secrets, configuration files, credentials, or enable further compromise. Impact: reading configuration files, private keys, environment files, or other sensitive files; disclosure of secrets or credentials; information leakage that could enable further attacks.
Vulnerable code snippet is in this file: https://github.com/esm-dev/esm.sh/blob/c62f191d32639314ff0525d1c3c0e19ea2b16143/server/router.go#L1168
Proof of Concept
- Using this default config file that I copy from the repo, the server is running at
http://localhost:9999with this commandgo run server/esmd/main.go --config=config.json
{
"port": 9999,
"npmRegistry": "https://registry.npmjs.org/",
"npmToken": "******"
}
- Trigger the LFI vulnerability by sending this command below to read a local file
# read /etc/passwd
curl --path-as-is 'http://localhost:9999/pr/x/y@99/../../../../../../../../../../etc/passwd?raw=1&module=1'
# or read the database esm.db file
curl --path-as-is 'http://localhost:9999/pr/x/y@99/../../../../../../../esm.db?raw=1&module=1'
Remediation
Simply remove any .. in the URL path before actually process the file. See more details in this guide
Credits
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/esm-dev/esm.sh"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "136"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-59341"
],
"database_specific": {
"cwe_ids": [
"CWE-23"
],
"github_reviewed": true,
"github_reviewed_at": "2025-09-17T18:39:20Z",
"nvd_published_at": "2025-09-17T18:15:53Z",
"severity": "HIGH"
},
"details": "## Summary\n\nA Local File Inclusion (LFI) issue was identified in the esm.sh service URL handling. An attacker could craft a request that causes the server to read and return files from the host filesystem (or other unintended file sources).\n\n**Severity:** High \u2014 LFI can expose secrets, configuration files, credentials, or enable further compromise.\n**Impact:** reading configuration files, private keys, environment files, or other sensitive files; disclosure of secrets or credentials; information leakage that could enable further attacks.\n\nVulnerable code snippet is in this file: https://github.com/esm-dev/esm.sh/blob/c62f191d32639314ff0525d1c3c0e19ea2b16143/server/router.go#L1168\n\n---\n\n## Proof of Concept\n\n1. Using this default config file that I copy from the repo, the server is running at `http://localhost:9999` with this command `go run server/esmd/main.go --config=config.json`\n\n\n```json\n{\n \"port\": 9999,\n \"npmRegistry\": \"https://registry.npmjs.org/\",\n \"npmToken\": \"******\"\n}\n\n```\n\n2. Trigger the LFI vulnerability by sending this command below to read a local file\n\n```bash\n# read /etc/passwd\ncurl --path-as-is \u0027http://localhost:9999/pr/x/y@99/../../../../../../../../../../etc/passwd?raw=1\u0026module=1\u0027\n\n# or read the database esm.db file\ncurl --path-as-is \u0027http://localhost:9999/pr/x/y@99/../../../../../../../esm.db?raw=1\u0026module=1\u0027\n```\n\n\u003cimg width=\"3338\" height=\"1906\" alt=\"poc-image\" src=\"https://github.com/user-attachments/assets/f3721e5d-a09c-4227-960a-35279ff52811\" /\u003e\n\n\n---\n\n## Remediation\n\nSimply remove any `..` in the URL path before actually process the file. See more details in [this guide](https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html)\n\n## Credits\n\n- [Ai Ho (Jessie)](https://github.com/j3ssie)\n- [CL Yang](https://github.com/A11riseforme)",
"id": "GHSA-49pv-gwxp-532r",
"modified": "2025-09-26T16:14:27Z",
"published": "2025-09-17T18:39:20Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/esm-dev/esm.sh/security/advisories/GHSA-49pv-gwxp-532r"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-59341"
},
{
"type": "WEB",
"url": "https://github.com/esm-dev/esm.sh/commit/492de92850dd4d350c8b299af541f87541e58a45"
},
{
"type": "PACKAGE",
"url": "https://github.com/esm-dev/esm.sh"
},
{
"type": "WEB",
"url": "https://github.com/esm-dev/esm.sh/blob/c62f191d32639314ff0525d1c3c0e19ea2b16143/server/router.go#L1168"
},
{
"type": "WEB",
"url": "https://pkg.go.dev/vuln/GO-2025-3962"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:P",
"type": "CVSS_V4"
}
],
"summary": "esm.sh has File Inclusion issue"
}
GHSA-4CCP-CQRH-3W9V
Vulnerability from github – Published: 2026-05-21 15:34 – Updated: 2026-05-21 21:30A directory traversal vulnerability in the Apex One (on-premise) server could allow a pre-authenticated local attacker to modify a key table on the server to inject malicious code to deploy to agents on affected installations.
This vulnerability is only exploitable on the on-premise version of Apex One and a potential attacker must have access to the Apex One Server and already obtained administrative credentials to the server via some other method to exploit this vulnerability.
{
"affected": [],
"aliases": [
"CVE-2026-34926"
],
"database_specific": {
"cwe_ids": [
"CWE-23"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-21T14:16:45Z",
"severity": "MODERATE"
},
"details": "A directory traversal vulnerability in the Apex One (on-premise) server could allow a pre-authenticated local attacker to modify a key table on the server to inject malicious code to deploy to agents on affected installations.\n\n\nThis vulnerability is only exploitable on the on-premise version of Apex One and a potential attacker must have access to the Apex One Server and already obtained administrative credentials to the server via some other method to exploit this vulnerability.",
"id": "GHSA-4ccp-cqrh-3w9v",
"modified": "2026-05-21T21:30:33Z",
"published": "2026-05-21T15:34:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34926"
},
{
"type": "WEB",
"url": "https://jvn.jp/en/vu/JVNVU90583059"
},
{
"type": "WEB",
"url": "https://success.trendmicro.com/en-US/solution/KA-0023430"
},
{
"type": "WEB",
"url": "https://success.trendmicro.com/ja-JP/solution/KA-0022974"
},
{
"type": "WEB",
"url": "https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2026-34926"
},
{
"type": "WEB",
"url": "https://www.jpcert.or.jp/english/at/2026/at260014.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:C/C:H/I:L/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-4H5M-3W75-QCQ5
Vulnerability from github – Published: 2026-06-29 12:31 – Updated: 2026-06-29 12:31A relative path traversal bug problem when processing repository metadata in libzypp before 17.38.10 could be used by remote attackers supplying repositories to overwrite files on the system, leading to denial of service or privilege escalation.
{
"affected": [],
"aliases": [
"CVE-2026-25707"
],
"database_specific": {
"cwe_ids": [
"CWE-23"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-29T10:16:30Z",
"severity": "HIGH"
},
"details": "A relative path traversal bug problem when processing repository metadata in libzypp before 17.38.10 could be used by remote attackers supplying repositories to overwrite files on the system, leading to denial of service or privilege escalation.",
"id": "GHSA-4h5m-3w75-qcq5",
"modified": "2026-06-29T12:31:44Z",
"published": "2026-06-29T12:31:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-25707"
},
{
"type": "WEB",
"url": "https://github.com/openSUSE/libzypp/commit/f09feda7fca03c941218aab0bb161cc82b185b6b"
},
{
"type": "WEB",
"url": "https://bugzilla.suse.com/show_bug.cgi?id=1259802"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-4HH3-VJ32-GR6J
Vulnerability from github – Published: 2024-08-19 17:29 – Updated: 2024-08-19 17:29Summary
Upon reviewing the MobSF source code, I identified a flaw in the Static Libraries analysis section. Specifically, during the extraction of .a extension files, the measure intended to prevent Zip Slip attacks is improperly implemented.
Since the implemented measure can be bypassed, the vulnerability allows an attacker to extract files to any desired location within the server running MobSF.
Details
Upon examining lines 183-192 of the mobsf/StaticAnalyzer/views/common/shared_func.py file, it is observed that there is a mitigation against Zip Slip attacks implemented as a.decode('utf-8', 'ignore').replace('../', '').replace('..\\', ''). However, this measure can be bypassed using sequences like ....//....//....//. Since the replace operation is not recursive, this sequence is transformed into ../../../ after the replace operation, allowing files to be written to upper directories.
For the proof of concept, I created an .a archive file that renders MobSF unusable by writing an empty file with the same name over the database located at /home/mobsf/.MobSF/db.sqlite3.
I am including the binary used for the POC named poc.VULN. To test it, you need to rename this binary to poc.a.
Warning: As soon as you scan this file with MobSF, the database will be deleted, rendering MobSF unusable.
PoC Binary File (poc.VULN)
PoC
https://github.com/user-attachments/assets/3225ccb0-cb00-47a5-8305-37a40ca1ae7f
Impact
When a malicious .a file is scanned with MobSF, a critical vulnerability is present as it allows files to be extracted to any location on the server where MobSF is running. In this POC, I deleted the database, but it is also possible to achieve RCE by overwriting binaries of certain tools or by overwriting the /etc/passwd file.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.0.6"
},
"package": {
"ecosystem": "PyPI",
"name": "mobsf"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.0.7"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-43399"
],
"database_specific": {
"cwe_ids": [
"CWE-22",
"CWE-23"
],
"github_reviewed": true,
"github_reviewed_at": "2024-08-19T17:29:52Z",
"nvd_published_at": "2024-08-19T15:15:09Z",
"severity": "HIGH"
},
"details": "### Summary\nUpon reviewing the MobSF source code, I identified a flaw in the Static Libraries analysis section. Specifically, during the extraction of .a extension files, the measure intended to prevent Zip Slip attacks is improperly implemented.\n\nSince the implemented measure can be bypassed, the vulnerability allows an attacker to extract files to any desired location within the server running MobSF.\n\n### Details\n\nUpon examining lines 183-192 of the `mobsf/StaticAnalyzer/views/common/shared_func.py` file, it is observed that there is a mitigation against Zip Slip attacks implemented as `a.decode(\u0027utf-8\u0027, \u0027ignore\u0027).replace(\u0027../\u0027, \u0027\u0027).replace(\u0027..\\\\\u0027, \u0027\u0027)`. However, this measure can be bypassed using sequences like `....//....//....//`. Since the replace operation is not recursive, this sequence is transformed into `../../../` after the replace operation, allowing files to be written to upper directories.\n\n\u003cimg width=\"448\" alt=\"image\" src=\"https://github.com/user-attachments/assets/fadf4bcc-1a92-4655-b66a-5349278ad9c5\"\u003e\n\n\nFor the proof of concept, I created an .a archive file that renders MobSF unusable by writing an empty file with the same name over the database located at `/home/mobsf/.MobSF/db.sqlite3`.\n\n\u003cimg width=\"300\" alt=\"poc a_1\" src=\"https://github.com/user-attachments/assets/54acf101-3931-401f-9970-a0934265eecb\"\u003e\n\n\nI am including the binary used for the POC named `poc.VULN`. To test it, you need to rename this binary to `poc.a`.\n\n **Warning:** As soon as you scan this file with MobSF, the database will be deleted, rendering MobSF unusable.\n\nPoC Binary File ([poc.VULN](https://drive.google.com/file/d/1K2eHYIZ1hUbs-Vi5zhKAKecnd0nDB8lO/view?usp=share_link))\n\n### PoC\n\n\nhttps://github.com/user-attachments/assets/3225ccb0-cb00-47a5-8305-37a40ca1ae7f\n\n\n\n### Impact\n\nWhen a malicious .a file is scanned with MobSF, a critical vulnerability is present as it allows files to be extracted to any location on the server where MobSF is running. In this POC, I deleted the database, but it is also possible to achieve RCE by overwriting binaries of certain tools or by overwriting the /etc/passwd file.\n",
"id": "GHSA-4hh3-vj32-gr6j",
"modified": "2024-08-19T17:29:52Z",
"published": "2024-08-19T17:29:52Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/MobSF/Mobile-Security-Framework-MobSF/security/advisories/GHSA-4hh3-vj32-gr6j"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43399"
},
{
"type": "WEB",
"url": "https://github.com/MobSF/Mobile-Security-Framework-MobSF/commit/cc625fe8430f3437a473e82aa2966d100a4dc883"
},
{
"type": "PACKAGE",
"url": "https://github.com/MobSF/Mobile-Security-Framework-MobSF"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Mobile Security Framework (MobSF) has a Zip Slip Vulnerability in .a Static Library Files"
}
GHSA-4HQ6-9Q59-HG3W
Vulnerability from github – Published: 2024-10-21 06:32 – Updated: 2024-10-21 06:32Administrative Management System from Wellchoose has a Path Traversal vulnerability, allowing unauthenticated remote attackers to exploit this vulnerability to download arbitrary files on the server.
{
"affected": [],
"aliases": [
"CVE-2024-10200"
],
"database_specific": {
"cwe_ids": [
"CWE-22",
"CWE-23"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-10-21T04:15:02Z",
"severity": "HIGH"
},
"details": "Administrative Management System from Wellchoose has a Path Traversal vulnerability, allowing unauthenticated remote attackers to exploit this vulnerability to download arbitrary files on the server.",
"id": "GHSA-4hq6-9q59-hg3w",
"modified": "2024-10-21T06:32:33Z",
"published": "2024-10-21T06:32:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-10200"
},
{
"type": "WEB",
"url": "https://www.twcert.org.tw/en/cp-139-8158-dadbc-2.html"
},
{
"type": "WEB",
"url": "https://www.twcert.org.tw/tw/cp-132-8159-0f7a2-1.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-4JVX-93H3-F45H
Vulnerability from github – Published: 2026-04-22 22:22 – Updated: 2026-05-29 21:45Summary
OpenC3 COSMOS contains a design flaw in the save_tool_config() function that allows saving tool configuration files at arbitrary locations inside the shared /plugins directory tree by supplying crafted configuration filenames. Although the implementation sufficiently mitigates standard path traversal attacks, by canonicalizing filename to an absolute path, all plugins share this same root directory. That enables users to create arbitrary file structures and overwrite existing configuration files within the shared /plugins directory.
Details
In function save_tool_config() (local_mode.rb) responsible for saving user-supplied tool configuration, the desired saving directory is not sufficiently enforced, instead allowing writes inside entire OPENC3_LOCAL_MODE_PATH.
PoC
- Navigate to any tool that enables “Save Configuration” option in left-hand drop-down menu (here Limits Monitor as an example)
- Save a new config with path traversal name using “../” sequences to escape desired directory (up to 3 levels high)
- Observe new files created in /plugins directory by inspecting docker container directly (
openc3-COSMOS-cmd-tlm-api) or using Bucket Explorer (plugin_default)
Impact
Modifying the data of other plugins
{
"affected": [
{
"package": {
"ecosystem": "RubyGems",
"name": "openc3"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.10.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "RubyGems",
"name": "openc3"
},
"ranges": [
{
"events": [
{
"introduced": "7.0.0.pre.rc1"
},
{
"fixed": "7.0.0-rc3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-42085"
],
"database_specific": {
"cwe_ids": [
"CWE-23"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-22T22:22:02Z",
"nvd_published_at": "2026-05-04T18:16:30Z",
"severity": "MODERATE"
},
"details": "### Summary\nOpenC3 COSMOS contains a design flaw in the `save_tool_config()` function that allows saving tool configuration files at arbitrary locations inside the shared `/plugins` directory tree by supplying crafted configuration filenames. Although the implementation sufficiently mitigates standard path traversal attacks, by canonicalizing filename to an absolute path, all plugins share this same root directory. That enables users to create arbitrary file structures and overwrite existing configuration files within the shared `/plugins` directory.\n\n### Details\nIn function `save_tool_config()` ([local_mode.rb](https://github.com/OpenC3/cosmos/blob/397abec0d57972881a2e8dc10902d0dce9c27f42/openc3/lib/openc3/utilities/local_mode.rb#L452)) responsible for saving user-supplied tool configuration, the desired saving directory is not sufficiently enforced, instead allowing writes inside entire `OPENC3_LOCAL_MODE_PATH`.\n\n### PoC\n1.\tNavigate to any tool that enables \u201cSave Configuration\u201d option in left-hand drop-down menu (here Limits Monitor as an example)\n2.\tSave a new config with path traversal name using \u201c../\u201d sequences to escape desired directory (up to 3 levels high)\n3.\tObserve new files created in /plugins directory by inspecting docker container directly (`openc3-COSMOS-cmd-tlm-api`) or using Bucket Explorer (`plugin_default`)\n\n\u003cimg width=\"811\" height=\"584\" alt=\"image\" src=\"https://github.com/user-attachments/assets/015a59b4-8b18-4801-aef0-df4831d5c1c3\" /\u003e\n\u003cimg width=\"720\" height=\"664\" alt=\"image\" src=\"https://github.com/user-attachments/assets/8ca4a5b7-ee45-4c3b-99f6-f41f974a74a7\" /\u003e\n\n### Impact\nModifying the data of other plugins",
"id": "GHSA-4jvx-93h3-f45h",
"modified": "2026-05-29T21:45:12Z",
"published": "2026-04-22T22:22:02Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/OpenC3/cosmos/security/advisories/GHSA-4jvx-93h3-f45h"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42085"
},
{
"type": "WEB",
"url": "https://github.com/OpenC3/cosmos/commit/9957a9fa460c0c0cf5cdbf6a5931bbdd025246a5"
},
{
"type": "WEB",
"url": "https://github.com/OpenC3/cosmos/commit/e6efccbd148ba0e3361c5891027f2373aa140d42"
},
{
"type": "PACKAGE",
"url": "https://github.com/OpenC3/cosmos"
},
{
"type": "WEB",
"url": "https://github.com/OpenC3/cosmos/releases/tag/v6.10.5"
},
{
"type": "WEB",
"url": "https://github.com/OpenC3/cosmos/releases/tag/v7.0.0-rc3"
},
{
"type": "WEB",
"url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/openc3/CVE-2026-42085.yml"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "OpenC3 COSMOS allows arbitrary writes to plugins directory via path-traversed config filenames"
}
GHSA-4P5M-GVPF-F3X5
Vulnerability from github – Published: 2025-01-27 09:30 – Updated: 2025-01-27 17:22Relative Path Traversal vulnerability in Apache Solr.
Solr instances running on Windows are vulnerable to arbitrary filepath write-access, due to a lack of input-sanitation in the "configset upload" API. Commonly known as a "zipslip", maliciously constructed ZIP files can use relative filepaths to write data to unanticipated parts of the filesystem. This issue affects Apache Solr: from 6.6 through 9.7.0.
Users are recommended to upgrade to version 9.8.0, which fixes the issue. Users unable to upgrade may also safely prevent the issue by using Solr's "Rule-Based Authentication Plugin" to restrict access to the configset upload API, so that it can only be accessed by a trusted set of administrators/users.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.solr:solr-core"
},
"ranges": [
{
"events": [
{
"introduced": "6.6"
},
{
"fixed": "9.8.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-52012"
],
"database_specific": {
"cwe_ids": [
"CWE-23"
],
"github_reviewed": true,
"github_reviewed_at": "2025-01-27T17:22:43Z",
"nvd_published_at": "2025-01-27T09:15:14Z",
"severity": "MODERATE"
},
"details": "Relative Path Traversal vulnerability in Apache Solr.\n\nSolr instances running on Windows are vulnerable to arbitrary filepath write-access, due to a lack of input-sanitation in the \"configset upload\" API.\u00a0 Commonly known as a \"zipslip\", maliciously constructed ZIP files can use relative filepaths to write data to unanticipated parts of the filesystem.\u00a0\u00a0\nThis issue affects Apache Solr: from 6.6 through 9.7.0.\n\nUsers are recommended to upgrade to version 9.8.0, which fixes the issue.\u00a0 Users unable to upgrade may also safely prevent the issue by using Solr\u0027s \"Rule-Based Authentication Plugin\" to restrict access to the configset upload API, so that it can only be accessed by a trusted set of administrators/users.",
"id": "GHSA-4p5m-gvpf-f3x5",
"modified": "2025-01-27T17:22:43Z",
"published": "2025-01-27T09:30:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-52012"
},
{
"type": "WEB",
"url": "https://github.com/apache/solr/commit/5795edd143b8fcb2ffaf7f278a099b8678adf396"
},
{
"type": "PACKAGE",
"url": "https://github.com/apache/solr"
},
{
"type": "WEB",
"url": "https://issues.apache.org/jira/browse/SOLR-17543"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread/yp39pgbv4vf1746pf5yblz84lv30vfxd"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2025/01/26/2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:U",
"type": "CVSS_V4"
}
],
"summary": "Apache Solr Relative Path Traversal vulnerability"
}
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-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-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-139: Relative Path Traversal
An attacker exploits a weakness in input validation on the target by supplying a specially constructed path utilizing dot and slash characters for the purpose of obtaining access to arbitrary files or resources. An attacker modifies a known path on the target in order to reach material that is not available through intended channels. These attacks normally involve adding additional path separators (/ or \) and/or dots (.), or encodings thereof, in various combinations in order to reach parent directories or entirely separate trees of the target's directory structure.
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.