CVE-2026-83627: RCE-fejl i Hummingbird til WordPress
Kritisk sårbarhed i WordPress-pluginet Hummingbird giver uautoriserede angribere fuld kodeudførelse. Opdatér pluginet nu.
Hvad er det?
Sårbarheden findes i WordPress-pluginet Hummingbird – Speed Optimization, Caching, Minify, Compress & CDN, der bruges til at gøre websider hurtigere. Fejlen er en kodeindsprøjtning (CWE-94), hvor pluginets fejllogfil for sidecache gemmes direkte i en webtilgængelig PHP-fil uden den beskyttelse, koden egentlig forsøger at give. En kontrol i koden, der skal tjekke om en bestemt klasse findes, slår aldrig til på grund af en navngivningsfejl, og derfor mangler den linje kode, der normalt ville stoppe filen i at blive kørt som et program. Herefter kan navnet på en almindelig cookie skrives ukontrolleret ind i logfilen og senere hentes og afvikles som PHP-kode af en besøgende uden login.
Hvem rammer det?
Det rammer WordPress-websider, der bruger Hummingbird i alle versioner op til og med 3.21.0. Sårbarheden kræver, at administrator har slået Page Caching til og aktiveret indstillingen Debug Log, hvilket ikke er standardopsætningen. Er den kombination aktiveret, kan logfilen blive skabt eller genskabt automatisk via pluginets egen ‘Ryd logs’-funktion, en cache-flush eller den daglige log-rotation, som pluginet selv kører i baggrunden.
Hvad kan ske?
En angriber uden login kan skrive skadelig PHP-kode ind i logfilen med en enkelt anonym forespørgsel og derefter afvikle koden ved at hente filen direkte i en browser. Det giver fuld kodeudførelse på webserveren, hvilket i praksis betyder, at angriberen kan læse og ændre alt indhold på siden, stjæle kundedata, oprette nye administratorbrugere eller bruge serveren som springbræt til andre systemer i netværket.
Hvor alvorligt er det?
CVSS-scoren er 9,8 ud af 10, hvilket er den højeste kategori. Angrebet kræver ikke login og ingen handling fra en bruger, og det kan udføres over internettet med lav kompleksitet. Det eneste, der begrænser sårbarheden, er at Page Caching og Debug Log skal være aktiveret, hvilket ikke er standard. Der er pr. offentliggørelsesdatoen ikke rapporteret aktiv udnyttelse, men detaljerne i sårbarheden er offentligt kendte og enkle at udføre.
Hvad gør jeg nu?
Følgende punkter lukker hullet og begrænser skaden, hvis I allerede er ramt.
- Opdatér Hummingbird-pluginet til den nyeste version, der er nyere end 3.21.0, hvor fejlen er rettet.
- Kan opdateringen ikke ske straks, så slå Debug Log fra under Page Caching-indstillingerne. Det fjerner den betingelse, angrebet kræver.
- Tjek om filen wp-content/wphb-logs/page-caching-log.php findes og indeholder uventet PHP-kode. Findes filen, skal I fjerne den og undersøge, om siden allerede er kompromitteret.
- Skift adgangskoder til alle administratorbrugere og WordPress-hemmeligheder (secret keys), hvis I finder tegn på misbrug.
- Gennemgå serverlogfiler for anmodninger mod page-caching-log.php i perioden, hvor pluginet var sårbart.
- Er I i tvivl om, om siden allerede er kompromitteret, eller mangler I ressourcer til undersøgelsen, bør I hente ekstern hjælp til en teknisk gennemgang.
Opdatér inden for 48 timer
Vi anbefaler, at alle websider med Hummingbird-pluginet opdateres snarest, uanset om Debug Log er aktiveret hos jer i dag, da indstillingen kan blive ændret senere uden at nogen bemærker det. Er opdatering ikke mulig med det samme, er det forsvarligt at vente et par dage, hvis Debug Log allerede er slået fra og I har bekræftet det. Er Debug Log aktiveret og pluginet ikke opdateret, bør det behandles som en åben dør, der skal lukkes uden unødig ventetid.
Tidslinje
Konkrete eksempler
Webshop med caching-fejlsøgning
En dansk webshop har slået Debug Log til i Hummingbird for at fejlsøge langsomme sider under en salgskampagne. En angriber sender en anmodning med en manipuleret cookie, der bliver skrevet ind i logfilen. Kort efter henter angriberen samme fil direkte i browseren og får fuld adgang til webserveren, herunder kundedatabasen med navne og adresser.
Ofte stillede spørgsmål
Er vi ramt af denne sårbarhed?
I er kun sårbare, hvis jeres WordPress-side bruger Hummingbird-pluginet i version 3.21.0 eller ældre, og indstillingen Debug Log under Page Caching er slået til. Tjek pluginets indstillinger for at se, om Debug Log er aktiveret.
Hvordan tjekker vi, om siden allerede er kompromitteret?
Åbn filen wp-content/wphb-logs/page-caching-log.php i en filhåndtering på serveren og se, om den mangler linjen ‘<?php die(); ?>’ i toppen eller indeholder ukendt PHP-kode. Findes uventet kode, skal siden undersøges nærmere og eventuelt genoprettes fra en ren backup.
Kan vi vente til weekenden med at opdatere?
Er Debug Log slået fra, kan opdateringen vente til næste planlagte vedligeholdelsesvindue. Er Debug Log slået til, bør opdateringen eller deaktivering af indstillingen ske samme dag, da der ikke kræves login for at udnytte fejlen.
Skal vi anmelde dette til Datatilsynet?
Kun hvis I finder tegn på, at persondata er blevet tilgået eller udtrukket via en kompromitteret side. Find I bevis for misbrug af sårbarheden med adgang til persondata, skal I vurdere anmeldepligten efter databeskyttelsesreglerne og gerne med juridisk rådgivning.
Rammer det andre plugins eller kun Hummingbird?
Sårbarheden er specifik for Hummingbird-pluginets logfunktion og påvirker ikke andre plugins, med mindre I har anden software, der genbruger samme kode.
Hvad gør vi, hvis vi ikke selv bruger WordPress-siden aktivt?
Selv en sjældent besøgt eller forladt WordPress-side med Hummingbird installeret kan udnyttes, hvis den er tilgængelig fra internettet. Opdatér eller fjern pluginet, også på sider I ikke bruger dagligt.
CVSS-detaljer
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
CWE-svaghedstyper
Original NVD-beskrivelse (engelsk)
The Hummingbird – Speed Optimization, Caching, Minify, Compress & CDN plugin for WordPress is vulnerable to Remote Code Execution in all versions up to, and including, 3.21.0 via the log_msg() function in core/modules/class-page-cache.php. The page-cache debug log is written to wp-content/wphb-logs/page-caching-log.php, a directly web-accessible PHP file that is supposed to be protected by a leading ” header. That header is guarded by class_exists( ‘Filesystem’ ), which can never match because class_exists() resolves string arguments in the global namespace while the class is HummingbirdCoreFilesystem; when the log is created during a front-end request the header is therefore omitted entirely. get_cookies() then writes the raw name of any cookie matching the wphb_cache_ prefix into that file without sanitization. This makes it possible for unauthenticated attackers to write arbitrary PHP into the log file with a single anonymous request and execute it by requesting the file directly, resulting in full remote code execution. Exploitation requires the site administrator to have enabled Page Caching with the Debug Log option (non-default), and the log file to be created during a front-end request — a state reached by the plugin’s own ‘Clear logs’ action, any cache flush, or unattended via the plugin’s daily log-rotation cron, which can strip the protective header from an existing log file.
Referencer & kilder
Eksterne kilder
Brug for hjælp med jeres sikkerhed?
Vi hjælper SMV’er med at omsætte trusler som denne til konkrete handlingsplaner.