Azure Linux and CVE-2025-54090: Not the Only Microsoft Affected

The short answer is: No — Azure Linux is not necessarily the only Microsoft product that can include the vulnerable Apache HTTP Server code, but it is the only Microsoft product Microsoft has publicly attested so far to include the affected library; that attestation is authoritative for Azure Linux and actionable for customers who run it, yet it is not a blanket guarantee that no other Microsoft-supplied image, appliance, container base, or managed runtime could carry the same vulnerable component.

---

Background / Overview​

CVE-2025-54090 (tracked in public advisories under the Apache HTTP Server 2.4.x family) is a configuration-dependent flaw that affects Apache HTTP Server releases in the 2.4.26 → 2.4.63 range and was fixed in Apache HTTP Server 2.4.64. The issue arises when certain reverse-proxy configurations (notably where mod_proxy and HTTP/2 proxying are in use with ProxyPreserveHost enabled) exercise a code path that can trigger a reachable assertion inside modproxy, resulting in worker process aborts and a denial-of-service (availability) impact. Operators are therefore advised to treat exposed proxies with these characteristics as high priority for remediation.
Microsoft’s Security Response Center (MSRC) published a concise product-level attestation stating: “Azure Linux includes this open‑source library and is therefore potentially affected by this vulnerability.” Microsoft also states it began publishing machine-readable CSAF/VEX attestations (a phased rollout beginning with Azure Linux) and will update CVE entries should additional Microsoft products be found to include the implicated library. That phrasing is deliberate — it confirms Azure Linux as a known carrier while leaving open the possibility of other Microsoft artifacts being affected until they are explicitly inventoried and attested.

---

Why Microsoft’s wording matters — what it does and doesn’t mean​

What the MSRC attestation does​

• It is an authoritative, product-scoped inventory statement for Azure Linux. If you run Azure Linux images, you can rely on MSRC’s finding that the distribution contains the vulnerable component and therefore requires attention and patching.
• Microsoft’s move to publish CSAF/VEX attestations in machine-readable form is a meaningful improvement: it enables automatable triage and reduces noisy false positives when a vendor has already confirmed a product is Not Affected or Known Affected. Starting with Azure Linux is pragmatic because it is a discrete, Microsoft-maintained image family that reaches many Azure customers.

What the MSRC attestation does not do​

• It does not assert exclusivity. The sentence naming Azure Linux is a confirmation that Microsoft has inspected that product and found the library; it is not a technical proof that no other Microsoft product or image includes the same version of Apache HTTP Server. Microsoft explicitly says it will update the CVE mapping if additional products are identified, which implies the mapping is incomplete until fully rolled out. Treat an un‑attested product as unverified, not as safe.
• It does not replace artifact‑level verification. Large vendors ship thousands of artifacts — VM images, marketplace appliances, container base images, hosted CI/CD runner images, WSL kernels, agent packages and SDKs — and any of these can embed open-source components transitively or by design. Absent a VEX/CSAF entry for a given product, you must verify that artifact yourself or wait for Microsoft’s attestation.

---

Where Apache HTTP Server commonly appears inside Microsoft’s ecosystem​

It’s important to understand the practical supply-chain vectors by which an upstream package like Apache can appear inside vendor artifacts. The following Microsoft-supplied or Microsoft-published artifact classes are plausible places to find Apache HTTP Server binaries or modules:

• Azure Marketplace VM images and appliance images (third‑party vendor images often bundle full application stacks).
• Microsoft-maintained distribution images (Azure Linux — explicitly attested).
• Container base images and images published to registries used in Azure (including Azure Container Registry and Marketplace container offerings).
• Hosted CI/CD runner images (GitHub Actions runners and Azure DevOps hosted agents — both of which supply base images used by many teams). GitHub is Microsoft-owned; runner images may include common server packages.
• Managed platform stacks and runtime images used by services (where a service’s runtime includes or depends on Apache modules or reverse proxies).
• WSL distributions and kernel/userland combos that Microsoft distributes or packages.

