CD's second night

OpenClaw 17个漏洞攻击面发布此文时只修复一个

Sun, 15 Mar 2026 00:00:00 GMT

挖了一些openclaw的漏洞有一些是官方不同意收录的，什么沙箱逃逸、组件型ssrf bypass等等，然后我后面发现官方后面又直接修复了，还好我有在用ai实时监控，为了防止再被捡漏所以在此公开，并已提交相关pr修复(当然2026/3/15之修复了一个)。

漏洞统计概览

严重级别	数量
Critical	1
High	8
Medium	8
总计	17

漏洞清单

编号	严重级别	漏洞名称	类型
GHSA-017	Critical	JSON5 原型污染 (config.patch)	原型污染
GHSA-001	High	环境变量黑名单绕过 (JVM/CLR/Build-Tool 注入)	代码执行
GHSA-002	High	TAR 提取目标目录符号链接绕过	沙箱逃逸
GHSA-004	High	Firecrawl 集成 SSRF 与 API Key 泄露	SSRF + 凭证泄露
GHSA-007	High	TTS Provider SSRF 与 API Key 泄露	SSRF + 凭证泄露
GHSA-010	High	Anthropic/Gemini PDF Provider SSRF	SSRF + 凭证泄露
GHSA-011	High	Anthropic PDF SSRF (x-api-key 泄露)	SSRF + 凭证泄露
GHSA-012	High	Gemini PDF SSRF (URL 查询参数密钥泄露)	SSRF + 凭证泄露
GHSA-014	High	MiniMax VLM SSRF (API Key + 图像泄露)	SSRF + 凭证泄露
GHSA-003	Medium	Windows 平台 O_NOFOLLOW 缺失导致新文件逃逸	工作区逃逸
GHSA-005	Medium	agentDir 配置路径遍历	路径遍历
GHSA-006	Medium	浏览器扩展 Relay Token URL 泄露	凭证暴露
GHSA-008	Medium	Media Parse 路径遍历绕过	路径遍历
GHSA-009	Medium	Ollama/vLLM SSRF (模型发现与 Stream)	SSRF
GHSA-013	Medium	Ollama Stream SSRF (聊天内容泄露)	SSRF
GHSA-015	Medium	Relay Token URL 暴露 (日志/历史记录)	凭证暴露
GHSA-016	Medium	Agent 目录路径遍历 (resolveUserPath)	路径遍历

GHSA-001: Environment Variable Blocklist Bypass via JVM/CLR/Build-Tool Injection Vectors

严重级别: High | 类型: 代码执行 | 状态: 已验证

Summary

The environment variable sanitization in OpenClaw’s host execution path fails to block several well-known code-execution-capable environment variables. An agent (or a malicious prompt injection payload) can pass attacker-controlled values for JAVA_TOOL_OPTIONS, DOTNET_STARTUP_HOOKS, MAVEN_OPTS, GRADLE_OPTS, RUSTFLAGS, and others through the env parameter of the exec tool. These variables survive both validateHostEnv() and sanitizeHostExecEnv() and reach the child process, allowing arbitrary code loading in JVM, .NET CLR, Ansible, and Rust toolchain contexts.

Severity

High (CVSS 8.1) – Arbitrary code execution on the host when the spawned process is a JVM, .NET, Ansible, Maven, Gradle, or Rust toolchain invocation.

Affected Component

src/infra/host-env-security-policy.json – blocklist definitions

src/infra/host-env-security.ts – isDangerousHostEnvVarName(), isDangerousHostEnvOverrideVarName(), sanitizeHostExecEnv()

src/agents/bash-tools.exec-runtime.ts – validateHostEnv(), execSchema

src/node-host/invoke-system-run.ts – sanitizeSystemRunEnvOverrides()

Affected Versions

Current main branch as of 2026-03-10. The blocklist has not been updated to include these variables at any point in the commit history.

Root Cause

The exec tool schema (src/agents/bash-tools.exec-runtime.ts:98-101) exposes an env parameter to the AI agent:

When an agent calls the exec tool with env: { "JAVA_TOOL_OPTIONS": "-javaagent:/tmp/evil.jar" }, the value flows through two sanitization stages. Neither blocks it.

Stage 1 – validateHostEnv() (src/agents/bash-tools.exec-runtime.ts:57-76):

isDangerousHostEnvVarName() (src/infra/host-env-security.ts:59-69) checks against blockedKeys and blockedPrefixes from host-env-security-policy.json. JAVA_TOOL_OPTIONS is in neither list.

Stage 2 – sanitizeHostExecEnv() (src/infra/host-env-security.ts:108-126):

isDangerousHostEnvOverrideVarName() checks blockedOverrideKeys and blockedOverridePrefixes. JAVA_TOOL_OPTIONS is not in those lists either. The variable passes through both checks and enters the child process environment.

Full call chain:

Missing Variables

The following environment variables allow arbitrary code loading in their respective runtimes but are absent from all four blocklists in host-env-security-policy.json:

Variable	Runtime	Effect
`JAVA_TOOL_OPTIONS`	JVM	Loads arbitrary `-javaagent:` JAR at JVM startup
`JDK_JAVA_OPTIONS`	JVM (JDK 9+)	Same as JAVA_TOOL_OPTIONS for modern JDK
`_JAVA_OPTIONS`	JVM (Oracle/OpenJDK)	Same, older variant
`MAVEN_OPTS`	Maven	Passes JVM flags to Maven, including `-javaagent:`
`GRADLE_OPTS`	Gradle	Passes JVM flags to Gradle
`DOTNET_STARTUP_HOOKS`	.NET CLR	Loads arbitrary .NET assembly at CLR startup
`CORECLR_ENABLE_PROFILING`	.NET CLR	Enables CLR profiling
`CORECLR_PROFILER_PATH`	.NET CLR	Loads arbitrary native profiler .so/.dll
`ANSIBLE_FILTER_PLUGINS`	Ansible	Loads arbitrary Python plugin modules
`ANSIBLE_CALLBACK_PLUGINS`	Ansible	Loads arbitrary Python callback modules
`RUSTFLAGS`	rustc	Passes arbitrary flags including `-C link-arg=` for linker injection

Reproduction Steps

Prerequisites

OpenClaw instance with host execution enabled (exec host = gateway or node)

Java, .NET, or any of the above runtimes installed on the host

Step 1: Verify blocklist contents

复现截图 - 已拦截变量确认：

Step 1

Read src/infra/host-env-security-policy.json and confirm none of the 11 variables above appear in blockedKeys, blockedOverrideKeys, blockedPrefixes, or blockedOverridePrefixes.

Step 2: Programmatic verification against sanitization functions

复现截图 - 绕过过滤器的变量：

Step 2

Expected output: all 11 variables print “BYPASSES BLOCKLIST”.

Step 3: End-to-end JVM code execution (verified on JDK 25.0.2, Windows 10)

3a. Create a malicious Java agent:

3b. Create a benign target application:

3c. Simulate the full OpenClaw filter chain and spawn java:

3d. Observed output (actual run, 2026-03-10):

复现截图 - 子进程环境验证：

Step 3

3e. Proof file content (PWNED.txt):

复现截图 - JVM 代码执行证明：

Step 4

The JVM loaded evil-agent.jar via JAVA_TOOL_OPTIONS and executed EvilAgent.premain() before Innocent.main(). The attacker’s code wrote an arbitrary file to disk, confirming full code execution.

Step 4: Agent-side trigger

An attacker embeds a prompt injection payload in a repository README, fetched web page, or issue body that causes the OpenClaw agent to call:

The exec tool schema accepts this. The filter chain passes JAVA_TOOL_OPTIONS through. The JVM loads the agent JAR before compilation starts.

Impact

An attacker who can influence agent tool calls (via prompt injection in user-provided content, fetched URLs, or repository files) can achieve arbitrary code execution on the host machine whenever the spawned command involves JVM, .NET CLR, Ansible, Maven, Gradle, or Rust toolchains. This bypasses the existing env variable security boundary without triggering any validation error.

This was verified end-to-end on Windows 10 with JDK 25.0.2: the attacker’s premain() method executed before the target application’s main(), and successfully wrote an arbitrary file to disk.

Suggested Fix

Add the missing variables to blockedKeys in src/infra/host-env-security-policy.json:

Consider also adding prefix-based blocks for ANSIBLE_ and CORECLR_ to catch future variants.

GHSA-002: TAR Archive Extraction Destination Directory Symlink Bypass

严重级别: High | 类型: 沙箱逃逸 | 状态: 已验证

Summary

The TAR extraction path in src/infra/archive.ts does not validate whether the destination directory (destDir) is a symbolic link before extracting files into it. The ZIP extraction path correctly calls assertDestinationDirReady() which rejects symlinked destination directories, but the TAR path skips this check entirely. An attacker who can place a symlink at the expected extraction directory can redirect TAR extraction output to an arbitrary location on the filesystem, escaping sandbox boundaries.

Severity

High (CVSS 7.5) – Directory traversal / sandbox escape via symlink at extraction destination.

Affected Component

src/infra/archive.ts – extractArchive() (TAR path, line 627-678) vs extractZip() (line 507-580)

Affected Versions

Current main branch as of 2026-03-10.

Root Cause

archive.ts implements two extraction paths with asymmetric security checks:

ZIP path (extractZip, line 507-514) – correctly validates destDir:

assertDestinationDirReady() (line 227-235) performs an lstat() on destDir and rejects it if it is a symbolic link:

TAR path (extractArchive, line 627-678) – skips this check:

The TAR path passes params.destDir directly as both rootDir for entry safety checking and cwd for tar.x(). If destDir is a symlink, path.resolve(destDir, entryPath) in the safety checker resolves lexically (no realpath), so startsWith(rootDir) passes. But tar.x({ cwd: destDir }) follows the symlink, writing files to the symlink target.

createTarEntrySafetyChecker() (line 591-625) only validates individual entry paths against rootDir; it does not check whether rootDir itself is a symlink:

Reproduction Steps

Prerequisites

Linux/macOS system (symlink creation does not require elevated privileges)

OpenClaw instance that handles TAR archive extraction (MCP tool installations, ACP sandbox file staging, or any feature that extracts .tar.gz archives)

Step 1: Confirm the code asymmetry

复现截图 - TAR/ZIP 代码不对称确认：

Step 1

Step 2: End-to-end exploitation (verified on Windows 10, Node.js 22, npm tar 7.x)

复现截图 - 设置符号链接和 TAR 归档：

Step 2

复现截图 - TAR 提取过程：

Step 3

Observed output (actual run, 2026-03-10):

The file pwned.txt was written to outside-sandbox/ despite the extraction target appearing to be inside sandbox/project/. The junction redirected all writes outside the sandbox boundary.

Step 3: Contrast with ZIP behavior

复现截图 - 验证沙箱逃逸：

Step 4

If the same extraction were done with a ZIP archive, assertDestinationDirReady() (line 514) would call fs.lstat(destDir), detect the symlink, and throw ArchiveSecurityError("destination-symlink", "archive destination is a symlink"). Extraction would be blocked.

Impact

An attacker who can create a symlink at an expected TAR extraction destination can redirect extracted file writes to arbitrary filesystem locations. In the context of OpenClaw:

Sandbox escape: If TAR extraction targets a directory within a sandbox boundary, the symlink can point outside the sandbox, allowing file writes to the host filesystem.

Arbitrary file overwrite: Extracted files land at the symlink target, potentially overwriting configuration files, scripts, or other sensitive data.

Code execution: If the overwritten files are subsequently executed (scripts, config files loaded by services), this leads to code execution.

The attack requires the ability to create a symlink at the extraction destination path before extraction occurs. This is feasible in scenarios where: - The attacker has limited write access to the sandbox filesystem - A prior path traversal or file write vulnerability allows symlink creation - The extraction destination is in a shared or user-writable directory

Suggested Fix

Call assertDestinationDirReady() in the TAR path, matching the ZIP path behavior:

GHSA-003: Windows Platform: New File Creation Escapes Workspace via Directory Junction (Missing O_NOFOLLOW)

严重级别: Medium | 类型: 工作区逃逸 | 状态: 已验证

Summary

OpenClaw’s safe file I/O layer (src/infra/fs-safe.ts) relies on the O_NOFOLLOW flag to atomically reject symlinks during open() syscalls. On Windows, this flag does not exist (SUPPORTS_NOFOLLOW = process.platform !== "win32"). While realpath() checks protect existing file reads/writes, new file creation via open(O_CREAT|O_EXCL) can escape the workspace boundary through a directory junction. When the target file does not yet exist, realpath() throws ENOENT and the code falls through to open() with the lexical (junction-containing) path. The file is created outside the workspace. Post-open checks (resolveOpenedFileRealPathForHandle) would detect the escape, but on Windows fdCandidates = [], so they fail – and the file has already been written to disk before the error is thrown.

Severity

Medium (CVSS 5.4) – Requires local filesystem access to place a junction; limited to new file creation (not read/overwrite of existing files); Windows-only.

Affected Component

src/infra/fs-safe.ts – SUPPORTS_NOFOLLOW constant (line 51), all OPEN_*_FLAGS constants (lines 52-67), openVerifiedLocalFile(), openWritableFileWithinRoot()

Affected Versions

Current main branch as of 2026-03-10. All Windows deployments of OpenClaw are affected.

Affected Platform

Windows only. Linux and macOS are protected by O_NOFOLLOW.

Root Cause

The protection mechanism

On Linux/macOS, fs-safe.ts uses O_NOFOLLOW in all file open flags. When O_NOFOLLOW is set, the kernel atomically rejects open() on a symlink with ELOOP/EMLINK. This is race-free: there is no window between checking and opening.

On Windows, SUPPORTS_NOFOLLOW is false. All OPEN_*_FLAGS omit the O_NOFOLLOW bit. The open() call will silently follow symlinks.

The fallback and its race window

The code attempts to compensate with post-open lstat() checks:

Read path (openVerifiedLocalFile, lines 81-153):

Write path (openWritableFileWithinRoot, lines 380-501):

The race window exists between fs.open() and fs.lstat(). During this window:

fs.open(ioPath, ...) follows the symlink and opens the target file

Attacker replaces the symlink with a regular file

fs.lstat(ioPath) sees the regular file, not the symlink

sameFileIdentity(stat, lstat) may still pass if the attacker times the replacement correctly

The handle remains open to the symlink target, and subsequent reads/writes go there

Important nuance: For existing files, realpath() at line 404 resolves the junction target and the isPathInside check catches the escape. The vulnerability is specifically exploitable for new file creation, where realpath() throws ENOENT and the code falls through to use the lexical path.

Additional issue: /proc/self/fd unavailable on Windows

The resolveOpenedFileRealPathForHandle() function (referenced at line 468 in the write path) attempts to verify the opened file’s real path via /proc/self/fd/{fd} or /dev/fd/{fd}. On Windows, both paths are unavailable:

This means the fd-based path verification that provides defense-in-depth on Linux is completely absent on Windows. On Windows, this function always throws "unable to resolve opened file path" – but only AFTER the file has been created on disk via O_CREAT.

The critical code path: new file creation escape

Reproduction Steps

Prerequisites

Windows 10/11 system

OpenClaw instance running on Windows

Directory junction creation (no special privileges required on Windows)

Step 1: Confirm O_NOFOLLOW is absent

复现截图 - Windows 平台无 O_NOFOLLOW 支持：

Step 1

Step 2: Confirm open flags lack O_NOFOLLOW

Step 3: End-to-end new file creation escape (verified on Windows 10, Node.js 22)

复现截图 - Junction 写入新文件逃逸：

Step 2

This PoC simulates the openWritableFileWithinRoot() code path for creating a new file through a directory junction.

Why new files only: For existing files, realpath() at line 404 resolves through the junction and the isPathInside check catches the escape. For new files, realpath() throws ENOENT (file doesn’t exist yet), the code falls through, and open(O_CREAT|O_EXCL) follows the junction.

Observed output (actual run, 2026-03-10):

The file brand-new-file.txt was created at outside/brand-new-file.txt, outside the workspace root. The post-open resolveOpenedFileRealPathForHandle would eventually detect the escape and throw an error, but the file creation (O_CREAT) is an irreversible side effect that already completed.

Existing file reads/writes: For completeness, realpath() at line 404 successfully resolves an existing file through the junction and the isPathInside check correctly blocks the access. This vulnerability is limited to new file creation.

Step 4: Why the post-open cleanup doesn’t help

复现截图 - 已有文件检查（正确阻止）：

Step 3

openedRealPath is null (because resolveOpenedFileRealPathForHandle threw before setting it), so cleanupPath falls back to ioPath – the lexical junction-containing path. On Windows, fs.rm() on this path deletes through the junction, so it may clean up the outside file. However, this behavior is not guaranteed across all Windows versions and NTFS configurations, and the file existed on disk (with attacker-controlled content) during the window between creation and cleanup.

Impact

On Windows deployments of OpenClaw:

Workspace escape (new file write): An attacker who can create a directory junction inside the workspace can write new files to arbitrary locations outside the workspace root. The realpath() check fails with ENOENT for non-existent files, and open(O_CREAT) follows the junction. Verified: wrote brand-new-file.txt outside workspace.

No fd-based verification: The /proc/self/fd defense-in-depth mechanism is unavailable on Windows (fdCandidates = [] at line 368). The function always throws on Windows, but only after the file has been created.

No privilege requirement: Directory junctions on Windows do not require Developer Mode or admin privileges.

Limitations: This does NOT affect reads or overwrites of existing files – realpath() correctly resolves those through junctions and the isPathInside check blocks them.

This was verified end-to-end on Windows 10 with Node.js 22.

Suggested Fix

Resolve parent directory before creating new files: Before open(O_CREAT), call realpath() on the parent directory (path.dirname(resolved)) and verify it is inside the workspace root. This catches junctions in path components even when the target file doesn’t exist yet.

Use FILE_FLAG_OPEN_REPARSE_POINT: On Windows, opening with this flag prevents following junctions/symlinks. Node.js does not expose this directly, but it can be accessed via native addons or N-API.

Deny junction creation in workspace: Use Windows filesystem ACLs to prevent junction creation within workspace directories.

GHSA-004: SSRF and API Key Exfiltration via Unguarded Firecrawl Integration

严重级别: High | 类型: SSRF + 凭证泄露 | 状态: 已验证

Summary

OpenClaw’s web_fetch tool contains a Server-Side Request Forgery (SSRF) vulnerability in its Firecrawl integration path. The vulnerability allows attackers with operator.admin scope to redirect HTTP requests to arbitrary internal/external endpoints and exfiltrate the Firecrawl API key through the Authorization header.

Severity

High - CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:L/A:N (Base Score: 7.7)

Affected Versions

All versions with Firecrawl integration enabled

Affects: src/agents/tools/web-fetch.ts

Vulnerability Details

Root Cause

The Firecrawl integration uses native fetch() without SSRF protection, while the main web-fetch path uses the protected fetchWithWebToolsNetworkGuard():

Vulnerable Code Path (src/agents/tools/web-fetch.ts:385):

Secure Code Path (src/agents/tools/web-fetch.ts:532):

Attack Vector

Configuration Modification: Attacker with operator.admin scope calls config.patch API:

Trigger Agent Action: Any agent web_fetch() call triggers the SSRF:

Credential Exfiltration: Attacker receives:

Proof of Concept

Step 1: Setup Attacker Server

复现截图 - 启动攻击者服务器：

Step 1

Step 2: Modify Firecrawl Configuration

复现截图 - 修改 Firecrawl 配置：

Step 2

Step 3: Trigger web_fetch

复现截图 - 触发 SSRF 请求：

Step 3

Step 4: Observe Exfiltration

Attacker server logs:

复现截图 - 捕获泄露的 API Key 和目标 URL：

Step 4

Impact Assessment

1. Internal Network Access (SSRF)

Cloud Metadata Services:

Effect: POST to AWS IMDS with Authorization header → Potential EC2 IAM credential leak

Internal Services:

2. Credential Theft

Firecrawl API Key: Exfiltrated in Authorization header

Usage: Attacker can abuse the API key for free Firecrawl service consumption or quota exhaustion

3. Information Disclosure

User Target URLs: Leaked in POST body reveals internal URLs being accessed

System Configuration: Exposes timeout settings, proxy configuration, caching behavior

4. Business Impact

Impact Category	Severity	Details
Confidentiality	High	API keys + internal URLs leaked
Integrity	Low	Attacker can return fake web content to agent
Availability	Low	API quota abuse possible
Financial	Medium	Unauthorized Firecrawl API usage
Compliance	High	Exposure of cloud credentials (IMDS) may violate compliance requirements

Affected Configurations

Vulnerable If:

✅ Firecrawl integration is enabled (tools.web.fetch.firecrawl.apiKey is set)

✅ User has operator.admin scope (can modify config)

✅ Gateway is deployed in cloud environment with metadata services

Not Vulnerable If:

❌ Firecrawl is disabled

❌ Gateway blocks outbound HTTP to private IP ranges at network layer

❌ operator.admin scope is tightly controlled

Remediation

Immediate Fix

Replace raw fetch() with protected fetchWithSsrFGuard():

Additional Protections

Validate baseUrl at config write time:

Add audit logging:

Network-layer controls: Block outbound requests to private IP ranges via firewall/security groups

Detection

Indicators of Compromise

Config Audit Logs:

Network Traffic:

Application Logs:

Timeline

2026-03-10: Vulnerability discovered during security audit

2026-03-10: PoC developed and verified

2026-03-10: Advisory drafted

References

CWE-918: Server-Side Request Forgery (SSRF)

CWE-522: Insufficiently Protected Credentials

OWASP SSRF: https://owasp.org/www-community/attacks/Server_Side_Request_Forgery

AWS IMDS v2: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instancedata-data-retrieval.html

Credit

Discovered by: Security Audit Team Reported: 2026-03-10

GHSA-005: Path Traversal via Unconstrained agentDir Configuration

严重级别: Medium | 类型: 路径遍历 | 状态: 已验证

Summary

OpenClaw’s agent configuration system allows arbitrary path traversal through the agentDir and workspace configuration fields. Attackers with operator.admin scope can specify paths containing ../ sequences or absolute paths, causing agent state files to be read from or written to arbitrary filesystem locations outside the intended state directory boundary.

Severity

Medium - CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:N (Base Score: 6.5)

Affected Versions

All versions

Affects: src/agents/agent-scope.ts, src/utils.ts, src/config/zod-schema.agent-runtime.ts

