WordPress.org kutter oppdateringsforsinkelsen til seks timer

#Oppdatert 28. juli 2026: ventetiden er nå seks timer

Den obligatoriske nedkjølingen på automatiske plugin- og temaoppdateringer fra WordPress.org er kuttet fra 24 timer til seks. Konstantin Obenland, en bidragsyter sponset av Automattic, kunngjorde endringen i kanalen #meta på WordPress-Slack, og The Repository omtalte den i utgave 312 den 24. juli 2026.

Seks timer er ikke endestasjonen. Ifølge samme melding arbeides det med å hoppe over forsinkelsen helt når KI-kontrolløren som heter Gandalf ikke finner noen feil. Da skal ventetiden falle til minutter for de fleste oppdateringer.

Alt under dette avsnittet ble skrevet mens ventetiden var 24 timer, og blir stående som dokumentasjon på hva den regelen kostet. Les tallene som situasjonen “før”: vinduet som beskrives er nå en firedel så stort, og det krymper videre. Selve problemet har samme form. En offentlig kodediff som ligger bak en hvilken som helst sperre, gir første trekk til den som leser den først, og et byrå som kan hente en tagget utgivelse fra Git, venter verken seks eller 24 timer.

#Innledning

Beslutningen fra WordPress.org sitt plugin-team i juni 2026 om å innføre en 24-timers oppdateringsforsinkelse skapte debatt blant utviklere og administratorer. Selv om mekanismen ble lansert for å forhindre automatisk spredning av skadelig programvare etter nylige angrep på leverandørkjeden (som CDN-kompromitteringen hos Awesome Motive), var det faktiske omfanget langt større. Forsinkelsen gjaldt nemlig alle oppdateringer - også de som kjøres manuelt fra kontrollpanelet. Fra 24. juli 2026 er ventetiden seks timer, og plugin-teamet arbeider med å fjerne den for utgivelser som Gandalf-kontrollen klarerer.

For byråer og team som vedlikeholder store B2B-nettsteder, medførte denne endringen en betydelig sikkerhetsrisiko. I det øyeblikket en utvikler publiserer en sikkerhetsoppdatering, blir endringsloggen offentlig. Hackere og roboter kan umiddelbart analysere koden og starte angrep, mens administratorer var blokkert fra å oppdatere et helt døgn. Nå er sperren seks timer. La oss se nærmere på mekanismen og hvordan vi kan sikre prosjektene våre utenfor det offisielle arkivet, uansett hvilken klokke som gjelder.

#Sikkerhetsvinduet: Roboter har et forsprang på administratoren

Hovedproblemet som påpekes av fellesskapet, er asymmetrien i informasjon. Miriam Schwab fra Elementor påpekte på Slack at denne forsinkelsen skaper et ideelt vindu for automatiserte angrep. Under normale omstendigheter måles reaksjonstiden på kritiske sårbarheter (f.eks. SQL-injeksjon eller kjøring av ekstern kode) i minutter. Når oppdateringen er tilgjengelig, kjører byråer WP-CLI eller styringsverktøy (f.eks. MainWP, ManageWP) for umiddelbar distribusjon.

Slik regelen opprinnelig var, blokkerte WordPress.org installasjon av koden i 24 timer etter innsending fra utvikleren. Nå er sperren seks timer, men skjevheten overlevde kuttet: koden er synlig i det offentlige SVN- eller GitHub-arkivet fra innsendingsøyeblikket. Roboter kan skanne nettet etter sårbare versjoner og angripe nettsteder før eierne i det hele tatt kan klikke på “Oppdater”.

Et annet problem er nullstilling av tidsuret. Hvis en utvikler oppdager en feil rett etter lansering og gir ut en ny rettelse (f.eks. versjon 1.0.1 noen timer etter 1.0.0), starter perioden på nytt. Under 24-timersregelen kunne det bety 48 timers venting på stabil kode. Obenlands melding om kuttet til seks timer sier ingenting om nullstillingen, så planlegg for den til plugin-teamet sier noe annet.

#Forsinkelsens effekt på sikkerhetsprosesser

