PHP Vulnerability: Check Your Version and Find Security Updates

Checking for a PHP vulnerability starts with identifying the PHP version your site actually uses, then matching it against official PHP security announcements and your operating system’s patch records. Run php -v for the command-line version, check the web server separately, and apply the latest security update available from your trusted package provider. A version number alone does not prove a server is vulnerable, particularly when a Linux distributor has backported a fix.

Security update, October 22, 2026: PHP’s official news reports critical security fixes released October 21, 2026, involving CVE-2026-109618 and CVE-2026-109619. Operators should consult the release-specific advisory and update promptly. Do not assume that every installation, configuration, or branch has identical exposure; confirm the affected versions and patches from the advisory and your software vendor. Read the official PHP release announcements.

1. Find your installed PHP version

On a Linux server or macOS terminal, run:

php -v

On Windows, open PowerShell or Command Prompt and run the same command if PHP is on your PATH. The output identifies the command-line interpreter (CLI). If the command is not found, PHP might still be installed for a web server, or its executable may be outside your shell PATH.

2. Confirm the version used by your website

Command-line PHP and web-serving PHP may use different installations. Check the version in your hosting dashboard, your PHP-FPM pool configuration, or a trusted administration interface. If you administer the site directly, you can temporarily create a file in a restricted staging or localhost environment containing <?php echo PHP_VERSION; ?>, request it through the web server, record the value, and delete the file immediately. Never leave an openly accessible phpinfo() page online: its configuration output can expose sensitive operational details.

For PHP-FPM, check the service or pool assigned to your virtual host; for containers, query the running application container rather than only the host. The relevant version is the one that processes the site’s requests.

3. Check whether the PHP branch is still supported

PHP currently lists the 8.2, 8.3, 8.4, and 8.5 branches as supported, with differing active-support and security-only periods. PHP 8.2 reaches upstream end of life on December 31, 2026. PHP 8.1 and older have already reached upstream end of life. Verify support dates at PHP Supported Versions.

An unsupported upstream branch calls for an upgrade plan, even if an individual vulnerability does not apply. However, enterprise Linux vendors sometimes maintain packages beyond PHP’s upstream schedule; check the specific distribution’s security lifecycle and advisories before interpreting the status of a packaged build.

4. Find official security advisories and fixed versions

1. Start with PHP.net news for release notices, and read the PHP 8 changelog to identify security-related fixes.
2. Review the applicable CVE entry and the original vendor advisory. Look for affected branches, fixed releases, prerequisites, and exploitation conditions.
3. For Debian, Ubuntu, Red Hat, or another packaged distribution, cross-check the distro’s security tracker or notice, including patched package release and revision.
4. For managed hosting, ask the provider which PHP build is deployed and when the relevant security fix was applied.

Official distribution references include Ubuntu Security Notices, Debian Security Tracker, and Red Hat Security Updates.

5. Apply updates and verify the running service

Back up application files, configuration, and database state, and test a supported PHP version with your framework and extensions. On Ubuntu or Debian, check available updates using:

sudo apt update
sudo apt list --upgradable

Then apply the appropriate vendor-provided package upgrades under your normal change-control process, for example sudo apt upgrade. A major PHP migration may require explicit package selection and changes to PHP-FPM pool configuration; it is not guaranteed by a routine upgrade command. Restart or reload the affected PHP-FPM and web services only as appropriate for your deployment, and check application health afterward.

On Red Hat-family systems, review dnf updateinfo and your vendor advisories before applying the relevant updates. For Docker and other containers, rebuild from a patched trusted base image, redeploy, and verify the PHP version inside the running container. Update extensions and application dependencies separately when advisories affect them.

Common misunderstandings about PHP security

• “My terminal says the latest PHP version, so my website is safe.” The web process may run another PHP binary. Check the web-facing runtime.
• “The version string matches a vulnerable release, so the flaw is definitely exploitable.” A distributor may have backported the security patch without changing the upstream version number. Read package changelogs and vendor security notices.
• “A supported branch automatically means every patch is installed.” Support eligibility is not installation status. Confirm the installed patch release.
• “Changing the PHP version fixes every website vulnerability.” PHP patches do not replace updates for WordPress, frameworks, plugins, dependencies, or unsafe application code.

Quick verification checklist

• Record both CLI and web-serving PHP versions.
• Check upstream lifecycle support and the vendor’s security maintenance policy.
• Read official PHP and distributor advisories, including any fixed-version details.
• Deploy and test patched builds, including containers, extensions, and dependencies.
• Confirm the service is running the intended updated PHP build, then remove diagnostic files.

For sites handling sensitive data, review logs for suspicious activity and follow your organization’s incident response procedures when an applicable critical vulnerability may have been exposed. A successful update prevents future exploitation of the fixed bug but does not by itself establish that the server was never compromised.