Microsoft has confirmed that its Azure Linux distribution includes a vulnerable version of the Apache HTTP Server, specifically targeted by CVE-2025-54090—a denial-of-service bug that can crash worker processes. But the advisory stops short of clearing other Microsoft products, leaving administrators to wonder whether container images, marketplace appliances, or hosted build agents might be silently exposed.

The Vulnerability: What’s at Stake

CVE-2025-54090 is a configuration-dependent flaw in Apache HTTP Server that affects versions 2.4.26 through 2.4.63. The underlying issue lies in the mod_proxy module when proxying to HTTP/2 backends while the ProxyPreserveHost directive is set to "On." Under these conditions, a reachable assertion inside mod_proxy can be triggered by crafted requests, causing worker process crashes and repeated service disruption.

The fix was released in Apache HTTP Server 2.4.64, which closes the assertion. Multiple distributors have already shipped updated packages. For any front-end reverse proxy meeting the conditions above, the risk is real: an attacker can force downtime simply by sending malformed HTTP/2 frames, with no authentication required.

Microsoft’s Advisory: Transparent but Incomplete

On its Security Response Center (MSRC) portal, Microsoft published a concise product-level attestation: “Azure Linux includes this open‑source library and is therefore potentially affected by this vulnerability.” The company also referenced its October 2025 rollout of CSAF/VEX (Common Security Advisory Framework / Vulnerability Exploitability eXchange) attestations—machine-readable documents that allow automated triage of vulnerability findings. The rollout began with Azure Linux, a deliberate choice for a distribution Microsoft maintains and that many enterprise customers deploy in production.

Crucially, the advisory includes a caveat: “If impact to additional products is identified, we will update the CVE to reflect this.” That sentence turns a single-product confirmation into an open-ended waiting game. For now, the MSRC entry offers no blanket assurance that other Microsoft-supplied artifacts—virtual machine images, container base images, GitHub Actions runner environments, WSL distributions, or managed platform stacks—are free of the same vulnerable library.

Where Apache May Be Lurking in Your Microsoft Stack

Apache HTTP Server is a pervasive component in cloud-native and enterprise environments. Within Microsoft’s ecosystem, the vulnerable library could appear in several common artifacts beyond the explicitly named Azure Linux:

  • Azure Marketplace images: Many third-party virtual appliances bundle full LAMP stacks or include Apache as a reverse proxy. Even if the base OS is not Azure Linux, the appliance itself may carry the affected version.
  • Container images: Base images from the Microsoft Container Registry, Azure Container Registry, and any custom images built atop them can include Apache binaries. Supply chain visibility is often poor for transitive dependencies.
  • Hosted CI/CD runners: GitHub Actions and Azure DevOps agent images provision full development toolchains. These runners routinely include web servers for integration testing and may ship with Apache in its affected range.
  • WSL distros and Windows packages: Microsoft-provided Windows Subsystem for Linux distributions, developer toolchains, or services like Azure App Service could embed Apache mod_proxy as part of local or sandboxed environments.

Because none of these artifacts have been explicitly attested by Microsoft in connection with CVE-2025-54090, defenders must assume potential exposure until each artifact is verified or an official VEX entry appears.

How to Check If You’re Exposed

Whether you manage a handful of virtual machines or a sprawling container fleet, the first step is finding every Apache instance. Use the following commands on Linux-based systems to gather the necessary facts:

  • Check the Apache version: apachectl -v (or httpd -v)
  • List loaded proxy modules: apachectl -M | grep proxy
  • Enumerate installed Apache packages: rpm -q apache\* (Red Hat family) or dpkg -l | grep apache2 (Debian/Ubuntu)
  • Search for the dangerous directive: grep -R "ProxyPreserveHost" /etc/apache2 /etc/httpd

For container images, use a registry scanning tool (e.g., Trivy, Grype, or Azure Defender for Containers) to generate a software bill of materials (SBOM) and flag any Apache HTTP Server version in the 2.4.26–2.4.63 range. For GitHub Actions runners, you can run apachectl -v within a workflow job to verify the version on the fly—but don’t assume that yesterday’s runner image matches today’s.

