PHP Security Vulnerabilities: What They Mean for Your Website (And What We Did at MyKayd)

Your website can be working perfectly and still be running vulnerable software.

Pages load. Customers sign in. Forms get submitted. Everything looks normal. But underneath the application, the server might be running outdated software with known security flaws. Recently we performed a maintenance update on MyKayd, our Laravel-powered form and response platform. Here is what PHP vulnerabilities mean, how they can affect websites, and what we actually did.

What is a PHP security vulnerability?

PHP executes server-side code to handle requests, process data, and interact with databases. A vulnerability is a weakness in the PHP runtime, an extension, or related software. On October 21, 2026, the PHP security team published emergency updates for two critical, unauthenticated remote-code-execution vulnerabilities in the PHP runtime itself.

Both CVE-2026-109618 and CVE-2026-109619 are rated 9.2 (Critical). The first involves memory corruption during out-of-memory handling; the second involves stale internal request state that can survive worker reuse. Both can permit code execution without authentication on vulnerable installations. Unlike many application-specific bugs, these flaws are in PHP request processing itself; an exploit has been demonstrated before application code runs. Internet-facing PHP services should be checked and patched urgently.

Exploitability is not identical across configurations, and a published vulnerability does not prove compromise. However, these are not merely theoretical risks or flaws limited to a specific Laravel application. See the CERT-EU advisory and Google Cloud analysis.

A published vulnerability also does not mean a website has been compromised. It means the owner should determine whether the system is affected and apply the appropriate fix.

How could it affect a real website?

Imagine a form application that receives responses, validates fields, stores answers, processes uploaded images, and sends notifications. The October 21 vulnerabilities affect the PHP runtime beneath those application features—not just a particular form field, image library, or Laravel dependency. A vulnerable PHP worker may be exposed when handling a crafted request even if the application code is otherwise secure.

Secure application code matters, but so do the runtime, operating system, database, and background services beneath it.

What we updated at MyKayd

MyKayd runs on an Ubuntu VPS with Nginx, PHP-FPM, Laravel, PostgreSQL, and background queue workers. During our October 2026 maintenance we verified PHP 8.4.27, updated the active PostgreSQL 18 installation to 18.6, installed reviewed Ubuntu package updates, and rebooted into the updated Linux kernel. PHP 8.4.27 is the upstream security release published on October 21, 2026 for these CVEs. Our PHP 8.4 packages come from Ondřej Surý's PHP PPA (ppa:ondrej/php), not Ubuntu's default PHP repository. We confirmed this using apt-cache policy php8.4-fpm, which reports installed version 8.4.27-1+ubuntu24.04.1+deb.sury.org+1 from the PPA's Ubuntu Noble repository. We have not established the precise time at which the PHP update was applied relative to the advisory, so we do not claim that MyKayd was exposed or compromised before maintenance.

We created a PostgreSQL backup first, checked the archive was readable, and copied it off-server. After rebooting we checked service status for Nginx, PHP-FPM, PostgreSQL, and the queue worker, confirmed Laravel could connect to PostgreSQL, and made an HTTP request that returned status 200. We also checked the PHP CLI version and the PHP-FPM service status. These are operational checks, not a penetration test or proof that every application feature works.

Those checks confirm important infrastructure health, not every user journey. End-to-end form submission and notification-delivery tests were still outstanding at the time of writing.

Commands to check your own Ubuntu PHP server

These commands are examples for a self-managed Ubuntu server. Do not delay critical security updates unnecessarily: follow your distribution or provider's advisory, back up important data, and apply the corrected package promptly. On October 21, Ubuntu published USN-8948-1 for supported Ubuntu PHP packages. A standard system update generally installs the corrected Ubuntu packages; machines using unattended upgrades may already have received them, but you must verify installed package status and restart affected PHP workers.

The upstream fixes are PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. For Ubuntu 24.04 LTS, USN-8948-1 lists a patched php8.3 package; it does not establish the patch status or source of a separately installed PHP 8.4 package. Distribution backports and third-party repositories can use different version numbers. Check apt-cache policy and the actual running PHP-FPM binary as well as your vendor's notice.

1. Check PHP and PHP-FPM

php -v
php-fpm8.4 -v
sudo systemctl status php8.4-fpm --no-pager
apt-cache policy php8.4-fpm

CLI PHP can differ from the version serving web requests. php -v checks the command-line interpreter; php-fpm8.4 -v checks the PHP-FPM executable. Confirm Nginx actually points to the intended FPM socket or upstream, and restart PHP-FPM after a security update so existing worker processes no longer use an older runtime. Adjust the service name to match your installed PHP-FPM version.

2. Review updates before installing

sudo apt-get update
apt list --upgradable
sudo apt-get -s upgrade

The -s flag simulates an upgrade without installing anything. For affected systems, install vendor security fixes promptly (for example, sudo apt-get upgrade after reviewing the package plan), restart the affected PHP-FPM service if the package did not do so, and verify the running worker uses the patched build. A CLI version check alone is insufficient. If PHP-FPM was not restarted as part of the package update, use sudo systemctl restart php8.4-fpm during an appropriate maintenance window, then confirm systemctl is-active php8.4-fpm reports active. Restarting may briefly interrupt in-flight requests.

3. Back up PostgreSQL

pg_dump -Fc -U YOUR_DB_USER \
  -d YOUR_DATABASE \
  -f database-backup.dump

pg_restore --list database-backup.dump

Replace the placeholders and use an appropriate secure backup location. Listing an archive confirms it is readable; it is not a substitute for testing a restore. Back up uploads and configuration separately where applicable.

4. Verify Laravel and services afterward

php artisan about
php artisan db:show
php artisan queue:failed

sudo systemctl is-active nginx php8.4-fpm postgresql
curl -s -o /dev/null -w "%{http_code}\n" https://your-domain.example

An HTTP 200 and an active service are useful signals, not proof that sign-in, submissions, notifications, or integrations work. Test those workflows directly after maintenance.

What if an update breaks production?

Plan recovery before applying changes. Keep a tested off-server database backup, preserve relevant configuration, and, where your provider supports it, create a VPS snapshot or other known-good recovery point. Record the installed package versions and how to reach your hosting provider.

If PHP-FPM fails after an upgrade, first inspect systemctl status php8.4-fpm and journalctl -u php8.4-fpm -n 100 --no-pager, check PHP-FPM configuration with sudo php-fpm8.4 -t, and resolve configuration or extension compatibility problems. Restore from a verified recovery point only when necessary and with a plan for any data written since the snapshot.

Do not treat apt-mark hold as a rollback: it only prevents future package upgrades. Avoid reverting to a known-vulnerable PHP build; prefer a corrected package, a compatible configuration fix, or a controlled recovery with appropriate security mitigations.

Who is responsible for PHP updates?

On managed hosting, the provider may maintain the operating system and PHP runtime, but you should confirm exactly what is covered. On your own VPS, you or your infrastructure team usually own those updates, backups, monitoring, and recovery procedures.

Automatic security updates can reduce exposure, but they still require monitoring, reboot policies, and a recovery plan. Some distributions also backport security fixes, so a version string alone does not always reveal patch status.

Final takeaway

Building a website is one job. Operating it reliably is another. Check your software versions, follow security advisories, back up data, review changes before upgrading, and verify the features customers actually use afterward.

Do not wait for your website to break before maintaining the software underneath it.

Advisories: PHP 8.4.27 security release, Ubuntu USN-8948-1, and CERT-EU advisory.