CVE-2022-46364 Proof of Concept, Apache CXF MTOM SSRF in Practice

CVE-2022-46364 is an Apache CXF server-side request forgery issue in MTOM request processing. The official description is precise: vulnerable CXF versions parse the href attribute of xop:Include in MTOM requests in a way that can be abused for SSRF-style attacks against web services that take at least one parameter of any type. Apache lists the affected branches as versions before 3.4.10 and 3.5.5, and the underlying Jira issue ties the bug to SOAP services and JAX-RS services with MTOM enabled. (Apache CXF)

The reason people are searching for “CVE-2022-46364-Proof-of-the-concept” again in late March 2026 is not that the CVE suddenly became new. It is that fresh public PoC repositories appeared again in GitHub and were picked up by exploit-tracking feeds. Feedly’s CVE page showed new GitHub PoC references for this CVE within roughly the last day, including repositories named cybermaksxx/CVE-2022-46364-Proof-of-the-concept ו kasem545/CVE-2022-46364-Poc. That is exactly the kind of event that pulls an older framework bug back into the working set for red teamers, bug bounty hunters, scanner vendors, and defenders who know that public PoC circulation often changes prioritization. (Feedly)

What makes this CVE worth a careful read is that it sits at the awkward intersection of standards compliance, framework behavior, product configuration, and real exploitability. If you only read the headline, it sounds like a generic Apache SSRF. If you only read a scanner result, it looks like another version-based dependency finding. If you only read a PoC repository, it can look easier than it is. The real story is narrower and more useful: this vulnerability depends on MTOM and XOP handling, the bug exists in a specific attachment resolution path, the patch changed default URL-following behavior, and the severity you should assign in your environment depends heavily on whether the affected code path is actually reachable. (Apache Issues)

CVE-2022-46364, the official definition and the real disagreement

Apache’s own advisory calls CVE-2022-46364 an “Apache CXF SSRF Vulnerability” and rates it as important. NVD, GitHub Advisory, Open Liberty, and several downstream vendor advisories present it as 9.8 critical. The CVE record and the GitHub Advisory Database both repeat the same core description about xop:Include href parsing in MTOM requests; Open Liberty lists it as a 9.8 SSRF issue affecting the jaxws-2.2 feature; IBM’s WebSphere Liberty bulletin also assigns a 9.8 base score and ties impact to Liberty instances using the jaxws-2.2 feature. (Apache CXF)

That split is not trivial. Apache’s language signals seriousness without claiming every CXF deployment is equally exposed. NVD and downstream products surface the maximum consequence profile of an unauthenticated network bug with no user interaction. Both views can be defensible at the same time. The official databases describe the vulnerability class and worst-case impact model. Product operators, on the other hand, still have to ask whether MTOM is enabled, whether the service endpoint is reachable, whether the request body structure is accepted by the target operation, and whether the application can actually reach the internal, external, or file-based resources the attacker wants. That is an inference from the official preconditions and downstream product variance, not a contradiction of the advisories themselves. (Apache CXF)

A good example of that nuance appears in Oracle’s own treatment of the same CVE. Oracle’s April 2023 and July 2023 verbose CPU text says CVE-2022-46364 “cannot be exploited in the context” of Oracle Essbase. But Oracle’s April 2024 CPU text says the same CVE is exploitable in Oracle Commerce Platform’s Endeca Integration component, affects versions 11.3.0 through 11.3.2, and can let an unauthenticated attacker compromise the product over HTTP. Same CVE, different product context, different reachable code path, different operational consequence. That is exactly why a serious article on a PoC has to talk about preconditions instead of repeating the CVSS score as if it were the whole story. (אורקל)

Why MTOM and XOP matter to a CVE-2022-46364 proof of concept

