Summary
Code Graph RAG can follow a symbolic link inside an analyzed repository to a file outside the configured project root. If a victim analyzes a repository containing such a link, structural search may disclose readable files, and structural replacement may overwrite writable files without an approval gate.
Code Graph RAG can follow a symbolic link inside an analyzed repository to a file outside the configured project root. If a victim analyzes a repository containing such a link, structural search may disclose readable files, and structural replacement may overwrite writable files without an approval gate.
Affected context
The issue occurs when Code Graph RAG's AST-based tools enumerate and access files beneath a configured project root. The path check uses unresolved lexical paths, so a link that appears to be inside the root can point outside it. Risk depends on the analyzed repository containing such a link and on the process having access to the target file.
The issue occurs when Code Graph RAG's AST-based tools enumerate and access files beneath a configured project root. The path check uses unresolved lexical paths, so a link that appears to be inside the root can point outside it. Risk depends on the analyzed repository containing such a link and on the process having access to the target file.
Exploit preconditions
- Attack surface: File access by structural search or structural replacement while analyzing a repository
- Required access: An attacker must be able to provide or influence a repository that the victim analyzes
- Trigger point: A tool follows a repository symlink during search or replacement
- Why exploitation is possible: The containment check does not resolve the link target before access; the MCP replacement path also lacks the agent-loop approval control
- Attack surface: File access by structural search or structural replacement while analyzing a repository
- Required access: An attacker must be able to provide or influence a repository that the victim analyzes
- Trigger point: A tool follows a repository symlink during search or replacement
- Why exploitation is possible: The containment check does not resolve the link target before access; the MCP replacement path also lacks the agent-loop approval control
Why this happens
The path validation checks lexical paths without resolving symbolic links and verifying the resolved target remains within the configured root. File operations then follow the link, allowing access beyond the intended directory boundary. This is improper link resolution before file access (CWE-59) and can also result in path traversal (CWE-22).
The path validation checks lexical paths without resolving symbolic links and verifying the resolved target remains within the configured root. File operations then follow the link, allowing access beyond the intended directory boundary. This is improper link resolution before file access (CWE-59) and can also result in path traversal (CWE-22).
Potential impact
- Structural search may disclose credentials, keys, environment files, or source code readable by the process
- Structural replacement may modify files writable by the process outside the analyzed project
- Sensitive data could be exposed or altered, depending on the process's permissions
- Changes to accessible files could disrupt services or affect other projects
- Structural search may disclose credentials, keys, environment files, or source code readable by the process
- Structural replacement may modify files writable by the process outside the analyzed project
- Sensitive data could be exposed or altered, depending on the process's permissions
- Changes to accessible files could disrupt services or affect other projects
General mitigation guidance
Defensive patterns should ensure that file access remains confined to the intended project boundary:
- Resolve candidate paths and verify their resolved targets remain within the configured root before reading or writing
- Use filesystem operations and policies that prevent unintended symbolic-link following where practical
- Apply equivalent boundary checks to enumeration, search, and replacement paths
- Require explicit authorization for potentially destructive operations, including through alternate tool interfaces
- Treat repository contents as untrusted input and run analysis with least-privilege filesystem permissions
- Limit access to sensitive files and use read-only access when modification is not needed
Defensive patterns should ensure that file access remains confined to the intended project boundary:
- Resolve candidate paths and verify their resolved targets remain within the configured root before reading or writing
- Use filesystem operations and policies that prevent unintended symbolic-link following where practical
- Apply equivalent boundary checks to enumeration, search, and replacement paths
- Require explicit authorization for potentially destructive operations, including through alternate tool interfaces
- Treat repository contents as untrusted input and run analysis with least-privilege filesystem permissions
- Limit access to sensitive files and use read-only access when modification is not needed
How teams detect issues like this
- Use static analysis to find path containment checks performed before canonicalization or without accounting for symbolic links
- Review file enumeration and read/write code for operations that follow links outside a configured root
- Check that all tool interfaces enforce consistent authorization and path-boundary policies
- Add tests with links targeting both in-root and out-of-root files, verifying that reads and writes are constrained
- Apply policy checks to flag filesystem access from untrusted repositories that is not confined to an approved workspace
- Use static analysis to find path containment checks performed before canonicalization or without accounting for symbolic links
- Review file enumeration and read/write code for operations that follow links outside a configured root
- Check that all tool interfaces enforce consistent authorization and path-boundary policies
- Add tests with links targeting both in-root and out-of-root files, verifying that reads and writes are constrained
- Apply policy checks to flag filesystem access from untrusted repositories that is not confined to an approved workspace