La oss sammenligne den klassiske oppdateringsmodellen, forsinkelsen slik den ble innført, og regelen som gjelder i dag:

#Hvordan konfigurere private Composer-arkiver for sikkerhetsoppdateringer i WordPress

For å unngå ventetiden på WordPress.org ved kritiske sikkerhetsfeil, seks timer i dag og 24 før juli, bør byråer administrere utvidelser via Composer. Her er en produksjonsklar konfigurasjon som bruker wpackagist og private GitHub-arkiver.

For å ha full kontroll over oppdateringsprosessen og unngå forsinkelsen på WordPress.org, anbefaler vi å administrere utvidelser via Composer. Dette gjør det mulig å hente kode direkte fra pålitelige kilder (f.eks. utviklerens GitHub-arkiv) før den blir godkjent i den offisielle katalogen.

Her er en produksjonsklar composer.json for et sikkert B2B-nettsted:

{
  "name": "wppoland/b2b-secure-site",
  "description": "Production-ready Composer configuration bypassing WordPress.org update cooldown",
  "repositories": [
    {
      "type": "composer",
      "url": "https://wpackagist.org"
    },
    {
      "type": "vcs",
      "url": "https://github.com/elementor/elementor"
    }
  ],
  "require": {
    "composer/installers": "^2.0",
    "johnpbloch/wordpress-core": "^6.9",
    "wpackagist-plugin/contact-form-7": "^5.9",
    "elementor/elementor": "dev-master"
  },
  "config": {
    "allow-plugins": {
      "composer/installers": true,
      "johnpbloch/wordpress-core-installer": true
    },
    "preferred-install": "dist"
  }
}

Med denne konfigurasjonen kan vi, ved kritiske feil i Elementor eller andre utvidelser, hente koden direkte fra den angitte GitHub-grenen, før ventetiden på WordPress.org er over.

#Tekniske aspekter ved Composer-distribusjon i store miljøer

Bruk av Composer for å omgå ventetiden krever endringer i byråets DevOps-prosesser. Ved å sette opp en egen Satis-instans kan oppdateringer rulles ut umiddelbart uten forsinkelse.

Her er et produksjonsklart eksempel på satis.json for et byrås interne pakkeserver:

{
  "name": "wppoland/agency-repository",
  "homepage": "https://satis.wppoland.dev",
  "repositories": [
    {
      "type": "vcs",
      "url": "https://github.com/elementor/elementor"
    },
    {
      "type": "vcs",
      "url": "https://github.com/wp-premium/contact-form-7"
    }
  ],
  "require": {
    "elementor/elementor": "*",
    "wpackagist-plugin/contact-form-7": "*"
  },
  "require-dependencies": true,
  "archive": {
    "directory": "dist",
    "format": "zip",
    "skip-dev": true
  }
}

Dette reduserer sikkerhetsrisikoen og lar teamet reagere så snart en patch publiseres på GitHub. Vi slipper dermed å vente på WordPress.org sin godkjenningsprosess for kritiske B2B-nettsteder.

Sammenligningen mellom SVN og Git-arkiver viser at Git gir bedre kontroll over kildekoden. Med Satis kan vi verifisere sjekksummer (checksums) for hver pakke automatisk, noe som forhindrer manipulerte filer i å nå produksjonsserverne.

#Dypdykk: Utviklingen av angrep på leverandørkjeden i WordPress i 2026

I 2026 har angrep på leverandørkjeden blitt vanligere i WordPress-økosystemet. Innskyting av skadelig kode i populære utvidelser tvang WordPress.org til å ta grep.

Nedkjølingsperioden gir tid til sikkerhetsskanning. Kuttet fra 24 timer til seks er plugin-teamets svar på innvendingen om at et helt døgn var for høy pris for den tiden, og det planlagte bortfallet etter ren Gandalf-kontroll går enda lenger. For byråer som må rulle ut kritiske sikkerhetsoppdateringer (CVSS 9.0+), er seks timer likevel seks timer.

