DEV Community

Cover image for PHP 8.2.12 Is Vulnerable: How I Patched PHP2Shell RCE by Upgrading to PHP 8.2.35
Technical Vandar
Technical Vandar

Posted on

PHP 8.2.12 Is Vulnerable: How I Patched PHP2Shell RCE by Upgrading to PHP 8.2.35

#php #php2shell #programming #cybersecurity

I Found My XAMPP PHP Was Vulnerable — Here's How I Patched It
On October 21, 2026, the PHP project released an urgent security update for two critical vulnerabilities that can potentially allow unauthenticated remote code execution (RCE) on vulnerable PHP installations.

The affected PHP branches included versions below:

  • PHP 8.5.12
  • PHP 8.4.27
  • PHP 8.3.36
  • PHP 8.2.35 The vulnerabilities are tracked as:
  • CVE-2026-109618
  • CVE-2026-109619 Both were rated CVSS 9.2 (Critical). PHP's own release announcement recommends that PHP 8.2 users upgrade to 8.2.35, and states that there is no complete mitigation other than updating. PHP News

So I decided to check the PHP installation on my Windows development machine.

And I found this:

PHP 8.2.12
Enter fullscreen mode Exit fullscreen mode

That version was vulnerable.

Here's exactly how I patched my XAMPP installation and verified that Apache was actually running the patched PHP version.
What Is the PHP Vulnerability?
These vulnerabilities are particularly serious because they affect the PHP runtime itself, rather than simply a vulnerable PHP application or framework.

According to CERT-EU, the vulnerabilities can result in unauthenticated remote code execution.

One vulnerability, CVE-2026-109618, involves memory corruption during PHP's out-of-memory handling.

The second, CVE-2026-109619, involves stale global state that can survive after request-related memory has been freed. CERT-EU

The important point for developers and server administrators is:
Updating your application code alone does not fix these vulnerabilities.

The PHP runtime itself needs to be patched.

The issue affects PHP installations serving web requests, including PHP-FPM, Apache mod_php, CGI, FrankenPHP and LiteSpeed. CERT-EU also notes that mod_php is considered the highest-risk setup. CERT-EU

Step 1 — Check Your PHP Version

The first thing I did was check the PHP version installed by XAMPP.

On Windows PowerShell:

C:\xampp\php\php.exe -v
Enter fullscreen mode Exit fullscreen mode

My old installation returned:

PHP 8.2.12 (cli) (built: Oct 24 2023 21:15:15) (ZTS Visual C++ 2019 x64)
Copyright (c) The PHP Group
Zend Engine v4.2.12
Enter fullscreen mode Exit fullscreen mode

This immediately showed that I was running an older PHP 8.2 release.

Since PHP 8.2 versions before 8.2.35 were affected, I needed to upgrade. CERT-EU

Step 2 — Back Up Everything

Before replacing PHP, I didn't want to risk my existing development environment.

I backed up my:

C:\xampp\htdocs
Enter fullscreen mode Exit fullscreen mode

This contained my PHP projects.

I also backed up the existing PHP installation:

C:\xampp\php
Enter fullscreen mode Exit fullscreen mode

and the relevant Apache/XAMPP configuration.

I also made sure my database data was backed up.

This is important because htdocs does not contain your MySQL databases.
My backup strategy

htdocs
├── Project files
└── PHP applications

php
├── Existing PHP runtime
└── Existing configuration

MySQL
└── Database backup
Enter fullscreen mode Exit fullscreen mode

Never treat upgrading PHP as simply "replace a folder and hope."

Step 3 — Choose the Correct PHP Version

Because my existing installation was PHP 8.2, I decided to move to:

PHP 8.2.35
Enter fullscreen mode Exit fullscreen mode

This was the patched release for the PHP 8.2 branch.

The PHP project released:
PHP Branch Patched Version
PHP 8.2 8.2.35
PHP 8.3 8.3.36
PHP 8.4 8.4.27
PHP 8.5 8.5.12

These versions contain the fixes for the two critical vulnerabilities. CERT-EU

For my existing application, I chose the latest patched 8.2.x release to minimize compatibility changes.

Step 4 — Download the Correct Windows Build

For XAMPP running Apache with PHP as a module, you need to pay attention to the Windows build.

My existing PHP environment was:

x64
ZTS
Visual C++ 2019
Enter fullscreen mode Exit fullscreen mode

So I downloaded the corresponding 64-bit Thread Safe (TS) PHP build.

The important part is not to randomly download a PHP ZIP and overwrite your installation.

For Apache module usage, make sure you're using the appropriate Thread Safe build.

The official Windows PHP downloads are available here:

