A structured public evidence library for the Hostinger case with exhibit IDs, source notes, evidentiary limits and links back to the master timeline.
The original August event in which manager.php was classified and cleanup left the affected customer-facing file at 0 bytes.
It anchors the first destructive incident and the chronology that followed.
The public exhibit does not establish scanner internals that Hostinger did not preserve in its event table.
I am now submitting these details to our malware security team to create the persistent allowlist entry for both files.
Support represented that the relevant hashes and paths had been submitted to the malware team for persistent allowlist handling.
Hostinger later confirmed that no allowlist was ever activated, making the earlier representation central to the handling record.
It records what support told the customer; it does not independently show an internal allowlist job.
No allowlist entry was ever activated; the submission was reviewed and declined by Imunify.
Hostinger acknowledged that the proposed allowlist was never activated and described the offer and reversal as a handling failure.
It directly corrects the earlier customer-facing understanding that persistent allowlist handling was being processed.
It does not by itself establish why the earlier statement was made.
A Hostinger notification named a different domain associated with the hosting plan even though the disputed manager.php detections concerned two other file locations.
It documents a customer-facing attribution mismatch. Hostinger later said the name came from the hosting plan's main-domain label.
The later explanation identifies how Hostinger says the domain label was selected; it does not independently establish the internal trigger that generated the notification.
We've received an update from our Engineering Team and can confirm that both files were identified as malicious and are not false positives.
Support used confirmed-backdoor and dropper language and described an Engineering or manual verification on August 14.
These representations materially changed the explanation given after the original false-positive and allowlist handling.
Later Hostinger responses withdrew or corrected important parts of this account.
There is no record of any Engineering scan, audit, command, or job on 14 August.
Hostinger stated that it had no record of any Engineering scan, audit, command or job on August 14 matching the earlier representation.
It removes a central technical claim that had been used to explain the incident.
The withdrawal establishes the absence of the represented record in Hostinger’s review; it does not establish why the claim was originally communicated.
The detection was performed by Imunify360, through the Detect Admin Tools feature.
Hostinger withdrew the earlier Monarx attribution and identified Imunify as the relevant detection system.
The identity of the scanner is a basic technical fact and changes how the earlier account must be read.
This correction does not by itself determine whether the category classification was appropriate.
Correcting information communicated previously: the complete files were sent for analysis of a possible false positive, not just their hashes.
Hostinger clarified that complete file content was submitted through Imunify360, not only hash values.
For proprietary source code, the distinction between a hash and a complete file is material to transparency and trust.
The confirmed submissions were later/current versions from August 18, not the original August 7 pre-cleanup bytes.
Each submission included the file path, server identifier, file owner, a note, and the complete file content via the Imunify360 submission tool to the CloudLinux API.
Hostinger stated that complete later/current files were submitted on August 18 through the Imunify360 false-positive tool to the CloudLinux API together with path, server identifier, file owner and a note.
It documents what was transmitted and corrects the earlier customer understanding that only hashes were involved.
Questions about access, downstream retention, copies, derivatives and the complete chain of custody remain separate issues.
A customer-facing escalation conversation that had been visible ceased to appear in the user-facing history while older conversations remained visible.
The missing conversation contains part of the technical escalation record and prompted preservation and explanation requests.
The cause remains unresolved, and the case file does not claim that Hostinger removed it to conceal evidence.
The formal escalation placed the contradictory technical claims, record-production questions and preservation requests into a documented complaint channel.
It establishes what Hostinger was being asked to address before the final internal review.
A complaint records requests and allegations; each factual point still depends on the supporting record.
We know this has taken far longer than it should have, and that you have had to keep track of contradictions on our side that never should have reached you in the first place.
Hostinger closed its internal review, maintained the category-based removal position, documented several formal corrections, confirmed CloudLinux complete-file submission, listed significant fields absent from the preserved event table and acknowledged shortcomings in the handling.
It is the most comprehensive Hostinger statement on the August record before the September recurrence.
The final review does not erase earlier statements. Both the earlier statements and later corrections remain part of the chronology.
The redacted detail view records a September 10 manager.php event as Malicious with the action Removed. The sensitive account path is withheld in the public copy.
It establishes that the same class of destructive problem recurred after Hostinger had closed its internal review of the August dispute.
The displayed interface records classification and action; the pre-event and post-event backups establish the file-state boundary separately.
The public screenshot identifies the September 10, 07:09 Hostinger recovery point. The extracted backup evidence, verified separately from the screenshot, preserves the affected manager.php at 548,265 bytes; an independent same-day backup preserves the same file byte-for-byte.
It provides an independently corroborated pre-event state before the new scanner removal.
The screenshot establishes the recovery point; the 548,265-byte file-state claim comes from the extracted and verified backup contents, not from text visible in the screenshot itself.
The public screenshot identifies the September 11, 07:11 Hostinger recovery point. The extracted post-event backup evidence, verified separately from the screenshot, preserves the same affected manager.php path at 0 bytes; the live file was also 0 bytes when the incident was observed.
Together with H-014 and H-013, it creates a clean pre-event, scanner-event and post-event documentary boundary.
The screenshot establishes the recovery point; the 0-byte file-state claim comes from the extracted and verified backup contents and the separately preserved live-state evidence.
The record exposed the exact path, a recorded hash, recorded size 0 bytes, malicious classification, quarantined status, quarantine timestamp, audit timestamp and a null cleanup timestamp.
The record provides backend-facing metadata but also exposes a semantic gap that support could not resolve.
Support could not establish whether the hash and the 0-byte size describe the same object or the same stage. A strategically sensitive independent hash correlation is retained outside the public record for now.
Human support stated that the explicit preservation and retention-hold request for the September event had been forwarded and recorded in complaint #137820 at a Hostinger-stated time of 13:04.
It establishes that an explicit preservation request was placed into the complaint record.
Recording a request is not the same as confirming that a hold was actually applied.
At 14:47 CEST, human support stated that Hostinger had not yet confirmed that the preservation hold itself had been applied.
It separates a recorded request from actual preservation implementation.
This was an interim status that was later supplemented by further human-support statements on September 11, including details that partly conflict with one another.
A human agent stated at 17:02 CEST that the explicit instruction preventing expiry or deletion had not yet been sent.
The statement is relevant because the same agent later supplied a send time that predates this message.
The public record preserves the statement without inferring why the later chronology conflicts with it.
At 17:33 CEST, the agent stated that the non-expiry instruction had been sent at 14:35 UTC, equivalent to 16:35 CEST. That stated send time is earlier than the 17:02 message saying the instruction had not yet been sent.
The two human-support statements create a procedural chronology conflict that remains part of the preservation record.
The case file does not infer intention or choose an undocumented explanation for the conflict.
The agent still could not confirm actual hold application, an internal hold reference or extended retention for any retained original or quarantine object.
This is the latest preservation status supported by the material in the archive supplied for publication.
It does not establish that evidence was destroyed or that preservation was refused. It establishes that actual hold application remained unconfirmed at that time.
The August 19 request expressly asked Hostinger to preserve the complete conversation record, GLB-247793 records, associated backend scanner logs, Event IDs, internal escalation links and records relating to the disputed August 14 Engineering/manual-scan account. The automated response instead routed the message to unrelated ticket #125522, after which a correction asked Hostinger not to merge or redirect the case and to record the preservation request under GLB-247793.
It establishes an explicit preservation request concerning the scanner dispute before Hostinger later dated expiration of the original quarantine bytes to August 21-22, and it documents a routing failure while preservation was being requested.
The August 19 wording did not expressly name the original quarantine object or pre-cleanup bytes. The record therefore supports a timing and scope question, not a claim that Hostinger had already confirmed a technical hold on those original bytes.
Hostinger stated that complaint #137820 was linked to GLB-247793, would not be redirected to an unrelated ticket, was being reviewed by a qualified human team member, and that no scanner action would be initiated against the two disputed files while the review was in progress.
The statement narrows the scope and duration of the temporary protection: it concerned the two disputed files and only while that review was in progress.
It was not a permanent allowlist, a platform-wide exception or a guarantee covering future deployments or later versions.
Hostinger stated that four event records and both scan records were subject to a standard 30-day retention period and that steps had been taken to preserve them beyond September 6. Separately, it said the original pre-cleanup bytes had been automatically deleted on August 21-22 under a 14-day quarantine policy. The same August 27 response said the static source review finding no hidden backdoor, dropper, concealed malicious payload or covert request-to-shell execution chain was consistent with the category-based classification, and that the classification was not based on hidden code but on the category of functionality. It also acknowledged that the case handling fell below the standard the customer was entitled to expect.
The distinction is essential because a preserved event record is not the same thing as preservation of the original quarantined file bytes.
The response does not resolve the conflict between the documented August 19 preservation request and later statements about when Hostinger considered the preservation request received for the original quarantine objects.
Hostinger confirmed that Events 1028417-1028420 were generated by Imunify through a rescan following a signature update, not by the routine hourly job. It also stated that the accurate classification was categorical, based on standalone PHP file-manager functionality, and that it had no file-specific record of unauthenticated access, authentication bypass, actual exploitation, account compromise or third-party access tied to the two files.
This narrows both the trigger and the technical basis Hostinger ultimately relied on.
The categorical policy position does not by itself establish that the file was harmless in every runtime context, and it is not equivalent to a file-specific concealed-payload finding.
Hostinger stated that complete file content for the later/current Tyrus and Site B file versions was submitted through the Imunify360 submission tool to the CloudLinux API on August 18 at 08:26:14 UTC and 08:27:01 UTC. Each submission included file path, server identifier, file owner, a note and complete file content. Hostinger also said there was no record of a CloudLinux submission on August 8 and that it had requested retention/deletion information from CloudLinux.
It corrects the scope of the earlier hash-only description and precisely identifies what Hostinger says left its system, when and through which tool.
The archive supplied for publication does not contain a later CloudLinux response resolving downstream retention, deletion, copies or derivatives. The submitted versions were later/current files, not the original August 7 pre-cleanup objects.
Hostinger identified Imunify360 Detect Admin Tools as the feature in force, described the basis as categorical functionality, stated that initiator root represented the automated scanner process, confirmed cause rescan, and listed fields not present in the event table, including original size/hash, exact rule version, scanner component identifier, quarantine object ID and matched byte offset. The supplied event table names the signature identifier SMW-BLKH-SA-CLOUDAV-php.bkdr.drpr-NP2141-1 on the two found events; Hostinger nevertheless stated that the exact rule version and matched byte/region were not captured in that table. The same final review stated that no Engineering scan, audit, command or job from August 14 could be found.
It is the most specific Hostinger description of the retained August event record and the policy basis relied on in the final determination.
The absence of fields from this table does not prove that no other system ever held them; it establishes what Hostinger said was not captured in this retained event table.
The review found no static evidence that the preserved later/current Tyrus manager.php was a hidden PHP backdoor/dropper or contained a concealed malicious payload. It also documented legitimate high-privilege file-manager capabilities and genuine security weaknesses. Exploit-relevant implementation details are intentionally withheld from the public case file.
It supports a precise distinction between concealed-malware findings and legitimate administrative functionality with dual use, without implying that the software was free of security weaknesses.
This is a static source review of a later/current preserved version, not a malware-vendor certification and not an examination of the original August 7 pre-cleanup bytes, runtime environment or every companion file. Security-sensitive implementation findings remain in the private evidence package.
You can be confident that the details provided are accurate.
Hostinger support said the preceding technical information had been provided directly by a Senior Technical team member who was part of the senior-management structure in that area and expressly assured the customer that the details were accurate.
Major parts of the technical account associated with that period were later corrected or withdrawn, including scanner identity, the claimed August 14 Engineering/manual scan and the basis of the backdoor/dropper characterization.
The exhibit establishes what Hostinger represented about the source and reliability of the information at that time. It does not establish why later corrections became necessary.
The scanner does not generate an isolated backup prior to cleanup, so account backups or external backups are required for restoration.
Support explained destructive cleanup as immediate truncation to 0 bytes and said the scanner did not generate an isolated backup before cleanup.
Hostinger later gave a more specific two-object explanation in which the live path had no backup at that location but a separate Imunify quarantine subsystem retained original bytes for 14 days.
This exhibit records the customer-facing explanation given on August 8. It does not independently inspect the internal quarantine subsystem.
The live file was truncated to 0 bytes at the moment of cleanup, with no backup created at that location. Separately, Imunify's quarantine subsystem held a copy of the original bytes for a fixed 14-day window, which expired automatically on 21 and 22 August 2026, before your preservation request reached us.
Hostinger said two different objects had been conflated in earlier explanations: the customer-facing live file was truncated to 0 bytes, while a separate Imunify quarantine copy retained the original bytes for a fixed 14-day period.
It materially clarifies the earlier no-isolated-backup explanation and establishes the retention model Hostinger relied on in its final position.
The original quarantine objects had already expired by the dates Hostinger supplied, so the public record cannot independently inspect those original bytes.
Earlier communications that described your files as "confirmed backdoors" or "dropper payloads" were inaccurate in that they implied a file-specific malicious code finding. The accurate position — confirmed by CloudLinux/Imunify's own response — is that the classification is categorical. Your static source review finding no hidden backdoor or dropper is consistent with this. We acknowledge that the earlier characterizations were misleading and we apologize for the confusion they caused.
Hostinger expressly corrected the earlier file-specific malicious-code implication and said the accurate position was a categorical classification. It also acknowledged that the earlier characterizations were misleading.
This is stronger than a later reinterpretation: Hostinger itself used the terms inaccurate and misleading for the earlier backdoor/dropper characterizations.
Hostinger continued to maintain a category-based classification and contractual position after correcting the earlier file-specific malicious-code language.
Hostinger said the domain name used in the August 13 notification referred to the hosting plan's main-domain label, rather than identifying the two affected file locations.
It preserves Hostinger's later explanation for the customer-facing mismatch without publishing the private domain name.
The explanation is a later Hostinger statement. The supplied archive does not independently reconstruct the notification generator that selected that label.
You’re right to challenge that inconsistency. The current file hashes were present; what was unavailable was any historical before/after hash comparison. My later wording incorrectly implied that no hash data existed, and I apologize.
Support first stated that the two current files had different SHA-256 hashes. Later wording incorrectly implied that no hash data existed. When challenged, Hostinger explicitly clarified that the current file hashes were present, while a historical before/after hash comparison was unavailable, and apologized for the incorrect wording.
It distinguishes current-file hashes from a historical pre/post-cleanup comparison and preserves Hostinger’s explicit correction rather than leaving the two statements to appear irreconcilable.
This records Hostinger’s customer-facing statement. It does not independently establish the provenance or creation time of the current hashes beyond what support represented.
our position on this matter remains unchanged
Customer Success restated the platform-wide policy and said the information previously supplied represented the full extent of what it could share at that point.
It explains why the next message narrowed the dispute to a direct preservation-status question rather than repeating the scanner-policy debate.
This is a customer-facing policy statement. It does not answer whether a hold had actually been applied to the September 10 records or object.
Has Hostinger actually applied the preservation / retention hold requested in complaint #137820
The message requested a direct Yes-or-No answer on actual hold application and specified the factual details requested for either answer.
It establishes the scope of the question Hostinger answered at 13:33 and again at 14:48.
This is the customer’s request, not proof that a hold existed or that Hostinger was legally required to apply one.
I am not able to confirm at this time whether a preservation hold was applied
Hostinger said actual hold application still required internal verification, stated its current policy on customer-initiated preservation requests, and requested the full manager.php source through pwpush.com for a formal whitelist review described as separate from the Imunify platform-wide policy.
The response introduces both the still-unverified preservation status and a newly described review path that must be read alongside earlier statements about whitelist availability.
The policy statement is Hostinger’s stated policy, not a legal conclusion adopted by this publication. The email does not establish what outcome the proposed review could actually produce.
This email expressly renews and continues my preservation request.
The message expressly renewed preservation, declined another complete-source disclosure until custody and handling terms were defined, preserved willingness for a properly scoped independent review, and requested reconciliation of the proposed whitelist review with earlier Hostinger statements.
It records the customer’s conditions and no-waiver position immediately before Hostinger’s 14:48 acknowledgement.
This records the customer’s position and requests. It does not by itself establish Hostinger’s legal duties or the final authority of any whitelist process.
No additional source-code disclosure is required from you while the custody, purpose, recipients, access controls, retention, and disposition questions remain unresolved.
Hostinger acknowledged the renewed preservation request, said it still could not provide a verified Yes-or-No answer on hold application or responsibly confirm the existence, expiry, deletion status or retention period of the relevant records, and said no additional source-code disclosure was required while custody-related questions remained unresolved.
The response sets the current editorial cutoff: preservation remains unverified, further source disclosure is not required for now, reconciliation remains promised, and Hostinger says a later/current file will not be characterized as the September 10 incident-time object.
The promised verified preservation answer and remaining point-by-point clarification were still pending at this cutoff.