From PHP2Shell to Laravel and WordPress Plugins: October 2026 PHP Security Issues and How to Check Your Servers

In one line

On 21 October 2026 the PHP project released PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, fixing two core vulnerabilities that can allow unauthenticated remote code execution. If a server handles web requests with PHP, check the version, update, and then restart every PHP worker.

PHP news arrived all at once this month. After the two core remote code execution flaws (widely called PHP2Shell), the PHP project published guidance on 23 October for a follow-up session issue that does not have a patch yet. On the framework side, Laravel fixed an authentication bypass in its token-based API guard, and in WordPress the Bricksforge plugin's file upload flaw was reported as targeted by attack attempts from just before its disclosure.

In Korea, KISA posted a PHP update advisory and a response guide for companies on its KrCERT portal (boho.or.kr), and on 22 October the Ministry of Science and ICT raised the private-sector cyber crisis alert from "Attention" to "Caution". If you run a PHP site yourself or had one built by an agency, it is worth checking this week.

Below we go issue by issue: what happened, how to tell whether your servers are affected using read-only checks, what to do right now, and how to make the next round easier.

At a glance

Issue	Disclosed	Affected	Fixed in	Primary sources
PHP core RCE x2 (CVE-2026-109618, CVE-2026-109619)	2026-10-21	Versions before 8.2.35, 8.3.36, 8.4.27, 8.5.12. No official updates for 8.1 and older	8.2.35 / 8.3.36 / 8.4.27 / 8.5.12	php.net, KISA
PHP session follow-up (CVE-2026-115560)	2026-10-23	Only a specific configuration and code combination	Not yet released (next regular release)	php.net, KISA
Laravel TokenGuard auth bypass (CVE-2026-114509)	2026-10-19	Before 12.68.0, and 13.0.0 up to before 13.29.0	12.68.0 / 13.29.0	GHSA, KISA
WordPress Bricksforge file upload (CVE-2026-85097)	2026-10-08	3.1.8.9 and earlier	3.1.8.10 (3.x) / 4.0.0 (4.x)	NVD, Bricksforge

What happened

1. Two PHP core remote code execution flaws (PHP2Shell)

On 20 October the PHP project announced a critical security release for 14:00 UTC the next day, and on 21 October it shipped PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 together with a security advisory. According to The PHP Foundation, the release was moved up by a day from 22 October after a leak.

Two vulnerabilities were fixed:

• CVE-2026-109618 (GHSA-w8hw-w9fx-j79w): out-of-memory handling can interrupt PHP while request data is only partially initialized, and request cleanup may then treat that data as valid.
• CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp): request-owned internal state can survive after its memory has been freed, and a later request on the same worker may use it.

Both are rated 9.2 (Critical) under CVSS v4.0. The GHSAs list versions before 8.2.35, 8.3.36, 8.4.27 and 8.5.12 in each branch as affected. The php.net advisory says every PHP installation serving web requests is at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed, and considers mod_php the highest risk. Because the flaws sit in the language runtime, WordPress, Laravel and hand-written code are all affected if the PHP version is.

PHP 8.1 and older no longer receive updates from the PHP project. Given the severity, the PHP security team provided minimal source backports for 7.4, 8.0 and 8.1, and the advisory notes that some distributions and LTS vendors offer backported fixes. PHP 8.2 also reaches the end of security support on 31 December 2026, according to the supported versions page.

In Korea, KISA published a PHP security update advisory on 21 October and a PHP2Shell response guide for companies on 22 October. The same day the Ministry of Science and ICT raised the cyber crisis alert and advised small businesses on shared hosting to ask their provider whether the update has been applied.

2. A follow-up session issue with no patch yet (CVE-2026-115560)

On 23 October php.net added an informational advisory on session upload progress. A remote code execution path exists only when all three of the following are true:

1. The configuration sets session.serialize_handler to php_binary or php_serialize
2. The application switches it to php with ini_set() before calling session_start()
3. Session upload progress (session.upload_progress.enabled) is still enabled (the default)

The PHP project considers this combination unlikely and is handling it in the regular release cycle. KISA's interim guidance points out that the 21 October releases do not fix it and recommends session.upload_progress.enabled=0 until they do. If you already applied that setting as a PHP2Shell mitigation, keep it in place.

3. Laravel token-based API guard authentication bypass (CVE-2026-114509)

