Critical PHP Vulnerabilities: Fix Guide | WebifyGO

Most PHP websites don't get hacked through some brilliant, never-seen-before attack. They get hacked through a known vulnerability whose fix has been available for months, sometimes years. Nobody installed it.

Two of those vulnerabilities stand out. Both let an attacker run their own code on your server, which is the worst kind of security hole. Both have public exploits. And automated scanners still look for both. Here's what each one is, how to tell if your site is exposed, and exactly how to fix it.

Vulnerability 1: CVE-2024-4577, the PHP-CGI argument injection

What it is

Security researcher Orange Tsai of DEVCORE disclosed this one in June 2024. It comes from a Windows feature called "Best-Fit" character mapping. When Windows converts certain characters, it quietly swaps them for similar-looking ones. The soft hyphen (0xAD) gets turned into a normal dash (-).

That matters because php-cgi reads anything that starts with a dash as a command-line option. An attacker can put a soft hyphen in a URL and pass options straight to PHP. For example, they can tell PHP to run code that arrives in the body of the request. PHP had added protection against this exact trick back in 2012 (CVE-2012-1823). The Windows character conversion slips past that protection.

Are you exposed?

You are at risk if all of these are true:

• PHP runs on a Windows server
• PHP runs in CGI mode, or the php-cgi executable can be reached from the web
• Your PHP version is older than 8.3.8, 8.2.20 or 8.1.29

XAMPP for Windows exposes PHP-CGI in its default setup, so any XAMPP install facing the internet should be treated as vulnerable until it's checked. The researchers confirmed the attack on Chinese and Japanese system locales and advised users on every other locale to update too.

If your PHP runs on Linux, or through PHP-FPM, this one doesn't apply to you. Vulnerability 2 probably does, though.

Why it's serious

Within days of the disclosure, attackers were using this flaw to install ransomware. The US cybersecurity agency CISA added it to its catalogue of vulnerabilities known to be exploited in real attacks. This was not a theoretical risk.

How to fix it

1. Upgrade PHP. Version 8.3.8, 8.2.20, 8.1.29 or anything later contains the fix. PHP 8.0, 7.x and 5.x are past end of life and will never get a fix. If you're on one of those, an upgrade is the only real answer. Also, 8.1 no longer receives security updates, and 8.2's support ends on 31 December 2026, so we recommend going straight to PHP 8.4 or newer.
2. Stop using CGI mode. Run PHP through PHP-FPM instead. It's safer and faster.
3. XAMPP users: XAMPP is built for local development, not live websites. If you can't move off it right away, open C:/xampp/apache/conf/extra/httpd-xampp.conf and comment out this line:

# ScriptAlias /php-cgi/ "C:/xampp/php/"

Temporary measure: if you can't upgrade today, this Apache rewrite rule blocks the known attack pattern. It's a short-term fix, not a replacement for upgrading:

RewriteEngine On
RewriteCond %{QUERY_STRING} ^%ad [NC]
RewriteRule .? - [F,L]

Vulnerability 2: CVE-2024-2961, the glibc iconv bug ("CNEXT")

What it is

This bug isn't in PHP itself. It's in glibc, the core system library on most Linux servers. When glibc's iconv() function converts text into a rarely used Chinese character set (ISO-2022-CN-EXT), it can write a few bytes past the end of its memory buffer.

A few bytes sounds harmless. But researcher Charles Fol of Ambionics showed that PHP's php://filter feature can trigger this conversion. That turns a "small" problem in your PHP code into remote code execution. The small problem is a file-reading bug, where user input decides which file a function like file_get_contents() opens. Many developers treat file-read bugs as low priority. This vulnerability is why they shouldn't.

Are you exposed?

• Your server runs Linux with glibc 2.39 or older and hasn't received the patched package from your distribution
• Your PHP application, plugin or library lets user input reach a file function anywhere in the code

Check your glibc version with:

ldd --version

Keep in mind that most distributions patch older version numbers rather than releasing a new one. What matters is whether your system packages are up to date, not just the number.

How to fix it

1. Update glibc through your package manager, then restart PHP-FPM and your web server:

# Debian / Ubuntu
sudo apt update && sudo apt install --only-upgrade libc6

# RHEL / AlmaLinux / Rocky
sudo dnf update glibc

2. Can't update yet? Turn off the vulnerable character set. Find the gconv modules config file. On Debian and Ubuntu it's usually /usr/lib/x86_64-linux-gnu/gconv/gconv-modules.d/gconv-modules-extra.conf. Comment out the lines that mention ISO-2022-CN-EXT, then rebuild the cache:

sudo iconvconfig
iconv -l | grep -E 'CN-?EXT'   # should return nothing

3. Fix the file-read bug itself. Never pass user input straight to file_get_contents(), include, fopen() or similar functions. Check paths against an allow-list and reject anything that contains php:// or another stream wrapper.

How to tell if you've already been hit

Patching closes the door. It doesn't tell you whether someone already got in. Check for these signs:

• Web server logs: requests with %AD at the start of the query string (CVE-2024-4577), or parameters containing php://filter, convert.iconv or ISO-2022-CN-EXT (CVE-2024-2961)
• Unknown files in your web root, especially recently changed .php files in upload or cache folders
• New admin accounts in your CMS, CRM or database that nobody on your team created
• New scheduled tasks (cron jobs on Linux, Task Scheduler on Windows)
• Unexpected outbound connections or CPU spikes, which are common signs of crypto-miners and backdoors

If you find signs of a breach

1. Isolate the server. Take it offline or restrict access, but don't wipe it yet.
2. Preserve the evidence: logs, suspicious files, database dumps.
3. Rotate every secret the server could reach: database passwords, API keys, .env values, SMTP credentials, payment gateway keys.
4. Rebuild from a known-clean backup and patch it before it goes back online. Restoring an unpatched backup just restores the same hole.
5. Check your legal obligations. If personal data of people in the EU may have been accessed, GDPR generally requires you to notify your supervisory authority within 72 hours of becoming aware of the breach.

How to keep this from happening again

Neither of these vulnerabilities needed a sophisticated attacker. They needed a server nobody was watching. A few habits prevent most of this:

• Stay on a supported PHP version. Check php.net's supported versions page and plan upgrades before support ends, not after.
• Patch the operating system, not just the application. CNEXT shows that PHP is only as safe as the system it runs on.
• Keep an inventory. Know every server, PHP version and plugin you run, including the old staging site everyone forgot about.
• Use PHP-FPM. It's more secure than CGI, and it was the best-performing setup in our PHP performance benchmarks.
• Test updates on staging first so that fear of breaking something never becomes the reason you skip a patch.

How we handle this for our clients

When a business brings a PHP website or web app to WebifyGO, security comes before new features. Our team checks the PHP version and server stack, applies the patches, moves risky setups like CGI or XAMPP onto a proper PHP-FPM environment, and fixes the code-level problems that turn small bugs into breaches.

The result is a site you don't have to worry about every time a new vulnerability makes the news. If you're not sure whether your server is affected by either of these, that's exactly the kind of question WebifyGO can answer quickly.