1. AI供应链攻击升级：攻击者开始用AI生成高质量恶意代码，使恶意包与正常开源项目几乎无法区分，传统检测体系正在失效。

2. Agent成为新攻击入口：攻击目标正从应用本身转向Agent执行链，通过工具调用和流程控制实现系统级入侵。

3. 身份与权限成为核心风险：Shadow AI与Agent角色越权频发，说明AI系统正在被“身份层”而不是“代码层”突破。

4. 上下文污染取代传统提示注入：攻击已从单点提示注入，演化为通过网页、数据源持续污染Agent决策过程。

5. AI基础设施漏洞在野化加速：MCP、AI中间件和Agent SDK漏洞在披露后极短时间内即被利用，补丁窗口正在收缩。

• 应用安全（4）· 供应链攻击 / 提示注入 / 在野利用 / Agent安全

• 身份安全（2）· 特权升级 / AI身份冒用

• 模型安全（1）· MCP协议架构漏洞

完整威胁分类，可在社区主页查看。

本次我们准备了 10 个 AISS 社区邀请码。获取方式： 转发本文 + 点赞 + 评论区留言「申请邀请码」我们将从评论区中抽取 10 位朋友，私信发送邀请码。AISS 是专注 AI 安全的开放社区，涵盖大模型安全风险矩阵、知识库、案例库与事件库，欢迎 AI 安全研究者、开发者与企业安全团队加入共建。

用户态（低权限）
  │
  ├─ splice() 将目标文件（如 /usr/bin/su）→ pipe → page cache 页引用
  │     （无需写权限，仅读权限）
  │
  ├─ sendmsg(MSG_SPLICE_PAGES) → AF_ALG socket → TX SGL
  │     （page cache 页被放入 crypto scatterlist）
  │
  ├─ recvmsg() 触发 AEAD 解密操作
  │     └─ in-place 操作：src == dst，page cache 页在 writable SGL 中
  │     └─ authencesn 解密时执行 scratch write，向 dst[assoclen+cryptlen] 写入 4 字节
  │     └─ 这 4 字节跨越 RX SGL 边界，写入链接着的 TX SGL page cache 页
  │
  └─ execve("/usr/bin/su") → 从 page cache 加载 → shellcode 执行 → root

ApexEye智能体构建了三大攻击链：

1. LPE攻击链：低权限用户污染本地setuid文件页缓存，执行后提权至root。

2. 跨容器逃逸攻击链：识别同镜像容器共享页缓存不受namespace隔离，一个容器注入shellcode，同镜像其他容器执行同一文件即获root。

3. 宿主机逃逸攻击链：通过/proc/1/root/访问宿主机文件系统，污染宿主机二进制页缓存，等待宿主机用户执行后完成逃逸。

让我们更惊喜的是，ApexEye在此基础上构造出了在特定条件下，无需宿主机交互，直接获得宿主机 root权限的攻击链。

Copy Fail对云原生环境构成致命威胁

• Kubernetes集群：恶意Pod可逃逸至宿主机，进而控制整个节点

• CI/CD流水线：构建容器可篡改宿主机工具链，实现供应链攻击

• 多租户PaaS平台：租户间隔离可被突破，导致横向移动

• Serverless/函数计算：底层宿主机权限可被获取

缓解措施与安全建议

紧急缓解措施

# 1. 立即禁用 algif_aead 内核模块
echo"install algif_aead /bin/false"> /etc/modprobe.d/disable-algif-aead.conf
rmmod algif_aead 2>/dev/null
# 2. 或通过 seccomp 策略阻止 AF_ALG socket
# 在容器运行时添加：
--security-opt seccomp=/path/to/seccomp-profile.json
# 其中 seccomp-profile 禁止 socket(AF_ALG, ...)
# 3. 更新内核至包含修复的版本（≥ commit a664bf3d603d）

Seccomp 策略示例

