CVE-2024-40725: Patch Apache 2.4.62 to Prevent Source Disclosure

A partial upstream fix in Apache HTTP Server left an opening that can return source code instead of executing it — and Microsoft’s short advisory that “Azure Linux includes the implicated open‑source library and is therefore potentially affected” is correct for Azure Linux images but does not mean Azure Linux is the only Microsoft product that could carry the vulnerable component. The vulnerability, tracked as CVE‑2024‑40725, stems from legacy content‑type handler configurations (for example, AddType) and affects Apache 2.4.60 and 2.4.61; the fully corrected code was released in Apache HTTP Server 2.4.62. Operators running Microsoft images should treat Azure Linux as an attested carrier and immediately prioritize remediation — and every team that runs Microsoft‑supplied images, kernels, or containers should verify their own artifacts because Microsoft’s attestation is product‑scoped, not an exclusivity guarantee.

---

Background / Overview​

CVE‑2024‑40725 was published in July 2024 after Apache maintainers discovered that a partial fix for an earlier regression (CVE‑2024‑39884) did not completely eliminate a logic path that, under certain configurations and indirect request flows, can expose local files as plaintext. In concrete terms, when legacy MIME‑type‑based mappings such as AddType are used to associate file extensions with handlers, an attacker can craft requests that cause the server to return the source code of files (for example, PHP scripts), rather than invoking the interpreter. This is a classical information‑disclosure failure: secrets embedded in code and configuration (database credentials, API keys, internal comments) can be leaked to unauthenticated remote clients.
Multiple vulnerability databases and vendor advisories agree on the core facts: affected Apache versions are 2.4.60 and 2.4.61, the bug is fixed in 2.4.62, and the vulnerability’s root cause is incomplete handling of legacy content‑type handler semantics (AddType/AddHandler) in an indirect request scenario. Industry trackers such as Rapid7, Armis and Linux distribution security pages produced matching technical summaries and mitigation guidance (upgrade to 2.4.62).
Why this matters in practice: many long‑running deployments — particularly those migrated from older setups or hosting legacy PHP apps — still use AddType/AddHandler mappings out of habit or compatibility. Reverse proxies, redirects, aliases, or certain rewrite chains can create the “indirect request” shapes that expose the edge case. The presence of a public proof‑of‑concept and active scanning means operators should treat the issue as operationally urgent for any server that matches the version and configuration pattern.

---

Technical anatomy: how an AddType mapping can turn PHP into plaintext​

What AddType/AddHandler does​

• AddType historically maps MIME types to file extensions (for example, mapping .php to application/x-httpd-php), which in some server environments was used to route files to interpreters.
• SetHandler and modern FilesMatch/ProxyPass patterns are the recommended ways to bind interpreter handling because they are explicit about the handling scope.

The bug arises because the Apache core’s decision logic that determines whether a resource should be passed to a handler or served as a static file relied on multiple pieces of state — the content type mapping, the request routing path, and whether the request was direct or “indirect” (for example via an Alias, mod_rewrite internal redirect, or proxying loop). A partial upstream fix missed scenarios where a legacy AddType mapping should have forced the interpreter path but did not, allowing a path where the server falls back to plain file serving. The result: the PHP source is returned as text/plain rather than executed.

Attack surface and impact​

• Attack vector: network, unauthenticated (remote attacker can craft requests).
• Typical impact: confidentiality breach (source code, credentials, internal comments).
• Exploitation complexity: low once the right configuration pattern is present; proof‑of‑concept code exists publicly.
• Affected components: Apache httpd 2.4.60–2.4.61; any packaged derivatives that used those code lines until the vendor shipped 2.4.62 or backported fixes.

Severity nuance​

Different trackers score the vulnerability across CVSS scales slightly differently — NVD and Ubuntu list a medium score in the 5.x range for confidentiality‑only impact in many configurations, while some distro maintainers (AWS/Alma/Red Hat derivatives) mark it higher where package and environment factors increase systemic risk. Regardless of numeric score, the qualitative risk is material when the affected server contains secrets or executes code handling sensitive data.

---

Microsoft’s advisory: what it actually says and what that means​

When Microsoft’s Security Response Center (MSRC) maps an upstream CVE to ahe language often used is concise: “Azure Linux includes the implicated open‑source library and is therefore potentially affected.” That line is an attestation that Microsoft examined the Azure Linux distribution and found the relevant upstream package or code path present. It is not — and Microsoft’s own guidance makes this explicit — a statement that no other Microsoft product could include the same open‑source component. Microsoft has also committed to publishing machine‑readable CSAF/VEX attestations (a rollout that began in October 2025) and to updating CVE mappings when their inventory work discovers additional affected artifacts.
Two practical consequences follow:

