CVE-2023-51441 is a High (7.2) improper input validation flaw in Apache Axis 1 through version 1.3 that lets users with access to the admin service perform possible server-side request forgery. Axis 1 is end of life. Migrate to another SOAP engine or apply the patch commit.
What's affected
The record says the issue affects Apache Axis through 1.3 and is marked unsupported when assigned. The Apache text states that Axis 1 has reached end of life and that the project does not expect to create an Axis 1.x release fixing this problem. Contributors who want to work toward a release are welcome.
There is therefore no fixed Axis 1 version. The two options the record gives are:
- Migrate to a different SOAP engine, such as Apache Axis 2/Java.
- Use a build of Axis with the patch from commit 685c309febc64aa393b2d64a05f90e7eb9f73e06 applied.
The record rates it 7.2 (High), vector CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H. The high privileges requirement reflects that an attacker needs access to the admin service. The record's CISA KEV flag is false. The Apache mailing list thread linked in the record did not render when fetched, so the details above come from the record text.
How to check if you're exposed
Find Axis 1 in your builds. In Maven projects, look for the org.apache.axis group:
mvn dependency:tree | grep -i "axis"
For Gradle, run the dependencies task and search the output the same way. Also search for axis jar files on disk and in container images, since old applications often bundle libraries in a lib folder:
find / -name "axis*.jar" 2>/dev/null
Then ask the question that matters for this CVE: is the Axis admin service reachable? If your web application maps the Axis servlet and the admin service is exposed to anyone beyond trusted administrators, risk is higher. A dependency scan at gold.safeguard.sh/scan can list Axis 1 components, and reachability analysis helps separate bundled but unused copies from live ones.
What to do now
- Inventory every application that bundles Axis 1.x, including transitive dependencies and container images.
- Plan migration to a supported SOAP engine such as Axis 2/Java, or to another maintained stack.
- As a stopgap, apply the patch commit referenced by Apache to a build you maintain, and test it.
- Block access to the Axis admin service from anything other than trusted administrator networks, and require strong authentication where it must stay.
- Limit outbound network access from the application servers to the destinations they genuinely need, which reduces what a server-side request can reach.
Why it matters
The record classifies the weakness as CWE-918 (Server-Side Request Forgery). In an SSRF, an attacker persuades a server to send a request on their behalf, often to an internal address that the attacker cannot reach directly, such as an internal admin interface or a cloud metadata service. The server acts as a proxy.
Here the attacker needs access to the admin service first, which explains the high privileges requirement. Even so, the rating is High because a server inside the network can reach many things. The bigger lesson is lifecycle. An unmaintained library will not get a vendor fix, so the only durable answer is replacement, and the cost of postponing grows with each new disclosure.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Will Apache release Axis 1.4 with a fix?
The Apache text says the project does not expect to create an Axis 1.x release for this problem. Plan to migrate or to carry the patch yourself.
How do I know which version is fixed?
There is none for Axis 1. The record says to migrate or to apply the patch commit named in the record to your own build, because no Axis 1.x release is expected.
Sources
- Apache Axis patch commit (listed in the record, not retrieved)
- Apache mailing list thread (listed in the record, page did not render)
- Gold page for CVE-2023-51441
Last reviewed: 19 October 2026.