Original announcement: · Reporting prepared on the publication date above.
What to know
- Verify the full vendor package release for both vulnerabilities.
- Confirm that website workers actually use the fixed binaries.
- Keep a record of application checks after maintenance.
What PHP announced
On 21 October 2026, the PHP project announced fixes for two critical remote code execution vulnerabilities: CVE-2026-109618 and CVE-2026-109619. The upstream fixed releases named in that announcement were 8.2.35, 8.3.36, 8.4.27 and 8.5.12. These are the announcement’s fixed versions, not a promise that they remain the newest releases. Read the original PHP security notice for updates.
Why the hosting runtime matters
The first flaw involves unsafe request state after a memory allocation failure. The second involves request-owned state surviving after its memory has been freed. An application can have strong passwords and still depend on an affected runtime. Exploit conditions differ by server integration, extensions and application behavior; the memory handling advisory and request-state advisory describe those distinctions.
Check the package, not only the version banner
Hosting vendors can apply the security changes to an existing PHP branch. A version banner alone cannot prove whether that vendor build is fixed. Ask for the complete package release and a changelog naming both vulnerabilities. cPanel separately lists its own builds and CloudLinux’s patched EasyApache packages.
Also identify every runtime serving the account: the command-line PHP, PHP-FPM pool and LiteSpeed handler may use different installations. Record which package actually handles website requests.
A practical verification checklist
- Back up the application and database, and record the current handler and extensions.
- Install the vendor’s signed security packages for every exposed PHP installation.
- Replace or gracefully reload old workers according to the server’s documentation.
- Check a real website request, then test sign-in, checkout and any required uploads.
- Review access and application logs and investigate unexpected changes separately.
A successful package transaction is one piece of evidence. A functioning application and a patched live worker are the other pieces your maintenance record should include.
Questions to send your hosting provider
Ask: “Which package serves my domain, does its release fix both CVEs, when were workers replaced, and which application checks passed?” If you manage several websites, request an account-by-account answer. Configuration workarounds are not equivalent to the complete patch, according to PHP.
For help planning an update, describe your stack through Kiava IT services. Our Linux VPS security checklist explains the ongoing controls around patching.
Sources & further reading
Primary sources supporting this article. The practical recommendations are Kiava’s general guidance and should be adapted to your project.