The vulnerability is not present if:
- The Apache version is 2.4.64 or later, or
- mod_proxy is not loaded, or
- proxying to HTTP/2 backends is not enabled, or
- ProxyPreserveHost is not set to "On" in any active virtual host.

However, you should still patch to be safe if Apache is part of a critical path.

Your Remediation Roadmap

Once you know where the vulnerable packages are, follow this prioritized sequence:

  1. Prioritize public-facing proxies. Any Apache reverse proxy that terminates traffic from untrusted networks and meets the vulnerable configuration should be patched immediately.
  2. Patch to Apache 2.4.64 or apply vendor updates. For Azure Linux, Microsoft’s standard package feed should contain the fixed version. Use tdnf update or the appropriate package manager. For container images, rebuild your base images from patched layers and redeploy through your CI/CD pipeline.
  3. If immediate patching is impossible, apply one of these short-term mitigations (test carefully; they can alter application behavior):
    - Set ProxyPreserveHost Off for affected virtual hosts.
    - Disable mod_proxy_http2 (the module responsible for HTTP/2 proxying) if your backend can accept HTTP/1.1 connections.
    - Restrict network access to the proxy with ACLs or firewall rules to reduce the blast radius.
  4. Validate the fix: After updating, run apachectl -v to confirm the version, and use apachectl -M to verify that the proxy modules are still active and functioning as expected. Run functional tests to ensure host header semantics haven’t broken.
  5. Monitor for signs of exploitation: Watch Apache error logs for messages like “Assertion failed,” “worker aborted,” or a sudden spike in child process restarts. These can indicate an in-progress denial-of-service attempt.

Why You Can’t Rely on Attestations Alone

Microsoft’s move toward CSAF/VEX attestations is a big step forward for vulnerability management. Machine-readable advisories allow security tools to automatically determine whether a given CVE applies to a specific product instance, slashing false positives. The fact that MSRC picked Azure Linux as the launch point for its VEX program signals a commitment to transparency for open-source components in Microsoft-maintained distributions.

Yet, the phased rollout means that most Microsoft-supplied artifacts remain unaccounted for. Even within a single product family—like the Azure Marketplace—an image published by an independent vendor may embed a different Apache build than the one Microsoft ships. Without explicit artifact-level verification, absence of a VEX entry is not proof of safety.

Third-party suppliers also play a role. If you use a marketplace appliance that bundles Apache HTTP Server, the publisher is ultimately responsible for issuing an advisory or SBOM. Microsoft’s CSAF/VEX program does not (yet) cover those third-party artifacts by default.

A Practical Defensive Policy for Supply Chain Gaps

To manage this uncertainty, adopt a policy of “verify, then trust” for any Microsoft artifact you consume:

  • Treat Microsoft’s Azure Linux attestation as a high-confidence signal and patch accordingly.
  • For all other Microsoft-supplied images or binaries, request an SBOM or VEX attestation from the publisher. For Azure Marketplace images, check the vendor’s own security page.
  • Scan artifacts yourself as part of your deployment pipeline. Tools like Trivy, Docker Scout, or Azure Defender for Containers can be integrated into CI/CD to block images containing known-vulnerable packages.
  • For hosted runners and CI images, do not assume any given snapshot is free of Apache. If you rely on those runners for production builds, periodically audit their package manifests.
  • Demand VEX feeds from third-party vendors. The more machine-readable attestations you can consume, the less manual triage you will need as vulnerabilities like CVE-2025-54090 emerge.

Looking Ahead: A More Automated Future

Microsoft’s VEX rollout is still in its early stages, but the destination is clear: a world where every product and artifact has a machine-readable vulnerability status that tools can consume automatically. For defenders, that means less guesswork and faster patching. Until the program reaches critical mass, however, the burden remains on you to inventory, verify, and mitigate.

As for CVE-2025-54090, the Apache Software Foundation has already done its part by releasing the fix. Microsoft has done its part for Azure Linux. The rest of the ecosystem—Microsoft’s broader artifact catalog, third-party marketplace listings, and the many bespoke container images running in enterprise environments—still requires hands-on attention. Treat every unverified asset as potentially affected until you have evidence to the contrary.