Because any of these artifact types can embed upstream packages either directly or transitively, defenders must assume potential exposure until an artifact is explicitly attested or scanned.

---

Technical conditions that make an Apache instance vulnerable​

Not every Apache 2.4.x build is exploitable. The vulnerability requires a specific constellation of software and configuration:

• Apache HTTP Server version is in the affected range: 2.4.26 → 2.4.63. The fix appears in 2.4.64.
• The server has mod_proxy and HTTP/2 proxying (modproxy) enabled and in active use.
• A reverse proxy setup proxies to an HTTP/2-capable backend (h2/h2c).
• The virtual host or server context has ProxyPreserveHost On (preserving the incoming Host header to be sent to the backend).

If these conditions are not met, the immediate risk is substantially reduced. However, because the configuration pattern above is common in modern front‑end proxies, many deployments must still verify and act.

---

Practical, prioritized checklist: what defenders should do now​

The most effective response is an evidence-driven inventory plus prioritized remediation. Follow this recommended sequence:

• Inventory: Locate every Apache instance and list package versions across your estate (VMs, containers, appliances, hosted images). Example commands:
• apachectl -v to check the Apache version.
• apachectl -M | grep proxy to check loaded modules.
• rpm -q apache* or dpkg -l | grep apache2 to enumerate installed packages.
• grep -R "ProxyPreserveHost" /etc/apache2 /etc/httpd to find configurations.
• Prioritize: Mark as highest priority any front-end proxies that:
• Terminate public traffic or are reachable from untrusted networks, or
• Proxy to HTTP/2 backends and have ProxyPreserveHost enabled, or
• Are embedded in Marketplace images or CI/CD runner images that are widely used in your organization.
• Patch / Rebuild: Upgrade to Apache HTTP Server 2.4.64 or later, or apply your OS/distributor’s security update that contains the upstream fix. For container workloads rebuild base images from patched layers and redeploy through CI/CD pipelines.
• Short-term mitigations (if you cannot immediately patch):
• Set ProxyPreserveHost Off for affected vhosts (test first — this can change backend behavior).
• Disable modproxy (HTTP/2 proxying) where acceptable.
• Restrict network access to the proxy (ACLs, WAF rules, firewall) to reduce exposure.
• Consider proxying to HTTP/1.1 backends as a temporary measure.
• Detect and hunt:
• Monitor Apache error logs for assertion messages, worker crashes, and “worker aborted” traces.
• Correlate child process restarts with incoming request traffic patterns and HTTP/2 frame anomalies.
• Add targeted WAF signatures and rate-limiting for proxied vhosts if possible.
• Verify and document: After patching, confirm the package version and module behavior via apachectl -v and apachectl -M. Re-run functional proxy tests to validate correct behavior and ensure that mitigations did not break expected host header semantics.

---

How to treat Microsoft-supplied artifacts you consume​

When a vendor like Microsoft says one of its products is affected, that lets you focus resources — but it should not be the only input to your risk decisions. Practical guidance:

• Treat MSRC’s attestation for Azure Linux as a high-confidence signal: if you use Azure Linux images, prioritize patching them.
• For other Microsoft artifacts (Marketplace images, container base images, hosted runners, managed platform images, WSL/agent packages), do not assume they are free of the component simply because they are not yet named. Instead:
• Request an SBOM or VEX/CSAF attestation from the image/vendor if it comes from a third party in the Marketplace.
• Scan images and artifacts in your registries and artifact stores for Apache packages and the affected version range. Use automated image-scanning tools and SBOM consumption where possible.
• For hosted runners and CI images, check the runner/agent image documentation and, where allowed, run a quick package enumeration in a job to capture versions.
• Rely on vendor VEX/CSAF feeds where available, but only as a complement to artifact-level verification. Microsoft’s VEX rollout is phased; absence of a VEX entry equals “not yet attested,” not “not affected.”

---

Why you can’t treat a single attestation as global proof​

