manager.php is a custom, password-protected, session-authenticated PHP file manager, built in-house, not pulled from a forum or a public repo. It has served as internal admin tooling for a commercial product for months, used daily, without a single security flag against it, until now.
On August 7, 2026, at 18:25 CEST, Hostinger's malware scanner (Monarx) flagged manager.php as Malicious on two unrelated hosting accounts at the exact same moment: this site, tyrus.dk, where the file was under active development, and a second, unrelated client account, where the same file had sat unchanged for over six weeks. Both copies were truncated to 0 bytes automatically. No warning, no quarantine, no isolated backup before the action.
The result was a blank admin panel, a broken product, and a customer who found out by accident the next morning, not because anyone was notified.
Every timestamp below comes directly from hPanel logs and live support chat transcripts, kept exactly as received.
Everything in this section is quoted exactly as it was written by Hostinger staff in the support chat. No editing, no interpretation. Read them in order and the picture builds itself.
"When custom or commercial management scripts contain encoded, password-protection, or obfuscated execution patterns, security scanners like Monarx can identify them as unknown web shells or false positives during automated signature updates."
On why the detection happened · 08/08/2026, 06:17 CEST"Automated cleanup neutralizes threats immediately by truncating flagged files to 0 bytes to prevent execution. The scanner does not generate an isolated backup prior to cleanup, so account backups or external backups are required for restoration."
On the truncation process itself, no backup, by design · 08/08/2026, 06:22 CEST"When Monarx deploys a global signature update across our infrastructure, an automated scan runs across all hosted accounts simultaneously against the new detection heuristics. Because the updated rule checked for specific obfuscation/execution patterns rather than file modification timestamps, it flagged matching code structures across separate accounts at that exact same time."
The admission that closes the case: this was a mass scan, not a per-file decision · 08/08/2026, 06:34 CEST"Because potential web shells can execute malicious actions in milliseconds, the scanner truncates flagged execution patterns right away to protect the broader server infrastructure, rather than placing files in an unblocked holding state."
On why there is no quarantine state, only destroy-first · 08/08/2026, 06:46 CEST"While we don't offer financial compensation for scanner false positives, we do provide automated backup tools in hPanel so you can quickly restore original file versions whenever code changes or security events occur."
On compensation for confirmed false positives: none · 08/08/2026, 06:46 CEST"You are correct about the specific timing for that individual daily run: since the file was neutralized at 18:25, the daily snapshot taken at 06:23 the following morning would indeed capture the file in its post-cleanup state."
On whether their own "daily backup" would have helped in this exact case: no, it would have saved the empty file · 08/08/2026, 07:00 CEST"The Malware cleaned indicator in hPanel displays a 30-day historical log of scanner actions. It serves as an audit trail and will clear automatically as clean daily scans run."
On why the "Malware cleaned" warning stays up after the case is closed · 08/08/2026, 07:13 CEST"To be completely direct with you: a vendor-level or publisher-level allowlisting program is not currently planned or under active policy review. [...] Policy ownership: Infrastructure & Security owns security policy, and their current framework strictly uses hash-based allowlisting."
On whether a vendor-level allowlist is even planned: no, and no one owns changing that · 08/08/2026, 07:27 CESTBefore a human ever entered the conversation, the AI support assistant ("Kodee") was asked to explain the detection. It first claimed the two flagged files had "different SHA-256 hashes," implying it had compared real hash records.
Two messages later, asked whether the detection was caused by a scanner-side signature update, the same assistant said the available records contained no hash data at all to compare. Both statements cannot be true. Read the exchange below, unedited.
[Kodee] I found the following account-level facts: [...] They have different SHA-256 hashes, so the scanner evaluated two distinct file contents. Both were classified as malicious and quarantined, not cleaned.[Kodee] I cannot confirm a Monarx ruleset update at August 7, 2026, 18:25 CEST. The available scanner records contain no engine version, signature ID, heuristic name, matched function, or before/after file hash, so they also cannot prove this was scanner-side rather than file-side.[Kodee] 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.A support layer built to sound confident before it has checked whether it can be will produce exactly this: two answers that cancel each other out, three minutes apart. The customer caught the contradiction himself and had to demand a human before anyone with real log access got involved.
Every point below is a confirmed, written-down fact about how the system is designed to behave, every time, for anyone hosting custom software on this infrastructure. None of it is opinion.
Every point below is a standard practice already used elsewhere in the security industry. None of it is exotic or expensive to build.
One broken file is the smallest part of this. The real story is what happens the moment your product looks, structurally, like the thing security software is trained to fear.
Any custom tool that manages files, uploads content, edits code live, or executes commands on a server, exactly the kind of functionality countless developers build for their own admin panels, matches the heuristic signature of a web shell closely enough that an automated scanner cannot always tell the difference. The gap between "legitimate internal tool" and "malicious backdoor" can be zero at the code level.
That alone would just be a hard technical problem. What turns it into a structural one is how the response is built around that uncertainty: destroy first, in milliseconds, with no snapshot, no holding state, and no way for the actual owner of the file to weigh in before it is gone.
The dashboard shows "Backups: Daily" as if that settles the matter. It does not. A daily backup is a single snapshot at a fixed point in time, usually early morning. Any work done after that snapshot and before an incident has no safety net at all, and the scanner has zero awareness of when the last backup ran when it decides to act.
A developer actively working on a critical file, which is the exact situation here, can lose hours or days of recent work regardless of having "daily backup" turned on, simply because the hosting provider's backup policy and the scanner's security policy were never designed to talk to each other.
The severity here did not stay flat. It escalated with every answer. What first looked like one file wrongly deleted turned out to be a mass scan applied identically to every hosted account, regardless of how old or how recently modified each file was.
Then it turned out the "safety net" of daily backups has a built-in gap that covers almost nobody who works daily on their own files. Then it turned out the allowlist offered as the fix breaks on the very next code change, protecting a version of the file rather than the product. Then it turned out there is no proactive path at all, only a reactive one: submit a hash after you've already been burned, and hope the next signature update doesn't burn you again.
Nobody at Hostinger set out to destroy a customer's product; bad intent isn't the problem here. The problem is a security model that, by design, cannot reliably tell the difference between actively developed legitimate software and a threat, and that has no structural mechanism to fix that over the long term, only case-by-case cleanup after the fact.
The clearest written admission of that came late in the thread, from a human agent, in plain language: this represents an ongoing operational risk for the customer's software distribution model. Not a one-time inconvenience. An ongoing risk, acknowledged in writing, with no fix planned.
For a junior developer reading this: the lesson is not "don't build admin tools." It's that any file manager, upload handler, or command runner you build, even fully authenticated and access-controlled, needs a plan for what happens if your host's automated security ever decides it looks suspicious, because "it's legitimate" is not a defense a scanner understands.
For a senior developer or a technical lead evaluating hosting providers: ask, before you sign anything, what your provider's automated security does the moment it flags one of your files. Ask if there's a holding state. Ask if there's a snapshot before deletion. Ask what remediation looks like for a confirmed false positive. "We'll truncate it and you can restore from your own backup" is a liability you'd be accepting on behalf of every product you host there, dressed up as a feature.
These clauses come directly from Hostinger's own publicly published Universal Terms of Service Agreement and Hosting Agreement. None of them are unusual for a hosting provider on their own, but together they show exactly how much of the risk sits on the customer's side by default.
Source: Hostinger's Universal Terms of Service Agreement and Hosting Agreement, publicly published, current as of this writing.
The two points below aren't from the support chat. They come from Hostinger's own public legal filings and published policies, and they contradict, in writing, the very basis this case was built on.
Sources: Hostinger's EU Digital Services Act Transparency Report 2024–2025 (public filing, reporting period 17 Feb 2024 – 16 Feb 2025, published 30 May 2025) and Hostinger's published Abuse Handling Policy (hostinger.com/legal/abuse-policy), both current as of this writing.