{
    "defaultAction":"SCMP_ACT_ALLOW",
    "architectures":["SCMP_ARCH_X86_64"],
    "syscalls":[
        {
            "names":["socket"],
            "action":"SCMP_ACT_ALLOW",
            "args":[
                {
                    "index":0,
                    "value":38,
                    "op":"SCMP_CMP_NE"
                }
            ]
        }
    ]
}

Kubernetes 缓解措施

# Pod Security Policy (PSP) / OPA 策略
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sBlockAFALG
spec:
    match:
        kinds:["Pod"]
    parameters:
        denySocketFamily:38# AF_ALG

# 避免使用相同基础镜像的敏感 Pod 共置
# 使用 nodeSelector / podAntiAffinity 隔离
spec:
    affinity:
        podAntiAffinity:
            requiredDuringSchedulingIgnoredDuringExecution:
            -labelSelector:
                matchLabels:
                    app: sensitive
             topologyKey: kubernetes.io/hostname

CVE-2026-39987 的成因异常简单，简单到令人警觉。Marimo 提供了一个基于 WebSocket 的终端功能（路径 /terminal/ws），用于在 notebook 界面内嵌入交互式 Shell。问题在于该端点完全跳过了认证验证，而其他端点（如 /ws）均正确调用了 validate_auth()。

任何能访问 Marimo 服务端口的未认证攻击者，只需建立一个 WebSocket 连接，即可获得完整的 PTY Shell——等同于直接拿到 SSH 登录权限，且无需任何凭证。

NKAbuse 最初由卡巴斯基于 2023 年 12 月记录，是一种利用 NKN（New Kind of Network）协议实现 C2 通信的 Go 语言后门。NKN 是基于区块链的去中心化网络协议，节点分散在全球，无单一 IP 或域名可屏蔽，C2 流量混入正常区块链活动，对传统检测体系近乎隐形。

这次攻击中最值得关注的战术创新，不是漏洞本身，而是将受信任的 AI 平台转化为恶意软件分发节点。攻击者创建的 Space 命名为 vsccode-modetx——针对【vscode】的拼写仿冒。在 Sysdig 分析时，该恶意 Space 在 16 个声誉评分来源中均获得 0 分（无威胁标记）。

• 升级 Marimo 至 0.23.0+ — 立即升级

• 威胁猎杀 — 在所有曾运行 Marimo 的主机上搜索 ~/.kagent/ 目录、kagent.service systemd 服务项、正在运行的 kagent 进程。发现任何一项，立即隔离主机。

• DNS / 代理层封锁 — 在 DNS 和代理层面屏蔽 vsccode-modetx.hf.space，阻断已知载荷投递 URL。

• 凭证轮换 — 对所有暴露过 Marimo 实例的环境，强制轮换 DATABASE_URL、AWS/GCP Key、OpenAI/Anthropic API Token 等高价值凭证。

• 网络访问控制 — Marimo 及类似 notebook 服务严禁直接暴露至公网，强制通过 VPN、堡垒机或带认证的反向代理访问，监听地址从 0.0.0.0 收紧至 127.0.0.1。

• AI 平台依赖审计 — 建立对 Hugging Face Spaces 等 AI 资产平台的访问白名单策略，限制生产环境从非验证来源拉取脚本或二进制文件。

• 运行时行为检测 — 部署基于行为的运行时检测（如 Falco、Sysdig Agent），针对 notebook 进程产生的非预期子进程、外联连接、文件创建行为设置告警规则。签名检测对此类新变种无效。

AISS安全智链社区已收录本案例，感兴趣的读者可前往 https://aiss.nsfocus.com/#/ai-cases 查看更多 AI 安全相关案例分析与最新研究。

本次我们准备了 10 个 AISS 社区邀请码。获取方式： 转发本文 + 点赞 + 评论区留言「申请邀请码」我们将从评论区中抽取 10 位朋友，私信发送邀请码。AISS 是专注 AI 安全的开放社区，涵盖大模型安全风险矩阵、知识库、案例库，欢迎 AI 安全研究者、开发者与企业安全团队加入共建。