Apache CXF’s MTOM documentation is explicit about what MTOM is for. MTOM is a SOAP mechanism for sending binary data efficiently, using XOP packages so binary content can travel as attachments instead of inflating the XML body. CXF’s documentation explains that MTOM requires annotating the data and enabling MTOM support in the runtime. It also says MTOM is not enabled by default. That detail matters because a huge number of write-ups stop at “Apache CXF SSRF” and skip the part where the relevant attachment-handling path may not be active at all on a given endpoint. (Apache CXF)

The XOP standard matters even more. The W3C XOP specification says the normalized value of the xop:Include href must be a valid URI under the cid: URI scheme. Apache’s own Jira issue for CXF-8706 says the problem was that, when used with SOAP or JAX-RS services with MTOM enabled, the unmarshaller allowed xop:Include tags to carry href attributes that allowed any protocol, while according to the W3C MTOM specification only cid: should be allowed for the href scheme. That is the difference between standards-compliant attachment reference handling and a framework bug that can turn attachment resolution into SSRF. (W3C)

This also explains why the PoC is conceptually simple even when the real exploit path is not. XOP assumes that href points to a MIME part in the same packaged request. If a framework instead accepts a remote URL, a local file path URL, or another dereferenceable scheme at that stage, the service can be tricked into fetching something the client never legitimately attached. Once you understand that, the rest of the PoC becomes a question of request shape, endpoint behavior, and observability rather than a mystery hidden behind the CVE number. (W3C)

The issue is also broader than classic JAX-WS-only mental models suggest. Snyk’s advisory notes that the vulnerability exists for SOAP web services and JAX-RS web services with MTOM enabled. Apache’s JAX-RS multiparts documentation says that CXF JAX-RS clients and endpoints can support XOP and that you need to set an mtom-enabled property on JAX-RS endpoints and clients to experiment with it. So the right question is not “Is this a SOAP CVE or a REST CVE.” The right question is “Does this endpoint accept the XOP and MTOM path that reaches the vulnerable attachment resolution logic.” (VulnGuide)

The vulnerable path, from XOP input to URL dereference

Apache’s Jira entry for CXF-8706 is unusually helpful because it exposes the affected call stack directly. The bug report says that when SOAP or JAX-RS services use MTOM, the unmarshaller allows xop:Include href attributes that accept arbitrary protocols. It then names the affected flow through AttachmentUtil.getAttachmentDataSource, JAXBAttachmentUnmarshaller.getAttachmentAsDataHandler, ו MTOMDecorator.startElement. That is a much more useful description than generic “improper input validation” language because it tells you the attack is tied to attachment resolution during binding and unmarshalling, not to some random downstream business method. (Apache Issues)

The patch commit fills in the rest. The ASF commit message for CXF-8706 says “Disable URLDataSource by default, always look inside attachments list by default.” The diff introduces a constant named org.apache.cxf.attachment.xop.follow.urls, documents that XOP href may include arbitrary URLs that “we should never follow unless explicitly allowed,” and changes AttachmentUtil.getAttachmentDataSource so URL following is controlled by a system property that defaults to false. The patch also adds tests that verify the default path no longer yields a URLDataSource, while explicitly setting the property to true restores URL following behavior. (Mail Archive)

That patch behavior tells you something important about the original flaw. The issue was not just that CXF forgot a narrow protocol denylist. The issue was that attachment resolution allowed URL-based data source behavior when the framework should have stayed inside the attachment set referenced by the package. The fix is therefore a semantic correction as much as a security correction: stop treating xop:Include as a general-purpose dereference instruction, and treat it as an attachment reference unless an operator makes a conscious and risky decision to opt back into URL following. (Mail Archive)

The same commit also changes a system test request so the example href is not a naked http://localhost:9036/policy.xsd but a cid:http://localhost:9036/policy.xsd value. That is a subtle but revealing patch detail. It reflects a design shift back toward attachment semantics rather than external retrieval semantics. Anyone writing or reviewing a PoC should pay attention to that change, because it makes clear that a successful exploit is not about any one method name or business object. It is about whether the server still follows the wrong reference semantics at the attachment-handling layer. (Mail Archive)

