START HERE
A clear overview of the two documented incidents, Hostinger’s changing explanations and corrections, the September 15 preservation/source-custody correspondence and the questions that remain unresolved.
Current case status
This case began with destructive malware-scanner action against working PHP files and developed into a dispute over what the scanner had detected, what technical work had actually occurred, which records were retained, what had been sent to a third party and how preservation was handled. The documentary record now covers two separate destructive incidents, formal Hostinger corrections and withdrawals, a preservation chronology with unresolved conflicts, and a new removal after Hostinger had already closed its internal review.
What happened
In August 2026, manager.php files associated with legitimate administrative software were classified by Hostinger’s malware system and subjected to cleanup that left the affected customer-facing files at 0 bytes. The dispute that followed was not limited to the classification itself. Hostinger’s technical account changed materially over time, several statements were later corrected or withdrawn, and the provider ultimately acknowledged shortcomings in the way the matter had been handled.
Why the record matters
The central issue for publication is the sequence of documented statements and records. Earlier explanations are preserved beside later corrections so that readers can see how the account evolved. A correction does not erase the earlier statement, and an unresolved question is not converted into a conclusion simply because the answer would be convenient.
Two documented destructive incidents
The August incident is documented through Hostinger communications, scanner-related records and preserved files. The September recurrence has an unusually clear boundary: a Hostinger-native pre-event backup preserves manager.php at 548,265 bytes, an independent same-day backup preserves exactly the same file, Hostinger’s malware interface records a new Malicious and Removed event, and a Hostinger-native post-event backup preserves the same path at 0 bytes.
What Hostinger later corrected
The later record includes formal correction of Monarx to Imunify, withdrawal of the alleged August 14 Engineering or manual scan, correction of the earlier hash-only description after Hostinger confirmed complete later/current file submissions to CloudLinux, confirmation that no allowlist was ever activated, and withdrawal of a specific size comparison that the retained event data did not support.
Hostinger had presented the Senior Technical account as reliable
On August 17, after the detailed technical response, Hostinger support said the information had been provided directly by Senior Technical, described that team as part of the senior-management structure in the area and expressly told the customer that the details were accurate. The later record matters because several material elements of that account were subsequently corrected or withdrawn.
The backup explanation was later clarified as two separate objects
Earlier support said destructive cleanup created no isolated backup before truncation. Hostinger later clarified that this was true at the live file location but incomplete as a description of the wider system: a separate Imunify quarantine object retained the original bytes for 14 days. The distinction is important because the live 0-byte file and the temporary quarantine copy were not the same object.
What Hostinger maintained
Hostinger’s final internal review continued to maintain that the August removal was correct and contractually permitted. Its final technical position described the detection as category and functionality based under an administrative-tools category, while stating that it had no file-specific record of authentication bypass, actual exploitation, account compromise, third-party access or a concealed malicious payload for the August files.
A preservation request predates the stated quarantine expiry
The supplied record contains an August 19 preservation request tied to GLB-247793. Hostinger later said the original pre-cleanup bytes were automatically deleted on August 21-22 under a 14-day quarantine policy, while event and scan records were subject to a separate 30-day retention period. A later Hostinger response also said the original copies had been deleted before the preservation request was received. The case file preserves that chronology as an unresolved record conflict rather than silently choosing one interpretation of what Hostinger meant by received.
The final technical position was more specific than the earlier backdoor language
Hostinger ultimately identified Imunify360 Detect Admin Tools as the relevant feature and described the classification as category-based on file-manager functionality. Its final record says the August events came from a rescan following a signature update and that initiator root represented the automated scanner process. Hostinger also stated that it had no file-specific finding of authentication bypass, actual exploitation, account compromise, third-party access or concealed payload for the two disputed August files.
What remains unresolved
Important gaps remain because Hostinger’s preserved August event table did not contain several fields repeatedly requested during the dispute, including the original size and hash, exact rule version, scanner component and matched byte or region. The disappearance of a previously visible customer-facing escalation conversation remains unexplained. The complete downstream retention and chain of custody for CloudLinux submissions remains a separate question. For the September recurrence, actual application of the preservation hold was still unconfirmed at 17:40 CEST on September 11.
September 15 added a separate preservation and source-custody chapter
Hostinger still could not verify actual hold application on September 15. It also proposed a new full-source whitelist review, after which the customer renewed preservation and requested written source-custody terms. Hostinger then said no additional source disclosure was required while those questions remained unresolved and promised not to treat a later/current file as the September 10 incident-time object.
Two destructive incidents are documented. Hostinger formally corrected or withdrew multiple earlier technical statements. Complete later/current files were submitted to CloudLinux. The September recurrence has a preserved pre-event and post-event boundary.
The missing customer-facing conversation remains unexplained. Several original August forensic fields were not captured in Hostinger’s preserved event table. CloudLinux downstream custody questions remain open. As of Sep 15, 2026 at 14:48 CEST, Hostinger still had not verified actual hold application or the existence, expiry, deletion status or retention period of the relevant September records or original/quarantine object.