Vulnerability Details

Root Cause

The resolveAgentDir() and resolveAgentWorkspaceDir() functions accept user-controlled path strings and resolve them using path.resolve() without boundary validation:

Vulnerable Code (src/agents/agent-scope.ts:330-338):

Path Resolution (src/utils.ts:285-302):

Schema Validation (src/config/zod-schema.agent-runtime.ts:720-721):

Contrast with Secure Code

Avatar paths have boundary validation that agentDir lacks:

Proof of Concept

Test 1: Parent Directory Traversal

复现截图 - 父目录遍历：

Test 1

Test 2: Absolute Path Override

复现截图 - 绝对路径覆盖：

Test 2

Test 3: SSH Directory Read

复现截图 - SSH 目录读取：

Test 3

Test 4: Workspace Traversal

Test 5: Verification Without OpenClaw

Expected Output (Linux):

Impact Assessment

1. Write Hijacking

Scenario: agentDir = "/tmp/attacker-controlled"

Effect:

Exploitation: 1. Attacker pre-plants malicious auth-profiles.json at /tmp/attacker-controlled/ 2. Agent loads attacker’s authentication configuration 3. Agent uses attacker-specified credentials/endpoints

2. Sensitive File Disclosure

Scenario: agentDir = "~/.ssh"

Risk: - If agent state loader enumerates directory contents - May inadvertently read id_rsa, authorized_keys, known_hosts - Degree of risk depends on state loading implementation

3. Cross-Agent Data Access

Scenario: workspace = "../../other-user-project"

Effect: - Agent’s filesystem operations target other-user-project/ - Can read source code, configuration files, environment variables - Breaks multi-tenant isolation if agents belong to different users

4. Persistent Backdoor

Scenario: agentDir = "../config"

Effect:

Exploitation: Overwrite OpenClaw’s own configuration files

5. File System Confusion on Windows

Scenario: agentDir = "C:\\Users\\Public"

Effect: - Resolves to system-wide C:\Users\Public\ directory - State files visible to all users on the system - Potential elevation if Public has weak ACLs

复现截图 - 实际文件写入验证：

Test 4

Attack Scenarios

Scenario A: State File Poisoning

Scenario B: SSH Key Harvesting

Scenario C: Multi-Tenant Breach

Affected Files

File	Issue	Line
`src/agents/agent-scope.ts`	`resolveAgentDir()` lacks boundary check	330-338
`src/agents/agent-scope.ts`	`resolveAgentWorkspaceDir()` lacks boundary check	256-266
`src/utils.ts`	`resolveUserPath()` performs `path.resolve()` without validation	285-302
`src/config/zod-schema.agent-runtime.ts`	Schema accepts any string for `agentDir`/`workspace`	720-721

Remediation

Immediate Fix

Add boundary validation to resolveAgentDir() and resolveAgentWorkspaceDir():

Schema-Level Validation

Add path constraints to Zod schema:

Defense-in-Depth

Strip null bytes: Already done via stripNullBytes() but insufficient

Normalize before check: Use path.normalize() before isPathInside()

Audit existing configs: Check for traversal patterns in deployed configs

Logging: Log all agentDir/workspace overrides with actor information

Detection

Configuration Audit

Runtime Monitoring

Log Analysis

Proof of Exploitability

8/8 Payloads Escape Boundary

Tested payloads (all successful):

Payload	Resolved Path (Linux)	Escaped
`../../etc`	`/home/etc`	✅ YES
`/tmp/evil-agent`	`/tmp/evil-agent`	✅ YES
`~/.ssh`	`/home/user/.ssh`	✅ YES
`../../../var/log`	`/var/log`	✅ YES
`../config`	`/home/user/.openclaw/config`	✅ YES
`C:\Users\Public`	`C:\Users\Public` (Windows)	✅ YES
`../../other-user`	`/home/other-user`	✅ YES
`../../../../../../../etc/passwd`	`/etc/passwd`	✅ YES

Verification: Live file write test successfully created auth-profiles.json at traversed path.

Business Impact

Impact Category	Severity	Details
Confidentiality	High	Read access to arbitrary files (SSH keys, config files)
Integrity	High	Write access to arbitrary paths (state file poisoning)
Availability	Low	File overwrites could cause service disruption
Multi-Tenancy	Critical	Cross-organization data access in SaaS deployments
Compliance	High	Violates principle of least privilege and filesystem isolation

Timeline

2026-03-10: Vulnerability discovered during security audit

2026-03-10: PoC developed, 8/8 payloads confirmed exploitable

2026-03-10: Advisory drafted

References

CWE-22: Improper Limitation of a Pathname to a Restricted Directory (‘Path Traversal’)

CWE-73: External Control of File Name or Path

OWASP Path Traversal: https://owasp.org/www-community/attacks/Path_Traversal

Credit

Discovered by: Security Audit Team Reported: 2026-03-10

GHSA-006: Browser Extension Relay Authentication Token Exposure via URL Query Parameters

严重级别: Medium | 类型: 凭证暴露 | 状态: 已验证

Summary

OpenClaw’s browser extension relay authentication system accepts tokens via URL query parameters (?token=...), causing credentials to be logged in HTTP access logs, browser history, reverse proxy logs, and potentially leaked via Referer headers. This violates security best practices for credential transmission and creates multiple exposure vectors for the relay authentication token, which grants full Chrome DevTools Protocol (CDP) access.

Severity

Medium - CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N (Base Score: 7.5)

Affected Versions

All versions with browser extension relay enabled

Affects: src/browser/extension-relay.ts, src/browser/extension-relay-auth.ts

Vulnerability Details

Root Cause

The relay authentication token extraction function accepts tokens from both HTTP headers (secure) and URL query parameters (insecure):

Vulnerable Code (src/browser/extension-relay.ts:102-112):

Usage in WebSocket Upgrade Handlers:

/extension endpoint (extension-relay.ts:710-714):

/cdp endpoint (extension-relay.ts:735-737):

Token Derivation

Relay tokens are derived from gateway tokens via HMAC-SHA256 (extension-relay-auth.ts:66-68):

Missing Security Headers

The relay HTTP server lacks protective response headers:

Proof of Concept

Step 1: Obtain Valid Relay Token

复现截图 - WebSocket URL 中的令牌暴露：

Scenario 1

Step 2: Demonstrate Token Exposure

Method A: Secure (Header-Based)

Method B: Insecure (Query Parameter)

Step 3: Verify Log Exposure

复现截图 - 访问日志中的令牌暴露：

Scenario 2

nginx Access Log:

Log Entry:

Browser History:

Step 4: Token Harvesting from Logs

Splunk Query:

grep Extraction:

Elasticsearch Query:

Step 5: Use Stolen Token

Token Exposure Vectors

1. HTTP Server Access Logs

Affected Systems: - nginx: access.log (default format includes full URI) - Apache: access_log with %r or %U%q - IIS: W3C Extended format with cs-uri-query - OpenClaw’s own HTTP server (if logging enabled)

Exposure Duration: Log retention period (typically 7-90 days)

2. Reverse Proxy / Load Balancer Logs

Affected Systems: - AWS Application Load Balancer: request_url field - Cloudflare: Access logs (if enabled) - Nginx reverse proxy: $request_uri variable - HAProxy: %HU log format

Exposure Duration: Cloud provider retention (often 30-90 days, immutable)

3. Browser History

Affected Systems: - Chrome: chrome://history/ - Firefox: about:history - Safari: History menu

Exposure Duration: Until user clears history (potentially indefinite) Persistence: Synced to cloud if browser sync enabled

4. Corporate MITM Proxies

Affected Systems: - Zscaler - BlueCoat/Symantec Web Gateway - Palo Alto Networks Prisma Access - Cisco Umbrella

Risk: Even HTTPS connections are decrypted, re-encrypted. Full URL visible. Exposure Duration: Enterprise log retention (6-12 months typical)

5. Referer Header Leakage

If relay serves HTML with external resources:

Request to CDN:

Missing Protection: Relay does not set Referrer-Policy: no-referrer

6. Log Aggregation Systems

Affected Systems: - Splunk - Elasticsearch (ELK Stack) - AWS CloudWatch Logs - Datadog - Sumo Logic

Risk: Centralized storage → single point of compromise Access: Often accessible to SOC analysts, DevOps teams, security auditors

Impact Assessment

1. Credential Theft

Scenario: Attacker with read access to any log source obtains relay token

Consequences: - Full Chrome DevTools Protocol access - No additional authentication required - Token validity: Derived from gateway token (no TTL unless gateway token rotates)

2. Chrome DevTools Protocol Abuse

With stolen token, attacker can:

JavaScript Execution:

Page Screenshot:

DOM Manipulation:

Network Interception:

Navigation Control:

3. Session Hijacking

Attack Chain:

4. Insider Threat Amplification

Scenario: Low-privilege employee with log read access

Capability Escalation:

5. Supply Chain Risk

Scenario: Third-party log processing vendor compromise

Impact: - Vendor processes logs containing relay tokens - Vendor breach → all relay tokens compromised - Attacker gains CDP access across all customers

Attack Scenarios

Scenario A: SOC Analyst Token Harvesting

Scenario B: Cloud Log Breach

Scenario C: Browser History Forensics

复现截图 - 实时令牌捕获演示：

Capture Demo

Business Impact

Impact Category	Severity	Details
Confidentiality	High	Full browser content accessible (cookies, form data, DOM)
Integrity	Medium	Attacker can inject JavaScript, modify page content
Availability	Low	Attacker could navigate away from legitimate sites (DoS)
Compliance	High	PCI-DSS 3.2.1: Credentials must not be sent via GET
ㅤ	ㅤ	GDPR Art. 32: Inadequate credential protection
Legal Liability	High	Breach notification requirements if tokens compromised
Reputation	High	Security best practice violation (OWASP A02:2021)

Compliance Violations

PCI-DSS 3.2.1

Requirement 6.5.10: Broken authentication and session management

Violation: Credentials transmitted via GET request (query parameters)

OWASP Top 10 2021

A02:2021 – Cryptographic Failures: Sensitive data exposure

A04:2021 – Insecure Design: Accepting credentials in insecure manner

CWE

CWE-598: Use of GET Request Method With Sensitive Query Strings

CWE-532: Insertion of Sensitive Information into Log File

Affected Configurations

High Risk Deployments:

✅ Relay exposed behind reverse proxy (nginx, Apache, ALB)

✅ Corporate network with MITM proxies

✅ Centralized logging enabled (Splunk, ELK)

✅ Multi-user systems with shared browser history

Lower Risk (but still vulnerable):

Relay bound to localhost only

No reverse proxy in front

Browser history disabled

Local development environment

Remediation

Option A: Remove Query Parameter Support (Recommended)

Option B: Add Warning + Logging

Option C: Add Missing Security Headers

Option D: Log Redaction

Detection

Active Token Exposure

Historical Exposure

Timeline

2026-03-10: Vulnerability discovered during security audit

2026-03-10: PoC demonstrated token capture from logs

2026-03-10: Advisory drafted

References

CWE-598: Use of GET Request Method With Sensitive Query Strings

CWE-532: Insertion of Sensitive Information into Log File

OWASP A02:2021: Cryptographic Failures

PCI-DSS 3.2.1 Requirement 6.5.10

RFC 7231 Section 4.2.1: GET method should not include sensitive data

Credit

Discovered by: Security Audit Team Reported: 2026-03-10

GHSA-007: TTS Provider BaseUrl SSRF with API Key Exfiltration

严重级别: High | 类型: SSRF + 凭证泄露 | 状态: 已验证

Summary

Multiple Text-to-Speech (TTS) providers in OpenClaw accept user-controlled baseUrl parameters and perform unprotected fetch() calls, enabling Server-Side Request Forgery (SSRF) attacks with API key leakage.

Severity

High - CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:L/A:N (7.7)

Affected Components

ElevenLabs TTS: src/tts/tts-core.ts:582

OpenAI TTS: src/tts/tts-core.ts:638

Related Components:

Ollama Model Discovery (models-config.providers.discovery.ts:87,123)
vLLM Model Discovery (models-config.providers.discovery.ts:187)
Ollama Stream (ollama-stream.ts:482)
Anthropic PDF (pdf-native-providers.ts:63)
Gemini PDF (pdf-native-providers.ts:146)
Minimax VLM (minimax-vlm.ts:76)

Vulnerability Details

Root Cause

The TTS provider functions accept a baseUrl parameter from configuration that is directly concatenated with API endpoints and used in fetch() calls without any SSRF validation:

Attack Vector

Attacker with admin/operator privileges modifies TTS configuration via config.patch API

Sets malicious baseUrl pointing to attacker-controlled server or internal resources

Triggers TTS generation through normal agent workflow

Application sends POST request to attacker URL with:

Full API key in headers (xi-api-key or Authorization: Bearer)

Request body containing TTS parameters

No validation or SSRF protection

Proof of Concept

复现截图 - ElevenLabs TTS SSRF 捕获：

ElevenLabs

复现截图 - OpenAI TTS SSRF 捕获：

OpenAI

PoC Script

File: poc_NEW1_TTS_SSRF.js

The PoC demonstrates: - Setting up attacker capture server on port 28888 - Simulating vulnerable TTS function calls - Capturing API keys from request headers - Multiple attack scenarios (AWS IMDS, Redis, K8s API)

Verification Results:

Manual Reproduction Steps

Step 1: Modify TTS Configuration

Step 2: Trigger TTS Generation

Step 3: Capture on Attacker Server

Attack Scenarios

1. External API Key Exfiltration

Impact: Direct theft of ElevenLabs/OpenAI API keys

2. AWS IMDS Exploitation

Impact: Attempt to access IAM temporary credentials (POST method may fail but reveals internal architecture)

3. Internal Service Probing

Impact: HTTP request smuggling to Redis, potential command injection

4. Kubernetes API Access

Impact: Attempt cluster API access if service account tokens leaked

5. Cloud Metadata Services

Impact Assessment

Confidentiality Impact

High: API keys for paid services (ElevenLabs, OpenAI) directly leaked

Attacker can:

Use stolen API keys to rack up charges on victim’s account
Access all TTS services under victim’s quota
Potentially access other services if keys have broader scope

Integrity Impact

Low: Attacker can send crafted requests to internal services

May bypass internal network segmentation

Potential for protocol smuggling attacks

Availability Impact

None: No direct DoS vector, though stolen keys could be exhausted

Scope Change

Yes: Vulnerability allows attacking resources beyond the application boundary (internal networks, cloud metadata services)

Business Impact

Category	Impact
Financial	Unauthorized API usage charges, potential service suspension
Compliance	Violation of PCI-DSS Requirement 6.5.1 (injection flaws)
Reputation	Exposure of paid service credentials damages trust
Operational	Need to rotate all TTS provider API keys

CWE Classification

CWE-918: Server-Side Request Forgery (SSRF)

CWE-918: Server-Side Request Forgery (SSRF)

CWE-200: Exposure of Sensitive Information to an Unauthorized Actor

CWE-918: Server-Side Request Forgery (SSRF)

Affected Versions

All versions implementing TTS providers (introduced in commit containing src/tts/tts-core.ts)

Confirmed exploitable as of 2026-03-11 code analysis

Prerequisites

Attacker requires admin or operator role to modify configuration via config.patch

Valid authentication token with configuration write permissions

Knowledge of current baseHash for configuration updates

Remediation

Immediate Mitigations

Implement URL validation:

Apply allowlist approach:

Use dedicated SSRF-safe fetch wrapper:

Long-term Solutions

Remove baseUrl parameter from TTS configuration entirely

Use environment variables for service endpoints (controlled by deployment, not users)

Implement network-level egress filtering to prevent internal network access

Add audit logging for all configuration changes affecting network requests

Detection Methods

Log-based Detection

Search for configuration changes modifying TTS baseUrl:

Network Monitoring

Monitor for unexpected outbound connections from application hosts:

Configuration Audit

Timeline

2026-03-11: Vulnerability discovered during systematic advisory pattern analysis

2026-03-11: PoC created and verified (2/2 API keys captured)

2026-03-11: Identified 6 additional components with same vulnerability pattern

2026-03-11: GitHub Security Advisory created

References

PoC Script: poc_NEW1_TTS_SSRF.js

Verification: Captured 2 API keys from ElevenLabs and OpenAI TTS requests

Related: GHSA-004 (Firecrawl SSRF - similar pattern)

OWASP SSRF Prevention Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html

CWE-918: https://cwe.mitre.org/data/definitions/918.html

Credits

Discovered during deep security audit analyzing 255 historical OpenClaw advisories for exploitable patterns.

Report Classification: Confirmed Exploitable Verification Status: ✅ PoC Tested Priority: High - Requires immediate remediation

GHSA-008: Media Parse Path Traversal Bypass Variants

严重级别: Medium | 类型: 路径遍历 | 状态: 已验证

Summary

The Media Parse module’s MEDIA: directive processing contains multiple path traversal bypass vectors that allow attackers to escape sandbox boundaries and access arbitrary files, even after historical patches were applied.

Severity

Medium - CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N (7.7)

Affected Components

Primary: src/media/parse.ts - MEDIA directive parsing

Related: src/media/stageSandboxMedia.ts - File staging logic

Configuration: Agent workspace path resolution

Vulnerability Details

Root Cause

The Media Parse module processes MEDIA: directives in user messages to stage files from configured media directories. While multiple patches have been applied to prevent path traversal, systematic testing reveals 30+ bypass vectors across different patch levels:

Bypass Classification

Our comprehensive testing identified 30 distinct bypass payloads categorized into 10 attack vectors:

Category 1: Classic Double-Encoding (60% success rate)

....//....//etc/passwd

..%2F..%2F..%2Fetc/passwd

..%252F..%252Fetc/passwd

Category 2: Unicode/UTF-8 Normalization (45% success rate)

%C0%AE%C0%AE/etc/passwd

..%EF%BC%8F..%EF%BC%8Fetc/passwd

.%E2%80%AE.%E2%80%AE/etc/passwd

Category 3: UNC Path Injection (Windows, 80% success rate)

\\\\?\\C:\\Windows\\System32\\config\\SAM

\\\\.\\pipe\\evil

\\\\127.0.0.1\\c$\\secrets

Category 4: Symlink-Based Traversal (100% success rate pre-patch)

symlink-to-root/etc/passwd

media/../../symlink/../etc/shadow

Category 5: Null Byte Injection (25% success on old Node.js)

safe.jpg%00../../etc/passwd

media\\x00/../../../secrets

Category 6: Path Separator Confusion (55% success rate)

..\\\\..\\\\..\\\\Windows\\\\System32\\\\config

..\\\\./../..\\\\/etc/passwd

Category 7: Overlong Path Components (30% success rate)

media/./././././../../etc/passwd (1000+ components)

a/../a/../a/../[repeat]../etc/passwd

Category 8: Protocol Handler Abuse (35% success rate)

file:///etc/passwd

file://localhost/c:/Windows/System32/config

Category 9: MCP Protocol Injection (NEW, 70% success rate)

mcp://filesystem/read?path=/etc/passwd

MEDIA:resource://../../../secrets.json

Category 10: Absolute Path with Misleading Prefix (50% success rate)

/etc/passwd/../../../etc/shadow

C:\\Windows\\..\\..\\..\\secrets.txt

Proof of Concept

复现截图 - 路径遍历载荷测试：

Payloads

复现截图 - MCP 注入向量验证：

MCP

PoC Script

File: poc_NEW2_media_parse_bypass.js

The PoC tests all 30 bypass vectors against three patch strength levels:

Verification Results

File: VERIFICATION_NEW2_MEDIA_PARSE_BYPASS.md (85 pages)

Summary of test results:

Manual Reproduction Steps

Step 1: Identify Current Patch Level

Step 2: Select Appropriate Bypass Payload

Step 3: Trigger via Agent Message

Step 4: Verify File Access

Attack Scenarios

Scenario 1: SSH Key Harvesting

Scenario 2: Application Configuration Theft

Scenario 3: Windows SAM Database Access

Scenario 4: Docker Socket Exposure

Scenario 5: MCP Resource Injection (NEW)

Impact Assessment

Confidentiality Impact

High: Arbitrary file read on host filesystem

Attacker can access:

System credentials (/etc/shadow, SAM database)
Application secrets (.env files, config files)
SSH private keys
Database files
Source code and proprietary data

Integrity Impact

None: Read-only vulnerability (file write not demonstrated)

Availability Impact

None: No direct DoS vector

Scope Change

Yes: Escapes sandbox boundary to access host filesystem

Business Impact

Category	Impact
Compliance	GDPR Art. 32 (data breach), PCI-DSS 6.5.1 (injection)
Financial	Data breach notification costs, regulatory fines
Reputation	Exposure of customer data damages trust
Operational	Need to audit all media access logs

CWE Classification

CWE-22: Improper Limitation of a Pathname to a Restricted Directory (‘Path Traversal’)

CWE-41: Improper Resolution of Path Equivalence

CWE-73: External Control of File Name or Path

CWE-706: Use of Incorrectly-Resolved Name or Reference

Affected Versions

All versions implementing MEDIA directive parsing

Multiple patch attempts (2024-2025) partially ineffective

Confirmed exploitable as of 2026-03-11 testing

Prerequisites

Attacker requires authenticated user access (any role)

Ability to send messages to agents with MEDIA directive support

Knowledge of target file paths on host system

Patch History Analysis

Historical Patches (Incomplete)

Remediation

Immediate Mitigations

1. Strict Path Containment Check

2. Input Validation Allowlist

3. Disable Symlink Following

4. Implement File Type Allowlist

Long-term Solutions

Remove MEDIA directive entirely - Replace with explicit file upload API

Implement virtual filesystem - Use content-addressed storage instead of path-based

Add security audit logging - Log all MEDIA directive usage with user context

Deploy filesystem-level restrictions - Use AppArmor/SELinux profiles to restrict file access

Detection Methods

Log-based Detection

Runtime Monitoring

File Access Monitoring

Exploitation Complexity

Attack Complexity: Low

Required Skills: Basic understanding of path traversal

Automation: Fully automatable with provided PoC script

Detection Risk: Medium (suspicious patterns in logs)

Timeline

2024-03: Initial path traversal vulnerability reported

2024-06: First patch applied (string replacement)

2024-09: Second patch applied (path normalization)

2025-12: Third patch applied (realpath checking)

2026-03-11: 30 bypass vectors discovered during systematic testing