Laravel published GHSA-f9x3-7vq9-cph6 on 19 October. A TokenGuard configured as a standard token-based API guard does not reject a non-string credential, and under some MySQL or MariaDB configurations an unauthenticated attacker can end up logged in as an existing user. It is rated 9.2 under CVSS v4.0. The fixes are in 12.68.0 and 13.29.0, and KISA issued a Laravel update advisory on 23 October. The advisory lists no workaround; upgrading is the only remediation it gives.

This is separate from PHP2Shell, so check your Laravel version even after updating PHP.

4. WordPress Bricksforge plugin file upload (CVE-2026-85097)

Published on NVD on 8 October, this flaw lets an unauthenticated user upload arbitrary files in Bricksforge 3.1.8.9 and earlier. Wordfence (the CNA) rates it 9.8 under CVSS 3.1, and Patchstack rates it 10.0. In its 8 October write-up, Patchstack said its telemetry recorded the first exploitation attempts at 21:47 UTC on 7 October.

The Bricksforge changelog says the flaw was fixed in 3.1.8.10 on the 3.x line and in 4.0.0 on the 4.x line. Version 4.0.1 (8 October) followed with a Pro Forms file upload security fix and 4.0.2 (13 October) with REST endpoint hardening, and the 4.0.2 notes recommend renewing stored API keys as a precaution. For a fresh install, the latest 4.x release is the simplest choice.

How to tell whether you are affected

Everything below is read-only. Nothing changes settings or files.

PHP version: the CLI and the web server can differ

php -v

php -v only reports the command-line PHP. As KISA's guide notes, when a server has more than one PHP installed, the PHP-FPM service or Apache module actually serving requests can be a different version. Check along these lines:

• Check each PHP the web service actually uses: the FPM service, the Apache module, and PHP inside containers.
• Distribution packages sometimes backport fixes without changing the version number. Look for CVE-2026-109618 and CVE-2026-109619 in the package changelog.
• Check PHP bundled in Docker images and in appliances or packaged products. The Dutch NCSC keeps a per-product status list in NCSC-NL/php2shell.
• Work from the servers that are actually running, not the asset list. Agency-built sites, finished campaign pages, test servers and admin panels are the ones most often missed.
• On shared hosting, ask your provider.

The rule is simple: 8.2.35, 8.3.36, 8.4.27, 8.5.12 or later (or a distribution package with the fixes) means the two PHP2Shell flaws are fixed. On 8.1 or older you need a backport or a move to a supported version.

PHP settings: session upload progress

Look up session.upload_progress.enabled in php.ini, the PHP-FPM pool configuration and the web server configuration. The CLI and the web server often read different php.ini files, so use the files the web service loads. To judge CVE-2026-115560, search your application code for places that change session.serialize_handler with ini_set().

Composer dependencies such as Laravel

composer show laravel/framework
composer audit --locked

composer show prints installed package versions, and composer audit checks installed packages against policies such as security advisories. With --locked it audits composer.lock instead of the vendor directory. Laravel below 12.68.0, or a 13.x release below 13.29.0, needs an update.

WordPress plugins

wp plugin list

WP-CLI's wp plugin list shows each installed plugin's name, status, version and update availability. Without WP-CLI, the plugin screen in the admin dashboard shows the same information. Bricksforge at 3.1.8.9 or earlier needs an update right away. Inactive plugins still have files on the server, so include them.

What to do now

1. Update, then restart

Move PHP to 8.2.35, 8.3.36, 8.4.27, 8.5.12 or later, or apply your distribution's security packages, starting with internet-facing servers. The key line in KISA's guide is that without a restart the old version keeps running in memory. Restart every service running PHP, including PHP-FPM, Apache, php-cgi, FrankenPHP and LiteSpeed, and redeploy containers from new images. Then confirm that the PHP version the web service uses has actually changed.

Move Laravel to 12.68.0 or 13.29.0 or later, and Bricksforge to its latest release.

2. If you cannot update immediately

These are the interim measures from php.net and KISA. Both state clearly that interim measures do not fully protect you and only an update is a complete fix.

• Set session.upload_progress.enabled=0 and restart every worker. Put it somewhere that applies before request parsing, such as php.ini, the FPM pool or the server configuration, not ini_set() or .user.ini.
• Set memory_limit=-1 in a way applications cannot override, such as php_admin_value in the FPM pool.
• Lower post_max_size: 8M if you do not need uploads, 32M if you do, and keep upload_max_filesize below it.
• On PHP 8.5, add fatal_error_backtraces=0.
• Limit request sizes at the WAF, web server or proxy, and block multipart requests for services that do not accept uploads. If you use a WAF, make sure its latest rules are in place.

