将两者串联：未认证攻击者向任意生成端点提供 x-base-url: http://169.254.169.254/latest/meta-data/iam/security-credentials/，服务器便会获取云 IAM 角色凭据并在响应中返回。无需事先拥有账户、无需令牌、无需本地立足点。

根本原因

该中间件是所有 API 路由的唯一认证关口。当 ACCESS_CODE 未设置时——即 .env.example 所规定的默认状态——对每个路由的每个请求都会立即通过。没有回退机制、没有发出警告、没有替代认证检查。fail-open 是无条件且静默的。这使 70 个 API 端点暴露给任何未认证调用者，包括生成、持久化、媒体代理、提取和 AI 执行路由。

lib/server/ssrf-guard.ts 中的 validateUrlForSSRF 函数已通过 ALLOW_LOCAL_NETWORKS 正确处理了特定环境的例外情况。每个路由处理器中的 NODE_ENV 门控作为开发模式便利措施完全是多余的，但作为安全边界却是灾难性的：它在 staging、preview、CI/CD 以及未显式将 NODE_ENV 设置为 'production' 的自托管部署中全局禁用了 SSRF 验证。

概念验证

步骤 1 - 枚举 IMDS 角色

预期响应（IMDS 透传）：

步骤 2 - 窃取完整 IAM 凭据

预期响应：

步骤 3 - 利用凭据

变体 - 内部服务转向（Redis、Postgres）

攻击向量

前置条件：

• 应用部署在未设置 ACCESS_CODE 的环境中（默认配置）。
• NODE_ENV 未严格设置为 'production'（例如 staging、dev、自托管或配置错误的容器）。
• 服务器运行在具有可访问元数据端点的云托管基础设施上（例如未强制实施 IMDSv2 令牌跳数限制的 EC2）。

验证与防御性验证逻辑

为在不部署恶意载荷的情况下确认可达性并验证安全防御：

1. 认证关口追踪：
   • 当 process.env.ACCESS_CODE 为 undefined 时，middleware.ts 返回 NextResponse.next()。向任意受保护端点（例如 POST /api/generate/image）发送不带认证头的 HTTP 请求，会得到端点级响应（例如针对提供商配置的 400/401），而非 401 Access Code Required 拒绝。
2. SSRF 防护执行追踪：
   • 在 NODE_ENV="staging" 或 NODE_ENV="development" 下，检查 validateUrlForSSRF 是否被调用。由于 if (clientBaseUrl && process.env.NODE_ENV === 'production')，执行会跳过验证块并尝试与指定基础 URL 建立网络连接。
3. 防御性回归测试模型：
   • 一个设置 NODE_ENV='development' 并提供回环 URL http://127.0.0.1:9999 的模拟服务器或测试运行器，可验证请求是被以 INVALID_URL（403）拒绝，还是被允许继续进入网络传输。在未修补状态下，请求会尝试套接字连接；在已修补状态下，它会立即被以 HTTP 403 拒绝。

影响与爆炸半径

• 机密性：严重 - 对内部网络服务和云实例元数据的完全读取访问。在 AWS/GCP/Azure 部署中，这可导致 IAM 临时凭据、KMS 加密的配置机密、内部数据库连接字符串和内部 API 令牌被窃取。
• 完整性：高 - 使用窃取的云凭据，攻击者可以修改基础设施资源、更改 S3 存储桶内容、覆盖应用构件或篡改运行时数据库。
• 可用性：高 - 具有管理或终止权限的云凭据可被用于更改或删除云基础设施组件。
• 范围：已改变 - 该漏洞突破了应用边界，直接危及底层云基础设施和控制平面。
• 横向移动 - 窃取的 IAM 角色提供了进入内部 VPC 子网、跨账户角色以及从公共互联网无法访问的私有数据存储的转向路径。