PHP Site AuditExplainers
PHP2Shell vs. CVE-2024-4577: two different PHP security issues
CVE-2024-4577 and PHP2Shell are not the same vulnerability. PHP’s changelog describes CVE-2024-4577 as an argument-injection flaw in PHP-CGI on Windows and records its fix in the 8.2.20 release notes. PHP2Shell is the nickname for distinct 2026 PHP-core vulnerabilities. Verify each issue against its own vendor advisory and the runtime actually in use.
What CVE-2024-4577 describes
PHP's official changelog identifies CVE-2024-4577 as a bypass of the older CVE-2012-1823 argument-injection issue in PHP-CGI. The changelog records a fix in PHP 8.2.20, and PHP's Windows/IIS documentation describes PHP handler configurations. The issue's CGI and platform context matters; it is not a synonym for every PHP vulnerability.
That issue dates from 2024. Its remediation does not automatically cover PHP2Shell, which was disclosed later and concerns separate PHP-core vulnerabilities. A site's prior remediation of one PHP advisory is not evidence that another is fixed.
If your organization has an older ticket for CVE-2024-4577, use it as a historical lead: verify which host and Windows handler it covered, then open a separate change record for the current PHP2Shell advisories. This is especially useful when a server hosts multiple sites or migrated between handlers. A prior closed ticket may be correct for its original scope and still say nothing about current systems.
What PHP2Shell refers to
PHP's October 21, 2026 advisory describes CVE-2026-109618 and CVE-2026-109619 as critical remote code execution vulnerabilities and lists fixed upstream releases. The advisory covers PHP installations serving web requests and notes that vendors may provide backports. Ask for package/build evidence that applies to your system.
PHP published a separate October 23 informational notice for CVE-2026-115560, involving an unusual runtime sequence. That is also distinct from CVE-2024-4577 and from the two PHP2Shell CVEs. Keep advisories separate in support tickets so the operator can answer the correct question.
Why the distinction changes your request
For CVE-2024-4577, ask whether the site used an affected Windows PHP-CGI configuration and what vendor update or mitigation was applied. For PHP2Shell, ask which web-serving PHP runtime is active and which package or backport covers CVE-2026-109618 and CVE-2026-109619. A Windows CGI configuration answer is not an all-runtime inventory.
If the host provides a version number, ask what advisory it covers and whether it names a vendor build. Different branches and vendors can publish different package labels. Include CVE IDs, hostnames, runtime owner, and exact scope in the question.
Avoid the version shortcut
A later-looking version string does not by itself prove that every relevant CVE is fixed, and an older-looking distribution version does not prove that no backport exists. Check the package vendor's advisory and the installed package or image assigned to production. The CLI version may differ from the web-serving runtime.
Keep remediation records by CVE and component: affected service, applicable vendor bulletin, package/build, rollout time, and verification owner. This creates a useful trail if a new advisory appears or a separate legacy PHP-CGI service is discovered.
CVE IDs help support teams avoid mixing unrelated fixes. In a ticket, write each ID on its own line and ask the vendor to confirm whether its package advisory covers that identifier. A version upgrade can address multiple issues, but the evidence should come from the changelog or security bulletin for the installed vendor package. If the system is Windows, ask which handler is configured for each IIS site; a server may have multiple sites and PHP binaries.
The historical fix in the PHP changelog is useful context, not a substitute for current vendor status. Administrators may use a distribution build with additional release suffixes or separate binary packages. Keep the question at the package level: what package is installed, which advisory applies, and what service uses it? That avoids both rejecting a valid backport and assuming a 2024 record resolves a 2026 advisory.
Owner checklist
- Separate the CVE IDs in your ticket.
- Identify platform and handler configuration for each service.
- Ask which vendor advisory applies.
- Confirm the installed web-serving build and worker activation.
- Do not treat one PHP patch record as proof for unrelated CVEs.
Common questions
Does fixing CVE-2024-4577 fix PHP2Shell too?
No. They are separate vulnerabilities. Check the PHP2Shell advisory and package evidence independently.
Does CVE-2024-4577 affect every PHP site?
No. PHP describes it as a PHP-CGI argument-injection issue; assess the specific Windows CGI configuration with the vendor.
Can I rely on the PHP version string?
Not alone. Check the vendor advisory and the exact package or backport serving the site.