---
title: "Axios absolute URL handling SSRF mapping"
published_date: "2025-03-07"
affected_versions:
  - ">= 1.0.0, < 1.8.2"
  - ">= 0.8.1, < 0.30.0"
fixed_versions:
  - "1.8.2"
  - "0.30.0"
severity: "high"
exploit_status: "See official advisory; treat as SSRF-prone request construction bug"
stack:
  - "Axios"
  - "Node.js"
  - "frontend-backend bridge"
attack_type:
  - "ssrf"
primary_source: "https://github.com/axios/axios/security/advisories/GHSA-jr5f-v2jv-69x6"
secondary_sources: []
target_types:
  - "lab-local"
  - "lab-public"
  - "authorized-third-party"
public_target_allowed: true
authorization_required: true
minimum_validation: "Use a lab service that joins user input with baseURL and validate only against controlled endpoints."
prohibited_use: "Do not turn this into arbitrary external SSRF probing."
---

# Axios 绝对 URL / 协议相对 URL SSRF 映射

## 事件层

- 官方来源: [GHSA-jr5f-v2jv-69x6](https://github.com/axios/axios/security/advisories/GHSA-jr5f-v2jv-69x6)
- 发布时间: 2025-03-07
- 影响范围: 1.0.0 至 1.8.2 之前，0.8.1 至 0.30.0 之前
- 修复版本: 1.8.2、0.30.0

该问题的核心是：应用以为 `baseURL` 限定了请求目标，但当调用方允许用户传入绝对 URL 或协议相对 URL 时，实际请求可能被重定向到意料之外的位置。

## 实验层

### 适用目标类型

- `lab-local`
- `lab-public`
- `authorized-third-party`

### 实验思路

1. 构造一个测试服务，内部代码类似 `axios.get(userInput, { baseURL: "http://internal-api.test" })`。
2. 在隔离环境中把 `userInput` 分别替换为相对路径、绝对 URL 和协议相对 URL。
3. 仅将目标指向你方控制的测试接收器，以验证请求是否越过预期边界。
4. 升级到修复版本后再次比对行为，并决定是否显式设置 `allowAbsoluteUrls`。

### 推荐的最小化验证

- 所有验证都指向你方控制的测试接收器，而不是外部第三方站点。
- 只记录是否越界、请求头差异和最终请求目的地。
- 如果应用位于公网测试环境，优先在 staging 或隔离租户中复现。

### 观测点

- `baseURL` 是否被绝对 URL 或 `//host/path` 绕过
- 服务端转发层、代理层和 allowlist 是否进一步放大风险
- 是否有令牌、内部头或源地址信息随请求一并泄露

## 回填建议

- 将命中的代码模式加入依赖审查清单。
- 对内部 HTTP 客户端封装统一限制“绝对 URL 输入”和“协议相对 URL”。