Oracle WebLogic Server RCE Deserialization Vulnerability Analysis

Oracle WebLogic Server RCE Deserialization Vulnerability Analysis

abril 20, 2018 | Adeline Zhang

On April 17th local time, Oracle released the critical patch update (CPU) advisory, which contains a fix for the high-risk WebLogic server deserialization vulnerability (CVE-2018-2628), via which attackers can remotely execute arbitrary code in an unauthorized manner.

Reference link:

Affected Versions

  • WebLogic
  • WebLogic
  • WebLogic
  • WebLogic

According to data on the NSFOCUS Threat Intelligence center (NTI), as many as 19,229 assets around the world have the WebLogic service publicly accessible from the Internet.

Technical Solutions

Self Check

Run the following commands to check whether the current WebLogic version is affected by this vulnerability:

$ cd /lopt/bea92sp2/weblogic92/server/lib

$java -cp weblogic.jar weblogic.version

Then check whether port 7001 (default port of WebLogic) is publicly accessible.

Official Fix

Oracle has fixed this vulnerability in the CPU released in April. Users are advised to download the latest update as soon as possible.

Reference link:

Note: Official patches of Oracle can be downloaded only by those with a licensed account of the software. Such users can use that account to log in to to obtain the latest patch.


To exploit the CVE-2018-2628 vulnerability, the first step is to establish a socket connection with the T3 service available on the service port of WebLogic Server. Therefore, the attack can be blocked by controlling access to the T3 protocol. WebLogic Server provides a default connection filter called This filter accepts all inbound connections. It is advisable to configure a rule through this filter to control access to T3 and T3S protocols.

  1. Access the administration console of WebLogic Server. Click base_domain in the left pane and then click the Security and Filter tabs successively to open the filter configuration page.
  2. Type in the Connection Filter field and * * 7001 deny t3 t3s in the Connection Filter Rules field.
  3. Click Save. Then this rule takes effect immediately without needing a restart.
Connection filter rules should be provided in the format of “target localAddress localPort action protocols”, where
  • target indicates one or more servers to be filtered.
  • localAddress specifies the host address of the server. (An asterisk (*) indicates all local IP addresses.)
  • localPort specifies the port that the server is listening on. (An asterisk (*) indicates all ports available on the server.)
  • action specifies the action to be taken. (The value must be allow or deny.)
  • protocols specifies the protocols to be filtered. (The value must be http, https, t3, t3s, giop, giops, dcom, and/or ftp.) If no protocol is specified, all protocols will be filtered.

NSFOCUS’s Recommendations

    Use NSFOCUS’s detection products or services to detect the vulnerability:

  1. For Internet-facing assets, use the emergency vulnerability detection service of NSFOCUS Cloud to check for the vulnerability online. The service is available at the following link:
  2. For internal assets, use NSFOCUS IDS, RSAS V6, and WVSS to check for the vulnerability:

You should upgrade your devices to the latest version by downloading upgrade packages from the preceding links before using them to detect vulnerabilities.

    Use NSFOCUS’s protection product (NIPS or NF) to protect against the vulnerability:

You should upgrade your devices to the latest version by downloading upgrade packages from the preceding links before using them for protection.

    Identification of Affected Internet Assets

NTI provides the function of querying network assets publicly accessible from the Internet. Enterprise users can use NTI to query which ports on their assets are opened, thereby finding out whether any assets are affected by this vulnerability.

NTI also provides the Internet asset audit service, enabling enterprise customers to learn the security of and changes in their assets in a timely manner. For details about the service, please contact

Technical Analysis


The T3 service decapsulates the object structure. Through successive readObject operations, it finally reaches port 1099 of the server involved in the second step and requests the malicious code.

The calculator then pops up.

WebLogic has blacklisted all PoC vulnerabilities exposed on the Internet. However, this blacklist can be bypassed through manual intervention. Let’s see how resolveProxyClass in InboundMsgAbbrev is implemented. This class is responsible for handling RMI interfaces, but it only adds java.rmi.registry.Registry to the blacklist. Therefore, attackers can easily bypass the blacklist by using other RMI interfaces.

protected Class<?> resolveProxyClass(String[] interfaces) throws IOException, ClassNotFoundException {

String[] arr$ = interfaces;

int len$ = interfaces.length;


for(int i$ = 0; i$ < len$; ++i$) {

String intf = arr$[i$];

if(intf.equals(“java.rmi.registry.Registry”)) {

throw new InvalidObjectException(“Unauthorized proxy deserialization”);




return super.resolveProxyClass(interfaces);