Why a public CVE-2022-46364 PoC can look easier than the real exploit

The new public GitHub PoC repositories are useful because they make the request anatomy visible. One repository describes the bug as an Apache CXF MTOM xop:Include SSRF issue and frames it as SSRF with potential local file inclusion effects. Its README says the issue exists because CXF incorrectly validates the href attribute inside xop:Include when processing MTOM-encoded SOAP messages and then lists examples such as file://, http://, https://, ו ftp://. Another repository README gives a leaner version: a vulnerable CXF SOAP endpoint, an SSRF URL to exfiltrate, and an example that uses file:///etc/passwd. Whether every one of those claims will hold on every target is a separate question, but these repos do reflect how the public PoC conversation is now being framed. (GitHub)

The more interesting part is the request shape visible in the code. The newer public Python PoC uses בקשות, sets סוג תוכן אל multipart/related עם application/xop+xml, declares a root part, and embeds <xop:Include href="..."/> inside a SOAP body parameter. That is not a random formatting choice. It mirrors the exact packaging model that MTOM and XOP expect. In other words, the exploit is not magic. It succeeds only if the request reaches code that treats the inbound part as XOP content and then dereferences the attacker-supplied href. (GitHub)

That is why a copied PoC often fails against real targets even when the target uses Apache CXF. The published script may target a specific service operation name, namespace, or schema shape that does not exist on your target. The target may use CXF but not expose a compatible MTOM-enabled operation. The target may accept SOAP but reject that particular XML body. The target may have outbound egress restrictions that prevent visible SSRF results. Or the target may carry the dependency in a code path that is unreachable in practice, which is exactly the kind of product-context distinction Oracle documents across different product lines. (GitHub)

A CVE-2022-46364 exploitability matrix for real environments

A serious proof of concept has to start with a matrix of conditions rather than a copy-pasted exploit. The table below is the shortest honest version of that matrix.

Condition	מדוע זה חשוב
Vulnerable Apache CXF version is present	The official advisory, NVD, and GitHub Advisory all scope the issue to versions before 3.4.10 and 3.5.5 in the affected lines.
MTOM or XOP path is actually enabled	Apache documents that MTOM is not enabled by default, and the bug specifically concerns MTOM request processing and XOP handling.
The endpoint accepts a request shape that reaches attachment unmarshalling	The Jira issue points to the attachment resolution and JAXB unmarshalling call stack, not an arbitrary code path.
The service can reach the attacker-chosen target	SSRF still needs something useful to fetch, whether that is an internal HTTP endpoint, a metadata service, or another reachable resource.
The attacker can observe the effect	Success might appear in-band in the response, or out-of-band through a listener, timing difference, or downstream access log.
Product context does not neutralize the vulnerable code path	Oracle’s treatment of the same CVE across Essbase and Oracle Commerce shows that shipping a vulnerable component is not identical to exposing an exploitable path.

The matrix is a summary of the Apache advisory, the Jira issue, the MTOM documentation, the JAX-RS XOP documentation, and downstream vendor bulletins. A scanner can usually confirm the first row. A real PoC has to answer the rest. (Apache CXF)

That distinction matters operationally. Tenable’s Red Hat JBoss EAP plugin for a downstream package set explicitly says Nessus did not test exploitability and instead relied on the application’s self-reported version number. That kind of detection is useful for exposure discovery, patch management, and SBOM triage. It is not the same as proving that your specific SOAP or JAX-RS surface is exploitable through MTOM and XOP. The difference between those two activities is exactly where a good PoC earns its keep. (Tenable®)

Same CVE, different downstream reality

