Recent PHP vulnerabilities: what happened in 2026 and how to secure your site

If your website runs on PHP, and most websites in the Philippines do (WordPress, Laravel, custom systems and many school, clinic and shop websites), then October 2026 was an important month. The PHP project released fixes for two critical vulnerabilities that can let an attacker run their own code on your server without logging in.

This guide explains what happened in plain words, how to check if you're affected, and the steps to secure an existing system, including tips for shared hosting like Namecheap, Hostinger and other cPanel hosts.

What happened in October 2026

On 20 October 2026, the PHP security team gave advance notice of an urgent release. On 21 October they released PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, which fix two critical flaws, both rated 9.2 out of 10 (CVSS v4.0):

• CVE-2026-109618, "RCE via OOM corruption" (GitHub advisory GHSA-w8hw-w9fx-j79w). When PHP runs out of memory at the wrong moment, it can be interrupted while internal request data is only half set up. Cleanup then treats that broken data as valid.

• CVE-2026-109619, "RCE via stale global state" (GHSA-6wmf-4rv5-p3rp). Some internal state from one request can survive after its memory is freed, and a later request on the same worker can use it.

"RCE" means remote code execution: the worst kind of bug. An attacker who succeeds can read your database, plant malware, send spam from your server or deface your site.

Who is affected?

According to the PHP team, all PHP installations serving web requests are at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. They rated the risk highest for mod_php, where an unauthenticated request can trigger the attack before any of your own code runs. That means even a perfectly written app is exposed if PHP itself is old.

Their advice was blunt: there are no complete workarounds, and updating is the only safe choice.

Other PHP fixes this year

The October release wasn't a one-off. PHP shipped security fixes in several releases through 2026. For example, the 24 September security releases (PHP 8.5.11, 8.4.26, 8.3.35 and 8.2.34) fixed problems in OpenSSL certificate hostname checks, the SOAP extension, Phar archives, the HTTP stream wrapper and the PHP-FPM IP allow-list. Most sites never notice these, but each one is a door an attacker could try. Staying on the latest patch release closes them all at once.

And for Laravel users

Frameworks have their own fixes. In 2026 the Laravel framework published several security advisories, including:

• CVE-2026-114509 (critical, 19 October 2026): an authentication bypass in Laravel's built-in token-based API guard (TokenGuard) under certain MySQL/MariaDB setups. Fixed in Laravel 12.68.0 and 13.29.0.

• CVE-2026-48019 (high, 1 June 2026): CRLF injection through the default email validation rule, which can affect apps that send mail to user-supplied addresses, like contact and sign-up forms. Fixed in 12.60.0 and 13.10.0.

Neither advisory lists a workaround. The fix is to upgrade.

Background: an older one worth knowing

Not new, but still exploited on forgotten servers: CVE-2024-4577 (June 2024), a PHP-CGI argument injection bug on Windows servers using certain language settings. Default XAMPP for Windows installs were among those exposed. If you have an old Windows box running PHP for an office system, it is a reminder that "it still works" doesn't mean "it's still safe".

Step 1: Check your PHP version and upgrade

Find your version. On a server you control, run:

php -v

On shared hosting, log in to cPanel and open Select PHP Version or MultiPHP Manager (the name depends on your host). You can also make a temporary file with <?php phpinfo();, open it once, then delete it immediately.

As of November 2026, these branches are supported by the PHP project:

• PHP 8.5: active support until 31 December 2027, security fixes until 31 December 2029.

• PHP 8.4: active support until 31 December 2026, security fixes until 31 December 2028.

• PHP 8.3: security fixes only, until 31 December 2027.

• PHP 8.2: security fixes only, and it reaches end of life on 31 December 2026. Plan your move now.

PHP 8.1 and older get no updates from the PHP project. If your site is on 7.4 or 8.0, it is running without a safety net. Upgrade to 8.4 or 8.5 if your code allows it, and test on a copy first.

