2019年4月，未授问漏Oracle发布了一个CVSS评分为9.8的权访WebLogic漏洞公告。编号CVE-2019-2725。未授问漏问题出在wls9_async_response.war和wls-wsat.war这两个组件上，权访攻击者构造一个SOAP请求，未授问漏就能在未授权的权访情况下远程执行任意代码。当时国内大量企业的未授问漏WebLogic控制台直接暴露在公网，补丁还没打完，权访批量扫描工具已经满天飞了。未授问漏

这个漏洞的权访本质是反序列化。WebLogic的未授问漏WLS组件在处理SOAP消息时，会把XML数据反序列化成Java对象。权访问题在于它没有做任何身份校验——你没登录？未授问漏没关系，照样处理你的权访请求。攻击者只要在SOAP的未授问漏body里塞入一个精心构造的序列化对象，就能触发XMLDecoder的readObject方法，进而调用ProcessBuilder执行系统命令。整个过程不需要任何凭据。

我印象很深的是当时帮一个朋友看他们公司的OA系统。WebLogic 10.3.6，端口7001直接挂在公网IP上。我随手发了条/wls-wsat/CoordinatorPortType的请求，返回200。再构造一个简单的poc，服务器直接弹了计算器。他们的运维当时就愣住了——这台机器上线三年，从来没打过补丁。

受影响的版本覆盖很广：10.3.6.0、12.1.3.0、12.2.1.0、12.2.1.1、12.2.1.2、12.2.1.3。基本上那个年代主流在用的版本全中。Oracle在4月补了一次，但补丁被绕过了，10月又补了一次。中间这半年，就是攻击者的黄金窗口。

利用方式其实不复杂。一个典型的HTTP请求长这样：

POST /wls-wsat/CoordinatorPortType HTTP/1.1 Host: target:7001 Content-Type: text/xml <soapenv:Envelope> <soapenv:Header> <work:WorkContext> <java> <void class="java.lang.ProcessBuilder"> <array class="java.lang.String" length="1"> <void index="0"><string>calc</string></void> </array> <void method="start"/> </void> </java> </work:WorkContext> </soapenv:Header> </soapenv:Envelope> 

这段XML会被WebLogic解析，WorkContext里的Java对象被反序列化，ProcessBuilder.start()直接执行。没有认证，没有token，什么都没有。

更麻烦的是，这个漏洞后来被各种蠕虫化利用。2019年下半年，挖矿木马开始批量扫描7001端口。中了之后CPU跑满，服务器卡死。有些变种还会横向移动，扫描内网其他WebLogic实例。一个未授权的入口，最后变成整个内网沦陷。

修复方案说起来简单：打补丁。但现实是很多企业没法及时更新——WebLogic上跑着核心业务，重启一次影响面太大。临时缓解可以删掉wls-wsat和wls9_async_response这两个war包，或者在前端加WAF规则拦截/wls-wsat/和/_async/路径的请求。但这些都只是权宜之计。

我后来养成了一个习惯：看到7001端口开放，先测/console/login/LoginForm.jsp能不能访问。如果能，再试/wls-wsat/CoordinatorPortType。两个都通，基本就是活靶子。这个习惯帮我发现过好几个客户的遗留系统。有个客户把WebLogic装在DMZ区，说是"内部系统"，结果公网直接可达。他们安全团队一直以为防火墙挡住了，其实规则配错了。

WebLogic的未授权访问漏洞不止这一个。CVE-2020-14882、CVE-2020-14883、CVE-2023-21839，每隔一段时间就冒出来一个。核心问题都一样：组件设计时假设网络边界是安全的，没做足够的权限校验。但现实是，7001端口暴露在公网上的WebLogic实例，到现在还有几万个。Shodan上一搜一大把。

如果你现在手里还有WebLogic在跑，先确认版本，再查有没有暴露面。别等扫描器找上门才想起来打补丁。这个领域没有侥幸。