🎯 CVE-2026-48710 深度技术分析：漏洞根因 · PoC/EXP · 检测指纹
🎯 CVE 全聚合深度分析
CVE-2026-48710 深度技术分析
📊 聚合 4 来源🧪 含 PoC
NVD-LatestCISA-KEVGitHub-AdvisoryPoC-in-GitHub
摘要：CVE-2026-48710 是 Starlette Web 框架中的一个高危（CVSS 6.5，MEDIUM）HTTP Host 头校验缺失漏洞。攻击者可构造包含 `/`、`?`、`#` 等特殊字符的畸形 `Host` 请求头，使其在 URL 重建过程中改变路径边界，导致基于 `request.url` 的安全校验（如认证、授权、路由保护）被绕过。该漏洞影响 1.0.1 之前的所有 Starlette 版本，并波及 FastAPI、vLLM、LiteLLM 等依赖 Starlette 的生态项目，已被 CISA 列入 KEV 目录，且在真实攻击链中可被用于 HTTP 请求/响应走私进而实施 SSRF 或进一步利用。
📌 漏洞概述
CVE ID：CVE-2026-48710
CVSS 评分：6.5（中危）
组件：Starlette（轻量级 ASGI 框架/工具包）
影响版本：< 1.0.1
修复版本：>= 1.0.1
漏洞类型：HTTP Host 头验证缺失导致的 URL 路径不一致 / 请求走私（Request Smuggling）前置条件
Starlette 是 Python ASGI 生态的核心框架，FastAPI、LiteLLM、vLLM 等众多 AI 与 Web 项目均直接依赖它。该漏洞的根因在于：框架在重建 request.url 时未对 Host 请求头按 RFC 9112 §3.2 / RFC 3986 §3.2.2 的语法进行校验，导致畸形 Host 头可改变解析后的 URL 路径。GitHub Advisory 编号为 GHSA-86qp-5c8j-p5mr，CISA 已确认其被积极利用（KEV），并指出其可与 CVE-2026-42271 链式利用。
🔬 漏洞根因分析
要理解该漏洞，须从 Starlette 的 URL 重建机制入手。当一个 HTTP 请求到达时，ASGI 服务器（如 uvicorn）会解析原始请求行中的路径，将其放入 scope["path"] 与 scope["raw_path"]，同时将请求头部中的 Host 值存入 scope["headers"]。Starlette 的核心路由算法严格使用 scope["path"] 进行路由匹配，这是可信的、由 ASGI 服务器基于实际请求行解析出的路径。然而，在构造高层次 request.url 对象时，Starlette 并未直接使用 scope["server"] 或已验证的 Host 头，而是简单地拼接字符串并重新解析：
url = f"http://{host_header}{scope['path']}" # 简化伪代码
request.url = URL(url)问题在于 host_header 完全由客户端控制，仅被当作“主机名:端口”处理。但 HTTP 规范中，Host 头仅允许 uri-host [ ":" port ] 这一严格语法，并且 uri-host 不能包含 /、?、# 等分隔符。若 Host 头中注入了这些字符（例如 Host: example.com/../../admin），则字符串拼接后的结果为 http://example.com/../../admin/foo。当 URL() 对此进行解析时，/../../admin 会被视为路径的一部分，并可能经过 URL 规范化（如去除点段）后改变最终 request.url.path 的值。更直接的是，注入 ? 或 # 会截断路径，使 request.url.path 只保留 Host 头中注入内容之前的部分，而实际请求的原始路径仍为 scope["path"] 所表示的 /foo。
这种不一致之所以成为安全漏洞，是因为大量中间件与端点——尤其是位于路由层之外的安全过滤器、认证装饰器、CSRF 防护、基于路径的访问控制（如 request.url.path 判断是否属于管理路径）——信任 request.url 而非原始的 scope["path"]。例如，一个中间件对 /admin 前缀做权限校验，但直接用 request.url.path 判断：当攻击者发送的 Host 为 example.com?x=/public/ 时，重建出的 URL 为 http://example.com?x=/public//admin，解析后的 path 变成 /，从而绕过中间件对 /admin 的拦截，但 ASGI 服务器实际将请求路由到了后端的 /admin 处理函数。同理，注入 # 或 ? 可实现路径混淆。若注入 / 和路径穿越序列，则可能使 request.url.path 与真实路径产生多样化的差异。
该漏洞同时也为 HTTP 请求/响应走私提供了条件。在反向代理（如 Nginx、AWS ALB）与 Starlette 应用串联的架构中，代理可能根据 Host 头或重建后的 URL 做出转发决策，而应用则基于另一套路径进行路由。攻击者利用畸形 Host 头可以制造代理与应用之间路径解析差异，进而造成请求走私，绕过代理层安全策略，或污染其他用户的请求。CISA 描述中明确指出“inject paths into the host part, prepending the actual path”，正是对这一机制的概括。
值得强调的是，Starlette 官方修复方案并非简单过滤非法字符，而是在构造 request.url 时使用 scope["server"] 作为权威来源，并依据 RFC 9112 §3.2 / RFC 3986 §3.2.2 对 Host 头进行验证；若 Host 头不符合语法，则回退到 scope["server"]。这表明漏洞本质是“将不可信输入当作可信的 URL 组件”的信任边界混淆问题。
💥 影响与危害
该漏洞的实际危害取决于应用如何在安全决策中使用 request.url。典型受影响场景如下：
- 基于 URL 路径的身份认证/授权绕过：若中间件判断
request.url.path是否以/admin、/internal等敏感前缀开头，攻击者通过构造Host: host.com?x=/public使request.url.path变为/，即可绕过校验访问真实路径/admin。 - 安全过滤器绕过（WAF/CSRF）：依赖
request.url做回调校验（如 OAuth 回调域名检查、CSRF origin 校验）的组件可能被绕过。若 Host 中注入额外路径，某些 URL 解析器会接受并规范化出非预期的 host 或 path，使过滤器认为请求来自可信来源。 - SSRF 与开放重定向的放大器：在服务端发起请求时，若开发者误用
request.url作为基础 URL 进行拼接，则畸形 Host 可控制后续请求的目标地址，引发 SSRF。CISA 描述中直接提到该漏洞可导致 SSRF/RCE——通常是通过走私链接触达内部接口。 - AI 生态的放大效应：Starlette 是 FastAPI 的基石，而 vLLM、LiteLLM 等 AI 推理/代理框架又基于 FastAPI。在 AI Agent 场景中，许多工具回调、插件接口会动态检查请求来源与路径，该漏洞特别容易成为进一步攻击跳板。GitHub 上相关 PoC 仓库（如
starlette-host-header-lab）已验证利用方式极为简单，只需修改 HTTP 请求头，无需特殊工具。 - 与 CVE-2026-42271 链式利用：CISA 特别指出该漏洞可与其他漏洞链式利用，典型模式为：先通过 BadHost 绕过前置认证，获得内部 API 访问权限，再利用另一个反序列化或命令注入漏洞实现 RCE。
由于该漏洞无需认证、利用条件简单（仅需向目标发送一个畸形 HTTP 请求），且已被加入 CISA KEV 目录，表明存在野外利用活动，所有将 Starlette 用于公网服务的组织都应立即评估自身暴露面。
🛡️ 修复与缓解
补丁版本：升级至 Starlette 1.0.1 或更高版本。官方补丁在构造 request.url 时对 Host 头执行 RFC 9112 §3.2 / RFC 3986 §3.2.2 语法验证，发现畸形值时回退到 ASGI 服务器提供的 scope["server"]（即 TCP 连接目标地址），从而彻底消除了 Host 头对 URL 路径边界的影响。
临时缓解措施：
- 升级依赖：由于 FastAPI 等框架通过依赖引入 Starlette，执行
pip list检查实际安装的 Starlette 版本；升级后需重启服务。若使用 FastAPI，还须注意 FastAPI 对 Starlette 版本的下限约束，确保兼容。 - 在反向代理层过滤非法 Host 头：若无法立即升级，可在 Nginx、HAProxy 或云 WAF 中拒绝包含
/、?、#、@、反斜杠或控制字符的Host头。Nginx 默认的host变量不允许这些字符，但自定义转发头时需额外校验。 - 使用中间件强制校验 Host：在应用入口添加中间件，依据 RFC 3986 的 host 语法白名单规则检查
Host头，不合规直接返回 400。注意应用自身的中间件必须运行在任何基于request.url的过滤器之前。 - 安全编码审计：检查全部代码中是否有以
request.url.path、request.url作为安全决策依据的逻辑，改为直接使用request.scope["path"]或request.scope["route"]。因为scope["path"]由 ASGI 服务器根据实际请求行生成，无法被 Host 头篡改。 - 监控与检测：在访问日志中记录并告警包含
?、#、/等异常的 Host 头；对后端响应中出现“Host 与请求行路径不一致”的请求进行审计。
鉴于该漏洞已被加入 CISA KEV 且存在链式利用风险，建议各组织将其视为紧急安全更新处理，在业务低峰期尽快完成升级。若使用公共云托管服务，需评估服务商是否已应用上游补丁。由于 Starlette 生态极广（FastAPI 用户量巨大、AI 基础设施中 vLLM/LiteLLM 也深度依赖），任何暴露于互联网的此类应用都应假定为高风险，建议立即进行排查和修补。
🧪 PoC 复现
从 GitHub 公开仓库抓取的实际 PoC 代码（仓库）。
📋 代码元数据语言md来源eris-ths/supply-chain-guard针对性✅ 已验证与漏洞相关（代码含 CVE 引用）依赖见代码注释/README用法详见代码注释中的使用说明
# Supply Chain Guard (SCG)
>**An incident-response toolkit for npm/yarn and Python (pip/poetry/uv) supply chain attacks — free,local,dependency-free.**
SCG is **not** a scanning engine that competes with commercial tools on coverage. It is a Claude Code skill and standalone shell toolkit that does three things well: **(1)** gives you a fast,
repeatable *first response* when a specific incident drops ("is my machine affected right now?"),**(2)** orchestrates existing OSS scanners (`npm audit`,`osv-scanner`,`pip-audit`) into one structured pass,and **(3)** documents hard-won *design-hygiene* lessons — especially for AI development environments — that generic scanners don't cover.
It was built and hardened during real incidents,
including:
- **[axios@1.14.1 RAT incident (2026-03-31)](https://elastic.co/security-labs/axios-one-rat-to-rule-them-all)** — npm maintainer account takeover (UNC1069/DPRK-APT) injecting a phantom dependency RAT
- **[Starlette BadHost (CVE-2026-48710,2026-05-22)](https://cryptobriefing.com/starlette-badhost-vulnerability-ai-agents/)** — Python HTTP framework Host header path injection → SSRF/RCE,
affecting FastAPI,vLLM,LiteLLM,
and the broader AI agent ecosystem
## What's new in v4 (2026-05-27)
- **Python supply chain scan** — `scripts/project-scan-py.sh` with pip-audit / osv-scanner / CVE-flagged version detection
- **CVE-flagged version layer (L3-CVE)** — track known vulnerable versions of legitimate packages with strict semver-spec evaluation (BadHost CVE-2026-48710 included out of the box)
- **Design hygiene guideline** — stdio-first MCP transport,
version pin discipline,
GCP default compute SA editor hardening (see SKILL.md §D.7 DesignHygiene)
- **Guild-CLI Devil lense integration** — invoke SCG as a Devil lense from guild-cli workflows (see "Guild-CLI Devil Integration" below)
---
## Table of Contents
- [Why This Exists](#why-this-exists)
- [How SCG Differs from Existing Tools](#how-scg-differs-from-existing-tools)
- [What SCG Is (and Isn't)](#what-scg-is-and-isnt)
- [Architecture](#architecture)
- [Quick Start](#quick-start)
- [Scan Modes](#scan-modes)
- [Threat Intelligence](#threat-intelligence)
- [Devil Gate Framework](#devil-gate-framework)
- [Standalone Scripts](#standalone-scripts)
- [CI/CD Integration](#cicd-integration)
- [Response Playbook](#response-playbook)
- [IOC Reference](#ioc-reference)
- [Disclaimer](#disclaimer)
- [Limitations](#limitations)
- [Integrity Verification](#integrity-verification)
- [License](#license)
---
## Why This Exists
On March 31,
2026,the widely-used `axios` npm package (v1.14.1 and v0.30.4) was compromised through a maintainer account takeover attributed to **UNC1069/DPRK-APT** (per Google Threat Intelligence Group). The attack injected a phantom dependency (`plain-crypto-js@4.2.1`) that deployed a cross-platform RAT via `postinstall` scripts,
disguised as legitimate system processes.
**Supply Chain Guard (SCG)** was built during the incident to provide:
1. **Immediate detection** — Is my machine or project affected right now?
2. **Structured assessment** — How severe is it? What's the blast radius?
3. **Guided response** — Step-by-step remediation with safety confirmations
4. **Ongoing defense** — An 8-gate verification framework to prevent recurrence
---
## How SCG Differs from Existing Tools
SCG is not a replacement for existing security tools. It combines multiple detection layers with a structured verification framework and guided remediation — designed for use **during active incidents** or as a periodic check alongside your existing tooling.
|
Tool |What it does |How SCG relates ||------|-------------|-----------------||**`npm audit`** |Checks registry for known vulnerabilities |SCG includes npm audit as its L1 layer,then adds IOC filesystem/network scanning,malicious package detection,and a structured response workflow on top ||**`osv-scanner`** |Scans lockfiles against Google's OSV database |
SCG includes OSV as its L2 layer. osv-scanner doesn't check for RAT artifacts on your filesystem or active C2 connections ||**Snyk / Socket.dev** |Commercial SaaS with real-time monitoring,PR checks,license scanning |SCG is free,local-first,no account required,no data sent to third parties. Designed for immediate incident response rather than ongoing monitoring ||**Manual IR** |
Ad-hoc investigation with custom scripts |SCG provides a repeatable framework (8 verification gates,convergence loop,severity matrix) instead of one-off checklists that vary per incident |**When to use SCG:**
- A supply chain incident just dropped and you need to check your machines and projects **right now**
- You want a structured,
repeatable process for verifying that a compromise has been fully addressed
- You need a lightweight check that runs locally without SaaS dependencies
**When to use something else:**
- You need continuous real-time monitoring → Snyk,Socket.dev
- You need license compliance scanning → Snyk,FOSSA
- You need coverage beyond npm/yarn → osv-scanner (supports pip,cargo,go,
etc.)
---
## What SCG Is (and Isn't)
We'd rather be honest about the boundaries than oversell. SCG is three things:
1. **An incident-response playbook,as code.** When a named incident drops (axios RAT,Shai-Hulud,a fresh CVE),SCG turns "am I affected,and if so what do I do?" into an executable checklist — 8 verification gates,a severity matrix,
and a remediation script where *every* destructive action needs explicit `[y/N]` confirmation. This is its primary value: the fast,structured *first response* that commercial monitoring tools aren't shaped for.
2. **An orchestrator of existing OSS scanners.** The L1/L2 layers wrap `npm audit` / `pip-audit` / `osv-scanner`. Most of the raw detection power is borrowed;
SCG's contribution is bundling them into one pass,adding filesystem/IOC checks the registry tools don't do,and making the output readable and actionable.
3. **Documentation of real design-hygiene lessons** (SKILL.md §D.7) — things we actually hit or investigated: MCP transport choice,GCP default-SA hardening,install-time execution vectors,
and threats that target AI dev tooling (Shai-Hulud reading `.claude/settings.json`,SANDWORM_MODE poisoning MCP configs). This niche — supply-chain hygiene for AI-assisted development — is where SCG is genuinely differentiated.
### What SCG is deliberately NOT
- **Not a coverage competitor.** The threat database (`SKILL.md` D.2,
the L3 static lists) is **hand-maintained** — it holds the incidents we've read about,not the tens of thousands of malicious packages a live commercial feed tracks. A hand-curated list *cannot* keep pace with the real rate of new threats,
and we don't pretend it does.
- **Not a behavioral analysis engine.** SCG matches known patterns. Obfuscated payloads and true zero-days with no public advisory are out of scope by construction.
- **Not continuous monitoring.** It's a point-in-time check you run during an incident or as a periodic sweep — not a service watching your dependency graph.
### Where SCG is headed
Because a hand-curated database can't win on coverage,
we're intentionally investing where SCG is *hard to replace* rather than where it will always lose:
- **Deeper incident-response playbooks** (#1) — better first-response ergonomics,more incident templates.
- **AI-development-environment hygiene** (#3) — detection and guidance for threats aimed at Claude Code / Cursor / MCP servers and similar tooling,
which commercial supply-chain scanners largely don't address.
The static threat DB (#2) will keep getting updated when notable incidents land,but it is explicitly **not** the direction we're trying to compete on.
---
## Architecture
SCG follows a **Domain-Driven Design (DDD)** architecture with three layers:
```
+-----------------------------------------------------+
|
Domain Layer ||Threat models,known threats DB,severity matrix,||Devil Gate definitions |+-----------------------------------------------------+
|Application Layer ||Use cases,scan pipeline,response protocols,||Devil execution loop |
+-----------------------------------------------------+
|Infrastructure Layer ||Scanner scripts (npm audit,OSV,static list,||IOC filesystem,network,lockfile integrity) |
+-----------------------------------------------------+
```
### Scan Pipeline
The same 5-layer pipeline applies to both ecosystems with ecosystem-specific scanners at each layer:
```
L1 ──→ L2 ──→ L3 ──→ IOC ──→ LF ──→ assess(SeverityMatrix) ──→ VERDICT
```
|Layer |npm/yarn (`project-scan.sh`) |Python (`project-scan-py.sh`) |
|-------|------------------------------|-------------------------------||**L1** |`npm audit` |`pip-audit` ||**L2** |`osv-scanner` / OSV.dev API |`osv-scanner` ||**L3** |Static list (malicious + typosquat) |Static list (malicious / typosquat + CVE-flagged versions) ||**IOC** |Filesystem + Network artifacts |Filesystem + Process artifacts (Python-flavored) ||**LF** |
`npm ci --dry-run` + integrity count |Lockfile integrity (uv.lock / poetry.lock / requirements*.txt) |
Both pipelines feed the same SeverityMatrix and Devil Gate Framework.
---
## Quick Start
### As a Claude Code Skill
Copy `SKILL.md` into your Claude Code skills directory:
```bash
# Global (all projects)
cp SKILL.md ~/.claude/skills/supply-chain-guard.md
# Or project-specific
mkdir -p .claude/skills
cp SKILL.md .claude/skills/supply-chain-guard.md
```
Then invoke in Claude Code:
```
>
/supply-chain-guard
>"Check this project for supply chain issues"
>
"Is my machine affected by the axios compromise?"
```
### As Standalone Scripts
```bash
# Environment-wide scan (IOC + all projects) [READ-ONLY]
./scripts/env-scan.sh
# npm/yarn project scan (requires package.json in cwd) [READ-ONLY]
./scripts/project-scan.sh
# Python project scan (requires pyproject.toml / requirements*.txt / poetry.lock / uv.lock in cwd) [READ-ONLY,
added in v4]
./scripts/project-scan-py.sh
# IOC-only scan (filesystem + network artifacts) [READ-ONLY]
./scripts/ioc-scan.sh
# Remediation (interactive,
every action requires confirmation)
./scripts/respond.sh --critical # Full RAT cleanup (npm + Python)
./scripts/respond.sh --high axios 1.14.0 # Pin npm package to safe version
./scripts/respond.sh --high urllib3 2.7.0 # Pin Python package (auto-detects pip/poetry/uv)
```
>**Python remediation is conservative by design.** For npm,`--high` applies the
>
override automatically. For Python it *guides*: it detects your manager
>(pip/poetry/uv),prints the exact pin command,and applies only the safe step —
>lockfile-mutating and venv-rebuild commands are shown for you to run. This avoids
>a false positive triggering a collateral force-reinstall across the fragmented
>Python packaging ecosystem.
For a polyglot repository (npm + Python),
run both project scanners sequentially from the relevant subdirectories.
>**Safety design:** All scan scripts are strictly read-only — they never modify,delete,or install anything. The remediation script (`respond.sh`) is the only script that performs destructive operations,
and **every single action requires explicit `[y/N]` confirmation** with a default of NO.
---
## Scan Modes
### Environment Scan (`env_scan`)
Scans your entire development machine for compromise indicators.
|Check |Description ||-------|-------------||**IOC: Filesystem** |RAT binaries,persistence mechanisms,staging files ||**IOC: Network** |Active C2 connections (IP + domain) ||
**IOC: Process** |Running malicious processes ||**Cross-project** |All `package-lock.json` files scanned for compromised versions ||**Malicious packages** |Known malicious package names in any lockfile |**Triggers:** "this PC","environment check","machine-wide"
### Project Scan — npm/yarn (`project_scan`)
Deep scan of a single npm/yarn project. Run from a directory containing `package.json`.
|
Layer |Scanner |Description ||-------|---------|-------------||**L1** |`npm audit` |Known vulnerabilities via npm registry ||**L2** |`osv-scanner` / OSV.dev API |Google's Open Source Vulnerability database ||**L3** |Static list |Hardcoded known-malicious package check ||**IOC** |Filesystem + Network |RAT artifact detection ||**LF** |Lockfile integrity |`npm ci --dry-run` + integrity hash count |
**Triggers:** "this project","npm audit",or `package.json` present in cwd
### Project Scan — Python (`project_scan_py`,added in v4)
Deep scan of a single Python project. Run from a directory containing `pyproject.toml`,`requirements*.txt`,`poetry.lock`,or `uv.lock`.
|Layer |Scanner |Description ||-------|---------|-------------||**L1** |`pip-audit` |
Known vulnerabilities via PyPI Advisory DB (optional — SKIP if not installed;`pip install pip-audit` recommended) ||**L2** |`osv-scanner` |Google's Open Source Vulnerability database against `uv.lock` / `poetry.lock` / `requirements*.txt` (optional — SKIP if not installed) ||**L3-MAL** |Static malicious list (`_L3_LIST`) |Known hijacked / typosquat package names. Matches PEP 621 list,
Poetry inline,and requirements-style declarations (see [PR #4](https://github.com/eris-ths/supply-chain-guard/pull/4)). FAIL on hit ||**L3-CVE** |Static CVE-flagged version list (`_L3_CVE_LIST`) |Known vulnerable versions of legitimate packages (e.g.,
`starlette<1.0.1` for [BadHost CVE-2026-48710](https://cryptobriefing.com/starlette-badhost-vulnerability-ai-agents/)). Strict semver-spec evaluation via Python's `packaging` library. FAIL on confirmed match. Warns if a package is declared but no lockfile is present (cannot evaluate version) ||**IOC** |Filesystem + Process |Python-flavored artifact check (rogue scripts,suspicious processes) ||
**LF** |Lockfile integrity |Verifies `uv.lock` / `poetry.lock` / `requirements*.txt` parses cleanly and contains pinned versions |**Triggers:** "this project" with Python files present,or any of `pyproject.toml` / `requirements*.txt` / `poetry.lock` / `uv.lock` in cwd
>
**Dependencies note:** L1 (`pip-audit`) and L2 (`osv-scanner`) gracefully SKIP with a hint when their respective CLI is absent. L3 is the always-on layer and does not require any external tool,but accurate L3-CVE evaluation needs `pip install packaging`.
---
## Threat Intelligence
### Known Threats Database
|ID |Date |Package |Threat Actor |Vector |
|----|------|---------|-------------|--------||**T001** |2026-03-31 |`axios@1.14.1`,`axios@0.30.4` |UNC1069/DPRK-APT |Maintainer compromise → phantom dep → RAT ||**T002** |2018-11 |`event-stream@3.3.6` |Unknown |Dependency injection → crypto theft ||**T003** |Ongoing |`crossenv`,`loadsh`,`crypto-js-esm` |Various |Typosquatting → postinstall exfiltration |
### T001 Kill Chain (axios RAT)
```
Credential theft → npm publish (bypass CI) → Inject phantom dep (plain-crypto-js)
→ postinstall exec → RAT drop → C2 beacon (sfrclak.com:8000) → Persist
```
### Safe Versions
|Package |Safe |Compromised ||---------|------|-------------||axios (latest) |`1.14.0` (exact) or `>=1.14.2` |`1.14.1` ||axios (legacy) |`0.30.3` (exact) |`0.30.4` |
### Advisory IDs
- [GHSA-fw8c-xr5c-95f9](https://github.com/advisories/GHSA-fw8c-xr5c-95f9)
- [MAL-2026-2306](https://osv.dev/vulnerability/MAL-2026-2306)
---
## Devil Gate Framework
SCG uses an **8-gate verification framework** organized into 4 categories,executed as a serial chain with convergence loop.
### Gates
|# |Gate |Category |Question ||---|------|----------|----------||G1 |
Direct Dependency |Dependency Poisoning |Are any direct dependencies at a compromised version? ||G2 |Transitive Dependency |Dependency Poisoning |Are any transitive (indirect) dependencies compromised? ||G3 |RAT Artifacts |Runtime Compromise |Are there RAT traces on the filesystem? ||G4 |Postinstall Scripts |Runtime Compromise |Are there suspicious `postinstall` scripts? ||G5 |Lockfile Integrity |
Integrity |Has the lockfile been tampered with? ||G6 |Provenance |Integrity |Is the package from a legitimate source/maintainer? ||G7 |Network |Environment |Are there suspicious outbound connections? ||G8 |CI/CD Hardening |Environment |Does CI/CD bypass postinstall / enforce frozen lockfile? |
### Chain Execution
```
S1: Dependency (G1+G2)
→ S2: Runtime (G3+G4)
→ S3: Integrity (G5+G6)
→ S4: Environment (G7+G8)
→ Any fail? → Fix → Re-run entire chain
→ All pass? → "No concerns" → Done
→ 3 rounds without convergence? → Escalate to user
```
### Severity Matrix
|Level |Condition |Action ||-------|-----------|--------||**CRITICAL** |
RAT artifact found OR malicious package installed |Network isolate → Kill process → Remove persistence → Reinstall ||**HIGH** |Compromised version in use |Pin safe version → Override → `npm ci` → Verify ||**MEDIUM** |Suspicious postinstall script |Manual review → Whitelist or remove ||**LOW** |Lockfile drift |`npm ci` resync ||**CLEAR** |All checks passed |No action needed |>
**Safety:** CRITICAL/HIGH responses involve destructive operations. SCG always presents findings and asks for explicit user confirmation before executing remediation.
---
## Standalone Scripts
### `scripts/env-scan.sh`
Full environment scan. Checks IOC artifacts,scans all lockfiles under `$HOME` (configurable),
and reports compromised packages.
```bash
./scripts/env-scan.sh [scan_root_dir]
# Default: $HOME
```
### `scripts/project-scan.sh`
Project-level scan. Run from a directory containing `package.json`.
```bash
cd my-project
/path/to/scripts/project-scan.sh
```
### `scripts/ioc-scan.sh`
IOC-only scan. Checks filesystem artifacts,running processes,
and network connections against known C2 indicators. Cross-platform (macOS/Linux/Windows via PowerShell).
```bash
./scripts/ioc-scan.sh
```
### `scripts/respond.sh`
Interactive remediation. **Every destructive action requires `[y/N]` confirmation (default: NO).**
```bash
# CRITICAL: Full RAT cleanup (kill → remove → reinstall)
./scripts/respond.sh --critical
# HIGH: Pin compromised package to safe version
./scripts/respond.sh --high axios 1.14.0 # npm
./scripts/respond.sh --high event-stream 3.3.5 # npm
./scripts/respond.sh --high urllib3 2.7.0 # python (pip/poetry/uv auto-detected)
```
Steps in `--critical` mode:
1. Network isolate (block C2 domain via `/etc/hosts`)
2. Kill RAT processes
3. Remove persistence (LaunchAgents / crontab / scheduled tasks)
4. Delete `node_modules` and lockfile,
clear npm cache
- **4b (Python):** purge pip cache (safe,auto);venv-rebuild shown as manual steps
5. Reinstall dependencies
6. Prompt for verification scan (`project-scan.sh` and/or `project-scan-py.sh`)
Each step checks whether action is actually needed (e.g.,skips "kill" if no RAT process is running) and shows exactly what will be executed before asking for confirmation.
For **HIGH** mode,
npm applies the override automatically;
Python is guided (detect manager → print pin command → apply only the safe step). See the Python remediation note in [Quick Start](#quick-start).
---
## CI/CD Integration
### GitHub Actions
```yaml
name: Supply Chain Guard
on:
pull_request:
paths:
- 'package.json'
- 'package-lock.json'
- 'yarn.lock'
jobs:
scg-scan:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Setup Node.js
uses: actions/setup-node@v4
with:
node-version: '20'
- name: Install dependencies (hardened)
run: npm ci --ignore-scripts
- name: Run SCG project scan
run: |
chmod +x ./scripts/project-scan.sh
./scripts/project-scan.sh
- name: Run IOC scan
run: |
chmod +x ./scripts/ioc-scan.sh
./scripts/ioc-scan.sh
```
### Hardening Recommendations
```bash
# Always use in CI:
npm ci --ignore-scripts # Block postinstall execution
# npm ci already enforces lockfile integrity by design (errors on mismatch)
# Yarn equivalent:
yarn install --frozen-lockfile --ignore-scripts
```
>**Pin actions by SHA,
not tag.** The example above uses `actions/checkout@v4` for readability,but tags can be moved. In production,pin to a full commit SHA to prevent action supply chain attacks:
>```yaml
>- uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
>- uses: actions/setup-node@39370e3970a6d050c480ffad4ff0ed4d3fdee5af # v4.1.0
>
```
---
## Response Playbook
### If CRITICAL (RAT detected)
>**Do not panic.** Follow these steps in order. Each step requires your explicit confirmation.
1. **Network Isolate** — Block C2 domain via `/etc/hosts`
2. **Kill Processes** — Terminate RAT processes (`com.apple.act.mond`,`ld.py`,`wt.exe`)
3. **Remove Persistence** — Delete LaunchAgents,crontabs,
scheduled tasks
4. **Clean npm** — Remove `node_modules` and `package-lock.json`,clear npm cache
5. **Reinstall** — Fresh `npm install &&npm ci`
6. **Rescan** — Re-run full pipeline,
expect CLEAR
### If HIGH (compromised version installed)
1. **Pin safe version** using respond.sh:
```bash
./scripts/respond.sh --high axios 1.14.0
```
This adds `overrides` (npm) or `resolutions` (yarn) to package.json,reinstalls,and prompts for verification.
2. **Or manually** in `package.json`:
```json
{"overrides": {"axios": "1.14.0" }}```
Yarn: `{"resolutions": {
"axios": "1.14.0" }}`
3. **Reinstall**: `npm ci`
4. **Verify**: Re-run scan
---
## IOC Reference
### Filesystem Artifacts
|Platform |Path |Type ||----------|------|------||macOS |`/Library/Caches/com.apple.act.mond` |RAT binary ||macOS |`~/Library/LaunchAgents/com.apple.act.mond.plist` |Persistence ||Windows |`%PROGRAMDATA%\wt.exe` |RAT binary (disguised as Windows Terminal) ||Windows |
`%TEMP%\6202033.vbs` |Dropper ||Windows |`%TEMP%\6202033.ps1` |Dropper ||Linux |`/tmp/ld.py` |RAT script ||Linux |`/tmp/.npm-cache/` |Staging directory |### Persistence Mechanisms
|Platform |Mechanism |Identifier ||----------|-----------|------------||macOS |LaunchAgent |`com.apple.act.mond` ||Windows |Scheduled Task |`WindowsTerminalUpdate` ||Linux |Crontab entry |
References `ld.py` or `.npm-cache` |### Network Indicators
|Type |Value ||------|-------||C2 Domain |`sfrclak.com` ||C2 IP |`142.11.206.73` ||C2 Port |`8000` |### Disguise Techniques
|Platform |Disguised As ||----------|-------------||macOS |Apple system process (`com.apple.act.mond`) ||Windows |Windows Terminal (`wt.exe` in ProgramData) |
---
## Output Format
```
SCG ──────────────────────────────────
[L1:audit] CLEAR|!!sev
[L2:osv] CLEAR|!!vuln-ids
[L3:static] CLEAR|!!pkg
[IOC:fs] CLEAR|!!C:artifact
[IOC:net] CLEAR|!!C:c2
[LF:integ] CLEAR|!!drift
─── Devil Gate(8) ────────────────────
G1:direct_dep G2:transitive G3:rat_fs
G4:postinstall G5:lockfile G6:provenance
G7:network G8:cicd
─── Devil Chain(R.N) ─────────────────
S1:dependency → S2:runtime → S3:integrity → S4:environment
─── Loop ─────────────────────────────
R.N → converge|continue
[VERDICT] CLEAR|HIGH|CRITICAL
───────────────────────────────────────
```
---
## References
|
Source |Description ||--------|-------------||[Zenn (JP)](https://zenn.dev/gunta/articles/0152eadf05d173) |Japanese early report ||[Elastic Security Labs](https://elastic.co/security-labs/axios-one-rat-to-rule-them-all) |Technical analysis (RAT disassembly,C2 protocol,timeline) ||[SANS](https://sans.org/blog/axios-npm-supply-chain-compromise-malicious-packages-remote-access-trojan) |
Enterprise IR procedures ||[Huntress](https://huntress.com/blog/supply-chain-compromise-axios-npm-package) |YARA signatures ||[Elastic Detections](https://elastic.co/security-labs/axios-supply-chain-compromise-detections) |SIEM detection rules (YARA/osquery/KQL) ||[Semgrep](https://semgrep.dev/blog/2026/axios-supply-chain-incident-indicators-of-compromise-and-how-to-contain-the-threat/) |
Static analysis rules,containment guide ||[SOCRadar](https://socradar.io/blog/axios-npm-supply-chain-attack-2026-ciso-guide/) |CISO guide with IOC timeline ||[Wiz](https://wiz.io/blog/axios-npm-compromised-in-supply-chain-attack) |Cloud impact analysis,container scanning ||[NVD CVE-2026-48710](https://nvd.nist.gov/vuln/detail/CVE-2026-48710) |
**Primary** — NVD canonical entry (published 2026-05-26,CVSS 3.1 base 6.5 MEDIUM,AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N) ||[GHSA-86qp-5c8j-p5mr](https://github.com/Kludex/starlette/security/advisories/GHSA-86qp-5c8j-p5mr) |**Primary** — GitHub Security Advisory on `Kludex/starlette` (published 2026-05-21): "Missing Host header validation poisons request.url.path,
bypassing path-based security checks" ||[Starlette v1.0.1 release notes](https://github.com/Kludex/starlette/releases/tag/1.0.1) |**Primary** — fix release (published 2026-05-21). Pin `starlette>=1.0.1` (and `fastapi>=0.119` for transitive resolution) ||[Starlette BadHost coverage (KuCoin)](https://kucoin.com/news/flash/starlette-vulnerability-exposes-millions-of-ai-agents-to-hackers) |
Secondary — Python ecosystem impact,AI agents framing ||[BadHost AI agent analysis (CryptoBriefing)](https://cryptobriefing.com/starlette-badhost-vulnerability-ai-agents/) |Secondary — FastAPI / vLLM / LiteLLM downstream impact framing |---
## Guild-CLI Devil Integration
If you use [guild-cli](https://github.com/eris-ths/guild-cli) (or any project that exposes a Devil lense workflow),
SCG can be invoked as one of the security lenses during a review pass.
### Recommended invocation pattern
```bash
# Inside a guild-cli review session,
in the project root:
~/path/to/supply-chain-guard/scripts/project-scan.sh # for npm/yarn projects
~/path/to/supply-chain-guard/scripts/project-scan-py.sh # for Python projects
# Capture the scan output as evidence for a judgment:
SCG_OUTPUT=$(~/path/to/supply-chain-guard/scripts/project-scan.sh 2>&1 ||
true)
# (a) Record it as a new judgment (fast-track — no prior review needed):
gate fast-track --from "$USER" \
--action "SCG supply-chain scan (Devil lense)" \
--reason "$SCG_OUTPUT"
# (b) Or attach it as the Devil lense on an existing review request <id>:
gate review <id>--lense devil --verdict concern --note "$SCG_OUTPUT"
```
>
Flag notes (verified against guild-cli): `gate review` **requires** an
>existing `<id>`,`--lense` (guild-cli spells it "lense"),and `--verdict`
>(`ok` / `concern` / `reject`). It has no `--area` flag. To log a fresh
>finding with no prior review object,
use `gate fast-track` as in (a).
### Why pair SCG with Devil
Devil's Advocate ("壊しにいく") and SCG share the same posture: **assume the worst,scan systematically,
then converge**. SCG provides the supply-chain dimension of a Devil pass — what the project's dependencies might be doing behind your back — alongside other lenses (security / correctness / architecture / user / operations).
### Limitations of the Devil pairing
- SCG runs read-only;
the Devil lense won't push fixes. Use `respond.sh` separately when remediation is required (with explicit user confirmation)
- SCG output may exceed Devil context budgets in large repos;pipe through `tail -50` if needed
- For polyglot repos,run both `project-scan.sh` and `project-scan-py.sh` and merge findings
---
## Disclaimer
SCG is a detection tool,
not a security guarantee. Being upfront about what it can and cannot do is part of the design.
**This software is provided "as-is" without warranty of any kind.** By using Supply Chain Guard,you acknowledge and agree to the following:
- **Not a substitute for professional security.** SCG is a supplementary detection tool,
not a comprehensive security solution. It does not replace professional incident response,endpoint detection and response (EDR) software,or security audits.
- **No guarantee of detection.** A `CLEAR` verdict means no matches were found against the tool's known threat patterns. **It does not mean your system or project is free from compromise.** Novel,unknown,
or modified attacks may not be detected.
- **No guarantee of remediation.** The remediation steps provided (`respond.sh`) address known indicators of specific threats. They may not fully remove all traces of a sophisticated compromise. If you suspect active compromise,engage a professional incident response team.
- **Use at your own risk.** The authors are not liable for any damages,data loss,
or security incidents arising from the use or inability to use this tool. This includes but is not limited to: false negatives (missed detections),false positives (incorrect detections),or unintended consequences of running remediation scripts.
- **Not legal or compliance advice.** This tool does not satisfy regulatory,compliance,
or legal requirements for security scanning. Consult appropriate professionals for compliance needs.
---
## Limitations
Understanding what SCG **cannot** do is as important as knowing what it can.
### Detection Boundaries
|What SCG checks |What SCG does NOT check ||-----------------|------------------------||Known compromised package versions (hardcoded DB) |
Zero-day supply chain attacks with no public advisory ||Known malicious package names |Typosquats not yet in the static list ||Specific IOC file paths for known threats |Arbitrary malware dropped to non-standard paths ||Specific C2 IP addresses and domains |C2 infrastructure that has been rotated or changed ||`postinstall` scripts in direct dependencies |Obfuscated maliciou⚔️ EXP 利用代码
截至分析时，Exploit-DB 未收录该 CVE 的公开利用代码。可利用上述 PoC 进行验证，或关注 Exploit-DB 更新。
🕵️ 检测指纹
当前规则库未收录针对该 CVE 的专用检测规则。建议：
- 根据漏洞根因编写 Nuclei 检测模板
- 在 WAF/IDS 中配置针对漏洞特征的规则
- 关注漏洞指纹库更新
🤖 本文由漏洞情报系统自动聚合生成 · 2026-09-03 02:07 · 数据源: NVD/GitHub-Advisory/OSV/CISA-KEV/Exploit-DB/PoC-in-GitHub + 检测规则库