TeamCity认证绕过漏洞（CVE-2024-27198）复现报告与分析

免责声明：本博客文章仅用于教育和研究目的。提供的所有技术和代码示例旨在帮助防御者理解攻击手法并提高安全态势。请勿使用此信息访问或干扰您不拥有或没有明确测试权限的系统。未经授权的使用可能违反法律和道德准则。作者对因应用所讨论概念而导致的任何误用或损害不承担任何责任。

目录

1. 引言与漏洞背景
2. 漏洞成因分析
3. 漏洞触发环境与复现条件
4. 漏洞发现方法与过程（0day视角）
5. 漏洞可利用性分析
6. 防御机制与突破点分析
7. 修复与缓解建议
8. 漏洞披露与社区争议
9. 结论
10. 参考与来源

1. 引言与漏洞背景

TeamCity 是 JetBrains 开发的一款广泛使用的 CI/CD（持续集成与持续交付）服务器，在企业软件开发生命周期中占据核心地位。由于其掌控着代码构建与部署权限，一旦被攻陷，极易引发大范围的软件供应链攻击。

2024年2月，Rapid7 漏洞研究团队在 TeamCity 的 Web 组件中发现了两个严重的认证绕过漏洞（CVE-2024-27198 与 CVE-2024-27199）。其中，CVE-2024-27198（CVSS 9.8）由于允许未经身份验证的攻击者直接获取最高管理权限并实现远程代码执行（RCE），危害尤为严重。

值得注意的是，该漏洞在3月初的披露过程并非一帆风顺。由于发现方（Rapid7）与厂商（JetBrains）在“协调披露”与“静默修补”理念上产生严重分歧，Rapid7 在补丁发布当日即公开了详细技术报告。这一事件不仅导致随后几天内爆发了针对该漏洞的大规模在野利用（如勒索软件和挖矿木马），更在安全社区引发了一场关于“漏洞披露伦理”的广泛争论（详见文末讨论）。

2. 漏洞成因分析

本节内容依据 Rapid7 官方报告 analysis 部分进行翻译与整理，重点还原“代码层为什么会绕过”，而非仅描述复现步骤。

该漏洞本质属于 CWE-288（Authentication Bypass Using an Alternate Path）：请求在不同处理层被解释为不同语义，导致鉴权边界与执行边界错位。

图2-1 鉴权层与执行层对同一请求语义解释不一致，是本漏洞的核心机制。

Rapid7 在报告中指出，关键问题位于 web-openapi.jar 内的 jetbrains.buildServer.controllers.BaseController。在 handleRequestInternal() 中，当请求未触发重定向时，会进入 updateViewIfRequestHasJspParameter() 逻辑；该逻辑会读取请求中的 jsp 参数并尝试覆盖 ModelAndView 的视图目标。

结合该控制流可得到漏洞成立的三个条件（Rapid7 原文同样给出了示例语义）：

1. 入口必须是未认证可达且可进入后续处理链的路径
   例如一个不存在路径触发 404 处理流。这里的目的不是访问该路径本身，而是让请求进入 BaseController 的后续逻辑。

2. 请求中携带可影响目标视图/路由的参数
   jsp 参数值被设置为受保护的 REST 路径后，会影响 ModelAndView 的最终视图解析目标。

3. 请求路径语义被伪装为 JSP 相关形式
   在路径中引入分号参数与 .jsp 后缀语义后，不同层（容器、鉴权、控制器）对 URI 的解释出现分歧：上层可能把它当成可放行的 JSP 视图请求，而后续路由阶段可能将其规范化/截断后命中真实受保护 API。

因此，这不是“单点逻辑缺陷”，而是一个多层解析不一致问题：
鉴权层看到的是“看似无害的视图请求”，执行层命中的是“受保护 REST 端点”。一旦错位成立，未认证请求即可跨越访问控制边界，进一步触发管理员级操作链路，最终导致服务器完全失陷风险。

3. 漏洞触发环境与复现条件

3.1 复现实验环境

• 操作系统：Windows 11（宿主机）
• 容器环境：Docker Desktop
• 目标版本：jetbrains/teamcity-server:2023.11.3（漏洞版）
• 对照版本：jetbrains/teamcity-server:2023.11.4（修复版）

3.2 触发前提条件

漏洞触发并非“单一 URL 命中”，而是需要满足一组语义条件：

