DEL IV: BEVARING, KILDEKODEFORVARING OG EN NY WHITELIST-PROCES
Korrespondancen den 15. september om bevaringsstatus, den fornyede bevaringsanmodning, spørgsmål om kildekodeforvaring, den foreslåede formelle whitelist-gennemgang og Hostingers senere udsagn om, at yderligere kildekodedeling ikke var nødvendig, mens disse spørgsmål fortsat var uafklarede.
Den 15. september blev et særskilt ansvarlighedskapitel, fordi korrespondancen bevægede sig ud over selve hændelsen den 10. september og over i verificeret bevaringsstatus, tidligere og foreslået forvaring af kildekode og en nyligt beskrevet whitelist-gennemgang.
12.20 — Hostinger gentog den platformdækkende politik
Customer Success oplyste, at den automatiske scannerpolitik for selvstændige PHP-filadministratorer var ensartet og platformdækkende, at nye detektioner af samme filtype var omfattet af samme politik, og at positionen var uændret. Svaret besvarede ikke det konkrete spørgsmål om, hvorvidt et bevaringshold faktisk var blevet anvendt på registreringerne eller objektet fra 10. september.
13.08 — Bevaringsspørgsmålet blev reduceret til Ja eller Nej
Opfølgningen bad Hostinger bekræfte alene, om den anmodede bevarings- eller opbevaringsforanstaltning faktisk var blevet anvendt. Ved ja blev der bedt om tidspunkt, intern reference og bekræftelse af fortsat opbevaring. Ved nej blev der bedt om den aktuelle eksistens og eventuel udløbs- eller slettestatus for et bevaret original- eller karantæneobjekt.
13.33 — Holdet stadig ubekræftet; en ny whitelist-proces blev foreslået
Hostinger oplyste, at det endnu ikke kunne bekræfte, om et bevaringshold var anvendt på registreringerne for detektionshændelsen den 10. september eller på det oprindelige/karantænerede manager.php-objekt, og lovede et verificeret Ja/Nej-svar efter intern verifikation.
Samme besked angav Hostingers aktuelle politik om, at kundeinitierede bevaringsanmodninger ikke automatisk udløser et hold, og bad om den fulde manager.php-kildekode via pwpush.com til en “formal whitelist review”, beskrevet som adskilt fra den platformdækkende Imunify-politik. Publikationen gengiver dette som Hostingers beskrevne politik og proces, ikke som en selvstændig juridisk konklusion.
14.39 — Bevaringen blev fornyet, og en ny kildekodedelingskæde blev afvist indtil svar om forvaring
Kunden fornyede og videreførte udtrykkeligt bevaringsanmodningen og oplyste, at endnu en komplet kopi af proprietær kildekode ikke ville blive sendt, før forvaring, formål, modtagere, adgangskontrol, opbevaring og disposition for den foreslåede deling var defineret skriftligt.
Beskeden præciserede udtrykkeligt, at dette ikke var et afslag på en korrekt afgrænset uafhængig teknisk gennemgang, og bad om den nye whitelist-beskrivelse afstemt med den tidligere position om, at der ikke fandtes en whitelist-undtagelsesvej for kategorien.
14.48 — Yderligere kildekodedeling var ikke nødvendig, mens forvaringsspørgsmål var uafklarede
Hostinger bekræftede den fornyede bevaringsanmodning og oplyste, at det fortsat ikke kunne give et verificeret Ja/Nej-svar om, hvorvidt et bevarings- eller opbevaringshold var anvendt. Hostinger oplyste også, at det ikke ansvarligt kunne bekræfte eksistens, udløb, slettestatus eller opbevaringsperiode for de relevante registreringer uden at færdiggøre den interne verifikation.
Hostinger oplyste derefter, at yderligere deling af kildekode ikke var nødvendig, mens spørgsmål om forvaring, formål, modtagere, adgangskontrol, opbevaring og disposition fortsat var uafklarede. Hostinger oplyste også, at det næste skriftlige svar skulle afstemme den kategoribaserede klassifikation, den foreslåede whitelist-gennemgang, dens kompetence og mulige resultat samt den præcise filversionsidentitet.
Hostinger forpligtede sig til ikke at beskrive en senere eller aktuel fil som objektet fra hændelsen den 10. september.
Hvad der fortsat var uafklaret ved det redaktionelle cutoff
Pr. 15. september 2026 kl. 14.48 CEST var det verificerede bevaringssvar fortsat udestående. Hostinger havde endnu ikke bekræftet, om holdet faktisk var anvendt, eller eksistens, udløb, slettestatus eller opbevaringsperiode for de relevante registreringer eller det oprindelige/karantænerede objekt. Den lovede afstemning af whitelist-processen, dens kompetence og mulige resultat samt de resterende spørgsmål om kildekodeforvaring var også fortsat udestående.