Oracle WebLogic Server has 13 entries in the CISA Known Exploited Vulnerabilities catalogue, and most of them share two causes: T3 and IIOP protocols reachable by untrusted networks, and administrative or internal applications exposed on the same ports as business traffic. Oracle's own lockdown guidance now addresses both, through secured production mode, a domain-wide administration port, connection filters, JEP 290 serialisation filtering and switches to disable internal applications. This guide turns that guidance into a practical baseline: how users, groups and roles work in WebLogic, how to protect administrators, the machine credentials a domain holds, what to log, and the network and patching discipline that keeps exploits out. It is for middleware administrators, platform engineers and security teams running WebLogic directly or underneath Oracle Fusion Middleware, E-Business Suite, PeopleSoft and other products. Settings are from the WebLogic Server 14.1.2 documentation; confirm names for older releases. Application suites built on WebLogic are covered in the Oracle E-Business Suite and Fusion Security Guide.
Key takeaways
- Never let T3 or IIOP cross the external firewall. Oracle's lockdown guide says to block T3, T3s, LDAP, IIOP and IIOPs outside it; CVE-2024-21182, added to KEV in June 2026, was exploitable by an unauthenticated attacker over T3 and IIOP.
- Use secured production mode or match it explicitly. It enables TLS and the administration port (default 9002) and blocks administrative traffic on other ports.
- Disable remote anonymous RMI and unused internal applications. Set RemoteAnonymousRMIT3Enabled and RemoteAnonymousRMIIIOPEnabled to false, and switch off _async, wls-wsat, Ready App and other features you do not use.
- Treat the Admin role as a root credential. It can view encrypted configuration values; use named administrators, Deployer and Monitor roles, a password validation provider and lockout.
- Patch every quarter, and faster for Security Alerts. Oracle ships Critical Patch Updates on the third Tuesday of January, April, July and October, and issues out-of-cycle alerts such as CVE-2020-14750 for console flaws.
How identity and access work in Oracle WebLogic Server
WebLogic security is organised by security realm: a set of providers that authenticate users, map them to groups and roles, and authorise access to resources (MBeans, applications, JNDI, JDBC, JMS). The default realm uses the embedded LDAP server as its user and group store, with the DefaultAuthenticator; enterprises usually add an LDAP or Active Directory authenticator, or an identity asserter for SSO. Resources are protected by policies that reference roles, and roles are granted to groups.
| Default group | Global role | What the role allows | Guidance |
|---|---|---|---|
| Administrators | Admin | Modify the entire configuration, view some encrypted attribute values, deploy, start and stop servers | At least two named accounts, MFA through the access path, no shared logins |
| Deployers | Deployer | Deploy and change applications and resources, view some encrypted deployment attributes | CI/CD identities and release engineers |
| Operators | Operator | Start, resume and stop servers; view configuration except encrypted attributes | Operations staff |
| Monitors | Monitor | Read-only access to configuration via Remote Console, WLST and MBeans | Monitoring tools and auditors |
| AdminChannelUsers | AdminChannelUser | Access the administrative channel | Only where a non-admin needs that channel |
| CrossDomainConnectors | CrossDomainConnector | Inter-domain calls from foreign domains | Only with cross-domain trust configured deliberately |
| everyone (runtime) | Anonymous | Granted to all users, including unauthenticated ones | Must not have access to the JNDI root context on externally visible servers |
Oracle warns not to delete the default roles, because default policies and the MBean security layer depend on them. Change who holds them instead. Two further identity defaults matter:
- Anonymous access: in secured production mode, anonymous JNDI list and modify are blocked (
RemoteAnonymousJNDIEnabledon SecurityConfigurationMBean), and the Security Warnings Report flags remote anonymous RMI over T3 and IIOP until both attributes are false. In the console, these are under Security > Advanced: deselect "Remote anonymous RMI access via IIOP" and "Remote anonymous RMI access via T3". - Lockout and password rules: configure a Password Validation provider immediately after domain creation, and review user lockout settings carried over from development. Lockouts are tracked per server, so an attacker can try each managed server in turn; secured production mode warns if the lockout threshold is weaker than the default.
- Embedded LDAP: in single-server configurations Oracle recommends closing the embedded LDAP listen port with a connection filter to protect it from brute force. For larger estates, move administrators to the enterprise directory and keep only break-glass accounts in embedded LDAP. See the LDAP Security Deep Dive Guide.
Admin roles and privileged access
Unauthenticated console flaws are among WebLogic's most exploited: CVE-2020-14882 and the related CVE-2020-14750, for which Oracle issued an out-of-cycle Security Alert with a CVSS score of 9.8, both reached the Console over HTTP. The lesson is that the administration surface must not be reachable from where attackers are.
- Domain-wide administration port: enable it (default 9002 in secured production mode). It accepts only TLS and authenticated connections, and once enabled, administrative traffic is refused on non-administration ports. On hosts running several servers, use unique listen addresses or a Local Administration Port Override.
- Restrict the port at the network: allow 9002 only from administrator subnets, bastions or privileged access workstations, and use connection filters as a second layer.
- Administration context paths: when the administration port is enabled,
console(Remote Console Helper),management(RESTful management services),bea_wls_deployment_internal/DeploymentService,bea_wls_management_internal2,bea_wls_cluster_internal,wls-catandwls_utcare served only there. Block the rest of the internal context paths listed by Oracle at the external firewall or proxy. - Disable what you do not use: if you do not manage the domain through WebLogic Remote Console, set RestfulManagementServicesMBean Enabled to false and RemoteConsoleHelperEnabled to false; disable the Management EJB with JMXMBean ManagementEJBEnabled false.
- Named administrators: Oracle advises at least two system administrator accounts with non-obvious names, avoiding
system,adminandadministrator; secured production mode also warns onweblogic. Put administrators in the Administrators group through the enterprise directory so leavers lose access centrally. - Separate duties: pipelines deploy with Deployer, operations staff use Operator, dashboards use Monitor. Very few identities need Admin.
- Restrict User Management Access: the April 2025 PSU added a servlet filter to restrict user management access; it is disabled by default, so evaluate enabling it.
See the Privileged Access Management Guide for vaulting and session recording around administrator accounts.
Integrations, API tokens and service accounts
A WebLogic domain is full of machine credentials, most of them stored encrypted in the domain configuration, which is why the domain's security files and the OS account that owns them need the same protection as the credentials themselves:
- Boot identity and Node Manager credentials: servers start with credentials from
boot.propertiesor Node Manager. Never put plain-text passwords in start scripts or WLST commands; Oracle recommendsstoreUserConfigin WLST or boot identity files. ProtectDOMAIN_HOME/securityand the serversecuritydirectories as secrets. - JDBC data source passwords: each data source holds a database account. Give each application its own least-privileged account and set
RmiJDBCSecuritytoSecureon DataSourceMBean to reject remote JDBC calls over RMI (default in secured production mode). - Keystores: replace Demo Identity and Demo Trust with Custom Identity and Custom Trust keystores holding CA-signed certificates; the Security Warnings Report flags demo certificates. Track expiry through the SecurityConfiguration MBean settings and your certificate inventory.
- LDAP authenticator bind accounts: read-only directory accounts used by authentication providers; rotate them and alert on use from anywhere but the domain hosts.
- Cross-domain and foreign JMS credentials: CrossDomainConnector trust and foreign JNDI providers carry credentials between domains. Enable them only where needed.
- Deployment pipeline identity: a Deployer-role account used by CI/CD against the administration port; store its credential in the pipeline's secret store, one per pipeline, rotated.
- Front-end plug-in trust: Oracle HTTP Server and the WebLogic Proxy Plug-in sit in front of many domains. CVE-2026-21962, an improper access control flaw in them, was added to KEV in August 2026, so patch the web tier with the domain.
The OS account matters as much as any WebLogic credential: Oracle recommends a dedicated account (its example is wls_owner) that is not an administrator, owns only the Oracle home, domain, keystore and application archive directories, is the only member of its group, and runs with umask 027 at minimum. See the Secrets Management Guide.
Network exposure: T3, IIOP, channels and serialisation
T3 is WebLogic's RMI protocol and IIOP is the CORBA-based alternative; both carry serialised Java objects, which is why deserialisation flaws such as CVE-2015-4852, CVE-2018-2628, CVE-2020-2883, CVE-2020-14644 and CVE-2023-21839 were exploitable remotely. The defence is layered.
| Layer | Setting | Effect |
|---|---|---|
| Network channels | External HTTPS channel only; internal T3s channel for trusted clients; Tunneling Enabled off on every channel | Separates business traffic from RMI; tunnelling would carry T3 over HTTP ports |
| Firewall | Block T3, T3s, LDAP, IIOP and IIOPs at the external firewall; allow only the HTTPS channel inbound | Removes remote reach to RMI protocols |
| Connection filters | Filter by source IP so only domain servers and trusted clients reach T3s and the embedded LDAP port | Second control behind the firewall |
| Anonymous RMI | RemoteAnonymousRMIT3Enabled=false, RemoteAnonymousRMIIIOPEnabled=false | Unauthenticated callers cannot invoke remote objects |
| Serialisation filtering | JEP 290 filters (WebLogic uses the JDK mechanism) | Rejects unexpected classes in incoming serialised objects |
| JTA allow list | weblogic.transaction.loggable.allowList | Restricts classes accepted by transaction logging |
| Internal applications | Disable _async, WSAT (wls-wsat) and READYAPP via OptionalFeatureMBean; keep DefaultInternalServletsDisabled=true | Removes components behind past XML and deserialisation flaws |
Oracle's reference topology puts external HTTPS on its own port behind the web-tier firewall and allows only the administration port and an internal T3s port into the application tier. Background on why serialised objects are dangerous is in the Insecure Deserialisation Guide.
Logging and detection
Enable an Auditing provider: events go to DefaultAuditRecorder.log in the domain, and in secured production mode ConfigurationAuditType defaults to CONFIG_CHANGE_AUDIT, recording configuration changes. Ship the audit log, server logs, HTTP access logs and web-tier logs to a SIEM. The Security Warnings Report scans the domain every 24 hours; export or review it on a schedule rather than only when someone opens the console.
| Signal | Source | What it can indicate | ATT&CK |
|---|---|---|---|
| T3 or IIOP connections from outside trusted ranges | Firewall, NetFlow, connection filter denials | Exposure being probed for deserialisation exploits | T1190 Exploit Public-Facing Application |
Requests to /console, /management, /_async, /wls-wsat or bea_wls_internal on business ports | Web-tier and HTTP access logs | Console bypass or internal application exploitation attempts | T1190 |
| Bursts of failed authentications, lockouts across several managed servers | Server logs, audit log | Password guessing that rotates across servers | T1110 Brute Force |
| New users, group membership changes, new deployments outside change control | Audit log (CONFIG_CHANGE_AUDIT) | Persistence or malicious deployment | T1078 Valid Accounts, T1505.003 Web Shell |
WebLogic JVM spawning sh, bash, cmd.exe or powershell.exe, or downloading tools | EDR, auditd | Code execution after exploitation | T1059 Command and Scripting Interpreter |
Reads of boot.properties, SerializedSystemIni.dat or config.xml by unexpected processes | File integrity monitoring, EDR | Attempt to recover encrypted domain credentials | T1552.001 Credentials In Files |
Measure that the baseline holds:
- CPU currency: percentage of domains on the latest quarterly Critical Patch Update within 30 days of release, and Security Alerts within 72 hours.
- Security Warnings: count of open Security Warnings Report items per domain (target zero, or documented exceptions).
- Exposure: number of hosts answering T3 or IIOP from outside trusted ranges in external scans (target zero).
- Admin population: number of identities holding Admin per domain, reviewed quarterly.
- Audit coverage: percentage of domains with an Auditing provider whose logs reach the SIEM.
Hardening baseline
- Install securely and patch: apply WebLogic, Java and database CPUs every quarter; subscribe to Oracle Security Alerts.
- Domain mode: secured production mode for new domains; for existing production domains, either switch or apply the same settings explicitly and test.
- Administration port enabled, TLS only, reachable from management networks only.
- TLS everywhere: Custom Identity and Custom Trust keystores with CA-signed certificates; no demo certificates.
- Channels and firewall: external HTTPS only; T3s internal; tunnelling off; T3, IIOP and LDAP blocked at the external firewall.
- Anonymous access off: anonymous RMI over T3 and IIOP disabled; everyone group without access to the JNDI root.
- Serialisation: JEP 290 filtering and the JTA allow list in place.
- Internal applications: disable _async, WSAT, Ready App, RESTful management and Remote Console Helper where unused; block internal context paths at the proxy.
- Identity: named administrators, Password Validation provider, reviewed lockout settings, enterprise directory for people.
- OS: dedicated non-administrator account, umask 027, sole member of its group, permissions restricted to WebLogic directories; for ports below 1024 use NAT or post-bind UID and GID switching rather than running as root.
- Audit: Auditing provider enabled and forwarded.
Rolling it out
- Inventory: list every domain, including those embedded in Oracle applications and third-party products, with WebLogic version, CPU level and exposure. See the Attack Surface Management Guide.
- Close external T3 and IIOP first, then patch to the current CPU.
- Clear the Security Warnings Report in a test domain, and run application regression tests: disabling anonymous RMI, internal applications and tunnelling can break legacy clients.
- Promote through staging and production with WLST scripts kept in version control, so rollback is re-running the previous script and restarting.
- Monitor: forward audit logs, schedule external exposure scans and review the warnings report each month.
Decision guidance
- Secured production mode or explicit settings: Oracle recommends secured production mode, especially for new environments. For established domains with legacy RMI clients, apply the settings one by one so you can identify which change breaks which client.
- T3s inside the network or not at all: if no external Java client needs RMI, keep T3s on an internal channel restricted to domain servers. If partners need RMI, publish an HTTPS API instead where possible.
- Small versus large estates: a single domain can be hardened by hand; dozens of domains under Oracle applications need a scripted baseline, CPU tracking per product and coordination with the application vendor's certification of each CPU.
Common misconfigurations
- T3 on the same port as HTTP, reachable from the internet: the default listen port serves several protocols unless channels separate them, so a web port often answers T3 too. This is the precondition for most KEV-listed WebLogic deserialisation flaws.
- Console exposed: CVE-2020-14882, CVE-2020-14883 and CVE-2020-14750 are all KEV-listed console flaws reached over HTTP; an administration port restricted to management networks removes that path.
- Development settings in production: development mode, demo certificates and weak lockout settings carried into production domains. The Security Warnings Report exists to catch these.
- Unused optional features left on: _async and wls-wsat are optional features most domains never use; leaving them enabled keeps components reachable that have been the target of past XML and deserialisation exploits.
- Shared weblogic account: one administrator login used by people and scripts, with its password in start scripts. Use named accounts, boot identity files and storeUserConfig.
- Patching the domain but not the web tier: Oracle HTTP Server and the Proxy Plug-in are separate components with their own KEV entry.
Framework mapping
| Control | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 | CIS Controls v8.1 | ISO/IEC 27001:2022 Annex A |
|---|---|---|---|---|
| Quarterly CPUs and Security Alerts | SI-2, RA-5 | ID.RA-01, PR.PS-02 | 7.4 Automated application patch management | A.8.8 Management of technical vulnerabilities |
| Secured production mode, internal applications disabled | CM-6, CM-7 | PR.PS-01 | 4.1 Secure configuration process; 4.8 Disable unnecessary services | A.8.9 Configuration management |
| T3/IIOP blocking, channels, connection filters | SC-7, AC-17 | PR.IR-01 | 4.4 Implement firewall on servers; 12.2 Secure network architecture | A.8.20 Network security; A.8.22 Segregation of networks |
| Administrators, Deployer and Monitor roles | AC-6, AC-2 | PR.AA-05 | 5.4 Restrict administrator privileges | A.8.2 Privileged access rights |
| Password validation, lockout, credential storage | IA-5 | PR.AA-01 | 5.2 Use unique passwords | A.5.17 Authentication information |
| Auditing provider and SIEM forwarding | AU-2, AU-12, SI-4 | PR.PS-04, DE.CM-09 | 8.2 Collect audit logs | A.8.15 Logging |
The relevant ATT&CK techniques are T1190 Exploit Public-Facing Application, T1505.003 Web Shell, T1110 Brute Force, T1078 Valid Accounts and T1552.001 Credentials In Files.
Practitioner checklist
- Inventory every WebLogic domain with version, CPU level, owning application and exposure.
- Block T3, T3s, IIOP, IIOPs and LDAP at the external firewall and confirm with an external scan.
- Enable the domain-wide administration port and restrict it to management networks.
- Set RemoteAnonymousRMIT3Enabled and RemoteAnonymousRMIIIOPEnabled to false; remove everyone access to the JNDI root.
- Disable _async, WSAT, Ready App and unused management interfaces; block internal context paths at the proxy.
- Replace demo keystores with Custom Identity and Custom Trust; enable JEP 290 filtering.
- Use named administrators, Deployer for pipelines and Monitor for tools; add a Password Validation provider and review lockout.
- Run as a dedicated non-administrator OS account with umask 027; keep passwords out of scripts.
- Enable an Auditing provider and forward logs; review the Security Warnings Report monthly.
- Apply each quarterly CPU and every Oracle Security Alert for WebLogic and the web tier.
Standards and references
- Oracle: Securing a Production Environment for Oracle WebLogic Server 14.1.2, Getting Started
- Oracle: Lock Down WebLogic Server 14.1.2
- Oracle: WebLogic Server Users, Groups and Security Roles
- Oracle: About the Security Checkup Tool
- Oracle: Critical Patch Updates, Security Alerts and Bulletins
- Oracle: Security Alert CVE-2020-14750
- CISA: Known Exploited Vulnerabilities Catalog
- NIST: SP 800-53 Rev. 5
Related NHI Mgmt Group resources: Oracle E-Business Suite and Fusion Security Guide · Apache Tomcat Hardening Guide · Java and Spring Security Guide · Insecure Deserialisation Guide