1. 请求首先进入一个未认证可达的处理流（常见是错误路径处理流）。
2. 请求参数中存在可影响视图/路由目标的输入（如 jsp 参数语义）。
3. 请求路径外观被构造成 JSP 相关语义（例如路径后缀和分号参数语义），使不同处理层产生解析分歧。

这三个条件叠加后，可能出现“上层鉴权判断通过，但下层路由命中受保护 API”的错位。

3.3 复现实验判定标准

本报告采用“对照验证”而非单点命中验证：

• 同一类输入在漏洞版（2023.11.3）出现未授权异常可达行为；
• 同一输入在修复版（2023.11.4）被拒绝或回到正常鉴权行为；
• 结合代码层分析，能够解释该差异与路径语义解析不一致有关。

4. 漏洞发现方法与过程

本节仅按 0day 视角还原“当时如何发现”：
从未授权基线出发，经通用语义变异发现异常，再通过旧版反编译做灰盒收敛，最后用第二轮定向样本完成复证闭环。

图4-1 0day视角发现路径：基线建模 -> 语义变异 -> 灰盒收敛 -> 定向验证。

4.1 方法论与研究约束

为了避免“先知道答案再倒推”，本次实验设定了四个约束：

1. 第一轮黑盒不直接使用公开利用样例，也不先假设参数名。
2. 先建立未授权访问基线，再做通用语义变异。
3. 只有当异常稳定出现后，才进入反编译灰盒收敛。
4. 后续公开资料仅用于结果对照，不作为前置发现线索。

对应的分析链路是：
基线建模 -> 第一轮通用变异 -> 灰盒收敛 -> 第二轮定向验证。

4.2 阶段A：未授权基线建模（0day 起点）

先回答一个最基础的问题：目标在未登录状态下“正常应该返回什么”？
我们对根路径、登录页面、REST 接口和错误路径做了基线测量，得到三类稳定外观：

• 受保护入口（如 /overview.html、/app/rest/server）：以 401 text/plain 为主。
• 登录相关页面（如 /login.html）：200 text/html。
• 错误路径（如 /does-not-exist）：404 text/html。

这一步的价值是建立“异常参照系”。后续若错误路径不再 404，或未授权请求出现受保护 API 语义，就属于高优先级异常。

4.3 阶段B：第一轮通用语义变异（不押答案）

第一轮只测试通用 Web 路径语义，不带特定可疑参数。典型样本包括：

/does-not-exist
/does-not-exist/
/does-not-exist//
/does-not-exist;x
/does-not-exist.jsp
/does-not-exist/.jsp

关键观察是：

• /does-not-exist 返回 404 text/html。
• /does-not-exist.jsp 与 /does-not-exist/.jsp 返回 401 text/plain。

这说明单纯 .jsp 外观就能改变处理流：请求从“错误页处理链”偏向“认证相关处理链”。
此时还不知道 jsp 参数，但已经能确定灰盒分析应优先关注 .jsp、视图解析、控制器参数读取。

4.4 阶段C：旧版反编译灰盒收敛

本阶段并非先验锁定 web-openapi.jar，而是先在 WEB-INF/lib 的 web-* 模块（web-core.jar、web-openapi.jar、web-startup.jar、web-diagnostic.jar）中做并行筛查。筛查关键词来自阶段B暴露出的行为特征，即 .jsp、ModelAndView、setViewName、getParameter。

检索结果显示，相关控制器线索主要集中在 jetbrains/buildServer/controllers/BaseController.java，且命中位于 web-openapi 反编译结果中；同样检索在 web-core 中未出现对应控制器命中。由此，分析重点自然收敛到 web-openapi.jar。

在 2023.11.3 旧版 web-openapi.jar 中继续反编译和阅读，可定位到 BaseController 的核心逻辑：

private void updateViewIfRequestHasJspParameter(HttpServletRequest request, ModelAndView modelAndView) {
    boolean isControllerRequestWithViewName =
        modelAndView.getViewName() != null && !request.getServletPath().endsWith(".jsp");
    String jspFromRequest = this.getJspFromRequest(request);
    if (isControllerRequestWithViewName && jspFromRequest != null && !jspFromRequest.equals(modelAndView.getViewName())) {
        modelAndView.setViewName(jspFromRequest);
    }
}

