Attacker Value
(1 user assessed)
(1 user assessed)
User Interaction
Privileges Required
Attack Vector


Last updated April 18, 2023
Add MITRE ATT&CK tactics and techniques that apply to this CVE.
Initial Access


Vulnerability in the Oracle WebLogic Server product of Oracle Fusion Middleware (component: Core). Supported versions that are affected are, and Easily exploitable vulnerability allows unauthenticated attacker with network access via T3 to compromise Oracle WebLogic Server. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Oracle WebLogic Server accessible data. CVSS 3.1 Base Score 7.5 (Confidentiality impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N).

Add Assessment

Technical Analysis

Oracle Weblogic, and prior to the April 2023 security update are vulnerable to an unauthenticated remote code execution vulnerability due to a post deserialization vulnerability via IIOP/T3. The bug has been described in detail in a writeup by 14m3ta7k of the company GobySec at, though as of the time of writing no PoC is available.

The bug is fairly similar to CVE-2023-21839 so if you haven’t read that assessment over at, I’d recommend reading that one first and then coming back here.

When receiving a request, Weblogic will parse incoming data using BasicServerRef’s invoke() method, which will in turn call _invoke(), which then calls resolve_any() based on the passed in method name of resolve_any.

In resolve_any(), the incoming binding name is resolved using resolveObject(), which will then call lookup() based on the context information.

Based on the context information, further lookup() calls are made in several classes such as WLContextImpl, WLEventContextImpl, RootNamingNode, ServerNamingNode and BasicNamingNode. All of this will eventually lead to a resolveObject() call in BasicNamingNode class.

At this point the resolveObject() method will realize the obj parameter passed into it is not an instance of the BasicnamingNode class and the mode parameter passed in will be 1 so it will call getObjectInstance() in WLNamingManager.

Finally getObjectInstance() in WLNamingManager will call getReferent() method inside the passed in object based on the object interface type, as can be seen in the screenshot below, taken from the writeup.


For CVE-2023-21931 we specifically are interested in the LinkRef interface type, instead of the OpaqueReference interface that is used by CVE-2023-21839. In particular the following code will be called when WLNamingManager’s getObjectInstance() method finds an object that is an implementation of the LinkRef interface. Code was taken from the writeup at

package weblogic.jndi.internal;
public final class WLNamingManager {
    public static Object getObjectInstance(Object boundObject, Name name, Context ctx, Hashtable env) throws NamingException {
        if (boundObject instanceof ClassTypeOpaqueReference) {
        } else if (boundObject instanceof LinkRef) {
            String linkName = ((LinkRef)boundObject).getLinkName();
            InitialContext ic = null;
            try {
                ic = new InitialContext(env);
                boundObject = ic.lookup(linkName);  // vulnerability trigger point
            } catch (NamingException var15) {
            } finally {......}

Basically if an object is passed in as the boundObject variable that is an instance of the LinkRef interface, then String linkName = ((LinkRef)boundObject).getLinkName(); is called to get the link name, before it is later passed on to a lookup call with the line boundObject = ic.lookup(linkName) where the remote JNDI loading occurs.

What is important to note is that the LinkRef interface contains a constructor that allows one to set the linkAddrType variable that the getLinkName() function will return, so the input string, aka linkName, in the remote JNDI loading operation boundObject = ic.lookup(linkName), is entirely attacker controlled.

For reference here is what the constructor for a LinkRef class looks like, taken from

package javax.naming;
public class LinkRef extends Reference {
    static final String linkClassName = LinkRef.class.getName();
    static final String linkAddrType = "LinkAddress";

    public LinkRef(Name linkName) {
        super(linkClassName, new StringRefAddr(linkAddrType, linkName.toString()));

    public LinkRef(String linkName) {
        super(linkClassName, new StringRefAddr(linkAddrType, linkName));

    public String getLinkName() throws NamingException {
        if (className != null && className.equals(linkClassName)) {
            RefAddr addr = get(linkAddrType);
            if (addr != null && addr instanceof StringRefAddr) {
                return (String)((StringRefAddr)addr).getContent();
        throw new MalformedLinkException();

The code shows that its possible to instantiate a new LinkRef class with a linkName string and that getLinkName() will return the contents of addr, aka the linkName that was passed in.

Whilst there is presently no in the wild exploitation of this vulnerability, given CVE-2023-21839 is almost identical to this vulnerability and is being exploited in the wild, I’d imagine that this vulnerability will likely also be exploited in the wild shortly, particularly given that this vulnerability was only recently patched in April 2023, whereas CVE-2023-21839 was patched back in January 2023.

General Information


  • Oracle Corporation


  • WebLogic Server

Additional Info

Technical Analysis