Summary

  • RIPE NCC’s precautionary shutdown covered four URLs across its Academy, the Number Resource Organization and the ICANN Address Supporting Organization.
  • The PHP project announced fixed releases on 21 October; RIPE’s incident log recorded the sites returning by 23 October as patches and service dependencies cleared.

A security patch can ship in an afternoon. Getting four public websites back online runs on a different clock.

At 17:37 CEST on 21 October, RIPE NCC’s status page reported that four websites had gone offline. The incident record names academy.ripe.net, elearning-2.ripe.net, www.nro.net and aso.icann.org/aso-ac/. RIPE NCC’s own notice describes the move as a precaution after discovery of two critical PHP vulnerabilities. It reported no indication that the flaws had been exploited within its systems.

The dates matter. The PHP project’s security advisory was scheduled for 21 October at 14:00 UTC. It identifies CVE-2026-109618, an out-of-memory corruption flaw, and CVE-2026-109619, a stale-state flaw. The project released PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 with fixes. These were remote-code-execution vulnerabilities affecting PHP web installations.

RIPE’s public incident record gives the restoration work its own clock. On 22 October, the team said upstream patches were available and it was updating services as dependencies became available. By 09:22 CEST on 23 October, the Academy and e-learning sites were back. At 14:32, RIPE marked all services online.

That is the unglamorous middle of incident response: the upstream fix exists, but the public service still waits for its own update path. “Patch released” is a software event. “Site restored” is an operating decision made after the code, dependencies and service are ready together.

The four URLs also show what the immediate action covered. The Academy is a training service; the other two front doors serve the NRO and ASO. RIPE’s status system classifies the incident under “Non-Critical Services (RIPE NCC Academy).” A service label helps with prioritisation, but the public record does not explain how these sites are hosted, which dependencies held up restoration, or whether another public route could carry their information during the shutdown.

Those missing details are the useful follow-up. The incident notice establishes a clear decision: access was removed while the team worked through updates. The public timeline records recovery. The deployment path between those two points remains behind the curtain.