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:

This table carried a per-category risk rating until it was checked against an external review. Every rating said Low and none of them survived. A rating is not a property of the code — nobody can test it, and it decays silently as the code moves underneath it. What the review did engage with was the second column, because a claim that names a mechanism can be shown false. So the ratings are gone and the mechanisms stay, each with the ground it does not cover. Add a row here only if you can say both halves.

axis2_ssize_t is typedef int. It was unsigned int, which meant the -1 that axutil_strlen and axutil_string_get_length document for failure arrived as UINT_MAX, and every < 0 test written against one was unreachable — the checks compiled and could never fire.

Making it signed is not enough on its own, and this is the part worth remembering: an unsigned other operand re-hides the error return. Comparing a length against sizeof(...), a size_t, or an unsigned constant converts the signed value to a large positive one, so -1 reads as "long enough" and the guard passes. Compare against a plain signed constant, or test for the error value explicitly.

-Wsign-compare is in CFLAGS for exactly this, and the tree compiles clean under it. Note it is part of -Wextra rather than -Wall for C, so it is off by default and had to be asked for. It cannot see every case — a length assigned into a size_t variable before being compared converts silently, with nothing left for the compiler to warn about — so a length that can be -1 should be tested while it is still signed.

AXIS2_ENV_CHECK(env, return_value) is defined empty in util/include/axutil_env.h. It reads like a guard and sits at the top of several hundred functions, but it compiles to nothing, so none of those functions reject a NULL env.

It cannot simply be switched back on: 24 call sites pass void as the return value, which would expand to return void; and fail to compile. Enabling it would mean giving those sites a void-specific form and accepting an early return at roughly 620 entry points.

Treat it as documentation of intent, not as a check. Where a NULL env needs handling, write the check explicitly — axutil_strdup does, because a test asserts it.

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: security@apache.org

Follow the Apache Security Policy.