manager.php este un file manager PHP construit intern, protejat prin parolă, autentificat prin sesiune. Nu e public. Nu e un script luat de pe un forum. A fost construit și întreținut ca panou de administrare intern pentru un produs comercial, folosit zilnic timp de luni de zile, fără niciun avertisment de securitate până în acel moment.
Pe 7 august 2026, la ora 18:25 CEST, scannerul de malware al Hostinger (Monarx) a marcat manager.php drept Malicious pe două conturi de hosting fără legătură între ele, exact în același moment: acest site, tyrus.dk, unde fișierul era activ dezvoltat, și un cont client, fără legătură, unde același fișier stătea neschimbat de peste șase săptămâni. Ambele copii au fost trunchiate automat la 0 bytes. Fără avertisment, fără carantină, fără backup dedicat înainte de acțiune.
Rezultatul a fost un panou de administrare gol, un produs stricat, și un client care a aflat întâmplător a doua zi dimineață, nu pentru că a fost notificat cineva.
Fiecare oră de mai jos vine direct din log-urile hPanel și din transcript-urile chat-ului de suport, păstrate exact așa cum au fost primite.
Tot ce urmează în această secțiune e citat exact așa cum a fost scris de echipa Hostinger, în chat-ul de suport. Fără editare, fără interpretare. Citește-le în ordine și imaginea se construiește singură.
"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."
Despre motivul detecției · 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."
Despre procesul de trunchiere, fără backup, prin 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."
Recunoașterea care închide cazul: a fost un scan în masă, nu o decizie per-fișier · 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."
Despre motivul pentru care nu există stare de carantină, doar distrugere-întâi · 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."
Despre compensație pentru fals-pozitive confirmate: niciuna · 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."
Despre dacă propriul lor "backup zilnic" ar fi ajutat exact în acest caz: nu, ar fi salvat fișierul deja gol · 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."
Despre motivul pentru care avertismentul "Malware cleaned" rămâne vizibil după închiderea cazului · 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."
Despre existența unui plan de allowlisting la nivel de vendor: nu, și nimeni nu răspunde de schimbarea asta · 08.08.2026, 07:27 CESTÎnainte ca un om să intre în conversație, asistentul AI de suport ("Kodee") a fost întrebat să explice detecția. La început a susținut că cele două fișiere marcate aveau "different SHA-256 hashes", sugerând că a comparat înregistrări reale de hash.
Două mesaje mai târziu, întrebat dacă detecția a fost cauzată de un update de semnătură pe partea scannerului, același asistent a spus că înregistrările disponibile nu conțineau deloc date de hash de comparat. Ambele afirmații nu pot fi adevărate simultan. Citește schimbul de mai jos, needitat.
[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.Un strat de suport construit să sune încrezător înainte de a verifica dacă poate fi va produce exact asta: două răspunsuri care se anulează reciproc, la trei minute distanță. Clientul a prins singur contradicția și a trebuit să ceară un om, înainte ca cineva cu acces real la log-uri să se implice.
Fiecare punct de mai jos e un fapt confirmat, scris, despre cum e proiectat sistemul să se comporte, de fiecare dată, pentru oricine găzduiește software custom pe această infrastructură. Nimic din asta nu e opinie.
Fiecare punct de mai jos e o practică standard, deja folosită în altă parte în industria de securitate. Nimic din asta nu e exotic sau scump de construit.
Un fișier stricat e partea cea mai mică din toată povestea asta. Miezul e ce se întâmplă în momentul în care produsul tău arată, structural, ca lucrul de care software-ul de securitate e antrenat să se teamă.
Orice instrument custom care administrează fișiere, primește upload de conținut, editează cod live, sau execută comenzi pe un server, exact tipul de funcționalitate pe care nenumărați dezvoltatori o construiesc pentru propriile panouri de administrare, se potrivește heuristic cu semnătura unui web shell suficient de mult încât un scanner automat nu poate face mereu diferența. Diferența dintre "instrument intern legitim" și "backdoor malițios" poate fi zero la nivel de cod.
Asta singură ar fi doar o problemă tehnică grea. Ce o transformă într-o problemă structurală e felul în care e construit răspunsul în jurul acestei incertitudini: distruge întâi, în milisecunde, fără snapshot, fără stare de așteptare, și fără nicio cale ca proprietarul real al fișierului să spună ceva înainte ca acesta să dispară.
Dashboard-ul afișează "Backups: Daily" de parcă asta ar rezolva problema. Nu o rezolvă. Un backup zilnic e o singură captură, la un moment fix, de obicei dimineața. Orice muncă făcută după acea captură și înainte de un incident nu are nicio plasă de siguranță, iar scannerul nu are nicio informație despre momentul ultimului backup atunci când decide să acționeze.
Un dezvoltator care lucrează activ la un fișier critic, exact situația de aici, poate pierde ore sau zile de muncă recentă, indiferent că are "backup zilnic" activat, pur și simplu pentru că politica de backup a providerului și politica de securitate a scannerului nu au fost gândite niciodată să comunice între ele.
Gravitatea aici nu a rămas constantă. A escaladat cu fiecare răspuns. Ce părea la început un fișier șters greșit s-a dovedit a fi un scan în masă, aplicat identic pe fiecare cont găzduit, indiferent cât de vechi sau cât de recent modificat era fiecare fișier.
Apoi s-a dovedit că "plasa de siguranță" a backup-urilor zilnice are o gaură integrată, care nu acoperă aproape pe nimeni care lucrează zilnic la propriile fișiere. Apoi s-a dovedit că allowlist-ul oferit ca soluție se rupe la următoarea modificare de cod, protejând o versiune a fișierului, nu produsul. Apoi s-a dovedit că nu există absolut nicio cale proactivă, doar una reactivă: trimiți un hash după ce ai fost deja ars, și speri că următorul update de semnătură nu te arde din nou.
Nimeni de la Hostinger nu și-a propus să distrugă produsul unui client; rea-voința nu e problema aici. Problema e un model de securitate care, prin design, nu poate distinge fiabil între software legitim activ dezvoltat și o amenințare, și care nu are niciun mecanism structural s-o rezolve pe termen lung, doar reparații de la caz la caz, după fapt.
Cea mai clară recunoaștere scrisă a asta a venit spre finalul firului, de la un agent uman, în cuvinte simple: reprezintă un risc operațional continuu pentru modelul de distribuție software al clientului. Nu un inconvenient de moment. Un risc continuu, recunoscut în scris, fără nicio soluție planificată.
Pentru un dezvoltator junior care citește asta: lecția nu e "nu construi instrumente de administrare". E că orice file manager, handler de upload, sau executor de comenzi pe care îl construiești, chiar complet autentificat și cu acces controlat, are nevoie de un plan pentru ce se întâmplă dacă securitatea automată a hostului tău decide vreodată că arată suspect, pentru că "e legitim" nu e o apărare pe care un scanner o înțelege.
Pentru un dezvoltator senior sau un lead tehnic care evaluează furnizori de hosting: întreabă, înainte să semnezi orice, ce face securitatea automată a providerului tău în momentul în care marchează unul dintre fișierele tale. Întreabă dacă există o stare de așteptare. Întreabă dacă există un snapshot înainte de ștergere. Întreabă cum arată remedierea pentru un fals-pozitiv confirmat. "Îl trunchiem și tu restaurezi din propriul backup" e o răspundere pe care ți-o asumi în numele fiecărui produs pe care îl găzduiești acolo, deghizată în funcție.
Aceste clauze provin direct din Universal Terms of Service Agreement și Hosting Agreement ale Hostinger, ambele publicate public. Niciuna nu e neobișnuită pentru un furnizor de hosting, luată separat, dar împreună arată exact cât de multă răspundere stă, implicit, pe partea clientului.
Sursă: Universal Terms of Service Agreement și Hosting Agreement ale Hostinger, publicate public, valabile la data redactării.
Cele două puncte de mai jos nu vin din chat-ul de suport. Vin din propriile raportări legale publice ale Hostinger și din politicile lor publicate, și contrazic, în scris, chiar temelia pe care s-a construit acest caz.
Surse: Raportul de transparență Digital Services Act al UE al Hostinger 2024–2025 (raportare publică, perioada 17 februarie 2024 – 16 februarie 2025, publicat pe 30 mai 2025) și Politica de gestionare a abuzurilor publicată de Hostinger (hostinger.com/legal/abuse-policy), ambele valabile la data redactării.