IBM’s WebSphere Liberty bulletin says the issue affects Liberty when the jaxws-2.2 feature is enabled and recommends either applying interim fixes or moving to Liberty Fix Pack 23.0.0.2 or later. Open Liberty’s security vulnerability list says CVE-2022-46364 affects versions 17.0.0.3 through 23.0.0.1, is fixed in 23.0.0.2, and affects the jaxws-2.2 feature. Those are not marketing footnotes. They are exploitability clues. If the relevant web services feature is not present, the vulnerable library version may still show up in inventories without yielding a reachable attack surface. (IBM)

WildFly is useful for another reason. Its 26.1.3 release notes call out an upgrade from CXF 3.4.7 to 3.4.10 specifically to address CVE-2022-46364. That tells you the ecosystem treated this as a real enough issue to justify framework uplift in platform releases, not just an advisory that sat unread in a mailing list archive. Red Hat’s Fuse 7.12 release notes also list CVE-2022-46364 as a fixed issue. If you operate Java middleware stacks, that means your exposure analysis has to include application servers, integration buses, and embedded framework bundles rather than limiting the search to direct Maven declarations in your own code. (WildFly)

Oracle is where the nuance becomes impossible to ignore. In one place Oracle says the CVE “cannot be exploited in the context” of Essbase. In another, Oracle describes it as an easily exploitable, unauthenticated HTTP path to compromise Oracle Commerce Platform’s Endeca Integration component. That difference is exactly why “Apache CXF version present” is only the start of your analysis. The real question is whether the affected product wires the vulnerable framework features into a reachable request path with attacker-controlled input and useful outbound access. (אורקל)

Building a safe lab for CVE-2022-46364 validation

If you are going to validate this bug, do it in an isolated environment you control. The safest lab is a deliberately vulnerable CXF service running on a private network, a separate listener that records inbound fetches, and a test request that proves whether the server follows the malicious href. The goal is not to build the prettiest exploit. The goal is to confirm the exact condition that matters: does the service dereference a value that should have stayed inside the attachment package. That kind of lab lets you compare behavior before and after the fix and see how much of the exploit path depends on the application rather than on CXF alone. (Mail Archive)

Apache’s MTOM documentation gives you the key lab ingredients. For JAX-WS, CXF says you can publish an endpoint, cast its binding to SOAPBinding, and call binding.setMTOMEnabled(true). It also shows XML configuration using a jaxws:endpoint with an <entry key="mtom-enabled" value="true"/>. Its MTOM-with-JAXB documentation repeats that process and shows the same mtom-enabled property in XML. For JAX-RS, the multiparts documentation says XOP experiments require setting an mtom-enabled property on JAX-RS endpoints and clients. If your service does not do some version of that, a PoC for this CVE is unlikely to reach the vulnerable path at all. (Apache CXF)

A minimal JAX-WS lab configuration can therefore look like this:

import javax.xml.ws.Endpoint;
import javax.xml.ws.soap.SOAPBinding;

Endpoint ep = Endpoint.publish("http://127.0.0.1:8080/mtom-lab", new MyService());
SOAPBinding binding = (SOAPBinding) ep.getBinding();
binding.setMTOMEnabled(true);

Apache documents this pattern as the programmatic way to enable MTOM on a server-side endpoint. The point of showing it here is not to give you a production recipe. It is to make the precondition concrete: MTOM is a feature choice, not an automatic property of every SOAP service. (Apache CXF)

An XML-based configuration makes the same point:

<jaxws:endpoint id="helloWorld"
                implementor="demo.spring.HelloWorldImpl"
                address="http://localhost/HelloWorld">
  <jaxws:properties>
    <entry key="mtom-enabled" value="true"/>
  </jaxws:properties>
</jaxws:endpoint>

CXF’s documentation uses this shape to show how MTOM is enabled in configuration-driven deployments. That also makes it a good hunting pattern for defenders searching older codebases, Spring XML bundles, and vendor packages for reachable exposure. (Apache CXF)

