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.
840 vulnerabilities reference this CWE, most recent first.
GHSA-CVRH-QGGV-7GF8
Vulnerability from github – Published: 2025-10-07 21:31 – Updated: 2025-10-07 21:31In Ankitects Anki before 25.02.6, crafted sound file references could cause files to be written to arbitrary locations on Windows and Linux (media file pathnames are not necessarily relative to the media folder).
{
"affected": [],
"aliases": [
"CVE-2025-62187"
],
"database_specific": {
"cwe_ids": [
"CWE-23"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-07T21:15:39Z",
"severity": "LOW"
},
"details": "In Ankitects Anki before 25.02.6, crafted sound file references could cause files to be written to arbitrary locations on Windows and Linux (media file pathnames are not necessarily relative to the media folder).",
"id": "GHSA-cvrh-qggv-7gf8",
"modified": "2025-10-07T21:31:08Z",
"published": "2025-10-07T21:31:08Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-62187"
},
{
"type": "WEB",
"url": "https://github.com/ankitects/anki/pull/4041"
},
{
"type": "WEB",
"url": "https://github.com/ankitects/anki/pull/4041/commits/51476e05b281737a0c2924342bccdb6e5be52ea9"
},
{
"type": "WEB",
"url": "https://github.com/ankitects/anki/releases/tag/25.02.6"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-CW93-P7FX-XGQX
Vulnerability from github – Published: 2026-06-09 18:30 – Updated: 2026-06-09 18:30Relative path traversal in Visual Studio Code allows an unauthorized attacker to perform tampering over a network.
{
"affected": [],
"aliases": [
"CVE-2026-47287"
],
"database_specific": {
"cwe_ids": [
"CWE-23"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-09T17:17:34Z",
"severity": "MODERATE"
},
"details": "Relative path traversal in Visual Studio Code allows an unauthorized attacker to perform tampering over a network.",
"id": "GHSA-cw93-p7fx-xgqx",
"modified": "2026-06-09T18:30:54Z",
"published": "2026-06-09T18:30:54Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-47287"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-47287"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-F3QC-F3RX-3HRM
Vulnerability from github – Published: 2024-11-11 09:30 – Updated: 2024-11-24 15:31The D-Link DSL6740C modem has a Path Traversal Vulnerability, allowing unauthenticated remote attackers to exploit this vulnerability to read arbitrary system files. Additionally, since the device's default password is a combination of the MAC address, attackers can obtain the MAC address through this vulnerability and attempt to log in to the device using the default password.
{
"affected": [],
"aliases": [
"CVE-2024-11067"
],
"database_specific": {
"cwe_ids": [
"CWE-23"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-11-11T08:15:08Z",
"severity": "HIGH"
},
"details": "The D-Link DSL6740C modem has a Path Traversal Vulnerability, allowing unauthenticated remote attackers to exploit this vulnerability to read arbitrary system files. Additionally, since the device\u0027s default password is a combination of the MAC address, attackers can obtain the MAC address through this vulnerability and attempt to log in to the device using the default password.",
"id": "GHSA-f3qc-f3rx-3hrm",
"modified": "2024-11-24T15:31:38Z",
"published": "2024-11-11T09:30:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-11067"
},
{
"type": "WEB",
"url": "https://www.bleepingcomputer.com/news/security/d-link-wont-fix-critical-bug-in-60-000-exposed-eol-modems"
},
{
"type": "WEB",
"url": "https://www.twcert.org.tw/en/cp-139-8233-903d9-2.html"
},
{
"type": "WEB",
"url": "https://www.twcert.org.tw/tw/cp-132-8226-0b07b-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-F463-V52Q-MJH6
Vulnerability from github – Published: 2025-07-29 06:30 – Updated: 2025-07-29 06:30An 'Arbitrary File Deletion' in Samsung DMS(Data Management Server) allows attackers to delete arbitrary files from unintended locations on the filesystem. Exploitation is restricted to specific, authorized private IP addresses.
{
"affected": [],
"aliases": [
"CVE-2025-53082"
],
"database_specific": {
"cwe_ids": [
"CWE-23"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-07-29T06:15:23Z",
"severity": "MODERATE"
},
"details": "An \u0027Arbitrary File Deletion\u0027 in Samsung DMS(Data Management Server) allows attackers to delete arbitrary files from unintended locations on the filesystem. Exploitation is restricted to specific, authorized private IP addresses.",
"id": "GHSA-f463-v52q-mjh6",
"modified": "2025-07-29T06:30:22Z",
"published": "2025-07-29T06:30:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-53082"
},
{
"type": "WEB",
"url": "https://security.samsungda.com/securityUpdates.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-F78G-9385-QXQJ
Vulnerability from github – Published: 2026-08-24 18:31 – Updated: 2026-08-28 21:55Relative path traversal vulnerability in Apache Camel Google Storage component.
This issue affects Apache Camel: from 4.0.0 before 4.14.9, from 4.15.0 before 4.18.4, from 4.19.0 before 4.22.0.
The camel-google-storage consumer downloads Google Cloud Storage objects to the local filesystem when the downloadFileName option is set. That option is documented as a folder or a filename, and when its value contains no expression token the consumer builds the local destination by appending the object name to it: evaluateFileExpression sets the Exchange file-name header to the remote object name and evaluates downloadFileName + "/${file:name}". The ${file:name} token returns the file-name header verbatim, unlike ${file:onlyname}, which applies FileUtil.stripPath to it. The resulting string was passed directly to new File(result) and blob.downloadTo(file.toPath()) with no lexical normalization and no check that the destination stayed inside the configured directory. The object name is not route-controlled data: the consumer lists the bucket, iterates every returned blob and creates one exchange per object from blob.getBlobId().getName() verbatim, and the filter option that could restrict those names is not applied at all unless it has been explicitly set. Google Cloud Storage object names are opaque UTF-8 keys that the service stores and lists exactly as written, with no server-side canonicalization, and a forward slash is only a display convention for pseudo-directories, so a key containing parent-directory segments survives round-tripping intact. An object name containing such segments therefore resolved to a location outside the configured downloadFileName directory, letting anyone able to influence the names present in the consumed bucket cause Camel to create or overwrite a file at a location of their choosing, with the privileges of the Camel process. Depending on what the process can write to, overwriting a file outside the download directory can escalate beyond the loss of integrity of that file. The downloadFileName option is an ordinary consumer parameter and carries no security marker, so nothing signalled to users that its value was not being enforced as a containment boundary. The defect is consumer-only; the producer has no download-to-file sink. Camel's other file-download consumers - camel-file, camel-ftp, camel-smb, camel-mina-sftp, camel-azure-files and the Azure Storage download paths - already constrained their local downloads to the configured directory using a path-segment boundary check; camel-google-storage was the remaining object-store download sink not covered by that work.
Users are recommended to upgrade to version 4.22.0, which fixes the issue. If users are on the 4.14.x LTS releases stream, then they are suggested to upgrade to 4.14.9. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.4. For deployments that cannot upgrade immediately, set the filter option to a regular expression that accepts only simple single-segment object names, so that any name carrying a path separator or a parent-directory segment is excluded before an exchange is created; note that no filtering whatsoever is applied when the option is left unset, and that the expression is matched against the whole object name. Alternatively, give downloadFileName an explicit expression that does not carry the remote path through, for example one built on ${file:onlyname} rather than the implicit ${file:name}, keeping in mind that a downloadFileName containing an expression is treated as route-author-controlled and is not covered by the containment check added in the fix. As defence in depth, treat the object names in any externally writable bucket as untrusted input and do not derive local filesystem paths from them.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.camel:camel-google-storage"
},
"ranges": [
{
"events": [
{
"introduced": "4.0.0"
},
{
"fixed": "4.14.9"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.camel:camel-google-storage"
},
"ranges": [
{
"events": [
{
"introduced": "4.15.0"
},
{
"fixed": "4.18.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.camel:camel-google-storage"
},
"ranges": [
{
"events": [
{
"introduced": "4.19.0"
},
{
"fixed": "4.22.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-66907"
],
"database_specific": {
"cwe_ids": [
"CWE-23"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-28T21:55:10Z",
"nvd_published_at": "2026-08-24T17:18:06Z",
"severity": "HIGH"
},
"details": "Relative path traversal vulnerability in Apache Camel Google Storage component.\n\nThis issue affects Apache Camel: from 4.0.0 before 4.14.9, from 4.15.0 before 4.18.4, from 4.19.0 before 4.22.0.\n\nThe camel-google-storage consumer downloads Google Cloud Storage objects to the local filesystem when the downloadFileName option is set. That option is documented as a folder or a filename, and when its value contains no expression token the consumer builds the local destination by appending the object name to it: evaluateFileExpression sets the Exchange file-name header to the remote object name and evaluates downloadFileName + \"/${file:name}\". The ${file:name} token returns the file-name header verbatim, unlike ${file:onlyname}, which applies FileUtil.stripPath to it. The resulting string was passed directly to new File(result) and blob.downloadTo(file.toPath()) with no lexical normalization and no check that the destination stayed inside the configured directory. The object name is not route-controlled data: the consumer lists the bucket, iterates every returned blob and creates one exchange per object from blob.getBlobId().getName() verbatim, and the filter option that could restrict those names is not applied at all unless it has been explicitly set. Google Cloud Storage object names are opaque UTF-8 keys that the service stores and lists exactly as written, with no server-side canonicalization, and a forward slash is only a display convention for pseudo-directories, so a key containing parent-directory segments survives round-tripping intact. An object name containing such segments therefore resolved to a location outside the configured downloadFileName directory, letting anyone able to influence the names present in the consumed bucket cause Camel to create or overwrite a file at a location of their choosing, with the privileges of the Camel process. Depending on what the process can write to, overwriting a file outside the download directory can escalate beyond the loss of integrity of that file. The downloadFileName option is an ordinary consumer parameter and carries no security marker, so nothing signalled to users that its value was not being enforced as a containment boundary. The defect is consumer-only; the producer has no download-to-file sink. Camel\u0027s other file-download consumers - camel-file, camel-ftp, camel-smb, camel-mina-sftp, camel-azure-files and the Azure Storage download paths - already constrained their local downloads to the configured directory using a path-segment boundary check; camel-google-storage was the remaining object-store download sink not covered by that work.\n\nUsers are recommended to upgrade to version 4.22.0, which fixes the issue. If users are on the 4.14.x LTS releases stream, then they are suggested to upgrade to 4.14.9. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.4. For deployments that cannot upgrade immediately, set the filter option to a regular expression that accepts only simple single-segment object names, so that any name carrying a path separator or a parent-directory segment is excluded before an exchange is created; note that no filtering whatsoever is applied when the option is left unset, and that the expression is matched against the whole object name. Alternatively, give downloadFileName an explicit expression that does not carry the remote path through, for example one built on ${file:onlyname} rather than the implicit ${file:name}, keeping in mind that a downloadFileName containing an expression is treated as route-author-controlled and is not covered by the containment check added in the fix. As defence in depth, treat the object names in any externally writable bucket as untrusted input and do not derive local filesystem paths from them.",
"id": "GHSA-f78g-9385-qxqj",
"modified": "2026-08-28T21:55:10Z",
"published": "2026-08-24T18:31:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-66907"
},
{
"type": "WEB",
"url": "https://github.com/apache/camel/pull/25179"
},
{
"type": "WEB",
"url": "https://github.com/apache/camel/pull/25180"
},
{
"type": "WEB",
"url": "https://github.com/apache/camel/pull/25181"
},
{
"type": "WEB",
"url": "https://github.com/apache/camel/pull/25182"
},
{
"type": "WEB",
"url": "https://github.com/apache/camel/commit/277ab7b7af9bd3beb789d458d54b00b704647191"
},
{
"type": "WEB",
"url": "https://github.com/apache/camel/commit/4b9b4ade15148e1512b39f302075b36c7a092e86"
},
{
"type": "WEB",
"url": "https://github.com/apache/camel/commit/a6f73c6d2828fe2b76bf423bad92f98d80af7437"
},
{
"type": "WEB",
"url": "https://camel.apache.org/security/CVE-2026-66907.html"
},
{
"type": "PACKAGE",
"url": "https://github.com/apache/camel"
},
{
"type": "WEB",
"url": "https://github.com/apache/camel/releases/tag/camel-4.14.9"
},
{
"type": "WEB",
"url": "https://github.com/apache/camel/releases/tag/camel-4.18.4"
},
{
"type": "WEB",
"url": "https://github.com/apache/camel/releases/tag/camel-4.22.0"
},
{
"type": "WEB",
"url": "https://issues.apache.org/jira/browse/CAMEL-24279"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2026/08/24/11"
}
],
"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"
}
],
"summary": "Apache Camel-Google-Storage: the consumer appended the remote object name to the configured downloadFileName directory without constraining the result"
}
GHSA-F8QC-G9FF-P4M7
Vulnerability from github – Published: 2026-05-09 06:31 – Updated: 2026-05-09 06:31Gibbon versions before v30.0.01 are affected by a path traversal vulnerability resulting in DOS by attempting extraction of web application PHP files, failed .zip extraction results in deletion of the file and a DOS condition. Successful exploitation requires Teacher or higher privileges. Exploitation could result in loss of availability of the web application.
{
"affected": [],
"aliases": [
"CVE-2026-8209"
],
"database_specific": {
"cwe_ids": [
"CWE-23"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-09T04:16:28Z",
"severity": "MODERATE"
},
"details": "Gibbon versions before v30.0.01 are affected by a path traversal vulnerability resulting in DOS by attempting extraction of web application PHP files, failed .zip extraction results in deletion of the file and a DOS condition. Successful exploitation requires Teacher or higher privileges. Exploitation could result in loss of availability of the web application.",
"id": "GHSA-f8qc-g9ff-p4m7",
"modified": "2026-05-09T06:31:36Z",
"published": "2026-05-09T06:31:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-8209"
},
{
"type": "WEB",
"url": "https://github.com/GibbonEdu/core/releases/tag/v30.0.01"
},
{
"type": "WEB",
"url": "https://projectblack.io/blog/gibbon-v30-authenticated-sql-injection-and-rce/#denial-of-service-via-path-traversal"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:H/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:H/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-F982-VXQP-WP2R
Vulnerability from github – Published: 2024-04-03 21:31 – Updated: 2024-04-03 21:31ABB has internally identified a vulnerability in the ABB VPNI feature of the S+ Control API component which may be used by several Symphony Plus products (e.g., S+ Operations, S+ Engineering and S+ Analyst)
This issue affects Symphony Plus S+ Operations: from 3..0;0 through 3.3 SP1 RU4, from 2.1;0 through 2.1 SP2 RU3, from 2.0;0 through 2.0 SP6 TC6; Symphony Plus S+ Engineering: from 2.1 through 2.3 RU3; Symphony Plus S+ Analyst: from 7.0.0.0 through 7.2.0.2.
{
"affected": [],
"aliases": [
"CVE-2024-0335"
],
"database_specific": {
"cwe_ids": [
"CWE-20",
"CWE-23"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-04-03T19:15:43Z",
"severity": "HIGH"
},
"details": "\nABB has internally identified a vulnerability in the ABB VPNI feature of the S+ Control API component which may \nbe used by several Symphony Plus products (e.g., S+ Operations, S+ Engineering and S+ Analyst)\n\nThis issue affects Symphony Plus S+ Operations: from 3..0;0 through 3.3 SP1 RU4, from 2.1;0 through 2.1 SP2 RU3, from 2.0;0 through 2.0 SP6 TC6; Symphony Plus S+ Engineering: from 2.1 through 2.3 RU3; Symphony Plus S+ Analyst: from 7.0.0.0 through 7.2.0.2.\n\n",
"id": "GHSA-f982-vxqp-wp2r",
"modified": "2024-04-03T21:31:41Z",
"published": "2024-04-03T21:31:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-0335"
},
{
"type": "WEB",
"url": "https://search.abb.com/library/Download.aspx?DocumentID=7PAA002536\u0026LanguageCode=en\u0026DocumentPartId=\u0026Action=Launch"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-F9V2-3453-RJ68
Vulnerability from github – Published: 2023-02-28 18:30 – Updated: 2023-03-09 21:30Relative Path Traversal vulnerability in ForgeRock Access Management Web Policy Agent allows Authentication Bypass.This issue affects Access Management Web Policy Agent: through 5.10.1.
{
"affected": [],
"aliases": [
"CVE-2023-0339"
],
"database_specific": {
"cwe_ids": [
"CWE-22",
"CWE-23"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-02-28T17:15:00Z",
"severity": "CRITICAL"
},
"details": "Relative Path Traversal vulnerability in ForgeRock Access Management Web Policy Agent allows Authentication Bypass.This issue affects Access Management Web Policy Agent: through 5.10.1.",
"id": "GHSA-f9v2-3453-rj68",
"modified": "2023-03-09T21:30:19Z",
"published": "2023-02-28T18:30:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-0339"
},
{
"type": "WEB",
"url": "https://backstage.forgerock.com/downloads/browse/am/featured/web-agents"
},
{
"type": "WEB",
"url": "https://backstage.forgerock.com/knowledge/kb/article/a21576868"
}
],
"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-FG23-3346-88F5
Vulnerability from github – Published: 2026-07-02 17:38 – Updated: 2026-07-02 17:38Summary
Langroid's ReadFileTool and WriteFileTool appear to treat curr_dir as the intended working-directory boundary for file operations. However, the tools only change the process working directory to curr_dir and then operate on the user-supplied file_path without resolving and enforcing that the final path remains inside curr_dir.
As a result, a tool caller can supply path traversal sequences such as ../secret.txt to read files outside the configured current directory, or ../written_by_tool.txt to write files outside that directory.
This can impact applications that expose Langroid file tools to an LLM agent, user-controlled tool call, or delegated coding/documentation agent while relying on curr_dir to restrict file access to a project/workspace directory.
Details
Affected components:
langroid/agent/tools/file_tools.pylangroid/utils/system.py
Relevant behavior observed:
ReadFileTool contains a comment indicating the intended assumption:
```text
ASSUME: file_path should be relative to the curr_dir
The tool then changes into the configured current directory and calls read_file(self.file_path).
WriteFileTool similarly resolves curr_dir, changes into that directory, and calls create_file(self.file_path, self.content).
The issue is that changing the process working directory does not prevent traversal. A path such as ../secret.txt is still valid and resolves outside the configured curr_dir.
In local testing, ReadFileTool successfully read a file outside the configured sandbox directory, and WriteFileTool successfully wrote a file outside the configured sandbox directory.
PoC
Tested locally against the current Langroid repository checkout.
Environment:
Python 3.12 Langroid installed in editable mode with pip install -e .
PoC script:
from pathlib import Path from tempfile import TemporaryDirectory import os
os.environ["docker"] = "false" os.environ["DOCKER"] = "false"
from langroid.agent.tools.file_tools import ReadFileTool, WriteFileTool
class DummyIndex: def add(self, files): print("dummy git add:", files)
def commit(self, message):
print("dummy git commit:", message)
class DummyRepo: index = DummyIndex()
with TemporaryDirectory() as root: base = Path(root) sandbox = base / "sandbox" sandbox.mkdir()
secret = base / "secret.txt"
secret.write_text("LANGROID_TOOL_ESCAPE_PROOF", encoding="utf-8")
ReadSandbox = ReadFileTool.create(get_curr_dir=lambda: sandbox)
read_tool = ReadSandbox(file_path="../secret.txt")
print("READ TOOL RESULT:")
print(read_tool.handle())
WriteSandbox = WriteFileTool.create(
get_curr_dir=lambda: sandbox,
get_git_repo=lambda: DummyRepo(),
)
write_tool = WriteSandbox(
file_path="../written_by_tool.txt",
content="WRITTEN_BY_LANGROID_TOOL",
language="text",
)
print("WRITE TOOL RESULT:")
print(write_tool.handle())
outside = base / "written_by_tool.txt"
print("outside exists:", outside.exists())
print("outside content:", outside.read_text(encoding="utf-8"))
Observed output:
READ TOOL RESULT:
CONTENTS of ../secret.txt:
(Line numbers added for reference only!)
---------------------------
1: LANGROID_TOOL_ESCAPE_PROOF
WRITE TOOL RESULT: Content created/updated in: ..\written_by_tool.txt dummy git add: ['../written_by_tool.txt'] dummy git commit: Agent write file tool Content written to ../written_by_tool.txt and committed outside exists: True outside content: WRITTEN_BY_LANGROID_TOOL
This demonstrates that both read and write operations can escape the configured curr_dir using ../ traversal.
Impact
If an application enables Langroid's file tools and treats curr_dir as a project, workspace, repository, or sandbox boundary, a tool caller can escape that boundary.
Potential impact includes:
Reading files outside the intended workspace. Writing files outside the intended workspace. Exposing local secrets, configuration files, source files, environment files, or other project-adjacent files. Modifying files outside the intended project directory if WriteFileTool is enabled.
This is especially relevant in agentic workflows where an LLM or external user can influence tool arguments.
This report does not claim unauthenticated remote exploitation by default. The impact depends on how an application exposes Langroid file tools and whether curr_dir is intended to restrict file access.
Suggested remediation
Before reading, writing, or listing files, resolve the configured base directory and the requested target path, then reject any path that escapes the base directory.
Example patch pattern:
from pathlib import Path
def safe_join(base_dir: str | Path, user_path: str | Path) -> Path: base = Path(base_dir).resolve() target = (base / user_path).resolve()
if target != base and base not in target.parents:
raise ValueError("Path escapes configured current directory")
return target
Then use the resolved safe path for ReadFileTool, WriteFileTool, and ListDirTool.
Suggested regression tests:
ReadFileTool(file_path="../secret.txt") should be rejected. WriteFileTool(file_path="../outside.txt") should be rejected. Absolute paths outside curr_dir should be rejected. Symlink-based escapes should be rejected after final path resolution. Normal relative paths inside curr_dir, such as src/main.py, should continue to work.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.63.0"
},
"package": {
"ecosystem": "PyPI",
"name": "langroid"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.64.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-50181"
],
"database_specific": {
"cwe_ids": [
"CWE-22",
"CWE-23"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-02T17:38:03Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Summary\n\nLangroid\u0027s `ReadFileTool` and `WriteFileTool` appear to treat `curr_dir` as the intended working-directory boundary for file operations. However, the tools only change the process working directory to `curr_dir` and then operate on the user-supplied `file_path` without resolving and enforcing that the final path remains inside `curr_dir`.\n\nAs a result, a tool caller can supply path traversal sequences such as `../secret.txt` to read files outside the configured current directory, or `../written_by_tool.txt` to write files outside that directory.\n\nThis can impact applications that expose Langroid file tools to an LLM agent, user-controlled tool call, or delegated coding/documentation agent while relying on `curr_dir` to restrict file access to a project/workspace directory.\n\n### Details\n\nAffected components:\n\n- `langroid/agent/tools/file_tools.py`\n- `langroid/utils/system.py`\n\nRelevant behavior observed:\n\n`ReadFileTool` contains a comment indicating the intended assumption:\n\n```text\n# ASSUME: file_path should be relative to the curr_dir\n\nThe tool then changes into the configured current directory and calls read_file(self.file_path).\n\nWriteFileTool similarly resolves curr_dir, changes into that directory, and calls create_file(self.file_path, self.content).\n\nThe issue is that changing the process working directory does not prevent traversal. A path such as ../secret.txt is still valid and resolves outside the configured curr_dir.\n\nIn local testing, ReadFileTool successfully read a file outside the configured sandbox directory, and WriteFileTool successfully wrote a file outside the configured sandbox directory.\n\nPoC\n\nTested locally against the current Langroid repository checkout.\n\nEnvironment:\n\nPython 3.12\nLangroid installed in editable mode with pip install -e .\n\nPoC script:\n\nfrom pathlib import Path\nfrom tempfile import TemporaryDirectory\nimport os\n\nos.environ[\"docker\"] = \"false\"\nos.environ[\"DOCKER\"] = \"false\"\n\nfrom langroid.agent.tools.file_tools import ReadFileTool, WriteFileTool\n\n\nclass DummyIndex:\n def add(self, files):\n print(\"dummy git add:\", files)\n\n def commit(self, message):\n print(\"dummy git commit:\", message)\n\n\nclass DummyRepo:\n index = DummyIndex()\n\n\nwith TemporaryDirectory() as root:\n base = Path(root)\n sandbox = base / \"sandbox\"\n sandbox.mkdir()\n\n secret = base / \"secret.txt\"\n secret.write_text(\"LANGROID_TOOL_ESCAPE_PROOF\", encoding=\"utf-8\")\n\n ReadSandbox = ReadFileTool.create(get_curr_dir=lambda: sandbox)\n read_tool = ReadSandbox(file_path=\"../secret.txt\")\n\n print(\"READ TOOL RESULT:\")\n print(read_tool.handle())\n\n WriteSandbox = WriteFileTool.create(\n get_curr_dir=lambda: sandbox,\n get_git_repo=lambda: DummyRepo(),\n )\n\n write_tool = WriteSandbox(\n file_path=\"../written_by_tool.txt\",\n content=\"WRITTEN_BY_LANGROID_TOOL\",\n language=\"text\",\n )\n\n print(\"WRITE TOOL RESULT:\")\n print(write_tool.handle())\n\n outside = base / \"written_by_tool.txt\"\n print(\"outside exists:\", outside.exists())\n print(\"outside content:\", outside.read_text(encoding=\"utf-8\"))\n\nObserved output:\n\nREAD TOOL RESULT:\n\n CONTENTS of ../secret.txt:\n (Line numbers added for reference only!)\n ---------------------------\n 1: LANGROID_TOOL_ESCAPE_PROOF\n\nWRITE TOOL RESULT:\nContent created/updated in: ..\\written_by_tool.txt\ndummy git add: [\u0027../written_by_tool.txt\u0027]\ndummy git commit: Agent write file tool\nContent written to ../written_by_tool.txt and committed\noutside exists: True\noutside content: WRITTEN_BY_LANGROID_TOOL\n\nThis demonstrates that both read and write operations can escape the configured curr_dir using ../ traversal.\n\nImpact\n\nIf an application enables Langroid\u0027s file tools and treats curr_dir as a project, workspace, repository, or sandbox boundary, a tool caller can escape that boundary.\n\nPotential impact includes:\n\nReading files outside the intended workspace.\nWriting files outside the intended workspace.\nExposing local secrets, configuration files, source files, environment files, or other project-adjacent files.\nModifying files outside the intended project directory if WriteFileTool is enabled.\n\nThis is especially relevant in agentic workflows where an LLM or external user can influence tool arguments.\n\nThis report does not claim unauthenticated remote exploitation by default. The impact depends on how an application exposes Langroid file tools and whether curr_dir is intended to restrict file access.\n\nSuggested remediation\n\nBefore reading, writing, or listing files, resolve the configured base directory and the requested target path, then reject any path that escapes the base directory.\n\nExample patch pattern:\n\nfrom pathlib import Path\n\ndef safe_join(base_dir: str | Path, user_path: str | Path) -\u003e Path:\n base = Path(base_dir).resolve()\n target = (base / user_path).resolve()\n\n if target != base and base not in target.parents:\n raise ValueError(\"Path escapes configured current directory\")\n\n return target\n\nThen use the resolved safe path for ReadFileTool, WriteFileTool, and ListDirTool.\n\nSuggested regression tests:\n\nReadFileTool(file_path=\"../secret.txt\") should be rejected.\nWriteFileTool(file_path=\"../outside.txt\") should be rejected.\nAbsolute paths outside curr_dir should be rejected.\nSymlink-based escapes should be rejected after final path resolution.\nNormal relative paths inside curr_dir, such as src/main.py, should continue to work.\n\n[Langroid CVE Report.pdf](https://github.com/user-attachments/files/28333958/Langroid.CVE.Report.pdf)",
"id": "GHSA-fg23-3346-88f5",
"modified": "2026-07-02T17:38:04Z",
"published": "2026-07-02T17:38:03Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/langroid/langroid/security/advisories/GHSA-fg23-3346-88f5"
},
{
"type": "WEB",
"url": "https://github.com/langroid/langroid/commit/56e2756ecab70a70a7e6edbee2f2187b8484683e"
},
{
"type": "PACKAGE",
"url": "https://github.com/langroid/langroid"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Langroid: Path traversal in the file tools allows read/write outside configured current directory"
}
GHSA-FHV3-Q37G-RJX5
Vulnerability from github – Published: 2026-05-29 15:30 – Updated: 2026-05-29 15:30Path traversal vulnerability in Remote Spark (https://www.Remotespark.Com/) SparkView allows reading and writing arbitrary files in all directories as root. This leads to RCE. The affected component is the RDP drive redirection. Depending on implementation, the vulnerability can be exploited by an unauthenticated attacker.
This issue affects SparkView: before build 1127.
{
"affected": [],
"aliases": [
"CVE-2026-8326"
],
"database_specific": {
"cwe_ids": [
"CWE-23"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-29T13:16:23Z",
"severity": "CRITICAL"
},
"details": "Path traversal vulnerability in Remote Spark (https://www.Remotespark.Com/) SparkView allows reading and writing arbitrary files in all directories as root. This leads to RCE. The affected component is the RDP drive redirection.\u00a0\u00a0Depending on implementation, the vulnerability can be exploited by an unauthenticated attacker.\n\nThis issue affects SparkView: before build 1127.",
"id": "GHSA-fhv3-q37g-rjx5",
"modified": "2026-05-29T15:30:33Z",
"published": "2026-05-29T15:30:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-8326"
},
{
"type": "WEB",
"url": "https://www.remotespark.com/view/new.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
Mitigation MIT-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.