PHP for Windows — Official Downloads

Step 5 — Keep the Old PHP Installation

Before replacing anything, I renamed:

C:\xampp\php
Enter fullscreen mode Exit fullscreen mode

to:

C:\xampp\php_old
Enter fullscreen mode Exit fullscreen mode

Instead of deleting it.

That gave me an easy rollback option if something went wrong.

Then I created:

C:\xampp\php
Enter fullscreen mode Exit fullscreen mode

and extracted the new PHP 8.2.35 build there.

Step 6 — Preserve My PHP Configuration

My existing application already had a working PHP configuration.

So I copied my existing:

php.ini
Enter fullscreen mode Exit fullscreen mode

from:

C:\xampp\php_old\php.ini
Enter fullscreen mode Exit fullscreen mode

to:

C:\xampp\php\php.ini
Enter fullscreen mode Exit fullscreen mode

However, this caused a small problem.

When I initially tested PHP, I got:

PHP Warning: Cannot open
"C:\xampp\php\extras\browscap.ini"

PHP Fatal error:
Unable to start standard module
Enter fullscreen mode Exit fullscreen mode

The problem was that my old php.ini referenced an extras\browscap.ini path that wasn't present in the new installation.

I searched php.ini for:

browscap
Enter fullscreen mode Exit fullscreen mode

and disabled the obsolete configuration:

;browscap = "C:\xampp\php\extras\browscap.ini"
Enter fullscreen mode Exit fullscreen mode

Then I tested PHP again.

Step 7 — Verify the New PHP Installation

I ran:

C:\xampp\php\php.exe -v
Enter fullscreen mode Exit fullscreen mode

And this time I got:

PHP 8.2.35 (cli) (built: Oct 20 2026 04:17:59)
(ZTS Visual C++ 2019 x64)

Copyright (c) The PHP Group
Zend Engine v4.2.35
Enter fullscreen mode Exit fullscreen mode

Success.

My PHP version had gone from:

8.2.12
Enter fullscreen mode Exit fullscreen mode

to:

8.2.35
Enter fullscreen mode Exit fullscreen mode

Step 8 — Start Apache

Next, I opened the XAMPP Control Panel and started Apache.

This step is important because checking:

php -v
Enter fullscreen mode Exit fullscreen mode

only proves that the CLI PHP binary is patched.

It doesn't necessarily prove that Apache is using the same PHP runtime.

So I needed to verify PHP through Apache itself.

Step 9 — Verify PHP Through Apache

I created a temporary file:

C:\xampp\htdocs\php-test.php
Enter fullscreen mode Exit fullscreen mode

with:

<?php
phpinfo();
Enter fullscreen mode Exit fullscreen mode

Then opened:
http://localhost/php-test.php

The page showed:

PHP Version 8.2.35
Enter fullscreen mode Exit fullscreen mode

More importantly, it showed:

Server API: Apache 2.0 Handler
Enter fullscreen mode Exit fullscreen mode

and:

Thread Safety: enabled
Enter fullscreen mode Exit fullscreen mode

The loaded configuration was:

C:\xampp\php\php.ini
Enter fullscreen mode Exit fullscreen mode

This confirmed that Apache itself was running PHP 8.2.35.

That distinction matters.

You don't want this situation:

CLI PHP       → 8.2.35
Apache PHP    → 8.2.12
Enter fullscreen mode Exit fullscreen mode

You want:

CLI PHP       → 8.2.35 ✅
Apache PHP    → 8.2.35 ✅
Enter fullscreen mode Exit fullscreen mode

Step 10 — Verify PHP Extensions

I also checked the PHP modules:

C:\xampp\php\php.exe -m
Enter fullscreen mode Exit fullscreen mode

The important modules were loading correctly, including:

curl
gd
mbstring
mysqli
mysqlnd
openssl
PDO
pdo_mysql
pdo_sqlite
session
xml
xmlreader
xmlwriter
Enter fullscreen mode Exit fullscreen mode

For a typical PHP/MySQL application, things like:
PDO

pdo_mysql
mysqli
Enter fullscreen mode Exit fullscreen mode

are particularly important.

No extension errors appeared.

Step 11 — Test the Actual Application

At this point, the PHP runtime was patched.

But I still needed to make sure my application didn't break.

I opened my existing PHP project and tested:

- Homepage
- Login
- Admin login
- Database connection
- Product CRUD
- Image upload
- File upload
- CKEditor
- Sessions
- Search
- Admin dashboard
- MySQL/PDO operations
Enter fullscreen mode Exit fullscreen mode

This is an important step after changing a PHP runtime.

A successful:

php -v
Enter fullscreen mode Exit fullscreen mode

