Earlier Hostinger statements shown next to later corrections or withdrawals, with dates and evidence references preserved in sequence.
The comparison below preserves the earlier customer-facing account next to Hostinger’s later correction or withdrawal. The labels describe the documentary relationship between the statements; they do not assign intent.
Earlier support communications attributed the relevant detection to Monarx.
Hostinger later withdrew the Monarx attribution and identified Imunify as the relevant detection system.
Support represented that a manual or Engineering verification had occurred on August 14.
Hostinger’s final internal review stated that no record of an Engineering scan, audit, command or job matching that representation could be found.
The customer was initially given an account framed around hash values or only hashes being submitted.
Hostinger later confirmed that complete content of later/current files was submitted through Imunify360 to the CloudLinux API together with associated metadata.
Support stated that hashes and paths had been sent for a persistent allowlist entry and that the submissions were being processed.
Hostinger later confirmed that no allowlist was ever activated and described the offer and reversal as a handling failure.
An earlier Hostinger account used a specific size comparison when discussing detected and later files.
Hostinger withdrew that comparison because its retained event data did not support it.
Support used language describing confirmed backdoors and dropper payloads.
Hostinger’s final position maintained a category and functionality based classification while stating that it had no file-specific record of authentication bypass, actual exploitation, account compromise, third-party access or a concealed payload for the August files.