CVE-2026-16077: 
AstrBot vulnerability analysis and mitigation

CVE-2026-16077 is a link-following (symlink/hardlink) vulnerability in AstrBotDevs AstrBot affecting versions up to and including 4.25.5. The flaw resides in the _normalize_rw_path function within astrbot/core/tools/computer_tools/fs.py, part of the Filesystem Computer-Use Tool component. It was disclosed on July 18, 2026, with a proof-of-concept published by researcher YLChen-007 on June 9, 2026; the vendor did not respond to early disclosure contact. The vulnerability carries a CVSS v3.1 base score of 5.3 (Medium) and a CVSS v4.0 base score of 1.9 (Low) (GitHub Advisory, VulDB).

The root cause is CWE-59 (Improper Link Resolution Before File Access — 'Link Following'). AstrBot's _is_path_within_allowed_roots() function authorizes a requested path by resolving its pathname and checking whether it falls under an allowed workspace root (e.g., data/workspaces/{normalized_umo}), but it does not verify whether the resolved path is a hardlink alias pointing to an inode outside the workspace. As a result, _normalize_rw_path() returns the approved in-workspace path to FileReadTool.call() and FileWriteTool.call(), which then pass it directly to the filesystem backend — allowing reads and writes to affect the out-of-workspace file sharing the same inode. Exploitation requires local access with low privileges (a member-role session in restricted local runtime mode with computer_use_require_admin=True), and the target file must reside on the same filesystem as the workspace and be accessible to the AstrBot process (PoC Gist).

A low-privileged local user (member role) can read or overwrite files outside their designated workspace boundary by creating a hardlink inside the workspace that aliases an out-of-workspace inode. This breaks AstrBot's documented security boundary for restricted local members, compromising confidentiality and integrity of host-local files reachable under the AstrBot runtime account. Availability impact is limited; the vulnerability does not imply full host compromise but could expose sensitive configuration files, credentials, or other data accessible to the AstrBot process (PoC Gist, GitHub Advisory).

A public proof-of-concept was published by researcher YLChen-007 on GitHub Gist (created June 9, 2026), including a verification driver and reproduction scripts. There is no evidence of in-the-wild exploitation or threat actor attribution at this time. The vulnerability is not listed in the CISA KEV catalog. The EPSS score is approximately 0.168% (6th percentile), indicating low near-term exploitation probability. Exploitation is not automatable and requires local access (GitHub Advisory, VulDB).

1. Prerequisite setup: Obtain a local member-role session on an AstrBot instance running in local runtime mode with provider_settings.computer_use_require_admin=True. Confirm the workspace directory and the target out-of-workspace file reside on the same filesystem and that the AstrBot process has read/write access to the target file.
2. Identify target file: Locate a sensitive file outside the allowed workspace root (e.g., /tmp/outside/secret.txt) that the AstrBot process can access but the member role should not.
3. Create hardlink alias: From within the workspace directory (e.g., data/workspaces/{umo}/), create a hardlink pointing to the target out-of-workspace file: ln /tmp/outside/secret.txt data/workspaces/{umo}/linked.txt. Both paths now share the same inode.
4. Trigger read via AstrBot tool: Invoke astrbot_file_read_tool with the in-workspace path linked.txt. The _is_path_within_allowed_roots() check resolves the pathname to the workspace and authorizes it; the read operation returns the content of the out-of-workspace file.
5. Trigger write via AstrBot tool: Invoke astrbot_file_write_tool with linked.txt as the target and arbitrary content. The same flawed authorization passes, and sb.fs.write_file overwrites the out-of-workspace file through the hardlink alias.
6. Verify impact: Confirm the out-of-workspace file's content has changed (e.g., outside_text_after: 'pwned-via-hardlink'), demonstrating successful boundary bypass (PoC Gist).

• File System: Presence of unexpected hardlinks inside AstrBot workspace directories (files with nlink > 1 pointing to inodes outside the workspace); use find data/workspaces/ -links +1 or stat to identify files with multiple hard link counts.
• File System: Unexpected modification timestamps (mtime) on files outside the workspace boundary that correspond to AstrBot tool invocation times.
• Logs: AstrBot access or audit logs showing astrbot_file_read_tool or astrbot_file_write_tool invocations by member-role users targeting filenames that resolve to inodes with nlink > 1.
• Process: AstrBot process performing filesystem read/write operations on paths outside configured allowed roots, detectable via auditd rules on the AstrBot process UID targeting paths outside data/workspaces/ (PoC Gist).

Upgrade AstrBot to a version newer than 4.25.5, which addresses the hardlink alias bypass. As an interim workaround, implement OS-level filesystem access controls (e.g., nosymfollow mount options, or restricting the AstrBot process to a dedicated user account with minimal filesystem permissions) to limit the blast radius of hardlink abuse. Additionally, monitor workspace directories for files with hard link counts greater than 1 and alert on unexpected cross-boundary inode sharing. The vendor did not respond to the initial disclosure, so users should monitor the official AstrBot repository for patch releases (GitHub Advisory, VulDB).