php.net warns not to substitute RLIMIT_AS or RLIMIT_DATA memory limits, since they can trigger the vulnerable allocation failure. If neither a patch nor interim measures are possible, KISA recommends considering blocking external access or pausing the service.

3. Review logs and files

KISA recommends reviewing everything since the vulnerability details leaked on 20 October, and earlier if possible. The main things to look for:

• Unusually large requests to PHP pages followed by HTTP 500 errors
• Unexplained PHP restarts, crashes (segfaults) and out-of-memory errors
• Signs of the web server account running a shell or a download tool
• New or modified PHP files (web shells) in web, upload and temporary directories
• External scripts injected into the homepage or payment pages
• Connections from the web server to unknown external addresses

If you ran Bricksforge, follow Patchstack's advice and look for unexpected PHP files in the uploads directory, especially wp-content/uploads/bricksforge/tmp/.

4. Rotate credentials

KISA's guide says these flaws can expose passwords, access tokens and API keys held in server memory. For servers that were internet-facing before the update, rotate database passwords, third-party API keys and admin passwords, and always rotate them on servers that show signs of compromise. The guide also notes that clean logs do not guarantee safety.

5. If you suspect a compromise, keep the order

KISA's order is isolate, report, preserve evidence, remediate. Do not shut down or restart the server; cut external access only. Report to KISA, preserve logs, running processes and network connections first, and then update, remove web shells and rotate credentials. Restarting first wipes the traces left in memory.

What not to do: run a PoC of unknown origin

KISA and the ministry both warn against downloading and running proof-of-concept code circulating online, since it often hides malware. Decide whether you are affected through version checks and log review, not a PoC.

Preventing the next scramble

When several big advisories land in one week, everyday structure decides how much it hurts.

• Keep a living version inventory. One table per site with PHP version, framework or CMS version, installed plugins and an owner lets you pick target servers as soon as the next advisory appears. Include agency-built sites and old campaign pages.
• Automate dependency checks. Run composer audit in CI, or turn on alerts that support Composer such as GitHub's Dependabot, so warnings reach you before you go looking for advisories.
• Schedule end-of-life upgrades early. PHP 8.2 security support ends on 31 December 2026, and KISA recommends moving to 8.3 or later. End-of-life versions do not get official fixes like this one.
• Reduce web server privileges. Keep the web server account from writing to code directories and block PHP execution in upload directories, so a file upload flaw has less room to do damage. Bricksforge 4.0.2 likewise made its temporary upload folder always block code execution.
• Treat WAFs and virtual patches as a bridge. Use them to buy time until you update, not instead of updating.
• Remove what you do not use. Inactive plugins, finished campaign sites and unused PHP features all add to what you have to check.

Using AI agents to help with the checks

If you run many repositories and servers, a coding agent can take on read-only checks. For example, it can collect composer.lock, Dockerfile base images and WordPress plugin lists from each repository, compare them with the fixed versions in the table above, and draft pull requests that bump versions where needed.

Keep the boundaries clear. Do not give the agent write access to production or secrets, have it cite the official advisory for every verdict, and keep it from searching for or running exploit code. People review and apply the updates and restarts.

References

• PHP: Security advisory (2026-10-21) · Session upload progress advisory (2026-10-23) · Supported versions · The PHP Foundation
• GitHub Security Advisories: GHSA-w8hw-w9fx-j79w · GHSA-6wmf-4rv5-p3rp · Laravel GHSA-f9x3-7vq9-cph6
• NVD: CVE-2026-109618 · CVE-2026-109619 · CVE-2026-114509 · CVE-2026-85097
• KISA (Korean): PHP update advisory · PHP2Shell response guide · CVE-2026-115560 interim guidance · Laravel update advisory
• Korean government (Korean): Cyber crisis alert raised
• WordPress: Bricksforge changelog · Patchstack analysis
• Tool docs: PHP CLI options · Composer CLI · WP-CLI plugin list · NCSC-NL/php2shell

Wrapping up

The Hypemarc Builder Community will keep sharing security news that builders can check and act on right away, grounded in official advisories. We'll continue gathering useful resources to share with fellow builders.

• Open chat: AI Builders
• Adoption advice and inquiries: Contact form
• Get the next post: Blog RSS · AI resource library