T-01
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.
TRACE / SPECIAL CASE FILE 003
MASTER TIMELINE
The master chronology of the Hostinger malware-scanner dispute from the August incident through the September recurrence and the September 15 preservation, source-custody and whitelist-review exchange.
T-02
Allowlist handling was represented as being processed
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 LATERT-03
Backdoor, dropper and manual-scan explanations appeared
Later 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 LATERT-03A
Senior Technical account was presented as accurate
After a detailed technical response, Hostinger support said the information had come directly from its Senior Technical team, described that team as part of the senior-management structure in this area, and told the customer: "You can be confident that the details provided are accurate." Multiple material elements of that account were later corrected or withdrawn.
CORRECTED LATERT-04
Later/current complete files were submitted to CloudLinux
Hostinger 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 LATERT-04A
Preservation request and unrelated-ticket routing
A preservation request tied to GLB-247793 and the missing customer-facing escalation conversation was sent while the dispute was active. An automated reply instead routed the message to unrelated ticket #125522; a correction was sent instructing Hostinger not to merge or redirect the case and asking that the preservation request be recorded under GLB-247793.
T-05
Formal Compliance escalation
The dispute was formally escalated with requests covering technical records, preservation, the missing customer-facing escalation conversation and the contradictory explanations already received.
T-05A
Qualified human review and a temporary scanner restriction
Hostinger confirmed that complaint #137820 was linked to GLB-247793, that the case was being reviewed by a qualified human team member rather than an automated system, and that no scanner action would be initiated against the two disputed files while that review was in progress.
T-06
Hostinger confirmed no allowlist had been activated
Hostinger confirmed that no allowlist had been activated, acknowledged that the case handling fell below the standard the customer was entitled to expect, and distinguished two retention regimes: 30 days for retained event/scan records and 14 days for original quarantine bytes, which Hostinger said had already expired on August 21-22.
T-06A
Hostinger explicitly corrected the confirmed-backdoor and dropper wording
Hostinger stated that earlier descriptions of the files as confirmed backdoors or dropper payloads were inaccurate insofar as they implied a file-specific malicious-code finding. It also acknowledged that the earlier characterizations were misleading, while maintaining a categorical classification.
CORRECTED LATERT-07
Technical corrections became explicit
Hostinger corrected the record again: complete later/current files, not merely hashes, had been submitted to CloudLinux on August 18 at 08:26:14 UTC and 08:27:01 UTC with path, server identifier, file owner, a note and full file content. Hostinger also said it had requested retention/deletion information from CloudLinux and would share the response once received.
CORRECTED LATERT-08
Final internal review, event-table disclosure and policy position
Hostinger closed its internal review, maintained the contractual classification/removal, formally stated that no Engineering scan, audit, command or job from August 14 could be found, identified Imunify360 Detect Admin Tools as the relevant feature, explained that initiator root represented the automated scanner process, and listed fields that were absent from its retained event table.
T-09
A new manager.php removal occurred after the final review
A newly deployed manager.php file in the Site B environment 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 corresponding location at 0 bytes.
T-10
Support exposed a hash and a recorded size of 0 bytes without explaining field semantics
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.
T-11
Preservation request recorded; hold application not confirmed
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.
T-12
Later preservation statements conflict, while actual hold application remains pending
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 UNRESOLVEDT-13
Hostinger restated its platform-wide policy and said its position remained unchanged
Customer Success said the automated policy for standalone PHP file managers was consistent and platform-wide, that new detections of the same file type fell under the same policy, and that the information already supplied represented the full extent of what it could share at that point.
REMAINS UNRESOLVEDT-14
A direct Yes-or-No preservation-status answer was requested
The follow-up narrowed the request to whether a preservation or retention hold had actually been applied to the September 10 records and any retained original or quarantine object, asking for the application time and reference if yes, or the existence and expiry/deletion status if no.
T-15
Hold application remained unverified and Hostinger proposed a new full-source whitelist review
Hostinger said it still could not confirm whether a hold had been applied and described customer preservation requests as not automatically triggering a hold under its current policy. In the same response it requested the full manager.php source through pwpush.com for a formal whitelist review described as separate from the Imunify platform-wide policy.
REMAINS UNRESOLVEDT-16
The preservation request was expressly renewed and source-custody conditions were set out
The response renewed the preservation request, declined a new full-source disclosure until custody, purpose, recipients, access controls, retention and disposition were defined, stated that this was not a refusal of a properly scoped independent review, and requested reconciliation of the newly described whitelist process with earlier statements.
T-17
Hostinger said no additional source disclosure was required while custody questions remained unresolved
Hostinger acknowledged the renewed preservation request, still could not verify hold application or the existence, expiry, deletion status or retention period of the relevant records or object, said no additional source disclosure was required while custody-related questions remained unresolved, and committed not to characterize a later/current file as the September 10 incident-time object.
REMAINS UNRESOLVED