Join our Newsletter — 33% off our NHI Course
Home› Guides› Oracle WebLogic Server Hardening Guide: T3 and IIOP,…
Guide Application Security

Oracle WebLogic Server Hardening Guide: T3 and IIOP, Console, Roles and Patching

← All guides
By NHI Mgmt Group, edited by Lalit Choda Updated 27 October 2026 15 min read
On this page

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 groupGlobal roleWhat the role allowsGuidance
AdministratorsAdminModify the entire configuration, view some encrypted attribute values, deploy, start and stop serversAt least two named accounts, MFA through the access path, no shared logins
DeployersDeployerDeploy and change applications and resources, view some encrypted deployment attributesCI/CD identities and release engineers
OperatorsOperatorStart, resume and stop servers; view configuration except encrypted attributesOperations staff
MonitorsMonitorRead-only access to configuration via Remote Console, WLST and MBeansMonitoring tools and auditors
AdminChannelUsersAdminChannelUserAccess the administrative channelOnly where a non-admin needs that channel
CrossDomainConnectorsCrossDomainConnectorInter-domain calls from foreign domainsOnly with cross-domain trust configured deliberately
everyone (runtime)AnonymousGranted to all users, including unauthenticated onesMust 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 (RemoteAnonymousJNDIEnabled on 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-cat and wls_utc are 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, admin and administrator; secured production mode also warns on weblogic. 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.properties or Node Manager. Never put plain-text passwords in start scripts or WLST commands; Oracle recommends storeUserConfig in WLST or boot identity files. Protect DOMAIN_HOME/security and the server security directories as secrets.
  • JDBC data source passwords: each data source holds a database account. Give each application its own least-privileged account and set RmiJDBCSecurity to Secure on 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.

LayerSettingEffect
Network channelsExternal HTTPS channel only; internal T3s channel for trusted clients; Tunneling Enabled off on every channelSeparates business traffic from RMI; tunnelling would carry T3 over HTTP ports
FirewallBlock T3, T3s, LDAP, IIOP and IIOPs at the external firewall; allow only the HTTPS channel inboundRemoves remote reach to RMI protocols
Connection filtersFilter by source IP so only domain servers and trusted clients reach T3s and the embedded LDAP portSecond control behind the firewall
Anonymous RMIRemoteAnonymousRMIT3Enabled=false, RemoteAnonymousRMIIIOPEnabled=falseUnauthenticated callers cannot invoke remote objects
Serialisation filteringJEP 290 filters (WebLogic uses the JDK mechanism)Rejects unexpected classes in incoming serialised objects
JTA allow listweblogic.transaction.loggable.allowListRestricts classes accepted by transaction logging
Internal applicationsDisable _async, WSAT (wls-wsat) and READYAPP via OptionalFeatureMBean; keep DefaultInternalServletsDisabled=trueRemoves 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.

SignalSourceWhat it can indicateATT&CK
T3 or IIOP connections from outside trusted rangesFirewall, NetFlow, connection filter denialsExposure being probed for deserialisation exploitsT1190 Exploit Public-Facing Application
Requests to /console, /management, /_async, /wls-wsat or bea_wls_internal on business portsWeb-tier and HTTP access logsConsole bypass or internal application exploitation attemptsT1190
Bursts of failed authentications, lockouts across several managed serversServer logs, audit logPassword guessing that rotates across serversT1110 Brute Force
New users, group membership changes, new deployments outside change controlAudit log (CONFIG_CHANGE_AUDIT)Persistence or malicious deploymentT1078 Valid Accounts, T1505.003 Web Shell
WebLogic JVM spawning sh, bash, cmd.exe or powershell.exe, or downloading toolsEDR, auditdCode execution after exploitationT1059 Command and Scripting Interpreter
Reads of boot.properties, SerializedSystemIni.dat or config.xml by unexpected processesFile integrity monitoring, EDRAttempt to recover encrypted domain credentialsT1552.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

  1. Install securely and patch: apply WebLogic, Java and database CPUs every quarter; subscribe to Oracle Security Alerts.
  2. Domain mode: secured production mode for new domains; for existing production domains, either switch or apply the same settings explicitly and test.
  3. Administration port enabled, TLS only, reachable from management networks only.
  4. TLS everywhere: Custom Identity and Custom Trust keystores with CA-signed certificates; no demo certificates.
  5. Channels and firewall: external HTTPS only; T3s internal; tunnelling off; T3, IIOP and LDAP blocked at the external firewall.
  6. Anonymous access off: anonymous RMI over T3 and IIOP disabled; everyone group without access to the JNDI root.
  7. Serialisation: JEP 290 filtering and the JTA allow list in place.
  8. Internal applications: disable _async, WSAT, Ready App, RESTful management and Remote Console Helper where unused; block internal context paths at the proxy.
  9. Identity: named administrators, Password Validation provider, reviewed lockout settings, enterprise directory for people.
  10. 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.
  11. Audit: Auditing provider enabled and forwarded.

Rolling it out

  1. 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.
  2. Close external T3 and IIOP first, then patch to the current CPU.
  3. 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.
  4. Promote through staging and production with WLST scripts kept in version control, so rollback is re-running the previous script and restarting.
  5. 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

ControlNIST SP 800-53 Rev. 5NIST CSF 2.0CIS Controls v8.1ISO/IEC 27001:2022 Annex A
Quarterly CPUs and Security AlertsSI-2, RA-5ID.RA-01, PR.PS-027.4 Automated application patch managementA.8.8 Management of technical vulnerabilities
Secured production mode, internal applications disabledCM-6, CM-7PR.PS-014.1 Secure configuration process; 4.8 Disable unnecessary servicesA.8.9 Configuration management
T3/IIOP blocking, channels, connection filtersSC-7, AC-17PR.IR-014.4 Implement firewall on servers; 12.2 Secure network architectureA.8.20 Network security; A.8.22 Segregation of networks
Administrators, Deployer and Monitor rolesAC-6, AC-2PR.AA-055.4 Restrict administrator privilegesA.8.2 Privileged access rights
Password validation, lockout, credential storageIA-5PR.AA-015.2 Use unique passwordsA.5.17 Authentication information
Auditing provider and SIEM forwardingAU-2, AU-12, SI-4PR.PS-04, DE.CM-098.2 Collect audit logsA.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

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

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Researched and written by the NHI Mgmt Group editorial team using AI tools, under the editorial direction of Lalit Choda. Facts are drawn from the sources listed on this page and checked by our automated quality process. Last updated 27 October 2026. Spotted an error? Use our contact page.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM and Agentic AI security. nhimg.org