For B2B-nettsteder er reaksjonstid alt. Vi anbefaler derfor å hente koden direkte fra utviklerens Git-arkiv for å omgå forsinkelsen i den offisielle katalogen. Dette beskytter mot skjult skadevare som ofte obfuskeres for å lure automatiske skannere. Et annet godt sikkerhetstiltak er å låse rettighetene til plugin-mappen med chmod 555 på Linux-nivå for å hindre uautoriserte endringer.

Incident Response-protokollen må inneholde: 1. WAF-regler for å blokkere angrep. 2. Nedlasting av patch via Git. 3. Automatisert utrulling med Composer. Dette fjerner avhengigheten av manuelle rutiner og WordPress.org.

#Praktisk distribusjonsskript for umiddelbare B2B-sikkerhetsoppdateringer

I krisesituasjoner kan utviklere bruke et bash-skript med WP-CLI for å installere oppdateringen direkte fra GitHub:

#!/usr/bin/env bash
# Emergency patch deployment bypass via WP-CLI
set -euo pipefail
PLUGIN_NAME="contact-form-7"
GITHUB_REPO="dQw4w9WgXcQ/contact-form-7"
TARGET_VERSION="5.9.6"
WP_PATH="/var/www/html"
curl -sSL -o "/tmp/patch.zip" "https://github.com/${GITHUB_REPO}/archive/refs/tags/v${TARGET_VERSION}.zip"
wp plugin install "/tmp/patch.zip" --path="${WP_PATH}" --force --activate
wp cache flush --path="${WP_PATH}"

For full automatisering via GitHub Actions, bruk denne arbeidsflyten:

name: Emergency Patch Deployment
on:
  push:
    branches:
      - main
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout repository
        uses: actions/checkout@v4
      - name: Install SSH key
        uses: shimataro/ssh-key-action@v2
        with:
          key: ${{ secrets.SSH_PRIVATE_KEY }}
          known_hosts: ${{ secrets.SSH_KNOWN_HOSTS }}
      - name: Run remote deployment via SSH
        run: |
          ssh [email protected] "bash -s" < ./scripts/deploy-patch.sh

Dette sikrer rask oppdatering av nettsteder uten å vente på WordPress.org og minimerer risikoen for manuelle feil under tidspress.

#Teknisk guide: WAF-konfigurering for å dempe zero-day-sårbarheter før oppdatering

Når en zero-day sårbarhet blir kjent og du må vente ut ventetiden på WordPress.org, seks timer siden 24. juli 2026, er WAF-regler din beste beskyttelse. Her er oppsettet for Nginx og Cloudflare.

#1. Nginx WAF-regel

Legg til følgende konfigurasjon i Nginx for å blokkere uautoriserte forespørsler på servernivå:

location = /wp-admin/admin-ajax.php {
    if ($arg_action = "update_settings") {
        return 403;
    }
    if ($request_body ~* "action=update_settings") {
        return 403;
    }
    include fastcgi_params;
    fastcgi_pass unix:/var/run/php/php8.1-fpm.sock;
}

#2. Cloudflare Custom WAF-regel

Bruk denne JSON-strukturen for å opprette en regel på kanten (edge) i Cloudflare:

{
  "action": "block",
  "expression": "(http.request.uri.path eq \"/wp-admin/admin-ajax.php\" and (http.request.uri.query contains \"action=update_settings\" or http.request.body.raw contains \"action=update_settings\"))",
  "description": "Emergency block for vulnerable AJAX action update_settings before patch cooldown expires"
}

#3. Logganalyse

Søk gjennom tilgangsloggene etter mulige angrepsforsøk med denne kommandoen:

grep "POST /wp-admin/admin-ajax.php" /var/log/nginx/access.log | grep -E "action=update_settings|update_settings"

Dette sikrer nettstedet mens du venter på den offisielle oppdateringen.

#Kasusstudie: Håndtering av zero-day-sårbarhet i en WooCommerce-butikk med høyt bestillingsvolum

La oss se på en reell hendelse fra juni 2026, uker før kuttet til seks timer, for å illustrere hva 24-timers cooldown på WordPress.org kostet så lenge den gjaldt. En av våre kunder, en stor nettbutikk innen mote, bruker WooCommerce og en avansert frakt-plugin. Klokken 14:00 ble en kritisk SQL-injeksjon i frakt-pluginen offentlig kjent, noe som ga angripere mulighet til å hente ut sensitive kundedata.

