As of 21 October 2026, 13:30 CEST.
At 11:08 this morning, bexio stopped responding — not because something broke, but because bexio took the service off the network on purpose. The reason is on the status page: a critical, worldwide security vulnerability in PHP, the language bexio runs on. Along with it, the assurance that customer data is safe, the prospect of the update later in the day, and a request not to contact support for the time being so the team can focus entirely on the fix.
The background is public. The PHP security team announced yesterday that an out-of-band security release would ship today at 14:00 UTC — 16:00 our time — fixing two critical vulnerabilities, both rated 9.2 out of 10. Which versions are affected, and what the vulnerabilities are called, will only be published with the release.
Put the two times side by side. bexio went offline at 11:08. The fix exists from 16:00. The service was dark for close to five hours before the patch even existed.
Three decisions we think are right
Shutting down instead of hoping. The comfortable option would have been to keep running until 16:00 and bet that nobody came knocking in the meantime. With a vulnerability of this severity, that is not a risk assessment. It is a dice roll with customer data.
Saying what is going on, and why. The notice contains the word PHP. It could just as easily have said «scheduled maintenance», and nobody would have known the difference. The fact that the actual cause is written there is the only reason we can write this piece at all.
Closing the support channel. Asking people not to call sounds unfriendly and is the opposite. Anyone who shuts down a service gets thousands of enquiries within minutes, and every one of them pulls people away from the fix. Saying that out loud costs a provider something — and it is more honest than a hotline that sounds busy and moves nothing.
What it costs us
Invoicing and bookkeeping stand still for as long as bexio stands still. That is the price, and today we can carry it — at the end of a quarter, or two days before payroll, we could not.
The observation that stays
The decision was right, and it was not ours to make. When you rent software, you rent its response time along with it. Today that is a good deal: a provider acting faster than we would have managed ourselves on a Wednesday morning. On another day the same mechanism is the problem — when the timing lands on payroll, when the communication never comes, when five hours turn into three days.
So what an organisation can do here is not «switch providers», but know the dependency before it comes due. Four questions are enough. Where does your data sit, and can you reach it without the portal? How long can operations run without invoicing? How would you hear about an outage — and have you subscribed to that channel, or will you go looking for it when it is already too late? And who makes the call in an emergency: you, or somebody else?
One more sentence about us, because it would otherwise go unsaid. We build sovereign infrastructure for NGOs, and PHP is part of it — Nextcloud is written in PHP. Sovereignty does not make a vulnerability like this any smaller. It only changes who holds the lever, and how long it takes until somebody pulls it. Today bexio pulled it, and pulled it early. That deserves credit.
