Critical PHP patch expected today after flaw rated 9.2 in severity
The language's developers published an advisory on Tuesday (20th) about two critical remote code execution vulnerabilities affecting every PHP version since 5. The patch is expected today, and security agencies are already recommending that servers that can't be fixed in time be shut down.

PHP developers published a security advisory on Tuesday (20th) about two critical vulnerabilities rated 9.2 on a scale of 10. The official patch is expected today, around 10am Eastern Time in the United States (approximately 11am Brasília time), according to a report from The Verge. The PHP team has already warned that it may bring the release forward if details of the flaw leak early or if there is evidence of active exploitation.
The official recommendation is direct: "upgrade as soon as the release is available," meaning update as soon as the fixed version is released. There is no documented alternative mitigation beyond the patch itself.
Why the flaw is so severe
According to cybersecurity firm watchTowr, cited by The Verge, the two vulnerabilities are of the Remote Code Execution (RCE) type and affect every PHP version from 5 onward. This includes legacy installations that many people have forgotten are still running in production, especially on shared hosting and older control panels.
RCE means an attacker can run their own code on the vulnerable server. In practice, this opens the door to altering a site's content, stealing database data, installing backdoors, or using the compromised server as a staging point for other attacks.
A security researcher estimated that more than 1.3 million internet-connected hosts are potentially exposed, according to The Verge's report. The number does not come from a survey by the PHP team itself, but it gives a sense of the scale of the problem even before the technical details of the flaw were publicly disclosed.
WordPress and shared hosting in the crosshairs
Wordfence, a company that maintains one of the most widely used WordPress security plugins, stated that every WordPress site will be vulnerable, simply because every WordPress site runs on a server with PHP. This matters because, according to WordPress's own data cited by The Verge, the platform powers more than 40% of the internet.
In Brazil, this matters even more on one specific point: a large share of the country's WordPress sites are on shared hosting, where whoever administers the server is not the same person who publishes the content. Wordfence warned that the patch cannot be installed via automatic PHP updates, so it falls to whoever manages the infrastructure (not the site owner) to apply the fix manually as soon as it is released.
In short: if you maintain a PHP site or application and don't know who is responsible for the infrastructure layer (hosting, VPS, dedicated server), today is the day to find out, before someone else finds out for you.
What is already being done
The European Union's CERT and the United Kingdom's National Cyber Security Centre published advisories recommending that companies unable to apply the patch immediately isolate their internet-exposed applications or take them offline entirely until full mitigation is achieved.
GrapheneOS, the mobile operating system developer, took its user discussion forum offline as a precaution, because proof-of-concept exploits are already being developed.
We don't want to take the risk.
GrapheneOS, in a statement cited by The Verge
PHP developer Gina Peter Banyard confirmed that applying the patch is the only real mitigation available, and that shutting down servers may be the most sensible alternative for those unable to update in time.
Might be the most sensible thing to do.
Gina Peter Banyard, PHP developer
Threat researchers at Sansec have already braced for the worst-case scenario.
We expect to see mass attacks within 15 minutes of the release.
Threat researchers at Sansec
And, according to Cloudflare CTO Dane Knecht, attacks didn't even wait for the patch to come out.
We are seeing early attacks emerging.
Dane Knecht, CTO of Cloudflare
Cloudflare said it is temporarily updating the platform's firewall rules as a stopgap measure until the official fix is available for its customers.
What to do now, in practice
Before anything else, find out which PHP version is running in your production environment. On a typical Linux server, that's:
php -vIn managed environments (cPanel, Plesk, Brazilian shared hosting), the usual path is the control panel, not the terminal. Some points to check today:
- Who is responsible for updating PHP in your stack: you, the infrastructure team, or the hosting provider?
- Whether your provider already has an advisory or ETA for the patch (many Brazilian shared hosting providers take time to roll out critical patches).
- Whether it's possible to put the application behind a WAF (Web Application Firewall) as an extra layer while the patch isn't out yet.
- Whether it's worth isolating public access, for non-essential services, until the fix is applied, as recommended by CERT-EU and the UK's NCSC.
For WordPress users, Wordfence's warning is direct: the security plugin doesn't fix this on its own, because the flaw lies in the PHP layer, below WordPress. The update needs to happen on the server, not in the site's dashboard.
What remains unclear
At the time the original article was published, The Verge did not include the CVE numbers for the two vulnerabilities, nor technical details about the exact exploitation vector, likely withheld on purpose by the PHP team until the patch is released. There is also, in the available sources, no confirmation that the patch has actually been released at the expected 10am ET, nor an official list of Linux distributions or cloud providers that have already packaged the fix. It's worth following the official announcement on the PHP website once it's out, and treating any internet-facing PHP server as exposed until the update is applied.
Translated from the Brazilian Portuguese original · Read the original
How to run distributed Spring Batch without a message broker, using only a database
An article published on InfoQ describes a pattern for distributing Spring Batch jobs across multiple nodes using only the relational database the framework already requires, swapping the message queue for heartbeats and conditional updates in SQL. The idea doesn't replace classic remote partitioning, but it avoids spinning up a Kafka or RabbitMQ just for that.





