Säkerhetsuppdateringen den 17 september — installerades den på din sajt?

Releasen är en ren säkerhetsuppdatering och gick ut på hela bredden: 7.0.5 på den aktuella grenen, plus bakåtportade rättningar till 6.9.8, 6.8.9, 6.7.8 och vidare ned genom de äldre grenar som fortfarande underhålls. Det är den ordning WordPress-projektet normalt jobbar i, och den är värd att känna till: du behöver inte byta gren för att få säkerhetsrättningar, du behöver bara ligga på den senaste punktversionen av din egen.

Sju sårbarheter åtgärdades. Bland dem en preparerad URL som kunde installera och förhandsgranska ett tema från WordPress.org, ett lagrat XSS-problem i egna sidhuvudsbilder på vissa teman, ett informationsläckage som exponerade rubriken på ett privat föräldrainlägg, ett fel i HTML-API:t där ändrad text kunde bryta sig ut ur en HTML-kommentar, ett fel i multisite där en webbplatsadministratör kunde nätverksaktivera en plugin avsedd bara för nätverket, ett XML-RPC-fel där changeset-inlägg kunde kringgå behörighetskontrollen för egen CSS, samt att användare på bidragsgivarnivå kunde se webbadresser till utkast och inlägg som väntar på granskning.

Ingen av dem är den sortens sårbarhet som tar ned en sajt av sig själv. De flesta kräver att angriparen redan har ett konto på sajten, eller att ett visst tema används. Det gör dem inte ofarliga — en bidragsgivarinloggning är inte svår att komma över på en sajt med öppen registrering — men det är en annan hotbild än ett hål som går att utnyttja utifrån utan inloggning.

Här är den ärliga delen, och den talar emot vår egen kategori: WordPress installerar mindre uppdateringar och säkerhetsreleaser automatiskt sedan version 3.7. Det gäller oavsett om du betalar 74 kronor i månaden för ett vanligt webbhotell eller 499 för en managed-tjänst. Sannolikt fick din sajt rättningen natten till den 18 september utan att någon rörde ett finger, och WordPress formulering är att installationer hos leverantörer som möjliggör automatiska uppdateringar, och som är konfigurerade för dem, får uppdateringen automatiskt.

Det finns undantag som är värda att känna till. Automatiken kan vara avstängd med en konstant i wp-config.php, av en plugin som tagit över uppdateringshanteringen, eller av en leverantör som kör filsystemet skrivskyddat. Och den täcker bara kärnan. Har någon en gång stängt av den för att slippa en trasig uppdatering ligger den oftast kvar avstängd, för det är ingen som går tillbaka och kontrollerar.

Slutsatsen är att den som säljer managed WordPress på att kärnan hålls uppdaterad säljer något du redan har. Det är värt att säga rakt ut, eftersom det står i nästan varje funktionslista i kategorin.

Kärnan är inte den vanliga vägen in. Det som oftast blir en incident på en svensk WordPress-sajt är en plugin som inte uppdaterats, ett tema från en leverantör som slutat underhålla det, eller en tilläggsfunktion som installerades en gång för ett syfte som inte finns kvar. Två av sårbarheterna i den här releasen rör dessutom teman direkt.

Plugins och teman uppdateras inte automatiskt som standard. Du kan slå på det per plugin i adminpanelen, men då slår du också på risken att en uppdatering körs mitt i en kampanj utan att någon tittar efteråt. Det är den avvägningen en managed-tjänst tar över: uppdateringarna körs, men mot en kopia av sajten först, och rullas tillbaka om något går sönder.

Det är också gränsen för vad tjänsten löser. Managed WordPress skyddar inte mot ett svagt administratörslösenord, mot en anställd som klickar i ett nätfiskemejl, eller mot en plugin vars utvecklare släpper en bakdörr. Tvåfaktorsautentisering på alla adminkonton ger mer säkerhet per krona än någon hostingnivå.

Automatiska uppdateringar har ett pris, och det redovisas sällan i marknadsföringen: de går sönder ibland. En plugin som slutar fungera mot en ny kärnversion, ett tema som bygger på en funktion som togs bort, en betalningsmodul som tystnar mitt i en helg. Ju fler uppdateringar som körs utan att någon tittar, desto större chans att det händer när du inte är där.

Det är därför staging och backup hör ihop med automatiken i stället för att vara två separata punkter i funktionslistan. En uppdatering som testats mot en kopia av din sajt innan den går live, och en säkerhetskopia som är några timmar gammal när något ändå spricker, är hela skillnaden mellan en incident och en kvart.

Så när du jämför managed WordPress är frågan inte om uppdateringarna sköts. Den är hur ofta backupen tas, hur långt tillbaka den går, och om det finns en stagingmiljö som uppdateringen faktiskt passerar innan den når besökarna.

Logga in i adminpanelen och gå till Verktyg och sedan Webbplatshälsa. Statusfliken säger om du kör en version med kända säkerhetsproblem och om automatiska bakgrundsuppdateringar är aktiva över huvud taget. Är de avstängda står det där, och då vet du varför sajten ligger kvar på en äldre punktversion.

Kontrollera sedan versionsnumret under Uppdateringar. Ligger du på den senaste punktversionen av din gren är du med. Ligger du flera punktversioner efter har automatiken inte kört på ett tag, och då är det inte den här releasen som är ditt problem utan alla som kom innan.

Ta samma runda genom plugin- och temalistan medan du är inne. Det är där arbetet finns, och det är den delen ingen leverantör gör åt dig om du inte betalar någon för att göra den.

Vi skriver inte om varje punktrelease — då blir nyhetsflödet en versionslogg. Den här är med för att den illustrerar något som återkommer i hela kategorin: den funktion managed WordPress oftast marknadsförs på är den som kostar minst att leverera, medan det som faktiskt räddar en sajt en dålig tisdag är backupfrekvensen och stagingmiljön.

Vår jämförelse av managed WordPress viktar därför drift och återställning tyngre än funktionslistan. Vi uppdaterar den när en leverantör ändrar backupfrekvens, tar bort staging eller ändrar vad som ingår i uppdateringsansvaret — inte när en ny WordPress-version släpps.