FreeBuf.COM网络安全行业门户，每日发布专业的安全资讯、技术剖析。

概述

CVE-2025-30762 与以往的CVE-2024-21006、CVE-2024-21216相似，通过绑定指向恶意ldap服务器的Reference实例，在调用Context.lookup对JNDI上下文的对象实例进行查找时，触发指向ldap服务器的恶意代码的执行。

漏洞允许攻击者无需身份验证，仅通过T3或IIOP协议进行网络访问，便可攻击Oracle WebLogic Server。成功利用此漏洞后，攻击者能够未经授权访问WebLogic Server中所有可访问的关键数据，合理构造可实现出网RCE。

分析

部署环境

• Linux Ubuntu
• java的jdk版本小于等于1.8.191
• weblogic server版本12.2.1.4.0

调用分析

这次的触发点在于BasicNamingNode#LookupShareable的object = this.getContinuationCtx(object, prefix, restOfName, env).lookup(restOfName);

看这个代码结构，非常像过去的反序列化系列漏洞所需的Context.lookup结构吧。过去21006，21216等几个洞都是在找后面的一些漏洞点，但是貌似漏了这个地方。

如果能获取合适的Content类，且lookup()参数可控，那么就能攻下了。这次的洞就是这个问题。前者通过this.getContinuationCtx(object, prefix, restOfName, env）获取需要的Context类；后者Context.lookup()解析restOfName，传入配置好的地址实现利用。
接下来深入，this.getContinuationCtx(object, prefix, restOfName, env）。由于传入的Reference类提供了sharableURLContextFactory的信息，这里会到达这个类的getObjectInstance类获取SharableContext类的实例并返回。这个类就是我们需要的Content类。调用栈如下。

获取SharableContext类实例后，程序返回触发点的BasicNamingNode#LookupShareable()函数，运行SharableContext.lookup(restOfName)。这里restOfName由于经过精心调整，再通过一个简单的检测Url函数，正好就是恶意ldap服务器地址。

而SharableContext本身没有重写lookup函数，会调用其父类，获取InitialContext类并运行其最终到达LdapURLContext#lookup()方法，这里lookup传入的方法就是恶意服务器地址。经过解析后就会访问ldap服务器了。

在这个过程中，restOfName的输入是要做一些处理的。可以看到BasicNamingNode#LookupShareable()里面传入的name字符串就被拆分成两部分，后者才是需要的restOfName。这是一个拆分点。

此外name传入过程中也有一些处理，name信息是以NameComponent类包装传输的，如果直接传入ldap地址是会被解析输入信息导致被过滤（悲）。

但是NameComponent类偏偏提供了一个kind字段，这kind字段就能用来存URL了（喜），在解析的时候可以把URL拼接进字符串。所以我们需要配合修改的wlfullclient.jar包使用，可以在Jar包中修改了Utils#nameToName()函数，将ldap服务器地址放入NameComponent类的kind字段，从而绕过的服务器的修改检测。

除此之外应该还有一些零零散散的细小过滤，多测试测试就清楚了，这里和POC一起略了，欢迎各位佬学习交流。

By Sleysolu Sinelesmeas

本文为 独立观点，未经授权禁止转载。
如需授权、对文章有疑问或需删除稿件，请联系 FreeBuf 客服小蜜蜂（微信：freebee1024）