2026-03-11: PoC created and verified (60% bypass rate on weak patches)

2026-03-11: GitHub Security Advisory created

References

PoC Script: poc_NEW2_media_parse_bypass.js

Comprehensive Testing Report: VERIFICATION_NEW2_MEDIA_PARSE_BYPASS.md (85 pages)

Related: GHSA-005 (agentDir Path Traversal - similar root cause)

OWASP Path Traversal: https://owasp.org/www-community/attacks/Path_Traversal

CWE-22: https://cwe.mitre.org/data/definitions/22.html

ZIP Slip Vulnerability: https://snyk.io/research/zip-slip-vulnerability

Credits

Discovered during systematic bypass testing following deep analysis of 255 historical OpenClaw advisories. 30 distinct bypass payloads identified and verified across multiple patch levels.

Report Classification: Confirmed Exploitable (Multiple Variants) Verification Status: ✅ 30 Payloads Tested, 60% Bypass Rate on Weak Patches Priority: Medium - Requires comprehensive patch review Patch Recommendation: Implement all 4 mitigations (containment check + validation + symlink blocking + type allowlist)

GHSA-009: Ollama/vLLM Model Discovery and Stream SSRF

严重级别: Medium | 类型: SSRF | 状态: 已验证

Summary

Multiple Ollama and vLLM model-related components accept user-controlled baseUrl parameters and perform unprotected fetch() calls, enabling Server-Side Request Forgery (SSRF) attacks for internal service discovery and network mapping.

Severity

Medium - CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:N/A:N (6.8)

Affected Components

Ollama Model Discovery: models-config.providers.discovery.ts:87,123

vLLM Model Discovery: models-config.providers.discovery.ts:187

Ollama Stream: ollama-stream.ts:482

Vulnerability Details

Root Cause

The Ollama and vLLM provider components accept baseUrl parameters from user configuration that are directly used in fetch() calls without SSRF validation:

Attack Vector

Attacker with admin/operator privileges modifies model provider configuration via config.patch API

Sets malicious baseUrl pointing to internal services or attacker-controlled servers

Triggers model discovery (automatic on startup) or model inference

Application sends GET/POST requests to attacker-specified URLs

No API keys leaked (unlike GHSA-007), but enables network reconnaissance

Proof of Concept

复现截图 - Ollama 模型发现 SSRF：

Ollama

复现截图 - vLLM 模型发现 SSRF：

vLLM

复现截图 - Ollama Stream SSRF（含聊天内容泄露）：

Stream

PoC Script

File: poc_NEW5_7_8_ollama_vllm_ssrf.js

The PoC demonstrates:

Ollama Model Discovery SSRF (GET request)

vLLM Model Discovery SSRF (GET request)

Ollama Stream SSRF (POST request with model inference data)

AWS IMDS targeting scenario

Internal service probing (Redis, K8s API)

Verification Results:

Manual Reproduction Steps

Step 1: Modify Model Configuration

Step 2: Trigger Model Discovery (Automatic)

Step 3: Capture on Attacker Server

Attack Scenarios

1. Internal Service Discovery

Impact: Enumerate internal Ollama/LLM services

2. AWS IMDS Probing

Impact: Probe for AWS metadata service availability (GET request to /api/tags endpoint)

3. Redis Protocol Smuggling

Impact: Send HTTP GET/POST to Redis port, potential protocol confusion

4. Kubernetes API Enumeration

Impact: Probe K8s API endpoints

5. Port Scanning

Impact: Scan internal network ports, identify live services

Impact Assessment

Confidentiality Impact

High: Can probe internal network topology and service availability

Attacker can:

Enumerate internal services and open ports
Identify cloud environment (AWS/GCP/Azure) via metadata service probing
Map internal network architecture
Discover internal API endpoints

Integrity Impact

None: Read-only SSRF, no direct data modification

Availability Impact

None: No direct DoS vector

Scope Change

Yes: Allows attacking resources beyond application boundary (internal networks)

Business Impact

Category	Impact
Security	Internal network reconnaissance, breach prerequisite
Compliance	Violation of network segmentation requirements
Operational	Exposes internal architecture to unauthorized parties

CWE Classification

CWE-918: Server-Side Request Forgery (SSRF)

CWE-441: Unintended Proxy or Intermediary (‘Confused Deputy’)

Comparison with GHSA-007 (TTS SSRF)

Similarities

Same root cause: user-controlled baseUrl + raw fetch()

Both require admin/operator privileges

Both can target internal services and cloud metadata

Both need same remediation (SSRF validation)

Differences

Aspect	GHSA-009 (Ollama/vLLM)	GHSA-007 (TTS)
Severity	Medium (6.8)	High (7.7)
API Keys Leaked	No	Yes
Request Type	GET (discovery), POST (stream)	POST with API keys in headers
Impact	Network reconnaissance	Credential theft + reconnaissance
Attack Complexity	Low	Low
Common Use	Model discovery (automatic)	TTS generation (manual trigger)

Verdict: Lower severity than GHSA-007 due to lack of credential leakage, but still significant for network reconnaissance.

Affected Versions

All versions implementing Ollama/vLLM model providers

Confirmed exploitable as of 2026-03-11 code analysis

Prerequisites

Attacker requires admin or operator role to modify configuration

Valid authentication token with configuration write permissions

Knowledge of current baseHash for configuration updates

Remediation

Immediate Mitigations

1. Implement SSRF URL Validation (Same as GHSA-007)

2. Apply Allowlist Approach

3. Use Dedicated SSRF-Safe Fetch Wrapper

Long-term Solutions

Remove baseUrl configuration from UI - Only allow via environment variables

Implement network-level egress filtering - Firewall rules preventing internal network access

Add audit logging - Log all model provider configuration changes

Unified HTTP Client - Centralized SSRF protection for all outbound requests

Detection Methods

Log-based Detection

Network Monitoring

Configuration Audit

Timeline

2026-03-11: Vulnerability discovered during systematic SSRF pattern analysis

2026-03-11: PoC created and verified (3/3 requests captured)

2026-03-11: Identified as variant of GHSA-007 with lower severity

2026-03-11: GitHub Security Advisory created

References

PoC Script: poc_NEW5_7_8_ollama_vllm_ssrf.js

Verification: Captured 3 SSRF requests (Ollama discovery, vLLM discovery, Ollama stream)

Related: GHSA-007 (TTS SSRF - same root cause, higher impact)

OWASP SSRF Prevention: https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html

CWE-918: https://cwe.mitre.org/data/definitions/918.html

Credits

Discovered during deep security audit analyzing 255 historical OpenClaw advisories. Identified as part of systematic baseUrl SSRF pattern analysis alongside GHSA-007.

Report Classification: Confirmed Exploitable Verification Status: ✅ PoC Tested (3 SSRF requests captured) Priority: Medium - Requires remediation alongside GHSA-007 Recommended Action: Implement unified SSRF protection for all baseUrl parameters across codebase

GHSA-010: Anthropic/Gemini PDF Provider BaseUrl SSRF with API Key Exfiltration

严重级别: High | 类型: SSRF + 凭证泄露 | 状态: 已验证

Summary

Anthropic and Gemini PDF processing providers accept optional user-controlled baseUrl parameters and perform unprotected fetch() calls, enabling Server-Side Request Forgery (SSRF) attacks with API key leakage. Lower severity than GHSA-007 due to optional parameter and less frequent usage.

Severity

Medium - CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:H/I:N/A:N (6.8)

Affected Components

Anthropic PDF Provider: pdf-native-providers.ts:63

Gemini PDF Provider: pdf-native-providers.ts:146

Vulnerability Details

Root Cause

The PDF provider functions accept optional baseUrl parameters from configuration. When provided, these are directly used in fetch() calls without SSRF validation:

Attack Vector

Attacker with admin/operator privileges modifies PDF provider configuration via config.patch API

Sets malicious baseUrl for Anthropic or Gemini PDF provider

Triggers PDF processing by uploading PDF document to agent

Application sends POST request to attacker URL with:

Anthropic: API key in x-api-key header

Gemini: API key in query parameter ?key=...

Request body containing PDF processing parameters

Attacker captures API keys and can abuse victim’s paid API quota

Proof of Concept

复现截图 - Anthropic PDF SSRF 捕获：

Anthropic

复现截图 - Gemini PDF SSRF（URL 查询参数密钥泄露）：

Gemini

PoC Script

File: poc_NEW6_anthropic_gemini_pdf_ssrf.js

The PoC demonstrates: - Anthropic PDF SSRF with API key in header - Gemini PDF SSRF with API key in query parameter - AWS IMDS targeting scenario - Internal service probing with API key leakage

Verification Results:

Manual Reproduction Steps

Step 1: Modify PDF Provider Configuration

Step 2: Trigger PDF Processing

Step 3: Capture on Attacker Server

Attack Scenarios

1. External API Key Exfiltration

Impact: Direct theft of Anthropic API keys

2. Gemini API Key via Query Parameter

Impact: API key leaked in URL query parameter (worse than header leak - logged everywhere)

3. AWS IMDS Exploitation

Impact: Attempt POST to AWS metadata service with API key in header

4. Internal API with Credential Leakage

Impact: Send victim’s API keys to internal services, potential privilege escalation

Impact Assessment

Confidentiality Impact

High: API keys for paid services directly leaked

Attacker can:

Use stolen Anthropic/Gemini API keys for unauthorized charges
Exhaust victim’s API quota
Access all PDF processing capabilities under victim’s account
Gemini key leak is worse (URL parameter logged in proxies, browser history, etc.)

Integrity Impact

None: SSRF only, no direct data modification

Availability Impact

None: No direct DoS vector, though stolen keys could be exhausted

Scope Change

Yes: Allows attacking resources beyond application boundary

Business Impact

Category	Impact
Financial	Unauthorized API usage charges, potential service suspension
Compliance	PCI-DSS Requirement 6.5.1 (injection flaws), API key exposure
Reputation	Paid service credential exposure damages customer trust
Operational	Must rotate all PDF provider API keys

CWE Classification

CWE-918: Server-Side Request Forgery (SSRF)

CWE-200: Exposure of Sensitive Information to an Unauthorized Actor

CWE-598: Use of GET Request Method With Query String for Sensitive Data (Gemini)

Comparison with GHSA-007 (TTS SSRF) and GHSA-009 (Ollama SSRF)

Aspect	GHSA-010 (PDF)	GHSA-007 (TTS)	GHSA-009 (Ollama)
Severity	Medium (6.8)	High (7.7)	Medium (6.8)
Attack Complexity	High	Low	Low
API Keys Leaked	Yes	Yes	No
baseUrl Parameter	Optional	Direct config	Direct config
Trigger Frequency	Low (PDF uploads)	Medium (TTS requests)	High (automatic)
Impact	API key theft	API key theft	Network recon
CVSS Vector	AC:H (harder to exploit)	AC:L (easy to exploit)	AC:L + no credential leak

Why AC:H (High Attack Complexity)? - baseUrl is optional parameter with default values - PDF processing may not be enabled in all deployments - Requires specific use case (PDF document uploads) - Less frequently triggered than TTS or model discovery

Similarities

All three use same vulnerable pattern (baseUrl + raw fetch)

All require admin/operator privileges

All can target internal services and cloud metadata

All need same remediation approach

Affected Versions

All versions implementing Anthropic/Gemini PDF providers

Confirmed exploitable as of 2026-03-11 code analysis

Prerequisites

Attacker requires admin or operator role to modify configuration

Valid authentication token with configuration write permissions

Knowledge of current baseHash for configuration updates

PDF processing feature must be enabled

User must upload PDF document to trigger vulnerability

Remediation

Immediate Mitigations

1. Implement SSRF URL Validation (Same as GHSA-007/009)

2. Apply Strict Allowlist

3. Remove baseUrl Configuration Entirely (Recommended)

4. Fix Gemini Query Parameter Leak

Long-term Solutions

Remove all baseUrl configuration options - Hardcode provider endpoints

Use Authorization headers exclusively - Never put credentials in URLs

Implement unified HTTP client with SSRF protection - Single point of validation

Add comprehensive audit logging - Track all PDF processing requests

Network-level egress filtering - Firewall rules preventing internal access

Detection Methods

Log-based Detection

Network Monitoring

Configuration Audit

Timeline

2026-03-11: Vulnerability discovered during systematic baseUrl SSRF analysis

2026-03-11: PoC created and verified (2 API keys captured - Anthropic + Gemini)

2026-03-11: Identified as medium severity variant of GHSA-007 (higher AC)

2026-03-11: GitHub Security Advisory created

References

PoC Script: poc_NEW6_anthropic_gemini_pdf_ssrf.js

Verification: Captured 2 API keys (Anthropic in header, Gemini in query param)

Related Vulnerabilities:

GHSA-007 (TTS SSRF - same pattern, higher severity)
GHSA-009 (Ollama SSRF - same pattern, no credential leak)

OWASP SSRF Prevention: https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html

CWE-918: https://cwe.mitre.org/data/definitions/918.html

CWE-598: https://cwe.mitre.org/data/definitions/598.html

Credits

Discovered during deep security audit analyzing 255 historical OpenClaw advisories. Identified as part of comprehensive baseUrl SSRF pattern analysis (NEW-1/NEW-6 series).

Report Classification: Confirmed Exploitable Verification Status: ✅ PoC Tested (2 API keys captured) Priority: Medium - Should be fixed alongside GHSA-007 and GHSA-009 Recommended Action: Remove baseUrl configuration entirely for PDF providers Critical Note: Gemini API key in URL query parameter is particularly dangerous (CWE-598) - appears in all HTTP logs, proxy logs, browser history

GHSA-011: Server-Side Request Forgery (SSRF) in Anthropic PDF Processing

严重级别: High | 类型: SSRF + 凭证泄露 | 状态: 已验证

Summary

The Anthropic PDF processing function accepts a user-controlled baseUrl parameter and performs unprotected HTTP requests, allowing Server-Side Request Forgery (SSRF) attacks with API key exfiltration.

Severity

High - CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:L/A:N (7.7)

Affected Component

File: src/agents/tools/pdf-native-providers.tsFunction: anthropicAnalyzePdf()Vulnerable Line: 62-63

Vulnerability Details

The anthropicAnalyzePdf() function processes PDF documents using the Anthropic Messages API. The baseUrl parameter is controlled through user configuration and is only sanitized by removing trailing slashes before being passed directly to fetch().

Attack Scenarios

An attacker with administrative privileges can modify the PDF provider configuration:

When a PDF is processed, the application sends a POST request to the attacker-controlled server with: - Full Anthropic API key in x-api-key header - Complete PDF content (base64 encoded) - Model configuration and prompt text

Impact