• For Azure Linux customers, Microsoft’s attestation is authoritative and actionable: treat the product as in‑scope and apply updates or mitft and upstream Apache recommend.
• For defenders who run other Microsoft artifacts — WSL kernels, curated Marketplace images, managed VM images, container base images published by Microsoft, SDKs, or other products that bundle Apache or similar libraries — do not assume those artifacts are unaffected unless Microsoft explicitly marks them Not Affected or publishes VEX attestations covering them. Inventory and artifact‑level verification are required.

WindowsForum community analyses that examined MSRC wording repeatedly reach the same conclusion: product‑scoped attestations are valuable, but they are inventories, not exclusivity proofs. Treat the MSRC statement as a priority flag for Azure Linux and a call to do artifact discovery elsewhere.

---

Is Azure Linux the only Microsoft product that includes the implicated library?​

Short answer: No — Azure Linux is the only Microsoft product Microsoft has publicly attested (so far) to include the implicated Apache httpdE, but that attestation does not prove exclusivity. Any Microsoft product, image, or service that ships or runs an Apache httpd binary compiled from the vulnerable upstream versions (2.4.60–2.4.61) or a derivative package that did not receive the fix could be affected. Examples of candidate places to check include:

• Marketplace VM images that include httpd as a package or container base.
• Azure Marketplace appliances published by Microsoft or partners.
• Azure container base images and curated images used with AKS node pools.
• WSL2 kernel images or any on‑premises Microsoft‑supplied images that bundle a Linux userland.
• Products that embed or statically link httpd or ship a bundled web server for management interfaces.

Microsoft’s FAQ language is deliberately conservative: it confirms Azure Linux is a confirmed carrier, promises greater machine‑readable transparency going forward, and commits to updating CVE mappings if additional Microsoft products areed. But it stops short of asserting an exhaustive inventory across every Microsoft artifact. That is a defensible operational posture for a large vendor with dozens of images and hundreds of build artifacts — it prioritizes attestation of specific product lines while the company completes broader artifact scanning and VEX attestations.

---

What operators and Microsoft customers should do — prioritized checklist​

If you run Azure Linux images (the attested product)

• Patch now: ensure your Azure Linux images have been updated to include Apache httpd 2.4.62 or the distribution vendor’s patched package. Microsoft’s attestation makes Azure Linux the immediate remediation priority.
• Validate: after patching, verify the httpd version (httpd -v) and test typical request flows that might use AddType/AddHandler, Aliases, and internal rewrites to confirm handlers are working correctly.
• Audit logs: search access logs for anomalous requests that could indicate probing for source exposure (requests for .php files returning text/plain, unexpected 200 responses on files that should have been executed).

If you run other Microsoft images, agents, or services

• Don’t assume you’re safe: perform artifact‑level discovery. Pull the image or package and inspect package lists, binary versions, and build manifests (SBOMs where available).
• Check WSL and other kernel/userland bundles: if a Microsoft image bundles a userland containing httpd, it may be affected.
• Request VEX attestations: if you rely on a Microsoft image and need a machine‑readable assurance, request Microsoft’s VEX/CSAF assertion for that artifact or wait for MSRC updates if they promise to update the CVE mapping.

If you run non‑Microsoft deployments

• Patch Apache to 2.4.62 or later immediately if you use 2.4.60–2.4.61.
• Replace legacy AddType usage with SetHandler, FilesMatch, or explicit handler configuration.
• Harden permissions: ensure source files (for example, .php) are not world‑readable and that web server file permissions follow least privilege.
• Review rewrite/alias/proxy rules that can create indirect request paths.

Cross‑organization operational hygiene (applies to everyone)

• Use SBOMs and image scanning: automated scanning of container images and VM images should flag vulnerable httpd versions.
• Implement automated detection: search code repositories and deployment manifests for AddType/AddHandler usage and for httpd package versions.
• Test a patch rollout on staging mirrors that mimic production rewrite and alias patterns; the vulnerability specifically depends on request routing shapes, so regression tests must include rewrites, aliasing, and proxy chains.

---

Detection: what to look for in the wild​

