Kort sagt: Cybersäkerheten i medelstora företag stupar vid PHP2Shell sällan på patchandet utan på överblicken. Vid sidan av webbplatsen körs återförsäljarportaler, konfiguratorer, karriärsidor och interna wikier hos olika leverantörer. Först en fullständig förteckning gör risken hanterbar och möjlig att styrka inför kunder och tillsyn.
Typiska PHP-system i medelstora företag
Under åren samlas många webbaserade applikationer i tillverkande företag: B2B-butiker för reservdelar, återförsäljar- och partnerportaler med prislistor, produktkonfiguratorer, nedladdningsområden för teknisk dokumentation och CAD-data, reklamations- och serviceportaler, karriärsidor med rekryteringshantering. Internt tillkommer wikier som MediaWiki, ärendeverktyg och webbanalys.
En stor del av detta körs på PHP. Systemen beställdes ofta av fackavdelningar, byggdes av byråer och drivs hos webbhotell som den centrala IT:n inte känner till. Just där ligger vid en sårbarhet som PHP2Shell det egentliga problemet.
Vilka uppgifter och förbindelser som kan beröras
I portaler finns kundvillkor, kontaktpersoner hos återförsäljare, offert- och orderdata samt ritningar som omfattas av sekretessavtal. Rekryteringsportaler innehåller CV och betyg. För konkurrenter och utpressare är konstruktionsdata och prisstrukturer ofta värdefullare än personuppgifter.
Kritiska är förbindelserna: Många portaler utbyter data med ERP, affärssystem eller PIM. Den som kör kod på en sådan webbserver hittar där inloggningsuppgifter till gränssnitt, databaser eller VPN. En komprometterad portal kan på så sätt bli ingången till företagsnätet.
Medelstora företag och cybersäkerhet: leveranskedja och NIS2
Med NIS2 gäller för många företag utökade skyldigheter för riskhantering och rapportering av betydande säkerhetsincidenter. Om ert företag omfattas direkt beror på sektor och storlek. Indirekt berörs betydligt fler, eftersom kunder för vidare säkerhetskrav till sina leverantörer via avtal.
För företagsledningen tillkommer frågan om det egna ansvaret. Vad som allmänt gäller förklarar sidan om ledningens ansvar. Bedömningen i det enskilda fallet hör till er juridiska rådgivning.
Palo Alto Networks (Unit 42) räknade fler än 22,6 miljoner exponerade, potentiellt sårbara instanser. Ett bortglömt testsystem hos en byrå syns för automatiserade skanningar lika väl som er huvudwebbplats.
Det typiska ansvarsglappet i medelstora företag
| Område | Vem som ofta bestämmer | Vad som saknas |
|---|---|---|
| Företagets webbplats | Marknadsföring med byrå | Patchunderlag för PHP |
| Återförsäljarportal, B2B-butik | Försäljning med leverantör | Inordning i IT-säkerhetskonceptet |
| Karriärsida | Personal med leverantör | Klarhet om hosting och uppgifter |
| Interna verktyg | enskilda avdelningar | Inventering och ansvariga |
Den centrala IT:n ansvarar för nät, arbetsplatser och ERP men saknar ofta åtkomst till externt hostade system. Det mönstret blir en flaskhals vid varje kritisk sårbarhet. Avhjälp ger en enkel regel: Varje webbapplikation som behandlar företagsuppgifter anmäls till IT med driftansvarig och kontaktperson innan den går live.
Skilj webbserver och produktionsnät på ett rent sätt
I industrin tillkommer webbapplikationer som talar med maskiner och anläggningar: service- och fjärrunderhållsportaler, dashboards med maskindata, portaler för kunder som hämtar status för sina levererade anläggningar. Vissa av dem är byggda på PHP och står i ett nätområde som har fler förbindelser än vad uppgiften kräver.
En komprometterad webbserver får inte vara en språngbräda in i produktionen. Kontrollera vilka förbindelser som finns från webbservrarnas nätområden till kontors- och produktionsnät och begränsa dem till det nödvändiga. Lagrade inloggningsuppgifter på webbservrar bör bara ha de rättigheter som applikationen verkligen behöver. För fjärrunderhållsåtkomster gäller det särskilt.
De första timmarna för IT-chef och ledning
- Upprätta en förteckning över alla externt nåbara PHP-system: domän, driftansvarig, PHP-version, driftläge, kontaktperson.
- Behandla system med mod_php och sådana på PHP 8.1 eller äldre först. Vid mod_php bedömer PHP-teamet risken som högst.
- Låt för varje system patch till 8.5.12, 8.4.27, 8.3.36 eller 8.2.35 respektive backport och omstart bekräftas skriftligen. Det som inte kan bekräftas tas tillfälligt offline.
- Säkra loggar från och med den 20 oktober 2026 och kontrollera webbservrarnas förbindelser in i det interna nätet.
- Dokumentera läget kortfattat så att ni kan svara kunder, försäkringsgivare och vid behov myndigheter på ett belagt sätt.
Hur hjälper PHP SOS konkret?
- Vi upprättar tillsammans med IT och fackavdelningar förteckningen över PHP-systemen och prioriterar efter risk.
- Vi samordnar patchar och omstarter med byråer och webbhotell och samlar underlagen på ett ställe.
- Vid misstanke tar vi över den strukturerade incidenthanteringen med spårsäkring och kontroll av förbindelserna in i företagsnätet.
- Därefter erbjuder vi en säkerhetsgranskning eller ett penetrationstest av specialiserade partner, vars resultat ni kan lägga fram för kunder.
- På begäran övervakar vi systemen löpande så att förteckningen förblir aktuell.
Vanliga frågor
Omfattas vårt företag av NIS2?
Det beror på sektor, företagsstorlek och omsättning och ska prövas i det enskilda fallet. Även den som inte direkt omfattas av NIS2 märker ofta kraven via kunder i leveranskedjan. Den bindande bedömningen klarar ni ut med er juridiska rådgivning.
Kan en hackad webbserver leda in i företagsnätet?
Det är möjligt om webbservern har förbindelser in i det interna nätet, till exempel gränssnitt mot ERP, gemensamma inloggningsuppgifter eller en VPN-tunnel. Om så är fallet hos er visar en granskning av nätverksförbindelserna och lagrade inloggningsuppgifter.
Hur hittar vi alla PHP-applikationer i företaget?
Utgångspunkt är DNS-poster, certifikat, hostingfakturor och avtal med byråer. Kompletterande hjälper intervjuer i marknadsföring, försäljning, service och personal. Oftast dyker då system upp som IT-avdelningen inte ens kände till.
Vad förväntar sig kunderna av oss som leverantör efter PHP2Shell?
Vissa kunder frågar aktivt om deras leverantörer var berörda och hur de reagerade. Till hjälp är en kortfattad, belagd redogörelse: vilka system, vilken patchnivå, när omstart skedde, vilka kontroller av kompromettering som gjorts. Att lova mer än det som är belagt skadar.