High-Severity PHP Flaws: 3 Places Media Buyers Should Check

PHP Tracking

Hi, I’m Peter.

Yesterday, two high-severity PHP vulnerabilities were disclosed, both scored 9.2 (out of 10). They let an attacker run code on your server without logging in, and plenty of people simply took their sites offline.

Our tracker is also written in PHP. Once the patch came out, I sent Claude Code a message. Here is what media buyers should check first this time.

01 What happened

On October 21, the PHP team released an emergency security update:

Official PHP security announcement

The announcement says any PHP serving web pages to the public is at risk, and Apache with mod_php is the most dangerous setup. The details leaked before they were published, and several security companies have already seen attack attempts.

The fixed versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. If your traffic goes through the Cloudflare proxy, one layer is blocked by default, but Cloudflare itself says that is no substitute for upgrading.

02 Check these 3 places first

A paid click passes through several stops, and many people build three of them on their own servers with PHP. If someone takes one over, the money can leak from there.

1. Tracker. If the redirect is altered, the clicks you paid for go to someone else’s offer, and you think your offer has stopped working. If it also stores your campaign data and the API keys for your traffic sources and affiliate networks, those can be taken too.

2. Landing pages. If a page is hacked and malicious code is planted, the related Google ads get disapproved. After you clean it up and resubmit, the page recheck can take up to 72 hours. Landing pages built on WordPress need the PHP upgrade as well.

3. Postbacks. If a traffic source relies on postbacks to optimize automatically, fake conversions can make it misallocate your budget, and if real conversions can’t be sent back, it may misjudge which placements are good.

03 Fixed in 5 minutes

I sent Claude Code a message asking it to do a full check.

It found that only the tracker runs PHP. At first it assumed the server was already on the latest secure version, then corrected itself after reading the link. Then it upgraded, restarted and ran an intrusion check, and found nothing abnormal this round. During the check it also noticed that the newer OpenSSL, which handles the site’s encryption, had been installed for 25 days without being used. It only took effect after a full restart.

From the moment I asked to the finished report, it took 5 minutes, and I never touched the server.

04 My take

1. Upgrading and taking a site offline both have a cost. When I reloaded last night, the click endpoint threw errors for a few seconds and a few hundred requests failed. At peak traffic, a dozen-plus seconds could hit more paid clicks. If you take a site down, pause your running ads first, or the clicks you bought will land on a page that won’t open.

But next to a security hole, that loss is negligible. Some people took their sites offline to wait for the fix, which is the safest approach.

Anyone who self-hosts a tracker, landing pages or a website on PHP: go take a look, and make sure the upgrade actually went through.

Hope this helps!