Large vendors ship an enormous set of artifacts across different distribution channels and lifecycles. Even if Microsoft’s Azure Linux images are patched and attested, other Microsoft-distributed binaries can independently carry the same upstream library because:

• Different artifacts are built at different times and from different upstream snapshots. Some may include older upstream versions until they are rebuilt.
• Third-party Marketplace images and appliances can bundle their own copies of Apache or include it transitively via application stacks. Those third parties have their own release cadences.
• Container base images and CI runner images are common vectors for transitive inclusion of server packages.

Because the presence or absence of a package is an artifact-level property, only per-artifact inspection or explicit vendor attestation can remove doubt. Microsoft’s statement that it will update CVEs if other products are affected underscores that the current mapping is a work in progress.

---

Cross-verification and the limits of public PoCs​

Multiple public vulnerability trackers and vendors corroborate the upstream fix and the affected version range — Apache’s 2.4.64 release contains the upstream remediation, and distributor advisories have followed. However, reports of public proof‑of‑concept exploit code should be treated cautiously until validated by trusted parties. Even where PoCs circulate, the exploitability is still configuration-dependent: an exposed reverse proxy with HTTP/2 backends and ProxyPreserveHost on is an attractive target, but other setups are not directly vulnerable. Prioritize verification and patching rather than waiting for exploit validation.

---

Operational risk analysis — strengths and residual risks​

Strengths​

• The upstream fix exists and is widely available: Apache HTTP Server 2.4.64 is the canonical remediation baseline. Multiple distributors have packaged fixes.
• MSRC’s product-level attestation and the VEX/CSAF initiative improve transparency and automation for defenders as the program expands.

Residual risks and caveats​

• Attestation coverage is incomplete while the VEX rollout proceeds; defenders must treat un‑attested artifacts as unverified.
• Container images, Marketplace appliances, and third‑party artifacts often lag OS package updates; many organizations must rebuild and redeploy images to fully remediate.
• Short-term mitigations (ProxyPreserveHost Off, disabling modproxy) can alter application behavior; test changes before wide deployment.

---

Recommended long-term actions to reduce supply-chain ambiguity​

• Bake SBOM/VEX consumption into your CI/CD and image-gating pipelines so that you can automatically match CVEs to the specific artifacts you run. Microsoft’s CSAF/VEX rollout is a helpful input — but design your processes to accept attestations and also to verify artifacts directly.
• Maintain image registries and enforce image-scanning gates for base images used by your teams. Rebuild images from patched base layers rather than relying on in‑container runtime patches.
• Add configuration-awareness to vulnerability inventory: track not just package versions, but module usage and critical vhost directives (e.g., ProxyPreserveHost). Vulnerability exposure can be configuration-dependent; knowing the configuration reduces noise and focuses remediation.
• Demand SBOMs and VEX attestations from Marketplace vendors and third-party appliance publishers. If you must deploy a Marketplace image, stage it and inspect packages before allowing it into production.

---

Conclusion​

Microsoft’s public statement that “Azure Linux includes this open‑source library and is therefore potentially affected” is an important, actionable inventory attestation for customers who run Azure Linux images — treat it that way and prioritize remediation accordingly. However, it is not a proof that Azure Linux is the only Microsoft product that could include the vulnerable Apache HTTP Server components. Until Microsoft publishes broader CSAF/VEX attestations or until you verify other Microsoft-supplied artifacts yourself, treat other Microsoft artifacts as unverified rather than safe.
Operationally, the path forward is straightforward: inventory artifacts (including marketplace images and container base images), check modules and configurations (modproxy, modproxy, ProxyPreserveHost, HTTP/2 backends), patch to Apache HTTP Server 2.4.64+ or apply vendor updates, and if necessary use short-term mitigations while you rebuild and redeploy. Microsoft’s VEX/CSAF program will help reduce uncertainty as it expands, but until then, artifact-level verification and practical mitigation remain your most reliable defenses.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center