How do you patch or mitigate CVE-2022-22947 (VMware Spring Cloud Gateway Code Injection)?

CISA’s required action for CVE-2022-22947 is to apply updates per vendor instructions. In practice, find every instance of VMware Spring Cloud Gateway in your estate, apply the vendor security update or documented mitigation, and if no fix can be applied, remove internet exposure or take the product out of service. After patching, review logs for signs of earlier exploitation, because attackers used this flaw in the wild.

What CVE-2022-22947 requires you to do first

For this CVE, the practical priority is not just “patch it,” but to establish whether VMware Spring Cloud Gateway is present anywhere in your estate, then apply the vendor security update or documented mitigation on every exposed instance. If you cannot remediate quickly, remove internet exposure or take the product out of service until the risk is contained.

The reason this matters is that code injection flaws are usually operationally urgent, because they can turn a reachable management or gateway component into a direct execution path. For exploited vulnerabilities, the first decision is always exposure reduction, then fix deployment, then validation that the vulnerable surface is gone.

How to confirm exposure and close the gap safely

Start with asset discovery and ownership. You need to know where VMware Spring Cloud Gateway is deployed, who maintains it, whether it is internet-facing, and whether it sits behind compensating controls. That inventory step is what makes a patching decision actionable, because untracked instances are the ones most likely to miss the vendor update window.

If the platform is still needed but patching is delayed, isolate it as tightly as possible. Remove public access, restrict inbound reachability to trusted administrative paths, and treat any externally reachable deployment as a higher-priority remediation target. Where the service is no longer required, decommissioning is the cleanest mitigation because it removes the exploit path entirely.

This is also the point to follow Zero-Day and Exploited Vulnerabilities Guide for the operational sequence that fits KEV-listed issues: triage quickly, apply the documented fix, and use compensating controls only as a temporary bridge.

What to check after patching or mitigation

Once updates or mitigations are in place, do not stop at version confirmation. Review application, reverse proxy, and host logs for unexpected requests, new processes, unusual child execution, and any indicators that the gateway was used before you closed the hole. For an exploited-in-the-wild flaw, post-patch validation is part of the remediation, not a separate nice-to-have.

If the investigation shows possible compromise, widen the review to adjacent systems that the gateway could have touched, especially credentials, tokens, or session material used around the service. A code-injection path may not only affect the vulnerable process itself, it can also become a foothold for follow-on access or lateral movement if the gateway had reach into other systems.

For prioritisation of what to fix first, Vulnerability Management Guide is the natural companion because it frames remediation around exposure, exploitability, verification, and exception handling rather than around CVEs alone.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CIS Controls v8, NIST CSF 2.0, NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	This CVE calls for rapid identification, patching, and verification of exposed systems.
Recommendation — Prioritise vulnerable assets, apply remediation quickly, and verify closure after changes.
NIST CSF 2.0	PR.IP-12 — Vulnerability Management	The subject is operational vulnerability remediation and exposure reduction for an exploited CVE.
Recommendation — Track, prioritise, and remediate the vulnerable gateway before restoring normal exposure.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	The issue requires applying vendor updates or mitigation and validating vulnerable instances are addressed.
	RA-5 — Vulnerability Monitoring and Scanning	Exposure confirmation and post-patch verification depend on finding every instance and checking for residual risk.
Recommendation — Apply the vendor fix or mitigation and confirm all affected instances are remediated. Scan for exposed deployments and validate that mitigation removed the vulnerable condition.
OWASP ASVS	V15 — Secure Coding and Architecture	Code-injection flaws are an application-security failure that demands secure deployment and remediation discipline.
Recommendation — Remove the vulnerable deployment path and confirm the application no longer accepts injected input.

Practitioner Guidance

What to prioritise: Patch every reachable instance before spending time on deeper hardening work, because the exploit path is the urgent issue. If the product is internet-facing, treat that as the highest-risk condition and shorten the exception window aggressively.

What to verify: Confirm the vendor update or mitigation is actually applied on each instance, then verify the service is no longer externally reachable if patching was deferred. A successful change ticket is not enough unless the exposure and the vulnerable code path are both gone.

What practitioners underestimate: Post-patch hunting often finds more value than the patch itself, because exploitation may have occurred before remediation. Log review, process review, and a quick compromise assessment should be treated as part of the same incident-aware response.

Practitioner takeaway: For an actively exploited code-injection CVE, the safest order is discover, isolate, patch, then hunt for signs of prior abuse, because remediation without verification can leave a compromised gateway silently in place.