For en nettbutikk med høyt bestillingsvolum betyr nedetid store økonomiske tap, og det å la nettstedet være sårbart i timer er en uakseptabel risiko. På grunn av nedkjølingsperioden som gjaldt den gangen, var ikke den sikre versjonen 4.2.1 tilgjengelig i kontrollpanelet, systemet oppga at oppdateringen først ville bli frigitt dagen etter kl. 14:00.

#Vår steg-for-steg-håndtering av hendelsen:

1. Kodeanalyse av rettelsen: Vårt SecOps-team lokaliserte utviklerens GitHub-depot og analyserte diff-koden mellom versjon 4.2.0 og 4.2.1 for å bekrefte at den rettet feilen på en trygg måte, uten å introdusere nye feil i ordresystemet.
2. Midlertidig WAF-regel: I løpet av få minutter opprettet vi en regel i Cloudflare som blokkerte alle POST-forespørsler mot det sårbare API-endepunktet, noe som stoppet pågående skanninger fra roboter.
3. Distribusjon via Composer VCS: Vi endret prosjektets composer.json for å hente versjon 4.2.1 direkte fra GitHub, i stedet for å vente på WordPress.org sitt offisielle speil.
4. Testing i testmiljø: CI/CD-systemet distribuerte oppdateringen til staging og kjørte automatiserte tester av betalingsflyten og integrasjonen med fraktleverandøren.
5. Produksjonssetting: Godt innenfor den første timen etter at sårbarheten ble kjent, var butikken fullt oppdatert og sikret i produksjon.

Dette viser hvorfor virksomheter ikke kan stole utelukkende på standard oppdateringsrutiner i WordPress. Uten Composer-oppsettet ville nettbutikken vært sårbar i 24 timer, noe som kunne ført til massiv lekkasje av personopplysninger. Samme hendelse i dag ville kostet seks timer på standardkanalen, som er bedre regnestykke og samme beslutning: en frakoblet leveransekjede slår begge tallene. I tillegg installerte vi et eget Nginx-skript på serversiden for å overvåke feillogger kontinuerlig. Skriptet blokkerer automatisk IP-adresser som prøver å sende mistenkelige payload-data til kjente sårbare baner. Dette sikrer at vi ikke bare stopper angrepet via WAF, men også beskytter serverressursene mot brute-force-skanning under sikkerhetskriser. Kombinasjonen av direkte pakkehåndtering og aktiv overvåking er avgjørende for moderne B2B-drift.

#Ekspertens vurdering og B2B-strategi: Automatiske vs. manuelle oppdateringer

Forsinkelsen, 24 timer da den kom og seks siden juli 2026, reiser spørsmål rundt den generelle strategien for oppdateringer på enterprise-nettsteder. Mens auto-oppdateringer er bra for mindre blogger, er risikoen for stor for komplekse B2B-sider. En uventet oppdatering kan skape konflikter med spesialbygde moduler og tredjepartssystemer som ERP eller CRM.

Steve Burge fra PublishPress påpeker at nedkjølingsperioden gir fordeler, ettersom sikkerhetsskannere har avdekket mindre feil i deres utvidelser før de nådde brukerne. Dette er positivt, men løser ikke utfordringen med manglende testing før produksjonssetting.

#Anbefalt B2B-strategi for byråer:

1. Deaktiver automatiske oppdateringer: Skru av automatiske oppdateringer i produksjon via wp-config.php:

   define('WP_AUTO_UPDATE_CORE', false);
   define('AUTOMATIC_UPDATER_DISABLED', true);

2. Filintegritetskontroll: Kjør regelmessige kontroller av filene via WP-CLI for å sikre at ingen filer har blitt endret utenom git:

   wp core verify-checksums
   wp plugin verify-checksums --all

3. Content Security Policy (CSP): Konfigurer strenge CSP-headere på Nginx/Apache. Dette blokkerer ekstern lasting av skript om en utvidelse skulle bli kompromittert i leverandørkjeden.