protected String getJspFromRequest(HttpServletRequest request) {
    String jspFromRequest = request.getParameter("jsp");
    if (jspFromRequest != null && (!jspFromRequest.endsWith(".jsp") || jspFromRequest.contains("admin/"))) {
        jspFromRequest = null;
    }
    return jspFromRequest;
}

同时在路径处理辅助逻辑中可见：

public static String removeSessionId(String uri) {
    int semicolon = uri.indexOf(";");
    return semicolon != -1 ? uri.substring(0, semicolon) : uri;
}

图4-2 BaseController 参数读取/视图改写与 WebUtil 分号截断的关键代码逻辑标注。

灰盒阶段的关键信息有三点：

1. jsp 参数是从代码中发现的，不是先验猜测。
2. 参数在满足约束后会参与 viewName 改写，具有控制流影响能力。
3. ; 语义处理支持“请求在不同阶段被不同解释”的机制假设。

4.5 阶段D：第二轮定向验证（灰盒驱动）

基于阶段C线索，设计“命中组 + 对照组”并实测：

图4-3 命中组与对照组稳定分离，支持“异常可重复、样本可分离”的发现结论。

命中样本响应体会出现受保护 REST 语义（如 server / users XML），而不是普通 404 页面。
这一步完成了“黑盒异常 -> 代码机制 -> 黑盒复证”的闭环。

4.6 阶段E：0day视角收尾与转入影响评估

在不依赖修复版对照、也不直接套用公开利用样例的前提下，至阶段D已经可以形成“高置信候选漏洞”的发现结论。依据主要有三点：

1. 异常可重复：错误路径在特定语义组合下可稳定偏移到受保护 REST 响应语义。
2. 机制可解释：旧版代码中存在与异常现象一致的参数读取与视图改写链路。
3. 样本可分离：命中组与对照组表现稳定分化，不是偶发抖动或单点噪声。

因此，本节到此完成的是“发现阶段闭环”：已经能回答“漏洞是否被发现、发现依据是否充分”。
后续第5节将不再讨论“如何发现”，而是转入“发现后可造成什么实际影响”，即漏洞可利用性分析。

5. 漏洞可利用性分析

5.1 影响能力边界

结合 Rapid7 在 2024-03-04 披露中给出的公开利用样例，漏洞的实际危害可以拆成一条更具体的能力链：

图5-1 从未认证访问到供应链外溢的能力升级路径。

1. 未认证调用管理 REST 接口（跨越登录边界）
   攻击者可构造类似 /does-not-exist?jsp=/app/rest/...;.jsp 的请求，把本应受保护的 REST 端点暴露给未登录请求。
   这一步代表的是直接获得对管理 API 的未认证调用能力。

2. 直接创建管理员账号（权限立刻提升到 SYSTEM_ADMIN）
   Rapid7 的公开示例显示，攻击者可向 /app/rest/users 发起创建用户请求，并在请求体中赋予 SYSTEM_ADMIN 角色。
   返回结果中的用户对象会包含管理员角色字段，这意味着攻击者无需先拿低权限账号，起手就是全局管理员。

3. 生成管理员访问令牌（持久化控制）
   除了创建管理员用户，攻击者还可针对用户 token 接口（如 /app/rest/users/id:1/tokens/...）生成管理员 token。
   一旦 token 生成成功，即使后续密码策略变更，攻击者仍可能通过 API 持续访问，形成较强持久化。

4. 接管 TeamCity 控制面（项目/构建/制品/代理）
   在管理员权限下，影响范围不是单一页面，而是整个 TeamCity 控制面：

   • 项目与构建配置修改
   • 构建任务与构建步骤变更
   • 构建代理与制品链路控制
   • 凭据、连接配置与自动化流程滥用

5. 供应链外溢风险（从 CI/CD 平台扩展到下游）
   TeamCity 是 CI/CD 中枢，一旦被管理员级接管，风险会外溢到制品发布、部署流程和下游环境，因此该漏洞的危害不止“单机被控”，而是可能演化为供应链级事件。

5.2 利用复杂度评估

• 前置门槛：仅需网络可达目标 TeamCity 服务，无需登录认证等权限。
• 交互要求：无需受害者额外交互。
• 利用稳定性：在满足语义条件时，利用链可重复触发。

对应 CVSS 9.8（Critical）的根本原因在于：攻击路径短、权限前置低、影响面高。
其典型向量可表述为：CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H，即网络可达、低复杂度、无前置权限、无用户交互且三性高影响。

