TECHNICAL LESSONS FOR DEVELOPERS
Technical lessons from the Hostinger case about category-based detections, administrative tooling, backup boundaries, scanner metadata and preservation.
The technical lesson is broader than a single signature. The record touches classification by functionality, destructive cleanup, backup boundaries, incomplete scanner metadata, third-party submission, retention and the difference between a malware category and a demonstrated concealed payload.
Category-based detection and dual-use administrative functionality
Hostinger’s final position treats the August file manager as an administrative-tool category based on functionality. For developers, that is materially different from a file-specific demonstration of hidden malicious code. Both facts can coexist: a security product can classify a powerful administrative tool into a risky category while the available file-specific record does not demonstrate a concealed payload.
Destructive cleanup changes the recovery problem
A detection that only alerts is operationally different from a detection that modifies or truncates a production file. Hostinger described cleanup in the August record as truncation to 0 bytes, and the September post-event backup preserves the same path at 0 bytes. Systems that can take destructive action require recovery planning that assumes the scanner itself may become part of the incident.
Independent hashes are useful, but publication strategy matters
Hashes can establish file identity across independent backups and can be valuable when a provider record is incomplete. They do not all need to be published immediately. This case file withholds some exact forensic correlations where publication would disclose proprietary source relationships or give the provider information that it should be able to produce from its own systems.
Preserve multiple clock sources instead of normalising them by assumption
Scanner UI times, quarantine timestamps, audit timestamps and backup labels can represent different stages and may use different time zones. This case file publishes them as recorded unless a source explicitly establishes how they relate. Silent timestamp reconciliation can turn a real uncertainty into a false precision.
Provider event tables may not contain the forensic fields you expect
Hostinger’s final review said the preserved August event table did not capture original size or hash, exact rule version, scanner component or matched byte or region. Developers should not assume that a hosting security dashboard implies retention of a complete forensic event object. If those fields matter, preservation requests should be precise and early.
Third-party submission should be documented precisely
In this case, Hostinger eventually confirmed complete later/current file submissions to CloudLinux through the Imunify360 false-positive tool. Technical documentation should distinguish the submitted file version, associated metadata, time, receiving service and what remains unknown about downstream retention or derivatives. A statement about a hash cannot substitute for a statement about complete file content.