CVE-2023-21931

What it actually does

CVE-2023-21931 is a remotely exploitable information disclosure vulnerability in the Core component of Oracle WebLogic Server affecting supported versions 12.2.1.3.0, 12.2.1.4.0, and 14.1.1.0.0. An unauthenticated attacker with network reachability to the WebLogic T3 protocol can trigger the flaw without user interaction or credentials. Successful exploitation can expose critical data or all data accessible to the compromised WebLogic Server instance. The CVSS vector indicates network exploitation, low attack complexity, no privileges required, no user interaction, unchanged scope, and high confidentiality impact, with no direct integrity or availability impact described.

Why it matters to the business

A vulnerable WebLogic Server exposed over the network can allow an outside attacker to read sensitive application or platform data without logging in. Depending on what the WebLogic instance can access, this may include application secrets, configuration data, business records, session-related data, or backend integration information. Although this issue is not listed in CISA KEV, it has a high EPSS probability and weaponized exploit maturity, so organizations should treat internet-reachable or partner-reachable T3 services as high-priority exposure. Data theft from middleware can lead to regulatory reporting obligations, credential compromise, follow-on intrusion, customer impact, and loss of trust.

How an attack unfolds

An attacker first identifies Oracle WebLogic Server instances with the T3 protocol reachable over the network, commonly on ports such as 7001 or 7002, though deployments may use custom ports. The attacker confirms the service speaks WebLogic T3, then sends crafted T3 traffic that exercises the vulnerable Core component behavior. Because the flaw requires no authentication and no user interaction, exploitation can be attempted directly against any reachable vulnerable listener. If successful, the attacker gains unauthorized access to sensitive data available to the WebLogic Server process. The stolen information may then be used for reconnaissance, credential theft, application compromise, lateral movement, or preparation for additional attacks against the middleware or connected systems.

How to fix it

Apply the relevant Oracle Critical Patch Update that fixes CVE-2023-21931 for affected WebLogic Server versions 12.2.1.3.0, 12.2.1.4.0, and 14.1.1.0.0. Oracle did not provide fixed version numbers in the supplied input, so remediation should be validated against the applicable Oracle CPU advisory and WebLogic patch inventory for the deployed release. If immediate patching is not possible, restrict T3/T3S network access to only trusted application clients and administrative networks, block unnecessary external access to WebLogic listener ports, and consider disabling T3 where business functionality permits. Enforce network segmentation around middleware, place WebLogic behind controlled ingress points, and ensure administrative and managed-server ports are not internet-exposed. Rotate secrets that may have been accessible to WebLogic if exploitation is suspected.

How to confirm the fix worked

Confirm all WebLogic Server installations are no longer on vulnerable unpatched builds of 12.2.1.3.0, 12.2.1.4.0, or 14.1.1.0.0 by reviewing Oracle patch inventory, OPatch output, WebLogic version details, and CPU patch application records. Verify that T3/T3S access is blocked from untrusted networks using firewall rules, network ACLs, load balancer policy, and external scanning. Test that only expected trusted sources can reach WebLogic listener ports, commonly 7001 and 7002 or any custom configured listen ports. Review configuration for enabled T3 channels and confirm compensating controls remain in place after patching. Where feasible, perform an authenticated configuration review and a controlled vulnerability scan that specifically checks Oracle WebLogic CPU patch status rather than relying only on banner versions.

Typical attack path

1. Scan for Oracle WebLogic Server instances with exposed T3 listeners.
2. Fingerprint WebLogic versions or confirm T3 protocol availability.
3. Send crafted unauthenticated T3 requests targeting the vulnerable Core component behavior.
4. Retrieve unauthorized data accessible to the WebLogic Server process.
5. Analyze exposed data for secrets, credentials, configuration details, business records, or integration endpoints.
6. Use the disclosed information to support follow-on compromise, lateral movement, or data theft.

How to detect it

Investigate WebLogic access logs, server logs, diagnostic logs, network firewall logs, IDS/IPS telemetry, load balancer logs, and packet captures for evidence of T3/T3S access from unexpected or untrusted sources. Focus on inbound connections to WebLogic listen ports such as 7001 and 7002, custom WebLogic ports, and any ports exposing T3 channels. Look for T3 protocol handshakes, repeated unauthenticated connection attempts, unusual serialized payload patterns, abnormal response sizes, and access from internet scanning infrastructure. Because the vulnerability is an information disclosure issue and may not create obvious file artifacts, detection should emphasize network telemetry and WebLogic request/session anomalies. Hunt for spikes in T3 traffic around the publication date and afterward, especially from source IPs not associated with known application clients. If suspicious activity is found, assess what data and secrets the WebLogic process could access, review application logs for follow-on use of exposed credentials, and search for subsequent authentication from unfamiliar sources.

• t3 12.
• t3s 12.
• HELO:
• AS:255
• HL:19
• MS:10000000
• Oracle WebLogic Server
• weblogic.kernel.Default
• weblogic.socket
• weblogic.rjvm
• weblogic.protocol
• weblogic.protocol.t3
• weblogic.protocol.t3s
• Inbound connection from
• Connection rejected, the server is in failed state
• BEA-000449
• BEA-000450
• BEA-000402
• BEA-002606
• BEA-101020
• GET /console/login/LoginForm.jsp
• POST /console/j_security_check
• :7001
• :7002

What your security team should do

• Immediately inventory all Oracle WebLogic Server deployments and identify versions 12.2.1.3.0, 12.2.1.4.0, and 14.1.1.0.0.
• Prioritize patching internet-facing, DMZ, partner-facing, and cross-network WebLogic instances because exploitation is unauthenticated and weaponized with high EPSS likelihood.
• Restrict T3/T3S access to required trusted sources only; block public or broad internal access to WebLogic listener ports.
• Review WebLogic and network logs for suspicious unauthenticated T3 activity, unusual source IPs, and abnormal data retrieval patterns before and after patching.
• Rotate credentials, API keys, certificates, and application secrets accessible to WebLogic if compromise or suspicious access is identified.
• Add SIEM detections for WebLogic T3 handshake traffic from untrusted sources and repeated connection attempts to WebLogic listener ports.
• Confirm Oracle CPU patch levels through OPatch or equivalent tooling, and track exceptions with time-bound mitigation plans.