How do you patch or mitigate CVE-2015-1635 (Microsoft HTTP.sys Remote Code Execution)?

CISA’s required action for CVE-2015-1635 is to apply updates per vendor instructions. In practice, find every instance of Microsoft HTTP.sys 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 Microsoft HTTP.sys safely across an enterprise

CVE-2015-1635 is one of those flaws where the practical answer is broader than “install the patch.” You need to locate every exposed Microsoft HTTP.sys instance, confirm which systems can actually receive the vendor update, and decide which ones need compensating controls while you work through change windows. For internet-facing servers, exposure reduction is part of the fix, not an afterthought.

The best rollout pattern is to treat this as a vulnerability management event, not a single server patch. Start with asset discovery, validate the presence of the affected component, then apply the vendor update or documented mitigation in a controlled sequence. Where the product cannot be updated immediately, remove public reachability or retire the service until remediation is complete.

For background on this kind of response, Zero-Day and Exploited Vulnerabilities Guide is useful because it frames emergency patching, KEV triage, and post-patch hunting as one workflow. A second useful reference is Vulnerability Management Guide, which supports the operational side of scope, prioritisation, verification, and exception handling.

How to confirm exposure and reduce blast radius first

Confirmation should be exact, not assumed from platform inventory alone. HTTP.sys is a kernel component, so you want to know which hosts actually depend on it for web servicing, reverse proxying, or related functionality, and whether those hosts are exposed to untrusted networks. That distinction matters because the fastest safe action is often to narrow exposure before the maintenance window opens.

If a server is internet-facing and cannot be patched immediately, treat that as an urgent containment problem. Remove the service from the public edge, restrict inbound access to trusted networks, or take the affected product out of service if there is no acceptable mitigation path. If you have to preserve availability, the containment decision should be documented and time-bounded.

For the official vulnerability and remediation record, check the CVE Program, the NIST National Vulnerability Database, and the CISA Known Exploited Vulnerabilities Catalog. Those sources help you anchor the patch plan to the authoritative record rather than relying on secondary summaries.

What to do after the update lands, and what to do if it does not

After the update, do not stop at “rebooted successfully.” Validate that the affected hosts are patched, that the mitigation is still in place where patching was deferred, and that no new exposure was introduced by the change. Then look for signs of earlier compromise, because exploited vulnerabilities often leave behind web-shell-like artefacts, unusual service behaviour, or suspicious child processes long after the original attack path is closed.

If patching must wait, keep the compensating control simple and explicit: reduce reachability, document the exception, set a firm expiry date, and preserve enough evidence to show that the risk was actively managed. The longer the exception exists, the more important it becomes to prove that the host was not left broadly exposed during the delay.

The practical lesson is that patching an actively exploited flaw is only half the job. The other half is proving that the vulnerable service was either removed from exposure or monitored closely enough that any prior abuse can still be found and contained.

Risk and Threat Considerations

This vulnerability matters because kernel-level HTTP exposure can give an attacker a direct path from network reachability to code execution. Once a flaw is known to be exploited in the wild, the main risk is not just compromise of one host, but the combination of public exposure, delayed patching, and incomplete hunting across the estate.

Failure mechanism: An attacker reaches an exposed HTTP.sys instance before the update or mitigation is in place, uses the flaw to execute code, and then may establish persistence or pivot to adjacent systems before defenders notice.

Impact: The result can be full server compromise, service disruption, lateral movement, and a longer dwell time if teams patch first but never check for pre-existing intrusion.

Standards & Framework Alignment

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

MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8, 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
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	HTTP.sys patching depends on timely detection and remediation of exploited vulnerabilities.
Recommendation — Prioritise exploited HTTP.sys systems and verify remediation on every exposed host.
NIST CSF 2.0	GV.RM-01 — Risk Management Strategy	KEV-driven patching requires a risk-based response strategy for exposed assets.
Recommendation — Treat KEV-listed HTTP.sys hosts as priority risk items and assign remediation timelines.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	The question is about applying vendor updates or mitigations for a known flaw.
	RA-5 — Vulnerability Monitoring and Scanning	Confirming exposure and checking for affected instances requires scanning and validation.
Recommendation — Apply vendor updates or approved mitigations and track completion to closure. Scan for every HTTP.sys instance, validate exposure, and confirm remediation after change.
MITRE ATT&CK	T1190 — Exploit Public-Facing Application	The vulnerability is exploitable through exposed HTTP service reachability.
Recommendation — Hunt exposed HTTP.sys attack paths and correlate logs for exploitation attempts.

Practitioner Guidance

What to prioritise: Patch or isolate the most exposed HTTP.sys instances first, especially systems reachable from the internet or fronting business-critical services. If two systems are equally important, the one with the wider attack surface gets priority.

What to verify: Verify both the fix and the absence of prior abuse. That means checking patch state, confirming that the mitigation was actually applied, and reviewing logs and host telemetry for suspicious activity around the exposure window.

Practitioner takeaway: For KEV-class flaws, the correct decision is usually not “patch everything eventually,” but “close the exposure path now, then prove the host was not already used.”