CVE-2020-14882 is a critical flaw in the Administration Console of Oracle WebLogic Server that lets an unauthenticated attacker run commands on the server through crafted HTTP requests. Fix it by applying the October 2020 Critical Patch Update plus the CVE-2020-14750 Security Alert patch (or a later WebLogic PSU that includes both) and keeping /console off untrusted networks.
Oracle lists the affected releases as 10.3.6.0.0, 12.1.3.0.0, 12.2.1.3.0, 12.2.1.4.0 and 14.1.1.0.0. If the console answers from the internet, treat the host as a possible compromise, not only as a patching task.
What the scanner is actually detecting
| Finding title | Scanner | How it is detected |
|---|---|---|
| Oracle WebLogic Server RCE (CVE-2020-14882) | Nessus 142594 (Web Servers family) | Remote. Nessus sends crafted HTTP requests to the console and Tenable marks it as exploited by Nessus. Covers CVE-2020-14882 and CVE-2020-14750 |
| Oracle WebLogic Server Multiple Vulnerabilities (Oct 2020 CPU) | Nessus 141807 (Misc. family) | Local, credentialed or agent check. Tenable notes it relies only on the self-reported version number. Also covers CVE-2020-14883 and several T3/IIOP flaws from the same CPU |
Oracle published no technical detail beyond the risk matrix: CVE-2020-14882 sits in the Console component, is reachable over HTTP without credentials and scores CVSS 9.8. CVE-2020-14883 is in the same component but Oracle scores it as needing high privileges (7.2). Public exploit code, including the Metasploit module “Oracle WebLogic Server Administration Console Handle RCE”, uses a path traversal to reach console pages without logging in, then a Java class instantiation in the console’s handle feature, and cites both CVEs.
The October 2020 fix was bypassed within days. Tenable describes a double-encoded traversal (%252e%252e%252f) that slipped past the patch’s filter, and on November 1, 2020 Oracle issued a Security Alert for CVE-2020-14750, which it calls related to CVE-2020-14882. That is why plugin 142594 asks for both patches. Tenable also notes that no reliable exploit exists for 10.3.6 or 12.1.3, which matters for how you read a clean remote result on those releases.
Real-world risk
The attack needs one HTTP request, no account and no user interaction, and commands run as the operating system user that runs WebLogic. On October 29, 2020, SANS Internet Storm Center reported exploitation against its honeypots within a day of a public proof of concept. CISA added CVE-2020-14882, CVE-2020-14883 and CVE-2020-14750 to the CISA Known Exploited Vulnerabilities catalog on November 3, 2021.
The limit: the console is deployed only on the Administration Server, so an attacker has to reach that server’s HTTP port. A domain that publishes only Managed Server ports through a proxy is less exposed from the internet, but anyone already inside the network can still use the flaw.
How to confirm it on the host
Check the version and patch level
For 12.1.3 and later, OPatch lists what is installed in each Oracle home. Run it for every Oracle home on the host, not only the one you expect to be live.
export ORACLE_HOME=/u01/app/oracle/middleware # your install path
$ORACLE_HOME/OPatch/opatch lsinventory
# Server version
. $ORACLE_HOME/wlserver/server/bin/setWLSEnv.sh
java weblogic.version
On Windows, run %ORACLE_HOME%OPatchopatch.bat lsinventory. WebLogic 10.3.6 uses Smart Update instead of OPatch:
cd $MW_HOME/utils/bsu
./bsu.sh -view -status=applied -prod_dir=$MW_HOME/wlserver_10.3
Compare the output with the patch numbers for your release in My Oracle Support Note 2694898.1 (October 2020 CPU) and Note 2724951.1 (CVE-2020-14750 alert).
Check whether the console is enabled and reachable
grep -E 'console-enabled|console-context-path|administration-port' $DOMAIN_HOME/config/config.xml
curl -s -o /dev/null -w '%{http_code}n' http://adminhost:7001/console/login/LoginForm.jsp
If config.xml has no console-enabled element, the default (enabled) applies. Run the curl from the same network segment the scanner used; a 200 there means the console is exposed to that segment.
Look for signs of exploitation
If HTTP access logging is enabled, search the Administration Server logs for the traversal and the class name SANS saw in attacks:
grep -iE '%252e%252e%252f|ShellSession' $DOMAIN_HOME/servers/*/logs/access.log*
Hits against an unpatched, exposed server call for incident response: review processes started by the WebLogic user, new files in the domain, and outbound connections.
How to fix CVE-2020-14882
Patch the Oracle home
Oracle’s January 2021 CPU states that it includes the CVE-2020-14750 Security Alert patches, so the practical target is the current quarterly WebLogic PSU for your release. Oracle ships Security Alert patches only for releases in Premier or Extended Support, so an older release may have no patch at all; the lasting fix there is an upgrade (see what to do when a KEV entry has no patch for your version).
- Read the patch README. Some PSUs require a newer OPatch release.
- Stop every server started from that Oracle home: Administration Server, Managed Servers and Node Manager.
- Back up the Oracle home. Oracle’s OPatch guide accepts any method, such as zip, cp -r or tar.
- Apply the patch and confirm it appears in the inventory.
tar -czf /backup/oracle_home_$(date +%F).tgz -C /u01/app/oracle middleware
cd /stage/patches/<patch_number>
$ORACLE_HOME/OPatch/opatch apply
$ORACLE_HOME/OPatch/opatch lsinventory
For 10.3.6, place the patch in the Smart Update download directory and install it by its patch ID:
cd $MW_HOME/utils/bsu
./bsu.sh -install -patch_download_dir=$MW_HOME/utils/bsu/cache_dir -patchlist=<PATCH_ID> -prod_dir=$MW_HOME/wlserver_10.3 -verbose
On Windows the scripts are opatch.bat and bsu.cmd. Start the servers again and confirm applications deploy cleanly.
Disable the console where nobody uses it
Oracle’s production lockdown guide lists the console as an internal application you can disable: set ConsoleEnabled on the DomainMBean to false, or clear Console Enabled in the domain’s advanced configuration settings in the console. WLST and the management APIs keep working. With WLST ($ORACLE_HOME/oracle_common/common/bin/wlst.sh):
connect('weblogic', '<password>', 't3://adminhost:7001')
edit()
startEdit()
cmo.setConsoleEnabled(false)
save()
activate()
disconnect()
Restart the Administration Server and repeat the curl check.
Restrict the console to admin networks
- Administration port. Enabling the domain-wide administration port (default 9002) moves administrative traffic, including the console, to one SSL port. Allow that port only from the admin subnet at the firewall.
- Proxy rules. If Apache HTTP Server or Oracle HTTP Server fronts WebLogic, keep /console from being served to users:
<Location "/console">
Require ip 10.20.30.0/24
</Location>
A proxy rule does nothing if the Administration Server’s listen port is also reachable directly, so block that port at the firewall too. These are mitigations: anyone who can still reach the console can still exploit an unpatched server.
How to verify the fix and rescan
- Run opatch lsinventory (or bsu.sh -view -status=applied) on every Oracle home and match the patches against the Oracle notes.
- Repeat the curl check from an untrusted segment. Expect a 404, a refused connection or a timeout.
- Rerun a credentialed Nessus scan so 141807 re-evaluates the version, and a remote scan from the original scanner location for 142594.
If you only restricted access, 142594 may clear from outside while 141807 keeps reporting until the patch is in.
What can break and how to roll back
| Change | What may break | Rollback |
|---|---|---|
| PSU or alert patch | Needs downtime for the whole Oracle home; test custom applications first | Stop servers, run opatch rollback -id <patch_number> (or bsu.sh -remove -patchlist=<PATCH_ID> on 10.3.6) |
| Console disabled | Admins lose the browser UI and must use WLST or scripts | Run the same WLST steps with cmo.setConsoleEnabled(true), then restart the Administration Server |
| Administration port | SSL must be configured on every server; Managed Servers must start with -Dweblogic.management.server=https://admin_server:administration_port; WLST must connect with t3s to that port | Connect with WLST over t3s to the admin port and set AdministrationPortEnabled to false |
Rolling back a patch reopens CVE-2020-14882, so keep the console restricted while you troubleshoot.
Common false positive reasons
- Stale Oracle homes. 141807 reads version data, so an old, unused install on the same host still fires. Remove it or patch it.
- Wrong asset. The IP is a load balancer or proxy, and the real Administration Server is elsewhere.
- Old scan data. The scan predates the patch window.
False negatives are the bigger risk. A renamed console context path, a firewall between the scanner and the admin port, or a 10.3.6 or 12.1.3 target (where Tenable notes no reliable exploit exists) can all leave 142594 silent on an unpatched server. The local check and the patch inventory are the better evidence.
FAQ
Is the October 2020 PSU alone enough?
No. Its fix was bypassed, which led to CVE-2020-14750. Add the Security Alert patch, or apply a PSU from January 2021 or later.
Does disabling the console close the finding?
It removes the vulnerable application from the Administration Server, so the remote check should stop firing, but 141807 reports until the Oracle home is patched.
We only expose Managed Servers. Are we safe?
Safer, not safe. The console runs on the Administration Server, which internal attackers can usually reach. Patch anyway.
Is CVE-2020-14882 actively exploited?
Yes. SANS saw attacks in October 2020, and the CVE has been in the CISA KEV catalog since November 2021.
Tracking this finding across many hosts
WebLogic tends to sit in several Oracle homes across many servers, and the hard part is proving each one was patched. SITEY, a self-hosted vulnerability management platform, imports Nessus results from an uploaded .nessus export, adds CISA KEV and FIRST EPSS context, and can re-test an individual Nessus finding such as 142594 after the patch window. Duplicates are merged per scanner, so the same host reported by Nessus and by another scanner still appears as two findings.