CronEngine's website runs on PHP, the language behind a large part of the web, from WordPress to online shops. On 21 October the PHP team released a fix for two serious bugs. Here is how we kept CronEngine safe, and what you can do if your own site runs on PHP.
In short
- 1We closed the door the attack used, about two hours before the official fix came out.
- 2We installed the fix the same afternoon.
- 3Your cron jobs, heartbeats and uptime checks kept running the whole time.
What happened
Every time someone visits a PHP website, PHP first reads and unpacks the request before the website itself does anything. The two bugs sat in that first step. A specially crafted request, mostly one that pretends to upload a file, could make PHP run an attacker's own instructions on the server.
That is why it was serious: the website's own protection, like logins and permission checks, only starts after that first step. The PHP team announced the fix a day in advance and published it on 21 October at 14:00 UTC.
What we did
| 12:18 | Blocked fake uploads before they could reach PHP. Every other part of CronEngine kept working. |
| 14:00 | The PHP team publishes the fix and the details. We are already protected. |
| 14:50 | Changed two PHP settings, which closed the way in for the second bug too. |
| 16:13 | Installed Ubuntu's fixed version of PHP and switched everything back to normal. |
Times in UTC.
Afterwards we checked the server for any sign of a break-in: unknown files, unknown scheduled tasks, unknown programs. Everything was exactly as we left it.
Through all of it, your cron jobs, heartbeats and uptime checks ran on time. The part of CronEngine that runs them is written in a different language and does not use PHP at all. The only thing that paused for a few hours was uploading a logo for a status page.
What to do if you run PHP
- Update PHP and restart it. That is the real fix. The fixed versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35, or your hosting provider's patched version.
- Use managed hosting? Ask your host whether they have installed the update. Most do this for you.
- On Ubuntu, check where your updates come from. Some servers get updates from a copy of Ubuntu's server that can run hours behind. Getting them from Ubuntu directly saved us time.
- On PHP 8.1 or older? There is no official fix for those versions, so plan the upgrade.
For Ubuntu servers, this is the file that makes updates come straight from Ubuntu:
Types: deb URIs: http://security.ubuntu.com/ubuntu Suites: noble-security Components: main restricted universe multiverse Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg
The full technical details are in the PHP security advisory and on Ubuntu's page for this bug.
Questions
Were CronEngine customers affected?
Your cron jobs, heartbeats and uptime checks kept running the whole time. The part of CronEngine that runs them does not use PHP. We found no signs of a break-in.
My server says PHP 8.3.6 after updating. Is that wrong?
No. Ubuntu keeps the version number and adds the fix inside it. Check the package instead: on Ubuntu 24.04 it should be 8.3.6-0ubuntu0.24.04.13 or later.
Is turning off uploads enough?
Only as a stopgap. The update is the real fix, so install it as soon as you can and restart PHP.
Spotted a mistake, or something that behaves differently for you? Tell us and we will update the guide.