Crit­ic­al PHP vul­ner­ab­il­ity: how we handled it on 21 Oc­to­ber

On Wednesday, 21 October, for a few hours we had to run our clients’ websites while a serious, publicly known security flaw still had no installable fix. The sites stayed online throughout; only file uploads and online payments were paused. By the evening, those were back as well.

ügyelet

What was the problem?

The flaw was in PHP, the programming language that Drupal and WordPress run on, along with roughly two thirds of all websites. It was not in a plugin or a neglected site, but in the layer underneath them. That meant even carefully built sites could be at risk.

An attacker did not need to log in. With a specially crafted request, they could run code on the server and reach, for example, the database. The PHP developers rated both flaws (CVE-2026-109618, CVE-2026-109619) 9.2 on a 10-point severity scale.

The flaws were reported to the PHP developers in the summer. Several security research teams and AI-based tools were involved in uncovering them. The fix was prepared quietly, with disclosure planned for 22 October. Details leaked on 20 October, however, and a video demonstrating the attack appeared that evening. The PHP team brought the release forward: patched versions came out on 21 October at 14:00 UTC (16:00 Budapest time).

What we did

As soon as we learned about the flaw, we assessed which of our systems were affected. We used AI tools for this and for preparing the temporary restrictions. Our colleagues checked the results before anything went live. Within an hour, the temporary measures were in place on every server we operate.

Instead of a full shutdown, we used server-side restrictions to reduce the chance of an attack. This meant pausing file uploads and online payments for a few hours; everything else kept working. According to the PHP developers, temporary settings like these do not replace the fix, they only narrow the attack surface. So we also wanted the official update installed as soon as possible.

Meanwhile, we notified all of our clients. We drafted the notices with the help of AI while the technical work continued.

Once the fix was released, we installed it across the environments we operate and lifted the restrictions. By the evening, file uploads and payments were working again. The next morning, when the news reached the Hungarian press, we were already running the patched version.

If someone else hosts your site

Ask your provider which PHP version your site runs on and whether the fix has been installed. Official updates are available for PHP 8.2 and later. Versions 8.1 and older are no longer supported by the PHP project. Some Linux distributions provide separate security fixes for them, but in the longer run, moving to a supported version is the way forward.

How AI helped

AI-based tools played a part in finding these flaws, and the same technology can speed up attackers’ work too. Cloudflare was already seeing exploit attempts before the fix came out, a few hours after the leak.

For us, AI meant that the assessment, the preparation of the restrictions and client communication could run in parallel rather than one after another. The decisions were made by the team. This time, a few hours of limited functionality got us through the period when no fix existed. With a different flaw, a full shutdown might be the right call. What matters is being able to make that decision quickly and on solid grounds.

Sources: NBSZ NKI alert (in Hungarian), PHP Foundation, The Hacker News

Share with your friends!