WebLogic Security Hardening: Deserialization Vulnerability Defense Configuration

Practical WebLogic hardening covering deserialization bugs (CVE-2015-4852, CVE-2017-10271, CVE-2019-2725), T3 disable, connection filters, and WAF integration. Shrink middleware exposure fast.

Scope

WebLogic hardening applies to Oracle WebLogic in enterprise production, especially hosts exposing management port 7001 to the internet or running old versions (10.3.6, 12.1.3, etc.). When deserialization advisories land (CVE-2015-4852, CVE-2017-10271, CVE-2019-2725), use this as the emergency hardening and long-term baseline procedure.

Prerequisites

• WebLogic Admin Console login or server shell
• Confirm WebLogic version (10.3.6 / 12.1.3 / 12.2.1.x) and patch level
• Change window; T3 changes cause brief downtime
• Domain directory and config.xml backed up

Internals

WebLogic's historical deserialization bugs come from two weaknesses. T3/IIOP is on by default with no source check, so an attacker can drop serialized objects on 7001. Some versions do not filter XMLDecoder, weblogic.jms.common.StreamMessageImpl, and similar classes, so a crafted byte stream yields RCE. Hardening is three-layer: shrink protocol exposure, source allowlist, filter malicious payloads.

Procedure

1. Version check and upgrade

cd /u01/oracle/wlserver/server/lib
java -cp weblogic.jar weblogic.version

After the version check, upgrade to the latest official CPU (Critical Patch Update). That is the complete fix for known deserialization bugs.

2. Disable T3 or restrict sources

Admin Console: Environment > Servers > select server > Protocols. Uncheck "Enable T3 Protocol". If the app requires T3, set a source allowlist under Network Security > Filter:

weblogic.security.net.ConnectionFilterImpl
127.0.0.1 * * allow
192.168.1.0/24 * * allow
0.0.0.0/0 * 7001 deny

Write the rule into the config.xml <connection-filter> node and restart. Non-allowlisted IPs hitting 7001 are dropped.

3. Remove high-risk deserialization components

# Backup, then delete client libs that ship gadgets (wlfullclient, etc.)
rm /u01/oracle/wlserver/server/lib/wlfullclient.jar
# Strip leftover XMLDecoder-related classes from WARs
find /u01/oracle/user_projects -name "*.jar" | xargs grep -l "XMLDecoder"

4. WAF rule integration

# Nginx + ModSecurity: block typical deserialization payload markers
SecRule REQUEST_URI "@rx (/(_async|wls-wsat|bea_wls_internal))" \
  "id:70001,phase:1,deny,status:403,msg:'WebLogic wls-wsat RCE'"
SecRule REQUEST_BODY "@rx (java\\.lang\\.Runtime|XMLDecoder|ProcessBuilder)" \
  "id:70002,phase:2,deny,status:403,msg:'Serialization gadget'"
# Management port: intranet only
iptables -A INPUT -p tcp --dport 7001 ! -s 10.0.0.0/8 -j DROP

Verification

• nmap -p 7001 --script t3-enum TARGET_IP — confirm T3 handshake refused
• From a non-allowlist IP: curl -v http://TARGET_IP:7001/ — confirm the filter drops the connection
• POST a malicious XML request to /wls-wsat/CoordinatorPortType — confirm WAF returns 403
• App check: T3-dependent JMS and EJB calls still work

FAQ

FAQ 1: After the latest patch, do we still disable T3?

Yes. Patches close known bugs. T3's attack surface remains; new deserialization gadgets will show up. Keep patch + T3 allowlist + WAF. Defense in depth beats a single control.

FAQ 2: The app requires T3. Cannot disable it.

Fallback: leave T3 on, but ConnectionFilter allowlist is mandatory—only app-server CIDRs. Unexpose the management port from the internet. Bind Admin Console to intranet or jump-host addresses only.

Summary

WebLogic hardening is attack-surface reduction: ship CPU patches, disable or allowlist T3/IIOP, strip high-risk components, and filter payloads with WAF plus firewall. Recheck protocol port exposure on a schedule. Put the baseline in change control and audit so it does not regress.