Apache Axis2/C is a SOAP and REST web services engine implemented in C. It provides HTTP/1.1 and HTTP/2 transports, dual XML parsers (Guththila and libxml2), native JSON processing (via json-c), MTOM/XOP attachment handling, and hot-deployment of services. It runs as a standalone HTTP server or as an Apache httpd module (mod_axis2).

Being a C implementation, memory safety vulnerabilities (buffer overflows, use-after-free, format strings, integer overflows) are in scope in addition to the logical vulnerabilities shared with Axis2/Java.

For detailed deployment hardening guidance, see docs/SECURITY.md.

• Remote Code Execution (RCE) — buffer overflow, format string, or other memory corruption exploitable by a remote attacker through the Axis2/C framework.
• Memory safety violations — heap/stack buffer overflows, use-after-free, double-free, or null pointer dereferences reachable from untrusted input.
• XML External Entity (XXE) injection — the XML parser resolves external entities from untrusted input, enabling file read or SSRF. (Guththila is inherently immune; libxml2 requires hardening.)
• Server-Side Request Forgery (SSRF) — the server makes requests to arbitrary hosts due to attacker-controlled URLs in WSDL imports, external entities, or client-side HTTP transport.
• Denial of Service via parser abuse — XML bombs, deeply nested JSON (>64 levels), or payloads exceeding size limits (>10MB) that crash the process or exhaust memory.
• Integer overflow — size calculations in buffer allocation or payload processing that wrap around, leading to undersized buffers and subsequent overflows.
• Format string vulnerabilities — user-controlled data passed as the format argument to printf-family functions or logging macros.
• Information disclosure — stack traces, internal paths, or configuration details leaked in SOAP faults or HTTP error responses.
• TLS/SSL vulnerabilities — acceptance of deprecated protocols (SSLv2, SSLv3, TLS 1.0/1.1) or weak cipher suites in the HTTP client transport.

• Vulnerabilities in user-written services. Input validation, SQL injection, and business logic flaws in deployed service implementations are the service author's responsibility.
• Missing authentication. Axis2/C does not ship built-in authentication. Securing endpoints is the responsibility of Rampart/C, the web server (Apache httpd), or a reverse proxy.
• Hot-deployment with weak filesystem permissions. If an attacker can write to the services directory, they can deploy arbitrary shared libraries. This is an OS-level access control issue.
• Denial of service at the network level. SYN floods, slowloris, and connection exhaustion are mitigated by Apache httpd or the network infrastructure, not by Axis2/C.
• Vulnerabilities in optional, external modules. Rampart/C (WS-Security) is a separate project.
• The standalone HTTP server in production. It is intended for development/testing. Production deployments should use mod_axis2 behind a reverse proxy.

Remote Client (untrusted input)
    |
    v
Apache httpd (TLS, connection limits, WAF)
  or standalone axis2_http_server (dev only)
    |
    v
mod_axis2 / HTTP request processor
    |
    v
Content-Type routing:
  JSON → json-c parser (HTTP/2) or JSON→AXIOM reader (HTTP/1.1)
  XML  → Guththila (default) or libxml2
    |
    v
AXIOM object model
    |
    v
Dispatchers → route to service/operation
    |
    v
Handler phases (Rampart/C security module executes here)
    |
    v
Message Receiver → invoke service function
    |
    v
Response serialization → transport out

As a C codebase, memory safety is a primary concern:

Production builds should use:

CFLAGS="-fstack-protector-strong -D_FORTIFY_SOURCE=2 -fPIE -Wformat -Wformat-security"
LDFLAGS="-pie -Wl,-z,relro,-z,now"

AddressSanitizer is available for development via --enable-asan.

• TLS 1.0/1.1 completely disabled in client transport
• Strong cipher suites enforced (AEAD + forward secrecy)
• JSON payload size limits (10MB) and depth limits (64 levels) added
• libxml2 entity loader override blocks all external entity resolution
• OSS-Fuzz integration with 5 fuzz targets (XML, JSON x2, HTTP headers, URLs)
• Integer overflow and size_t consistency fixes from Gemini code review

Axis2/C has an active OSS-Fuzz integration with 5 fuzz targets:

Additionally, fuzz_finbench tests the FinancialBenchmarkService at the application level with integer overflow and boundary value inputs.

Local fuzzing validated with 8M+ iterations and zero ASAN errors. See docs/OSS-FUZZ.md for details.

Monthly CVE checks run via GitHub Actions (.github/workflows/cve-check.yml).

Report vulnerabilities to: [email protected]

Follow the Apache Security Policy.