If you run PHP, find out exactly which version and build serves your sites. Compare it with the fixed releases named in the official advisory, update through the channel that installed it, restart services and check for signs of compromise.
Search data from Google in the United States shows a rise in queries such as “php vulnerability 2026”, “php2shell” and “CVE-2026-109618”. The source gives no technical details, so this guide does not say which PHP versions or components are affected, or how serious the flaw is. It does not confirm that the identifier is genuine either. Instead, it sets out a routine you can use for any reported PHP flaw, so you can act on verified information when it is published.
Gather what you need before starting
PHP is a server-side scripting language. It runs behind a large share of websites, including many content management systems, shops and internal tools. A flaw can sit in the PHP interpreter itself, in one of its extensions, or in an application written in PHP. These three cases need different fixes.
Before you start, make sure you have:
- Shell or control-panel access to every server that runs PHP, including staging and old machines that are easy to forget.
- A recent, tested backup of your application files and databases.
- A note of how PHP was installed on each machine: operating system packages, a third-party repository, a container image, a hosting provider’s selector, or a manual build.
- A maintenance window, or at least permission to restart web services.
- A plain list of the PHP applications and plugins you run.
Confirm the exact PHP version in use
Run php -v on the command line to see the version of the command-line interpreter. Your web server may use a different binary. PHP-FPM pools, Apache modules and hosting selectors can each point to their own version. To check what web requests actually use, put a temporary page that calls phpinfo() in a protected location, read the version and loaded extensions, and delete the page straight away. That output reveals a lot about your server and should never be left public.
Note the full version string and the package release on each host. On Linux distributions, the package manager can show the installed build. That is what matters when vendors backport fixes.
Find the official advisory for the CVE
Look up the identifier in the CVE record maintained by the CVE Programme and in the US National Vulnerability Database. Then check the PHP project’s own changelog and security announcements, and your operating system vendor’s security tracker. Your goal is to answer four questions: which component is affected, which versions are vulnerable, which releases fix the problem, and whether any workaround exists.
If you cannot find an official record, treat the name as unconfirmed. Names spread through search trends and social media can be mistaken, mistyped or invented. Blog posts and forum threads do not replace the vendor’s own advisory.
Update PHP through the channel that installed it
Apply the fix the same way PHP was installed. For distribution packages, use the system package manager and install the vendor’s security update. The version number on screen may not change, because many distributions backport patches into older releases. Check the package changelog rather than relying on the version alone. For third-party repositories, update from that repository. For containers, rebuild from an updated base image and redeploy; do not patch a running container. On shared hosting, use the provider’s version selector or contact their support team.
If your PHP branch has reached end of life, a fix may never arrive for it. In that case, the proper fix is to move to a supported branch.
Restart PHP services and verify the change
Installing new packages does not always replace code that is already loaded in memory. Restart PHP-FPM and the web server, or the container, so the patched binaries are actually in use. Then repeat the checks from the version step, both on the command line and through the web server. Load your main pages, log in, and test any forms or uploads to confirm nothing has broken.
Audit the application and its dependencies
Many problems described as PHP vulnerabilities are really flaws in frameworks, plugins or libraries. If you use Composer, run composer audit in each project to compare installed packages with known advisories, then update the affected packages. For content management systems, update the core software, themes and plugins through their own update tools, and remove any plugins you no longer use.
Look for signs of compromise
Patching closes the hole but does not remove anyone who got in earlier. Look for PHP files in places they should not be, especially upload folders, cache and temporary folders. Check for recently changed files you cannot explain, unknown administrator accounts, unexpected scheduled tasks, and outbound connections you do not recognise. Web server logs can show unusual requests to odd script names. If you find a planted script, often called a web shell, assume the server is compromised. Bring in incident response help rather than just deleting the file.
Avoid the mistakes people actually make
- Checking only the command-line version. The web server often runs a different PHP build from the one
php -vreports. - Assuming the version number tells the whole story. Distribution packages carry backported fixes, so an older-looking number may already be patched. A matching number may also hide an unpatched build.
- Forgetting secondary systems. Staging servers, old marketing sites and admin tools are often left unpatched.
- Leaving diagnostic pages online. A forgotten
phpinfo()page gives attackers a detailed map of your server. - Skipping the restart. Long-running PHP-FPM processes keep the old code until they are restarted.
- Acting on rumour. Changing settings or disabling features because of an unverified social media post can cause outages without improving security.
Recognise when this approach is the wrong choice
This routine assumes you control the server and that the issue can be fixed by updating software. It is not enough if you find signs of an active intrusion. Then you need to isolate the system, preserve evidence and follow an incident response plan, ideally with professional support. It does not fit fully managed platforms either: there, the provider patches the runtime and your job is mainly to keep your application code and plugins up to date. Finally, if your application only runs on an end-of-life PHP branch, patching is not possible. You face a migration project, and in the meantime you should put protective controls such as a web application firewall and restricted access in front of the site.
Frequently asked questions
What is PHP and why do its vulnerabilities matter?
PHP is a server-side scripting language used to build websites and web applications, including many popular content management systems and online shops. Because it processes requests from the internet, a flaw in the interpreter, an extension or an application can let attackers read data, change content or run their own code on the server. That is why administrators watch PHP security announcements closely and apply updates quickly.
How do I check which PHP version my website uses?
Run php -v on the server for the command-line version. Remember that the web server may use a different build. To see what web requests actually use, temporarily place a protected page that calls phpinfo(), read the reported version and extensions, and then delete the page. On shared hosting, the control panel usually shows the active PHP version for each site.
Is CVE-2026-109618 a confirmed PHP vulnerability?
Search data shows people looking up this identifier alongside PHP-related terms, but its details are not known here. Its affected versions, severity and fixes have not been verified. To confirm whether it exists and what it covers, check the CVE Programme’s record, the US National Vulnerability Database and the PHP project’s security announcements. Treat any claims that are not backed by those official sources with caution.
Does updating PHP remove an attacker who already got in?
No. Updating closes the weakness that was exploited, but it does not remove files, accounts or scheduled tasks an attacker may have added before the patch. After updating, look for unexpected PHP files in upload and temporary folders, unknown user accounts and unusual log entries. If you find evidence of intrusion, isolate the system and follow a proper incident response process.
Sources and further reading
- The PHP project: official changelogs, supported-versions information and security release notes.
- The CVE Programme: the authoritative record for vulnerability identifiers.
- The US National Vulnerability Database (NIST): severity scoring and links to vendor advisories.
- Operating system vendors’ security trackers: details of backported fixes in distribution packages.
Surfaced from the google:US signal “PHP security vulnerability searches”. AI-assisted draft, editorially reviewed.