For JAX-RS, Apache’s documentation is shorter but still useful. It says CXF JAX-RS endpoints can support XOP and that you need to set an mtom-enabled property on the endpoint and client sides. That means a code or configuration review should not stop at classic SOAP service classes. A JAX-RS application that uses CXF multipart and XOP features can still be relevant to this CVE if it reaches the same attachment resolution semantics. (Apache CXF)

Anatomy of a safe proof of concept request

A responsible PoC for CVE-2022-46364 does not need to be a polished exploit script. It needs to make one thing observable: whether the server follows an xop:Include href that should not be followed. The current public PoC repositories show the common structure clearly: a multipart/related request, a root part declared as application/xop+xml, a SOAP envelope, a business operation element, and an attacker-controlled href בתוך xop:Include. That structure tracks the MTOM packaging model rather than some CVE-specific trick. (GitHub)

A safe lab template looks like this:

POST /your-service HTTP/1.1
Host: lab.example
Content-Type: multipart/related; type="application/xop+xml"; start="<root>"; start-info="text/xml"; boundary="boundary"

--boundary
Content-Type: application/xop+xml; charset=UTF-8; type="text/xml"
Content-Transfer-Encoding: 8bit
Content-ID: <root>

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
                  xmlns:xop="http://www.w3.org/2004/08/xop/include"
                  xmlns:ns="http://example.com/service">
  <soapenv:Header/>
  <soapenv:Body>
    <ns:submitDocument>
      <arg0>
        <content>
          <xop:Include href="https://listener.example.invalid/mtom-proof"/>
        </content>
      </arg0>
    </ns:submitDocument>
  </soapenv:Body>
</soapenv:Envelope>

--boundary--

This template intentionally uses a placeholder listener domain and a generic operation. It is useful because it teaches the shape of the request without pretending your target will accept the same namespace, method name, or body schema as a public demo repository. The real work in any authorized test is adapting the body to the target’s actual service contract. (GitHub)

There are several things to verify before you interpret results. First, confirm that the business operation normally accepts MTOM or XOP content rather than rejecting multipart payloads outright. Second, establish a control request that uses a benign attachment reference or a valid cid: path so you can compare normal parsing behavior with malicious parsing behavior. Third, watch both the application response and the listener side. Some services will reflect data. Others will only produce timing differences, fault messages, or outbound callbacks. A good PoC is therefore less about “I got a shell” and more about “I proved the server dereferenced an attacker-controlled reference in a place where it should not have.” (W3C)

What success looks like in a CVE-2022-46364 PoC

For some targets, success is obvious. The service fetches a benign resource from your listener or lab web server, and you can see the inbound request in your logs. For others, success is indirect. A request with a routable internal URL takes longer than a request with an unroutable one. A file-based or internal-resource fetch causes a distinct fault path. A request aimed at a canary endpoint produces a header, DNS lookup, or HTTP hit that the control request never produces. The point is not to insist on one universal output. The point is to define in advance what your proof condition is. (Feedly)

Public PoC repositories tend to emphasize dramatic outcomes such as local file inclusion or cloud metadata access. Those are plausible consequences in some environments, but they are not guaranteed outcomes of the CVE by themselves. The exploit path still depends on the schemes accepted, the privileges of the service process, the presence or absence of egress controls, and the visibility of the response path. The safer and more professional way to frame a PoC is to start with SSRF confirmation and only then reason about what the server could reach from its network and privilege context. (GitHub)

This is also where a lot of weak reporting goes wrong. A version scanner sees CXF 3.5.4, flags CVE-2022-46364, and the report immediately implies that the application can read local files or hit cloud metadata. That may be true. It may also be false. Oracle’s own downstream product language proves that the same component-level CVE can be non-exploitable in one product context and materially exploitable in another. A good PoC closes that gap with evidence rather than assumption. (אורקל)

What the patch changed and why that matters operationally