5.3 在野利用与真实影响

从公开情报看，CVE-2024-27198 并非只是“理论可利用”，而是在披露后快速进入规模化利用阶段，体现出其低门槛与高收益特征。

• 美国 CISA 将其纳入 KEV（Known Exploited Vulnerabilities）目录，并标注“已用于勒索软件”：CISA 的 KEV 条目显示该漏洞 Known To Be Used in Ransomware Campaigns: Known，并要求在规定日期前完成处置（联邦机构截止 2024-03-28）。这类信号通常意味着漏洞已进入实战攻击链条且应急优先级很高。

• 厂商一手“受害者报告”：JetBrains 在后续官方文章中表示，在 Rapid7 发布完整技术细节与公开 exploit 示例之后，他们开始收到客户反馈服务器被入侵，并列举了多起代表性案例（包括勒索加密、异常管理员账号创建等）。

• 披露后数小时至数天内出现规模化扫描与入侵迹象（第三方观测汇总）：

  • Shadowserver：最早在 2024-03-04 22:00 UTC 观测到利用尝试；2024-03-05 观测到约 16 个 IP 扫描互联网寻找易受攻击实例（媒体汇总口径）。
  • GreyNoise：追踪到针对该漏洞的利用尝试，观测到数十个恶意 IP 参与活动（媒体引用口径）。
  • LeakIX：在 2024-03-06 前后报告“clear signs of rogue user creation（明显的异常用户创建迹象）”；并在 2024-03-07 的媒体报道中被引用为 1,442 个实例存在此类迹象；同一报道还提到其观测到约 1,711 个仍处于易受攻击状态的实例。

• 安全厂商遥测观测到后渗透载荷投放：Trend Micro 报告称，其遥测观测到攻击者利用 TeamCity 漏洞链在受害服务器上投放多种后渗透载荷，包括勒索软件（Jasmin）、挖矿（XMRig）、Cobalt Strike beacon、SparkRAT 等，并给出了示例网络流量与进程树证据。该类后渗透活动符合“先接管 CI/CD 中枢，再横向与变现”的现实攻击路径。

基于上述情报，我们可以确认，这个漏洞并不是“理论上很危险”，而是“已经被快速武器化并在野利用”的高危漏洞。

6. 防御机制与突破点分析

6.1 目标系统原有防御机制

• 基于会话/身份的认证过滤链。
• 基于路径与资源类型的访问控制判定。
• 对部分视图后缀（如 JSP）的特殊处理逻辑。

6.2 被突破的关键点

该漏洞并不是“认证组件完全失效”，而是认证判定输入与实际执行输入不一致：

1. 上层鉴权逻辑按“请求外观”判定可放行；
2. 下层控制器/路由按“规范化后语义”执行目标；
3. 二者在分号参数、后缀与参数覆盖语义上存在差异，形成可利用的 Alternate Path。

6.3 防御启示

• 单点鉴权不足：必须保证“鉴权路径”和“执行路径”使用同一 canonical form。
• 路径规范化前置：在最上游统一做 URI 规范化并拒绝歧义输入。
• 语义黑名单不可靠：仅靠后缀/关键字过滤（如 .jsp）容易被组合绕过。

7. 修复与缓解建议

7.1 根本修复

• 升级至 TeamCity 2023.11.4 及以上版本（官方已修复）。
• 对无法立即升级的环境，优先采用官方给出的安全补丁方案。

7.2 过渡期缓解措施

• 将 TeamCity 管理面从公网下线，限制为内网或零信任访问。
• 通过反向代理/WAF 阻断异常路径语义组合（分号参数、异常后缀、路径-参数联动模式）。
• 开启并集中审计 TeamCity 访问日志，重点关注未认证请求命中管理 API 的异常行为。

7.3 检测与应急建议

• 排查异常新增用户、异常 Token、未知插件变更。
• 核验构建配置与制品完整性，防止供应链侧后门残留。
• 在完成修复后执行“漏洞版 vs 修复版”回归对照，确保拦截策略与业务兼容。

8. 漏洞披露与社区争议

该漏洞除了技术层面的典型性外，披露过程本身也很有代表性：它把“公开透明”与“防守窗口”之间的矛盾放到了台面上。

图8-1 从漏洞报告、修复发布到在野利用确认的披露时间线与争议焦点。

