The Wikimedia Foundation did not switch Wikipedia off and go home. It switched off the parts where it could not promise the PHP version.
On 21 October the foundation said it was dealing with two critical PHP flaws that hit any site running PHP, not just Wikimedia. Readers might see wiki outages during the work. Supporting services were taken offline on purpose until they could be patched. The names that matter are Toolforge and Cloud VPS. Those host a lot of PHP apps. Volunteer developers run them. Some of those users pick their own PHP version. Staff cannot safely flip that back on by pushing one package.
A later community status page told the same story in a list. Cloud VPS and Toolforge, including *.wmcloud.org, *.wmflabs.org, and *.toolforge.org, were offline and might stay that way longer. Wikibase Cloud was down. Phabricator, translatewiki.net, GitLab, and doc.wikimedia.org were later marked restored. Zuul's status page stayed down for the same reason.
The outage is an ownership problem
This is the post in the series that is not about a vendor installing a patch overnight. Saylor could hand the window to a host. Logius could take DigiD down and bring it back. Wikimedia can patch what it operates. It cannot patch a Toolforge tool whose owner chose the runtime.
That is why the foundation's note says some of those services may be offline longer, and why staff were triaging, emailing documented owners, and upgrading only where they had access. A security bug in core PHP becomes an inventory bug the moment more than one team can pin a version.
If you run a platform where users bring their own PHP, you are in this post, not the Saylor post. Taking the platform offline is the honest move until every reachable worker is on 8.5.12, 8.4.27, 8.3.36, or 8.2.35, or on a vendor backport you have actually installed. "We patched the main wiki" is not a status for the side hostnames.
Sources: Wikimedia Diff, 21 October 2026; Wikitech community status; PHP advisory.
