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.
On September 2, Hostinger explicitly said the earlier confirmed-backdoor and dropper-payload descriptions were inaccurate insofar as they implied a file-specific malicious-code finding, acknowledged that the characterizations were misleading, and maintained instead a categorical classification.
The support record contained multiple descriptions of scanner timing and mechanisms, including explanations involving periodic scanning and later an alleged manual verification.
Hostinger ultimately stated that the August 7 events were Imunify events generated by a rescan following a signature update, not the routine hourly cache/queue job; the final event table also records cause: rescan and explains initiator: root as the automated scanner process.
An August 19 preservation request expressly covered the conversation, GLB-247793 records, backend scanner logs, Event IDs, escalation links and the disputed August 14 records. It was sent while the dispute was active, before Hostinger later dated automatic deletion of the original quarantine bytes to August 21-22.
A September 3 Hostinger response stated that the original copies had been deleted under the fixed retention period before the preservation request was received. Because the August 19 request did not expressly name the original quarantine object or pre-cleanup bytes, the supplied record leaves unresolved how Hostinger defined the scope and receipt of preservation for those objects.
On August 17, Hostinger support said the preceding technical information came directly from Senior Technical, described that team as part of the senior-management structure in the area and told the customer that the details could be treated as accurate.
Material elements of that technical account were later corrected or withdrawn, including scanner identity, the claimed August 14 Engineering/manual scan and the file-specific backdoor/dropper characterization.
On August 8, support said cleanup truncated flagged files to 0 bytes and that the scanner did not generate an isolated backup before cleanup.
The final review distinguished two objects: no backup was created at the live location, but a separate Imunify quarantine subsystem retained a copy of the original bytes for a fixed 14-day period.
Support first said the two current files had different SHA-256 hashes, then later wording incorrectly implied that no hash data existed.
Hostinger explicitly corrected that the current file hashes were present; only a historical before/after hash comparison was unavailable, and it apologized for the incorrect wording.
On August 27, Hostinger said no whitelist exception path was available for this file category and that files in the category would not be whitelisted regardless of individual file content.
On September 15, Hostinger proposed a “formal whitelist review” for the specific file, described as separate from the platform-wide Imunify policy. After the customer requested reconciliation, Hostinger said its written response would need to reconcile the proposed review, its authority and possible outcome with the earlier position.
At 13:33, Hostinger asked for the full manager.php source through pwpush.com to start the newly described formal whitelist review.
At 14:48, after the customer required custody and handling questions to be defined, Hostinger said no additional source-code disclosure was required while those questions remained unresolved.