On October 21, 2026, we took the Springcast applications offline as a temporary precaution. A day earlier, the PHP security team had announced two critical vulnerabilities in the software our applications run on. An update to fix them was not yet available.
That decision affected you and your listeners. We were back online the same day. Here is what happened, why we made that choice, and what you noticed.
What is PHP?
PHP is a programming language that many web applications are built with, including Springcast’s. It runs on our servers, behind the applications you and your listeners use. You don’t install PHP yourself, and you don’t maintain it either. The diagram shows where PHP sits, and with that, where the vulnerabilities were.
What became known on October 20 and 21?
The PHP security team announced a security update on October 20 for two critical vulnerabilities. Both received a severity score (CVSS) of 9.2 on a scale of 0 to 10. PHP only published which versions were affected, and which versions fix the vulnerabilities, with the release on October 21.
With that release, PHP confirmed what “critical” means here: both vulnerabilities can allow remote code execution. Someone could then make a server run their own commands remotely, without logging in. According to CERT-EU, the cybersecurity service for the EU institutions, every PHP installation that handles web requests is at that risk (advisory 2026-018).
A vulnerability that affects software worldwide is not proof of a worldwide attack, nor that anything was exploited at Springcast. The risk did rise quickly, though.
After the release, technical details were discussed publicly and the first proofs of concept began to circulate: sample code showing that an attack works. According to CERT-EU, that made it more likely that attackers were already exploiting the vulnerabilities.
For us, the announcement was already a reason not to keep our applications reachable over the internet while the update was not yet available.
Why we didn’t wait for the update
On October 21, we first took smaller precautions. We temporarily turned off uploading audio and images; uploads through the file manager kept working. We also added extra monitoring and alerts to our servers. Then we took a further step.
There was time between the announcement and the update. As long as our applications stayed reachable online during that period, they ran on software with known vulnerabilities that had not yet been fixed.
In the first version of its advisory, before the release, CERT-EU advised organizations to prepare for the update. If immediate patching was not possible, it recommended considering isolating internet-facing applications until a fix was available. That is what we did: we took the applications offline until the vulnerabilities would be fixed. The diagram below shows what that does and does not do.
Going offline limited the risk, but it did not fix the vulnerabilities. That only happened once PHP had released the update and we had installed it. Those are two separate moments: PHP releasing an update does not mean Springcast has already been updated.
The choice came at a cost, and you and your listeners bore it: for a while, Springcast did not work. We preferred that inconvenience over applications that stayed reachable with known, serious vulnerabilities for which no fix existed yet.
What you and your listeners noticed
Besides the applications themselves, the Springcast Pro status page also listed these components as offline:
RSS feeds, which podcast apps use to fetch new episodes;
the player, including where you have embedded it on another website;
podcast websites;
statistics.
So the interruption affected more than you as a creator. Podcast apps temporarily could not fetch your feed, and your embedded player and podcast website were unreachable.
On October 21, we informed customers by email about the interruption, and again later that day when we were back online. On our website, a notice at the top of the page pointed to the Springcast Pro and Springcast Classic status pages, where we posted updates.
What we know about your data
We had not observed any suspicious activity when we decided to go offline, nor when we came back online. The interruption itself did not cause any data loss: being temporarily unable to access your account does not mean anything was deleted.
How it ended
That same day, October 21, we installed PHP’s security update on all our servers and brought the applications back online. Uploading audio and images worked as usual again, and in Springcast Pro, RSS feeds, the player and podcast websites were reachable again.
We reported this that same afternoon on the Springcast Pro and Springcast Classic status pages. We added that we would monitor our systems especially closely in the days that followed.
Questions?
If you have a question about your own account, contact our support. You can find the status of your environment on the Springcast Pro or Springcast Classic status page.