Resources · Advisory

PHP Vulnerability: What You Should Do

PHP has published fixes for critical remote code execution vulnerabilities. Any internet-facing system running an outdated PHP version should be treated as at risk until it is patched. The PHP project’s own supported versions page currently carries an “update now” advisory.

The hard part is rarely the patch. It is knowing where PHP runs: old WordPress sites, resident portals, vendor-installed systems, and forgotten test servers. You can’t patch what you can’t find, so this guide starts with inventory.

Step 0: Find where PHP runs

Build a list of every system that runs PHP before changing anything. Start with what is reachable from the internet.

• Websites and portals: company site, resident or tenant portals, booking and payment pages.
• Content platforms: WordPress, Drupal, Joomla, Magento, and their plugins.
• Vendor-installed systems: property, access-control, or camera management consoles with a web interface.
• Hosting accounts: shared hosting, VPS, and cloud servers, including old test or staging sites.
• Record for each: owner, location, PHP version, whether it is internet-facing, and who maintains it.

To check a version, ask your hosting provider or run php -v on the server. Any system nobody can identify an owner for is a priority on its own.

Step 1: Apply patches immediately

Update every PHP installation to the latest release of a supported branch, published by the official PHP project at php.net. Anything older than 8.2 no longer receives security fixes at all.

Test updates on a copy first where possible, and back up before patching production. Update CMS plugins and themes at the same time.

Step 2: Take vulnerable systems offline if you can’t patch

If a system cannot be updated right away, remove it from the internet until it can. An unpatched public server is the most likely entry point.

• Take the site or server offline, or serve a maintenance page from a patched host.
• Restrict access to known IP addresses or a VPN if the system must stay up.
• Disable the affected application or plugin if the rest of the site can run without it.
• Set a deadline and an owner for the fix. Isolation is a pause, not a solution.

Step 3: Monitor for signs of compromise

Patching closes the door but does not tell you whether someone already got in. Review server logs, or ask your host or IT provider to, for:

• Unusual traffic: spikes, requests from unexpected countries, repeated hits on odd URLs.
• Unauthorized database queries or new admin accounts.
• New or changed files in web folders, especially .php files you did not upload.
• Unexpected outbound connections or CPU usage from the server.

If you find signs of compromise, keep the system isolated and bring in a qualified incident-response provider before restoring it.

Quick checklist

• List every system running PHP, with owner and version.
• Mark which systems are internet-facing.
• Update each to the latest supported PHP release.
• Isolate anything that cannot be patched today.
• Review logs for signs of compromise.
• Retire, or assign an owner to, every unowned system.

How HalaOne helps

A HalaOne Asset Audit builds the Step 0 list for you: every system, its location, owner, software version, and support status, in one record. Lifecycle tracking then flags software and hardware as it approaches end of life, so the next advisory starts with a known list instead of a search.

Request an Asset Audit →

This guide is general information, not a security service. HalaOne provides IT asset management; patching, monitoring, and incident response should be carried out by your IT team or a qualified security provider. Questions: contact@halaone.io.