Yesterday, two critical security vulnerabilities in PHP dubbed “php2shell” were publicly disclosed: CVE-2026-109618 and CVE-2026-109619. Both could allow attackers to execute code on vulnerable servers without authentication. With no reliable mitigation available other than updating PHP, we made the decision to temporarily take all our and our customers’ hosted services offline as a precaution.
Now, a day later, it’s time to reflect and see what we learned.
CosmoCode Services are back up
All the PHP services, including the wikis we host, are back up and running the new PHP versions released yesterday.
The official PHP security advisory with details was released at 14:00 UTC. With it, new PHP versions were made available.
Updated PHP packages for Debian (our preferred Linux distribution) followed shortly after, and we began updating and restarting the first services.
The official Docker packages took a couple of hours to arrive at Docker Hub. About 20 minutes later, new DokuWiki Docker images were released.
Around 19:30 UTC (21:30 German time), all our systems were back to normal.
I want to thank my colleagues Karsten and Tilo, who worked with me until such a late hour. I also want to thank the many, mostly unpaid volunteers, in the involved Open-Source communities making this quick turnaround possible!
Was it necessary?
As always, when a catastrophe has been prevented, the question arises whether there would actually have been one in the first place.
When the first information about the vulnerability came out, no concrete details were known. It was not clear whether any mitigation was available, and the only information we had was a Mastodon post by PHP core developer Gina Peter Banyard:
The only thing I can say is that the only mitigation is patching / upgrading PHP. I sadly know too much.
At the same time, Cloudflare reported that they had seen and blocked patterns that looked like attempts to exploit the vulnerability (or what little was known about it) at the time. It seemed that at least parts of the vulnerability were already known and were being actively exploited.
This is why we decided on the drastic measure of taking the services offline. We were not alone in that assessment, and many other small and large organizations followed suit during the day.
With the full details now known, it seems that actually exploiting the vulnerability is a bit more difficult than initially assumed. So the big wave of automated break-ins that was feared most has not materialized yet. Nonetheless, we are already seeing probing attempts for the CVEs in our CrowdSec web application firewall logs.
Will it happen again?
The PHP Foundation’s write-up on the issue is a good read. Basically, the threat was vaguely known for a long time, but it was difficult to assess whether and how it could be exploited at all, especially with the limited resources available to an open-source project.
AI is changing the landscape here. All Internet-facing software is under constant scrutiny now. AI labs are spending trillions of tokens to proudly proclaim that they were the ones who found a serious vulnerability and thus made the net “safer”. Which is both true and false at the same time.
AI is also giving attackers a new tool to exploit known vulnerabilities, beyond their own skills. Trying to keep issues under wraps and coordinate disclosure, as we saw yesterday, is becoming harder and harder. Even yesterday’s release was already a deviation from the original release plan, because knowledge of the issue had leaked during the embargo. And often the rumor of a vulnerability is now enough to have LLMs reproduce it independently and generate working exploits.
So more serious vulnerabilities will be found, and the notice periods may become even shorter. Drastic measures like the ones we saw yesterday might very well become more common.
What is CosmoCode doing?
With this new reality, we need to be prepared for next time. Luckily, we have been improving our infrastructure management over the last couple of years, moving most of our services to a Kubernetes cluster managed by us. This new infrastructure proved invaluable for the fast reactions and updates we were able to deliver yesterday.
But we also learned a few lessons:
Not all our updates in the cluster were as frictionless as we would have liked, and we might need to improve the way we can quickly identify all services running a specific technology. This could be a programming language, as was the case yesterday, or a specific library or framework in the future. There are also some legacy systems left that should be migrated.
We also need to improve our processes for quickly notifying affected customers. For our wiki customers, it was easiest for me to quickly send a newsletter.With the added benefit that this also informed those whose wikis we’re not hosting. But others had to be contacted individually.
If you need help preparing for the next security incident or have other technical challenges, feel free to get in touch with us. We’re happy to discuss how we can help.