If you can't upgrade today, the PHP advisory lists partial measures, such as setting session.upload_progress.enabled=0 in php.ini or the FPM pool and restarting PHP, and keeping post_max_size low (8M if you don't need uploads). These reduce risk but, in the PHP team's words, do not make an installation safe. Treat them as a stopgap for days, not months.

Step 2: Harden php.ini

A few settings make a big difference in production:

display_errors = Off
log_errors = On
expose_php = Off
allow_url_include = Off
session.cookie_httponly = 1
session.cookie_secure = 1
session.use_strict_mode = 1
session.upload_progress.enabled = 0

If your app never needs to run shell commands, consider disabling the dangerous functions attackers love:

disable_functions = exec,passthru,shell_exec,system,proc_open,popen

Test after changing this. Some tools (like queue workers or image libraries) may need one of these.

Step 3: Update your dependencies

Your own code is only part of the story. Libraries in vendor/ have bugs too. If you use Composer, run:

composer audit
composer outdated --direct
composer update

composer audit checks your installed packages against known security advisories. Run it every month, and before every deploy. Commit composer.lock so the server installs exactly what you tested. For WordPress, update core, themes and plugins, and delete the ones you don't use.

Step 4: Laravel-specific checks

• Upgrade the framework. Check with composer show laravel/framework and make sure you are past the fixed versions above.

• Turn off debug mode. In production, .env must have APP_ENV=production and APP_DEBUG=false. A debug page can leak your database password and keys.

• Protect your .env file. Your web root should point to public/, never to the project folder. If someone can open yoursite.com/.env, fix this today.

• Rotate APP_KEY if it may have leaked. Laravel 11 and newer support APP_PREVIOUS_KEYS, so you can set a new key with php artisan key:generate and keep the old one there while encrypted data and sessions move over. Rotate database and mail passwords at the same time.

• Use the built-in protections: CSRF tokens on forms, Blade's {{ }} escaping, Eloquent or query bindings, and Form Request validation.

Step 5: Secure your code

Use prepared statements

Never paste user input into SQL. With plain PDO:

$stmt = $pdo->prepare('SELECT * FROM orders WHERE email = ?');
$stmt->execute([$email]);

Validate input, escape output

Check that every value is what you expect (an email is an email, a quantity is a whole number). When printing user content into HTML, escape it:

echo htmlspecialchars($name, ENT_QUOTES, 'UTF-8');

Make file uploads boring

• Allow only the file types you need, and check the real type, not just the extension.

• Rename uploads to random names and store them outside the public folder when you can.

• Never let an uploaded file run as PHP. A "photo" named invoice.php is a classic way in.

• Limit the file size.

Step 6: Server and hosting basics

• File permissions: folders 755, files 644, and .env or config files 600 or 640 where your host allows. Never use 777.

• Turn on a WAF. Many hosts include ModSecurity or Imunify360. Cloudflare's free plan also adds a layer in front of your site.

• Use SSH keys and two-factor login for cPanel, your registrar and your hosting account.

• Remove leftovers: old backups like site.zip in the web root, phpinfo() files, test scripts and unused admin panels.

Step 7: Watch, log and back up

• Read your logs. Check error logs and access logs for strange requests, like many hits on /wp-login.php or /.env.

• Set up uptime and change alerts so you hear about problems before your customers do.

• Back up daily, and keep copies off the server. Use your host's backup tool (such as JetBackup in cPanel) plus a copy in Google Drive or another account. Test a restore at least once.

• Subscribe to announcements: the php.net news page and the GitHub security advisories of the frameworks you use.

Your quick checklist

1. PHP on 8.5.12, 8.4.27, 8.3.36 or 8.2.35 or newer.

2. Plan off PHP 8.2 before 31 December 2026, and off anything older right away.

3. Laravel at or above 12.68.0 or 13.29.0.

4. composer audit shows no advisories.

5. APP_DEBUG=false, .env not reachable, web root on public/.

6. Hardened php.ini, safe file permissions, WAF on.

7. Off-site backups you have actually restored once.

Security isn't a one-time job. Put a monthly reminder in your calendar: update, audit, check backups. For more habits like this, read our web development best practices.