On April 1, 2014 at 21:00 UTC — which is 00:00 Moscow time on April 2 — every GLONASS satellite simultaneously began transmitting “infected” Broadcast Ephemerides (the orbital-element data receivers use to convert satellite signals into a fix). Errors in the broadcast positions reached ±200 km along-track and produced systematic rotations of the orbital planes consistent with a software bug rather than a physical anomaly.

The disruption was caused by a software update on the GLONASS ground segment activated at midnight Moscow time. The provider identified the failure almost immediately after activation, but the correction — switching back to the previous software release — had to be applied satellite-by-satellite, starting at 22:45 UTC on April 1 and finishing around 07:00 UTC on April 2 (satellite 21 was the last to recover). Crucially, the provider did not communicate the failure to GLONASS users while it was in progress.

Impact on the user community varied by receiver firmware: some receivers ignored the bad ephemerides and kept tracking, some dropped GLONASS, and some receivers stopped GPS tracking as well. Of ~180 IGS reference stations analyzed by CODE, about 60 were severely affected. IGS post-processing products (ultra-rapid, rapid, final orbits) were “virtually not affected” — they aggregate over a day of observations and the disruption only knocked out ~10% of GLONASS observations on April 2 — but the IGS Real-Time Experiment, which depends directly on Broadcast Ephemerides, treats the BE as a single point of failure.

Recommendations for the IGS: implement IGS-side validation of all GNSS Broadcast Ephemerides (or stop relying on them in the real-time service); for fully deployed constellations like GPS and GLONASS, derive station coordinates and Earth-rotation parameters from each system separately before combining, so per-system anomalies surface earlier; and monitor Broadcast Ephemerides quality continuously, e.g. by using the predicted portion of the IGS ultra-rapid orbits as a reference.