Ved å følge disse rutinene sikrer byråer at de har full kontroll over kildekoden, og reduserer faren for nedetid på kritiske faren for nedtid på kritiske nettløsninger. For å styrke dette ytterligere anbefaler vi at byråer innfører regelmessige penetrasjonstester av alle installerte utvidelser, slik at man kan avdekke og tette sikkerhetshull før de blir utnyttet av ondsinnede aktører. Det anbefales også å benytte avanserte monitoreringsverktøy som varsler teamet umiddelbart ved uvanlige API-forespørsler eller endringer i kritiske filer, slik at man kan reagere proaktivt. For å maksimere sikkerheten bør byråer også implementere strenge tilgangskontroller (såkalte IP-whitelists) for alle sensitive administrative endepunkter, samt kreve tofaktorautentisering (2FA) for alle brukere med publiseringsrettigheter. Dette reduserer sannsynligheten for at stjålne legitimasjonsopplysninger kan brukes til å kompromittere nettstedet, og gir en sikrere driftshverdag. Det er også lurt å etablere en streng rutine der alle eksterne biblioteker manuelt godkjennes av en seniorutvikler før de legges til i prosjektets avhengigheter, for å sikre at ingen uønsket kode blir introdusert via bakdører i pakkesystemet. Dette bidrar til å opprettholde en ukompromittert kodebase over tid. Slike ekstra sikkerhetstiltak er helt avgjørende for at bedriften skal kunne opprettholde et høyt beskyttelsesnivå mot moderne trusler og sikre at kundedata forblir trygge under alle omstendigheter. Dette gir også driftsteamet full kontroll over kildekoden til enhver tid og forenkler arbeidet med revisjoner og samsvarsvurderinger. Ved å etablere slike rutiner kan organisasjonen redusere sårbarhetsvinduet betraktelig og sikre at kritiske systemer alltid kjører med de mest stabile og sikre programvareversjonene. Dette reduserer også sannsynligheten for nedetid og tap av omsetning betraktelig over tid. Dermed er en solid og gjennomtenkt tilnærming til sikkerhet en av de viktigste investeringene et byrå kan gjøre for sine kunder og forbedre driftssikkerheten til hele infrastrukturen på en særdeles effektiv måte.

#Sjekkliste: Slik bør B2B-byråer reagere på endringene

Følgende tiltak vil minimere risikoen knyttet til den nye mekanismen:

1. Revisjon av leverandørkjeden: Identifiser virksomhetskritiske utvidelser og de som tidligere har hatt sikkerhetshull.
2. Gå over til Composer: Administrer viktige utvidelser via Composer og VCS-arkiver (f.eks. GitHub, GitLab).
3. Bruk WP-CLI for umiddelbare rettinger: Hvis en sårbarhet blir kjent, installer ZIP-filen direkte via WP-CLI:

   wp plugin install https://github.com/vendor/plugin/archive/refs/tags/v1.0.1.zip --force

4. Overvåk endringslogger: Bruk tjenester som WPScan eller Patchstack for tidlig varsling av sårbarheter.
5. Bruk testmiljø (staging): Test alltid manuelle installasjoner på et testmiljø først for å unngå nedetid på produksjonsnettstedet.

#Oppsummering

Oppdateringsforsinkelsen har alltid vært et kompromiss mellom sikkerhet og funksjonalitet, og plugin-teamet har nå priset kompromisset på nytt: 24. juli 2026 ble 24 timer til seks, med en varslet vei mot å fjerne ventetiden helt for utgivelser Gandalf-kontrollen klarerer. Kritikken i denne teksten gjorde jobben sin, og det meste av kostnaden den beskrev er borte.

Det som overlever kuttet, er arbeidsflyten. Seks timers sperre på en offentlig kodediff gir fortsatt første trekk til den som leser diffen raskest, og et B2B-nettsted med en CVSS 9.0+-feil i en frakt-plugin bør ikke stå i noen kø. Composer med VCS-kilder, kontroll av sjekksummer og WAF-regler som midlertidig skjold er fortsatt standarden for profesjonelle WordPress-byråer, uansett hvilket tall som står på plassen neste gang.