GrafanaGhost 漏洞的本质是大数据平面模型（LLM）控制平面与数据平面模型的交互。当 Grafana 的 AI 智能体（Agent）包含恶意指令的外部非受信（如错误日志、外部同样、第三方集成数据）时，未能有效实现上下文隔离。攻击者通过构造特定的语义提示，污染 AI 的上下文窗口，进一步内容劫持 AI 智能体的工具调用逻辑（Tool Calling），从而造成原有安全护栏，执行非预期的备份。

本漏洞的攻击序列清晰，序列性极强。

• 零点击静默触发：相较于传统社会工程学攻击，GrafanaGhost 彻底摆脱了对用户交互行为的依赖。只要管理员或系统例行调用 AI 助手分析包含恶意载荷的面板、日志或告警条目，攻击逻辑即刻在后台静默触发，利用成本极低。

• 核心监控资产失陷：Grafana 承担着企业统一观测平台与运维数据集成节点的职能，后端深度关联着业务核心指标、基础架构拓扑及各类 API 凭证。漏洞允许攻击者绕过鉴权逻辑，精准提取这些维系业务运行的高价值敏感资产。

• 高度隐蔽性与持续驻留：由于注入指令潜伏在正常的业务日志或外部遥测数据流中，且数据外泄行为高度混淆于常规的静态图片加载请求内，现有的 WAF 过滤规则与 SOC 审计逻辑极难有效识别并拦截此类带外（OOB）攻击行为。

在AI业务大规模落地的背景下，针对AI智能体应用侧安全，建议采取以下手段：

1. 明确数据与边界指令（数据构造）：在LLM处理外部非置信日志之前，增加专门的清理（清理）层，或强制采用数据格式（如JSON）传递上下文，分割文本中的指令性语气。

2. 收敛AI工具调用权限（最小权限原则）：严格限制AI助手对核心数据库的直接访问权限。对于涉及数据导出的敏感API，必须引入强制的人工中间环节（HITL）。

3. 封堵带外（OOB）外传通道：在接入渲染层实施严格的内容安全策略（CSP），禁止加载未授权的外部域资源；在网络层对可落地平台的出站流量（Egress）进行白管名单控制。

Vertex AI Agent Engine 在部署 AI 代理时，默认使用 Per-Project, Per-Product Service Agent（P4SA）服务账号，其格式通常为 service-@gcp-sa-aiplatform-re.iam.gserviceaccount.com。该账号被授予的权限范围远超代理实际运行所需，为攻击提供了可乘之机。

1. 攻击者通过 Google Cloud Agent Development Kit（ADK）构建恶意代理，并将核心恶意代码打包成 pickle 格式的 code.pkl 文件；

2. 代理运行时自动访问 Google 元数据服务，获取 P4SA 服务账号的访问令牌、项目信息以及 OAuth scopes；

3. 利用获取到的凭证，读取消费者项目内的 Cloud Storage 存储桶内容；

4. 进一步访问 Google 内部受限的 Artifact Registry 仓库（如 us-docker.pkg.dev/cloud-aiplatform-private/reasoning-engine），成功下载官方容器镜像、Dockerfile 及相关依赖文件。

报告中完整展示了从凭证提取到跨项目资源访问的全过程。攻击者甚至从中获取了谷歌内部 Dockerfile 中硬编码的存储桶路径和项目信息。

1. 服务账号权限过度：P4SA默认拥有storage.buckets.get、storage.buckets.list、storage.objects.get等权限，能够遍历并读取项目内多数Cloud Storage资源。官方文档虽有记录，但实际部署时经常被忽略。

2. 不安全的序列化方式：Vertex AI Agent Engine使用Python pickle序列化代理代码。Python官方文档明确指出，从不可信来源加载pickle存在任意代码执行风险。攻击者修改code.pkl即可在运行时注入恶意操作。

