mirror of
https://github.com/gelusus/wxvl.git
synced 2026-10-28 19:30:54 +00:00
正在获取URL...
chainreactors: 25 个URL BruceFeIix: 33 个URL Doonsec: 17 个URL 总共去重后: 42 个URL 智能网联汽车漏洞管理实践探索、【一周安全资讯0919】全国网安标委发布《人工智能安全治理框架3.0》；Telegram Desktop曝存储型XSS漏洞、CVE-2026-93435 redis-parser 拒绝服务漏洞、黑客攻陷OpenAI：两个漏洞让我们拿下ChatGPT控制权、AWS 严重漏洞使攻击者能够绕过端口转发限制并窃取 IAM 凭证、【已复现】WordPress 核心主题预览缺陷可导致RCE漏洞（Click2Shell）、国家信息安全漏洞共享平台认证！360揽获三项漏洞治理核心殊荣、众测复盘：从 APP 一条普通图片请求，挖掘外围服务器文件上传漏洞、专家解读 | 依法堵住网络“小设备”的安全大漏洞、
This commit is contained in:
test committed
1 parent
f4e9614d5c
commit
9e1f052750
10 files changed
+1576
-1
No files matched your search
@@ -26914,5 +26914,14 @@
|
||||
"https://mp.weixin.qq.com/s/kCNEL8eA7w9miTKTLpeclg": "伪造 Object Header：一次 C++ 解释器类型混淆漏洞利用分析",
|
||||
"https://mp.weixin.qq.com/s/6v00MkyOxvuIUnDB7DW8gw": "近期漏洞简单整理复现-showdoc∕Nacos∕JimuReport",
|
||||
"https://mp.weixin.qq.com/s/yf_HO1-2HGX26wLzNFgHtg": "信息安全漏洞周报【第092期】",
|
||||
"https://mp.weixin.qq.com/s/ok6WTTCgN2L3QPgsvmQVDg": "Docker Sandboxes曝严重逃逸漏洞，恶意代码可读写macOS主机文件"
|
||||
"https://mp.weixin.qq.com/s/ok6WTTCgN2L3QPgsvmQVDg": "Docker Sandboxes曝严重逃逸漏洞，恶意代码可读写macOS主机文件",
|
||||
"https://mp.weixin.qq.com/s/C7Z9cpxznj9o6Qu3rlwW4A": "智能网联汽车漏洞管理实践探索",
|
||||
"https://mp.weixin.qq.com/s/mooA-oI9oEqOEwYfQgS46g": "【一周安全资讯0919】全国网安标委发布《人工智能安全治理框架3.0》；Telegram Desktop曝存储型XSS漏洞",
|
||||
"https://mp.weixin.qq.com/s/wBnhLBZ4Kjwe6UOYMnQGFQ": "CVE-2026-93435 redis-parser 拒绝服务漏洞",
|
||||
"https://mp.weixin.qq.com/s/zdXAvMDq5trrV1om-OagzA": "黑客攻陷OpenAI：两个漏洞让我们拿下ChatGPT控制权",
|
||||
"https://mp.weixin.qq.com/s/Sw59H6HMs_Ogx9an7H-iBw": "AWS 严重漏洞使攻击者能够绕过端口转发限制并窃取 IAM 凭证",
|
||||
"https://mp.weixin.qq.com/s/gCzjmru9awQp-YrMH3MyPg": "【已复现】WordPress 核心主题预览缺陷可导致RCE漏洞（Click2Shell）",
|
||||
"https://mp.weixin.qq.com/s/A9XSM4sLw91lPYEo3_-nsw": "国家信息安全漏洞共享平台认证！360揽获三项漏洞治理核心殊荣",
|
||||
"https://mp.weixin.qq.com/s/8sEpo2P5dHyXqAnHjGOzsQ": "众测复盘：从 APP 一条普通图片请求，挖掘外围服务器文件上传漏洞",
|
||||
"https://mp.weixin.qq.com/s/1_ALUqD3yoiOV3tuxWOjLw": "专家解读 | 依法堵住网络“小设备”的安全大漏洞"
|
||||
}
|
||||
@@ -0,0 +1,28 @@
|
||||
# AWS 严重漏洞使攻击者能够绕过端口转发限制并窃取 IAM 凭证
|
||||
原创 ZM
|
||||
ZM 暗镜 2026-09-18 22:00
|
||||
|
||||
WS Systems Manager (SSM) 代理中的一个严重漏洞可能允许授权攻击者绕过会话管理器端口转发限制，访问链路本地服务，并窃取分配给Amazon EC2 实例的临时 IAM 凭证。
|
||||
|
||||
该问题被追踪为 CVE-2026-89049，影响 AWS Systems Manager Agent 版本早于 3.3.4851.0。GitHub 安全公告 GHSA-w9jw-h72g-6hxc3 将该漏洞分类为严重漏洞，其 CVSS v3.1 评分反映了网络可访问性、攻击复杂性低、权限要求低、无需用户交互以及影响大等特点。
|
||||
|
||||
AWS-StartPortForwardingSessionToRemoteHostAWS Session Manager 的功能存在漏洞。
|
||||
|
||||
SSM Agent 在托管的 AWS 节点上运行，使管理员和授权用户能够建立远程管理会话，而无需将 SSH 或 RDP 服务直接暴露给互联网。
|
||||
|
||||
会话管理器的远程主机端口转发功能包含一些限制，旨在防止用户将流量隧道传输到链路本地地址。
|
||||
|
||||
这些地址在 AWS 环境中尤其敏感，因为EC2 实例元数据服务 (IMDS)通常可以通过链路本地地址访问169.254.169.254。
|
||||
|
||||
根据 AWS 的说法，SSM 代理没有正确验证被阻止目标地址的等效表示形式。
|
||||
|
||||
攻击者可以使用替代的 IP 地址表示来规避拒绝列表，导致代理与本应被阻止的链路本地端点建立连接。
|
||||
|
||||
该漏洞被归类为 CWE-918（服务器端请求伪造）和 CWE-1289（输入中不安全等价性的验证不当）。该漏洞实际上会将托管实例变成一个代理，使其能够代表会话管理器用户访问内部目标。
|
||||
|
||||
已通过身份验证且拥有启动远程主机端口转发会话权限的主体可以利用此漏洞查询实例元数据服务。如果受影响的 EC2 实例附加了 IAM 角色，攻击者可以获取该角色的临时 AWS 访问凭证。
|
||||
|
||||
这些凭证可以在被入侵实例之外使用，以发起实例配置文件 IAM 策略允许的 AWS API 调用。因此，实际影响很大程度上取决于附加到 EC2 角色的权限。
|
||||
|
||||
例如，具有读取 Amazon S3 存储桶、检索 AWS Secrets Manager 值、枚举 IAM 资源或访问数据库权限的实例配置文件可能会为攻击者提供一条通往更大范围云账户入侵的途径。
|
||||
|
||||
@@ -0,0 +1,206 @@
|
||||
# CVE-2026-93435 redis-parser 拒绝服务漏洞
|
||||
撅人 2026-09-18 16:00
|
||||
|
||||
|
||||
|
||||
VulnCheck 于 2026 年 9 月 17 日发布了编号为 **CVE-2026-93435**
|
||||
的安全公告。该漏洞存在于 Node.js 生态的 **redis-parser**
|
||||
库中，恶意 Redis 服务端可通过构造特制的 RESP 字节流，触发解析器无限递归，最终导致客户端 Node.js 进程崩溃。
|
||||
|
||||
CVSS 4.0 基础评分 **8.7 分**
|
||||
，严重等级评定为 **High**
|
||||
。该漏洞由 PayPal 网络安全团队发现并报告。目前暂无在野利用，暂无官方修复版本。
|
||||
|
||||
1
|
||||
|
||||
漏洞速览
|
||||
|
||||
**CVE 编号**
|
||||
CVE-2026-93435
|
||||
|
||||
**漏洞类型**
|
||||
CWE-674 Uncontrolled Recursion（不受控递归）
|
||||
|
||||
**影响产品**
|
||||
redis-parser（NodeRedis/node-redis-parser npm 包）
|
||||
|
||||
**安全等级**
|
||||
High（CVSS 4.0 基础评分 8.7）
|
||||
|
||||
**影响级别**
|
||||
仅可用性（Availability: High），无机密性和完整性影响
|
||||
|
||||
**受影响版本**
|
||||
redis-parser <= 3.0.0（所有版本至 3.0.0）
|
||||
|
||||
**披露时间**
|
||||
2026-09-17（VulnCheck 安全公告发布日）
|
||||
|
||||
**补丁情况**
|
||||
暂无官方修复版本
|
||||
|
||||
**利用情况**
|
||||
暂无在野利用
|
||||
|
||||
2
|
||||
|
||||
漏洞概述
|
||||
|
||||
redis-parser 是 NodeRedis 项目下的 Redis RESP 协议解析器，被 node-redis 和 ioredis 等主流 Node.js Redis 客户端库广泛依赖。它负责将 Redis 服务端返回的 RESP（REdis Serialization Protocol）字节流解析为 JavaScript 对象。
|
||||
|
||||
该漏洞的根因在于解析器处理 **RESP 数组类型**
|
||||
时存在不受控递归。RESP 协议允许数组嵌套——即数组元素本身也可以是数组。解析器在遇到数组头（如 ***2\r\n*2\r\n*2\r\n...**
|
||||
）时会递归调用解析函数。当攻击者构造一个包含大量重复数组头的 RESP 字节流时，递归深度无上限增长，最终**耗尽 V8 引擎的调用栈**
|
||||
。
|
||||
|
||||
栈溢出触发 V8 抛出 **RangeError**
|
||||
。关键问题在于，这个异常会**绕过 redis-parser 的错误处理回调**
|
||||
——RangeError 作为未捕获异常直接终止 Node.js 进程。这意味着 redis-parser 的 error 事件、try/catch 块、甚至 uncaughtException 处理器都无法阻止进程崩溃。
|
||||
|
||||
该漏洞的特殊之处在于攻击方向是**服务端攻击客户端**
|
||||
。通常安全关注点在客户端攻击服务端，但此漏洞允许恶意 Redis 服务端反向攻击连接它的客户端。攻击者可以搭建恶意 Redis 实例，诱导目标应用连接后发送精心构造的 RESP 响应来触发崩溃。
|
||||
|
||||
截至公告发布，该漏洞暂无在野利用记录，redis-parser 官方也尚未发布修复版本。
|
||||
|
||||
3
|
||||
|
||||
CVSS 评分详解
|
||||
|
||||
该漏洞采用 CVSS 4.0 评分标准，向量字符串：**CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N**
|
||||
|
||||
**攻击向量（AV）**
|
||||
Network — 攻击者可通过网络远程发起攻击
|
||||
|
||||
**攻击复杂度（AC）**
|
||||
Low — 无需特殊条件，构造 RESP 字节流简单直接
|
||||
|
||||
**攻击要求（AT）**
|
||||
None — 无需特定攻击前置条件
|
||||
|
||||
**所需权限（PR）**
|
||||
None — 攻击者无需认证权限，仅需搭建恶意 Redis 实例
|
||||
|
||||
**用户交互（UI）**
|
||||
None — 无需用户交互，客户端自动解析服务端响应
|
||||
|
||||
**机密性影响（VC）**
|
||||
None — 不影响数据机密性
|
||||
|
||||
**完整性影响（VI）**
|
||||
None — 不影响数据完整性
|
||||
|
||||
**可用性影响（VA）**
|
||||
High — 完全破坏可用性，Node.js 进程立即崩溃
|
||||
|
||||
**系统机密性（SC）**
|
||||
None — 无系统级机密性影响
|
||||
|
||||
**系统完整性（SI）**
|
||||
None — 无系统级完整性影响
|
||||
|
||||
**系统可用性（SA）**
|
||||
None — 无系统级可用性影响
|
||||
|
||||
4
|
||||
|
||||
利用条件与攻击路径
|
||||
|
||||
该漏洞的利用需要满足以下前提：
|
||||
|
||||
第一，目标应用使用 **redis-parser <= 3.0.0**
|
||||
作为 Redis 客户端的 RESP 解析器。这包括直接依赖 redis-parser 的项目，以及通过 node-redis 或 ioredis 间接依赖的项目。ioredis 在 issue [#2108]()
|
||||
中确认受此问题影响。
|
||||
|
||||
第二，目标应用需要连接到攻击者控制的 Redis 实例。攻击者可以通过**DNS 劫持、中间人攻击、容器环境下注入恶意 Redis 地址**
|
||||
等方式诱导客户端连接。在 SSRF 场景中，应用从用户输入获取 Redis 连接地址时尤其危险。
|
||||
|
||||
**攻击路径总结：**
|
||||
攻击者搭建恶意 Redis 实例 → 诱导目标 Node.js 应用连接（DNS 劫持 / MITM / SSRF）→ 客户端发送 Redis 命令 → 恶意服务端返回构造的 RESP 字节流（大量嵌套数组头 *N\r\n）→ redis-parser 递归解析耗尽 V8 调用栈 → 抛出未捕获 RangeError → Node.js 进程崩溃
|
||||
|
||||
5
|
||||
|
||||
修复建议
|
||||
|
||||
截至公告发布日，redis-parser 官方**尚未发布修复版本**
|
||||
。该库的最后更新可追溯至较早期版本，维护活跃度较低。以下是临时缓解措施建议：
|
||||
|
||||
**当前建议**
|
||||
持续关注 redis-parser GitHub 仓库和 VulnCheck 公告，待修复版本发布后及时更新。如项目使用 ioredis，关注 ioredis 仓库 issue [#2108]()
|
||||
的后续修复进展。
|
||||
|
||||
**临时缓解措施：**
|
||||
|
||||
· 仅连接**可信的 Redis 实例**
|
||||
，禁止从用户输入动态指定 Redis 连接地址，防止 SSRF 攻击向量
|
||||
|
||||
· 在连接 Redis 前使用 TLS 加密传输，防止中间人篡改 RESP 响应
|
||||
|
||||
· 对 Redis 连接地址做白名单校验，仅允许预配置的主机名和端口
|
||||
|
||||
· 使用进程管理工具（PM2、Docker restart policy）实现自动重启，降低 DoS 影响
|
||||
|
||||
· 评估替换为其他 Redis 客户端库的可行性，如直接使用 Redis 官方维护的 node-redis v4（自带独立解析器，不依赖 redis-parser）
|
||||
|
||||
· 在网络层限制 Redis 端口的出站连接，仅允许访问已知 Redis 集群 IP
|
||||
|
||||
· 对关键服务实施熔断和降级策略，当 Redis 连接异常时自动降级而非进程崩溃
|
||||
|
||||
6
|
||||
|
||||
漏洞时间线
|
||||
|
||||
**2026-09-17**
|
||||
|
||||
VulnCheck 发布安全公告，CVE-2026-93435 详情公开
|
||||
|
||||
**2026-09-18**
|
||||
|
||||
ioredis issue [#2108]()
|
||||
讨论持续，本文发布
|
||||
|
||||
**待定**
|
||||
|
||||
redis-parser 官方修复版本尚未发布
|
||||
|
||||
7
|
||||
|
||||
致谢与参考
|
||||
|
||||
该漏洞由 **Wayde Shi**
|
||||
（PayPal Cyber Security Team）发现并报告。VulnCheck 在公告中对其协调披露行为表示感谢。
|
||||
|
||||
**参考链接：**
|
||||
|
||||
· VulnCheck 安全公告：
|
||||
|
||||
https://www.vulncheck.com/advisories/redis-parser-through-3.0.0-denial-of-service-via-unbounded-recursion
|
||||
|
||||
· redis-parser GitHub 仓库：
|
||||
|
||||
https://github.com/NodeRedis/node-redis-parser
|
||||
|
||||
· 漏洞代码位置（parser.js [#L204]()
|
||||
-L213）：
|
||||
|
||||
https://github.com/NodeRedis/node-redis-parser/blob/701655430f5f7d9ca00892a02f7eefcbc1193a98/lib/parser.js[#L204]()
|
||||
-L213
|
||||
|
||||
· 漏洞代码位置（parser.js [#L291]()
|
||||
-L306）：
|
||||
|
||||
https://github.com/NodeRedis/node-redis-parser/blob/701655430f5f7d9ca00892a02f7eefcbc1193a98/lib/parser.js[#L291]()
|
||||
-L306
|
||||
|
||||
· ioredis issue [#2108]()
|
||||
：
|
||||
|
||||
https://github.com/redis/ioredis/issues/2108
|
||||
|
||||
· CVE 记录：
|
||||
|
||||
https://www.cve.org/CVERecord?id=CVE-2026-93435
|
||||
|
||||
本文信息来源为 VulnCheck 安全公告（vulncheck.com）及 GitHub 公开 issue/代码仓库，仅供安全研究与防御参考。redis-parser 当前暂无官方修复版本，建议关注 GitHub 仓库后续更新并采取临时缓解措施。
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,193 @@
|
||||
# 【一周安全资讯0919】全国网安标委发布《人工智能安全治理框架3.0》；Telegram Desktop曝存储型XSS漏洞
|
||||
聚铭网络 2026-09-19 03:00
|
||||
|
||||
****
|
||||
****
|
||||
**WEEKLY NEWS**
|
||||
|
||||
**每周安全资讯**
|
||||
|
||||
**新鲜资讯热点都在这里**
|
||||
|
||||
|
||||
|
||||
**要闻速览**
|
||||
|
||||
|
||||
**1**
|
||||
|
||||
**全国网安标委发布《人工智能安全治理框架3.0》**
|
||||
|
||||
**2**
|
||||
|
||||
**《电子产品信息清除技术要求》强制性国家标准实施配套的3项标准实践指南发布**
|
||||
|
||||
**3**
|
||||
|
||||
**Telegram Desktop曝存储型XSS漏洞**
|
||||
|
||||
**4**
|
||||
|
||||
**黑客利用WooCommerce插件漏洞上传PHP后门**
|
||||
|
||||
**5**
|
||||
|
||||
**泰国最大网络运营商3BB遭工具投毒，多台内网服务器被远控窃取数据**
|
||||
|
||||
**6**
|
||||
|
||||
**日本政府共享平台遭非0Day VPN漏洞入侵，24.6万条记录面临泄露风险**
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**一周政策要闻**
|
||||
|
||||
|
||||
|
||||
|
||||
**全国网安标委发布《人工智能安全治理框架3.0》**
|
||||
|
||||
|
||||
|
||||
|
||||
2026年9月15日，全国网络安全标准化技术委员会秘书处正式发布《人工智能应用安全指引 总则》等4项网络安全标准实践指南（网安秘字〔2026〕118号）。
|
||||
|
||||
本次发布的人工智能应用安全指引系列文件分为通用文件与行业领域文件两类。其中，《总则》作为通用文件，提供通用性安全指导，适用于各行业领域开展人工智能应用活动；教育、卫生健康、广播电视和网络视听3项行业领域文件，则为特定行业提供针对性安全实践指引。
|
||||
|
||||
该系列指南的出台，旨在有效应对人工智能快速发展应用带来的新风险新挑战，安全释放人工智能应用需求。
|
||||
|
||||
|
||||
信息来源：全国网络安全标准化技术委员会
|
||||
|
||||
https://www.tc260.org.cn/tc260/xwdt1/202609/d513a007d04347f58e483fabaefb34b8.shtml
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**《电子产品信息清除技术要求》强制性国家标准实施配套的3项标准实践指南发布**
|
||||
|
||||
|
||||
|
||||
|
||||
9月15日，在山东济南举办的“2026年国家网络安全宣传周——电子产品信息清除分论坛”上，3项网络安全标准实践指南正式发布，分别为《半导体存储介质块擦除技术指引》《电子产品回收过程中的信息清除管理指引》和《移动智能终端信息清除技术指引》。
|
||||
|
||||
这3项指南由全国网安标委秘书处在中央网信办、工业和信息化部等部门指导下，组织30余家存储芯片厂商、电子产品制造商、回收经营者和第三方机构等编制，旨在配套GB 46864-2025《数据安全技术 电子产品信息清除技术要求》强制性国家标准的落地实施，规范电子产品信息清除活动。
|
||||
|
||||
|
||||
消息来源：国家互联网信息办公室
|
||||
|
||||
https://www.cac.gov.cn/2026-09/17/c_1791397055656100.htm
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**业内新闻速览**
|
||||
|
||||
|
||||
|
||||
|
||||
**Telegram Desktop曝存储型XSS漏洞**
|
||||
|
||||
|
||||
|
||||
|
||||
安全研究人员披露，Telegram Desktop聊天导出功能存在一项存储型跨站脚本（Stored XSS）漏洞，攻击者可利用精心构造的Bot消息，将恶意JavaScript代码隐藏在导出的HTML聊天文件中，进而窃取用户聊天历史及相关元数据。
|
||||
|
||||
漏洞源于导出流程对消息内容（尤其是内联键盘按钮文本）过滤不足，利用该漏洞需要用户交互，即导出并打开HTML文件。研究人员建议用户尽快升级Telegram Desktop至修复版本，并重新生成此前导出的HTML文件；企业也应加强即时通信工具导出文件的安全管理，避免在受信任环境外打开来源不明的HTML文件。
|
||||
|
||||
|
||||
消息来源：安全牛
|
||||
|
||||
[网安标委发布《人工智能安全治理框架3.0》，风险分类与技术应对措施同步更新；CNVD发布2026年第36期漏洞周报| 牛览](https://mp.weixin.qq.com/s?__biz=MjM5Njc3NjM4MA==&mid=2651142730&idx=2&sn=1b5184c30967d3d8dc83d1996adfe06b&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**黑客利用WooCommerce插件漏洞上传PHP后门**
|
||||
|
||||
|
||||
|
||||
|
||||
9月15日，Wordfence发布高危预警：WordPress插件WooCommerce Wholesale Lead Capture存在严重任意文件上传漏洞（CVE-2026-27540，CVSS 9.8），影响2.0.3.1及之前的所有版本。未授权攻击者可借插件AJAX上传逻辑（入口wwlc_file_upload_handler）缺少文件类型校验，直接上传PHP Web Shell等恶意脚本，实现远程代码执行，进而窃取配置和数据库凭据、劫持后台，甚至横向控制同主机其他站点。
|
||||
|
||||
该漏洞已被大规模在野利用：自2026年6月起利用尝试超10万次，最近24小时仍记录到99次实时攻击。专家
|
||||
建议：立即升级插件至最新版；无法升级则停用插件并禁止上传目录对外访问；检查wp-content/uploads、plugins及临时目录中是否有异常php/phtml/jsp/asp文件；审计管理员账号、配置文件与日志是否被篡改。企业站点若仍在使用受影响版本，应尽快停用并升级，降低攻击面。
|
||||
|
||||
|
||||
消息来源：安全圈
|
||||
|
||||
[【安全圈】WooCommerce 批发插件曝 9.8 高危漏洞：未授权上传即成 PHP Web Shell](https://mp.weixin.qq.com/s?__biz=MzIzMzE4NDU1OQ==&mid=2652078970&idx=1&sn=79e2e22a1ea642c180b12f34e2d63115&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**泰国最大网络运营商3BB遭工具投毒，多台内网服务器被远控窃取数据**
|
||||
|
||||
|
||||
|
||||
|
||||
安全内参9月16日消息，泰国大型宽带运营商3BB遭针对性网络攻击，黑客滥用合法远程运维工具植入隐形后门，成功拿下内网服务器Root最高权限，横向渗透超55台内网设备，核心目标瞄准海量用户上网凭证。
|
||||
|
||||
攻击者通过恶意配置MeshCentral绕过安全审计，再用清理脚本清除日志、销毁工具，只留下驻留程序，实现无痕持久控权。站稳内网后，他们通过SSH密码喷洒、盗取数据库账号和SSH密钥、植入WebShell等方式扩大控制，并专门编写脚本靶向3BB的RADIUS认证数据库。目前仅证实数据库遭入侵，暂未确认数据泄露。此外，黑客服务器还留存3BB的VPN证书及Jasmine网络会话，而Jasmine与3BB共享基础设施，存在持续风险。
|
||||
|
||||
|
||||
消息来源：安全内参
|
||||
|
||||
[https://www.secrss.com/articles/93828](https://mp.weixin.qq.com/s?__biz=MjM5MDk1NzQzMQ==&mid=2654149820&idx=2&sn=b0b4028478e2517a92b62843bf33b426&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**日本政府共享平台遭非0Day VPN漏洞入侵，24.6万条记录面临泄露风险**
|
||||
|
||||
|
||||
|
||||
|
||||
近日，
|
||||
日本数字厅通报，其运营的政府共享服务平台GSS因VPN设备漏洞遭入侵，可能导致约24.6万名政府雇员、公职人员及外包人员的个人信息泄露。攻击者利用VPN漏洞突破网络边界，冒用一名运维人员账号进入内部系统并浏览大量文件。数字厅6月25日发现异常，7月9日确认攻击手段，当天封禁涉事账号并切断失陷设备外部通信，直到9月11日才对外公开。
|
||||
|
||||
可能泄露的数据包括约23.6万条姓名、23.1万个邮箱、9.4万个电话和约1000条实体地址，不包含My Number、金融账号或养老金编号。被利用的VPN漏洞属中危，并非0Day，攻击发生时厂商已发布补丁，但数字厅7月15日才告知隐私监管机构，称延迟是因溯源排查难度大。目前尚无数据被滥用的报告，但泄露信息可能被用于定向钓鱼和冒充数字厅的诈骗。
|
||||
|
||||
|
||||
消息来源：FREEBBUF
|
||||
https://www.freebuf.com/news/500863.html
|
||||
|
||||
|
||||
|
||||
**来源:本安全周报所推送内容由网络收集整理而来，仅用于分享，并不意味着赞同其观点或证实其内容的真实性，部分内容推送时未能与原作者取得联系，若涉及版权问题，烦请原作者联系我们，我们会尽快删除处理，谢谢！**
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**★**
|
||||
|
||||
|
||||
|
||||
**往期回顾**
|
||||
|
||||
|
||||
|
||||
**★**
|
||||
|
||||
[](https://mp.weixin.qq.com/s?__biz=MzIzMDQwMjg5NA==&mid=2247492709&idx=1&sn=d13d438443bd9246e1020f605120d860&chksm=e8b15a44dfc6d3525bd1ff3c187ac55be18b1f9ab41c00916b75d128ae158dc2502d7956e794&scene=21#wechat_redirect)
|
||||
|
||||
[](https://mp.weixin.qq.com/s?__biz=MzIzMDQwMjg5NA==&mid=2247508361&idx=1&sn=4ac35feac3090b51dbee15d6bf30f9a0&scene=21#wechat_redirect)
|
||||
|
||||
[](https://mp.weixin.qq.com/s?__biz=MzIzMDQwMjg5NA==&mid=2247508847&idx=1&sn=d9b1d6392e2c912e34546929e0ed905c&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,148 @@
|
||||
# 【已复现】WordPress 核心主题预览缺陷可导致RCE漏洞（Click2Shell）
|
||||
原创 360漏洞研究院
|
||||
360漏洞研究院 360漏洞研究院 2026-09-19 06:54
|
||||
|
||||
WordPress 核心主题预览功能存在安全缺陷，特制链接可触发主题自动安装和预览。
|
||||
|
||||
|
||||
漏洞被命名为 Click2Shell。攻击者无需拥有站点账号，但需要诱导已登录且具备主题安装权限的管理员访问恶意链接。与第三方主题漏洞结合后，可实现服务器端 PHP 代码执行。
|
||||
|
||||
|
||||
**利用前置条件：**
|
||||
- 管理员已登录 WordPress 后台，并访问攻击者构造的链接（UI:R）
|
||||
|
||||
- 目标站点 WordPress 版本低于 7.1.1
|
||||
|
||||
目前 **360漏洞挖掘智能体已成功复现该漏洞**
|
||||
。本文包含完整影响范围、正式修复方案、技术原理与复现细节。
|
||||
|
||||
|
||||
<table><tbody><tr style="box-sizing: border-box;"><td colspan="4" data-colwidth="100.0000%" width="100.0000%" style="border-width: 1px;border-color: rgb(100, 130, 228);border-style: solid;background-color: rgb(100, 130, 228);box-sizing: border-box;padding: 0px;"><section style="text-align: center;color: rgb(255, 255, 255);box-sizing: border-box;"><p style="margin: 0px;padding: 0px;box-sizing: border-box;"><strong style="box-sizing: border-box;"><span leaf="">漏洞概述</span></strong></p></section></td></tr><tr style="box-sizing: border-box;"><td data-colwidth="24.0000%" width="24.0000%" style="border-width: 1px;border-color: rgb(100, 130, 228);border-style: solid;box-sizing: border-box;padding: 0px;"><section style="font-size: 12px;color: rgb(0, 0, 0);padding: 0px 8px;box-sizing: border-box;"><p style="white-space: normal;margin: 0px;padding: 0px;box-sizing: border-box;"><strong style="box-sizing: border-box;"><span leaf="">漏洞名称</span></strong></p></section></td><td colspan="3" data-colwidth="76.0000%" width="76.0000%" style="border-width: 1px;border-color: rgb(100, 130, 228);border-style: solid;box-sizing: border-box;padding: 0px;"><section style="font-size: 12px;padding: 0px 8px;box-sizing: border-box;"><p style="white-space: normal;margin: 0px;padding: 0px;box-sizing: border-box;"><span style="box-sizing: border-box;"><span leaf="">WordPress 主题预览远程代码执行漏洞</span></span></p></section></td></tr><tr style="box-sizing: border-box;"><td data-colwidth="24.0000%" width="24.0000%" style="border-width: 1px;border-color: rgb(100, 130, 228);border-style: solid;box-sizing: border-box;padding: 0px;"><section style="font-size: 12px;color: rgb(0, 0, 0);padding: 0px 8px;box-sizing: border-box;"><p style="white-space: normal;margin: 0px;padding: 0px;box-sizing: border-box;"><strong style="box-sizing: border-box;"><span leaf="">漏洞编号</span></strong></p></section></td><td colspan="3" data-colwidth="76.0000%" width="76.0000%" style="border-width: 1px;border-color: rgb(100, 130, 228);border-style: solid;box-sizing: border-box;padding: 0px;"><section style="font-size: 12px;padding: 0px 8px;box-sizing: border-box;"><p style="white-space: normal;margin: 0px;padding: 0px;box-sizing: border-box;"><span leaf="">LDYVUL-2026-00215704</span></p></section></td></tr><tr style="box-sizing: border-box;"><td data-colwidth="24.0000%" width="24.0000%" style="border-width: 1px;border-color: rgb(100, 130, 228);border-style: solid;box-sizing: border-box;padding: 0px;"><section style="font-size: 12px;color: rgb(0, 0, 0);padding: 0px 8px;box-sizing: border-box;"><p style="white-space: normal;margin: 0px;padding: 0px;box-sizing: border-box;"><strong style="box-sizing: border-box;"><span leaf="">公开时间</span></strong></p></section></td><td data-colwidth="28.0000%" width="28.0000%" style="border-width: 1px;border-color: rgb(100, 130, 228);border-style: solid;box-sizing: border-box;padding: 0px;"><section style="font-size: 12px;padding: 0px 8px;box-sizing: border-box;"><p style="white-space: normal;margin: 0px;padding: 0px;box-sizing: border-box;"><span leaf="">2026-09-18</span></p></section></td><td data-colwidth="28.0000%" width="28.0000%" style="border-width: 1px;border-color: rgb(100, 130, 228);border-style: solid;box-sizing: border-box;padding: 0px;"><section style="font-size: 12px;padding: 0px 8px;box-sizing: border-box;"><p style="white-space: normal;margin: 0px;padding: 0px;box-sizing: border-box;"><strong style="box-sizing: border-box;"><span style="color: rgb(0, 0, 0);box-sizing: border-box;"><span leaf="">POC状态</span></span></strong></p></section></td><td data-colwidth="20.0000%" width="20.0000%" style="border-width: 1px;border-color: rgb(100, 130, 228);border-style: solid;box-sizing: border-box;padding: 0px;"><section style="font-size: 12px;padding: 0px 8px;color: rgb(100, 130, 228);box-sizing: border-box;"><p style="white-space: normal;margin: 0px;padding: 0px;box-sizing: border-box;"><strong style="box-sizing: border-box;"><span leaf="">已公开</span></strong></p></section></td></tr><tr style="box-sizing: border-box;"><td data-colwidth="24.0000%" width="24.0000%" style="border-width: 1px;border-color: rgb(100, 130, 228);border-style: solid;box-sizing: border-box;padding: 0px;"><section style="font-size: 12px;color: rgb(0, 0, 0);padding: 0px 8px;box-sizing: border-box;"><p style="white-space: normal;margin: 0px;padding: 0px;box-sizing: border-box;"><strong style="box-sizing: border-box;"><span leaf="">漏洞类型</span></strong></p></section></td><td data-colwidth="28.0000%" width="28.0000%" style="border-width: 1px;border-color: rgb(100, 130, 228);border-style: solid;box-sizing: border-box;padding: 0px;"><section style="font-size: 12px;padding: 0px 8px;box-sizing: border-box;"><p style="white-space: normal;margin: 0px;padding: 0px;box-sizing: border-box;"><span leaf="">代码注入</span></p></section></td><td data-colwidth="28.0000%" width="28.0000%" style="border-width: 1px;borderLine truncated
|
||||
|
||||
|
||||
**01**
|
||||
|
||||
**漏洞影响范围**
|
||||
|
||||
|
||||
|
||||
受影响的 WordPress 核心版本：
|
||||
|
||||
WordPress < 7.1.1
|
||||
|
||||
|
||||
**02**
|
||||
|
||||
**修复建议**
|
||||
|
||||
|
||||
|
||||
**正式防护方案**
|
||||
|
||||
升级 WordPress 至 7.1.1 或更高版本。
|
||||
|
||||
|
||||
**03**
|
||||
|
||||
**漏洞描述**
|
||||
|
||||
|
||||
|
||||
近日，安全研究团队公开了 WordPress 核心中的一处主题预览漏洞，并将其命名为 Click2Shell。主题预览逻辑将 URL 中的主题标识未经适当转义拼接到 jQuery 选择器中，攻击者可改变选择目标，使页面自动触发安装操作。官方补丁对输入进行选择器转义，并限制匹配对象为主题卡片。
|
||||
|
||||
|
||||
核心缺陷能够安装攻击者指定的 WordPress.org 官方目录主题。研究方通过 Mobile Repair Zone 2.5.4 主题演示了后续攻击：未启用的主题仍可在预览时加载，其插件安装接口缺少 nonce 和权限校验，进而被用于加载攻击者提供的 PHP。代码以站点 PHP 进程权限执行，可能导致站点数据泄露、内容篡改及站点被接管。
|
||||
|
||||
|
||||
**04**
|
||||
|
||||
**漏洞复现**
|
||||
|
||||
|
||||
|
||||
360 漏洞研究院已成功复现 WordPress 主题预览注入漏洞（Click2Shell），构造并发送对应 Payload，成功验证该漏洞可导致远程代码执行，最终获取到目标站点 Shell 权限。
|
||||
|
||||
|
||||
|
||||
发送Payload
|
||||
|
||||
|
||||
|
||||
Click2Shell WordPress 核心主题预览缺陷致 RCE 漏洞
|
||||
|
||||
|
||||
**05**
|
||||
|
||||
**产品侧支持情况**
|
||||
|
||||
|
||||
|
||||
**360安全智能体：**
|
||||
支持该漏洞攻击的智能分析**。**
|
||||
|
||||
**360测绘云 Quake**
|
||||
：默认支持该产品的指纹识别。
|
||||
|
||||
**360高级持续性威胁预警系统**
|
||||
：预计 2026年9月20日发布规则更新包，支持该漏洞利用行为的检测。
|
||||
|
||||
**360资产与漏洞检测管理系统**
|
||||
：预计 2026年9月20日发布规则更新包，支持该漏洞利用行为的检测。
|
||||
**本地安全大脑**
|
||||
：默认支持该漏洞的PoC检测。
|
||||
|
||||
|
||||
**06**
|
||||
|
||||
**时间线**
|
||||
|
||||
|
||||
|
||||
2026年9月19日，360漏洞研究院发布本安全风险通告。
|
||||
|
||||
|
||||
**07**
|
||||
|
||||
参考链接
|
||||
|
||||
|
||||
|
||||
https://pwn.ai/blog/click2shell
|
||||
|
||||
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://core.trac.wordpress.org/changeset/63664
|
||||
|
||||
|
||||
08
|
||||
|
||||
更多漏洞情报
|
||||
|
||||
|
||||
|
||||
“扫描下方二维码，进入公众号粉丝交流群。更多一手网安资讯、漏洞预警、技术干货和技术交流等您参与！”
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
建议您订阅360数字安全-漏洞情报服务，获取更多漏洞情报详情以及处置建议，让您的企业远离漏洞威胁。
|
||||
|
||||
|
||||
邮箱：360VRI@360.cn
|
||||
|
||||
网址：https://vi.loudongyun.360.net
|
||||
|
||||
|
||||
|
||||
“洞”悉网络威胁，守护数字安全
|
||||
|
||||
|
||||
**关于我们**
|
||||
|
||||
|
||||
360 漏洞研究院，隶属于360数字安全集团。其成员常年入选谷歌、微软、华为等厂商的安全精英排行榜, 并获得谷歌、微软、苹果史上最高漏洞奖励。研究院是中国首个荣膺Pwnie Awards“史诗级成就奖”，并获得多个Pwnie Awards提名的组织。累计发现并协助修复谷歌、苹果、微软、华为、高通等全球顶级厂商CVE漏洞3000多个，收获诸多官方公开致谢。研究院也屡次受邀在BlackHat，Usenix Security，Defcon等极具影响力的工业安全峰会和顶级学术会议上分享研究成果，并多次斩获信创挑战赛、天府杯等顶级黑客大赛总冠军和单项冠军。研究院将凭借其在漏洞挖掘和安全攻防方面的强大技术实力，帮助各大企业厂商不断完善系统安全，为数字安全保驾护航，筑造数字时代的安全堡垒。
|
||||
|
||||
|
||||
@@ -0,0 +1,40 @@
|
||||
# 专家解读 | 依法堵住网络“小设备”的安全大漏洞
|
||||
公安部网安局 2026-09-18 23:00
|
||||
|
||||
|
||||
|
||||
|
||||
2026年，公安机关深入开展“护网—2026”专项工作，围绕网络安全、数据安全、信息安全重点任务，依托国家网络与信息安全信息通报机制，扎实推进网络空间安全保护和综合治理体系建设，集中整治一批突出风险问题，发现清理一批漏洞隐患，侦办一批不履行保护义务的行政案件，有力维护了关键信息基础设施、重要网络系统和数据安全。2026年9月17日，公安部网安局公布10起“护网—2026”专项工作中的
|
||||
网络安全行政执法典型案例。（[公安机关深入开展“护网—2026”专项工作 全力强化网络空间安全保护和综合治理](https://mp.weixin.qq.com/s?__biz=MzU0MTA3OTU5Ng==&mid=2247583775&idx=1&sn=b514938642fc56b1095a49b02357eec1&scene=21#wechat_redirect)
|
||||
）本期邀请中国社会科学院法学研究所支振锋研究员
|
||||
解读案
|
||||
例二“
|
||||
安徽芜湖某单位不履行网络安全保护义务案
|
||||
”。
|
||||
|
||||
基本案情
|
||||
|
||||
|
||||
2026年4月，安徽芜湖公安机关接有关部门线索通报，辖区某IP地址存在异常和安全隐患。经查，该IP地址系当地某单位独立使用的通信组网IP。因该IP地址使用的路由器存在漏洞且设备同时开放管理端口等功能，导致被恶意软件控制。由于处置及时，未造成严重后果。目前，属地公安机关已依法责令该单位改正。
|
||||
|
||||
2026年4月，安徽芜湖公安机关在调查中发现，公交车站台上使用独立IP地址的电子站牌出现异常流量。问题出在路由器：出厂默认账号密码从未修改，弱口令漏洞赫然在列，Web管理端口、SSH远程端口、NAT穿透功能同时开放。恶意软件轻松进入，设备沦为被远程操控的“肉鸡”。所幸处置及时，未造成严重后果。但“未造成严重后果”不等于“没有违法”。这是一起典型的网络运营者未履行网络安全保护义务的行政执法案件。
|
||||
|
||||
类似风险并非孤例。国家互联网应急中心2026年2月预警显示，新型僵尸网络RCtea自2025年12月下旬活跃，专门攻击路由器、摄像头等物联网设备，通过Telnet暴力破解弱口令传播，仅2026年1月20日至25日，我国境内确认受感染设备达9827台。青海果洛州公安局2025年办理的案件中，某单位系统存在弱口令，极易泄露个人信息（含姓名、联系方式等），被督促整改后仍未采取必要技术措施，最终被行政警告。南充某行政单位OA系统也因弱口令和日志留存不足，被境外黑客组织入侵窃取信息。境外同样有教训：韩国丽水公交站台电子屏被入侵播放不雅视频，巴西库里蒂巴公交站台显示屏被控制播放色情内容。公交站牌虽小，一旦失守，关乎公共秩序与城市形象。
|
||||
|
||||
从法理看，该涉案单位作为国家机关，虽非电信运营商和一般的网络运营者，却对公交站牌独立通信组网具有实际运营、管理和支配能力。《网络安全法》规定，国家机关政务网络的运营者不履行本法规定的网络安全保护义务的，由其上级机关或者有关机关责令改正；对直接负责的主管人员和其他直接责任人员依法给予处分。因此，该机关就应承担《网络安全法》所要求的网络安全保护义务，要和其他网络运营者一样制定内部安全管理制度和操作规程，采取防范计算机病毒、网络攻击、网络侵入的技术措施，监测记录网络运行状态并留存日志不少于六个月等。未改默认密码，等于未采取防范侵入的技术措施；同时开放多个管理端口，等于未落实安全管理责任。该单位在上述环节的缺失，已使违法事实成立。处罚并不以实际危害后果为构成要件；后果有无，只影响处罚轻重。法律信号的指向十分清晰：网络安全不是“出了事再说”的软约束，而是必须前置履行的硬义务。
|
||||
|
||||
小设备为何屡成大漏洞？根源在于长期存在的“重建设、轻安全，重应用、轻管理”。公交站牌、摄像头、传感器等物联网终端，往往由基层单位建设，缺乏专业安全人员，运维外包又容易责任虚化。设备装好即用，密码不换、端口不关、日志不留、异常不察。攻击者恰恰偏爱这类“低垂的果实”。它们算力虽小，数量却大，一旦被僵尸网络收编，既能篡改公共信息，也能作为跳板攻击更重要的系统。公共电子屏连着城市治理的末梢，其安全具有明显的公共品属性，不能交由运气看守。
|
||||
|
||||
依法堵漏，需要运营者、监管者和技术提供方共同发力。运营者应落实“谁运营谁负责”，从改掉默认密码、关闭不必要端口、做好网络隔离、留存日志、建立监测和应急机制做起。监管者应把物联网设备纳入常态化安全检查，对通报线索一查到底，对拒不整改者依法亮剑。技术提供方则应在设备出厂时强制首次修改密码，默认关闭高风险远程功能。更重要的是，不能等公交站牌真的显示乱码、城市运行真的受阻，才想起那台无人问津的路由器。
|
||||
|
||||
网络空间的任何一个角落都是重要的。一台路由器的弱口令，可能撕开一座城市数字治理的大口子。依法堵住网络“小设备”的网络安全大漏洞，不是苛责基层，而是守护公共安全的基本功。唯有让每一台联网设备都有人负责、有制度约束、有法律兜底，城市数字化的底座才真正稳固。
|
||||
|
||||
|
||||
|
||||
|
||||
作者：
|
||||
支振锋
|
||||
中国社会科学院法学研究所研究员
|
||||
|
||||
来源：“公安三所网络安全法律研究中心”微信公众号
|
||||
|
||||
@@ -0,0 +1,697 @@
|
||||
# 众测复盘：从 APP 一条普通图片请求，挖掘外围服务器文件上传漏洞
|
||||
w4nk3r
|
||||
w4nk3r 神农Sec 2026-09-19 01:00
|
||||
|
||||
课程培训
|
||||
|
||||
扫码咨询
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
#
|
||||
|
||||
专注于SRC漏洞挖掘、红蓝对抗、渗透测试、代码审计JS逆向，CNVD和EDUSRC漏洞挖掘，以及工具分享、前沿信息分享、POC、EXP分享。不定期分享各种好玩的项目及好用的工具，欢迎关注。加内部圈子，文末有彩蛋（课程培训限时优惠）。
|
||||
#
|
||||
|
||||
文章作者：
|
||||
w4nk3r
|
||||
|
||||
文章来源：
|
||||
https://xz.aliyun.com/news/92800
|
||||
|
||||
01
|
||||
|
||||
0x1 众测复盘：从 APP 一条普通图片请求，挖掘外围服务器文件上传漏洞
|
||||
|
||||
## 0x00 前言
|
||||
|
||||
这次众测一开始其实并不顺利。
|
||||
|
||||
按照正常的测试流程，我先从目标暴露在公网的 Web 资产入手，对主要业务系统进行了信息收集和常规漏洞探测。
|
||||
|
||||
但这一轮下来，几个主要 Web 应用的防护都比较完善，并没有发现特别有价值的突破口。
|
||||
|
||||
眼看着时间一点点过去，我开始考虑换一个方向。
|
||||
|
||||
**Web 面没有明显突破口，并不意味着目标没有问题，也可能只是当前看到的攻击面还不够完整。**
|
||||
|
||||
既然如此，不如换一个观察角度
|
||||
|
||||
于是，我把测试重点转向了目标的 APP
|
||||
|
||||
而这次真正让我找到突破口的，并不是什么复杂的漏洞利用，而是一条看起来非常普通的图片资源请求
|
||||
## 0x01 从 Web 面转向 APP
|
||||
|
||||
在实际众测过程中，我比较习惯把目标理解成“一组业务资产”，而不是单独的一个域名。
|
||||
|
||||
一个目标除了主站 Web 应用之外，往往还可能存在：
|
||||
- APP
|
||||
|
||||
- 小程序
|
||||
|
||||
- H5
|
||||
|
||||
- API
|
||||
|
||||
- 图片/文件服务
|
||||
|
||||
- 对象存储
|
||||
|
||||
- 后台管理系统
|
||||
|
||||
- 第三方业务系统
|
||||
|
||||
- 历史遗留服务
|
||||
|
||||
这些系统虽然表面上属于同一个业务体系，但背后的服务器、域名、开发团队，甚至安全策略，都可能完全不同。
|
||||
|
||||
因此，当 Web 主站没有明显突破口时，与其继续盯着同一个入口反复测试，不如换一个观察角度。
|
||||
|
||||
这也是我这次转向 APP 流量分析的原因。
|
||||
## 0x02 APP 流量分析
|
||||
|
||||
这次测试使用的是华为鸿蒙手机。
|
||||
|
||||
由于设备无法 Root，我没有继续折腾模拟器，而是直接使用 Yakit 作为中间代理，通过手机 Wi-Fi 代理将 APP 的 HTTP/HTTPS 流量转发到测试机。
|
||||
|
||||
Yakit 监听地址设置为：
|
||||
```
|
||||
0.0.0.0
|
||||
|
||||
```
|
||||
|
||||
随后在手机 Wi-Fi 中配置对应的代理地址和端口。
|
||||
|
||||
配置完成后，打开 APP 并进行正常操作，就可以在 Yakit 的 MITM 模块中看到 APP 发出的请求。
|
||||
|
||||
代理抓包本身属于比较基础的操作，这里不再展开
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
真正值得关注的，是大量正常请求中突然出现的一条异常请求
|
||||
## 0x03 一条“不太正常”的图片请求
|
||||
|
||||
在浏览 APP 正常功能时，我看到了一批图片、接口等请求。
|
||||
|
||||
大部分请求都很普通，基本符合：
|
||||
|
||||
业务域名 → API → JSON / 图片 / 其他资源
|
||||
|
||||
但其中一个图片资源请求引起了我的注意。
|
||||
|
||||
**APP 在请求图片资源时，并没有使用业务域名，而是直接请求了一个裸 IP 地址**
|
||||
|
||||
|
||||
|
||||
当时我的第一反应并不是：“这里肯定有漏洞”，
|
||||
|
||||
而是：**“这个 IP 到底是谁？”**
|
||||
|
||||
它可能只是正常的图片服务器，也可能是 CDN 节点。
|
||||
|
||||
但还有一种可能：
|
||||
|
||||
**这是一个没有出现在前期 Web 资产视野中的独立服务器**
|
||||
|
||||
如果是后一种情况，那么这条看似普通的图片请求，就不再只是一张图片，而更像是 APP 无意中暴露出的一个新攻击面
|
||||
|
||||
这里还有一个值得注意的地方：**这个 IP 并不是通过扫描器枚举得到的，而是 APP 在正常业务流程中主动请求到的通信地址**
|
||||
|
||||
这意味着，接下来与其继续围绕主域名做测试，不如顺着这个 IP 看看它到底承担着什么业务
|
||||
## 0x04 从一个 IP 继续往下追
|
||||
|
||||
拿到这个 IP 后，我先进行了基础验证
|
||||
|
||||
这里我并没有直接把它当成漏洞，而是先确认它到底是什么角色。
|
||||
|
||||
如果它只是普通 CDN 节点，那么继续深入测试的价值有限；
|
||||
|
||||
如果它对应的是一台独立业务服务器，那么就意味着 APP 暴露出了一个新的业务入口。
|
||||
|
||||
实际访问后发现，这个地址并不是简单返回图片资源，而是可以直接访问，并且背后运行着一个独立的 Web 服务
|
||||
|
||||
也就是说:APP->图片请求->裸 IP->独立 Web 服务->新的业务入口
|
||||
|
||||
到这里，测试思路发生了一次变化
|
||||
|
||||
这个 IP 本身未必意味着漏洞
|
||||
|
||||
但**IP 背后的服务，可能意味着新的攻击面**
|
||||
|
||||
对于众测来说，这种发现往往比单纯拿到一个 IP 更有价值
|
||||
## 0x05 意外发现文件上传功能
|
||||
|
||||
继续观察这个 Web 服务后，我发现其中存在文件上传功能
|
||||
|
||||
到这里，我开始重点关注它的上传逻辑
|
||||
|
||||
首先确认正常文件能否上传，然后进一步观察服务端对于文件类型、文件名以及后缀的处理方式
|
||||
|
||||
测试过程中发现：
|
||||
|
||||
**服务端主要依赖文件名后缀进行限制，存在校验不足的问题，可以通过修改文件名后缀上传自定义后缀文件**
|
||||
|
||||
原本预期的业务逻辑应该更接近：
|
||||
|
||||
用户上传文件->服务端校验文件类型->严格限制允许的文件类型->保存文件
|
||||
|
||||
但实际观察到的处理逻辑存在明显的限制缺失。
|
||||
|
||||
因此，这里不能简单地把它理解成一个普通的“文件上传接口”。
|
||||
|
||||
真正值得关注的是：
|
||||
|
||||
**攻击者能够影响最终上传文件的类型。**
|
||||
|
||||
当然，文件上传漏洞最终能够造成多大的影响，还需要结合上传目录、文件访问方式、服务器解析机制以及权限控制等因素进行判断。
|
||||
## 0x06 文件上传漏洞验证
|
||||
|
||||
发现上传功能后，我没有停留在“这里存在一个上传点”这一层，而是继续对其实际处理逻辑进行了验证
|
||||
|
||||
对于文件上传类问题来说，上传接口本身并不能直接等同于高危漏洞。真正需要确认的是：**攻击者能否控制最终写入服务器的文件，以及这个文件落地后能够产生什么影响**
|
||||
|
||||
因此，我按照实际请求链路继续进行了测试
|
||||
|
||||
首先测试正常文件上传，确认服务端能够接收并处理上传请求；随后进一步观察服务端对上传文件名称、后缀以及文件类型的处理方式
|
||||
|
||||
|
||||
|
||||
测试过程中发现，服务端对上传文件的限制并不严格，上传文件的后缀存在可控空间。通过调整上传文件的文件名及相关参数，我成功绕过了原有的文件类型限制，使服务端接受了原本不应被允许上传的文件
|
||||
|
||||
到这里，问题已经不再是简单的“存在一个上传接口”，而是**攻击者已经能够影响服务器最终接收并保存的文件类型**
|
||||
。
|
||||
|
||||
随后我进一步确认了文件的实际落地情况，并验证上传后的文件能够被正常访问。
|
||||
|
||||
也就是说，这条攻击链已经实际走通：上传接口->上传限制校验->绕过文件类型限制->文件成功上传->文件实际落地->上传文件可被访问
|
||||
|
||||
至此，文件上传漏洞已经完成了实际验证。
|
||||
|
||||
这里需要特别说明的是，我没有继续尝试利用该文件上传点进一步获取服务器权限或扩大影响。
|
||||
|
||||
原因并不是漏洞无法继续利用，而是在后续核实过程中发现，当前服务器虽然与目标业务存在关联，但并不属于本次众测约定的核心业务资产范围。
|
||||
|
||||
因此，在确认漏洞真实存在并保留必要验证证据后，我停止了进一步利用，并将该问题及资产归属情况一并反馈给了甲方，甲方给出的说法与我想的一致，并且给出口头嘉奖
|
||||
|
||||
|
||||
|
||||
这次测试给我的一个比较深的体会是：
|
||||
|
||||
**漏洞验证和漏洞利用，是两个不同的阶段；能够继续利用，不代表就应该继续利用。**
|
||||
|
||||
在真实的安全测试中，技术上“能不能打进去”和授权范围内“应不应该继续打”，是两件完全不同的事情
|
||||
## 0x07 一个有意思的问题：我好像“打偏了”
|
||||
|
||||
到这里，其实已经可以确认：
|
||||
|
||||
**漏洞本身是真实存在的**
|
||||
|
||||
后续进行资产归属核验时，却发现了一个比较有意思的情况。
|
||||
|
||||
这个上传点所在的服务器，属于目标单位的外围附属资产，但**不在本次众测约定的核心业务资产范围之内**
|
||||
。
|
||||
|
||||
也就是说，从技术路径来看，我确实找到了漏洞；
|
||||
|
||||
但从众测规则和资产边界来看，却相当于：
|
||||
|
||||
**“漏洞是真的，但打偏了。”**
|
||||
|
||||
这个结果反而让我觉得很有代表性。
|
||||
|
||||
因为在实际众测中，我们经常会把注意力集中在：
|
||||
```
|
||||
主域名
|
||||
核心业务
|
||||
核心 API
|
||||
后台系统
|
||||
|
||||
```
|
||||
|
||||
但一个真实单位的互联网暴露面，往往远比这些复杂
|
||||
|
||||
可能存在:核心业务,APP,API,图片服务,文件服务，历史系统，独立服务器，第三方/外围系统
|
||||
|
||||
这些系统虽然可能服务于同一个业务体系，但安全建设水平并不一定一致。
|
||||
|
||||
因此：
|
||||
|
||||
**发现漏洞、确认资产归属、判断业务影响，其实是三个不同的问题。**
|
||||
|
||||
这次测试也让我更加意识到，漏洞验证不能只关注技术层面的“能不能打”，还需要确认：
|
||||
- 资产到底属于谁；
|
||||
|
||||
- 是否属于授权范围；
|
||||
|
||||
- 是否属于核心业务；
|
||||
|
||||
- 漏洞实际影响是什么。
|
||||
|
||||
确认该资产不在本次众测约定的核心范围后，我没有继续对该服务器进行进一步利用，而是保留必要的验证证据并结束了后续测试
|
||||
## 0x08 为什么 APP 流量值得关注？
|
||||
|
||||
回头看整个过程，真正让我觉得有价值的，其实不是最后那个上传点。
|
||||
|
||||
而是：
|
||||
|
||||
**如果我没有去分析 APP 流量，这个服务器很可能根本不会进入我的测试视野。**
|
||||
|
||||
传统 Web 资产发现的思路通常是：
|
||||
```
|
||||
主域名
|
||||
↓
|
||||
子域名
|
||||
↓
|
||||
IP
|
||||
↓
|
||||
端口
|
||||
↓
|
||||
Web 服务
|
||||
↓
|
||||
漏洞
|
||||
|
||||
```
|
||||
|
||||
而 APP 给了我另一条路径：
|
||||
```
|
||||
APP
|
||||
↓
|
||||
API / 图片 / 文件请求
|
||||
↓
|
||||
通信地址
|
||||
↓
|
||||
新的 IP / 域名
|
||||
↓
|
||||
独立 Web 服务
|
||||
↓
|
||||
新的功能
|
||||
↓
|
||||
漏洞
|
||||
|
||||
```
|
||||
|
||||
这两条路径最大的区别在于：**第二条路径是从业务行为反推出基础设施**
|
||||
|
||||
它不一定每次都能发现漏洞，但有机会发现传统资产收集过程中没有进入主要测试视野的业务入口
|
||||
|
||||
所以对于 APP 流量，我现在更关注的并不是“能不能抓到包”，而是：
|
||||
|
||||
**APP 到底在和哪些服务器说话？**
|
||||
## 0x09 从一次异常请求重新理解攻击面
|
||||
|
||||
这次的情况还有一个值得注意的地方。
|
||||
|
||||
如果单纯把：“APP 请求资源时使用了裸 IP”
|
||||
|
||||
单独拎出来，并直接定性为信息泄露漏洞，其实并不严谨。
|
||||
|
||||
因为：
|
||||
|
||||
**一个 IP 地址本身，并不一定构成安全漏洞。**
|
||||
|
||||
真正有价值的是后续形成的完整链条：
|
||||
```
|
||||
APP 暴露通信信息
|
||||
↓
|
||||
发现新的网络入口
|
||||
↓
|
||||
确认入口存在独立 Web 服务
|
||||
↓
|
||||
发现文件上传功能
|
||||
↓
|
||||
发现上传限制存在缺陷
|
||||
↓
|
||||
确认真实安全风险
|
||||
↓
|
||||
进行资产归属核验
|
||||
|
||||
```
|
||||
|
||||
所以，这里真正值得记录的并不是：“APP 泄露了 IP。”
|
||||
|
||||
而是：
|
||||
|
||||
**一个看似普通的客户端通信信息，最终成为了扩大攻击面的入口。**
|
||||
|
||||
这也是我认为这次测试最有价值的地方
|
||||
## 0x10 如果重新来一次，我还会怎么做？
|
||||
|
||||
如果让我重新测试一次类似目标，我大概还是会遵循几个简单的原则。
|
||||
### 1. 先看业务入口，再看客户端
|
||||
|
||||
先完成基础 Web 资产收集。
|
||||
|
||||
如果主 Web 面没有明显突破口，再转向：
|
||||
```
|
||||
APP
|
||||
小程序
|
||||
H5
|
||||
客户端接口
|
||||
|
||||
```
|
||||
|
||||
不要把 APP 只当成一个业务客户端，也可以把它当成一个观察目标基础设施的入口
|
||||
### 2. 先关注异常，再判断漏洞
|
||||
|
||||
对于客户端流量，我会特别注意：
|
||||
- IP 地址
|
||||
|
||||
- 异常域名
|
||||
|
||||
- 非主域名请求
|
||||
|
||||
- 图片/文件服务器
|
||||
|
||||
- 对象存储
|
||||
|
||||
- 特殊接口
|
||||
|
||||
- 不常见的通信地址
|
||||
|
||||
因为真正值得继续追踪的东西，往往并不会直接告诉你：“这里存在一个漏洞。”
|
||||
|
||||
它可能只是表现得：**“这里和其他地方不太一样。”**
|
||||
### 3. 先确认资产归属，再判断影响
|
||||
|
||||
发现新的 IP 或域名后，不要马上进入漏洞利用。
|
||||
|
||||
需要先回答：
|
||||
|
||||
它属于谁？
|
||||
|
||||
为什么 APP 会访问它？
|
||||
|
||||
对应什么业务？
|
||||
|
||||
是否属于目标？
|
||||
|
||||
是否属于授权范围？
|
||||
|
||||
只有把这些问题搞清楚，后续的漏洞验证才有意义
|
||||
### 4. 先证明问题真实存在，再考虑进一步利用
|
||||
|
||||
对于漏洞验证，我更倾向于：发现->复现->确认->评估影响
|
||||
|
||||
而不是为了让漏洞看起来更“高危”，强行把利用链往后延伸
|
||||
|
||||
尤其是在真实众测环境中，**测试边界本身也是测试的一部分**
|
||||
|
||||
02
|
||||
|
||||
0x2 培训课程介绍
|
||||
|
||||
26
|
||||
|
||||
**SRC漏洞挖掘培训课程**
|
||||
|
||||
|
||||
|
||||
|
||||
**1.课程价格目前是575（后面也会随着人数越多，涨价）🌟师傅们还可以上车补票，冲冲冲！**
|
||||
|
||||
**2.报名成功送知识星球一个，拉内部小圈子交流群+SRC直播通知群！✨**
|
||||
|
||||
**3.一周2节课程，直播+录播形式，课程内容大家可以看课表，目前是第一期，一次报名永久无限听课！❤️**
|
||||
|
||||
**4.目前是第一期课程，后面比如说开了二、三期，都是不用在花钱的！**
|
||||
|
||||
**5.上课结束后，会把视频录播+课件笔记一起打包发直播群！**
|
||||
|
||||
**6.哔哩哔哩SRC课程公开课，链接🔗直达：**
|
||||
|
||||
**https://space.bilibili.com/642258933**
|
||||
|
||||
SRC课程详情🔎：
|
||||
[学了一堆理论，还是挖不到漏洞？你缺的是实战！](https://mp.weixin.qq.com/s?__biz=Mzk0Mzc1MTI2Nw==&mid=2247509869&idx=1&sn=4bd678e9f9c864300cc2426432a8c967&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
内部小圈子知识星球详情🔎：[50 元封顶！渗透攻防 + SRC 漏洞星球限时开放！](https://mp.weixin.qq.com/s?__biz=Mzk0Mzc1MTI2Nw==&mid=2247509408&idx=1&sn=2e12452dfc2d34631af5109af28a6758&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
欢迎关注公众号：
|
||||
神农Sec
|
||||
，报名咨询添加VX：
|
||||
routing_love
|
||||
|
||||
|
||||
|
||||
开课快五个月时间
|
||||
，课程目前已经
|
||||
累计加入了1000+个学员
|
||||
了，课程培训招生任火热持续中，师傅们
|
||||
对于我们课程感兴趣的，想要学习技术，找工作的可以咨询我报名
|
||||
。
|
||||
|
||||
|
||||
|
||||
课程培训记录📝，每次上车在1-3小时之间，上课包括课程内部群大家
|
||||
交流氛围很好！
|
||||
|
||||
|
||||
|
||||
课程上课笔记课件📒都会打包给师傅们，笔记都非常详细，很多几k价格的培训机构哪怕是课件笔记都没有的，我这里都是下课第一时间把
|
||||
录播+笔记打包发给大家！
|
||||
|
||||
|
||||
|
||||
平常也都会给学员进行一些项目发布，包括后面的
|
||||
工作、护网内推等，经常上麦交流，大家互相学习，简历优化等。
|
||||
|
||||
|
||||
|
||||
SRC漏洞挖掘课程培训已经两个星期了，期间也是创建了
|
||||
“回本小群”，希望学员回本越来越多，创建这个群主要是鼓励学员学习进步，以及不定时发小项目！
|
||||
|
||||
最后也是希望大家都可以赚钱，找到好工作🎉
|
||||
|
||||
|
||||
|
||||
培训时间不长，感谢🙏师傅们的
|
||||
喜报
|
||||
，很开心看到师傅们给我分享自己的成果，
|
||||
希望师傅们越来越强！
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
平常也会分享项目，下面是一些
|
||||
学员项目成果
|
||||
，群里报课的学员都是不抽成的，主要是帮助学员进行
|
||||
回本
|
||||
，
|
||||
让大家都可以进步！
|
||||
|
||||
|
||||
|
||||
上课结束后，会把
|
||||
视频录播+课件笔记
|
||||
一起打包发直播群
|
||||
|
||||
**「神农安全」**
|
||||
知识星球目前已经
|
||||
累计2500+网络安全爱好者的加入！
|
||||
|
||||
后面也是小圈子做大起来了，师傅们也都喜欢看我文章，想着给大家教下src漏洞挖掘思路，所以自己花了很长时间做了✨
|
||||
课件和课表，都是纯自己手搓的，大家也可以看下课表的内容。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
03
|
||||
|
||||
0x3 课程特色
|
||||
|
||||
课程
|
||||
主打真实，
|
||||
一线SRC漏洞挖掘师傅是如何学习和挖掘SRC漏洞的，让你真正了解SRC漏洞挖掘，助力在岗人员和大学生的能力提升，掌握新的技能树，为下一次
|
||||
跳槽涨薪做好准备。本
|
||||
课程内容覆盖企业
|
||||
SRC、众测项目挖掘、护网HVV红蓝攻防技巧、CVE、CNVD、EDUSRC等平台通杀案例技巧挖掘方法。
|
||||
|
||||
本课程
|
||||
适合人群
|
||||
（光看不挖啥也不会）
|
||||
```
|
||||
1、有计算机经验，想从0转行入行的大学生或自学者
|
||||
2、想从CTF比赛/Web或SRC进阶到项目实战的选手
|
||||
3、想参与项目/找工作/提高收入的转型者
|
||||
4、想通过挖SRC赏金做副业的师傅们
|
||||
5、挖SRC漏洞遇到瓶颈的师傅们
|
||||
6、想学习AI安全自动化渗透测试漏洞挖掘的师傅
|
||||
```
|
||||
|
||||
课程价格：575 元
|
||||
|
||||
报课成功的师傅们直接免费送内部小圈：一个知识星球+内部小圈子交流群
|
||||
```
|
||||
1、课程价格真心实惠，绝不割韭菜
|
||||
2、四五百的课程价格让你体会大几千的培训课程内容
|
||||
3、带着大家从0到1，本人上课坚持手搓课件（实战案例+知识体系）
|
||||
4、拒绝使用PPT演讲模式（无实操，很枯燥）
|
||||
```
|
||||
|
||||
直播培训教学方式
|
||||
|
||||
课程
|
||||
一周1-2节课，课程特色涵盖直播多人上麦活跃回答，直播过程中有问题随时解决或私信我。
|
||||
拉群：一个知识星球内部小圈子交流群+课程培训直播通知群。有项目/工作/护网第一时间内推报课的师傅，
|
||||
一对一简历优化，助力在岗人员和大学生的能力提升。
|
||||
|
||||
一次报名每期均可永久学习，并且赠送内部「神农安全」知识星球，一对一永久解答、无保留教学！
|
||||
|
||||
欢迎关注公众号：
|
||||
神农Sec
|
||||
，报名咨询添加VX：
|
||||
routing_love
|
||||
|
||||
课程均为线上交付，报名成功后
|
||||
不支持退款
|
||||
|
||||
内部小圈子
|
||||
（知识星球+内部小圈子交流群+知识库）
|
||||
|
||||
对内部小圈子感兴趣的师傅们也可以看下下面的这个
|
||||
跳转链接，里面有对小圈子的详细介绍，报名课程成功的师傅们直接免费送一个（直接点击下面直接可以跳转）。
|
||||
|
||||
[强烈推荐一个永久的SRC挖掘、渗透攻防内部知](https://mp.weixin.qq.com/s?__biz=Mzk0Mzc1MTI2Nw==&mid=2247508882&idx=1&sn=0ca5ab133a5b589e26e25de14882b28f&scene=21#wechat_redirect)
|
||||
|
||||
[](https://mp.weixin.qq.com/s?__biz=Mzk0Mzc1MTI2Nw==&mid=2247508882&idx=1&sn=0ca5ab133a5b589e26e25de14882b28f&scene=21#wechat_redirect)
|
||||
|
||||
[识库](https://mp.weixin.qq.com/s?__biz=Mzk0Mzc1MTI2Nw==&mid=2247508882&idx=1&sn=0ca5ab133a5b589e26e25de14882b28f&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
|
||||
|
||||
讲师介绍
|
||||
|
||||
id：一个想当文人的黑客
|
||||
|
||||
|
||||
|
||||
欢迎关注公众号：神农Sec，报名咨询添加VX：
|
||||
routing_love
|
||||
|
||||
|
||||
|
||||
04
|
||||
|
||||
0x4 第一期挖洞培训课表内容
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**内部圈子介绍（报课赠送）**
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**圈子专注于更新src/红蓝攻防相关：**
|
||||
|
||||
```
|
||||
1、维护更新src专项漏洞知识库，包含原理、挖掘技巧、实战案例
|
||||
2、知识星球专属微信“小圈子交流群”
|
||||
3、微信小群一起挖洞
|
||||
4、内部团队专属EDUSRC证书站漏洞报告
|
||||
5、分享src优质视频课程（企业src/EDUSRC/红蓝队攻防）
|
||||
6、分享src挖掘技巧tips
|
||||
7、不定期有众测、渗透测试项目（一起挣钱）
|
||||
8、不定期有工作招聘内推（工作/护网内推）
|
||||
9、送全国职业技能大赛环境+WP解析（比赛拿奖）
|
||||
10、十个专栏会持续更新~提前续费有优惠，好用不贵很实惠
|
||||
11、每日内部资料分享，内部圈子资料1000+
|
||||
12、联系圈主获取：内部漏洞知识库+圈子使用手册+内部圈子交流群
|
||||
13、VX：routing_love，技术交流+疑问解决
|
||||
```
|
||||
|
||||
|
||||
**内部圈子**
|
||||
**专栏介绍**
|
||||
|
||||
知识星球内部共享资料截屏详情如下
|
||||
|
||||
（只要没有特殊情况，每天都保持更新）
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
05
|
||||
|
||||
0x5
|
||||
优秀学员报喜
|
||||
|
||||
下面是最近两个月培训期间，很多
|
||||
优秀学员进行报喜，看到师傅们有收获，也是感到很开心的！
|
||||
拉回本小群，就是为了促进大家学习，在群里发学员成果，也是为了让大家学习优秀的师傅们。
|
||||
|
||||
加油，你我皆是黑马！
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**神农安全公开交流群**
|
||||
|
||||
有需要的师傅们直接扫描文章二维码加入，然后要是后面群聊二维码扫描加入不了的师傅们，直接扫描文章开头的二维码加我（备注加群）
|
||||
|
||||
|
||||
|
||||
|
||||
```
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,55 @@
|
||||
# 国家信息安全漏洞共享平台认证！360揽获三项漏洞治理核心殊荣
|
||||
安全客 2026-09-19 00:30
|
||||
|
||||
****
|
||||
近日，国家信息安全漏洞共享平台（CNVD）正式开展2025年度技术组支撑单位能力评价工作。
|
||||
凭借在漏洞挖掘、报送分析、协同处置等方面的扎实能力与持续输出，360一举斩获“CNVD 协作特别贡献单位”、“漏洞应急工作突出贡献单位”、“漏洞信息报送贡献单位”三项重磅荣誉。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
漏洞治理是网络安全防护的关键一环，高效管控各类安全漏洞风险，是筑牢网络空间防线、守护国家网络安全的重要抓手。
|
||||
|
||||
|
||||
作为目前国内最权威的官方漏洞平台之一，国家信息安全漏洞共享平台（CNVD）围绕漏洞搜集发现、技术研判分析、漏洞大数据运营、重大安全事件协同处置、专项任务联动等多个维度，对各技术支撑单位的年度履职成效开展综合考评。
|
||||
|
||||
|
||||
360是国内最早参与CNVD共建协作的技术单位之一，长期深度融入平台全链条业务。其中，360漏洞研究院作为核心支撑力量，持续参与漏洞归集、真伪校验与研判、威胁态势预警等关键环节；同时，360漏洞研究院依托其搭建的360漏洞众包平台推进漏洞安全技术创新实践，持续输出高价值漏洞情报资源，为我国网络安全漏洞综合治理能力建设提供有力支撑。
|
||||
|
||||
在落地实践层面，360重点从三方面推进漏洞安全能力建设：
|
||||
|
||||
|
||||
|
||||
第一，强化网络空间安全监测与应急响应能力，持续跟踪全网漏洞态势变化，为国家层面提供及时高效的态势感知与风险预警支撑。
|
||||
|
||||
|
||||
第二，构建完整漏洞安全业务生态，搭建覆盖态势监测、线索归集、漏洞挖掘、资产存储、闭环管理、专家研判、定制化安全服务的全链路一体化漏洞安全能力体系。
|
||||
|
||||
|
||||
第三，面向国家机构与政企行业客户，输出漏洞情报订阅、合规众测、7×24 漏洞应急处置、补丁推送落地、专家专项支撑等多元化服务能力，帮助客户提前识别安全隐患，掌握风险处置主动权。
|
||||
|
||||
|
||||
与此同时，AI正加速重塑网络攻防方式。**360进一步将AI能力引入漏洞研究体系，推动自主研发的AI安全攻防系统“图龙锋”。**
|
||||
其依托“安全领域大模型+专业智能体蜂群”技术路线，将漏洞数据、专家经验和安全工具融入分析流程，由安全领域大模型解析复杂代码与业务逻辑，多组专业智能体协同完成攻击面梳理、代码分析、漏洞研判、风险复现和工具调用，推动漏洞挖掘从高度依赖少数专家经验向自动化、规模化演进，成为360参与国家级漏洞治理的新增技术能力。
|
||||
|
||||
|
||||
**截至目前，图龙锋累计挖掘漏洞超万个，其中260个获国家级权威机构核验确认，覆盖OpenAI Codex、Claude Code、Hermes、OpenClaw等主流商用及开源AI产品，包含多项严重、高危级漏洞。**
|
||||
|
||||
|
||||
多年来，360依托在漏洞安全领域的技术沉淀与实战成果，多次获得国家信息安全漏洞共享平台（CNVD）授予的荣誉认可。本次三项荣誉加身，再次印证平台对于360漏洞挖掘、智能研判、应急处置综合实力的高度认可。
|
||||
|
||||
|
||||
未来，360将进一步深化与国家级漏洞平台的协同联动，高质量落实网络安全应急保障支撑任务，不断提升行业安全研判与风险预警水平，为筑牢国家网络安全防线贡献更多力量。
|
||||
|
||||
往期推荐
|
||||
|
||||
<table><tbody><tr><td data-colwidth="100.0000%" width="100.0000%" style="border-width: 0px;border-color: rgb(62, 62, 62) rgb(62, 62, 62) rgb(255, 255, 255);border-style: none;padding: 0px 0px 10px;"><section style="min-height: 40px;"><section style="width: 100%;margin: 0px auto -10px;"><table><tbody><tr><td rowspan="2" data-colwidth="30.0000%" width="30.0000%" style="border-color: rgb(62, 62, 62);border-style: none;background-repeat: no-repeat;background-attachment: scroll;vertical-align: bottom;background-image: url("https://mmbiz.qpic.cn/sz_mmbiz_png/zfoRGB81MxO8VSPIqY0jhhibzq9yMdoShdflfY2O2sNOicmpAogEMnp8LcWCiaHobakM1lANW0HFSk8HickRrcZHiaXgtCHt0icsbo5wW8aRaJ0kc/640?wx_fmt=png&from=appmsg");padding: 0px;background-position: 50% 50% !important;background-size: cover !important;"><section style="margin: 0px 0% 4px;"><section style="text-align: right;padding: 0px 4px;color: rgb(255, 255, 255);font-size: 32px;line-height: 1;"><p><strong><span leaf="">01</span></strong></p></section></section></td><td data-colwidth="70.0000%" width="70.0000%" style="border-color: rgb(62, 62, 62);border-style: none;padding: 0px 10px;background-color: rgb(249, 249, 249);"><section style="margin: 10px 0% 0px;"><section style="color: rgb(140, 140, 140);"><p style="white-space: normal;"><span style="color: rgb(202, 29, 24);"><span leaf="">● </span></span><span style="color: rgb(58, 66, 94);"><span leaf=""><a class="normal_text_link mp_article_text_link" target="_blank" style="" href="https://mp.weixin.qq.com/s?__biz=MzA4MTg0MDQ4Nw==&mid=2247586499&idx=1&sn=9f0f70f075ec089ad3aa4c08aae9e67f&scene=21#wechat_redirect" textvalue="“AI安全报告”首位推荐！360构建智能体全域防护体系" data-itemshowtype="0" linktype="text" data-linktype="2">“AI安全报告”首位推荐！360构建智能体全域防护体系</a></span></span></p></section></section></td></tr><tr><td data-colwidth="70.0000%" width="70.0000%" style="border-color: rgb(62, 62, 62);border-style: none;padding: 0px 10px;background-color: rgb(249, 249, 249);"><section style="margin: 10px 0%;"><section style="line-height: 1;color: rgb(140, 140, 140);"><p style="text-align: right;white-space: normal;"><span style="font-size: 14px;color: rgb(208, 208, 208);"><span leaf="">► 点击阅读</span></span></p></section></section></td></tr></tbody></table></section></section></td></tr><tr><td data-colwidth="100.0000%" width="100.0000%" style="border-width: 0px;border-color: rgb(62, 62, 62) rgb(62, 62, 62) rgb(255, 255, 255);border-style: none;padding: 0px 0px 10px;"><section style="min-height: 40px;"><section style="width: 100%;margin: 0px auto -10px;"><table><tbody><tr><td rowspan="2" data-colwidth="30.0000%" width="30.0000%" style="border-color: rgb(62, 62, 62);border-style: none;background-repeat: no-repeat;background-attachment: scroll;vertical-align: bottom;background-image: url("https://mmbiz.qpic.cn/mmbiz_jpg/zfoRGB81MxNwD4qeIU9M1CKn8q46lDyVHlR8cfyibmNbOy4R9rc9ouAiapj8rZS6kO7FfoXKoEDeJ5dBJJQXzFaiarbyUAoapts3TogZrC8HLY/640?wx_fmt=jpeg&from=appmsg");padding: 0px;background-position: 50% 50% !important;background-size: cover !important;"><section style="margin: 0px 0% 4px;"><section style="text-align: right;padding: 0px 4px;color: rgb(255, 255, 255);font-size: 32px;line-height: 1;"><p><strong><span leaf="">02</span></strong></p></section></section></td><td data-colwidth="70.0000%" width="70.0000%" style="border-color: rgb(62, 62, 62);border-style: none;padding: 0px 10px;background-color: rgb(249, 249, 249);"><section style="margin: 10px 0% 0px;"><section style="color: rgb(71, 193, 168);"><p style="white-space: normal;"><span style="color: rgb(202, 29, 24);"><span leaf="">● <a class="normal_text_link mp_article_text_link" target="_blank" style="" href="https://mp.weixin.qq.com/s?__biz=MzA4MTg0MDQ4Nw==&mid=2247586322&idx=1&sn=c68961f482c2dc603287457d88414ec8&scene=21#wechat_redirect" textvalue="ISC.AI 2026 周鸿祎演讲全文：打造中国版“Mythos”，应对网络安全新挑战" data-itemshowtype="0" linktype="text" data-linktype="2">ISC.AI 2026 周鸿祎演讲全文：打造中国版“Mythos”，应对网络安全新挑战</a></span></span></p></section></section></td></tr><tr><td data-colwidth="70.0000%" width="70.0000%" style="border-color: rgb(62, 62, 62);border-style: none;padding: 0px 10px;background-color: rgb(249, 249, 249);"><section style="margin: 10px 0%;"><section style="line-height: 1;color: rgb(140, 140, 140);"><p style="text-align: right;white-space: normal;"><span style="font-size: 14px;color: rgb(208, 208, 208);"><span leaf="">► 点击阅读</span></span></p></section></section></td></tr></tbody></table></section></section></td></tr><tr><td data-colwidth="100.0000%" width="100.0000%" style="border-width: 0px;border-color: rgb(62, 62, 62) rgb(62, 62, 62) rgb(255, 255, 255);border-style: none;padding: 0px 0px 10px;"><section style="min-height: 40px;"><section style="width: 10Line truncated
|
||||
|
||||
|
||||
@@ -0,0 +1,93 @@
|
||||
# 智能网联汽车漏洞管理实践探索
|
||||
GRCC
|
||||
GRCC IoVSecurity 2026-09-19 00:00
|
||||
|
||||
|
||||
|
||||
点击上方
|
||||
蓝色字体
|
||||
，关注我们
|
||||
|
||||
**/**
|
||||
**技术交流群****/**
|
||||
|
||||
添加微信
|
||||
13918880149\**15021948198(好友已满），申请会员下载ppt & 加入网络信息安全、测试评价、汽车电子、自动驾驶、智能机器人、智能船舶、超级高铁、飞行器、招聘求职、投融资合作群...**
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
相关文章
|
||||
|
||||
# 整车信息安全设计对车企的挑战与一汽奔腾的应对
|
||||
# 智能网联汽车安全测评的中国方案与实践
|
||||
# 国强标下智能网联汽车信息安全检测解决方案
|
||||
#
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
扫描二维码**申请**
|
||||
会员**下载ppt**
|
||||
&
|
||||
|
||||
加入行业交流群
|
||||
|
||||
获取合作机会
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
扫描二维码获取
|
||||
|
||||
更多精彩
|
||||
|
||||
|
||||
|
||||
|
||||
关注“**IoVSecurity**
|
||||
”
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
点个在看
|
||||
你最好看
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,106 @@
|
||||
# 黑客攻陷OpenAI：两个漏洞让我们拿下ChatGPT控制权
|
||||
原创 Red Hunter
|
||||
Red Hunter 黑白之道 2026-09-19 01:20
|
||||
|
||||
|
||||
> **导语**
|
||||
：安全研究团队Hacktron披露，他们用libheif图像解码器的堆缓冲区溢出漏洞，结合OpenAI SSO身份认证的配置缺陷，72小时内接管了多名OpenAI员工的ChatGPT与Codex账户，最终通过GitHub集成访问到OpenAI内部monorepo。为了证明确实拿到了访问权限，他们让员工的Codex在openai/openai仓库开了个PR #1186742。OpenAI为此支付了6,500美元漏洞赏金。
|
||||
|
||||
## 一、攻击链全景
|
||||
|
||||
整个利用链分七步走：libheif图像解码器 → Debian缺失的安全补丁 → ImageMagick调用libheif → Discourse论坛图片上传 → OpenAI社区论坛 → OpenAI SSO身份缺陷 → ChatGPT/Codex账户接管 → GitHub连接集成 → OpenAI内部仓库。
|
||||
|
||||
|
||||
|
||||
过去两个月里，任何登录过OpenAI官方帮助论坛的用户或员工都可能被一锅端。因为人们会把各种服务接入Codex与ChatGPT，理论上能接触到的东西包括GitHub、Slack、邮箱，范围大得吓人。
|
||||
|
||||
|
||||
## 二、libheif堆缓冲区溢出
|
||||
|
||||
Hacktron团队几个月前开始研究前沿AI公司的安全问题，由Harsh Jaiswal带队，加上Mohan Pedhapati和Rahul Maini。后来把研究扩展成了名为「HEIF Heist」的跨产品调查，追踪libheif在Slack、Meta、GitHub Enterprise、Ruby on Rails，以及Next.js、Astro、Gatsby等Node.js框架里的踪迹。大量被广泛使用的软件都依赖这同一个图像处理库。
|
||||
|
||||
**自托管Discourse的用户请立即重建**
|
||||
：旧版Docker镜像可能含有漏洞版本的libheif依赖，通过图片上传就能执行代码。仅做Web界面升级可能不够，必须从/var/discourse
|
||||
执行git pull
|
||||
后跑./launcher rebuild app
|
||||
。Discourse官方托管客户已修复。
|
||||
|
||||
7月23日，团队审Discourse的图片上传管线时发现，HEIC和HEIF文件走了条不寻常的路：FastImage不支持HEIF，于是被转交给ImageMagick的magick命令做转换，底层libheif解析器直接暴露给攻击者可控的文件。
|
||||
|
||||
他们用Opus 4.8会话审查安装的libheif包后发现，某些安全修复没被反向移植到Debian的包里，导致HEIC解码时存在堆缓冲区溢出，能拿到越界读写原语。漏洞代码前一年在上游就改过，但那次提交没标注为安全修复，也没分配CVE，所以Debian 12和13都没及时拿到反向移植。Discourse的Docker镜像基于Debian 12，安装的libheif版本是1.19.7（漏洞版本），Debian 13当时也还在用1.19.8。直到2026年8月8日，Debian才发布13的安全更新。
|
||||
## 三、Opus 5 救场
|
||||
|
||||
7月24日，团队用Opus 4.8开发出本地版的ImageMagick/libheif利用脚本（关闭ASLR）。开了几个独立会话尝试适配Discourse默认开启ASLR的配置，没成功。
|
||||
|
||||
当晚Anthropic发布了Claude Opus 5。新会话3小时内产出一份可在Mac ARM64环境跑的利用脚本，然后让他们移植到Discourse的x86-64加jemalloc环境。7月25日凌晨6点确认通过图片上传实现本地RCE。
|
||||
|
||||
接着他们把Claude放进自主/goal
|
||||
循环里跑，对象是自己的Discourse Cloud实例，通过rce.ee/ctf-forum
|
||||
代理出去伪装成CTF靶机——因为Opus拒绝直接对远程实例写利用。上午10点回来检查时，Agent已经拿下Discourse Cloud的RCE，并读取/etc/hosts
|
||||
作为访问证据。拿着生成的脚本，团队成功在OpenAI的实例上也拿到了RCE。
|
||||
|
||||
确认能无交互接管论坛活跃成员的ChatGPT/Codex账户后，他们立刻把报告发给OpenAI安全团队。然后接管了一名OpenAI员工的账户——该员工的Codex接入了OpenAI的GitHub组织。为了在不读取任何内部代码的前提下证明影响，他们让这名员工的Codex替他们在OpenAI内部monorepo里开了个PR，然后立即停止进一步测试。
|
||||
|
||||
他们也通过HackerOne向Discourse上报，周六收报、周日回复、周一修好，响应速度值得点赞。Discourse还立即开始对ImageMagick做沙箱化处理。
|
||||
|
||||
要强调的是，这次能提权并不是Discourse的锅——是OpenAI SSO的问题，把论坛被攻破这件事放大成了ChatGPT和Codex访问权限。任何使用OpenAI SSO的第一方或第三方服务被攻破，都会通向同样的结果。
|
||||
## 四、发现这些漏洞的成本
|
||||
|
||||
整套攻击Agent跑下来几天，人工只花了几小时。整个「HEIF Heist」研究项目横跨Slack、Meta等目标，2个月、3名研究员、token总成本不到3,000美元。把利用适配到每家新公司通常只要一两天。
|
||||
|
||||
模型代际能力跳跃明显：Opus 4.8开了好几个会话都没搞出能在开启ASLR条件下工作的利用。Opus 5发布后几小时内把同样的问题丢给它，就成功了。在更广的Campaign里，还看到了Opus 5到GPT-5.6 Sol之间清晰的能力跳跃——那次要在对目标系统一无所知的情况下完成利用。
|
||||
|
||||
每个目标都从一次图片上传开始，把内存损坏转化成稳定的内存泄漏或shell，通常完全不需要知道准确的libheif版本、libc版本、部署环境。AI几乎是两眼一抹黑开干，1到2天内适配好每家公司的利用。几千张图片投递、图像处理器反复崩溃，没几家公司检测到异常——只有Shopify除外。
|
||||
|
||||
代码执行落到沙箱或受限环境里，模型还帮着搞权限提升、横向移动、绕过已有防御。这不是完全自主的黑客行为，熟练的人工引导仍然重要，但小团队能干的工作量已经被显著放大了。
|
||||
## 五、尾声：安全的假设需要重写
|
||||
|
||||
|
||||
|
||||
软件长期以来享受着「靠复杂性带来的安全」。代码甚至漏洞都可以是公开的，但把一个Bug打磨成可靠的利用脚本，仍然需要稀缺的专业知识、大量时间、以及对目标环境的了解。已知的内存损坏漏洞运营成本很高，零日漏洞基本只留给最高价值的目标。
|
||||
|
||||
这从来就不是真正的安全边界，但它在实践中保护了普通公司。AI正在瓦解这层保护，把稀缺的专业能力更多转化为算力。曾经需要资源充足的团队花几个月干的活，现在能压缩到几天。
|
||||
|
||||
安全假设必须跟上攻击者能力。现实的威胁模型应当考虑当下的利用经济学，而不是依赖那些关于「谁能发起复杂攻击」的过时假设。Hacktron正在把研究扩展到前沿实验室和其他互联网关键系统。
|
||||
## 六、影响版本与修复
|
||||
|
||||
「HEIF Heist」不绑死某个版本，针对的是多个发行系列（1.19.x、1.20.x、1.22.x、1.23.x）里的整个漏洞生态。任何没打最新上游安全补丁的部署都可能中招。
|
||||
- **更新上游**
|
||||
：通过发行版安全频道或上游发布，安装最新打了安全补丁的libheif和libde265包。截至2026年9月14日，最新上游libheif安全版本是v1.23.4，v1.23.2已被后续修复取代。
|
||||
|
||||
- **纵深防御**
|
||||
：生产架构应在不需要时禁用不可信的HEIF/AVIF解码，或将图像处理管线隔离在加固的临时沙箱中。ImageMagick的安全策略支持限制接受的格式和资源占用。
|
||||
|
||||
## 七、研究仓库与延伸阅读
|
||||
- **HEIF Heist 专题站**
|
||||
：https://heif-heist.com
|
||||
|
||||
- **Hacktron 博客原文**
|
||||
：https://www.hacktron.ai/blog/hacking-openai
|
||||
|
||||
- **Discourse 安全公告**
|
||||
：https://github.com/discourse/discourse/security/advisories/GHSA-vhm9-85gw-x335
|
||||
|
||||
- **ImageMagick 沙箱化提交**
|
||||
：https://github.com/discourse/discourse/commit/a07188016987de1613c961277e2e928aaa7c37ec
|
||||
|
||||
- **xkcd 2347**
|
||||
：https://xkcd.com/2347/
|
||||
|
||||
**致谢**
|
||||
：Hacktron团队感谢Sudanshu Rajhbhar的技术协助，以及Zayne Zhang、Fabian Faessler、Robert Chen、Jessica Ruan的校对与反馈。
|
||||
|
||||
**原文出处**
|
||||
：本文编译自Hacktron博客《Hacking OpenAI》（2026年9月13日发布），原文链接：https://www.hacktron.ai/blog/hacking-openai
|
||||
|
||||
|
||||
|
||||
[](https://mp.weixin.qq.com/s?__biz=MzAxMjE3ODU3MQ==&mid=2650621549&idx=1&sn=21c4b072726d2387d562109ada6b9bbb&scene=21#wechat_redirect)
|
||||
|
||||
[](https://mp.weixin.qq.com/s?__biz=MzAxMjE3ODU3MQ==&mid=2650621944&idx=1&sn=3cc6dc9876a20466d4ec3634deb80220&scene=21#wechat_redirect)
|
||||
|
||||
[](https://mp.weixin.qq.com/s?__biz=MzAxMjE3ODU3MQ==&mid=2650622065&idx=1&sn=09f8ae84c06d4331e71c277b177ae701&scene=21#wechat_redirect)
|
||||
> 👇 点击**阅读原文**
|
||||
，访问我的网站
|
||||
|
||||
|
||||
Reference in new issue
Block a user