PHP 7.4 vulnerabilities accumulated across dozens of point releases before the branch reached end of life in November 2022, and PHP 7.3 hit end of life a year earlier in December 2021, which means any production system still running either version has been collecting unpatched security debt for years. This post is not a line-by-line CVE list, since exact identifiers and patch versions from years-old point releases are easy to get wrong and not that useful on their own. Instead it walks through the categories of issues that showed up repeatedly across the 7.3 and 7.4 series, why they matter, and what to actually do if you find these versions in a dependency scan today.
Why do PHP 7.3 and 7.4 still show up in security scans?
PHP 7.3 and 7.4 remain common in production because PHP has historically been embedded deep in hosting stacks, legacy CMS installs, and internal tooling that nobody wants to touch. A WordPress site provisioned in 2019 or a shared hosting plan that never forced an upgrade can easily still be running php 7.3.33 or php 7.4.33, the final point releases of each branch. Those are the version strings you will most often see flagged by a scanner, precisely because they were the last builds ever shipped, so anything discovered after end of life stayed unpatched in them by definition.
The security implication is straightforward: end of life means no more security patches, full stop. Any vulnerability discovered in PHP's core or bundled extensions after November 2022 was fixed in supported branches (8.1 and later, at the time) and never backported to 7.4. Vendors sometimes offer extended support contracts, but the free, community-supported patch stream stopped.
What kinds of issues recurred across the 7.x security history?
Across the PHP 7.x lifecycle, the categories that came up repeatedly were memory-safety bugs in core parsing and string-handling functions, issues in bundled extensions like exif and phar, deserialization weaknesses tied to unserialize() on untrusted input, and edge cases in filter and validation functions such as email and URL validation that could be abused to bypass input checks. None of these are unique to a single point release; they are the recurring shape of vulnerability classes in a large C codebase that parses untrusted input, which is exactly what a PHP interpreter does constantly.
The practical upshot for a php 7.4.26 exploit or a php 7.4.33 exploit search is usually the same regardless of the exact point release involved: unsafe deserialization of user-controlled data, unsanitized file uploads processed through vulnerable extension code, or memory-corruption bugs reachable through crafted input to string or image-parsing functions. These are exactly the categories that a SAST or SCA scan should flag automatically, since they map to well-known weakness patterns rather than needing a human to spot each one manually.
Does upgrading from 7.3 to 7.4 fix the underlying risk?
Only partially, and that is the important nuance. Some fixes released during 7.4's supported window were backported to the still-supported 7.3 line for a while, and some 7.4-specific improvements narrowed certain classes of bugs. But since 7.4 is now also end of life, upgrading from 7.3.33 to 7.4.33 today closes essentially zero currently outstanding vulnerabilities, because both branches stopped receiving fixes. The only upgrade that meaningfully reduces risk is moving to a currently supported major version.
This is a common mistake in dependency remediation: teams see "upgrade available" and bump to the latest point release of the same unsupported major, which resolves the finding cosmetically in some scanners without resolving the underlying exposure. A good scanning workflow should flag the whole branch as end of life rather than just the specific version string, so remediation guidance points at a real fix.
How should you prioritize remediation if you find PHP 7.3 or 7.4 in your stack?
Treat "running an end of life PHP version" as its own finding, separate from any individual CVE, because the absence of ongoing patches is itself the risk. Inventory every place PHP runs, including forgotten internal tools, staging environments, and third-party appliances that embed PHP, since these are the systems most likely to be missed by a scan scoped only to primary production services.
Prioritize internet-facing systems first. A PHP 7.4 install behind no authentication, processing file uploads or user-submitted data, is a materially higher risk than an internal admin tool on a private network. Tools under SCA and SAST/DAST scanning can both help here: SCA flags the interpreter and library versions in your dependency graph, while DAST can probe a running application for exploitable behavior regardless of what the version string claims. Once you have a prioritized list, plan the migration to a supported PHP major (8.2 or later as of this writing) rather than treating point-release bumps within 7.x as a fix. If a full migration will take months, put compensating controls in front of the affected systems, such as a WAF rule set tuned to known PHP exploit patterns, while the migration is in flight.
FAQ
Is PHP 7.4 still safe to run if I have a WAF in front of it?
A WAF reduces exposure but does not eliminate it. It can block known attack signatures, but zero-day and logic-level issues in an unsupported interpreter will not always match a signature. Treat a WAF as a mitigation during migration, not a substitute for upgrading.
What is the actual difference between php 7.3.33 and php 7.4.33 security-wise?
Both are the final, most-patched point releases of their respective branches at end of life. Neither has received fixes for vulnerabilities discovered after their branch's end of life date, so from a current-risk standpoint they are closer to equivalent than the version numbers suggest.
How do I find every PHP version running across my organization?
An SCA or software composition scan across your repositories and container images is the most reliable starting point, supplemented by a network-level fingerprinting pass for any legacy or third-party systems that are not in your source control at all.
Is it worth patching 7.4 manually instead of upgrading?
Rarely worth it at scale. Backporting individual fixes into an end of life branch requires deep C-level expertise and ongoing effort for every future issue. It is almost always cheaper to migrate to a supported major version once and stop the recurring cost entirely.