PHP Upgrade on Windows Server: IIS and Apache Impact, Fixes and Best Practices

Home › Blog › PHP Upgrade on Windows Server: IIS and Apache Impact, Fixes and Best Practices

By the DESSS Team | Updated November 2026

Running PHP on Windows Server is more common than people think. Plenty of businesses host PHP apps on IIS next to their .NET applications, or run Apache on Windows because that's what the team knows. It works well, until it's time to upgrade.

With the PHP2Shell vulnerabilities (CVE-2026-109618 and CVE-2026-109619) patched on October 21, 2026, and PHP 8.2 reaching end of life on December 31, 2026, many Windows servers need attention right now. Here's what's different about Windows, the problems we see most often, and how to get through an upgrade without a weekend of 500 errors. For the bigger picture, read our news summary PHP Upgrade 2026: What Just Happened.

Why Windows needs its own playbook

On Linux, you run a package update and the system handles most of the details. On Windows, there's no package manager for PHP, and Windows Update doesn't touch it. Upgrading means you:

• Download a new PHP build by hand
• Choose the right build type for your web server
• Make sure the matching Visual C++ runtime is installed
• Point IIS or Apache at the new folder
• Restart the processes that are still running the old version

Every one of those steps is a chance for something to go wrong. And Windows has a history here: in 2024, CVE-2024-4577 hit PHP running in CGI mode specifically on Windows. PHP-CGI on Windows deserves extra care.

Is your Windows server affected?

If your server runs any PHP version from 5.4 through 8.5.11, yes. Official Windows builds with the PHP2Shell fixes are available on windows.php.net for 8.2.35, 8.3.36, 8.4.27 and 8.5.12. There are no official Windows builds with the fix for PHP 8.1 or older.

Don't forget the less obvious places PHP hides on Windows:

• XAMPP, WampServer and Laragon bundles on developer or internal machines
• Plesk for Windows, which ships its own PHP versions (Plesk has also flagged a separate Brotli issue on Windows, CVE-2026-111497)
• Vendor applications that bundle their own php.exe

The problems we see most often

1. The wrong build type

PHP for Windows comes in two flavors, and picking the wrong one is the number one cause of failed upgrades.

2. Missing Visual C++ runtime

PHP for Windows needs the Microsoft Visual C++ Redistributable for Visual Studio 2015–2022. PHP 8.4 and 8.5 are built with VS17, while 8.2 and 8.3 use VS16. If the runtime is missing or damaged, PHP won't start, and IIS just shows a generic FastCGI error. Install the x64 runtime for x64 PHP builds.

3. Old processes keep running

IIS keeps php-cgi.exe processes alive between requests. After you swap PHP folders, those processes can keep serving the old, vulnerable version until the application pool is recycled. We've seen servers "patched" for days that were still running old code.

4. Hard-coded paths

IIS FastCGI settings and handler mappings name the full path to php-cgi.exe. Apache uses LoadModule and PHPIniDir. Install PHP into a new folder and forget to update those, and nothing changes.

5. Extension DLLs that don't match

Every extension DLL must match the PHP version, build type (NTS or TS) and compiler. Common examples are php_sqlsrv, php_pdo_sqlsrv, php_redis and php_xdebug. One mismatched DLL can stop PHP from loading. Also, PHP 8.5 no longer ships php_opcache.dll, so remove any zend_extension=php_opcache.dll line from php.ini.

6. Older Windows Server versions

PHP 8.3 and newer require Windows 8 or Windows Server 2012 at minimum, and PHP doesn't run on ARM-based Windows. In practice, the bar is higher: Microsoft's SQL Server drivers for PHP (version 5.13) have dropped Windows Server 2012 and 2012 R2. If you're on 2012, plan an OS upgrade alongside PHP.

Best practices for PHP on Windows

• Use FastCGI with NTS on IIS, not CGI mode.
• Set instanceMaxRequests in IIS FastCGI so PHP processes recycle regularly.
• Keep PHP folders versioned (C:\PHP\8.3, C:\PHP\8.4).
• Lock down permissions so the IIS app pool identity can read the PHP folder but not write to it.
• Monitor for odd child processes. PHP2Shell attacks often show up as php-cgi.exe launching cmd.exe or powershell.exe.
• Track PHP separately from Windows Update. Subscribe to PHP security announcements, because Windows won't tell you.

How DESSS helps with Windows PHP upgrades

Our team works across the Microsoft stack and the open source world, which makes PHP on Windows a natural fit for us. We can:

• Patch your IIS or Apache servers against PHP2Shell and confirm the fix is live
• Upgrade PHP versions, extension DLLs and Visual C++ runtimes together
• Fix SQL Server connectivity issues after an upgrade (see our database article)
• Plan Windows Server upgrades or a move to Microsoft Azure when the OS is the blocker
• Keep everything current through our Infrastructure & Managed Services and Upgrades & Migrations teams

Request a customized quote

Tell us your Windows Server version, web server (IIS or Apache), current PHP version and the applications you run. We'll send a tailored upgrade plan and quote.

Request your customized Windows PHP upgrade quote

Disclaimer

The information in this article is provided for general informational and educational purposes only. It reflects publicly available information as of November 4, 2026. PHP versions, support dates, security advisories and third-party software change often, so always confirm details with official sources such as php.net and your software vendors before making changes.

This article is not professional, legal or security advice, and following these steps does not guarantee protection against every vulnerability or compatibility issue. Always back up your systems and test upgrades in a staging environment before applying them to production. DESSS, Inc. is not liable for any loss, damage or downtime resulting from the use of this information.

Product names and trademarks mentioned (including PHP, Microsoft, Windows, IIS, SQL Server, Oracle, MySQL, MariaDB, PostgreSQL, Ubuntu, Debian, Red Hat, cPanel and Plesk) belong to their respective owners and are used for identification only. Links to third-party sources do not imply endorsement. Please also see the DESSS Disclaimer and Privacy Policy.