The most important patch detail is the new system property org.apache.cxf.attachment.xop.follow.urls. The patch defaults it to false. That means fixed versions stop following arbitrary URL-based references during attachment resolution unless someone explicitly opts back into the old behavior. The commit comments explicitly say that the xop:Include href may include arbitrary URLs “which we should never follow unless explicitly allowed.” That is not just an implementation tweak. It is a statement of secure default behavior. (Mail Archive)

Operationally, that means upgrading is the first step, not the last. You also need to search for places where someone may have re-enabled the risky behavior. If you find the org.apache.cxf.attachment.xop.follow.urls system property set to נכון, treat it as a high-priority review item. In a modern environment, any reason to re-enable external URL following in XOP resolution should be examined hard, documented clearly, and isolated behind network controls. Most teams should never need it. (Mail Archive)

The patch also tells defenders how to build a regression test. If you send a controlled MTOM request with an xop:Include value that points at a lab listener, fixed versions should not follow it by default. If your post-patch environment still generates the callback, you either have not actually upgraded the effective framework path, you are not testing the component you think you are testing, or someone has deliberately restored the dangerous behavior. That is a clean and defensible regression model. (Mail Archive)

Detection, verification, and triage for defenders

The most reliable first pass is dependency and runtime inventory. Search Maven and Gradle declarations, container image SBOMs, embedded libraries, application server modules, and platform bundles for affected CXF versions. Then move immediately to configuration hunting. In CXF code and XML, look for mtom-enabled, SOAPBinding.setMTOMEnabled(true), @XmlMimeType, DataHandler, and JAX-RS multipart or XOP configuration. Apache’s own MTOM examples provide the strings that matter in real environments. (Apache CXF)

A simple codebase triage can start with commands like these:

grep -R "setMTOMEnabled(true)" -n .
grep -R "mtom-enabled" -n .
grep -R "@XmlMimeType" -n .
grep -R "DataHandler" -n .
grep -R "multipart/related" -n .

These patterns are not perfect, but they align with the official CXF MTOM documentation and often cut through large Java codebases surprisingly quickly. They also help separate “the library exists somewhere in the stack” from “this service actually uses the attachment and XOP features that matter for this CVE.” (Apache CXF)

The next layer is traffic and egress observation. If you are reviewing live services, look for multipart/related requests, application/xop+xml, xop:Include, and suspicious egress from SOAP or web service tiers to private, link-local, or unusual external destinations. Penligent’s own SSRF-focused article is useful here because it frames private and link-local targets as first-class SSRF validation cases rather than niche edge cases. That matches what matters operationally for this CVE: the bug is only as dangerous as the things the service can reach and the trust boundaries those requests cross. (Penligent)

A compact detection matrix helps organize that work:

שכבה	What to check
Dependency layer	CXF versions before 3.4.10 and 3.5.5 in direct dependencies, app server bundles, or vendor packages
Configuration layer	mtom-enabled, JAX-WS SOAPBinding.setMTOMEnabled(true), JAX-RS XOP enablement, @XmlMimeType, DataHandler שימוש
Request layer	multipart/related, application/xop+xml, xop:Include, unusual SOAP attachments
Runtime egress layer	Requests from service hosts to private networks, link-local ranges, metadata services, or unexpected HTTP targets
Validation layer	Controlled canary requests that distinguish normal attachment processing from external dereference behavior

That matrix comes straight out of the official MTOM and XOP documentation, the Apache advisory, and the vulnerability’s code-path description. It is intentionally conservative. It is designed to help defenders prove or disprove reachable exploitability instead of stopping at package names. (Apache CXF)

Scanner output should be read in that same spirit. Tenable’s plugin language makes clear that some detections are version-based and not active exploit tests. That is why the right workflow is usually inventory first, precondition review second, and controlled validation third. A dependency finding is enough to justify patch planning. It is not enough to support a strong statement about exploitability unless you verify the relevant path. (Tenable®)

