Drupal varsler kritisk opdatering – exploits kan følge inden for timer

I Drupals forhåndsvarsel fra 12. oktober 2026 varslede Security Team en kritisk opdatering af Drupal core til alle understøttede grene den 14. oktober mellem kl. 16 og 21 UTC, vurderede risikoen til 19 af 25 og advarede med ordene “exploits might be developed within hours or days”. Varslet gav administratorer tid til at forberede opdateringen, mens de tekniske detaljer endnu var tilbageholdt.

Ifølge Pantheons udgivelsesmeddelelse fra 14. oktober 2026 er rettelsen nu tilgængelig som Drupal 11.4.10, 11.3.19 og 10.6.19. For administratorer er opgaven dermed skiftet fra at reservere tid til at få den rette version sikkert i produktion. Den installerede gren afgør, hvilken udgave der skal vælges; en almindelig fejlrettelsesversion fra før sikkerhedsudgivelsen er ikke tilstrækkelig.

Hvad den offentliggjorte advisory ændrer ved risikovurderingen

Den endelige Drupal-advisory SA-CORE-2026-014 fra 14. oktober 2026 identificerer CVE-2026-108097 som en kritisk sårbarhed i core-modulet Field UI, der kan føre til fjernudførelse af kode. Core alene giver ikke en direkte angrebsvej, men tilføjede moduler kan skabe alvorlige udnyttelsesveje, og mindst én kendt vej kræver ikke login. Egenudviklet kode kan også blotlægge den sårbare funktion.

Det gør installationens sammensætning vigtig for prioriteringen. Et site med en berørt core-version skal opdateres, også selv om administratoren endnu ikke har fastslået, om et bestemt tilføjet modul åbner en angrebsvej. Omvendt beskriver risikovurderingen en mulig udnyttelse og dens konsekvenser; den er ikke i sig selv dokumentation for, at et bestemt site er blevet angrebet.

Forhåndsvarslet angav adgangskompleksiteten som kompleks, mens den endelige vurdering angiver den som grundlæggende. Den senere vurdering bygger på den offentliggjorte beskrivelse af kendte angrebsveje og er det relevante grundlag for driftsbeslutningen. Drupals risikotal bør derfor læses sammen med betingelserne for udnyttelse, ikke som en påstand om, at alle installationer kan angribes på identisk vis.

Fra forhåndsvarsel til kontrolleret udrulning

Før sikkerhedsudgivelsen anbefalede Drupal at opdatere til den seneste understøttede fejlrettelsesversion på sitets gren. Formålet var at få almindelige opdateringsproblemer af vejen inden frigivelsesvinduet. Nu er målet den rettede sikkerhedsversion, men forberedelserne er stadig afgørende: en patch, der fejler under udrulning eller ikke når produktionsmiljøet, beskytter ikke det offentlige site.

1. Fastslå, hvad der faktisk kører. Registrér core-versionen i produktion og vælg rettelsen til samme understøttede gren. Kontrollér også afhængigheder, tilføjede moduler og egenudviklet kode, så opdateringen ikke standses af en overset kompatibilitetsfejl. En ufuldstændig kortlægning af mulige angrebsveje bør dog ikke blive en grund til at udskyde en tilgængelig rettelse.
2. Tag en backup, der kan gendannes. Gem database og relevante filer efter sitets normale procedure, og kontrollér, at kopien er fuldført og tilgængelig. En succesmeddelelse fra backupjobbet siger alene, at jobbet blev kørt; den viser ikke, om data kan bruges til at bringe sitet tilbage.
3. Afprøv rollback. Gennemgå den konkrete rækkefølge for at føre kode, database og filer tilbage, hvis opdateringen fejler. Prøv forløbet i et adskilt miljø, hvor det er muligt. Det afslører afhængigheder og manglende adgang, før beslutningen skal træffes under et produktionsnedbrud.
4. Reservér et ændringsvindue med ansvarlige personer. Aftal, hvem der udfører udrulningen, hvem der godkender resultatet, og hvem der kan beslutte rollback. Afsæt også tid til at kontrollere centrale offentlige sider og redaktionelle funktioner efter installationen; en gennemført softwareopdatering er ikke alene en gennemført driftskontrol.
5. Bekræft resultatet i produktion. Kontrollér den installerede core-version på det kørende site, gennemgå relevante fejlmeddelelser og afprøv de funktioner, der er vigtigst for driften. Registrér tidspunkt og resultat for hvert site, så ingen installation forsvinder mellem en planlagt ændring og en faktisk gennemført rettelse.

Installationer på udgåede grene kræver en anden plan end en almindelig patch på samme gren. De gamle grene modtager ikke denne sikkerhedsrettelse og må flyttes til en understøttet udgave. Det kan tage længere tid, så en eventuel midlertidig afværgning og ansvaret for migrationen skal fremgå særskilt af driftsplanen.

Midlertidig beskyttelse frem til den rettede version

Hvis opdateringen ikke kan gennemføres straks, kan afinstallation af Field UI bruges som midlertidig afværgning. Før ændringen skal administratoren afklare, om modulet bruges til at administrere felter, og derefter kontrollere de berørte administrative arbejdsgange. Afværgningen giver tid til udrulning; den fjerner ikke behovet for at installere en rettet core-version.

Drupal Steward beskytter allerede nogle kendte angrebsveje for sites, der bruger ordningen, men beskyttelsen dækker ikke alle mulige exploits. Et site med Steward skal derfor fortsat have et aftalt ændringsvindue. For sites, der endnu afventer opdatering, er den vigtigste åbne driftsoplysning, hvem der ejer den midlertidige beskyttelse, og hvornår den rettede version ventes i produktion.

Efter udrulningen bør versionskontrollen stå i samme driftsregistrering som resultatet af funktionstesten og en eventuel rollback. Først når den rettede version er bekræftet på det kørende site, kan den midlertidige afværgning afsluttes efter en vurdering af sitets normale funktioner.

Læs også:

• AI kan løfte opgaven uden at forbedre læringen, advarer to EU-rapporter
• Brug Copilot i Teams uden referat – men Purview kan stadig gemme spor
• Claude flytter ind i Webex – samtalen kan blive til en handling