PHP Security Assessment: What It Checks and How to Start
Read Time 7 mins | Written by: Vinayak Bhagat
The bottom line: PHP2Shell showed that most companies cannot say, fast, where PHP runs and which version is live. A PHP security assessment fixes that. It takes a few weeks, and the first steps cost nothing but time.
There is also a deadline. PHP 8.2 reaches end of life on December 31, 2026. After that, it gets no more security fixes from the PHP project.
Who needs one
If any of these run on PHP, you are in scope:
- Your website or CMS (WordPress, Drupal, Magento)
- An ecommerce storefront
- Customer or partner portals
- Internal tools built years ago
- Apps a vendor hosts for you
The last two are where old PHP usually hides. Nobody remembers them until an advisory lands.
What a good assessment checks
- Version. Which PHP runs on every server, and is it still supported? Check what the web workers serve, not just the command line.
- Server setup. How PHP is served and which account it runs as. That account decides how much an attacker can reach.
- Packages. The third-party code your apps pull in. Composer's built-in audit flags known problems in minutes.
- Your code. How input reaches databases, how uploads are stored, and whether passwords sit in the code.
- CMS and plugins. Every plugin and theme, who owns it, and whether it is still updated.
- Patch path. When a fix ships, who hears about it and how it reaches every server.
What to do this week
- List every PHP system. Production, staging, old containers and vendor-hosted apps. A shared spreadsheet is enough to start.
- Write down the live version. Compare it with the PHP supported versions page. Flag anything on 8.2 or older.
- Ask your hosts in writing. On managed hosting, the provider controls PHP. Get the running version confirmed by email.
- Run a package audit. composer audit on each app takes minutes.
- Name an owner. One person who reads PHP advisories and makes sure patches land.
Anything critical and reachable from the internet gets fixed the day you find it. Everything else goes on a ranked list.
Why it matters now
Most breaches do not come from clever attacks. They come from the gap between a patch shipping and a patch running. With PHP2Shell, that gap was measured in hours.
Teams that already had a PHP inventory answered "are we exposed?" in an afternoon. Everyone else built one under pressure. Do it now, before year-end change freezes and before PHP 8.2 goes out of support.
How Ontrac helps
- PHP Security Assessment: we find every PHP system, including the forgotten ones, and rank them by risk.
- Patching help: our engineers apply, restart and verify updates across servers, containers and hosts.
- Legacy upgrades: for apps stuck on old PHP, we plan the upgrade and fix the code that blocks it.
- Extra hands: developers or DevOps engineers who plug into your team for the busy weeks.
Running a small estate on a supported version with clean audits? You can do this yourselves with the checklist. Need the whole stack reviewed, not just PHP? See our tech stack audit.
Book a call with usFrequently Asked Questions
How long does a PHP security assessment take?
For most mid-market companies, a few weeks. The inventory and version check can be done in days; code review and fixes take longer.
Is it the same as a penetration test?
No. An assessment finds and reviews your PHP systems and confirms fixes. A penetration test tries to break in. Do the assessment first.
Which PHP versions are still supported?
As of November 2026, PHP 8.2 to 8.5. PHP 8.2 reaches end of life on December 31, 2026, and 8.1 and older are already out of support.
Keep reading
→ Tech Stack Audit as a Service: when the question is the whole stack, not just PHP.
→ Cloud Migration for Mid-Market: if the upgrade plan becomes a move off old hosting.
Sources: php.net, PHP security advisories, Composer documentation. This post reflects information available as of November 2, 2026.