manager.php er en brugerdefineret, adgangskodebeskyttet, sessionsautentificeret PHP-filhåndtering. Den er ikke offentlig. Den er ikke et script hentet fra et forum. Den blev bygget og vedligeholdt som internt admin-værktøj til et kommercielt produkt, brugt dagligt i månedsvis uden en eneste sikkerhedsmarkering imod den.
Den 7. august 2026 kl. 18:25 CEST markerede Hostingers malware-scanner (Monarx) manager.php som Malicious på to urelaterede hostingkonti på nøjagtig samme tidspunkt: denne side, tyrus.dk, hvor filen var under aktiv udvikling, og en anden, urelateret kundekonto, hvor den samme fil havde ligget uændret i over seks uger. Begge kopier blev automatisk tømt til 0 bytes. Ingen advarsel, ingen karantæne, ingen isoleret backup før handlingen.
Resultatet var et tomt admin-panel, et ødelagt produkt, og en kunde der opdagede det ved et tilfælde næste morgen, ikke fordi nogen blev underrettet.
Hvert tidspunkt nedenfor kommer direkte fra hPanel-logs og live chat-transskriptioner fra support, gengivet nøjagtigt som modtaget.
Alt i dette afsnit er citeret nøjagtigt, som det blev skrevet af Hostingers medarbejdere i support-chatten. Ingen redigering, ingen fortolkning. Læs dem i rækkefølge, og billedet tegner sig selv.
"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."
Om hvorfor detektionen skete · 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."
Om selve tømningsprocessen, ingen backup, per 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."
Indrømmelsen der lukker sagen: dette var et masse-scan, ikke en fil-for-fil-beslutning · 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."
Om hvorfor der ikke findes en karantænetilstand, kun 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."
Om kompensation for bekræftede falske positiver: ingen · 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."
Om hvorvidt deres egen "daglige backup" ville have hjulpet i netop dette tilfælde: nej, den ville have gemt den tomme fil · 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."
Om hvorfor advarslen "Malware cleaned" bliver stående, efter sagen er lukket · 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."
Om hvorvidt en leverandørbaseret allowlist overhovedet er planlagt: nej, og ingen har ansvaret for at ændre det · 08.08.2026, 07:27 CESTFør et menneske overhovedet trådte ind i samtalen, blev AI-supportassistenten ("Kodee") bedt om at forklare detektionen. Den påstod først, at de to markerede filer havde "different SHA-256 hashes", hvilket antydede at den havde sammenlignet reelle hash-data.
To beskeder senere, adspurgt om detektionen skyldtes en signaturopdatering på scanner-siden, sagde den samme assistent, at de tilgængelige data slet ikke indeholdt hash-oplysninger at sammenligne. Begge udsagn kan ikke være sande samtidig. Læs udvekslingen nedenfor, uredigeret.
[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.Et supportlag bygget til at lyde selvsikkert, før det har tjekket om det kan være det, producerer præcis dette: to svar, der ophæver hinanden, tre minutter fra hinanden. Kunden opdagede selv modsigelsen og måtte kræve et menneske, før nogen med reel logadgang blev involveret.
Hvert punkt nedenfor er et bekræftet, skriftligt dokumenteret faktum om, hvordan systemet er designet til at opføre sig, hver gang, for enhver der hoster brugerdefineret software på denne infrastruktur. Intet af det er en mening.
Hvert punkt nedenfor er en standardpraksis, der allerede bruges andre steder i sikkerhedsindustrien. Intet af det er eksotisk eller dyrt at bygge.
Én ødelagt fil er den mindste del af det her. Kernen er, hvad der sker i det øjeblik, dit produkt strukturelt ligner det, sikkerhedssoftware er trænet til at frygte.
Ethvert brugerdefineret værktøj, der håndterer filer, tager imod uploads, redigerer kode live, eller eksekverer kommandoer på en server, altså præcis den type funktionalitet utallige udviklere bygger til deres egne admin-paneler, matcher heuristisk signaturen på en web shell tæt nok til, at en automatiseret scanner ikke altid kan se forskellen. Forskellen mellem "legitimt internt værktøj" og "ondsindet bagdør" kan være nul på kodeniveau.
Det alene ville bare være et svært teknisk problem. Det, der gør det til et strukturelt problem, er, hvordan reaktionen er bygget op omkring den usikkerhed: ødelæg først, på millisekunder, uden øjebliksbillede, uden holdingtilstand, og uden nogen mulighed for at filens reelle ejer kan sige noget, før den er væk.
Dashboardet viser "Backups: Daily", som om det løser sagen. Det gør det ikke. En daglig backup er ét øjebliksbillede på et fast tidspunkt, normalt tidlig morgen. Alt arbejde udført efter det øjebliksbillede og før en hændelse har intet sikkerhedsnet overhovedet, og scanneren har ingen viden om, hvornår sidste backup kørte, når den beslutter sig for at handle.
En udvikler, der aktivt arbejder på en kritisk fil, hvilket er præcis situationen her, kan miste timer eller dages nyligt arbejde, uanset om "daglig backup" er slået til, simpelthen fordi hostingudbyderens backup-politik og scannerens sikkerhedspolitik aldrig var designet til at tale sammen.
Alvoren her forblev ikke uændret. Den eskalerede med hvert svar. Det, der først lignede én forkert slettet fil, viste sig at være et masse-scan, anvendt identisk på hver hostet konto, uanset hvor gammel eller hvor nyligt ændret hver fil var.
Så viste det sig, at "sikkerhedsnettet" fra daglige backups har et indbygget hul, som næsten ikke dækker nogen, der arbejder dagligt på sine egne filer. Så viste det sig, at den tilbudte allowlist-løsning bryder ved den næste kodeændring, og beskytter en version af filen, ikke produktet. Så viste det sig, at der slet ikke findes en proaktiv vej, kun en reaktiv: du indsender et hash, efter du allerede er blevet brændt, og håber det næste signatur-opdatering ikke brænder dig igen.
Ingen hos Hostinger satte sig for at ødelægge en kundes produkt; ond vilje er ikke problemet her. Problemet er en sikkerhedsmodel, der per design ikke pålideligt kan skelne mellem aktivt udviklet legitim software og en trussel, og som ikke har nogen strukturel mekanisme til at løse det på lang sigt, kun oprydning fra sag til sag, efter fakta.
Den klareste skriftlige indrømmelse af det kom sent i tråden, fra en menneskelig agent, i klart sprog: det udgør en løbende operationel risiko for kundens softwaredistributionsmodel. Ikke en engangsulejlighed. En løbende risiko, anerkendt skriftligt, uden nogen planlagt løsning.
For en junior-udvikler, der læser dette: lektien er ikke "byg ikke admin-værktøjer". Det er, at enhver filhåndtering, upload-behandler eller kommando-eksekvering, du bygger, selv fuldt autentificeret og adgangskontrolleret, har brug for en plan for, hvad der sker, hvis din hosts automatiserede sikkerhed nogensinde beslutter, at den ser mistænkelig ud, fordi "det er legitimt" ikke er et forsvar, en scanner forstår.
For en senior-udvikler eller en teknisk leder, der evaluerer hostingudbydere: spørg, før du underskriver noget, hvad din udbyders automatiserede sikkerhed gør i det øjeblik, den markerer en af dine filer. Spørg om der findes en holdingtilstand. Spørg om der tages et øjebliksbillede før sletning. Spørg hvordan afhjælpning ser ud ved en bekræftet falsk positiv. "Vi tømmer den, og du gendanner fra din egen backup" er en hæftelse, du ville acceptere på vegne af hvert eneste produkt, du hoster der, udklædt som en funktion.
Disse klausuler kommer direkte fra Hostingers egne, offentligt publicerede Universal Terms of Service Agreement og Hosting Agreement. Ingen af dem er usædvanlige for en hostingudbyder isoleret set, men tilsammen viser de præcis, hvor meget af risikoen der som udgangspunkt ligger hos kunden.
Kilde: Hostingers Universal Terms of Service Agreement og Hosting Agreement, offentligt publicerede, gældende på skrivetidspunktet.
De to punkter nedenfor kommer ikke fra support-chatten. De kommer fra Hostingers egne offentlige juridiske indberetninger og publicerede politikker, og de modsiger, skriftligt, selve grundlaget denne sag er bygget på.
Kilder: Hostingers EU Digital Services Act-transparensrapport 2024–2025 (offentlig indberetning, rapporteringsperiode 17. februar 2024 – 16. februar 2025, offentliggjort 30. maj 2025) og Hostingers publicerede Abuse Handling Policy (hostinger.com/legal/abuse-policy), begge gældende på skrivetidspunktet.