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. This affected all releases through 2.0.0 on Apache Tomcat, but only when the Tribes-based clustering feature was manually enabled (it was off by default). Assigned CVE-2026-66713 and resolved by complete removal of the clustering module in 40+ files (AXIS2-6097) in release 2.0.1.

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.

9. WS-Addressing response endpoints (2.0.2): A non-anonymous wsa:ReplyTo or wsa:FaultTo makes the server open a connection to an address the caller chose. Unless WS-Security is engaged to bind that endpoint reference to a trusted issuer, the WS-Addressing specification leaves it to the receiver to decide whether to honour it, so Axis2 now declines by default. allowNonAnonymousResponseEndpoints is false; replies and faults travel back down the inbound connection only. Apache CXF made the same choice in org.apache.cxf.ws.addressing.decoupled.enabled.

   Deployments that genuinely use decoupled responses — the separate-listener "Dual" clients, or a third-party callback endpoint — set it to true, and should also set httpFrontendHostUrl so the generated reply address is the real external URL rather than the local one. With the feature enabled:

   • allowedResponseEndpointSchemes permits HTTPS only. Widen it to name a transport actually used for replies.
   • The destination is screened both where the inbound header is parsed and where a server-side response acquires its transport, so the check cannot be reached around by setting the endpoint reference another way.
   • Link-local, wildcard and multicast destinations are always refused. blockPrivateNetworkResponseEndpoints additionally refuses loopback and private ranges; it is off by default because a callback inside the same private network is how most decoupled deployments are wired.
   • Redirects are not followed, so a reply endpoint cannot hand the sender a destination the policy already refused.
   • Name resolution is bounded (responseEndpointResolveTimeoutMillis) and runs on a capped pool, so a slow resolver cannot tie up request threads.

   Known limitation: the destination is resolved once to check it and again to connect, so a hostile DNS server could answer differently the second time. Closing that requires connecting to a pinned address, which the transport does not currently support. Operators in cloud environments should pair these settings with network egress controls.

10. Request body ceilings (2.0.2): The multipart/form-data and application/x-www-form-urlencoded builders read the transport stream directly, so a servlet container's post-size limit never sees the body. multipartMaxRequestSize and multipartMaxFileSize (100 MB) and formUrlEncodedMaxRequestSize (2 MB) bound them; -1 restores the previous unbounded behaviour, and either may be set per service. Multipart temp files are now deleted rather than accumulating: form-field parts as soon as their text is read, file parts once the item backing the DataHandler is unreachable.

11. OpenAPI and Swagger UI output (2.0.2): Request-controlled values are validated and encoded for the context they are written into, the served page carries a Content-Security-Policy with a per-response script nonce, and the published servers[].url is relative — resolved by the client against wherever it fetched the document — rather than derived from the request Host. openapi.serverBaseUrl pins an absolute URL where a deployment needs one.

12. Uniform metadata exposure (2.0.2): exposeServiceMetadata is now honoured by every anonymous metadata route: the ?wsdl, ?wsdl2 and ?xsd queries as before, plus the .xsd/.wsdl file routes on both the servlet and standalone HTTP paths, the named-WSDL route, and the OpenAPI/Swagger/MCP generators. A service with exposure disabled is skipped rather than refused, so it stays indistinguishable from one that is not deployed.

Report vulnerabilities to: security@apache.org

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