doesn't mean your application is automatically healthy.

Step 12 — Delete the Temporary phpinfo() File

Once verification was complete, I deleted:

C:\xampp\htdocs\php-test.php
Enter fullscreen mode Exit fullscreen mode

You shouldn't leave a publicly accessible phpinfo() page on a production server because it exposes detailed information about the PHP environment.
**

Final Verification

**
My final environment looked like this:

Before
────────────────────────────
PHP:          8.2.12
Apache:       XAMPP
Status:       Vulnerable
Enter fullscreen mode Exit fullscreen mode

After:

After
────────────────────────────
PHP:          8.2.35
Architecture: x64
Thread Safe:  Yes
Server API:   Apache 2.0 Handler
php.ini:      C:\xampp\php\php.ini
Status:       Patched
Enter fullscreen mode Exit fullscreen mode

I also verified:

CLI PHP       → 8.2.35 ✅
Apache PHP    → 8.2.35 ✅
PHP modules   → Loading ✅
PDO/MySQL     → Loading ✅
Application   → Tested ✅
Enter fullscreen mode Exit fullscreen mode

What You Should NOT Do

Don't try to "patch" these vulnerabilities by simply changing your application code.

For example, adding:

if (...) {
    // security check
}
Enter fullscreen mode Exit fullscreen mode

to your application doesn't patch a vulnerability in the PHP runtime.

These vulnerabilities exist in PHP's internal request handling.

The PHP project explicitly recommends upgrading, and CERT-EU says that only an update fully fixes the vulnerabilities. PHP News

What If You Can't Upgrade Immediately?

If you absolutely cannot patch immediately, CERT-EU lists temporary mitigations for specific attack paths.

However, these are not replacements for upgrading.

For example, CERT-EU discusses controls around memory limits, upload sizes and session upload progress depending on the vulnerability. But the advisory explicitly states that only updating PHP fully fixes the vulnerabilities. CERT-EU

So the preferred order is:

1. Upgrade PHP
        ↓
2. Restart PHP/Apache
        ↓
3. Verify runtime
        ↓
4. Test application
        ↓
5. Review logs if previously exposed
Enter fullscreen mode Exit fullscreen mode

What If My Server Was Already Public?
This is where things get more serious.

If a vulnerable PHP installation was publicly reachable before patching, don't assume that updating PHP means there was never an intrusion.

The vulnerabilities were publicly discussed and proof-of-concept material began circulating after disclosure. CERT-EU recommended immediate patching and, where patching isn't feasible, isolating internet-facing applications. CERT-EU

If the server was exposed while vulnerable, consider reviewing:

  • Web server access logs
  • PHP/application logs
  • Authentication logs
  • Recently modified files
  • Unexpected PHP files
  • New administrator accounts
  • Suspicious scheduled tasks
  • Unexpected outbound connections
  • API keys/secrets that may have been accessible to the application If compromise is suspected, don't simply reinstall PHP and call it done. Investigate the system and rotate potentially exposed credentials.

One More Important Thing: PHP 8.2

Although 8.2.35 is the correct patched release for the 8.2 branch, PHP 8.2 is approaching the end of its normal security-support lifecycle.

So I consider this upgrade a necessary security patch, not a reason to stay on PHP 8.2 forever.

My next step will be testing the application against a newer supported PHP branch before eventually migrating.

Final Takeaway

If you run PHP, check your version today.

Run:

php -v
Enter fullscreen mode Exit fullscreen mode

If you're on an affected branch, upgrade to at least:

PHP 8.2.35
PHP 8.3.36
PHP 8.4.27
PHP 8.5.12
Enter fullscreen mode Exit fullscreen mode

depending on your branch. CERT-EU

For my XAMPP environment, the fix was:

PHP 8.2.12
      ↓
Backup
      ↓
Install PHP 8.2.35
      ↓
Preserve configuration
      ↓
Fix obsolete browscap configuration
      ↓
Restart Apache
      ↓
Verify php -v
      ↓
Verify phpinfo() through Apache
      ↓
Verify PHP extensions
      ↓
Test application
      ↓
Delete phpinfo()
      ↓
PATCHED ✅
Enter fullscreen mode Exit fullscreen mode

The most important lesson is simple:

Don't just check the PHP version in your terminal. Verify the PHP runtime actually serving your web application.

Official References

Two critical PHP vulnerabilities can allow unauthenticated remote code execution on vulnerable PHP installations. Here's how I discovered my XAMPP environment was running PHP 8.2.12, upgraded it to PHP 8.2.35, fixed a configuration issue, verified Apache, checked extensions, and tested the application.

Top comments (0)