PHP vulnerabilities are exploitable flaws in the PHP engine, its extensions or the code and libraries built on it, and you manage them by knowing your version and exposure, patching or retiring what is unsupported, hardening the code, and keeping a fallback for the days you cannot patch.

On October 21, 2026, the PHP project released fixes for two critical remote code execution flaws known as php2shell. Five days later, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) added both to its Known Exploited Vulnerabilities Catalog. For a leader, the hard question is not what the flaws do. It is whether anyone on your team can say, today, which PHP version each of your applications runs.

This guide covers PHP vulnerabilities in the order a decision maker meets them: what is being exploited now, which versions are still supported, which flaws are most common, how to assess your exposure, how to prevent new ones, what to do when you cannot patch, and when patching stops being enough. It is written for CTOs, CISOs and operating leaders, with extra detail for healthcare, where a vulnerable application can expose patient data. The last section shows how Cabot helps.

Which PHP Vulnerabilities Are Being Exploited Right Now?

Two critical remote code execution flaws, CVE-2026-109618 and CVE-2026-109619, known as php2shell, are the PHP vulnerabilities to act on now, and CISA added both to its Known Exploited Vulnerabilities Catalog on October 26, 2026.

Both flaws sit in parts of PHP that nearly every request touches, which is why they are serious. The PHP Foundation describes them this way:

1. CVE-2026-109618, memory corruption under load. If a request reaches PHP's memory limit at exactly the wrong moment, PHP can leave half built internal data behind and later treat it as valid. On Apache with mod_php, an unauthenticated request can trigger it before any application code runs.
2. CVE-2026-109619, stale state between requests. A fatal error at the wrong point can leave internal state pointing to memory that belonged to a previous request. A later request handled by the same worker can then reuse that freed memory.

The PHP Foundation puts the real severity score at 9.2 out of 10. CISA's alert says the flaws allow unauthenticated remote code execution and affect all PHP installations serving web requests, including Apache with mod_php, PHP-FPM, php-cgi, FrankenPHP and LiteSpeed. The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.

CISA's actions for this week are a useful checklist for any leadership team:

• Inventory every system that runs any version of PHP. CISA notes that PHP is often a component of other software, so exposure may not be visible at first.
• Patch internet facing systems first.
• If a system cannot be updated at once, or still runs PHP 8.1 or earlier, take it offline until it is patched or updated.
• Treat a web application firewall as partial protection only.
• Monitor for PHP worker processes launching shells or downloading tools.

One more detail matters for planning. The PHP Foundation reports that the first signs of the memory problem appeared in a 2024 external audit, and that a fix took months to settle because every approach carried tradeoffs. A weakness in a core component can sit for a long time, so your own inventory and patching process cannot wait on anyone else's timing. Treat PHP vulnerability news as a trigger for that process, not as background reading.

Which PHP Versions Still Receive Security Fixes?

As of November 4, 2026, PHP 8.2, 8.3, 8.4 and 8.5 receive security fixes, and PHP 8.1 and earlier have reached PHP end of life and are no longer supported by the PHP project.

Each PHP branch gets two years of active support, then two more years of critical security fixes only. After that it reaches end of life, and the project warns that users may be exposed to unpatched security vulnerabilities. The table below shows the supported branches on the official PHP supported versions page.

Two points are easy to miss. First, the October fixes shipped for four branches only, and CISA's alert tells organizations still on PHP 8.1 or earlier to take those systems offline until they are updated. Second, PHP 8.2 reaches the end of its security support on December 31, 2026, so any application on that branch needs an upgrade date now, not in the new year. Customer security reviews and auditors can ask which version you run, and an end of life answer is hard to defend.

What Are the Most Common PHP Vulnerabilities?

The most common PHP vulnerabilities are injection, broken access control, security misconfiguration, vulnerable dependencies, unsafe deserialization, file upload flaws and weak authentication, and most map to categories in the OWASP Top 10.

Each one has a plain description and a control that stops it. Engineers already know these. The value for a leader is knowing which questions to ask:

1. SQL injection. Attacker input changes a database query and exposes or alters data. Control: parameterized queries everywhere, with no string built SQL.
2. Command and code injection. In PHP injection, input reaches a shell command or code evaluation. Control: never pass user input to a shell or eval, and use allow lists for anything that must.
3. Object injection through unsafe deserialization. Untrusted data rebuilt into objects can trigger unintended code paths. Control: avoid unserializing untrusted input and use a data only format such as JSON.
4. Cross site scripting. Attacker script runs in a user's browser. Control: encode output for its context and set a content security policy.
5. Broken access control. A user reaches data or actions they should not. Control: enforce permissions on the server on every request, with deny by default.
6. File upload and path flaws. An uploaded file is executed or a path escapes its folder. Control: validate type and size, store uploads outside the web root, and never execute them.
7. Vulnerable dependencies. A Composer package carries a known flaw or is abandoned. Control: lock versions, scan on every build, and retire packages nobody maintains.