3. OAuth 2.0 scopes设置宽松：报告指出默认分配的 OAuth 2.0 scopes 过于宽松且无法编辑，这可能将访问范围扩展到 Google Workspace 服务（Gmail、Google Calendar、Google Drive 等）。这一默认配置属于结构性安全弱点。

• 数据泄露风险：攻击者可静默读取项目内敏感文件，整个过程几乎无明显告警，隐蔽性极高；

• 供应链攻击潜力：获取谷歌内部 Artifact Registry 镜像后，攻击者能够逆向分析 Vertex AI 的实现细节，进而构造更高级的逃逸或绕过技术；

• 持久化后门：恶意代理在每次正常调用时均执行窃取逻辑，常规日志难以区分，易实现长期潜伏；

• 横向移动能力：若 OAuth scopes 涉及 Workspace 服务，可能导致敏感数据在企业级范围内扩散，形成更大范围的 compromise。

谷歌在收到 Unit 42 报告后，已更新官方文档，明确说明了 Vertex AI 资源、账号及代理的使用规范。但要真正提升安全水平，仍需用户主动加固配置。推荐采取以下措施：

1.  强制使用 Bring Your Own Service Account（BYOSA） 放弃默认的 P4SA 服务账号，创建专用服务账号并严格遵循最小权限原则（Principle of Least Privilege），仅授予代理实际运行所需的权限。在 Agent Engine 配置中明确指定该自定义账号。

2. 收紧 OAuth 2.0 scopes 默认 scopes 过于宽松且无法直接编辑，存在显著凭证滥用风险。建议结合 BYOSA 配置，进一步限制整体访问范围，避免不必要的服务暴露。

3. 谨慎使用 pickle 序列化 由于 pickle 存在固有的任意代码执行风险，建议优先采用其他更安全的序列化方式，或在可信隔离环境完成代码打包，并进行严格的代码审查和安全扫描。

4. 加强 Artifact Registry 访问控制 对 Google 内部及项目内的 Artifact Registry 仓库实施严格的访问限制，防止被 compromised 的服务账号下载受限镜像和内部依赖文件。

截至目前，AISS安全智链社区已收录百余条案例，涵盖多种AI安全风险，感兴趣的读者可前往 https://aiss.nsfocus.com/#/ai-cases 查看更多 AI 安全相关案例分析与最新研究。

[1]axios@1.14.1:mailto:axios@1.14.1

[2]axios@0.30.4:mailto:axios@0.30.4

[3]StepSecurity - axios Compromised on npm:https://www.stepsecurity.io/blog/axios-compromised-on-npm-malicious-versions-drop-remote-access-trojan

[4]GitHub - axios/axios Issue #10604:https://github.com/axios/axios/issues/10604

[5]Aikido Security - axios compromised on npm:https://www.aikido.dev/blog/axios-npm-compromised-maintainer-hijacked-rat

[6]Socket.dev - Supply Chain Attack on Axios:https://socket.dev/blog/axios-npm-package-compromised

[7]VibeAudits - Axios npm Supply Chain Attack:https://vibeaudits.com/blog/axios-npm-supply-chain-attack-31-march-26-what-happened-whos-affected

1. 双层桥接架构（Bridge & Gateway）：OpenClaw 表面上通过 ACP 接收客户端请求，但内部实际上会将请求翻译并转发到自己的 Gateway，再由 Gateway 去调度真正的模型或工具。

2. 多 Agent 调度（Multi-Harness）：OpenClaw 可以同时挂载多个 Agent，并利用 ACP 反向调用外部 Agent 进行工作流接力。

3. 会话的持久化与线程绑定：传统 ACP 断开即丢失，而 OpenClaw 的 ACP 会话可以持久化存储，并且能与 Discord、Telegram 等外部通道的频道/用户进行线程绑定。

同时，OpenClaw 在 WebSocket 连接之上叠加了多因子认证：Gateway Token、设备签名（Ed25519）、Bootstrap Token、Tailscale 身份等，形成了严格的零信任接入策略。简而言之：在 OpenClaw 的语境下，ACP 已经从一个本地开发协议，升级为进入整个多 Agent 编排体系的"远程控制总线"。