8.1 更完整的披露时间线

结合 JetBrains 与 Rapid7 双方公开信息，可以把链条补得更完整一些（JetBrains 时间线为 CET）：

1. 2024-02-19：Rapid7 首次联系 JetBrains，报告 TeamCity 严重安全问题。
2. 2024-02-20：Rapid7 提交详细技术报告；JetBrains 当天复现确认。
3. 2024-02-21 ~ 2024-02-23：双方围绕披露策略出现明显分歧。JetBrains 倾向“先发布修复与补丁、邮件通知客户、提供高层次风险说明，再延后完整技术细节”；Rapid7 则坚持修复一旦公开可得，就应尽快同步完整技术披露。
4. 2024-03-01：双方继续就 CVE 标识、版本影响范围与披露节奏沟通。
5. 2024-03-04 15:00：JetBrains 发布 2023.11.4（含修复）及安全补丁插件。
6. 2024-03-04 15:05：JetBrains 向 TeamCity On-Premises 客户和安全订阅用户发送告警邮件。
7. 2024-03-04 15:59：JetBrains 发布单独安全公告，公开 CVE-2024-27198 / CVE-2024-27199、受影响范围、严重性与缓解方案，但未公开完整 root cause、利用链与复现/利用细节。
8. 2024-03-04 19:07：JetBrains 将这两个问题加入其公开安全问题页面，并使对应 CVE 记录对外可见。
9. 2024-03-04 20:23：Rapid7 发布完整技术披露文章与利用细节。
10. 2024-03-07：CISA 将 CVE-2024-27198 纳入 KEV，确认已进入在野利用态势。

需要特别区分的是，15:59 的动作是“安全公告发布”，而不是“完整技术披露”；19:07 则更接近“CVE 记录/安全问题页面正式公开”。Rapid7 文中还特别说明，JetBrains 的版本发布日志在不同时区可能显示为 3 月 3 日或 3 月 4 日，这也让“修复版到底何时已公开可得”在传播层面更容易引发争议。

8.2 从披露到在野利用的加速链条

从 SecurityWeek（引用 Shadowserver、GreyNoise、LeakIX）和 CISA 信号看，利用出现速度很快：

1. 2024-03-04：漏洞细节公开当天即出现利用尝试。
2. 2024-03-05：Shadowserver 观测到互联网扫描与探测活动上升；GreyNoise 也开始看到多源攻击尝试。
3. 2024-03-06：LeakIX 报告出现大规模异常账户创建迹象。
4. 2024-03-07：CISA 将其加入 KEV，风险等级进一步被官方“在野利用”标签确认。

这条链路的意义在于：争议不是停留在理念层，而是直接映射为防守方在最初 24~72 小时内的实战压力。

8.3 争议焦点：不是“有没有公告”，而是“公开粒度与时机”

如果只看表面，会出现一个疑问：JetBrains 既然在 2024-03-04 15:59 已经发布了安全公告，Rapid7 为什么仍然会把这一路径描述为接近其所反对的 “silent patching”？关键原因在于，双方对“公开”一词的含义并不相同。

对 Rapid7 而言，问题不在于厂商是否“完全沉默”，而在于：

1. 修复是否先于充分披露对外可见：一旦修复版已发布，具备逆向能力的攻击者就可能通过补丁比对快速理解漏洞；如果厂商此时只给高层次风险说明、而不及时公开足够的技术细节，信息优势会先落到高水平攻击者手里。
2. 防守方是否获得了足够可操作的信息：从 Rapid7 的视角看，仅有“存在认证绕过风险、请立即升级”这类摘要，并不等于防守者已经拿到与攻击者近似对等的理解能力，因此这种“先修复、后细节”的模式会被归入其反对的 silent patching 范畴。

对 JetBrains 而言，安全公告、CVE 编号、影响范围和缓解措施已经足以构成“负责任通知”；真正不应在修复刚上线时同步公开的，是完整 root cause、利用条件与 exploit 细节。因为一旦这些内容在补丁发布同时出现，会显著降低利用门槛，使尚未完成升级的客户暴露在更高风险窗口中。

因此，双方真正冲突的不是“该不该公开”，而是：

1. Rapid7 侧重点：反对“补丁先行、细节后置”，认为这会让 skilled attacker 比普通防守者更早获益。
2. JetBrains 侧重点：反对“修复与完整利用细节同步公开”，认为这会把窗口期内的攻击门槛压得过低。

