How do you patch or mitigate CVE-2022-22536 (SAP Multiple Products HTTP Request Smuggling)?

CISA’s required action for CVE-2022-22536 is to apply updates per vendor instructions. In practice, find every instance of SAP Multiple Products 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.

How to patch CVE-2022-22536 safely in a live SAP estate

Start by inventorying every SAP Multiple Products instance and confirming whether it is exposed in any path that can receive untrusted HTTP traffic. The practical patch step is vendor-directed update or documented mitigation, but the operational question is whether each system can be changed without breaking business flows. Where patching must wait, remove internet exposure or take the product out of service.

Because this was exploited in the wild, treat the update as an emergency change rather than routine maintenance. That means validating the exact product family in use, scheduling downtime if needed, and making sure the mitigation actually blocks the smuggling path rather than only reducing general exposure.

What to do if you cannot patch immediately

If the vendor update cannot be applied right away, the safest fallback is to shrink the reachable attack surface, ideally to zero public exposure. In practice, that often means placing the system behind restrictive network controls, disabling any unnecessary reverse-proxy or front-door exposure, and, if risk remains unacceptable, removing the product from service until remediation is complete.

For request smuggling issues, partial mitigations can be brittle because the vulnerability often depends on how different layers parse the same request. A control that looks strong at the application layer may still fail if a proxy, gateway, or load balancer interprets the traffic differently. That is why vendor guidance matters here more than generic hardening.

How to confirm the issue is gone after remediation

After patching or mitigation, review logs for signs of earlier exploitation and any unusual request patterns around the vulnerable period. Look for unexplained backend requests, anomalous header combinations, inconsistent request counts between tiers, or other signs that traffic may have been parsed differently by front-end and back-end components.

It is also worth checking whether the vulnerable service handled authenticated sessions, administrative traffic, or sensitive business functions. If so, expand the review to include session misuse, unexpected state changes, and any follow-on activity that could indicate the attacker moved beyond the initial smuggling event.

Risk and Threat Considerations

This class of flaw is dangerous because request smuggling can let an attacker desynchronise front-end and back-end request parsing, which may enable request hijacking, cache poisoning, or access to requests that were never meant to be individually reachable. In an SAP environment, that can create broad exposure because one parsing fault may sit in front of multiple products or business workflows.

Failure mechanism: A proxy, gateway, or front-end component accepts a request in one form while the back-end interprets the same bytes differently, allowing the attacker to hide or graft traffic across request boundaries.

Impact: Attackers can bypass expected controls, tamper with requests, and potentially reach internal actions or data paths that were assumed to be protected by the front door.

Standards & Framework Alignment

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

NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	PR.PS-01 — Secure Software Development	Patch and mitigation decisions for an exploited product vuln are part of secure maintenance.
	DE.CM-09 — Detection of Unauthorized or Adverse Events	Post-fix log review is needed to spot signs of exploitation before remediation.
	RS.MA-01 — Incident Management Plan Implementation	Exploited-in-the-wild flaws require coordinated containment when patching is delayed.
Recommendation — Apply secure change control to deploy the vendor fix and validate the remediated service path. Review logs and alerts for request-smuggling indicators and follow-on abuse around the affected window. Execute containment actions, including exposure removal or service shutdown, until remediation is complete.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	This CVE response is fundamentally about applying the vendor remediation or mitigation.
	RA-5 — Vulnerability Monitoring and Scanning	Finding every SAP instance and confirming exposure requires vulnerability discovery and tracking.
	AU-6 — Audit Record Review, Analysis, and Reporting	Log review for earlier exploitation maps directly to audit review after remediation.
Recommendation — Install the vendor update or approved mitigation and verify the vulnerable component is remediated. Continuously identify affected SAP assets and track whether each remains reachable or remediated. Analyze logs for suspicious request patterns and preserve evidence of possible pre-patch abuse.

Practitioner Guidance

What to prioritise: Treat exposure reduction and patch deployment as the first decision, not log review. If the system is internet-facing, remove that exposure before you spend time on deeper hunting, because active exploitation risk is driven as much by reachability as by the presence of the flaw.

What to verify: Confirm that every relevant SAP instance is covered, that the chosen mitigation matches the exact vendor guidance for that product line, and that the front-end path no longer accepts the malformed request pattern the bug depends on. If you rely on a compensating control, verify it at the protocol boundary, not just in the application.

Practitioner takeaway: For request smuggling CVEs, the decisive question is whether the vulnerable traffic path still exists. If it does, assume the flaw remains exploitable until the vendor fix or a proven exposure removal is in place.