PART III: THE PROBLEM HAPPENED AGAIN
The September 10 recurrence, preserved pre-event and post-event backups, Hostinger scanner records and the September 11 preservation chronology.
The September recurrence is documented separately because it occurred after Hostinger had already issued its final internal review. The strongest part of this record is the independent pre-event and post-event boundary around the new scanner action.
A clean pre-event record
A Hostinger-native backup prepared from September 10, 07:09 preserves the Jurist root manager.php at 548,265 bytes. An independent backup created the same day preserves exactly the same file byte-for-byte. Those two independent sources establish the state of the file before the new malware event without relying on a reconstruction from Hostinger support statements.
The scanner event
Hostinger’s malware interface records a new event for manager.php as Malicious with the action Removed. The interface date and the backend timestamps exposed later by support are preserved exactly as recorded because the systems may represent different stages or time zones. The case file does not silently force them into a single timestamp.
The post-event record
A Hostinger-native backup prepared from September 11, 07:11 preserves the same manager.php path at 0 bytes. The live file was also 0 bytes when the incident was observed. The documented sequence therefore contains a full pre-event file, the scanner event and a post-event Hostinger backup of the same path at 0 bytes.
Support exposed backend-facing metadata but could not explain its semantics
On September 11, a support-facing record exposed the exact path, a recorded hash, a recorded size of 0 bytes, malicious classification, quarantined status, a quarantine timestamp, an audit timestamp and a null cleanup timestamp. Support could not establish whether the recorded hash and the 0-byte size described the same object or the same lifecycle stage. The public record preserves that uncertainty instead of supplying a speculative explanation.
Preservation became a new issue on September 11
Human support confirmed that the explicit preservation and retention-hold request had been recorded in complaint #137820. Later statements distinguish that recorded request from the actual application of a hold. At 17:40 CEST, Hostinger support still had not confirmed actual hold application, an internal hold reference or extended retention of any retained original or quarantine object.
The preservation chronology contains a conflict that remains unexplained
At 17:02 CEST, a human agent said the explicit non-expiry instruction had not yet been sent. At 17:33, the same agent said it had been sent at 14:35 UTC, equivalent to 16:35 CEST. The stated send time therefore predates the message saying it had not yet been sent. Both statements are preserved as given. The case file does not infer intention or invent a reason for the inconsistency.
The procedural status also changed after the recurrence
Hostinger described its September 7 response as the conclusion of its internal review. After the new September 10 removal, support said on September 11 that the case was still open and under review by a specialised technical team. Those statements may refer to different procedural stages, so the public record preserves both without presenting them as a single confirmed status.