{
  "type": "event",
  "event": "connect.challenge",
  "payload": {
    "nonce": "550e8400-e29b-41d4-a716-446655440000",
    "ts": 1774000000000
  }
}

1. 100% 确认目标身份 — connect.challenge是 OpenClaw 特有的握手消息

2. 完全被动 — 无需发送任何载荷，不存在误触发风险

3. 无法规避 — 即使更换 WebSocket 路径，只要连接成功就会触发

4. 极其隐蔽 — 不会在目标日志中留下请求记录

缺少凭证时：

{
  "type": "res",
  "id": 1,
  "ok": false,
  "error": {
    "code": -32600,
    "message": "unauthorized: gateway token missing (open the dashboard URL and paste the token in Control UI settings)"
  }
}

Token 位置错误时：

{
  "error": {
    "message": "invalid connect params: at /device: unexpected property 'token' "
  }
}

1. 确认产品身份 — gateway token、Control UI settings 是 OpenClaw 特有术语

2. 推断认证架构 — 区分 CLI 和 Control UI 两种客户端场景

3. 确认 Schema 机制 — 网关使用严格的 JSON Schema 校验，且校验发生在认证之前

{
  "type": "res",
  "id": "...",
  "ok": false,
  "error": {
    "code": "INVALID_REQUEST",
    "message": "invalid handshake: first request must be connect"
  }
}

请求：

{
  "type": "req",
  "id": "test-id-456",
  "method": "chat.history",
  "params": {
    "sessionKey": "agent:main:discord:channel:12345",
    "agentId": "main",
    "limit": 10
  }
}

响应：

{
  "type": "res",
  "id": "test-id-456",
  "ok": false,
  "error": {
    "code": "INVALID_REQUEST",
    "message": "invalid chat.history params: at root: unexpected property 'agentId'"
  }
}

1. 确认处理链路 — 请求需经过 WebSocket 帧解析 → RPC 方法路由 → Agent 级参数校验

2. 确认 Schema 独立性 — 不同方法的 Schema 是独立定义的

3. 推断 sessionKey 格式 — agent:名称:平台:类型:ID 被 Schema 层接受

AUTH* 系列（共享密钥认证）：

举例：

{
"error": {
  "message": "unauthorized: gateway token mismatch"
 }
}

DEVICE_AUTH* 系列（设备身份认证）：

举例：

{
"error": {
  "message": "device signature invalid"
 }
}

其对应的认证因子主要有以下几种：

1. 完整认证架构地图 — AUTH* 系列：13 种错误原因；DEVICE_AUTH* 系列：7 种错误原因；6 种认证因子

2. 确认防护机制 — 存在速率限制（`rate_limited`）；设备签名有时效性（device-signature-stale）；nonce 防重放（device-nonce-mismatch）

3. 确认设备配对机制 — 设备身份认证（DEVICE_AUTH*）；共享密钥认证（AUTH*）；设备签名验证优先于 token 验证

第二轮测试的目标来自公开的 OpenClaw 测绘网站爬取结果，属于"已知确定资产"，用于验证新方案在大规模样本上的稳定性。

基于 434 个可达端点的统计：

• ACP 指纹命中率：418 / 434 = 96.3%

• 传统 HTTP 命中率：428 / 434 = 98.6%

• 两者一致命中：415 / 434 = 95.6%

综合两轮实验，我们得出以下结论：

1. 协议语义指纹在真实环境中有效且稳定 — 在大规模确定资产上达到 96.3% 命中率，与方案一致性超过 95%。

2. 能发现传统 HTTP 方法的漏网之鱼 — 第一轮捡漏 4 个，第二轮补充 3 个，累计 7 个目标仅被 ACP 指纹识别。

3. 两套方案定位角度不同，应配合使用 — 传统方法覆盖广（适合初筛），ACP 指纹精度高（适合确认真实网关）。在实际测绘中，建议先 HTTP 初筛，再 ACP 复核，以提高识别准确性和覆盖完整性。