Teams that have to do this repeatedly usually move away from one-off scripts toward an evidence-first retest workflow. Penligent’s PoC article makes a useful point here: good PoC work is about isolating the attacker-controlled input, choosing the smallest security-relevant effect, and preserving a control-versus-test comparison. That is exactly the mindset defenders should use for CVE-2022-46364 retests, whether the tool is a curl command, a custom harness, or a larger automated validation platform. (Penligent)

Hardening beyond the framework upgrade

The direct fix for Apache CXF is straightforward: move to 3.4.10, 3.5.5, or a later maintained release on a supported branch. Apache’s 3.5.5 release notes mark that release as the current patch line for 3.5.x at the time, and Apache’s later release history shows that the project continued shipping security fixes for other SSRF-adjacent issues in 2024 and 2025. The main lesson is not just “install one patch.” It is that web-service frameworks deserve regular upkeep because parser, description, and dereference behaviors continue to produce security issues over time. (Apache CXF)

The first hardening move after patching is to close unnecessary egress. If a SOAP tier has no business talking to arbitrary internet hosts, private network ranges, metadata services, or loopback-style services, block that traffic at the network layer. SSRF defense is far stronger when the application cannot physically reach the interesting targets. This is especially important because Apache CXF has had later SSRF-related advisories too, including CVE-2024-28752 on Aegis databinding and CVE-2024-29736 on WADL stylesheet parameters. Fixing one bug is good. Constraining what the service can reach is better. (Apache CXF)

The second move is to disable or retire MTOM on services that do not need it. Apache’s own MTOM documentation makes clear that MTOM is a feature that must be enabled. In many older environments it remains on because “that is how the service was always deployed,” not because anyone still needs binary attachment optimization. Legacy feature reduction is often the cheapest real risk reduction you can buy. (Apache CXF)

The third move is to treat old SOAP and JAX-WS surfaces as special assets. Open Liberty, IBM Liberty, WildFly, Red Hat Fuse, Oracle Commerce, and other downstream products all illustrate the same operational point: the vulnerable logic often lives inside platforms that teams forget are still exposed. Those interfaces may not get the same scrutiny as modern REST APIs, but they often carry privileged integration behavior, stable schemas, and legacy egress assumptions that make SSRF more valuable when it works. (IBM)

Related CVEs that help explain the pattern

CVE-2022-46364 does not sit alone in Apache CXF history. The paired 2022 release also included CVE-2022-46363, which Apache describes as a directory listing and code exfiltration issue that appears when CXFServlet is misconfigured with both static-resources-list ו redirect-query-check. That bug is not the same as MTOM SSRF, but it is still a helpful comparison because it shows how much CXF risk can depend on feature combinations and configuration context rather than a simplistic “library equals exploit” model. (Apache CXF)

Then there is CVE-2024-28752. Apache describes it as an SSRF vulnerability using the Aegis databinding, affecting versions before 4.0.4, 3.6.3, and 3.5.8, and explicitly says users of other databindings, including the default databinding, are not impacted. That is another case where the exploitability question is not answered by the framework name alone. You need to know which binding model the application actually uses. (Apache CXF)

CVE-2024-29736 pushes the same lesson into REST. Apache and NVD describe it as an SSRF issue in WADL service description handling, affecting CXF before 3.5.9, 3.6.4, and 4.0.5, but only when a custom stylesheet parameter is configured. Again, the CVE is real, the patch is real, and the exploitability depends on whether the application enables the risky feature path. Once you look at these three bugs together, a pattern becomes obvious: whenever framework code is allowed to interpret attacker-controlled references, descriptors, or externalized content locations, SSRF-class problems keep reappearing. (Apache CXF)

That is a useful design lesson for both offensive and defensive teams. Offensive teams should look for reference-resolution behavior hiding behind framework features instead of treating every SSRF as a hand-rolled application bug. Defensive teams should stop thinking of SSRF as a web-controller-only problem and start reviewing binary packaging, style transforms, documentation generators, and attachment handlers as equal citizens in threat modeling. Apache CXF’s advisory history supports that broader view. (Apache CXF)

