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. During this period the technical account changed repeatedly, the case was misrouted at one point, preservation became a separate issue, Hostinger introduced a qualified human review and a temporary restriction on scanner action against the two disputed files, and later responses formally corrected or withdrew major parts of the earlier account.
From false-positive handling to a category-based policy position
The August 8 support record led to a persistent-allowlist representation. Later support used confirmed-backdoor and dropper language. Hostinger’s final position was materially different: the files were classified under Imunify360 Detect Admin Tools because of standalone PHP file-manager functionality, while Hostinger stated that it had no file-specific record of authentication bypass, actual exploitation, account compromise, third-party access or concealed payload for the two disputed August files.
Hostinger later called the file-specific backdoor/dropper wording inaccurate and misleading
On September 2, Hostinger explicitly said that earlier communications describing 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 and apologized for the confusion. Hostinger nevertheless continued to maintain a categorical classification based on file-manager functionality.
Senior Technical accuracy assurance preceded later corrections
On August 17, support said the preceding information came directly from Senior Technical, described the team as part of the senior-management structure in this area and wrote: "You can be confident that the details provided are accurate." This matters because the subsequent record corrected or withdrew material parts of the same technical account. The case file preserves both moments rather than replacing the earlier assurance with the later version.
The allowlist that was never activated
On August 8, support represented that hashes and paths had been supplied for persistent allowlist handling and that those submissions were being processed. Hostinger later confirmed that no allowlist entry was ever activated and described the offer and later reversal as a handling failure. The record does not silently equate the August 8 internal malware-team submission with the later August 18 CloudLinux complete-file submissions; Hostinger was explicitly asked to identify them separately if they were different workflows.
The notification did not identify the affected file locations
A Hostinger email named a different domain associated with the hosting plan even though the disputed manager.php detections concerned two other file locations. Hostinger later explained that the name was the hosting plan's main-domain label. That explanation is preserved, but it does not change the fact that the notification itself did not identify the affected file locations.
A preservation request was sent on August 19 while the dispute was active
The August 19 record contains an explicit preservation request tied to GLB-247793 and the missing customer-facing escalation conversation. An automated response instead routed the message to unrelated ticket #125522, prompting an immediate correction instructing Hostinger not to merge or redirect the case and asking that the preservation request be recorded under GLB-247793.
Qualified human review and a limited scanner restriction
On August 25, Hostinger confirmed that complaint #137820 was linked to GLB-247793 and was being reviewed by a qualified human team member, not an automated system. Hostinger also stated that no scanner action would be initiated against the two disputed files while that review was in progress. The commitment was limited to those two files and that review period; it was not a permanent allowlist or a guarantee covering later deployments.
The August 27 response separated event retention from quarantine-byte retention
Hostinger said the four event records and both scan records were subject to a 30-day retention period and that steps had been taken to preserve them beyond September 6. Separately, Hostinger said the original pre-cleanup bytes had been automatically deleted on August 21-22 under a 14-day quarantine policy. The same response acknowledged that the handling of the case fell below the standard the customer was entitled to expect, specifically citing the unfulfilled allowlist offer, contradictory support statements and delayed or unclear escalation responses.
The August 7 trigger was ultimately identified as an Imunify rescan after a signature update
Hostinger later confirmed that Events 1028417-1028420 were generated by Imunify through a rescan following a signature update, not by the routine hourly cache/queue job. The final event table records cause: rescan, and Hostinger explained that initiator: root represented the automated scanner process rather than a human-initiated action.
The August 14 scan account was ultimately withdrawn
Earlier Hostinger communications described a manual or Engineering verification on August 14. Later responses changed that account, and the September 7 final internal review stated that no record of any Engineering scan, audit, command or job on August 14 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 from hashes to complete files
Hostinger ultimately stated that complete content of the later/current Tyrus and Site B file versions was submitted through Imunify360 to the CloudLinux API on August 18 at 08:26:14 UTC and 08:27:01 UTC, together with path, server identifier, file owner and a note. Hostinger said there was no record of a CloudLinux submission on August 8. It also said it had requested information from CloudLinux about retention and deletion of the submitted copies; the archive supplied for publication contains no later CloudLinux response resolving those downstream questions.
The preserved event table was specific about what it did not contain
The final Hostinger record said the retained table contained date/time, path, action, cause, initiator, signature and, where applicable, a detection identifier. The supplied table names the signature identifier SMW-BLKH-SA-CLOUDAV-php.bkdr.drpr-NP2141-1 on the two found events. It did not contain original file size/hash, exact rule version, scanner component identifier, quarantine object ID, matched byte offset/region and several other requested forensic fields. The absence of those fields from this table is kept separate from any broader claim about what another system may once have held.
The missing customer-facing conversation remains a separate unresolved question
Hostinger repeatedly answered by describing GLB-247793 as an internal coordination ticket that remained intact. The issue documented here is different: a customer-facing escalation conversation that had previously been visible in account history ceased to be visible while older conversations remained. The case file therefore does not treat an answer about the internal GLB ticket as an answer about the missing customer-facing conversation, and it does not infer why the customer-facing item disappeared.
Hostinger’s final internal review closed the review but also formalised major corrections
On September 7, Hostinger maintained that the August classification and removal stood and were contractually permitted. At the same time, the final review formalised corrections about the August 14 scan, scanner identity, complete-file CloudLinux submissions and unsupported size comparisons, described the Detect Admin Tools policy, supplied the retained event table and again acknowledged shortcomings in the handling of the case. The final review therefore does not erase the earlier contradictions; it records and corrects several of them.
The final review corrected the earlier backup model
The August 8 explanation said the scanner created no isolated backup before cleanup. The September 7 final review clarified that two distinct objects existed: the live file at the affected location was truncated to 0 bytes with no backup created there, while a separate Imunify quarantine subsystem retained a copy of the original bytes for a fixed 14-day window. This later distinction also explains why a 0-byte live file and temporary original-byte retention can both appear in the record without describing the same object.