Microsoft has confirmed that its Azure Linux distribution is affected by CVE-2024-2756, a PHP vulnerability that could allow attackers to hijack user sessions by tricking servers into accepting malicious cookies as secure. But the company’s advisory stops short of declaring other Microsoft products safe, leaving users of services like Azure App Service, Windows PHP installations, and container images to verify their own exposure.

What CVE-2024-2756 Actually Does

CVE-2024-2756 is a PHP-level parsing bug that undermines cookie security. When exploited, an attacker can craft a cookie that PHP incorrectly interprets as having the Secure or Host prefix. These prefixes are meant to ensure cookies are only sent over HTTPS or to a specific host, respectively. By spoofing these attributes, an attacker could inject a session identifier or manipulate application state in a way that leads to session hijacking or cross-site request forgery (CSRF).

In a typical exploit scenario, an attacker positioned between the user and the server—or through script injection—can set a cookie like __Secure-malicious=value with the Secure flag missing. PHP’s parser may incorrectly map this cookie as having the __Secure- prefix, causing the application to treat it as genuine. This can be used to overwrite a session cookie or inject a CSRF token.

The vulnerability stems from a partial fix for an earlier issue, CVE-2022-31629, which also involved cookie handling. That earlier patch closed some avenues but left edge cases in parsing that this new CVE reopens. The fix requires updated PHP packages that properly validate cookie names and attributes.

Upstream PHP maintainers released patched versions, and major Linux distributions—including Amazon Linux, Oracle Linux, and others—issued updates. For Azure Linux, Microsoft has provided updated packages that address the flaw.

Microsoft’s Advisory: What It Says and What It Doesn’t

The key sentence in Microsoft’s advisory reads: “Azure Linux includes this open-source library and is therefore potentially affected.” The company frames this as a transparency measure, noting that it began publishing CSAF/VEX (Common Security Advisory Framework / Vulnerability Exploitability eXchange) attestations in October 2025 to help customers automate vulnerability management.

However, the advisory is careful. It adds: “If impact to additional products is identified, we will update the CVE to reflect this.” This wording means that while Azure Linux is the only product Microsoft has officially flagged, the absence of other products does not mean they are free of the vulnerable PHP component. Microsoft’s phased approach to inventorying its vast portfolio means many other offerings—from Azure App Service to Windows PHP installs—haven’t been scrutinized publicly yet.

Where Else PHP Might Be Lurking in Microsoft Environments

If you’re a Microsoft customer, you likely touch more than one service that could run PHP. Here are common places where the language appears, and where you should check:

  • Azure Linux VMs and containers: This is the confirmed product. If you run Mariner-based images, update immediately.
  • Azure App Service (Linux): The platform often provisions PHP runtimes. While managed, the runtime images may contain vulnerable versions until patched by the service team.
  • Azure Functions: If you use custom containers with PHP, verify the base image.
  • Windows Subsystem for Linux (WSL): Many developers run PHP under WSL; check your installed packages.
  • Windows Server with IIS and PHP: PHP for Windows installations are separate from Azure Linux but still use the same upstream code. If you installed PHP manually, you may need to download a fresh build.
  • Marketplace images and third-party offerings: Any Azure Marketplace image with a LAMP stack or preinstalled PHP needs verification.
  • Developer VMs and CI/CD agents: Build environments often include PHP tooling.

For each, the only reliable method is to inspect the package versions yourself.

How to Check if Your Microsoft-Hosted PHP Is Affected

Start by listing every Microsoft artifact that runs PHP. Then, check the installed PHP version:

  • On RPM-based systems (Azure Linux, CentOS, etc.): rpm -qa | grep -i php or dnf list installed 'php*'
  • On Debian/Ubuntu: dpkg -l | grep php
  • Inside containers: docker run --rm -it <image> sh -c "php -v || rpm -qa | grep php || dpkg -l | grep php"
  • On Windows: run php -v from the command line.

Compare the version number with the fixed releases listed in the upstream PHP advisory. Unfortunately, Microsoft has not published a definitive “fixed version” for all its services, so you’ll need to cross-reference with the PHP project’s own changelog. The exact fixed versions depend on the PHP branch you’re running (e.g., PHP 8.1.x, 8.2.x), but generally, versions released after early 2024 should include the patch.

If you use managed services like Azure App Service, you may not have direct access to the underlying image. Check the runtime stack configuration in the portal to see the PHP version, then consult the App Service documentation or support to understand when patched runtimes will be deployed. Automated scanning tools like Tenable, Qualys, or Trivy can also detect vulnerable PHP packages inside images; several have added specific checks for CVE-2024-2756 in Azure Linux.

What to Do Right Now

  1. Patch Azure Linux immediately. If you run any Azure Linux instances, apply the updates through your normal update mechanism (e.g., dnf update for Mariner). This is your first priority.
  2. Inventory everything else. Use the checklist above to identify all other Microsoft products or services where PHP might run. Don’t assume managed services are automatically safe—verify.
  3. Scan your images and hosts. Run vulnerability scanners that have CVE-2024-2756 detection. Tenable Nessus, for instance, has a plugin ID for this specific CVE on Azure Linux.
  4. Harden your application. While waiting for patches, apply code-level mitigations:
    - Explicitly validate cookie names and attributes server-side. Reject malformed cookie headers.
    - Enforce HTTPS for all session cookies; don’t rely solely on prefix flags.
    - Implement Web Application Firewall (WAF) rules to block suspicious Set-Cookie headers.
  5. Monitor Microsoft’s advisory. Subscribe to MSRC updates. Microsoft’s promise to update the CVE if more products are found means you may get a late-breaking alert. Set a reminder to revisit the advisory over the next month.
  6. Replace base images in CI/CD. If you build custom images, ensure you pull the latest patched base images from trusted sources, not stale ones.

How We Got Here

CVE-2024-2756 is a reminder that even widely used foundational software like PHP can harbor subtle bugs that vendors must chase across complex product lines. The PHP ecosystem issued fixes in early 2024, and many Linux distributors moved quickly. Microsoft’s delayed and limited advisory reflects a broader challenge: large cloud providers often have to trawl through hundreds of internal artifacts before they can confidently issue global CVEs.

Microsoft’s newer CSAF/VEX program, launched in October 2025, is supposed to make this process more transparent and machine-readable, so customers can automate detection. But it’s still a work in progress: the company started with Azure Linux as a “first pass” and is taking an iterative approach. Meanwhile, security researchers and scanners have had to step in, publishing checks that fill the gap while Microsoft completes its inventory.

What Comes Next

Expect Microsoft to expand its CVE-2024-2756 advisory over the coming weeks. The company has committed to updating the entry if it finds the vulnerable PHP component in other products. Watch for new CSAF/VEX documents and MSRC alerts. Additionally, keep an eye on upstream PHP announcements, as secondary fixes might emerge.

For now, the safest posture is to assume that any Microsoft product or service that runs PHP could be affected until proven otherwise. Patch Azure Linux without delay, and then methodically audit the rest of your estate. The question isn’t just “What has Microsoft told us is vulnerable?” but “What haven’t they told us yet?”