✦ Preferences saved
HOSTINGER CASE FILE/MASTER TIMELINE
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 preservation record.

DOCUMENTED FACT
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.

HOSTINGER STATEMENT
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 LATER
HOSTINGER STATEMENT
T-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 LATER
DOCUMENTED FACT
T-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 LATER
DOCUMENTED FACT
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.

HOSTINGER STATEMENT
T-06

Hostinger confirmed no allowlist had been activated

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.

LATER CORRECTION
T-07

Technical corrections became explicit

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 LATER
HOSTINGER STATEMENT
T-08

Hostinger issued its final internal review

Hostinger 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.

DOCUMENTED FACT
T-09

A new manager.php removal occurred after the final review

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.

TECHNICAL NOTE
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.

PRESERVATION STATUS
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.

PRESERVATION STATUS
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 UNRESOLVED