换句话说，Rapid7 所说的 “silent patching” 在这里并不是指 “JetBrains 完全没有发公告”，而是指其反对“先发布修复和高层次公告，再延后完整技术披露”的披露模式；而 JetBrains 则认为，这种延迟 full disclosure 的做法恰恰是为了给客户争取升级与打补丁的缓冲时间。

8.4 本文观点

我个人观点会更偏“分层披露”。说直白一点：Rapid7 反对静默修补并没有错，但这次节奏确实偏激进。
TeamCity 这种全球广泛部署的 CI/CD 枢纽软件，企业侧真实响应要走“感知风险 -> 评估影响 -> 变更审批 -> 生产上线”这整套流程；很多组织在跨时区场景下，补丁发布后最初几小时甚至还没进入有效响应状态。

所以问题不在“该不该公开”，而在“什么时候公开到什么粒度”。更现实的路径是：

1. 先同步高价值防守信息（受影响范围、风险等级、可执行缓解措施、检测线索）；
2. 给一个可落地的升级窗口；
3. 再发布完整技术细节。

这种“分层+分时”策略，通常更有机会同时兼顾透明性与防守可操作性。

9. 结论

CVE-2024-27198 的典型性，不仅在于“未认证可达”，更在于它揭示了现代 Web 系统里一个经常被低估的问题：
安全边界不是由某个单点鉴权函数决定的，而是由整条请求处理链的一致性决定的。

从本文复现与分析过程看，这个漏洞并非传统意义上的“显式越权接口”，而是由三层因素叠加形成的语义错位：

1. 路径外观（.jsp）改变了请求进入的处理链；
2. 控制器允许请求参数参与视图目标改写；
3. 路径规范化（尤其分号语义）在不同阶段存在解释差异。

这三者叠加后，系统出现了“鉴权看到一种请求，执行命中另一种请求”的结构性问题。
也正因为如此，这类漏洞的修复重点不应停留在“补一个黑名单规则”，而应转向更稳定的工程策略：在统一的 canonical form 上完成鉴权、路由、视图解析与审计，并把跨阶段语义一致性作为安全设计约束。

从攻防视角看，CI/CD 平台的风险放大效应值得特别强调。TeamCity 一旦被绕过认证并进入管理面，影响对象不再是单台服务，而是项目配置、构建链路、制品分发与下游部署流程。这也是该漏洞被评为 Critical 并在披露后迅速武器化的根本原因。

因此，这次分析的价值不只在于还原了一个历史漏洞，更在于给出了一条可迁移的方法论：
先做行为基线，再做语义变异；先证实异常，再灰盒收敛；最后用可分离的对照样本验证机制。
这套路径对于同类“认证边界错位”问题，具有普遍适用性。

10. 参考与来源

1. Rapid7 原始漏洞披露声明（阐述了漏洞技术细节及其反静默修补的立场）:
   • CVE-2024-27198 and CVE-2024-27199: JetBrains TeamCity Multiple Authentication Bypass Vulnerabilities (FIXED)
2. JetBrains 官方安全通报（呼吁客户升级并提及了与 Rapid7 的时间线争议）:
   • Additional Critical Security Issues Affecting TeamCity On-Premises (CVE-2024-27198 and CVE-2024-27199) – Update to 2023.11.4 Now
3. JetBrains 官方回应争议的专门文章（阐述了其“延迟披露”的伦理考量及后续观测到的勒索攻击情况）:
   • Preventing Exploits: JetBrains’ Ethical Approach to Vulnerability Disclosure
4. JetBrains 披露时间线总结:
   • Insights and Timeline: Our Approach to Addressing the Recently Discovered Vulnerabilities in TeamCity On-Premises
5. 在野利用证据（政府与安全厂商）:
   • CISA Adds One Known Exploited JetBrains Vulnerability, CVE-2024-27198, to Catalog
   • CISA Known Exploited Vulnerabilities Catalog（CVE-2024-27198 条目）
   • Trend Micro: TeamCity Vulnerability Exploits Lead to Jasmin Ransomware, Other Malware Types
   • SecurityWeek: Critical TeamCity Vulnerability Exploitation Started Immediately After Disclosure
   • SC Media/SCWorld: JetBrains TeamCity critical flaw exploited; 1.4k servers compromised