Why this PoC still matters in 2026

The public disclosure is old. The patch is old. But the PoC still matters because the lifecycle of framework bugs is long. New PoC publication changes defender behavior, scanner signatures, and attacker attention. Feedly’s timeline for CVE-2022-46364 shows not only the new March 2026 PoC references but also later scanner detections and vendor advisories over time. That is the normal afterlife of a dependency-level issue in enterprise software: long tail, repeated rediscovery, and periodic bursts of interest whenever new exploit material or downstream product mappings appear. (Feedly)

It also matters because the internet is full of shallow CVE pages that flatten everything into “critical SSRF, upgrade now.” That advice is directionally right and analytically incomplete. The better question is whether your environment exposes an MTOM or XOP path that is reachable, observable, and useful to an attacker. If the answer is yes, the PoC matters because it closes the proof gap between version inventory and security reality. If the answer is no, the PoC still matters because it tells you exactly what conditions would have to change for the risk to become live later. (Apache CXF)

Closing thoughts

CVE-2022-46364 is a good example of how a framework vulnerability can be both overhyped and underestimated at the same time. It gets overhyped when people act as if any Apache CXF dependency automatically means full SSRF and file read in production. It gets underestimated when teams dismiss it as “just another library finding” without checking whether MTOM and XOP are actually exposed on reachable services. The official sources support a more disciplined reading: the bug is real, the patch is clear, the affected versions are known, the vulnerable path is identifiable, and exploitability depends on configuration and product context in ways that responsible operators should verify rather than guess. (Apache CXF)

The recent return of public PoC material makes now a good time to do that verification. Inventory your CXF versions. Hunt for MTOM and XOP enablement. Check whether old SOAP and JAX-WS surfaces still exist. Confirm whether your service tier can reach sensitive internal destinations. Then run a controlled regression test against a lab or clearly authorized environment. That is the difference between being surprised by a revived CVE and already having the answer when the alert lands in your queue. (Feedly)

הפניות

Apache CXF advisory for CVE-2022-46364, the canonical vendor summary and fixed-version statement. (Apache CXF)

NVD entry for CVE-2022-46364, including the 9.8 CVSS score and affected version ranges. (NVD)

Apache Jira issue CXF-8706, which shows the vulnerability description and the affected call stack. (Apache Issues)

ASF commit archive for the CXF-8706 patch, including the org.apache.cxf.attachment.xop.follow.urls property and the default behavior change. (Mail Archive)

W3C XOP specification, which states that xop:Include href must be a valid cid: URI. (W3C)

Apache CXF MTOM documentation and MTOM with JAXB documentation, useful for understanding the exact feature preconditions and enablement patterns. (Apache CXF)

Apache CXF JAX-RS multiparts documentation, which documents XOP support and the mtom-enabled property for JAX-RS endpoints and clients. (Apache CXF)

IBM WebSphere Liberty bulletin and Open Liberty vulnerability list, which show how downstream products scope the issue to JAX-WS-related features. (IBM)

WildFly 26.1.3 release note, which shows a CXF uplift to address CVE-2022-46364 in a real platform release. (WildFly)

Oracle CPU material showing product-context differences, including Oracle Essbase as non-exploitable in context and Oracle Commerce Platform as exploitable in context. (אורקל)

Related Apache CXF advisories for CVE-2022-46363, CVE-2024-28752, and CVE-2024-29736. (Apache CXF)

Penligent’s SSRF article on private and link-local destinations, which is relevant when thinking about what a successful SSRF in a service tier can actually reach. (Penligent)

Penligent’s article on building a minimal reproducible PoC, which aligns with the control-versus-test workflow that makes CVE-2022-46364 validation useful rather than noisy. (Penligent)

Penligent homepage, relevant if you are comparing evidence-driven AI-assisted retest workflows and reproducible PoC generation. (Penligent)