前面的四层指纹已经足够完成高置信度的暴露面测绘。但为了验证 OpenClaw 作为"编排器"的深层协议特征，我们在实验室环境中完成了 Ed25519 设备签名与 Token 认证，进行深层语义探测。

作为编排器，OpenClaw 内部必然维护着一个 Agent 注册表，用于将 agent 请求路由到正确的 Agent。

向网关发送指向不存在 Agent 的调度请求：

{
  "type": "req",
  "id": "...",
  "method": "agent",
  "params": {
    "idempotencyKey": "...",
    "agentId": "fake-agent-9999",
    "method": "health",
    "params": {},
    "timeout": 10000
  }
}

{
  "type": "res",
  "id": "...",
  "ok": false,
  "error": {
    "code": "INVALID_REQUEST",
    "message": "invalid agent params: unknown agent id \"fake-agent-9999\""
  }
}

既然存在 Agent 路由表，那么是否可以通过伪造 Agent ID 来欺骗调度层，将任务劫持到恶意 Agent？

构造包含自定义 agentId 的请求，尝试调用不属于自己的 Agent：

{
  "type": "req",
  "id": "...",
  "method": "agent",
  "params": {
    "agentId": "nonexistent-harness",
    "message": "hello",
    "idempotencyKey": "uuid-here"
  }
}

{
  "type": "res",
  "id": "...",
  "ok": false,
  "error": {
    "code": "INVALID_REQUEST",
    "message": "invalid agent params: unknown agent id \"nonexistent-harness\""
  }
}

OpenClaw 原生支持跨平台会话绑定，sessionKey 中应包含通道类型和标识符。

向 chat.history 发送包含不同平台特征 sessionKey 的请求：

sessionKey: agent:main:discord:channel:12345
sessionKey: agent:main:telegram:chat:67890
sessionKey: agent:main:feishu:chat:oc_xxx
sessionKey: agent:main:qqbot:direct:abc123

OpenClaw 作为编排网关，暴露了大量 RPC 方法，其中可能存在高风险方法。

在授权状态下，通过分析网关的方法路由表和事件订阅列表。

方法分类（13 类，100+ 方法）：

高风险方法清单（14 个）：

基于上述四层指纹和四项授权后实验，我们可以为 OpenClaw 的 ACP 暴露面绘制一个完整的威胁模型：

针对部署了 OpenClaw 或类似 AI Agent 网关的企业：

• 越狱类：角色扮演越狱、CoT推理链注入、多模态越狱等

• Prompt攻击：直接/间接提示注入、零点击注入、Agent命令链攻击等

• RAG/知识库：RAG数据投毒、 Tool Poisoning / MCP工具描述投毒等

• 模型与供应链：序列化后门、模型投毒、Agent技能市场投毒等

• 隐私与数据泄露：企业机密泄露、训练数据提取、凭据外泄等

• 基础设施与部署安全：SSRF/XSS、DDoS、反序列化RCE等

• 身份与访问安全：账号接管、越权调用、未授权访问等

• AI辅助攻击：AI自主发现0Day、LLM加速渗透、AI生成恶意软件_x0005_等

社区欢迎成员补充更多开源/公开案例，特别是：

• 覆盖主流模型（包括国内开源/闭源模型）的典型示例

• 多模态场景下的公开攻击/失效案例

• 与风险矩阵高度匹配、可作为佐证的开源案例

凡与 AI 安全相关的真实案例、研究复现或公开事件，均欢迎补充与完善。

投稿流程：

1. 登录AISS社区（AISS绿盟大模型安全智链社区）

2. 进入“案例库” → 点击“提交案例”

3. 按表单提示填写信息

4. 提交后 1-3 个工作日审核通过

5. 审核通过即纳入案例库公开显示

• 在社区案例库、微信公众号等进行推荐展示

• 署名感谢贡献者

• 部分优秀案例会被纳入大模型安全知识库风险的“攻击案例”栏目