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 attributed the issue to tiru.casa even though the affected files documented in the incident were located elsewhere.
It is part of the broader record of inconsistent technical and account handling.
The record shows the attribution mismatch; it does not establish the internal cause of that mismatch.
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.
Hostinger’s interface records a new Jurist manager.php event as Malicious with the action Removed after the September 7 final internal review.
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 Hostinger-native backup before the recurrence preserves the root manager.php as a non-zero file 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 public case file does not publish the proprietary source archive or every private hash correlation.
The Hostinger-native backup after the recurrence preserves the same 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.
Different timestamps displayed by scanner, audit, quarantine and backup systems are preserved as recorded rather than silently reconciled.
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.