PART II: THE TECHNICAL ACCOUNT CHANGED
The August to September 7 record: changing technical explanations, formal corrections, CloudLinux disclosure, missing records, Compliance handling and Hostinger’s final internal review.
Part II covers the period after the August 8 publication through Hostinger’s final internal review on September 7. The importance of this period lies in the way the technical explanation changed as the complaint moved from ordinary support into technical escalation and Compliance review.
From false-positive handling to category-based classification
The early support record treated the incident in a way that led to an allowlist representation. Later communications shifted toward confirmed-backdoor and dropper language. By the final internal review, Hostinger’s maintained position was different again: the files were classified by category and functionality as administrative tools, without a file-specific record of authentication bypass, exploitation, compromise, third-party access or concealed payload.
The allowlist that was never activated
On August 8, support represented that relevant hashes and paths had been submitted for persistent allowlist handling. Hostinger later confirmed that no allowlist was ever activated and characterised the offer and reversal as a handling failure. The earlier statement remains visible in the case file because it is part of the customer-facing chronology.
The August 14 scan account was withdrawn
Support communications described a manual or Engineering verification on August 14. Later Hostinger reviews progressively corrected that account. The September 7 final internal review stated that no record of an Engineering scan, audit, command or job matching the earlier representation could be found. The case file therefore treats the earlier scan account as a withdrawn Hostinger statement, not as an established event.
CloudLinux disclosure changed the scope of the transparency issue
Hostinger later corrected the earlier hash-only framing and confirmed that complete content of later/current file versions had been submitted on August 18 through the Imunify360 false-positive tool to the CloudLinux API together with associated metadata. Those submissions were not the original August 7 pre-cleanup bytes. The distinction between later/current copies and the original removed objects is preserved throughout this case file.
The record gaps remained significant
Hostinger’s final review confirmed that its preserved August event table did not contain several fields repeatedly requested during the dispute, including original size and hash, exact rule version, scanner component and matched byte or region. Hostinger also maintained that the original quarantined bytes had expired under its normal retention process and that no secondary copy, forensic image or derived digest of those original bytes remained on its side.
The missing customer-facing conversation remains unresolved
A customer-facing escalation conversation that had previously been visible ceased to appear in the user-facing Hostinger history while older conversations remained visible. The final review discussed the internal GLB record, which is a different issue. The case file therefore keeps the disappearance of the customer-facing conversation marked as unresolved and does not assign an intent that the record does not establish.
Hostinger’s final internal review
On September 7, Hostinger declared its internal review closed. It maintained that the August removal was correct and contractually permitted, supplied event and scan identifiers, confirmed that important requested event fields were not captured, formalised several corrections, confirmed complete-file submissions to CloudLinux and acknowledged that contradictory statements and the allowlist handling should not have reached the customer in the form they did.