• Access log entries showing raw PHP source or other script files returned with text/plain or 200 responses where execution was expected.
• Requests that exploit alias or rewrite chains, e.g., odd URL patterns that resolve through multiple path handlers and return script text.
• IDS/IPS alerts for the PoC signatures that security vendors and CERTs have published; public PoCs exist and some vendors have added signatures. Treat PoC activity as high‑priority for investigation.

---

Why vendor attestations matter — and why you must still verify​

Vendor attestations like the MSRC line naming Azure Linux are useful because they give customers an authoritative, fast answer for a named product: if you run that product, you should patch. But large vendors do not ship a single monolithic build — they ship images, kernels, agents, SDKs, management appliances, and container bases. Each artifact is a separate build and may include different upstream components or versions. An attestation that names a single product is therefore both a signal and a partial inventory result; it is not a universal proof that the vulnerable code does or does not exist everywhere in the vendor’s artifact inventory. The WindowsForum community has repeatedly emphasized this distinction in coverage of MSRC attestation language.
Microsoft’s roll‑out of machine‑readable VEX/CSAF attestations (announced as beginning October 2025) aims to reduce that friction by delivering product‑by‑product, artifact‑level statements customers and security vendors can ingest programmatically. That is an important step that will reduce uncertainty — but until VEX coverage is comprehensive, artifact‑level verification (SBOMs, package scanning, binary inspection) remains the gold standard.

---

Risk evaluation: realistic scenarios and worst cases​

• Common, high‑probability scenario: a legacy LAMP stack using AddType on Apache 2.4.61 serves PHP sources for specific indirect request shapes. Impact: disclosure of credentials or PII embedded in code — moderate to severe depending on content.
• Supply‑chain scenario: a Microsoft or third‑party VM image includes the vulnerable package — numerous tenants could be affected simultaneously until a marketplace patch propagates. Impact: operationally significant in cloud fleets.
• Edge case, low probability: exposed web UI in a managed product that embeds Apache and uses AddType internally — could leak configuration or private keys stored within bundled files. Impact: severe for single targeted products with high‑value secrets.

In all scenarios the recommended technical response is the same: apply the upstream fix and verify handler behavior; but in an enterprise context the operational response should also include artifact discovery and communications with image vendors.

---

Practical remediation playbook (step‑by‑step)​

• Inventory
• List all hosts, containers, and images that run Apache httpd or include httpd packages.
• Query package managers (dpkg, rpm, apk) and image manifests for httpd versions.
• Patch
• Upgrade servers to Apache httpd 2.4.62 (or apply a vendor backport that contains r1919249).
• For Azure Linux, apply Microsoft’s updated images or patches as published in the MSRC update guidance.
• Configuration hardening
• Replace AddType/AddHandler mappings with SetHandler/FilesMatch where appropriate.
• Remove unneeded legacy handlers and re‑test application functionality.
• Test
• Recreate indirect request shapes (Aliases, rewrites, proxied requests) in staging to confirm the fix.
• Monitor
• Inspect access logs for unusual .php (or other script) retrievals after remediation.
• Deploy temporary WAF rules that block suspicious URI patterns that match published PoCs until patches are complete.
• Communicate
• Notify stakeholders, especially if images were deployed via Marketplace or CI pipelines.
• If you use Microsoft images beyond Azure Linux, request VEX attestations or open a support case to get artifact‑level clarification.

---

Final analysis and takeaways​

CVE‑2024‑40725 is a textbook information‑disclosure vulnerability caused by an incomplete upstreahe fixed it in 2.4.62, and vendors and distributions quickly followed with patches. Microsoft’s MSRC statement that “Azure Linux includes the implicated open‑source library and is therefore potentially affected” is a correct and actionable product attestation for Azure Linux customers; it is not, however, a guarantee that no other Microsoft product could include the same vulnerable component. The right operational posture is therefore dual: treat Azure Linux as a confirmed remediation priority, and simultaneously perform artifact‑level discovery across all Microsoft‑supplied images and binaries you run until additional VEX attestations or vendor confirmations remove doubt.
Be pragmatic: patch, test, and audit configurations (especially legacy AddType usage). Use SBOMs and image scanning to close blind spots in your supply chain. And when a vendor publishes a targeted product attestation, treat it as a strong, immediate indicator of risk for that product — but not as a substitute for your organization’s own artifact verification and vulnerability management processes.
In short: Azure Linux is the attested carrier and must be patched now — but it is not the only place the vulnerable code could exist. Verify artifacts, apply the Apache 2.4.62 fix where appropriate, and harden handler configurations to prevent legacy mappings from becoming future attack vectors.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center