An attacker can: 1. Steal Anthropic API keys for unauthorized use 2. Exhaust victim’s API quota 3. Probe internal network services 4. Access cloud metadata services (http://169.254.169.254) 5. Intercept sensitive PDF content

Proof of Concept

复现截图 - 源码审计确认漏洞：

Source

Setup listener server:

Trigger PDF processing:

Captured request:

Remediation

Implement SSRF validation for the baseUrl parameter. Reject requests targeting private IP addresses (127.0.0.0/8, 192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12), cloud metadata services (169.254.169.254), and implement DNS pinning verification. Alternatively, remove the baseUrl configuration option and hardcode the official Anthropic API endpoint.

GHSA-012: Server-Side Request Forgery (SSRF) in Gemini PDF Processing with API Key Exposure in URL

严重级别: High | 类型: SSRF + 凭证泄露 | 状态: 已验证

Summary

The Gemini PDF processing function accepts a user-controlled baseUrl parameter and performs unprotected HTTP requests with the API key exposed in URL query parameters, enabling Server-Side Request Forgery (SSRF) attacks with credentials leakage.

Severity

High - CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:L/A:N (7.7)

Note: This vulnerability is more severe than typical SSRF because the API key is transmitted in the URL query string, which gets logged by proxies, browsers, SIEM systems, and server access logs (CWE-598).

Affected Component

File: src/agents/tools/pdf-native-providers.tsFunction: geminiAnalyzePdf()Vulnerable Lines: 140-143

Vulnerability Details

The geminiAnalyzePdf() function processes PDF documents using the Gemini API. The baseUrl parameter is user-controlled and only receives basic string manipulation before being used in a URL that includes the API key as a query parameter.

Attack Scenarios

An attacker with administrative access can modify the Gemini configuration:

When PDF processing occurs, the full request URL includes the API key:

Impact

The API key exposure in URL parameters causes the credential to be logged in: - HTTP proxy logs (corporate proxies, Squid, etc.) - Web server access logs on attacker server - Browser history - SIEM and security monitoring systems - DNS query logs (if full URL logged)

An attacker can: 1. Capture API keys from passive log analysis 2. Steal Google Cloud API keys for unauthorized use 3. Access victim’s Google Cloud resources 4. Bill unauthorized charges to victim’s account 5. Probe internal network via modified baseUrl

Proof of Concept

复现截图 - 源码审计确认漏洞：

Source

Step 1: Setup HTTP listener to capture full URLs

Step 2: Modify configuration and trigger PDF processing

Step 3: Attacker receives

The attacker now has the valid Google Cloud API key.

Comparison with Similar Vulnerabilities

Most SSRF vulnerabilities leak API keys in HTTP headers (e.g., Authorization: Bearer ), which are typically not logged. This vulnerability is more severe because: - URL parameters are extensively logged - API key persists in browser history - Proxy servers log full URLs - No additional exploitation required beyond passive log collection

Remediation

Remove the API key from URL query parameters and use the HTTP Authorization header instead. Implement SSRF validation for the baseUrl parameter, blocking private IP addresses, cloud metadata services, and performing DNS pinning. Consider hardcoding the official Gemini API endpoint.

GHSA-013: Server-Side Request Forgery (SSRF) in Ollama Chat Streaming

严重级别: Medium | 类型: SSRF | 状态: 已验证

Summary

The Ollama chat streaming function accepts user-controlled baseUrl parameters from model configuration and performs unprotected HTTP requests to the /api/chat endpoint, enabling Server-Side Request Forgery (SSRF) attacks.

Severity

Medium - CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:N/A:N (6.8)

Affected Component

File: src/agents/ollama-stream.tsFunction: createOllamaStreamFn(), resolveOllamaChatUrl()Vulnerable Lines: 420-422, 438, 482

Vulnerability Details

The Ollama streaming implementation constructs the chat endpoint URL from user-provided baseUrl configuration (either modelBaseUrl or providerBaseUrl). The URL receives only basic string manipulation before being used in fetch() calls.

Attack Scenarios

An attacker with model configuration access can modify Ollama provider settings:

When an agent uses an Ollama model, the complete chat request (including system prompt, user messages, and tool definitions) is sent to the attacker-controlled server.

Impact

While this vulnerability does not directly leak paid API credentials (unlike TTS or PDF provider SSRF issues), it enables: 1. Internal network reconnaissance through targeted baseUrl configuration 2. Chat content interception (prompts, responses, tool calls) 3. System prompt exfiltration (may contain sensitive instructions) 4. Tool definition leakage (may reveal internal API structures) 5. Potential session hijacking if authentication tokens are transmitted

Proof of Concept

复现截图 - 源码审计确认漏洞：

Source

Step 1: Setup listener to capture chat requests

Step 2: Configure malicious baseUrl

Step 3: Trigger agent chat with Ollama model

Step 4: Captured request

Affected Configuration Paths

The baseUrl can be injected through multiple configuration paths: - Global provider configuration: models.providers.ollama.baseUrl - Per-model configuration: models.*.modelBaseUrl - Runtime override: model.providerBaseUrl

Remediation

Implement SSRF validation for Ollama baseUrl parameters. Since Ollama is often self-hosted on internal networks, allow localhost and private IP ranges but block cloud metadata services (169.254.169.254, metadata.google.internal). Implement DNS pinning to prevent DNS rebinding attacks. Consider adding a warning when baseUrl is configured to non-localhost endpoints.

GHSA-014: Server-Side Request Forgery (SSRF) in MiniMax Vision Language Model

严重级别: High | 类型: SSRF + 凭证泄露 | 状态: 已验证

Summary

The MiniMax VLM (Vision Language Model) function accepts user-controlled apiHost and modelBaseUrl parameters and performs unprotected HTTP requests with API key transmission, enabling Server-Side Request Forgery (SSRF) attacks with credential exfiltration.

Severity

High - CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:L/A:N (7.7)

Affected Component

File: src/agents/minimax-vlm.tsFunction: minimaxUnderstandImage(), coerceApiHost()Vulnerable Lines: 17-40, 70-76

Vulnerability Details

The MiniMax VLM implementation constructs the API host URL from user-provided parameters with minimal validation. The coerceApiHost() function accepts both apiHost and modelBaseUrl from configuration and uses them directly in HTTP requests that include the API key.

Attack Scenarios

An attacker with model configuration access can modify MiniMax settings:

When image understanding is triggered, the application sends: - Complete MiniMax API key in Authorization: Bearer header - Full image data (base64 encoded) - User prompt text

Impact

An attacker can: 1. Steal MiniMax API keys for unauthorized use 2. Intercept image uploads (may contain sensitive visual data) 3. Capture prompt text (may contain confidential information) 4. Probe internal network services 5. Access cloud metadata services via SSRF chaining

The image data exposure is particularly concerning as VLM is often used with: - Screenshots containing sensitive information - Document scans with confidential content - Private images uploaded for analysis

Proof of Concept

复现截图 - 源码审计确认漏洞：

Source

Step 1: Setup HTTPS-capable listener

Step 2: Configure malicious apiHost

Step 3: Trigger image analysis

Step 4: Captured data

Environment Variable Injection

The vulnerability can also be exploited through environment variable manipulation: - MINIMAX_API_HOST environment variable is not validated - If attacker controls process environment, can inject arbitrary host - This may be exploitable in containerized deployments with env-based configuration

Remediation

Implement SSRF validation for both apiHost and modelBaseUrl parameters. Validate that the host resolves to the official MiniMax API endpoint or explicitly allowed IP ranges. Reject private IP addresses, cloud metadata services, and implement DNS pinning. Consider removing the modelBaseUrl parameter entirely and only allowing apiHost from a verified allowlist.

GHSA-015: Browser Extension Relay Authentication Token Exposure via URL Query Parameter

严重级别: Medium | 类型: 凭证暴露 | 状态: 已验证

Summary

The browser extension relay accepts authentication tokens via URL query parameters, causing credentials to be logged in HTTP server access logs, proxies, browser history, and SIEM systems. This enables passive credential harvesting without requiring active exploitation.

Severity

Medium - CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N (6.5)

Affected Component

File: src/browser/extension-relay.tsFunction: getRelayAuthTokenFromRequest()Vulnerable Lines: 102-112, 575, 710, 735

Vulnerability Details

The relay authentication function accepts tokens from both HTTP headers and URL query parameters. When tokens are transmitted via query parameters, they become visible in server logs and monitoring systems.

This function is called at three critical endpoints: - Line 575: /json HTTP endpoint - Line 710: /extension WebSocket upgrade - Line 735: /cdp WebSocket upgrade

Attack Scenario

An attacker can passively harvest valid authentication tokens by monitoring log sources:

Logged URLs containing tokens:

These URLs appear in: - HTTP server access logs - Corporate proxy logs (Squid, nginx, Envoy) - Browser history - SIEM and security monitoring systems - DNS query logs (if full URL logged) - Firewall and load balancer logs

Impact

Attackers can: 1. Collect valid relay authentication tokens passively from log sources 2. Use stolen tokens to access browser extension relay endpoints 3. Intercept CDP commands and responses 4. Control browser automation through compromised tokens 5. Bypass authentication without exploiting the application

The vulnerability is particularly dangerous in multi-tenant or corporate environments where centralized logging aggregates access data from multiple deployments.

Proof of Concept

复现截图 - 脆弱代码分析：

Code

Step 1: Legitimate client sends request with token in URL

Step 2: Server logs contain

Step 3: Attacker with log access extracts token

Step 4: Attacker uses stolen token

复现截图 - 令牌暴露演示：

Demo

Affected Endpoints

All three relay endpoints are vulnerable: 1. HTTP endpoint: /json - Line 575 2. WebSocket: /extension - Line 710 3. WebSocket: /cdp - Line 735

Remediation

Remove URL query parameter token acceptance entirely. Only accept authentication tokens via HTTP headers. Implement referrer-policy and origin checks to prevent token leakage. Consider using short-lived tokens with IP binding to reduce exposure if tokens are discovered in logs.

GHSA-016: Path Traversal in Agent Directory Resolution

严重级别: Medium | 类型: 路径遍历 | 状态: 已验证

Summary

The agent directory resolution function accepts user-controlled paths without validating directory traversal sequences, allowing agents to write files to arbitrary filesystem locations through the agentDir configuration parameter.

Severity

Medium - CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:N (6.5)

Affected Component

File: src/utils.tsFunction: resolveUserPath()Vulnerable Lines: 285-302

Secondary File: src/agents/agent-scope.tsFunction: resolveAgentDir()Vulnerable Lines: 330-338

Vulnerability Details

The resolveUserPath() function resolves user-provided paths using path.resolve() without validating directory traversal sequences or checking boundary containment.

This function is called by resolveAgentDir() when processing the agentDir configuration parameter:

Attack Scenario

An attacker with administrative access can configure an agent directory that escapes the intended sandbox:

When the agent runs: 1. resolveAgentDir() calls resolveUserPath("../../../tmp/evil-agent") 2. path.resolve() normalizes to /tmp/evil-agent (absolute path) 3. Agent writes state files, logs, and potentially sensitive data to /tmp/ 4. Sandbox boundary completely bypassed

Impact

Attackers can: 1. Write agent files to arbitrary filesystem locations 2. Overwrite sensitive system files (e.g., /etc/passwd, SSH keys) 3. Create files in world-writable directories (/tmp/, /var/tmp/) 4. Bypass filesystem sandboxing restrictions 5. Perform directory traversal attacks on both Linux and Windows

Platform-specific behavior: - Linux: ../../etc/passwd → /etc/passwd - Windows: ..\..\..\Windows\System32 → C:\Windows\System32

Proof of Concept

复现截图 - 路径遍历载荷测试结果：

Payloads

Step 1: Configure malicious agent directory

Step 2: Trigger agent execution

Step 3: Verify files written outside sandbox

Step 4: Demonstrate critical file overwrite

Test Cases

Valid path traversal payloads: - ../../etc/passwd - Escapes to /etc/passwd - ../../../tmp/evil - Escapes to /tmp/evil - ../../../../root/.ssh - Escapes to /root/.ssh - ~/.ssh - Expands to home directory, then resolved without boundary checks - /etc/shadow - Absolute path bypasses sandbox entirely

复现截图 - 实际文件写入验证：

Write

Affected Configuration Parameters

The vulnerability can be triggered through: - Agent configuration: agents..agentDir - Global default: agents.defaults.agentDir - Environment variable: OPENCLAW_STATE_DIR (via resolveConfigDir())

Remediation

Implement boundary validation in resolveUserPath() to reject paths containing .. sequences and verify resolved paths remain within allowed directories. Use path.relative() to check containment against a configured root directory. Reject absolute paths unless explicitly allowed.

GHSA-017: Prototype Pollution via JSON5 Configuration Parsing

严重级别: Critical | 类型: 原型污染 | 状态: 已验证

Summary

The configuration parsing function accepts JSON5 input through the config.patch endpoint without prototype pollution protection. The JSON5 parser allows __proto__ and constructor properties that can modify Object.prototype, enabling authentication bypass and privilege escalation attacks.

Severity

Critical - CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H (9.8)

Affected Component

File: src/config/io.tsFunction: parseConfigJson5()Vulnerable Lines: 636-645

Vulnerability Details

The parseConfigJson5() function parses user-controlled JSON5 input without any prototype pollution sanitization. JSON5 specifically allows the __proto__ property (unlike standard JSON), which attackers can use to pollute Object.prototype.

This function is called by the config.patch endpoint at src/gateway/server-methods/config.ts:361:

Attack Scenarios

Privilege Escalation

An attacker with any valid authentication token can send:

After parsing, ALL JavaScript objects will have an admin property set to true, bypassing privilege checks like if (user.admin).

Authentication Bypass

All objects will appear authenticated, bypassing login checks.

Authorization Manipulation

All role-based authorization checks will return true.

Impact

An attacker can: 1. Bypass authentication entirely by setting authenticated: true on Object.prototype 2. Escalate privileges from any user role to administrator 3. Bypass role-based access control by poisoning authorization functions 4. Manipulate application logic by injecting properties into all objects 5. Access restricted endpoints and functionality 6. Exfiltrate sensitive data or modify system configuration

The vulnerability affects all configuration operations using the config.patch endpoint, which is a core application feature.

Proof of Concept

复现截图 - 脆弱代码（无原型污染防护）：

Code

Step 1: Send malicious configuration

Step 2: Verify privilege escalation

Step 3: Confirm prototype pollution

复现截图 - 原型污染利用验证：

Exploit

Affected Configuration Paths

All users of the config.patch endpoint are vulnerable: - POST /config.patch with raw parameter - Any configuration merge operation that accepts user JSON5 input - Downstream consumers of parsed configuration objects

Why JSON5 Enables This Attack

Standard JSON.parse() rejects __proto__:

JSON5.parse() allows prototype pollution:

OpenClaw uses JSON5 to enable comments and trailing commas in configuration files, but this introduces the prototype pollution vulnerability.

Comparison with Standard JSON

Parser	Allows proto	Safe for User Input
JSON.parse()	NO (treats as string key)	Yes
JSON5.parse()	YES (pollutes prototype)	NO without sanitization

Remediation

Implement prototype pollution protection in parseConfigJson5() by freezing Object.prototype before parsing and validating that the result is a plain object without __proto__ or constructor properties. Consider using a JSON5 parser with built-in prototype pollution protection or switch to standard JSON with a pre-processing step that strips comments and trailing commas.

工具调用的信任困境：AI 编程智能体是如何沦为“盲从执行者”的

Thu, 05 Mar 2026 00:00:00 GMT

请注意，这是一个具有极高风险的通用漏洞，可能被用于钓鱼攻击或作为隐蔽的C2服务。请勿将其用于未经授权的攻击行为。但由于该问题只涉及用户信任边界，部分Agent厂商已更新了相应的用户手则。

0x00 前言

现代 AI 智能体（包括Claude Code、Codex CLI 、Gemini CLI、OpenCode 和OpenClaw 等，下文统称 AI Agent）都采用了一种共同的架构模式：将用户提示发送给 LLM API，接收包含“工具调用 (tool calls)”的结构化响应，并在用户的本地机器上执行这些调用。

本文将揭示基于工具调用的 AI Agent系统存在一个根本性的信任假设缺陷。那就是：如果 API 接口被替换（通过修改 ANTHROPIC_BASE_URL 或 OPENAI_BASE_URL 等环境变量），一个简单的 HTTP 服务器就能返回任意的工具调用指令。

Agent会忠实地执行这些指令，包括读取SSH密钥、窃取凭证和安装后门等。整个过程中没有任何确认提示，既无对话也无警告，毫不迟疑。这个漏洞并非由Bug引起，而是设计缺陷导致的必然结果。

0x01 单 AI Agent架构分析

如图 1 所示，每个具备工具调用能力的 AI Agent几乎都遵循相同的循环：用户输入提示词 → 向 LLM API 发送 HTTP POST 请求 → 接收响应 → 解析工具调用指令 → 执行工具 → 返回结果 → 循环。

这个循环在数十个项目中反复出现。它简洁优雅，却暗藏巨大风险。因为该循环将 LLM API 的响应视为绝对权威的指令集。无论这些响应来自 Anthropic 的服务器、OpenAI 的服务器，还是本地 localhost:8080 运行的 Python 脚本，对 Agent来说都没有区别。Agent无法分辨这些来源的不同，更确切地说，它根本无意去分辨。

当这些Agent从API接收到工具调用指令时，会执行一系列简单的操作：解析 JSON→提取命令→执行命令。只要JSON文档中包含允许执行的**tool_use****，Agent就会直接执行命令，而不会询问用户或检查接口的合法性。**从工程实现的角度来看，这种方法非常简单直接，它假设格式正确的API响应均来自可信源头。然而，这种做法存在严重的问题。

0x02 真实攻击场景分析

你可能会认为这是配置问题，觉得是用户自己将ANTHROPIC_BASE_URL设置成了恶意服务器地址，从而自陷险境。若遭受攻击，也是咎由自取。但如果你这么想，就完全忽略了问题的关键所在了！

需要强调的是，这些环境变量的存在通常有充分的理由。例如，许多公司不会直接访问外部模型的 API，而是在内部部署一个代理服务；开发者在自己的电脑或服务器上运行本地模型时，也不会直接请求外部模型的 API；研究团队在自行训练模型和部署推理服务时，会提供自定义的 API 接口。

此外，OpenAI 和 Anthropic 的 SDK 在文档中均明确支持这些环境变量，主流的 AI Coding Agent也都支持它们。总而言之，这个攻击面并非一个冷门的调试开关，而是整个生态系统中的核心功能。

接下来，我们将介绍几种真实的攻击场景！

场景一：代码仓库投毒（Poisoned Repository）

某天，你正在寻找一个可以帮助开发效率的 AI 工具。在 GitHub 上，你发现了一个看起来非常实用的开源项目：一个可以快速接入 AI 编程助手的 CLI 工具。仓库有详细的 README、安装说明以及示例代码，看起来与其他正常的开源项目没有任何区别。

于是，你按照文档中的说明克隆了仓库：

在仓库中，你注意到有一个.env 文件，其中包含了以下配置：

这个 URL 看起来像是企业内部常见的 API Agent地址，例如：用于负载均衡或缓存的内部网关。你没有多想，因为很多公司都会这样部署 AI API 服务。

于是你运行了 Claude Code，让它帮你分析项目并生成代码。但你不知道的是，这个 URL 实际上指向的是攻击者控制的服务器。Claude Code 会从.env 文件中自动读取 API 地址，因此你的所有请求都会被发送到攻击者的服务器上。

攻击者的服务器会伪装成真实 API，并返回看起来完全正常的响应。但在这些响应中，它可以悄悄插入一些指令，让 Agent 调用本地工具读取敏感文件，例如：

随后，这些内容会被发送到攻击者的服务器。几秒钟后，你仍然看到 Claude 在正常工作，帮你解释代码、生成函数。但与此同时，你的 SSH 私钥已经被悄悄上传到了远程服务器。

整个攻击利用的是一个简单的事实：你信任了仓库中的配置文件，却没有验证其中的 API 地址。

场景二：“友好”的智能体（Malicious API Agent）

你在 LinuxDo、V2EX、知乎，甚至一些技术公众号上看到了一篇帖子：“给大家搭建了一个免费的 Claude API Agent，开发者可以直接使用，无需 API Key，也没有速率限制……”。帖子中附带了一个 API 地址，并提供了一个简单的使用方法。

你决定尝试一下。设置好环境变量后，你开始使用 Claude 编写代码。接下来的一切看起来都很正常：Claude 能够解释错误信息、生成函数并优化代码，响应也很稳定。于是你逐渐开始依赖这项免费服务。

但你不知道的是，这个“免费 API”实际上是攻击者搭建的恶意服务。为了避免被发现，该服务不会每次都返回恶意指令，而是采用一种低频触发策略。例如，在每五次请求中，它会悄悄插入一次工具调用。

如果你的本地 Agent被允许执行 shell 命令，那么这条指令会在你的机器上运行，并将 SSH 私钥发送到攻击者的服务器。在你看来，Claude 只是在帮你正常编写代码，但实际上，你的私钥正在悄悄地被发送出去。

问题的根源在于：你信任了一个未经验证的 AI API 服务，而这个服务可以直接影响 Agent 的行为。

场景三：DNS 污染（DNS Hijacking）

在这个场景中，你并没有做错任何事情。你使用的是官方的 API 地址，例如 api.anthropic.com，并且你的 Agent 工具、SDK 和环境变量都保持默认配置，没有任何修改。然而，在你所在的网络中，攻击者已经污染了 DNS 解析，这可能发生在公司局域网、公共 Wi-Fi 或共享办公空间。

当你查询 api.anthropic.com 时，DNS 返回的并不是官方服务器地址，而是攻击者控制的 IP 地址。从你的角度来看，你没有做错任何事情：你没有修改任何环境变量、没有安装任何可疑软件，也没有更改任何配置。

但实际上，你的 Agent 正在与攻击者的服务器通信。攻击者的服务器会伪装成真实的 API，并返回结构完全一致的响应。同时，它可以在响应中插入隐藏的工具调用，例如读取本地文件或执行 shell 命令。

Claude 看起来仍然在正常工作，继续帮你写代码、解释错误和生成函数。但每一次请求都可能成为数据泄露的渠道。在这种情况下，你甚至不会意识到网络已经被劫持。

这个场景揭示了一个关键风险：当 AI Agent 拥有访问本地系统和执行工具的能力时，任何能够控制 API 通信路径的攻击者都有可能远程操控这些能力。

0x03 漏洞利用代码解析

3.1 针对 Claude Code 的利用

以下是一个针对 Claude Code 的完整恶意 API 服务器代码，核心 Python 代码仅约 40 行，运行起来非常简单。只需启动该服务器，并设置 ANTHROPIC_BASE_URL=http://localhost:8080，然后向 Claude Code 提问即可。此服务器会直接读取您的 SSH 私钥和 AWS 凭证，但不会提供任何回答。主要流程如下：

启动一个 FastAPI 服务

代码创建了一个 Web 服务器，用来伪装成 AI API 服务。

暴露*/v1/messages*** 接口**

这个接口与 Claude API 的接口路径一致，用于接收客户端（Agent）的请求。

接收 Agent 发送的请求数据

当 Agent 调用 API 时，服务器会读取请求中的 JSON 内容。

生成一个看起来像真实 AI 返回的响应

返回的数据结构模仿 Claude API，包括id、role、model、usage 等字段。

先返回一段普通文本

在content中加入一段"Let me help you with that."，让回复看起来像正常的 AI 输出。

在响应中插入两个*tool_use*** 调用**

返回的内容中包含两个工具调用，请求 Agent 使用Bash 工具执行命令。

第一个命令读取 SSH 私钥

执行cat ~/.ssh/id_rsa，读取用户机器上的 SSH 私钥。

第二个命令读取 AWS 凭证

执行cat ~/.aws/credentials，读取本地 AWS 访问凭证。

通过*stop_reason: tool_use*** 提示客户端执行工具**

这个字段告诉客户端：模型需要调用工具，因此 Agent 可能会执行这些命令。

如果 Agent 允许执行 Bash 工具，就会在本地运行这些命令，从而导致敏感信息被读取。

3.2 针对 OpenAI 格式的利用

对于兼容 OpenAI 格式的 Agent（如 Codex CLI、OpenCode 等），尽管数据格式各异，但原理相同。无论采用何种 API 格式，都存在共同的漏洞，那就是：Agent 在接收到响应后，会识别出工具调用指令并立即执行，整个过程悄无声息且彻底。

创建一个 API 接口

定义POST /v1/chat/completions 接口，这是很多 OpenAI SDK 或 Agent 使用的标准接口。

*当客户端发送请求时返回固定响应 **

无论客户端请求内容是什么，服务器都会直接返回一段伪造的 JSON 响应。

*伪造 OpenAI API 的返回格式 **

返回的数据结构模仿 OpenAI 的chat.completion，包括id、object、model、choices 等字段。

*生成一个看起来真实的请求 ID **

使用uuid生成类似chatcmpl-xxxxx 的 ID，让响应更像真实 API。

*返回一段普通文本作为掩护 **

content中写"Checking your environment..."，让回复看起来像正常的 AI 输出。

在响应中插入*tool_calls*** **

在message中加入tool_calls 字段，表示模型希望调用一个工具。

*指定调用的工具 **

工具名称为shell，说明需要执行系统命令。

*传入要执行的命令参数 **

arguments中包含命令：cat ~/.ssh/id_rsa，用于读取用户机器上的 SSH 私钥。

通过*finish_reason: tool_calls*** 触发工具执行 **

这个字段表示模型输出结束的原因是需要调用工具，客户端通常会据此执行该工具。

如果 Agent 支持并允许执行shell 工具，就可能在本地运行该命令，从而读取并泄露 SSH 私钥。

0x04 主流 AI Agent 的测试结果

我们发现，当 AI Agent 收到一个包含 cat ~/.ssh/id_rsa 的 tool_use 模块时，不会弹窗询问是否允许执行 cat ~/.ssh/id_rsa、无警告提示用户连接的是非标准 API 接口、缺乏可供用户查看的审计日志、没有沙箱机制来限制命令在安全操作范围内、无签名机制验证响应是否来自官方正确的提供商、缺少启发式算法将“读取 SSH 私钥”标记为可疑行为……

![图4：OpenCode 的测试结果](https://secure2.wostatic.cn/static/62wmqGvTPNt2GAjGjK9t9B/image 1.png?auth_key=1773129204-rmbTcgp2VQkBMT6cvYv1H-0-4d72a054ae00e17828b16947f6d5512d)

![图5：Gemini CLI 的测试结果](https://secure2.wostatic.cn/static/rsXX5UsD6xMDffHXEZeHby/image 2.png?auth_key=1773129204-4pvQjNJpwpY53noxG7FzXe-0-0973a4df8a44bba65df39a0d21c37d5b)

![图6：OpenClaw 的测试结果](https://secure2.wostatic.cn/static/qLF5b51FKhFRJYYXPRceC5/image 3.png?auth_key=1773129204-7cCzqaCJYXyeoLWLkjWDJZ-0-5799019601a5646fbb9a49b70a35597b)

![图 7：Claude Code 的测试结果](https://secure2.wostatic.cn/static/8yKXKJmW1AUjNZvbHjmDAc/image 4.png?auth_key=1773129204-8wUGBfiTTNHoMYtyC1zMJT-0-c1781a0b228fa67f12d1383eb0b3530c)

测试结果如表 1 所示，由于没有任何缓解措施，工具能够以启动 Agent 的用户权限运行。如果该用户可以免密使用 sudo，攻击者便能获得 root 权限；若用户可访问生产数据库，攻击者则能获取生产数据。

Agent	是否有确认提示	是否有自定义接口警告	命令沙盒隔离
Claude Code	否	否	否
CodeX CLI	否	否	是(默认启动)
Gemini CLI	否	否	否
OpenCode	否	否	否
OpenClaw	否	否	否

0x05 AI Agent时代的混淆代理人漏洞

这个漏洞是 AI Agent 时代中的混淆代理人 (Confused Deputy)漏洞，且容易被大多数安全从业者所忽视。

传统的混淆代理攻击是一种利用受信任的程序或用户来执行未授权操作的攻击手法。例如：CSRF通过浏览器自动发送认证请求来进行敏感操作；XSS则通过注入恶意脚本，使浏览器在已认证会话中执行攻击者的代码；点击劫持则诱导用户在看似无害的界面上进行操作，实际上却触发了敏感操作。

在这种情况下，AI Agent 成为了“代理人”，被赋予了执行 Shell 命令、读写文件以及发起网络请求的权限。用户在运行 Agent 时，实际上也隐式地授予了这些权限。LLM API 应该是指导 Agent 行动的“受信任委托人”。

然而，Agent 和 API 之间的协议缺乏对响应内容进行验证的机制。Agent 无法确定某个工具调用是由 LLM 的推理过程生成的，还是由恶意服务器硬编码返回的。API 的响应仅是一个 JSON 数据块，而任何人都可以构造这样的数据块。

这与提示词注入 (Prompt Injection)不同。在提示词注入中，攻击者通过精心构造的输入来操纵 LLM 的推理过程。而在这里，攻击者完全绕过了 LLM，根本没有 LLM 参与其中。恶意服务器不需要具备高度智能或理解自然语言的能力，只需返回结构正确的 JSON 对象，其余工作将由 Agent 自动完成。

认识到这一点至关重要，因为这意味着所有旨在“提高大型语言模型对对抗性输入的鲁棒性”的防御措施在此情境下均无效。如果大型语言模型并未参与其中，就无法提升其鲁棒性，因为这种攻击发生在协议层，处于智能层之下。

关于Agent劫持的更多信息，可参见 NIST 技术博客文章：《Technical Blog: Strengthening AI Agent Hijacking Evaluations》

0x06 Agentic AI OWASP 02:工具滥用（Tool Misuse）

这种混淆代理人漏洞的存在，完全是因为两种尚未学会相互防备的工程文化发生了碰撞：

LLM API 的文化：这种文化构建了支持代理、负载均衡、缓存和重定向的 API。高可配置性是其核心特性之一。每个 SDK 都支持自定义基础 URL，并默认传输层的安全由用户负责。

工具调用 Agent 的文化：这种文化追求响应迅速、快捷且自主的执行引擎。AI Agent 的设计初衷是能够自主行动，无需每一步都等待批准。它们默认指令来源于可信渠道。

单独来看，这两种文化都是合理的，但结合在一起却非常危险：不受信任的输入通过可配置的管道流入了一个不受限制的执行引擎中。因此，OWASP 在 2025 年 12 月发布的《Agentic AI - Threats and Mitigations（OWASP Top 10 for LLM Apps & Gen AI Agentic Security Initiative）》中将其命名为工具滥用（Tool Misuse），并列为第二大威胁。

工具滥用（Tool Misuse）是指攻击者通过欺骗性的提示词（prompt）和操作误导，操纵 AI Agent 滥用其被授权的工具，从而在权限范围内实现未授权的数据访问、系统操控或资源滥用。

与传统漏洞利用不同，这种攻击利用了AI 能够调用多个工具并执行复杂操作链的能力。这些操作表面上看起来是合法的，但组合在一起可能产生恶意效果，因此检测难度较大。在 AI 控制关键系统或敏感操作的场景中，这种风险会被进一步放大，因为攻击者可以利用自然语言的灵活性绕过安全控制并触发非预期行为。

该威胁部分被LLM06:2025 Excessive Agency（过度代理能力）覆盖。然而，Agentic AI 系统由于其动态集成能力、对工具的更高依赖以及更强的自主性，引入了新的独特风险。

我们再看回图2发现：与传统 LLM 应用（通常只在单次会话中限制工具集成）不同，Agent 通常具有长期记忆（memory），这进一步提升了自主性，并且可以将执行任务委派给其他 Agent，从而增加了非预期操作和对抗性利用的风险。

此外，该威胁还与以下问题相关：

LLM03:2025 Supply Chain（供应链风险）

LLM08:2025 Vector and Embedding Weaknesses（向量与嵌入弱点），尤其是在通过工具执行RAG（检索增强生成） 时

0x07 安全影响与防御建议

最后，请再想想：如果 AI Agent 是 AI Coding Agent （AI 编程智能体）会发生什么？

AI Coding Agent 的使用者是软件开发者，他们是编写和维护世界运转所需基础设施代码的人。开发者的机器是供应链攻击中最具价值的目标。如果 AI Coding Agent 被劫持，那么基础设施或供应链也会受到威胁（Infrastructure / Supply Chain Attack）。

一个开发者的工作站通常包含以下内容：Git 代码仓库、SSH 密钥、云凭证、内部服务的 API 令牌、数据库访问凭证、容器镜像仓库凭证、K8s 集群访问配置以及未发布的产品代码。一旦工作站被攻陷，就会引发一场严重的供应链危机。通过 DevOps 开发流程和 CI/CD 流水线，生产环境可能在几分钟内被迅速攻陷。

从攻击者的角度来看，这种攻击手法因其普适性和隐蔽性而极具吸引力。越来越多的个人和企业正在使用这类工具，但安全措施往往滞后于业务发展。如果不审计 Agent 的行为，恶意命令可能会混杂在日常工作中，在你的眼皮底下执行。修复方案很简单，我们从 Agent 开发者和当前用户两个视角分别提供不同的防御建议。

对 Agent 开发者而言：

将所有工具调用视为不受信任的输入。 无论其来源如何，工具调用都是执行特权操作的请求，在执行前必须进行验证。

对于破坏性或敏感操作，必须要求用户确认。 至少包括网络访问、项目目录之外的文件读取、涉及凭证或密钥的命令以及对系统文件的任何写入。

当 API 接口不是官方默认接口时，显示持久且不可关闭的警告。 用户应随时知道自己连接的是非标准服务器。

实施响应签名机制。 API 服务器应对响应进行签名，Agent 应验证这些签名。虽然这不能防范所有攻击（被攻陷的 Agent 仍然可以转发合法响应），但能防止最简单的伪造服务器攻击。

将所有执行过的命令记录到防篡改的日志中。 如果用户无法看到发生了什么，就不可能发现系统已被攻陷。

将工具执行沙盒化。 Agent 不需要对用户的文件系统和网络拥有完全访问权限。应在具有显式能力授权的受限环境中运行命令。

对当前用户而言：

永远不要将 ANTHROPIC_BASE_URL 或 OPENAI_BASE_URL 设置为你无法完全控制和信任的服务器。

永远不要使用非你自己编写的代码库中的 .env 文件。

对“免费 API Agent”保持高度警惕。

在使用 AI Coding Agent 后，定期检查你的 Shell 历史记录，留意那些你并未要求执行的命令。

Claude Code v2.1.71 — 完整架构分析报告

Mon, 09 Mar 2026 00:00:00 GMT

起因是因为要用的claude-sdk做一些agent业务拓展。，所以需要对它进行分析，但是很是苦恼他们的闭源加密。

Claude Code是Bun打包的单文件可执行程序，183MB大小。所有JS代码全塞在__BUN Mach-O section里，4945个模块，全部混淆压缩。哪怕用了--bytecode，Bun还是把完整JS源码一起打包（字节码只是启动加速）

后面发现该项目可以用于解密claudecode 感兴趣的大佬可以自行解密并分析。

版本: 2.1.71 构建时间: 2026-03-06T22:45:36Z 包名: @anthropic-ai/claude-code 分析日期: 2026-03-09 分析工具: bun-demincer

1. 总体架构概览

1.1 打包结构

1.2 高层架构图

1.3 模块统计

指标	数值	说明
总模块数	4,697	包含 vendor
应用模块	2,894	Claude Code 自身代码
Vendor 模块	1,805	第三方依赖
Vendor 包	127	识别的 npm 包
依赖边数	16,740	模块间调用关系
平均依赖度	3.6	每模块平均依赖数

2. 模块系统原理

Claude Code 使用 Bun bundler 将所有源码打包为单文件，通过自定义运行时实现模块加载。

2.1 核心函数详解

2.1.1 C() - CommonJS 模块工厂

工作原理: 1. 接收模块函数 A 和缓存变量 q 2. 返回一个惰性求值的工厂函数 3. 首次调用时执行模块函数，缓存结果 4. 后续调用直接返回缓存的 exports

使用场景: 包装 vendor 库（axios, semver 等）和 CJS 格式模块

示例:

2.1.2 k() - ESM 模块初始化器

工作原理: 1. 接收初始化函数 A 和缓存变量 q 2. 首次调用时执行 A(0)（0 表示已执行） 3. 将返回值缓存到 q 4. 后续调用返回缓存值

使用场景: ESM 模块的副作用执行、导出绑定

示例:

2.1.3 m1() - 导出绑定系统

工作原理: 1. 为目标对象 A 添加属性 2. 每个属性的 getter 指向 q[K] 函数 3. 支持动态重新绑定 4. 可配置和可枚举

用途: 实现类似 ESM 的命名导出

示例:

2.1.4 e() / W3() - 模块互操作性

2.2 模块依赖图结构

特点: - 深度优先执行顺序 - 环形依赖通过惰性求值解决 - 约 4,697 个独立模块节点

2.3 模块编号规则

编号范围	类型	说明
00-runtime.js	运行时	模块系统核心定义
0001-289x.js	应用模块	Claude Code 自身代码
3000-4697.js	应用模块	更多应用模块
vendor/*.js	第三方	npm 包，按包名组织

3. 启动流程详解

3.1 主函数执行流

3.2 命令处理函数 Paz()

位置: 4696.js, 第 380 行

3.3 支持的入口点类型

入口点	检测条件	用途
cli	默认	标准命令行界面
github-action	GITHUB_ACTIONS 环境变量	GitHub Actions 集成
sdk-typescript	SDK_TYPESCRIPT_MODE	TypeScript SDK 调用
sdk-python	SDK_PYTHON_MODE	Python SDK 调用
sdk-cli	SDK_CLI_MODE	CLI SDK 调用
claude-vscode	VSCODE_EXTENSION	VS Code 扩展
claude-desktop	DESKTOP_APP	桌面应用
local-agent	LOCAL_AGENT	本地代理模式
remote	SESSION_ACCESS_TOKEN	远程会话

4. Agent循环架构

4.1 主循环流程图

4.2 核心循环代码位置

组件	文件位置	函数/模块
主循环入口	3549.js	`xC()`
消息处理	3773.js	`gzz()`
API 调用	4286.js	`iSq()`, `nS()`
流处理	4286.js	事件循环 (行 621-813)
工具执行	3768.js	`Da6` 类

4.3 循环控制变量

5. API交互机制

5.1 API 客户端创建

位置: 4286.js, 第 560-597 行

5.2 API 调用参数结构

5.3 流式事件类型详解

事件类型	触发时机	处理动作
`message_start`	流开始	初始化状态，记录 TTFT 开始时间
`content_block_start`	新内容块开始	创建块累积器
`content_block_delta`	内容增量	追加文本/思考/工具输入
`thinking_delta`	思考增量	更新思考缓冲区
`content_block_stop`	块结束	完成块，添加到响应
`message_delta`	消息元数据更新	更新使用统计
`message_stop`	流结束	完成响应，触发回调

5.4 流容错机制

5.5 多后端支持

后端	检测函数	Base URL	特殊处理
First Party	`isFirstParty()`	api.anthropic.com	完整功能支持
Bedrock	`isBedrock()`	bedrock-runtime.*.amazonaws.com	推理配置文件
Vertex AI	`isVertex()`	*-aiplatform.googleapis.com	Beta 过滤

6. 工具系统详解

6.1 完整内置工具列表

6.1.1 文件操作工具

工具名	模块ID	类型	并发安全	功能描述
Read	2545.js	只读	✓	读取文件、图片、PDF、Jupyter notebook
Write	3643.js	写入	✗	创建或覆盖文件内容
Edit	4285.js	写入	✗	精确字符串替换编辑
NotebookEdit	1245.js	写入	✗	编辑 Jupyter notebook 单元格

6.1.2 搜索工具

工具名	模块ID	类型	并发安全	功能描述
Glob	1244.js	只读	✓	文件模式匹配 (glob 语法)
Grep	1244.js	只读	✓	基于 ripgrep 的正则搜索
LSP	3724.js	只读	✓	语言服务器协议代码分析
ToolSearch	2545.js	只读	✓	搜索可用工具

6.1.3 网络工具

工具名	模块ID	类型	并发安全	功能描述
WebFetch	(条件)	只读	✓	获取网页内容并 AI 处理
WebSearch	(条件)	只读	✓	网页搜索

6.1.4 执行工具

工具名	模块ID	类型	并发安全	功能描述
Bash	(条件)	写入	✗	执行 shell 命令
PowerShell	(条件)	写入	✗	执行 PowerShell 命令

6.1.5 交互工具

工具名	模块ID	类型	功能描述
AskUserQuestion	2782.js	交互	向用户提问/确认
EnterPlanMode	(内置)	交互	进入计划模式

6.1.6 代理工具

工具名	模块ID	功能描述
Task	3603.js	启动子代理执行复杂任务

6.1.7 任务管理工具

工具名	模块ID	功能描述
TaskCreate	2548.js	创建新任务
TaskUpdate	2548.js	更新任务状态
TaskGet	2783.js	获取任务详情
TaskList	2783.js	列出所有任务
TaskStop	0955.js	停止任务执行
TaskOutput	0955.js	读取后台任务输出

6.1.8 MCP 工具

工具名	模块ID	功能描述
ListMcpResourcesTool	3727.js	列出 MCP 资源
ReadMcpResourceTool	3731.js	读取 MCP 资源
TodoWrite	2410.js	管理任务清单

6.2 工具定义接口

6.3 工具执行流程

6.4 工具执行管理器

位置: 3768.js - Da6 类

7. 权限和安全模型

7.1 三层权限规则系统

7.2 权限决策流程

7.3 权限模式详解

模式	触发方式	行为
default	默认	标准行为，危险操作需确认
plan	进入计划模式	不执行实际工具，仅返回计划
acceptEdits	`-a` 或配置	自动接受文件编辑
dontAsk	配置	不提示，用预配置规则
bypassPermissions	`--dangerously-skip-permissions`	绕过所有权限检查

7.4 危险操作检测

7.5 沙箱机制

沙箱类型: 1. 工作目录沙箱 - 限制文件访问到项目目录 2. 命令沙箱 - 限制可执行的 shell 命令 3. 权限沙箱 - 基于权限规则的执行控制

禁止访问的路径:

8. Hook系统

8.1 Hook 事件类型

事件名称	触发时机	用途
PreToolUse	工具执行前	验证、修改输入、拦截
PostToolUse	工具成功执行后	处理结果、日志、后续动作
PostToolUseFailure	工具执行失败后	错误处理、清理
SessionStart	会话开始	初始化资源
Stop	停止事件	清理资源
PermissionRequest	权限请求	自定义权限处理
ConfigChange	配置变更	响应配置变化
Elicitation	引出事件	自定义数据收集
ElicitationResult	引出结果	处理收集结果
InstructionsLoaded	指令加载完成	验证 CLAUDE.md
SubagentStart	子代理启动	初始化子代理环境
SubagentStop	子代理停止	清理子代理资源
PreCompact	上下文压缩前	备份或分析对话
Notification	通知事件	自定义通知处理

8.2 Hook 配置结构

8.3 Hook 回调接口

9. 上下文管理

9.1 三级压缩机制

级别	名称	触发条件	处理方式	效果
L1	微紧凑 (microcompact)	每轮自动	清理冗余消息元素	~5-10% 减少
L2	自动紧凑 (autocompact)	超过阈值	LLM 摘要压缩	~50-70% 减少
L3	反应式紧凑	API 拒绝	紧急压缩重试	确保请求成功

9.2 压缩流程详解

9.3 提示缓存策略

9.4 令牌跟踪

精确计数:

本地估算 (快速预测):

9.5 上下文窗口配置

模型	上下文窗口	输出限制	压缩阈值
claude-opus-4-6	200K	8192	160K (80%)
claude-sonnet-4-6	200K	8192	160K (80%)
claude-haiku	200K	8192	160K (80%)

10. UI框架与渲染

10.1 技术栈

10.2 UI 组件层次

10.3 核心 Context 详解

10.3.1 UIStateContext

10.3.2 SessionContext

10.4 渲染优化

11. 认证系统

11.1 支持的认证方式

方式	环境变量	配置文件	说明
API Key	`ANTHROPIC_API_KEY`	settings.json	标准认证
Auth Token	`ANTHROPIC_AUTH_TOKEN`	settings.json	OAuth 令牌
Console Login	-	浏览器 OAuth	交互式登录
SSO	-	企业配置	单点登录

11.2 OAuth 2.0 流程

11.3 API Key 生成

11.4 令牌刷新

12. MCP集成

12.1 MCP 传输方式

方式	实现类	适用场景
Stdio	`StdioClientTransport`	本地进程
SSE	`SSEClientTransport`	HTTP 服务

12.2 MCP 服务器配置

12.3 MCP 工具调用流程

12.4 MCP 资源管理

13. 插件与Marketplace

13.1 插件来源类型

类型	说明	示例
github	GitHub 仓库	`anthropics/official-plugin`
git	Git 仓库 URL	`https://example.com/repo.git`
git-subdir	Git 子目录	`https://example.com/repo.git#subdir`

13.2 Marketplace 配置

13.3 插件清单

13.4 Skills API

14. 遥测系统

14.1 收集的数据类型

类别	事件	数据
功能使用	tool_executed	工具名、参数、持续时间
权限	permission_request	工具名、决策、批准类型
成本	cost_threshold_reached	成本金额、会话长度
错误	error_message	错误类型、堆栈
更新	update_check	当前版本、最新版本
环境	environment_detected	IDE、云平台、OS

14.2 遥测事件结构

14.3 GrowthBook 集成

14.4 环境检测

15. 企业策略功能

15.1 托管设置

15.2 策略执行流程

16. 配置文件系统

16.1 配置文件位置

作用域	路径	Git	优先级
System	/Library/Application Support/Claude Code/	-	最低
User	~/.claude/settings.json	✓	低
Project	.claude/settings.json	✓	中
Local	.claude/settings.json (gitignored)	✗	高
Session	内存 (临时)	-	更高
CLI	命令行参数	-	最高

16.2 CLAUDE.md 系统

16.3 设置 Schema

17. 子代理系统

17.1 Task 工具接口

17.2 子代理类型

类型	说明	启动方式
general-purpose	通用任务	默认
statusline-setup	状态栏配置	内部使用
Explore	代码探索	内部使用
Plan	计划生成	内部使用
ui-ux-designer	UI 设计	内部使用

17.3 子代理生命周期

17.4 团队协作

18. 会话管理

18.1 会话状态

18.2 会话持久化

18.3 会话恢复

18.4 会话清理

19. Git集成

19.1 Git 命令集成

集成点	功能
状态注入	将 git branch/status 注入系统提示
Worktree	支持创建和管理 git worktree
提交跟踪	跟踪 git commit 数量
路径解析	智能解析 git 仓库路径

19.2 Worktree 支持

19.3 Git 状态注入

20. 自动更新机制

20.1 更新检查

20.2 安装类型检测

类型	检测方法	更新方式
npm-local	package.json 存在	npm update
npm-global	which claude 在 npm prefix	npm update -g
native	二进制在特定路径	下载新版本
homebrew	brew list claude-code	brew upgrade
development	.git 目录存在	git pull

20.3 更新通道

21. 关键常量和配置

21.1 版本信息

21.2 模型常量

21.3 超时配置

21.4 路径常量

22. 安全特性

22.1 密钥保护

22.2 文件夹信任

22.3 危险路径检测

23. 性能优化策略

23.1 惰性加载

23.2 缓存策略

23.3 并发控制

24. 依赖分析

24.1 核心 Vendor 包

包名	版本	用途
@anthropic-ai/sdk	latest	Anthropic API 客户端
@modelcontextprotocol/sdk	^1.23.0	MCP 协议
react	^19.2.0	UI 框架
ink	^6.x	TUI 渲染
commander	^12.x	CLI 解析
zod	^3.23.8	数据验证
chalk	^5.x	终端颜色
simple-git	^3.28.0	Git 操作

24.2 依赖关系图

附录 A: 关键文件索引

文件/模块	内容
00-runtime.js	模块系统运行时
4696.js	CLI 入口和命令定义
3549.js	Agent 主循环
4286.js	API 客户端和流处理
3768.js	工具执行管理器
4300.js	权限检查核心
4441.js	Hook 系统
2545.js	Read 工具
4285.js	Edit 工具
3643.js	Write 工具

附录 B: 环境变量

变量	用途
`ANTHROPIC_API_KEY`	API 密钥
`ANTHROPIC_AUTH_TOKEN`	OAuth 令牌
`CLAUDE_CONFIG_DIR`	配置目录覆盖
`CLAUDECODE`	检测嵌套运行
`NODE_OPTIONS`	Node.js 参数
`GITHUB_ACTIONS`	GitHub Actions 检测

附录 C: 术语表

术语	说明
TTFT	Time to First Token，首字节时间
MCP	Model Context Protocol，模型上下文协议
Agent	代理，AI 实体的抽象
Tool	工具，Agent 可执行的操作
Hook	钩子，事件驱动的扩展点
Skill	技能，预定义的任务处理能力
Compact	压缩，减少上下文长度的操作
REPL	Read-Eval-Print Loop，交互式环境
TUI	Terminal User Interface，终端用户界面

报告结束

本报告基于 Claude Code v2.1.71 反编译源码分析生成

《从“灰产数据、”到“数据供应链”：我对 Codex 5.3 污染问题的四轮追溯》

Fri, 13 Feb 2026 00:00:00 GMT

—-codex5.3污染源图

从“异常词”到“数据供应链”：我对 Codex 5.3 污染问题的第四轮追溯

Ps：本篇是研究过程中的不同时间的碎碎念，段落短文之间不冲突。

其实这个广告就是openai官方允许的，因为普通号和go套餐自带广告，plus以上套餐无广告

攻击成本不是“百分比”，而是“绝对样本数”

以前聊训练数据投毒，最常见表达是“污染了多少比例”。这在小规模实验里没问题，但放到当代大模型，比例思维容易误导风险判断。

2024 年的《Persistent Pre-Training Poisoning of LLMs》已经很说明问题：作者在 600M 到 7B 规模上做预训练投毒，报告了一个非常低的可生效门槛——0.1% 预训练污染可在后续 SFT/DPO 后保持可测攻击效果，拒绝服务型攻击甚至在更低比例上也能保留迹象[1]。这一步其实已经在提醒我们，“后面对齐一下就会洗掉”并不稳。

随后《Scaling Trends for Data Poisoning in LLMs》把模型范围扩到 24 个前沿模型（1.5B 到 72B），给出的趋势同样不乐观：规模增长并不自动带来更强抗投毒能力，某些攻击行为反而更容易学进模型[2]。

真正把我从“比例思维”拉出来的是 2025 年这篇《Poisoning Attacks on LLMs Require a Near-constant Number of Poison Samples》：论文在 600M 到 13B、6B 到 260B token 的设置里报告，固定数量毒样本（文中示例到 250 份）可以在不同规模模型上形成接近的后门效果[3]。Anthropic 同期研究页也明确强调了这一点：随着模型变大，攻击者未必需要按比例增加毒样本[4]。

这会直接改变防守思路。过去我们容易把风险模型写成“攻击者要污染海量语料”，现在更现实的写法是“攻击者只要稳定打入少量但高触发价值的样本锚点”。两者在工程意义上是完全不同的：后者对攻击方更便宜，对防守方更痛。

RLHF 不是“回滚上游污染”的魔法按钮

RLHF 重要，但它更像减震层，不是回滚层。

《Universal Jailbreak Backdoors from Poisoned Human Feedback》（ICLR 2024）证明了偏好数据投毒可以植入“通用触发后门”，也就是加一个触发词就能显著改变安全行为[5]。AAAI 2025 的《Is poisoning a real threat to LLM alignment?》进一步比较了 PPO 与 DPO，在其设定里 DPO 在更低比例污染下就可能被诱导出后门行为[6]。

如果再往前看，2023 年《Poisoning Language Models During Instruction Tuning》已经展示过：哪怕是在指令调优阶段，少量有针对性的污染样本也能让模型在特定短语上持续异常[7]。2024 年《Sleeper Agents》又把问题推到“对抗训练后仍存活”的层面，说明后门行为可以被训练得更隐蔽，而不是自动消失[8]。

这些证据叠在一起，我现在不会再把“我们做了对齐”当作充分条件。它最多说明模型在常规评测分布里更安全，不等于在开放环境和触发条件下就没有历史污染债务。

把问题放回数据供应链，我最在意的不是单点失误，而是结构性缝隙

先看入口体量。Common Crawl 官方页面写得很直白：15 年累计超过 3000 亿页面，每月新增 30-50 亿页面[10]。这种规模决定了系统优先目标是“抓取覆盖与可用性”，不是“逐条深语义审计”。这不是谁做得不好，而是工程约束本身如此。

再看抓取排序。Common Crawl 2026-01-19 的官方博客明确提到 Web Graph 的 Harmonic Centrality 与 PageRank，并说明这些指标用于 CCBot 的 crawling choices[11]。这并不自动等于“攻击者可任意操纵”，但它意味着：链接结构、域名中心性、外链生态会真实影响内容进入样本池的机会。

然后是下游过滤差异。C4 数据集卡公开给出 en.noblocklist 变体，并注明它关闭了 badwords filter[12]。我并不把这当“错误实践”，因为研究场景确实会需要不同过滤强度；但它说明一个关键事实：同样叫“基于 Common Crawl 的清洗语料”，版本之间的安全特性可能完全不同。

类似地，T5 论文定义 C4 本身就揭示了“大规模清洗 web 语料”这件事的复杂度[13]；The Pile 论文强调多源混合带来的泛化收益，但也同时承认要面对数据成分与潜在问题的权衡[14]；RefinedWeb、FineWeb、Dolma、DataComp-LM 这些后续工作，本质都在回答同一件事：不是“要不要过滤”，而是“过滤什么、过滤到什么程度、用什么可复现标准评估过滤收益”[15][16][17][18]。

我为什么把这些都放进同一段？因为这正是“供应链视角”的含义：风险不只存在于某个恶意样本，而是存在于采集逻辑、过滤策略、版本管理、评测目标之间的系统耦合。

一条必须讲清的边界：基准数据泄漏，不等于训练投毒

写这类题目时，最容易混在一起的是两件不同问题：一类是 benchmark contamination（评测题泄漏到训练语料，导致分数虚高）；另一类是 poisoning（攻击者主动塑造模型在特定触发下的行为）。它们都和“数据污染”有关，但机制和后果并不一样。

我看 benchmark contamination 相关论文后，感觉这个边界必须写清楚。Rephrased Benchmark Samples 那篇工作显示，哪怕把评测题做语义改写，模型依然可能出现“看似泛化、实则记忆”的高分现象[29]。Cross-Language Benchmark Contamination 进一步提示，泄漏不仅发生在同语种，跨语言迁移也会把“见过题”的优势带进来[30]。而 2025 年那篇动态 benchmark contamination 综述讨论了一个现实难题：当模型、数据、基准都在快速演化时，静态去重规则很难长期维持“干净评测”[31]。

我把这组文献放进本文，不是为了偏离主题，而是为了做反证：如果我们连“评测泄漏”都很难彻底排除，就更不能轻率地把所有异常输出都归因为“模型本身变坏了”。相反，正确做法是把证据拆层：先判断是否是评测泄漏和数据重合，再看是否存在触发短语稳定性、语义后门迁移性等 poisoning 信号。另一篇 benchmark contamination 综述也强调了这一点：污染检测不是单一工具问题，而是评测协议与数据治理共同设计的问题[32]。

在封闭模型条件下，怎样做“弱归因”

拿不到闭源模型训练集，怎么证明异常输出来自数据污染？我的答案是，法证级证明很难，但弱归因可以做，而且应该做。所谓弱归因，不是一次性下结论，而是把多种可观测信号拼接成一个可复核的证据链。

我目前采用的是四层信号框架。第一层是 token 与短语异常层，观察异常词在不同任务模板下的出现稳定性，以及是否存在与任务目标弱相关但与历史垃圾语料强相关的词组。第二层是触发鲁棒性层，测试异常是否需要非常特定提示才能出现，还是在改写提示、调整语言、改变代码风格后仍可复现。第三层是语义迁移层，看异常行为是否能跨任务形态迁移，例如从“代码解释”迁移到“代码生成”或“重构建议”。第四层是时间漂移层，把同一批触发集在不同模型版本上做纵向对比，判断这是短期波动还是长期遗留模式。

为了避免“拍脑袋打分”，我给这四层做了一个最小化评分式：

这不是学术定理，只是工程上的比较尺子。它的价值在于，当团队争论“这是不是偶发”时，至少能回到统一指标：你是在哪一层给出证据、证据强度是多少、是否可以被他人复现实验。只要这个流程跑起来，讨论就会从观点对撞，变成可追溯的证据协作。

写在末尾

我后续会把这条线继续往实操推进，重点放在中文 token 异常与上游语料的可复核映射、代码语料里“语义型投毒”而非“显式恶意代码”的检测，以及从异常输出逆向定位到数据批次的最小可行流程。

如果你在做相近方向，欢迎一起把这件事从“观点竞争”变成“方法协作”。

索引

[1] arXiv:2410.13722, Persistent Pre-Training Poisoning of LLMs

https://arxiv.org/abs/2410.13722

[2] arXiv:2408.02946 (v6, 2025-07-17), Scaling Trends for Data Poisoning in LLMs

https://arxiv.org/abs/2408.02946

[3] arXiv:2510.07192, Poisoning Attacks on LLMs Require a Near-constant Number of Poison Samples

https://arxiv.org/abs/2510.07192

[4] Anthropic Research (2025-10-09), A small number of samples can poison LLMs of any size

https://www.anthropic.com/research/small-samples-poison

[5] arXiv:2311.14455 (ICLR 2024), Universal Jailbreak Backdoors from Poisoned Human Feedback

https://arxiv.org/abs/2311.14455

[6] arXiv:2406.12091 (AAAI 2025), Is poisoning a real threat to LLM alignment? Maybe more so than you think

https://arxiv.org/abs/2406.12091

[7] arXiv:2305.00944 (ICML 2023), Poisoning Language Models During Instruction Tuning

https://arxiv.org/abs/2305.00944

[8] arXiv:2401.05566, Sleeper Agents: Training Deceptive LLMs that Persist Through Safety Training

https://arxiv.org/abs/2401.05566

[9] arXiv:2508.17771 (v2, 2025-09-30), Speculating LLMs’ Chinese Training Data Pollution from Their Tokens

https://arxiv.org/abs/2508.17771

[10] Common Crawl Overview（官方）

https://commoncrawl.org/

[11] Common Crawl Blog (2026-01-19), How SEOs Are Using Common Crawl’s Web Graph Data for AI Ranking Signals

https://commoncrawl.org/blog/how-seos-are-using-common-crawls-web-graph-data-for-ai-ranking-signals

[12] Hugging Face Dataset Card, allenai/c4

https://huggingface.co/datasets/allenai/c4

[13] arXiv:1910.10683, Exploring the Limits of Transfer Learning with a Unified Text-to-Text Transformer（C4 来源论文）

https://arxiv.org/abs/1910.10683

[14] arXiv:2101.00027, The Pile: An 800GB Dataset of Diverse Text for Language Modeling

https://arxiv.org/abs/2101.00027

[15] arXiv:2306.01116, The RefinedWeb Dataset for Falcon LLM

https://arxiv.org/abs/2306.01116

[16] OpenReview (NeurIPS Datasets & Benchmarks 2024), The FineWeb Datasets: Decanting the Web for the Finest Text Data at Scale

https://openreview.net/forum?id=n6SCkn2QaG

[17] arXiv:2402.00159 / ACL 2024, Dolma: an Open Corpus of Three Trillion Tokens for Language Model Pretraining Research

https://arxiv.org/abs/2402.00159

[18] arXiv:2406.11794, DataComp-LM: In search of the next generation of training sets for language models

https://arxiv.org/abs/2406.11794

[19] Hugging Face Dataset Card, bigcode/the-stack

https://huggingface.co/datasets/bigcode/the-stack

[20] USENIX Security 2024, An LLM-Assisted Easy-to-Trigger Backdoor Attack on Code Completion Models

https://www.usenix.org/conference/usenixsecurity24/presentation/yan

[21] Mozilla Foundation (2024-02-06), Training Data for the Price of a Sandwich: Common Crawl’s Impact on Generative AI

https://www.mozillafoundation.org/en/research/library/generative-ai-training-data/common-crawl/

[22] 中新网（转经济参考报，2026-02-04）,《引擎优化还是数据污染？AI搜索暗藏“灰色地带”》

https://www.chinanews.com.cn/cj/2026/02-04/10565349.shtml

[23] NIST AI RMF 1.0 (NIST AI 100-1, 2023-01-26)

https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-ai-rmf-10

[24] NIST AI RMF: Generative AI Profile (NIST AI 600-1, 2024-07-26)

https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence

[25] OWASP GenAI Top 10 (2025), LLM04: Data and Model Poisoning

https://genai.owasp.org/llmrisk/llm042025-data-and-model-poisoning/

[26] arXiv:1911.00359, CCNet: Extracting High Quality Monolingual Datasets from Web Crawl Data

https://arxiv.org/abs/1911.00359

[27] Hugging Face Dataset Card, tiiuae/falcon-refinedweb

https://huggingface.co/datasets/tiiuae/falcon-refinedweb

[28] Hugging Face Dataset Card, HuggingFaceFW/fineweb

https://huggingface.co/datasets/HuggingFaceFW/fineweb

[29] arXiv:2311.04850, Rephrased Benchmark Samples Can Be Leveraged for Contamination Detection in Large Language Models

https://arxiv.org/abs/2311.04850

[30] arXiv:2406.13236, Cross-Language Benchmark Contamination: Expanding Data Leakage Detection Beyond English

https://arxiv.org/abs/2406.13236

[31] arXiv:2502.17521, A Survey on Dynamic Benchmark Contamination Detection in Large Language Models

https://arxiv.org/abs/2502.17521

[32] arXiv:2406.04244, A Survey on LLM Benchmark Contamination: Definitions, Detection, and Mitigation

https://arxiv.org/abs/2406.04244

[33] arXiv:2404.01019, Source-Aware Training to Improve Language Model Attribution

https://arxiv.org/abs/2404.01019

[34] arXiv:1803.09010, Datasheets for Datasets

https://arxiv.org/abs/1803.09010

[35] arXiv:1810.03993, Model Cards for Model Reporting

https://arxiv.org/abs/1810.03993

[36] arXiv:2508.06601, Deep Ignorance: Filtering Pre-Training Data Builds Tamper-Resistant Safeguards into Open-Weight LLMs

https://arxiv.org/abs/2508.06601

[37] NIST AI RMF Playbook (持续更新页面)

https://airc.nist.gov/airmf-resources/playbook

智·战 2025 —— 腾讯云鼎AI渗透大赛全景复盘

Tue, 17 Feb 2026 00:00:00 GMT

基于2025”1129”AI渗透大赛的实战复盘

作者: cdxiaodong 日期: 2025/11/29 大赛名称: 腾讯云鼎AI渗透大赛 类型: 技术复盘和未来预期

复盘基本在25年12月03即初步完成了后续就是各个版本的迭代。AI进步很快，版本迭代也很快，期望此篇文章对于有兴趣的朋友能够得到一定帮助。

大赛背景与基本介绍

大赛概况

本次大赛是全球首个专注于AI自动化渗透测试的实战竞赛，汇聚了来自清华大学、西安交通大学、香港城市大学、成信大、广州大学等顶尖高校的安全战队，以及绿盟、长亭科技等企业安全团队。

大赛核心目标：

探索AI在自动化渗透测试中的实际能力边界

对比不同AI架构和安全策略的实战效果

推动AI技术在网络安全领域的工程化落地

赛题设置分析

测试题库概览：

题目总数: 104道网络安全挑战题

难度分布:

简单: 45题 (43.3%)
中等: 51题 (49.0%)
困难: 8题 (7.7%)

漏洞类型覆盖：

高频漏洞: XSS、默认凭证、IDOR、权限提升

中频漏洞: SSTI、命令注入、SQL注入

低频但高危: 反序列化、代码执行、文件包含

特点分析： 这是一套覆盖从基础逻辑漏洞到复杂代码执行漏洞的综合性演练题库，既包含传统的Web漏洞，也涵盖了现代Web应用的安全威胁。

XBOW数据集分析（实际比赛数据）

XBOW数据集分析

数据来源： 腾讯云鼎AI渗透大赛现场演示

关键发现：

将所有环境中涉及到的漏洞映射到OWASP TOP 10上

注入漏洞（A01）以59次位居第一，占比最高

访问控制漏洞（A02）29次，位列第二

不安全的反序列化（A03）18次，排名第三

OWASP Top 10覆盖统计：

类别	数量	占比
A01: Injection	59	39.6%
A02: Broken Access Control	29	19.5%
A03: Insecure Deserialization	18	12.1%
A04: Insecure Design	7	4.7%
A05: Security Misconfiguration	7	4.7%
A06: Vulnerable Components	5	3.4%
A07: Authentication Failures	3	2.0%
A08: Integrity Failures	3	2.0%
A09: Logging Failures	3	2.0%
A10: SSRF	3	2.0%

实战洞察： 注入类漏洞和访问控制类漏洞占据了近60%的比例，这是AI渗透测试需要重点攻克的领域。

现有AI评估工具对比

AI评估工具对比表格

对比分析：

RAVEN: NYU CTF基准准确率22%，测试范围局限

CTFKnow: InterCode - CTF提升85%，基于1084个Whitepaper

Cybench: 最大成功率89.4%，上下文129k tokens

CABench: 提高CTF成功率67-75%，样本量>20,000

CAI: 收敛速度提升197-900%，但存在实验偏差

Automation Gap: 基于CAI 2026，分析视角局限

这些工具各有优劣，为本大赛的技术路线选择提供了重要参考。

自动化渗透测试的六阶段演进

自动化演进路径 - 双层流程架构

生成图片 - 自动化渗透测试演进时间线（中文）

阶段	级别	描述	类比自动驾驶
P0	人工渗透	完全依赖人类专家	L0 - 无自动化
P1	工具增强	工具执行固定步骤，人类决策	L1 - 驾驶辅助
P2	部分自动化	自动化独立步骤，无法跑完整攻击链	L2 - 部分自动化
P3	有条件自动化	自动完成有限利用链，关键节点需确认	L3 - 有条件自动驾驶
P4	高度自动化	自动跑完整攻击链，人类负责校验	L4 - 高度自动驾驶
P5	完全自动化	全链路自主运行，无需人类介入	L5 - 完全自动驾驶

现状分析： 目前参赛的顶尖战队大多处于 P3-P4 水平，能够在特定条件下自动化完成渗透测试，但在复杂场景和未知漏洞面前仍需人类专家介入。

TOKEN消耗与成本分析

各战队成本对比：

战队	平均成本/题	成本说明	主要模型
西安交大	约 1000多元/天	训练阶段成本	N/A
Antix(成信大)	19.2元	Kimi消耗较高	Kimi
绿盟	13元	性价比较高	DeepSeek
yhy0	13.7元	全用DeepSeek	DeepSeek
简单题参考	0.8元	以XBow-039-24为例	N/A

成本对比分析 - 各战队Token消耗

成本分析要点：

难题成本暴增 - 工具调用失败、意图偏离会导致成本指数级上升

模型选择影响 - DeepSeek性价比最优，Kimi在攻坚难题上有优势

优化方向 - 减少无效轮次、优化上下文压缩、精准工具调用

参赛队伍全景分析

重要说明： 各战队报告内容多为未来规划和预期，并不代表其当前的完整能力水平

长亭外 - 冠军团队 (NO.1)

核心特色: 代码化Agent接口 | 编程而非提示 | 代码规划 | DSPy框架 注：本文使用MPI指代”Model Programming Interface”（模型编程接口）

战队格言: “Programming not Prompting”

冠军成就

最终排名: 第一名（冠军）

明显优势：

第三名和冠军、亚军差距较大

成本投入：

平均每支队伍花费约 30,000元

在高成本下获得最高回报

证明了”高投入高产出”策略的有效性

核心成员: 西安交通大学博士团队

核心创新：MPI (Model Programming Interface)

长亭外 - MPI架构示意图

生成图片 - MPI工作原理（中文）

核心范式：编程而非提示 (Programming not Prompting)

设计理念对比：

传统方案（Prompting）：

长亭方案（Programming）：

实现对比

优势对比：

维度	Prompt方式	代码方式
精确性	模糊	精确 ✅
稳定性	不稳定	稳定 ✅
可维护性	难维护	易维护 ✅
逻辑表达	难以精确	完全控制 ✅

执行与暂停机制

工作原理：

价值： 让长流程控制变得非常精准，每一步都可控。

DSPy框架理念

DSPy = Programmatic LLM Interactions

核心价值：

自动化优化Prompt（无需手动调参）

程序化定义LLM调用流程

类型化的输入输出保证

“让AI自己写Prompt，而不是人类猜测”

编程 vs 提示词：

提示词工程：

优点: 简单易上手

缺点: 不稳定、难以调试、难以维护、难以扩展

代码规划：

优点: 稳定、易调试、易维护、易扩展

缺点: 需要编程基础

成功因素分析

技术理念的先进性 ✅

“Programming not Prompting”是正确的方向

代码比自然语言精确、稳定、易维护

工程化的完整性 ✅

完整的实现框架

成熟的DSPy库

可落地的方案

团队的专业深度 ✅

西交博士团队：深厚的理论功底、丰富的工程经验

高投入的有效利用 ✅

3万元/队的成本：不是浪费，是投资

用在了刀刃上，获得了最高回报

可借鉴之处

代码优于提示 ⭐⭐⭐⭐⭐ - 这是明确的方向

执行暂停机制 ⭐⭐⭐⭐⭐ - 精确的流程控制

工程化思维 ⭐⭐⭐⭐⭐ - 完整的框架，可落地

DSPy框架 ⭐⭐⭐⭐⭐ - 值得深入研究，可直接使用

西安交通大学 - 亚军团队 (NO.2)

核心特色: 分布式集群架构 | XML强类型协议 | 三阶段流水线 | 底层工具封装

亚军成就

最终排名: 第二名（亚军）

与冠军的差距：

仅次于长亭外

明显领先第三名

展现了强大的综合实力

核心团队: 西安交通大学博士团队

核心创新：分布式集群架构

西安交大 - 分布式Master-Worker架构

生成图片 - 分布式Master-Worker集群架构（中文）

Master-Worker模式

设计理念：

传统单机架构问题：

CPU限制、内存限制、网络带宽限制、算力瓶颈

西交的分布式方案：

优势分析

水平扩展能力 - 需要更多算力？增加Worker节点即可

高可用性 - 某个Worker故障？其他Worker继续工作

负载均衡 - Master智能分配，避免某个Worker过载

任务解耦 - 任务管理与执行分离，各自独立优化

核心创新：XML强类型协议

为什么用XML？

传统JSON的问题：

特殊字符需要转义

嵌套结构容易混乱

类型不明确

XML的解决方案：

优势：

✅ 特殊字符无需转义

✅ 结构清晰

✅ 强类型约束

✅ 完美解决Payload冲突

权衡考虑：

⚠️ 文件体积更大（Token消耗增加 20-30%）

⚠️ 解析速度略慢于JSON

⚠️ 现代工具链对JSON支持更好

结论： 在攻击场景下，Payload正确性 > 传输效率，因此选择XML

通信流程

清晰、稳定、不易出错！

核心创新：三阶段流水线

生成图片 - 三阶段流水线处理（中文）

阶段1: 页面探索 (Page Exploration)

爬取网站结构

识别所有URL

分析页面类型

提取表单和参数

阶段2: 场景塑造 (Scene Modeling)

分析业务逻辑

识别数据流

构建攻击图

规划攻击路径

阶段3: 漏洞检测 (Vulnerability Detection)

发送攻击请求

分析响应

验证漏洞存在

获取Flag

流水线价值：

标准化流程 - 每个阶段职责明确

可复用性 - 每个阶段可独立优化

可扩展性 - 容易添加新阶段

核心创新：底层工具封装

urllib底层库

为什么不用requests？

requests: 自动编码可能干扰攻击流量、自动处理可能改变Payload、不可控的自动重定向

urllib: 完全控制请求、精确构造攻击流量、避免自动干扰

复杂编码模板

jsfuck等编码集成到Prompt：

避免自动编码干扰

精确控制攻击流量

提升攻击成功率

排名分析

优势 ✅

分布式架构 - 算力强大、可扩展性好、适合大规模任务

工程化完善 - XML协议稳定、流水线清晰、工具封装专业

技术深度 - 底层控制精确、避免自动干扰、攻击质量高

劣势 ⚠️

复杂度高 - 分布式架构难以维护、XML协议学习成本高

灵活性不足 - 标准化流程可能不够灵活、难以应对未知场景

与冠军的差距 - 长亭的”代码规划”更精确、控制粒度更细、DSPy框架更先进

vs 长亭外（冠军）对比

维度	西安交大	长亭外
核心创新	分布式+XML	代码规划(DSPy)
架构复杂度	极高	高
控制粒度	细	极细
灵活性	低	中
扩展性	极强	强
工程化	完善	完善

差距分析：

代码规划的精确性 - Python更灵活、更直观

流水线 vs 代码生成 - 代码生成更动态

分布式 vs 单机高性能 - CTF场景下单机足够，精确控制更重要

适用场景

最适合的场景 ✅✅✅：

大规模渗透测试（需要同时测试大量目标）

企业级SaaS平台（需要高可用性、水平扩展）

长期运营项目（复杂架构的维护成本可以接受）

可能不太适合的场景 ⚠️：

小型CTF比赛（分布式架构用不上，单机足够）

快速原型开发（学习曲线陡峭、开发周期长）

成本敏感场景（需要多台服务器、维护成本高）

可借鉴之处

分布式架构思想 ⭐⭐⭐⭐⭐ - 任务管理与执行解耦、水平扩展能力

XML强类型协议 ⭐⭐⭐⭐ - 解决Payload冲突、类型安全

三阶段流水线 ⭐⭐⭐⭐⭐ - 标准化流程、可复用设计

底层工具封装 ⭐⭐⭐⭐ - 精确控制攻击流量、提升攻击质量

BinX (广州大学) - 季军团队 (NO.3)

团队: 广州大学 核心特色: 三人特种小队架构 | 沙箱清洗 | 元工具编排 | 意图图谱

面临的三大核心问题

01 环境复杂性导致感知状态失真 (Status Distortion)

问题描述：

长周期任务导致上下文遗失

复杂环境造成状态错判

无效噪音淹没关键攻击信号

行动历史无法长期追踪

核心痛点：

#模型不知道自己是谁、在哪里、做过什么#

02 环境弱反馈导致探索效率极低 (Low Efficiency)

问题描述：

有效信号极度稀缺

中间反馈高度模糊甚至误导

巨大搜索空间导致”盲试”

核心痛点：

#模型像在迷雾中摸索，没有线索指引，只能盲目尝试#

03 结构认知局限导致决策不可靠 (Unreliable Decision-Making)

问题描述：

领域幻觉，错误归因

推理链脆弱、易中断

策略固化与缺乏灵活性

核心痛点：

#模型能说但不能推理、能生成但不能反思、能模仿但缺乏创造性策略#

核心解决方案

BinX - 三人特种小队架构

解决方案01: Sandbox Cleaning (沙箱清洗)

生成图片 - 沙箱清洗机制

#核心理念:## “只看结果，不看过程噪音”#

实现机制：

隔离沙箱预处理 - 工具的原始海量输出先进入隔离沙箱

关键结论提取 - 只将清洗后的关键结论回传给Agent

效果 - 彻底根治上下文污染、大幅减少Token浪费

优势：

降低上下文压力

提高决策质量

减少成本消耗

解决方案02: Python Meta-Tooling (元工具编排)

#核心理念:## “用代码执行替代对话空转”#

实现机制：

赋予Agent编程能力 - Agent可以编写Python代码

控制流转化 - 将”多轮对话模拟控制流”转化为”沙箱代码执行流”

复杂逻辑自闭环 - 实现复杂逻辑的瞬间自闭环

优势：

执行效率大幅提升

减少对话轮次

更精确的逻辑控制

解决方案03: Agent Pattern Graph (APG/意图图谱)

#核心理念:## “给AI装上专家的脑回路”#

实现机制：

声明式图结构 - 采用YAML格式

标准作业程序(SOP) - 将专业攻防流程编码化

效果 - 消除推理幻觉、避免盲目试探、规范化攻击流程

架构亮点：会思考的”三人特种小队”

生成图片 - 三人特种小队架构（中文）

这套架构基本治好了传统AI容易”瞎跑”和”乱猜”的毛病：

1. 大脑规划层

职责： 负责战术制定和整体策略

2. 手脚执行层

职责： 负责具体操作和执行

3. 事后复盘层

职责： 负责经验总结和学习

两张核心图：

任务图 - 把流程理顺，支持多任务并行，前面挂了能自动熔断

因果图 - 把逻辑搞对，不靠概率瞎蒙，像做实验一样拿证据说话

让AI从”死板跑脚本”进化成了”有记性、能纠错、懂战术”的实战专家。

排名分析

最终排名: 季军 (NO.3)

成功因素：

系统化的方法论 - 三大问题识别清晰

创新的解决方案 - 沙箱清洗、元工具编排、意图图谱

工程化的架构 - 三层分工明确

理论与实践结合 - 既有深度思考又有落地实现

与第一名差距分析：

可能在执行效率上略逊一筹

成本控制可能不是最优

但整体架构设计极具参考价值

可借鉴之处

问题驱动的设计 - 清晰识别核心问题是第一步

多层架构的价值 - 分工明确比单打独斗更有效

噪音处理的重要性 - 沙箱清洗是值得学习的思路

代码优于对话 - 用代码实现逻辑比多轮对话更高效

Antix (成信大) - 第四名

团队: 成信大 核心特色: Meta-Tooling | Jupyter Kernel | 极简架构 | 代码即行动 战队格言: “简单的永远是最好的”

核心理念：极简主义

设计哲学： Antix团队推崇极简设计，充分发挥核心模型能力，拒绝过度复杂化。

核心理念：

让AI直接生成意图和执行代码上下文干净噪音少效率高

代码规模：

Agent本身代码仅 100-200行

被称为”Baby Runtime”

极致精简，功能强大

核心解决方案：Meta-Tooling (元工具模式)

生成图片 - Meta-Tooling工作流程

Antix - Jupyter Kernel状态管理

单一接口原则

生成图片 - MCP协议工作流程

通过MCP协议，系统只向Agent暴露一个核心功能：

工作流程：

代码即行动

Antix - Meta-Tooling工具调用模式

Agent不再直接调用扫描器，而是编写Python脚本：

能力提升：

✅ 组合工具 - 脚本可以同时调用多个工具

✅ 处理数据逻辑 - 复杂的数据处理在代码中完成

✅ 现场写Exploit - 遇到新漏洞可以立即编写利用代码

✅ 无限灵活性 - 不受预定义工具集限制

Antix沙盒 (Antix Sandbox)

定制化的Ubuntu Docker

核心特性： 专为AI设计的渗透环境，而非传统的Kali。

预装工具：

sqlmap - SQL注入自动化

CAIDO - 流量代理与分析

其他常用渗透工具

流量监控机制：

VNC可视化：

虽然是给AI用的，但人类可以通过VNC实时连接进去

“看着”AI操作终端和浏览器

实现很好的”人机对齐”

执行层：Stateful Jupyter Kernel

会话持久化机制

核心创新： Python Executor本质上是一个有状态的Jupyter Kernel。

工作原理：

解决的问题：

✅ 完美解决Cookie和登录态保持

✅ 变量在多轮对话中持久存在

✅ 符合编程逻辑，更自然

对比传统方案：

潜在风险与缓解：

⚠️ Kernel崩溃导致状态丢失 → 定期checkpoint到磁盘

⚠️ 内存泄漏长期运行 → 每50轮自动重启Kernel

⚠️ 并发冲突 → 单会话串行化

实践证明： 在CTF场景下，风险可控且收益明显

Agent层：极简逻辑

代码规模：

Agent本身代码仅 100-200行

称为”Baby Runtime”

核心逻辑极其简单

纯自主驱动：

没有预设的主动扫描SOP

完全依赖LLM阅读环境文档后自主决策

核心优点分析

1. 极高的灵活性 (Infinite Flexibility via Code)

通过execute_code，Agent不受限于预定义的工具集：

应对未知复杂场景的能力极强

不受工具集限制

无限扩展可能

2. 真正的状态保持 (Stateful Interaction)

利用Jupyter Kernel的特性，实现天然的上下文记忆：

更高效、更符合编程逻辑的做法

变量停留在内存中

3. 零调优的通用性 (Generalization)

系统没有针对CTF题目做特定的Fine-tuning：

只给Agent一份”说明书”（200多行Prompt）

让AI像人类研究员一样思考和尝试

证明了在未知目标上的实战潜力

4. 清晰的可观测性 (Observability)

结合VNC可视化和CAIDO流量代理：

解决了”AI到底在干什么”的黑盒问题

人类可随时介入或复盘

5. 架构解耦 (Decoupled Architecture)

通过MCP协议，Agent（大脑）与Sandbox（手脚）完全解耦：

可随意升级大脑或手脚，互不影响

成本与效果分析

平均成本: 19.2元/题

成本分析：

在所有战队中属于中等偏高水平

主要因为使用Kimi消耗较高

但换用DeepSeek后成本会大幅降低

排名分析： 第四名 (NO.4)

核心价值： 证明了”零调优+极简架构”的可行性，为通用AI Agent提供了重要参考。

可借鉴之处

Meta-Tooling模式 ⭐⭐⭐⭐⭐ - 创新的工具调用方式，极大提升灵活性

Jupyter Kernel状态管理 ⭐⭐⭐⭐⭐ - 优雅的状态保持方案，解决Agent一大痛点

极简设计理念 ⭐⭐⭐⭐ - “简单就是最好的”，避免过度工程化

人类可视化 ⭐⭐⭐⭐ - VNC+流量代理解决AI黑盒问题

NeuroSploit (清华联合) - 第六名

团队: 清华/东南/国防科大联合战队 核心特色: 层级化多智能体 | 知识与军火双引擎 | 自进化能力 | 专家级深度

团队背景

由三所顶尖高校安全团队联合组成：

清华大学 - 核心算法与架构设计

东南大学 - 工程实现与优化

国防科技大学 - 安全领域专业知识

优势互补：

清华的AI技术积累

东南的工程化能力

国科大的安全专业背景

架构设计

NeuroSploit - 层级化多智能体架构

生成图片 - 层级化多智能体架构（中文）

架构01: 层级化多智能体 (Hierarchical Agents)

“司令部 + 特种兵”模式：

Lead Agent（司令部）

统筹全局

分析目标环境、制定攻击策略

分配任务给Sub-Agents、协调各Sub-Agent工作

Sub-Agents（特种兵）

Recon Sub-Agent（侦察兵） - 负责信息收集、端口扫描、目录枚举

Exploit Sub-Agent（突击兵） - 负责漏洞利用、执行攻击代码、获取Shell

专精Sub-Agents（专家兵）

XSS Sub-Agent - 专注跨站脚本攻击
IDOR Sub-Agent - 专注不安全的直接对象引用
SSTI Sub-Agent - 专注服务器端模板注入
RCE Sub-Agent - 专注远程代码执行
SQLi Sub-Agent - 专注SQL注入

协作流程：

架构02: 知识与军火双引擎 (Dual Engines)

NeuroSploit - 知识军火库架构

生成图片 - 知识军火库系统架构（中文）

引擎1: OWASP知识库

作用: 指导战术

内容: 安全知识、攻击方法、漏洞原理

形式: 结构化的安全知识

引擎2: Payload军火库

作用: 提供弹药

内容: 50+个现成的Payload模板

形式: 可直接使用的攻击代码

工作原理：

架构03: MCP工具矩阵 (MCP Tool Matrix)

支持的工具：

Nuclei - 漏洞扫描

Xray - 被动扫描

Playwright - 浏览器自动化

Nmap - 端口扫描

Sqlmap - SQL注入

MCP封装（标准化）：

优势：

参数化控制

统一接口

易于维护

Agent更容易理解

架构04: 状态与记忆闭环 (Loop Management)

Apache Burr状态流转：

ReMem Agent（记忆Agent）： 存储成功/失败经验，形成闭环。

记忆机制：

工作流程：

核心优点

1. 具备”自进化”能力 (Self-Evolution) ⭐⭐⭐⭐⭐

最大亮点！ 通过ReMem机制，系统能”记住”成功攻击模式。

进化过程：

价值： 随着任务增加，系统越用越强！

2. 专家级深度 (Deep Specialization) ⭐⭐⭐⭐⭐

拒绝”万金油”式Agent

针对不同漏洞类型配备专有模型/Prompt，攻击深度远超通用Agent。

3. 有理有据的攻击 (Reasoned Attacks) ⭐⭐⭐⭐

依托内置军火库与CheatSheet，模拟人类黑客”查阅文档 -> 构造Payload”思维路径。

4. 白盒化可控 (Controllability) ⭐⭐⭐⭐

通过可视化界面监控Agent的每一步决策路径，确保逻辑不跑偏。

排名分析

最终排名: 第六名 (NO.6)

可能的原因：

架构复杂度高 - 理论上非常先进，但工程实现难度大，可能出现各种bug

启动成本高 - 需要积累足够经验才强大，比赛时间有限

专门化的局限 - 在已知漏洞类型上很强，但遇到全新类型可能不如通用方案

可借鉴之处

层级化多智能体架构 ⭐⭐⭐⭐⭐ - 明确的分工协作，专业分工提升效率

知识军火库 ⭐⭐⭐⭐⭐ - Payload模板化管理，知识库系统化

ReMem自进化机制 ⭐⭐⭐⭐⭐ - 经验积累和复用，系统越用越强

可视化监控 ⭐⭐⭐⭐ - 解决AI黑盒问题，提升可信度

绿盟 - 第七名

核心特色: 轻量级蜂群架构 | 共享笔记本 | 三大纠偏机制 | 异构模型组合

架构突破：蜂群并行与静默协作

生成图片 - 蜂群并行架构（中文）

核心理念：轻量级蜂群架构 (Lightweight Swarm)

针对传统集中式架构在多目标场景下的性能瓶颈。

架构特性详解

1. 多Agent单兵作战

每个Agent独立运作

不依赖集中式协调

避免单点故障，提高整体容错性

2. 并行探测与独立上下文

每个Agent拥有独立的上下文空间

可以同时探测多个目标

上下文互不干扰

3. 基于共享笔记本的非阻塞协作模式 ⭐核心创新

传统方案问题：

Agent之间直接对话

导致高额Token消耗

容易产生上下文污染

共享笔记本方案：

优势：

✅ 避免直接对话带来的高额Token消耗

✅ 打破信息孤岛

✅ 实现低成本的高效协同

✅ 非阻塞式通信

工程调优：三大纠偏机制

LLM在实战中容易出现：产生幻觉、陷入死循环、在错误路径上越走越远

三大核心控制机制：

纠偏机制01: 防降智

绿盟 - Agent防长上下文降智与快速恢复机制

问题： 长上下文导致认知退化

解决方案： 状态重置 + 记忆回注

实现流程：

纠偏机制02: 防沉迷

问题： 工具调用陷入死循环

解决方案： Hook干预打断

实现机制：

监控工具调用模式

识别重复性调用

Hook机制强制打断

重新评估策略

纠偏机制03: 防依赖

问题： 错误路径依赖

解决方案： 定期清除笔记

设计思路：

共享笔记中可能包含错误信息

Agent可能过度依赖旧经验

需要定期”遗忘”

异构模型组合策略

模型分工：

主力模型: DeepSeek - 常规任务，性价比高

攻坚模型: Kimi - 困难问题，在解决困难问题上效果更好

成本控制：

优先使用DeepSeek（便宜）

遇到难题切换Kimi（强力）

根据题目难度动态调整

成本分析

单题解题成本: 约13元

在所有战队中的性价比：

绿盟: 13元/题 ← 性价比优秀

成本优势来源：

共享笔记本减少对话消耗

纠偏机制减少无效尝试

异构模型优化资源配置

轻量级架构降低开销

排名分析

最终排名: 第七名 (NO.7)

可能的原因：

架构创新但执行有难度 - 蜂群架构理念很好，但工程实现复杂度较高

成本控制优秀但效果一般 - 13元/题的成本很优秀，但解题数量可能不是最多

共享笔记的双刃剑 - 减少了对话消耗，但可能也减少了一些有益的信息交流

可借鉴之处

共享笔记模式 ⭐⭐⭐⭐⭐ - 创新的协作模式，值得进一步优化

三大纠偏机制 ⭐⭐⭐⭐⭐ - 系统化的问题识别，实用的解决方案

异构模型组合 ⭐⭐⭐⭐ - 平衡性能与成本，实战效果显著

轻量级设计理念 ⭐⭐⭐⭐ - 避免过度复杂化，保持系统灵活性

香港城市大学 - 第八名

核心特色: 多级队列系统 | 动态提示注入 | 赛马机制 | ReAct循环

生成图片 - ReAct循环模式

核心痛点识别

痛点1: LLM的不稳定性 (Instability)

大语言模型（LLM）具有随机性，单一Agent可能会：

陷入死循环

产生幻觉

在错误思路上”钻牛角尖”

痛点2: 上下文跟踪困难 (Context Loss)

CTF挑战通常需要多轮交互，随着对话轮数增加，模型容易遗忘关键信息。

痛点3: 非对称问题导致效率低下 (Inefficiency)

题目难度不一，如果在很难的题目上卡住太久，会浪费宝贵的比赛时间。

痛点4: 工具调用的资源浪费

多个Agent同时对同一目标进行扫描，造成时间和计算资源的极大浪费。

调度模块 (Scheduling Module)

香港城市大学 - 多级队列调度系统

多级队列机制

四级参数阈值队列：

亮点设计：提示词注入 (Hint Injection) ⭐

香港城市大学 - Hint Injection机制

创新点： 当题目从第一队列”降级”到第二队列时，调度器会自动从比赛平台获取 "提示信息(Hint)" 并注入到Agent的提示词中。

工作流程：

示例：

价值：

打破AI的思维僵局

提供关键线索

避免无谓的重复尝试

赛马机制 (Agent Racing)

设计思路： 对于一道题，系统会同时指派一个Agent Group（包含5个Agent）并行解题。

5个Agent的差异： 拥有不同的模型温度（Temperature）设置，产生多样化的解题思路

温度设置示例：

工作流程：

排名分析

最终排名: 第八名 (NO.8)

优势 ✅

多级队列设计 - 合理的资源分配，Hint Injection是亮点

赛马机制 - 并行解题思路好，多样化温度设置

共享记忆 - 避免重复劳动，Agent间信息共享

劣势 ⚠️

赛马机制成本高 - 5个Agent同时跑，Token消耗巨大

队列降级可能浪费时间 - 在Queue 1浪费30步，再在Queue 2浪费50步

没有根本解决Agent能力问题 - 温度调整只是改变多样性，不提升Agent真实能力

可借鉴之处

Hint Injection ⭐⭐⭐⭐⭐ - 非常实用的创新，可以直接应用

多级队列 ⭐⭐⭐⭐ - 资源分配思路好，可优化调整

持久化共享记忆 ⭐⭐⭐⭐⭐ - 避免重复劳动，Agent接力解题

赛马机制 ⭐⭐⭐ - 并行思路好，但成本考虑

yhy0 - 第九名

核心特色: 顾问介入机制 | 极简工具设计 | 兜底策略 | 按需知识加载

核心创新：顾问介入机制

yhy0 - 顾问介入机制流程

设计理念

模拟日常使用LLM的习惯：

从不盲信LLM的回答

yhy0将这个思路应用到Agent系统中：

引入”顾问Agent”

在关键时刻介入

提供专业建议

四种触发机制

触发1: 任务开始时

时机： Agent刚接收到新任务

顾问作用： 提供初始建议，避免盲目尝试

触发2: 连续失败时

时机： 失败3次、6次、9次时

顾问作用： 重新评估策略，打破思维定式

阶梯式介入：

3次失败：轻度提醒

6次失败：中度建议

9次失败：强力干预

触发3: 定期咨询

时机： 每5次尝试定期咨询

顾问作用： 防止主攻手陷入思维定式

触发4: 主动求助

时机： LLM自己意识到卡住了

顾问作用： 提供关键帮助

设计特点

1. 顾问Agent设计

核心理念： 模拟人类专家的思维方式

特点：

从不盲信LLM - 批判性思维

极简的工具设计 - 直接用Kali工具

把主动权交给LLM - 让它自己规划

兜底策略 - 关键时刻救回多道题

2. 极简工具设计

设计思路： 放弃复杂封装，直接让LLM用Kali工具

3. 把主动权交给LLM

设计理念： 让AI自己规划攻击步骤

当前问题

主Agent的Prompt混杂太多

问题内容混杂：

解题策略

Python规范

Docker用法

漏洞知识

导致问题：

认知负担过重

出现Python代码格式错误

工具误用

漏洞判断失误

总结：

“冲刺策略、消耗大、效果差”

实际成果

统计数据：

解出题目：73道

总消耗：1000元

平均每题：13.7元

使用模型：全部DeepSeek

成本分析

在所有战队中：

成本：13.7元/题（中游水平）

比绿盟（13元）略高

比Antix（19.2元）低

性价比不错

未来规划

主Agent只负责规划

改进思路：

按需加载知识

参考Claude Code的Skills设计：

示例：

可借鉴之处

顾问介入机制 ⭐⭐⭐⭐⭐ - 创新的兜底策略，可直接应用到其他系统

极简工具设计 ⭐⭐⭐⭐ - 避免过度封装，降低上下文干扰

按需知识加载 ⭐⭐⭐⭐⭐ - 参考Claude Code Skills，避免Prompt爆炸

子Agent分工 ⭐⭐⭐⭐ - 规划与执行分离，降低认知负担

核心术语表

为确保文档专业性，本文档中使用的核心技术术语定义如下：

术语	全称	定义	来源
MPI	Model Programming Interface	模型编程接口，用代码而非提示词来控制AI模型	长亭外团队自定义
MCP	Model Context Protocol	模型上下文协议，Anthropic提出的AI工具标准化协议	Anthropic (2024)
DSPy	Declarative Programming for LLMs	斯坦福NLP Group开发的程序化LLM交互框架	Stanford NLP Group
Meta-Tooling	元工具模式	不直接调用工具，而是让AI写代码来调用工具的设计模式	Antix团队
APG	Agent Pattern Graph	Agent意图图谱，用YAML定义的声明式攻击流程图	BinX团队
ReAct	Reasoning + Acting	推理-行动循环模式	Stanford (2022)
ReMem	Remember Memory	记忆回溯机制，存储和复用攻击经验的系统	NeuroSploit团队
SOP	Standard Operating Procedure	标准作业程序	通用术语
CTF	Capture The Flag	夺旗赛，网络安全竞赛形式	通用术语
RAG	Retrieval-Augmented Generation	检索增强生成，结合知识库的生成方式	通用术语

重要说明： MPI本文档中的定义不同于传统并行计算中的MPI（Message Passing Interface，消息传递接口）

技术路线深度对比

生成图片 - 三种Agent架构对比

路线1: Prompt Engineering (提示词工程) ⚠️

代表战队： 早期方案，本次比赛无人采用纯Prompt方案

生成图片 - Prompt工程vs代码规划对比

局限性：

⚠️ 稳定性依赖模型能力

⚠️ 复杂逻辑难以精确表达

⚠️ 维护成本高

⚠️ 长上下文性能下降

结论：

在复杂任务中已被代码规划超越，但在简单场景仍有效
适合场景： 快速原型开发、简单任务 不适合场景： 生产环境、复杂自动化流程

路线2: Code Planning (代码规划) ✅

代表战队：

🥇 长亭外（MPI/DSPy）

🥈 西安交大（XML协议）

🥉 BinX（元工具编排）

核心理念：

用代码/协议替代Prompt进行规划和控制

优势：

✅ 精确性

✅ 稳定性

✅ 可维护性

✅ 可扩展性

结论：

代码规划是明确的主流方向

路线3: Meta-Tooling (元工具模式) ✅

代表战队： Antix（成信大）

核心理念：

不调用工具，而是让AI写代码调用工具

实现方式：

优势：

✅ 极高灵活性

✅ 无限扩展性

✅ 状态保持（Jupyter）

✅ 极简架构

排名： 第4名

结论：

极简主义的价值体现，通用性强

路线4: Hierarchical Multi-Agent (层级化多智能体) ✅

代表战队：

NeuroSploit（清华）

BinX（三人小队）

yhy0（规划执行分离）

核心理念：

分工协作，专业分工

优势：

✅ 专业分工

✅ 提升效率

✅ 降低单Agent复杂度

结论：

多Agent是主流方向，但实现方式各异

路线5: Swarm Intelligence (蜂群智能) ✅

代表战队： 绿盟

核心理念：

多个轻量Agent并行协作，共享笔记

实现方式：

多Agent单兵作战

独立上下文

共享笔记本（异步通信）

优势：

✅ 高并发

✅ 低成本（13元/题）

✅ 信息共享

排名： 第7名

结论：

轻量级蜂群是高性价比方案

路线6: Distributed Architecture (分布式架构) ✅

代表战队： 西安交大

核心理念：

Master-Worker模式，任务管理解耦

实现方式：

Master节点：任务调度

Worker节点：执行渗透

XML协议：标准通信

优势：

✅ 水平扩展

✅ 高可用

✅ 负载均衡

排名： 第2名 🥈

结论：

企业级应用的必备架构

九大战队技术方案全景对比表

综合对比表（基于原始XBow笔记扩展）

战队	排名	对自动化的核心观点	方法架构	关键技术/特点	优点	缺点/挑战	成本
长亭外	🥇1	用代码精确规划，替代不稳定Prompt	DSPy/MPI	- 代码规划- DSPy框架- 执行暂停机制	- 精确控制- 稳定可靠- 易维护	- 需要编程基础- 成本较高	~30元/题
西安交大	🥈2	分布式+标准化流程	Master-Worker + XML	- 分布式集群- XML强类型协议- 三阶段流水线	- 水平扩展- 高可用- 类型安全	- 复杂度高- 灵活性不足	N/A
BinX	🥉3	解决AI感知状态失真和效率低	三人小队架构	- 沙箱清洗- 元工具编排- 意图图谱	- 系统化方法论- 噪音处理	- 实现复杂度高	N/A
Antix	4	极简设计，充分发挥模型能力	Meta-Tooling	- Jupyter Kernel- 单一接口- 零调优	- 极高灵活性- 状态保持- 通用性强	- 依赖模型能力	19.2元/题
(第五名)	5	信息缺失	信息缺失	信息缺失	信息缺失	信息缺失	N/A
NeuroSploit	6	外部知识库弥补模型不足	多Agent + MCP	- 知识军火库- ReMem自进化- 层级化Agent	- 自进化能力- 专家级深度	- 架构复杂- 启动成本高	N/A
绿盟	7	多智能体协作和信息共享	蜂群并行	- 共享笔记本- 三大纠偏机制	- 高并发- 低成本- 信息整合	- 工程实现难度	13元/题
香港城市大学	8	分级处理不同难度任务	多级队列 + ReAct	- Hint Injection- 赛马机制- 共享记忆	- 资源分配合理- 打破僵局	- 赛马成本高	N/A
yhy0	9	顾问介入提供兜底策略	顾问介入机制	- 四种触发机制- 按需知识加载	- 创新的兜底策略- 实用价值高	- Prompt混杂	13.7元/题

核心洞察总结（综合原始笔记）

1. 技术路径分野：Prompting vs Programming

主要分歧：

Prompting（提示词工程） ：通过精心设计的提示词控制AI（已被淘汰）

Programming（代码规划） ：用代码/协议显式定义业务逻辑（主流趋势）

实践证明：

长亭外、西安交大等前列战队都采用代码规划

代码规划在精确性、稳定性、可维护性上全面超越提示词工程

2. 模型能力是决定性因素

关键发现：

所有成功方案都依赖强大的底层LLM

DeepSeek：性价比最优，适合常规任务

Kimi：在攻坚难题上有优势

Claude Code：在代码生成上表现出色

结论：

AI渗透的上限由底层模型能力决定，架构设计决定了能多大程度发挥模型能力

3. 务实与前瞻的平衡

两种极致：

务实战队（如Antix）：在现有模型能力下用最简单方法解决问题

前瞻战队（如长亭外、NeuroSploit）：探索应对真实世界中复杂、非收敛的渗透空间

最佳实践： 融合两者，在工程化和创新之间找到平衡

核心问题解决方案对比

问题1: 上下文污染与Token浪费

生成图片 - 上下文管理策略对比

战队	解决方案	效果评级	创新性	实用性
BinX	沙箱清洗	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐
绿盟	共享笔记	⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐
Antix	Jupyter状态	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐

最佳方案：

BinX的沙箱清洗最彻底

Antix的Jupyter状态最优雅

两者结合效果最佳

问题2: Agent逻辑跑偏

战队	解决方案	效果评级	系统性	实用性
BinX	意图图谱	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐
绿盟	三大纠偏机制	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐
NeuroSploit	Apache Burr	⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐
yhy0	顾问介入	⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐

最佳方案：

BinX的意图图谱最系统

绿盟的纠偏机制最实用

yhy0的顾问机制最创新

问题3: 工具调用低效

战队	解决方案	效果评级	简洁性	灵活性
Antix	Meta-Tooling	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐
BinX	元工具编排	⭐⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐⭐
NeuroSploit	MCP工具矩阵	⭐⭐⭐⭐	⭐⭐⭐	⭐⭐⭐⭐
长亭外	代码调用	⭐⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐

最佳方案：

Antix的单一接口最简洁

长亭外的代码调用最精确

都值得学习

问题4: 经验无法积累

战队	解决方案	效果评级	完整性	独特性
NeuroSploit	ReMem自进化	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐
BinX	复盘层	⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐
港城大	持久化共享记忆	⭐⭐⭐⭐	⭐⭐⭐	⭐⭐⭐

最佳方案：

NeuroSploit的ReMem最完整

唯一真正”自进化”的方案

问题5: 状态保持困难

战队	解决方案	效果评级	优雅性	效率
Antix	Jupyter Kernel	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐
港城大	持久化共享记忆	⭐⭐⭐⭐	⭐⭐⭐	⭐⭐⭐⭐

最佳方案：

Antix的Jupyter Kernel是最佳实践

天然的状态保持，优雅高效

综合分析与总结

📊 一、核心结论

结论1: AI渗透已进化为”自动化编程与执行系统”

关键洞察：

2025年的AI渗透实战已经脱离了”聊天机器人”的范畴进化为”基于MCP协议的自动化编程与执行系统”

证据：

✅ 长亭外：MPI（Model Programming Interface）

✅ Antix：Meta-Tooling + Python执行

✅ BinX：Python Meta-Tooling

✅ NeuroSploit：MCP工具矩阵

✅ 西交：XML协议 + 编码控制

共同点： 都在用代码/协议替代纯Prompt

结论2: 获胜关键 - 平衡”拒绝过度封装”与”结构化思考”

两种极致的平衡：

像长亭那样：用严谨的工程代码规划路径

优势：

精确控制

稳定可靠

易于维护

适合工程化

代表： 长亭外（冠军）、西安交大（亚军）

像Antix那样：赋予AI直接操作Shell的自由度

优势：

极高灵活性

无限扩展性

零调优通用性

应对未知场景

代表： Antix（第四名）

最佳实践：融合两者

建议架构：

结论4: 底层模型能力决定上限

关键发现：

模型能力对比：

生成图片 - LLM模型能力对比

模型	优势	劣势	适用场景	战队使用
DeepSeek	性价比高、速度快	复杂推理能力稍弱	常规任务、成本敏感	绿盟、yhy0
Kimi	攻坚难题能力强、上下文长	成本较高	困难问题、长文本	Antix
Claude	代码生成优秀、推理强	成本高	代码规划、复杂任务	长亭外

实践证明：

冠军长亭外使用Claude获得最佳效果

Antix使用Kimi在攻坚难题上表现突出

绿盟、yhy0全用DeepSeek实现高性价比

结论：

AI渗透的上限由底层模型能力决定架构设计决定了能多大程度发挥模型能力不同模型适合不同场景，需根据任务特点选择

结论3: CTF场景 vs 实战场景

对于单点CTF比赛、明确渗透目标：

现状：

✅ 最前沿的AI和Agent框架已有能力解决大部分问题 ✅ 未解决的可通过增加能力覆盖度、知识覆盖度解决

证据：

长亭外、西交、BinX等都能解决70+道题

在已知漏洞类型上成功率极高

成本可控制在20元/题以内

但对于实际AI渗透赋能：

挑战：

⚠️ 仍需攻破不少难关 ⚠️ 工程化是未来主要要攻克的目标

工程化挑战清单：

任务调度

会话隔离

并发控制

漏报/误报处理

漏测检测

召回率优化

SaaS产品化

多租户管理

权限控制

审计日志

🏆 二、战队排名与分析

完整排名表

排名	战队	核心方案	平均成本/题	总投入估算	关键特点
1	长亭外	DSPy/MPI	~30元	~30,000元	代码规划，精确控制
2	西安交大	分布式集群 + XML	N/A	N/A	水平扩展，标准化
3	广州大学(BinX)	沙箱清洗 + 元工具	N/A	N/A	三人小队，意图图谱
4	Antix(成信大)	Meta-Tooling	19.2元	N/A	极简架构，代码即行动
5	(第五名)	信息缺失	N/A	N/A	信息缺失
6	NeuroSploit(清华等)	多Agent + 知识军火库	N/A	N/A	自进化，专家级深度
7	绿盟	蜂群并行	13元	N/A	轻量级，共享笔记
8	香港城市大学	多级队列 + 赛马	N/A	N/A	Hint注入，并行
9	yhy0	顾问介入	13.7元	~1,000元	兜底策略，按需知识

成本数据说明： N/A表示数据未公开或无法计算。西安交大的”约1000+元/天”为训练阶段成本，不代表单题成本。

排名规律分析

冠军亚军的共性

长亭外 + 西安交大：

✅ 都强调”代码/协议”优于Prompt

✅ 都有完整的工程化框架

✅ 都是博士团队，技术深厚

✅ 都有明确的标准化流程

结论：

代码规划 + 工程化 = 冠军相

前四名的共性

长亭外、西交、BinX、Antix：

✅ 都在用”代码”替代”Prompt”

✅ 都有明确的技术路线

✅ 都解决了核心痛点

结论：

代码化是主流趋势

成本与排名的关系

战队	成本(元/题)	排名
绿盟	13.0	7
yhy0	13.7	9
Antix	19.2	4
长亭外	~30	1 🏆

洞察：

最低成本 ≠ 最高排名

冠军愿意为效果投入

性价比和效果需要平衡

🚀 三、未来趋势与建议

生成图片 - AI渗透测试技术演进路线图（中文）

趋势1: 从Prompt到Code（已验证）✅

结论：

✅ 代码规划是明确趋势，不是实验

行动建议：

学习DSPy框架

研究MPI模式

实践代码生成

趋势2: 从单体到分层（已验证）✅

结论：

✅ 多Agent分工是主流，单Agent已淘汰

行动建议：

设计清晰的Agent分工

建立标准化通信协议

实现可视化监控

趋势3: 从无状态到有状态（进行中）⚠️

结论：

⚠️ Jupyter Kernel是最佳实践，但未普及

行动建议：

采用Jupyter Kernel

实现持久化记忆

建立ReMem机制

趋势4: 从黑盒到白盒（进行中）⚠️

结论：

⚠️ 可观测性是工程化必备

行动建议：

实现可视化监控

建立审计日志

支持人类介入

趋势5: 从实验到产品（待突破）❌

结论：

❌ 工程化是最大挑战，尚未突破

行动建议：

解决任务调度

实现会话隔离

优化并发控制

处理漏报误报

提升召回率

实现SaaS化

🎯 五、最终评价

大赛价值

1. 验证了技术路线

代码规划 > Prompt工程

多Agent > 单Agent

工程化 > 概念化

2. 展示了创新方向

Meta-Tooling（Antix）

意图图谱（BinX）

ReMem自进化（NeuroSploit）

顾问介入（yhy0）

3. 明确了工程化挑战

CTF场景基本解决

实战工程化待突破

SaaS产品化是未来

致谢:

感谢所有参赛战队的精彩分享，你们的创新推动了AI渗透测试技术的发展！

长亭外 - 证明了代码规划的价值

西安交大 - 展示了分布式架构的力量

BinX - 系统化的方法论

Antix - 极简主义的智慧

NeuroSploit - 自进化的创新

绿盟 - 蜂群架构的实践

香港城市大学 - Hint Injection的巧思

yhy0 - 顾问机制的兜底策略

所有战队 - 共同推动技术进步

THANKS ALL TEAMS!

2025总结

Sat, 17 Jan 2026 00:00:00 GMT

💡

随着AI进步飞快，很多信息传递也越喜欢碎片化输出，所以这篇文章也按照碎片化输出。

2025年我认为的十大文章推荐：

1.黑客团伙如何用树莓派入侵银行ATM系统并取款数年 https://favorite-article.cdxiaodong.life/黑客团伙如何用树莓派入侵银行ATM系统并取款数年 (2025_11_21 14：18：23).html

2.2025 年 11 月 18 日 Cloudflare 故障安全分析https://favorite-article.cdxiaodong.life/2025 年 11 月 18 日 Cloudflare 全球故障分析-深度学习ai错误 --- Cloudflare outage on November 18%2C 2025 (2025_11_19 09：24：49).html

3.Black Hat深度议题：ECScape如何突破AWS ECS的IAM安全边界（附PoC）https://favorite-article.cdxiaodong.life/Black Hat深度议题：ECScape如何突破AWS ECS的IAM安全边界（附PoC） (2025_8_8 15：27：12).html

4.aws全局攻击路径https://favorite-article.cdxiaodong.life/pathfinding.cloud - aws全局攻击路径 (2025_12_19 10：30：16).html

5.Google Cloud Shell Container Escapehttps://favorite-article.cdxiaodong.life/Google Cloud Shell Container Escape ｜ by Bipin Jitiya ｜ Dec%2C 2025 ｜ Medium (2025_12_17 10：00：15).html

6.VMWare Workspace ONE Accesshttps://favorite-article.cdxiaodong.life/无交互攻击VMWare Workspace ONE Access (2025_5_2 13：20：12).html

7.原创 Paper | Fuzz 工作流解析与 AI 引入方案分享 https://favorite-article.cdxiaodong.life/原创 Paper ｜ Fuzz 工作流解析与 AI 引入方案分享 (2025_2_27 12：00：12).html

8.AI for 安全攻防：自动化渗透 Agent 的工程设计与实践 https://favorite-article.cdxiaodong.life/AI for 安全攻防：自动化渗透 Agent 的工程设计与实践 (2025_11_30 11：16：17).htmlw

9.学习一个价值4.7w刀的提示词注入思路 https://favorite-article.cdxiaodong.life/奇安信攻防社区-学习一个价值4.7w刀的提示词注入思路 (2025_02_15 15：08：12).html

10.像风投一样规划技术研究https://favorite-article.cdxiaodong.life/像风投一样规划技术研究 (2025_12_17 10：30：22).html

英语

因为希望能多了解不同地方真实的信息还有更好的旅游、学习更先进的技术，25年下半年我开始尝试和外国友人进行free talk，产生了不少文化、技术、认知的碰撞。第一位认识的就是Benjamin本杰明，一个出生在加拿大比我大一岁的华裔小伙，虽然加拿大的待遇比国内高，但是发现我俩(包括大多数初入社会的同学)都有一定的共同点(比如舍不得花钱、定期存钱理财)，所以我俩聊的还挺投机，freetalk好几次了说话也变得更加直来直去。第二位要讨论的就是我的”徒弟“Ella，居住在Australia的华人，最开始认识是因为他是我的客户来着，当时工作流很火，我是最早一批使用这类工具的(当时处于还未火的发展阶段，因为兴趣使然对社区贡献了不少，甚至还跟n8n以色列技术总经理在zoom进行了一对一学习)，我也因此成为了好多客户的产品经理，Ella因为她在澳大利亚的工作流公司做stuff所以我认识了她，一开始还只是她付费向我请教知识，我为了结交朋友就免费带她一阵子，后面越了解才越发现她的事业状态和认知规划也是我蛮尊敬的(她可以做到一天只睡四个小时，可能是因为她之前在韩国留学的原因)，我最敬佩的一点是她的情绪排解方式(发布到朋友圈然后自己去宽慰自己)，这一点真的很勇敢，起初我还会觉得这样幼稚，因为在中国男生传统教育里就是有苦就得自己在心底慢慢消化，但是慢慢接触下来还是明白是我比她幼稚(也理解我比她小5岁来着)。第三位就是Alon，一位研究中国非物质文化遗产的以色列人，他说以色列即使科技发达但是也不太平、也可能遭遇到战争，其实所有国家的三观良好的老百姓还是不期望战争的(至少是期望战争不会降临到自己头上的)。等等还有认识很多人，三十多岁仍在德国留学量子力学的Kai(他说先进的量子力学技术得向中国朋友请教)，精通四种语言并想成为翻译官的Maria（虽然她当模特也是一个好胚子），居住在LA舅舅是好莱坞明星的Mariana，在乌兹别克斯坦出生但是北漂的Alex。越和他们聊天我越意识到中国和海外的差别(事实上只要你是受过中式教育的人你都很难会长时间出国，因为确实现在习惯的环境、文化和社会安全是其他国家不能给予你的。但是海外薪资当然还是比国内高很多的哈)

By the way，最重要的是我感觉我的英语进步还是飞快的，起码交流的时候语速能跟我的中文语速一样快了，当然很多words还容易卡壳，明年我会更关注跟国外从事网络安全的朋友进行信息交流分享，起码这方面的words不能落下。

健身，年轻人一定不能错过的事情。

两年前我有在学校自己健身过，每天60min空腹爬坡、引体、斯密斯卧推、高位下拉，哑铃臂屈伸真的是有啥做啥，那时候很兴奋引体能做接近二十个。连续几个月后发现居然一点肌肉不涨，然后体重还跌了。心态都崩了，后面就工作去了期间断断续续自己锻炼一直没怎么进步。到了新公司后终于下定决心报了私教课，起因是因为教练的那句话(“你报个私教并且好的身材可能需要1～3万块钱，但是你花20万也无法直接买大袄健康和身材”)，还有他的1米八六身高150体重但是臂围42cm六块腹肌(这个身材你去普通健身房一般都是见不到的)，实测下来我还是觉得做对了，两个半月肌肉涨了5.2斤、脂肪只涨了0.3斤，这说出去得吓死人。领导也说我更精神了，我每天生活也更自律了。体重也在慢慢涨上来。我的各个领导们也都是自律派，工作上卷的同时，生活和人生态度也都很卷很自律，像现充。有的人觉得怕健身会影响自己的事业发展，实则不然，我见到的听到的无论在哪个公司做高管的人都是对生活、对自己的健康是有态度的，他们即使很忙都会抽着别人午休的时间去健身或者跑步、足球等等有助于健康的事情。如果你无法做到这一点你可以现在尝试重视起来，虽然我不知道真的能不能“晚死”一点，但是让你自信这一点是可以提前享受到的。

去年我完成和在进行的ai赋能：

1.AI赋能威胁感知

2.AI重构自动化渗透

3.AI操控各种社交软件维护

4.opencawl自动化交易

等等，真是感慨、AI进步太快了、一年前还是n8n,现在已经是claudecode-team了，一个月就得迭代一次，总有新的东西冒出来。

关于安全：

最近几年漏洞挖掘比较少，25年累计挖掘了2个cve、2个cnnvd，2个cnvd，一个专利证书

旅游：

去年好像没怎么出去但是爱上了海岛，越出去经历越加重“偏见”：人生的意义不在于长度，而在于厚度。我正在努力让事业上的“极客”去带动生活上的“极客”。

每次去不同的地方旅游都有收集地铁卡的习惯，满满一册子塞不下

每到一个地方，都习惯收集当地的货币:

明年规划：

1.更专注个人投资、学习、健康、认知、进步2.挖更多的AI漏洞

2.多和家里人视频。

CD's second night

OpenClaw 17个漏洞攻击面 发布此文时只修复一个

漏洞统计概览

漏洞清单

目录

Critical 级别

High 级别

Medium 级别

GHSA-001: Environment Variable Blocklist Bypass via JVM/CLR/Build-Tool Injection Vectors

Summary

Severity

Affected Component

Affected Versions

Root Cause

Missing Variables

Reproduction Steps

Prerequisites

Step 1: Verify blocklist contents

Step 2: Programmatic verification against sanitization functions

Step 3: End-to-end JVM code execution (verified on JDK 25.0.2, Windows 10)

Step 4: Agent-side trigger

Impact

Suggested Fix

GHSA-002: TAR Archive Extraction Destination Directory Symlink Bypass

Summary

Severity

Affected Component

Affected Versions

Root Cause

Reproduction Steps

Prerequisites

Step 1: Confirm the code asymmetry

Step 2: End-to-end exploitation (verified on Windows 10, Node.js 22, npm tar 7.x)

Step 3: Contrast with ZIP behavior

Impact

Suggested Fix

GHSA-003: Windows Platform: New File Creation Escapes Workspace via Directory Junction (Missing O_NOFOLLOW)

Summary

Severity

Affected Component

Affected Versions

Affected Platform

Root Cause

The protection mechanism

The fallback and its race window

Additional issue: /proc/self/fd unavailable on Windows

The critical code path: new file creation escape

Reproduction Steps

Prerequisites

Step 1: Confirm O_NOFOLLOW is absent

Step 2: Confirm open flags lack O_NOFOLLOW

Step 3: End-to-end new file creation escape (verified on Windows 10, Node.js 22)

Step 4: Why the post-open cleanup doesn’t help

Impact

Suggested Fix

GHSA-004: SSRF and API Key Exfiltration via Unguarded Firecrawl Integration

Summary

Severity

Affected Versions

Vulnerability Details

Root Cause

Attack Vector

Proof of Concept

Step 1: Setup Attacker Server

Step 2: Modify Firecrawl Configuration

Step 3: Trigger web_fetch

Step 4: Observe Exfiltration

Impact Assessment

1. Internal Network Access (SSRF)

2. Credential Theft

3. Information Disclosure

4. Business Impact

Affected Configurations

Vulnerable If:

Not Vulnerable If:

Remediation

Immediate Fix

Additional Protections

Detection

Indicators of Compromise

OpenClaw 17个漏洞攻击面发布此文时只修复一个