The OWASP Top 10:2025 ranks Broken Access Control first, Security Misconfiguration second, Software Supply Chain Failures third, Cryptographic Failures fourth and Injection fifth. The list also includes Mishandling of Exceptional Conditions, a reminder that how software behaves when something goes wrong is itself a security issue.

Ownership differs by type. Engine flaws like php2shell are fixed by updating PHP, which is a platform responsibility. Code flaws are fixed by engineering. Dependency flaws need both. Assigning a named owner to each type is the first management decision.

How Do You Assess PHP Vulnerabilities Across Your Applications?

Assess PHP vulnerabilities in five steps: inventory every PHP application and version, match them against known exploited flaws, test the code and dependencies, review authentication and data paths by hand, and rank the fixes by exposure.

1. Inventory. List every application, the PHP version it runs, its framework, its extensions and its Composer packages. Include PHP that arrives inside purchased software, because CISA notes it is often not directly visible.
2. Match against known exploited flaws. Check each version against the CISA Known Exploited Vulnerabilities Catalog and the PHP security announcements. Anything on the list moves to the top of the queue.
3. Test. Run dependency scanning, a PHP vulnerability scanner and static analysis on the code, then dynamic testing against a running staging copy. Tools find known issues quickly. They do not find design flaws, which is why the next step exists.
4. Review by hand. Have an experienced engineer read the login, session, permission and data export paths. These are the places where one mistake exposes the most.
5. Rank and decide. Fix in this order: known exploited first, then internet facing, then systems that hold sensitive data. For each system, record one decision: patch, modernize in phases, or retire.

Put five questions to your team before the next board or customer review:

• Which PHP version does each production application run, and who owns it?
• Which of those versions are past end of life?
• Which applications are reachable from the internet?
• When was each last tested, and what did the test find?
• How fast can we ship an emergency patch, and who approves it?

If these answers take more than a day to assemble, the inventory is the first finding of any PHP security audit.

How Do You Prevent PHP Vulnerabilities from Reaching Production?

Prevent PHP vulnerabilities by running only supported versions, building security checks into the delivery pipeline, and reviewing every change, including code written with AI tools, before it merges.

Prevention is cheaper than response, and PHP security best practices come down to a short list of habits applied every release:

1. Supported versions only. Set a rule that no production application runs a branch within six months of its security end date without an approved upgrade plan.
2. Safe defaults in the code. Parameterized queries, output encoding, server side permission checks and strict input validation, enforced in code review.
3. Dependency governance. Locked versions, an automated scan on every build and a named owner for each package that matters.
4. Least privilege and secrets handling. Application accounts with minimum rights, and credentials kept out of code and logs.
5. Automated tests and a security gate. A failing security check blocks the release. Tests are also what make a version upgrade safe later.
6. Logging and alerting. Enough detail to see a PHP worker behaving oddly, before a customer reports it.

AI generated code needs its own rule. Models write correct looking code quickly, and correct looking is not the same as safe. Our post on vibe coding versus professional MVP development covers the published evidence on security flaws in generated code, and our explainer on AI augmented software development describes how review keeps AI speed without the risk. At Cabot, the standard is simple: we stay model neutral, a named engineer reviews every AI assisted change before it merges, and client code and data are never used to train a model. Ask any vendor, including us, to put that in writing. Our AI development services apply the same governance to AI features built into your products.

How Do You Mitigate a PHP Vulnerability When You Cannot Patch Today?

When you cannot patch today, reduce exposure first: take the most exposed systems offline or behind controls, add web application firewall rules as a stopgap, watch for signs of compromise, and set a dated plan for the real fix.

There are reasons a patch waits: a vendor has not released one, a release needs testing, or the application sits on a version with no fix. The sequence below buys time without pretending the risk is gone:

1. Reduce reach. Remove public access where you can. For systems on unsupported versions, CISA's advice is to take them offline until they are updated.
2. Add a stopgap control. A web application firewall may provide some protection, according to CISA. It only covers traffic that passes through it, so treat it as a delay, not a fix.
3. Watch for compromise. Look for PHP worker processes launching shells or downloading tools, and keep the logs you will need if you have to investigate.
4. Patch, then restart. Installing a new package does not change a running process. Restart the PHP workers so they load the fixed code, then confirm the version in production.
5. Set a deadline and an owner. A mitigation with no date becomes the permanent state.

