Original malware-scanner removals
Two manager.php files on separate deployments were classified and subjected to destructive cleanup. The customer-facing result was a file at 0 bytes.
The master chronology of the Hostinger malware-scanner dispute from the August incident through the September recurrence and preservation record.
Two manager.php files on separate deployments were classified and subjected to destructive cleanup. The customer-facing result was a file at 0 bytes.
Hostinger support stated that hashes and paths had been submitted to the malware team for a persistent allowlist entry and that the submissions were being processed. Hostinger later confirmed that no allowlist was ever activated.
CORRECTED LATERLater support communications used confirmed-backdoor and dropper language and described an August 14 Engineering or manual scan. Hostinger ultimately withdrew the August 14 scan account and corrected the scanner attribution from Monarx to Imunify.
WITHDRAWN LATERHostinger later confirmed that complete content of later/current file versions, not merely hash values, was submitted through the Imunify360 false-positive submission tool to the CloudLinux API together with associated metadata.
CORRECTED LATERThe dispute was formally escalated with requests covering technical records, preservation, the missing customer-facing escalation conversation and the contradictory explanations already received.
A point-by-point response supplied four event IDs and scan IDs, described cleanup as truncation to 0 bytes, maintained a category-based classification and acknowledged that the offered allowlist had never been activated. Hostinger described the offer and reversal as a handling failure.
Hostinger confirmed complete-file submission to CloudLinux, withdrew the Monarx attribution, said no full manual Imunify360 scan on August 14 could be found, corrected the earlier only-hashes description and withdrew the previous specific size comparison.
CORRECTED LATERHostinger closed its internal review and maintained that the August removals were correct and contractually permitted. The same response formally preserved several corrections, confirmed full-file submission to CloudLinux, identified significant event-record fields that were not captured and acknowledged that contradictory statements should not have reached the customer.
A new deployment of the Jurist root manager.php was shown by Hostinger’s malware interface as Malicious and Removed. A Hostinger-native pre-event backup and an independent same-day backup preserve the full file, while a Hostinger-native post-event backup preserves the same path at 0 bytes.
The support-facing record exposed the path, a recorded hash, recorded size 0 bytes, malicious classification, quarantined status and timestamps. Support could not establish whether the hash and size describe the same object or the same stage of the quarantine and removal process.
Human support stated that the explicit preservation and retention-hold request had been recorded in complaint #137820 at 13:04. At 14:47, support said Hostinger had not confirmed that the preservation hold itself had actually been applied.
At 17:02 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. At 17:40 the agent still could not confirm actual hold application, an internal hold reference or extended retention of any retained original or quarantine object.
REMAINS UNRESOLVED