# Bureau: Kundesider hacket? Ring til os. Vi hjælper. > Flere kundesider hos jeres bureau berørt? Ring til os eller skriv til os på WhatsApp. Vi sikrer, renser og dokumenterer det hele på afstand. Kilde: https://phpsos.de/da/soforthilfe/agentur-kundenseiten-gehackt/ Status: 25.10.2026 Udbyder: PHP SOS, PHP-nødhjælp og serversikkerhed. Akut hjælp på WhatsApp: https://wa.me/491736494914?text=Hej%20PHP%20SOS%2C%20vi%20har%20brug%20for%20hj%C3%A6lp%20med%20vores%20PHP-server.%20Firma%3A%20%E2%80%A6%20Website%3A%20%E2%80%A6 **Kort sagt:** Er der flere kundesider berørt hos jeres bureau, er det sjældent tilfældigt, men som regel en fælles server, en delt adgang eller den samme PHP-version. Er I berørt, så kontakt os med det samme. Vi skaffer jer et overblik, inddæmmer hændelsen på afstand, renser systemerne og leverer jer rapporter til jeres kunder. > **Handl med det samme:** > **Slet intet og opsæt intet på ny nu.** Også selv om presset fra kunderne er stort: Uden sikrede logs og filer kan hverken årsagen afklares eller bevises, hvad der ikke var berørt. [Meld en nødsituation](https://phpsos.de/da/notfall/), så overtager vi fra den første besked. ## Er I berørt? Tegn, når kundesider er blevet hacket Som bureau ser I mønstre, som enkeltdriftsansvarlige aldrig bemærker. På en fælles hændelse peger: - Flere kundesider viser samtidig de samme symptomer: omdirigeringer, spamindhold, advarsler i browseren. - Den samme ukendte admin-konto eller den samme mistænkelige fil dukker op hos forskellige kunder. - Hostingudbyderen melder misbrug eller påfaldende belastning for en konto, hvorpå der ligger mange projekter. - Kunder ringer, fordi deres side advares mod hos Google, og ved modkontrol finder I flere sider i samme tilstand. - En udvikler eller tidligere medarbejder havde adgang til mange projekter, og en adgang er kommet ud. - Vedligeholdelsesarbejde via et centralt værktøj, for eksempel deployment, backups eller en opdateringstjeneste, har ændret en side, som I ikke har rørt. - I driver mange sider på PHP-versioner, hvis patch-status I ikke kan dokumentere for hver enkelt. Siden PHP2Shell er der kommet det til, at sårbarheden ligger i selve PHP-fortolkeren. En CMS-opdatering, for eksempel ved WordPress, lukker den ikke; afgørende er den PHP-runtime, der faktisk leverer. ## Hvad I gør med det samme 1. **List de berørte sider:** Domæne, server, hostingkonto, PHP-version, CMS, ansvarlige. Også mistænkte tilfælde hører med. 2. **Find fællestræk:** Samme server? Samme adgange? Samme plugin? Samme deployment-vej? 3. **Afskærm udsatte sider:** Sæt sider, der aktivt leverer skadelig kode, i vedligeholdelsestilstand. Slet ikke. 4. **Få logs og tilstand sikret:** Bed hostingudbyderen om at bevare protokoller; sikr egne deployment-protokoller. 5. **Kontrollér centrale adgange:** Hvem har adgang til hostingpanel, SSH, Git, adgangskodemanager og deployment? Ændringer først efter aftale. 6. **Informér kunder tilbageholdende:** Først kun det, der er dokumenteret. Nævn ingen årsag, før den står fast. 7. **Kontakt os:** Ring til os eller skriv på WhatsApp. ## Hvordan hjælper PHP SOS konkret? 1. **Danne overblik over situationen:** Vi skaffer sammen med jer et overblik over alle sider og servere og ordner dem efter hastegrad: aktivt leveret skadelig kode, mistanke om dataudsivning, formentlig kun upatchet. 2. **Sikre og lukke:** Vi sikrer hvert berørt system, før noget ændres, og lukker den fælles indgangsdør: adgange, PHP-version, genstart af alle processer. 3. **Kontrollere og rense:** Vi leder systematisk på tværs af alle sider efter de samme spor, fjerner webshells og bagdøre og genopretter rent. Detaljer under [Få malware og webshells fjernet](https://phpsos.de/da/leistungen/malware-entfernung/). 4. **Hærde og rapportere:** Vi adskiller sider fra hinanden, hvor det er fornuftigt, og leverer for hver kunde en kort rapport, som I kan give videre, samt en samlet rapport til jer. Vi arbejder på afstand, uden transport, i hele Tyskland og Europa. På ønske i baggrunden for jeres bureau, som beskrevet på siden [Bureauer og white label](https://phpsos.de/da/branchen/agenturen-white-label/). ## Hvorfor der hos bureauer ofte falder mange sider på én gang Den, der driver mange projekter på én server, sparer omkostninger, men bytter isolation for bekvemmelighed. Kører alt under samme bruger og samme PHP-procespool, kan koden fra en hacket side læse og ændre naboernes filer. Det er ikke noget eksotisk tilfælde, men standard i mange konfigurationer. Hvordan pools kan adskilles rent, beskriver [Isolér PHP-FPM-pools](https://phpsos.de/da/blog/php-fpm-pools-isolieren/). Dertil kommer delte adgange: én SSH-nøgle til alle projekter, en hostingkonto med alle domæner, de samme adgangskoder til staging og produktion. Her gælder princippet om mindste rettigheder. Mere herom i [Webserverbrugerens rettigheder](https://phpsos.de/da/blog/rechte-des-webserver-benutzers/). Også leverandørkæden tæller: Plugins, temaer og biblioteker kommer fra tredjemand, hostingudbyderen er ansvarlig for platformen, bureauet for driften. Hvor disse grænser går, og hvor der opstår huller, behandler [Leverandørkæden bureau og hostingudbyder](https://phpsos.de/da/blog/lieferkette-agentur-hoster/). ## Oversigt, PHP-versioner og kommunikation med kunder Det hyppigste problem i sådanne situationer er manglende overblik: Hvilken side kører på hvilken server med hvilken PHP-version, og hvem er ansvarlig? Uden denne liste kan det ikke siges, hvem der er berørt af rettelsen, og hvem der ikke er. Hvordan I opbygger sådan et register, viser [Oversigt over websites og servere](https://phpsos.de/da/blog/inventar-websites-server/). Kører flere PHP-versioner parallelt, hjælper desuden [Flere PHP-versioner på én server](https://phpsos.de/da/blog/mehrere-php-versionen-server/). Over for kunderne tæller klarhed. I behøver ikke vide alt, men intet må forskønnes: Hvad er dokumenteret, hvad kontrolleres endnu, hvad gør I som det næste? Formuleringshjælp finder I under [Informér kunder efter en hændelse](https://phpsos.de/da/blog/kunden-nach-vorfall-informieren/). Er personoplysninger berørt, kan anmeldelsespligter efter art. 33 GDPR spille en rolle. Det er en generel oplysning; vurderingen hører til databeskyttelsesrådgiver og advokat. Vokser hændelsen ud over enkelte sider, går vi over til struktureret [incident response](https://phpsos.de/da/leistungen/incident-response/). ## Hvad I bør sende til os - en liste over de berørte og de formentlig berørte domæner - oplysninger om server og hosting for hvert projekt, så vidt kendt - PHP-versioner og anvendte CMS eller shops - de adgange, som I kan give os, og rollerne i teamet - oplysninger om, hvad der sidst blev ændret eller rullet ud - navn på kontaktpersonen til beslutninger samt til kundekommunikation ## Hvorfor PHP SOS Vi arbejder Made in Germany og har sammen med vores partnernetværk af cyberprofessionelle i over 25 år specialiseret os i it-sikkerhed. I har én kontaktperson til alle berørte projekter, vi arbejder på afstand og dokumenterer for hvert system, hvad der blev fundet og gjort. Vi lover ingen mirakler. Det, der ikke kan dokumenteres, kalder vi ukendt, så I over for jeres kunder ikke siger mere, end I ved. ## Er I berørt? Ring til os. Vi hjælper. Hvis flere af jeres kundesider er påfaldende, er tidspresset dobbelt: teknisk og i forholdet til jeres kunder. Kontakt os nu: Ring til os eller skriv på WhatsApp. Vi overtager fra den første besked og bliver ved, indtil hændelsen er afsluttet og dokumenteret. [Meld en nødsituation nu](https://phpsos.de/da/notfall/) ## Ofte stillede spørgsmål **Hvorfor er der ofte flere kundesider berørt på én gang?** Ofte deler siderne en server, en hostingkonto, den samme PHP-proces eller de samme adgangsdata. Kommer en angriber ind ét sted, kan han bevæge sig sidelæns. Et sårbart PHP berører desuden alle sider, der bruger det. **Skal jeg informere kunderne med det samme?** Det afhænger af situationen og af kontrakten. Afklar først, hvilke sider der virkelig er berørt, så I ikke informerer med formodninger. Ved personoplysninger er anmeldelsespligter mulige; vurderingen hører til databeskyttelsesrådgiver eller advokat. **Hvem hæfter, hvis en kundes side er blevet hacket?** Det afgøres efter jeres kontrakter, omfanget af driften og forløbet. Vi yder ikke juridisk rådgivning hertil. En ren rapport om årsag og foranstaltninger hjælper ved denne afklaring. **Kan I arbejde under vores navn, uden at slutkunden ser os?** På ønske arbejder vi i baggrunden for jeres bureau og leverer rapporter, som I kan give videre til jeres kunder. Enkeltheder drøfter vi på forhånd. **Er det nok at rense kundesiderne enkeltvis?** Som regel ikke. Ligger årsagen i den fælles server, i en delt adgang eller i en upatchet PHP-version, dukker problemerne op igen efter enkeltrensningen. Årsagen skal afhjælpes med. ## Kilder - [BSI: det tyske forbundsagentur for informationssikkerhed](https://www.bsi.bund.de/) - [GDPR art. 33: anmeldelse til tilsynsmyndigheden](https://dsgvo-gesetz.de/art-33-dsgvo/) - [php.net: meddelelser og sikkerhedsopdateringer](https://www.php.net/)