Apache Axis2/Java is a SOAP and REST web services engine. It provides a message-processing pipeline with pluggable transports (HTTP/HTTPS, JMS, TCP, local), a module system for cross-cutting concerns (WS-Security via Rampart, WS-Addressing), hot-deployment of service archives (AAR/MAR), and multi-protocol serving (JSON-RPC, REST/OpenAPI, MCP) from a single service deployment. It runs inside a Jakarta Servlet container (Tomcat, Jetty, WildFly) or embedded via Spring Boot.

• Remote Code Execution (RCE) via the Axis2 framework itself — not through user-written service logic.
• XML External Entity (XXE) injection — the framework's XML parsers resolve external entities or allow DOCTYPE declarations from untrusted input, enabling file read, SSRF, or denial of service.
• Server-Side Request Forgery (SSRF) — an attacker causes the server to make requests to arbitrary internal or external hosts through framework features such as WSDL/XSD import resolution, endpoint references, or transport senders.
• Deserialization of untrusted data — framework-level Java object deserialization that can be triggered by remote input without a class whitelist. This was historically the most severe class of vulnerability in Axis2 (see CVE history below).
• Denial of Service via parser abuse — billion-laughs XML bombs, deeply nested JSON, or other input that causes unbounded memory or CPU consumption inside framework-level parsers.
• Authentication or authorization bypass — a flaw in the handler/phase pipeline that allows a message to skip an engaged security module.
• Information disclosure of server internals — stack traces, class names, or configuration details leaked to unauthenticated callers through fault messages or metadata endpoints when exposure has been disabled.
• Path traversal — a crafted service name, URI component, or WSDL import location that allows reading or writing files outside expected directories.
• Multipart/file upload abuse — unbounded file counts or sizes via multipart form data that exhaust server resources.

• Vulnerabilities in user-written services. SQL injection, broken access control, or insecure business logic in a deployed service are the service author's responsibility.
• Missing authentication on endpoints. Axis2 does not ship built-in authentication. Securing endpoints is the responsibility of the servlet container, servlet filters, or engaged security modules (Rampart).
• Hot-deployment with weak filesystem permissions. If an attacker has write access to WEB-INF/services/ or WEB-INF/modules/, they can deploy arbitrary code. This is an OS/container configuration issue.
• Service enumeration via /services/ listing. When exposeServiceMetadata is true (the default), service names are visible. This is documented behavior controllable via axis2.xml.
• Denial of service at the network level. SYN floods, slowloris, or transport-layer attacks are mitigated by the servlet container, not Axis2.
• Vulnerabilities within optional, external modules. For example, a flaw in Rampart's cryptographic implementation would be handled by the Rampart project. However, a flaw in Axis2's handler pipeline that allows the Rampart module to be bypassed is a vulnerability in Axis2.

Remote Client (untrusted input)
    |
    v
Servlet Container (TLS termination, optional authentication)
    |
    v
AxisServlet / HTTPWorker              <-- HTTP entry point
    |
    v
MessageContext created                <-- request metadata captured
    |
    v
Transport-In Phase                    <-- transport-level handlers
    |
    v
Dispatchers                           <-- route to service/operation
  (URI, SOAPAction, WS-Addressing, JSON method, HTTP location)
    |
    v
Handler Phases                        <-- global + per-service handlers
  (security modules like Rampart execute here)
    |
    v
Message Builder                       <-- deserialize body
  (SOAP, XML, JSON, MTOM, multipart/form-data)
    |
    v
MessageReceiver                       <-- invoke service method
    |
    v
Response Phases + Transport-Out       <-- serialize response, send

Axis2 exposes the following URL patterns from the servlet mapping:

Axis2's CVE history concentrates in three categories. The scan should weight these areas accordingly.

Clustering module (removed): A previous version of Axis2 included a clustering module for multi-node coordination using Apache Tribes. This module exposed a network listener that deserialized Java objects from untrusted network streams without validation, enabling Remote Code Execution (RCE) via standard deserialization gadget chains. Resolved by complete removal of the clustering module in 40+ files (AXIS2-6097).

Lesson: Any ObjectInputStream.readObject() on network input is a critical-severity finding. The remaining use of Java serialization in Axis2 is SafeObjectInputStream for context externalization, which uses a class whitelist.

CVE-2010-1632: DTD/XXE in MTOMBuilder flow. Fixed by strictly forbidding DOCTYPE declarations in SOAP and XML requests.

WSDL import parsing: wsdl4j 1.6.3 creates its own DocumentBuilderFactory without XXE hardening. Axis2 mitigates this with SecureWSDLLocator (pre-validates imported documents with a hardened SAX parser, rejects DOCTYPE, protocol-whitelists to HTTP/HTTPS, enforces size limits and timeouts) and hardened URI resolvers for xmlschema-core imports.

Lesson: Third-party XML libraries (wsdl4j, xmlschema-core) create their own parser factories that bypass framework-level hardening. Every XML parsing path — including transitive ones through dependency libraries — must be audited.

Lesson: Dependency-level CVEs are the most frequent class. The migration from commons-fileupload 1.x to commons-fileupload2 in 2.0.0 was specifically driven by CVE-2023-24998.

1. XML parsing: All DocumentBuilderFactory and SAXParserFactory instances created by the framework disable DTDs and external entities (XMLUtils.java, SecureWSDLLocator.java, DefaultEntityResolver.java).

2. WSDL import security: SecureWSDLLocator pre-parses imported documents before passing them to wsdl4j. Protocol-restricted to HTTP/HTTPS. Size-limited. Timeout-protected. Relative-path SSRF bypass patched.

3. Schema import security: URI resolvers for AAR and WAR deployments block HTTP/HTTPS/FTP/JAR/file scheme resolution to prevent SSRF via xmlschema-core's DefaultURIResolver.

4. Deserialization whitelist: SafeObjectInputStream restricts Java object deserialization to known Axis2 context classes.

5. Clustering removed: The entire clustering module (Tribes-based inter-node communication with unvalidated deserialization) has been removed from the codebase.

6. File upload limits: Migration to commons-fileupload2 enforces file count limits, preventing CVE-2023-24998-style DoS.

7. Fault detail suppression: sendStacktraceDetailsWithFaults defaults to false.

8. Fuzz testing: Jazzer-based fuzzers cover XML, JSON, HTTP header, and URL parsers. 45M+ iterations with zero crashes or security findings. See src/site/xdoc/docs/OSS-FUZZ.md. Axis2/C has an active OSS-Fuzz integration.

Report vulnerabilities to: security@apache.org

Follow the Apache Security Policy. All confirmed issues go through coordinated disclosure with CVE assignment.