GitHub Issue
已提交官方 Issue：https://github.com/anthropics/claude-code/issues/61148
漏洞概述
Claude Code 当前版本中，permissions.deny 权限系统在特定情况下可以被 @../ 附件语法绕过。
正常情况下，被 deny 的文件：
-
无法通过
Read访问 -
无法通过绝对路径访问
-
无法通过 workspace 内
@file访问
但是：
@../path/to/file
这种“父目录穿越 attachment”语法，在目标文件位于当前 workspace 外部时，可以直接绕过权限系统并将文件内容注入模型上下文。
这是一个：
-
Permission Bypass（权限绕过）问题
-
Workspace Boundary Escape（工作区边界逃逸）问题
-
Policy Enforcement Inconsistency（策略执行不一致）问题
受影响版本
Claude Code当前所有版本 v2.1.146
测试平台：
Windows
问题核心
漏洞并不是“Claude 能读取文件”本身。
真正的问题是：
同一个文件：
| 访问方式 | 结果 |
|---|---|
Read 绝对路径
|
被 deny 拦截 |
@workspace/file
|
被 deny 拦截 |
@../outside/file
|
成功绕过 |
说明：
-
deny 系统本身是工作的
-
hook 系统本身是工作的
-
但
@../走了另一套未受保护的路径
测试目录结构
D:\TestProject ├── Library │ └── Security │ └── KeyIV.cs └── Library.Devices
敏感文件：
D:\TestProject\Library\Security\KeyIV.cs
Claude 从：
D:\TestProject\Library.Devices
启动。
此时：
Library\Security
位于当前 workspace 外部。
deny 配置
{
"permissions": {
"deny": [
"Read(**/Security/**)"
]
}
}
正常情况（权限正确生效）
方式1：绝对路径读取
输入：
Read D:\TestProject\Library\Security\KeyIV.cs
Claude 返回：
Access blocked by security policy
权限正常。
方式2：workspace 内 attachment
如果 Claude 从：
D:\TestProject
启动。
输入：
Read @Library\Security\KeyIV.cs
Claude 返回：
File path rejected by permission settings
权限正常。
漏洞触发方式（权限绕过）
Claude 从：
D:\TestProject\Library.Devices
启动。
输入：
Read @../Library/Security/KeyIV.cs
Claude 返回：
Read ..\Library\Security\KeyIV.cs (111 lines)
随后成功总结文件内容，包括：
-
AES Key/IV 实现
-
序列化格式
-
Random 种子逻辑
-
加密实现缺陷分析
整个过程中：
-
deny 未触发
-
hook 未触发
-
文件直接进入上下文
关键观察
漏洞仅在以下条件同时满足时出现：
| 条件 | 必须 |
使用 @ attachment
|
是 |
使用 ../ 父目录穿越
|
是 |
| 文件位于 workspace 外 | 是 |
如果文件位于 workspace 内，则 deny 正常生效。
技术分析
从现象看，Claude Code 内部很可能存在两套文件访问路径：
| 访问方式 | 权限检查 |
| Read Tool | 有 |
| workspace attachment | 有 |
@../ attachment
|
无 |
推测内部流程类似：
Prompt -> attachment preprocessing -> relative path resolution -> direct file read -> context injection -> permission layer (too late)
而正常安全流程应该是：
Prompt -> path normalization -> permission validation -> file read -> context injection
也就是说：
@../
很可能在“权限检查之前”就已经完成了文件读取与上下文注入。
hook 同样被绕过
我同时配置了：
PreToolUse
hook。
测试结果：
| 访问方式 | hook 是否触发 |
| 普通 Read | 触发 |
| workspace @file | 触发 |
@../file
|
不触发 |
进一步说明：
@../
并没有进入正常 Tool 执行路径。
安全影响
该问题可能导致：
-
API Key 泄漏
-
SSH Key 泄漏
-
.env泄漏 -
私有源码泄漏
-
邻接仓库泄漏
-
内部安全实现泄漏
尤其危险的是：
用户会误以为：
permissions.deny
已经保护了这些目录。
但实际上：
@../
可以绕过。
为什么这是安全问题
有些人可能会认为：
用户主动输入了
@../
所以不算漏洞。
但问题在于：
Claude Code 已经提供了：
permissions.deny
这一安全模型。
用户合理预期：
-
deny 应统一生效
-
所有文件访问方式应共享同一权限层
-
attachment 不应绕过策略
因此：
这是典型的：
Policy Enforcement Bypass
而不是普通功能行为。
建议修复方案
官方应该：
-
对所有 attachment 路径统一做 path normalization
-
在任何文件读取前执行 deny 校验
-
对
@../使用与 Read Tool 相同的权限层 -
保证 hook 在所有文件访问路径上统一触发
-
阻止 attachment preprocessing 绕过权限系统
当前临时缓解方案
在官方修复前：
不要依赖：
permissions.deny
保护 workspace 外部敏感目录。
更安全做法：
-
将敏感目录移出相邻路径
-
使用 ACL 限制 Claude 进程权限
-
使用 sandbox / VM / WSL
-
给 Claude 提供独立安全 workspace
-
避免让敏感仓库能通过
../到达
结论
Claude Code 当前版本存在：
@../
attachment 路径导致的权限绕过问题。
该问题会：
-
绕过 deny
-
绕过 hook
-
读取 workspace 外部文件
-
将敏感内容直接注入模型上下文
属于一个真实的安全边界失效问题。