One caution applies to every case. Patching closes the door but does not remove someone who is already inside. If a system was reachable and exposed while a known exploited flaw was live, check it for signs of compromise, not only for its version number.

Is Patching Enough, or Is It Time to Modernize Your PHP Application?

Patch when the version is supported and the code is sound, modernize in phases when you carry unsupported versions, abandoned dependencies or untested code, and rewrite only when the architecture itself blocks both.

The fear that stops many leaders is the rewrite: a long project that freezes the roadmap and may not finish. Phased work removes that fear, because each phase ships and each phase lowers risk. Three paths cover most cases:

1. Upgrade in place. Move to a supported PHP branch and update the framework and packages. This fits applications with sound structure and decent tests.
2. Phased migration. Move service by service to a supported stack while the existing application keeps running. This fits large applications with mixed code quality, and it keeps feature delivery moving.
3. Targeted rewrite. Rebuild only the parts that cannot be upgraded safely. When this is justified, prove the new design with a thin first release, the way an MVP development engagement does, before committing the rest.

Signs that patching alone has stopped working:

• The application runs a branch that is end of life, or will be within a year.
• Upgrades keep failing because packages are abandoned or tests are missing.
• Few people on your team are willing or able to maintain the code.
• Every release carries emergency fixes instead of planned work.

If two or more of these are true, plan a phased path instead of another patch cycle. Our application modernization services start from that assessment and sequence the work around your roadmap.

What Do PHP Vulnerabilities Mean for Healthcare and Regulated Applications?

For an application that holds electronic protected health information, a known and unpatched PHP flaw is a compliance finding as well as a security one, because the HIPAA Security Rule requires covered entities and business associates to assess and reduce risks and vulnerabilities.

The rule is specific. 45 CFR 164.308 requires an accurate and thorough assessment of the potential risks and vulnerabilities to electronic protected health information, and security measures sufficient to reduce those risks to a reasonable and appropriate level. A flaw on CISA's exploited list, in a system that stores patient data, is hard to describe as reasonable and appropriate once it has been public for weeks.

The cost of getting it wrong is also rising. IBM's 2026 Cost of a Data Breach Report puts the global average cost of a data breach at $4.99 million, a 12 percent increase over the prior year and a record high. Enterprise buyers, payers and health systems run security reviews before they sign, and they ask about supported versions, patch timelines and dependency scanning.

Healthcare adds one more exposure. EHR connections, partner APIs and data exchange all extend the surface an attacker can reach, so each integration inherits the risk of the PHP application behind it. Our healthcare software development and healthcare integration services treat those connections as part of the security review, not an afterthought.

How Does Cabot Help Technology Leaders Reduce PHP Risk?

Cabot helps technology leaders reduce PHP risk by assessing exposure first, then modernizing in phases alongside the roadmap, with security, testing and named engineer review built into every step.

Assessment before commitment

We start with the inventory and the ranked list described above: which applications run which versions, what is exposed, and what to do with each one. You receive a recommendation per system, patch, phase or retire, with the reasoning, so leadership can decide before any large budget is committed.

Phased modernization that keeps shipping

Our application modernization work moves applications to supported platforms in stages, so the product keeps releasing while risk falls. Automated tests come first, because they are what make each upgrade safe. Our QA and testing team builds that safety net before the code changes.

AI assisted analysis under human review

We use AI to speed up code and dependency analysis, and the governance rules do not change: we stay model neutral, a named engineer reviews every AI assisted change before it merges, and your code and data are never used to train a model.

Built for regulated environments

Cabot has built software since 2010, with more than 700 projects delivered for over 140 clients, including healthcare organizations that handle protected health information. We sign a business associate agreement before any patient data is handled, and you own the code and the IP from the first commit.

If you are comparing partners for this work, our guide on how to choose a software development company gives you the questions to ask. When you are ready to see where your PHP applications stand, talk to Cabot's engineering team.

Conclusion

Managing PHP vulnerabilities and PHP application security comes down to knowing what you run, keeping it supported, fixing what is exploited first, and having a plan for what cannot be patched. In the next 30 days: build the inventory, patch everything internet facing to a fixed PHP version, set upgrade dates for any application on PHP 8.2 or earlier, put a named owner on every mitigation, and decide which applications need phased modernization instead of another patch cycle.