Uautoriseret PHAR-deserialisering i kontaktformular 7 // Udgivet den 19-08-2025 // CVE-2025-8289

WP-FIREWALL SIKKERHEDSTEAM

Redirection for Contact Form 7 Vulnerability

Plugin-navn Omdirigering til kontaktformular 7
Type af sårbarhed PHAR-deserialiseringssårbarhed
CVE-nummer CVE-2025-8289
Hastighed Høj
CVE-udgivelsesdato 2025-08-19
Kilde-URL CVE-2025-8289

Haster: PHP Object Injection i 'Redirection for Contact Form 7' (<= 3.2.4) — Hvad WordPress-webstedsejere skal gøre lige nu

Forfatter: WP-Firewall Sikkerhedsteam
Dato: 2025-08-20
Tags: WordPress, WAF, Sårbarhed, PHP Object Injection, Kontaktformular 7, Sikkerhed

Oversigt: En meget alvorlig PHP Object Injection-sårbarhed (CVE-2025-8289, CVSS 7.5), der påvirker omdirigering for kontaktformular 7 versioner ≤ 3.2.4, giver uautoriserede angribere mulighed for at udløse PHAR-deserialisering og potentielt opnå fjernudførelse af kode, dataadgang eller kompromittering af webstedet. Opdater til 3.2.5 med det samme, og følg de lagdelte afhjælpningsforanstaltninger nedenfor.

Hvorfor dette er vigtigt (kort version)

En ny sårbarhed er blevet afsløret i det udbredte plugin "Redirection for Contact Form 7", der tillader uautoriseret PHP Object Injection (POI) via PHAR-deserialisering. Da problemet er uautoriseret, og plugin'et er populært, er dette et højrisikoproblem, der – i nærvær af en gadgetkæde – kan udvikle sig til kodeudførelse, fillæsning/skrivning eller andre effektive angreb. Udnyttelsesforsøg vil sandsynligvis være automatiserede og udbredte. Hvis dit websted kører dette plugin og ikke opdateres eller afhjælpes, skal du behandle det som presserende.


Hvad er PHP Object Injection via PHAR deserialisering?

En kort ikke-akademisk forklaring:

  • PHP-objektinjektion (POI) sker, når en applikation afserialiserer brugerstyrede data, der indeholder serialiserede PHP-objekter. Når PHP rekonstruerer objekter, vil deres magiske metoder (f.eks. __vågn op, __destruct) kan køre og kan misbruges, hvis disse klasser udfører følsomme handlinger (filhandlinger, eval, databaseforespørgsler osv.).
  • PHAR-deserialisering er en angrebsteknik, hvor en angriber uploader eller refererer til et PHAR-arkiv (eller på anden måde får kode til at åbne en fil med phar:// stream wrapper). Når PHP læser et PHAR-arkiv, kan arkivets metadata indeholde serialiserede objekter. PHP vil deserialisere disse metadata, hvilket potentielt kan forårsage objektinjektion, selv når applikationen ikke eksplicit kaldte afserialiser() på brugerinput.
  • Kombineret kan en angriber fremstille en PHAR-nyttelast, således at når applikationen indlæser arkivet (eller interagerer med en fil/ressource, der omdannes til en PHAR), udfører PHP en usikker deserialiseringssti, hvilket udløser farlig adfærd.

Hvad gør denne sårbarhed særligt farlig:

  • Plugin-slutpunktet kan udløses uden godkendelse (enhver gæst kan forsøge at foretage anmodninger).
  • PHAR-deserialisering kan give angribere mulighed for at udnytte indbyggede klasser eller plugin-/temakode, der har "gadgetkæder" - sekvenser af magiske metoder og objektegenskaber, der fører til vilkårlige handlinger.
  • Når kodeudførelse eller adgang til filer er opnået, planter angribere ofte bagdøre, opretter administratorbrugere eller stjæler data.

CVE og tekniske fakta

  • CVE: CVE-2025-8289
  • Berørt software: Omdirigering til Contact Form 7-plugin — versioner ≤ 3.2.4
  • Rettet i: version 3.2.5
  • Sværhedsgrad: Høj (CVSS 7,5)
  • Påkrævet privilegium: Ugodkendt
  • Rapporteret: 19. august 2025
  • Udnyttelsesvektor: PHAR-deserialisering forårsager PHP-objektinjektion

Opdater eller afhjælp med det samme. Behandl alle websteder med det sårbare plugin som i fare, indtil det er afhjulpet.


Hvem burde læse dette lige nu?

  • WordPress-administratorer og webstedsejere, der bruger Kontaktformular 7 og omdirigering til Kontaktformular 7
  • Administrerede WordPress-udbydere og hostingsikkerhedsteams
  • Sikkerhedsteams, der håndterer sårbarheds- og programrettelser
  • Enhver organisation, der behandler deres WordPress-installation som en del af en internetbaseret aktivopgørelse

Øjeblikkelige handlinger (hvad skal der gøres i den næste time)

  1. Identificér berørte steder
    • Log ind på hvert WordPress-websted, og gå til Plugins → Installerede plugins.
    • Søg efter "Omdirigering til kontaktformular 7" og bekræft den installerede version. Hvis du har mange websteder, skal du bruge WP-CLI:
      wp plugin liste --field=navn,version | grep -i wpcf7-redirect
    • Lav en liste over alle websteder, der har pluginet med version ≤ 3.2.4.
  2. Opdater plugin'et nu
    • Leverandøren har udgivet version 3.2.5, som løser problemet. Opdatering via WP admin eller WP-CLI:
      wp plugin opdatering wpcf7-redirect
    • Hvis du ikke kan opdatere med det samme (vedligeholdelsesvinduer, kompatibilitetstjek), skal du anvende de midlertidige afhjælpningsforanstaltninger nedenfor.
  3. Sæt værter i en sikker tilstand
    • Hvis du registrerer aktiv udnyttelse (mistænkelige PHP-filer, tilføjede administratorkonti, obfuskerede filer), skal du afbryde offentlig adgang eller oprette en vedligeholdelsesside, mens du undersøger sagen.
  4. Aktivér WAF/virtuel patching (hvis tilgængelig)
    • Konfigurer din webapplikationsfirewall til at blokere kendte udnyttelsesmønstre for denne sårbarhed. (Se eksempler på regler nedenfor.)
  5. Scan for kompromitteret
    • Kør en dybdegående malware-scanning, tjek ændrede tidsstempler, scan for PHP-webshells, og verificer databaseintegritet og brugerkonti.

Anbefalede afbødende foranstaltninger (kort-mellem-lang sigt)

Lagdelt forsvar er afgørende. Stol ikke på en enkelt foranstaltning.

  1. Programrettelse (primær/permanent)
    • Opdater plugin til 3.2.5 eller nyere. Dette er den eneste komplette og understøttede rettelse.
  2. Virtuel patching / WAF-regler (midlertidig / øjeblikkelig)
    • Blokeringsanmodninger, der indeholder brug af phar:// stream wrapper eller anmodninger, der forsøger at uploade .phar filer.
    • Begræns eller bloker mistænkelige POST'er til plugin-slutpunkterne, hvis det er muligt.
    • Tilføj specifikke regler for at afvise anmodninger, der indeholder mistænkelige serialiserede objektnyttelaster, når de registreres i brødtekster/felter.
  3. Forhindr usikker filhåndtering
    • Sørg for, at beskyttelse mod filupload forhindrer .phar uploader og validerer MIME-typer.
    • Begræns mapper, hvor uploads gemmes, og forbyd PHP-kørsel i disse mapper (f.eks. deaktiver PHP-kørsel i wp-indhold/uploads).
  4. Hærdning af PHP-konfiguration
    • Sikre phar.readonly = 1 (standard i de fleste miljøer). Dette reducerer risikoen for at oprette eller ændre phar-arkiver på serveren.
    • Hold PHP og webserver opdateret.
    • Aktivér IKKE usikker php.ini indstillinger for at "omgå" problemet; brug plugin-opdateringen og WAF.
  5. Tilladelser og færrest privilegier
    • Kør PHP-FPM-processer og filsystemtilladelser med færrest rettigheder.
    • Begræns skrivbare placeringer og databaseadgangsområder for webprocesser.
  6. Overvåg og revider
    • Overvåg webserverlogfiler for usædvanlige mønstre (detaljerede detektionsheuristikker nedenfor).
    • Kontrollér filintegriteten regelmæssigt (sammenlign med kendte, fungerende kopier), og verificér de seneste redigeringer.

Detektion — hvordan man kan se, om nogen prøvede eller lykkedes

Se efter følgende indikatorer i logfiler og filsystemet. Ingen af disse alene beviser et vellykket misbrug, men de indikerer forsøg på eller aktivt misbrug:

  • Webserveradgangslogfiler: Anmodninger, der indeholder "phar://" i anmodnings-URI'en, forespørgselsstrengen eller anmodningsteksten.
  • Upload slutpunkter, der modtager filer med .phar udvidelser eller med usædvanlige MIME-typer: ansøgning/x-phar, applikation/oktet-strøm med .phar filnavn.
  • POST'er, der indeholder lange serialiserede strenge (strenge, der starter med Å: eller s: og mange kolon/parenteser), især i felter, der normalt ikke indeholder serialiserede data.
  • Uventet oprettelse eller ændring af PHP-filer under wp-indhold/uploads, wp-indhold/plugins, eller wp-indhold/temaer.
  • Nye administratorbrugere er oprettet, eller der er ikke tilladte ændringer af brugerroller.
  • Planlagte opgaver (WP-Cron), der ikke blev oprettet med vilje.
  • Udgående forbindelser til mistænkelige domæner umiddelbart efter plugin-interaktion.
  • Base64-kodet indhold i plugin-data eller databaseindstillinger, hvor der ikke tidligere fandtes noget.
  • Kendte webshell-signaturer registreret af malware-scanner (f.eks. filer med obfuskeret kode, eval(base64_decode())).

Foreslåede detektionskommandoer:

  • Søg efter farmaceutiske omtaler:
    grep -R "phar://" /var/www/html -n
  • Søg efter mistænkelige serialiserede nyttelaster:
    grep -R "O:[0-9]\+:" /var/www/html -n
  • Tjek for ændrede filer i de seneste dage:
    find /var/www/html -type f -mtime -7 -ls

Hvis du finder mistænkelige filer, skal du gemme logfiler og oprette en retsmedicinsk kopi, før du foretager ændringer.


Eksempel på WAF-regler og afhjælpning på serverniveau

Nedenfor er eksempler på regler, du hurtigt kan anvende. Test først i detektionstilstand for at undgå falske positiver.

Nginx (blok-URI'er, der indeholder phar://):

# Afvis enhver anmodning, der indeholder phar:// i URL'en eller forespørgselsstrengen if ($request_uri ~* "phar://") { return 403; }

Apache (.htaccess) — blokerer upload af .phar-filer og phar-wrappere:

# Bloker direkte anmodninger med phar://-mønster i anmodningen RewriteEngine Ved RewriteCond %{THE_REQUEST} phar:// [NC] Omskrivningsregel .* - [F] # Nægt adgang til alle .phar-filer Ordre tillad, afvis Afvis fra alle

ModSecurity-regel (eksempel):

SecRule REQUEST_HEADERS|REQUEST_BODY "phar://" "id:1001001,phase:2,deny,log,msg:'Blokeret forsøg på phar-wrapper'" SecRule FILES_NAMES|REQUEST_BODY "\.phar$" "id:1001002,phase:2,deny,log,msg:'Blokeret forsøg på PHAR-upload'"

WordPress (PHP) best-effort-blok i et mu-plugin (midlertidig afhjælpning):

Denne kode forsøger at detektere brugen af phar wrapper i anmodningsdata eller uploadede filer og blokere yderligere behandling. Placer i wp-indhold/mu-plugins/ midlertidigt (test før implementering i produktion).

<?php
// MU plugin: block obvious PHAR attempts. Temporary measure.
add_action('init', function() {
    $blocked = false;
    // Check raw request body
    $raw = file_get_contents('php://input');
    if (stripos($raw, 'phar://') !== false) $blocked = true;
    // Check uploaded filenames
    foreach ($_FILES as $f) {
        if (!empty($f['name']) && stripos($f['name'], '.phar') !== false) $blocked = true;
    }
    if ($blocked) {
        header('HTTP/1.1 403 Forbidden');
        exit('Forbidden');
    }
}, 0);

Bemærk: Dette er en defensiv, midlertidig nødløsning. Den kan ikke erstatte en ordentlig programrettelse og kan forårsage falske positiver. Fjern den, når plugin'et er opdateret.


Tjekliste efter udnyttelse — hvis du har mistanke om kompromittering

Hvis du finder indikatorer for vellykket udnyttelse, skal du behandle webstedet som potentielt kompromitteret og følge denne prioritetstjekliste:

  1. Tag offline eller presentér vedligeholdelsessiden (hvis nødvendigt), men behold logfiler og et retsmedicinsk billede.
  2. Skift adgangskoder og roter hemmeligheder:
    • WordPress administratoradgangskoder.
    • Hosting-kontrolpanel, FTP/SFTP, SSH-legitimationsoplysninger.
    • Alle API-nøgler, der bruges af webstedet (mailudbydere, betalingsprocessorer, CDN).
  3. Kør en fuld malwarescanning og manuel kodegennemgang:
    • Kig efter webshells, obfuskeret PHP, uventede planlagte opgaver eller databaseindstillinger med indsprøjtet indhold.
  4. Gendan fra en ren sikkerhedskopi (hvis tilgængelig) fra før kompromitteringen.
    • Sørg for at plugin-versionerne er opdaterede, før du sætter webstedet online igen.
  5. Hvis der ikke er en ren sikkerhedskopi, skal du genopbygge webstedet og kun importere indhold efter en grundig rensning.
  6. Gennemgå og fjern ukendte administratorbrugere, plugins og temaer.
  7. Revider adgangslogfiler for at identificere angriber-IP'er og adgangsmetoder; bloker og forstærk i overensstemmelse hermed.
  8. Implementeringsovervågning (filintegritet, login-advarsler, WAF-logs).
  9. Overvej en professionel incidentresponstjeneste til retsmedicinsk analyse, hvis webstedet er kritisk, eller hvis bruddet virker komplekst.

Hvordan angribere typisk bruger PHP Object Injection som våben

  • Våbenbevæbning starter ofte med en probe: angribere sender testanmodninger til slutpunkter, der håndterer filer eller eksterne ressourcer. Hvis en applikation bruger file_get_contents eller andre filhandlinger på angriberkontrolleret input, forsøger angribere at erstatte et PHAR-arkiv eller en sti, der udløser phar:// indpakning.
  • Hvis applikationen eller miljøet indeholder klasser med usikre magiske metoder, vil de serialiserede metadata blive deserialiseret, og den ondsindede objektkæde aktiveres.
  • Når kodeudførelse er tilgængelig, vil angribere:
    • Upload en persistent bagdør (webshell) til en uploadmappe eller plugin-fil.
    • Opret en administratorbruger til permanent adgang.
    • Eksfiltrér databaseindhold.
    • Opsæt planlagte opgaver.
    • Pivoter til andre systemer, hvis legitimationsoplysninger genbruges.

Hvorfor en WAF / virtuel patching hjælper – og hvad den ikke kan gøre

En webapplikationsfirewall er et nyttigt lag med hurtig respons, der kan blokere angrebsforsøg, før de når sårbar kode. Effektive WAF-regler kan:

  • Opdag og bloker kendte udnyttelsesmønstre (phar://, mistænkelige serialiserede nyttelast).
  • Bloker kendte ondsindede IP-adresser og begræns mistænkelig trafik.
  • Sørg for midlertidige virtuelle programrettelser, indtil plugin'et er opdateret.

Hvad en WAF ikke kan:

  • Erstat den leverandørleverede sikkerhedsrettelse. Hvis der findes en sårbarhed i PHP eller applikationen, er den eneste fuldstændige afhjælpning at opdatere den sårbare kode.
  • Vær 100% nøjagtig — komplekse, nye udnyttelser kan omgå naive regler, og falske positiver kan blokere legitim trafik.

Derfor anbefaler vi patch + WAF + overvågning som en kombineret tilgang.


Sådan bekræfter du din sikkerhed efter en opdatering

Når du har opdateret Omdirigering for Kontaktformular 7 til 3.2.5, skal du udføre disse bekræftelsestrin:

  1. Bekræft plugin-version:
    • WordPress-administrator → Plugins eller
    • wp plugin liste | grep wpcf7-redirect
  2. Ryd caches (objektcache, CDN) og browsercachen.
  3. Scan igen for malware og integritet:
    • Kør en sammenligning af filintegritet mod nye plugin- og temapakker.
    • Scan efter indsatte webshells og mistænkelige filer.
  4. Overvåg logfiler for gentagne forsøg på udnyttelse:
    • Selv efter opdateringer kan angribere fortsætte med at undersøge; overvåge for phar:// forsøg og IP-adresser.
  5. Roter nøgler og legitimationsoplysninger, hvis beviser tyder på, at de er kompromitteret.

Praktiske udviklernoter (til plugin-/temaudviklere)

Hvis du er udvikler, så tag disse bedste fremgangsmåder med dig:

  • Undgå afserialiser() på upålidelig input. Brug JSON i stedet for til eksterne data.
  • Kald aldrig filhåndteringsfunktioner på brugerstyrede URI'er uden streng validering.
  • Vær opmærksom på PHAR stream wrapper og hvordan visse filhandlinger kan føre til deserialisering af metadata.
  • Implementer inputvalidering og -rensning ved det tidligste indgangspunkt.
  • At hærde kode til at fungere sikkert under princippet om mindste privilegier gør udnyttelse vanskeligere.
  • Hold tredjepartsbiblioteker og afhængigheder opdaterede.

Eksempel på tidslinje for hændelser (hvad man kan forvente under et aktivt udbrud)

  • T0: Sårbarhed offentliggjort. Automatiserede scannersignaturer begynder at cirkulere inden for få timer.
  • T1 (0–24 timer): Massescanning af internettet. Mange robotter med stor volumen vil forsøge at undersøge phar:// og kendte slutpunkter.
  • T2 (24–72 timer): Automatiserede angrebsscripts kan forsøge at uploade nyttelast eller fremstille PHAR-nyttelast for at udløse deserialisering. Nogle angreb vil kun lykkes, hvor der findes gadgetkæder.
  • T3 (>72 timer): Angribere etablerer persistens (webshells, administratorkonti). Oprydning bliver mere tidskrævende.
  • Anbefalet svar: Opdater inden for 24 timer og aktiver WAF-regler med det samme.

Ofte stillede spørgsmål (FAQ)

Q: Mit websted bruger ikke omdirigeringsfunktionerne – er det stadig sårbart?
A: Muligvis. Sårbarheden ligger i selve plugin-koden og kan i mange tilfælde udløses af uautoriserede anmodninger. Hvis plugin'et er installeret og aktivt, skal det antages, at det er sårbart, indtil det opdateres.

Q: Jeg kan ikke opdatere med det samme på grund af kompatibilitetstest – hvad skal jeg gøre?
A: Aktivér WAF/virtuel patching for at blokere angrebsmønstre, implementér midlertidige serversideregler for at afvise phar:// brug og .phar uploads og begræns adgang (IP-tilladelsesliste) til webstedet eller berørte slutpunkter, mens du tester.

Q: Beskytter det mig, hvis jeg sætter phar.readonly = 1?
EN: farmaceutisk skrivebeskyttet hjælper, men er ikke en mirror kugle. Det forhindrer oprettelse/ændring af PHAR-arkiver på serveren, men deserialisering af PHAR-metadata kan stadig forekomme, når en PHAR-fil læses. Kombinerede afhjælpningsforanstaltninger er nødvendige.

Q: Skal jeg fjerne plugin'et helt?
A: Hvis du ikke har brug for plugin'et, skal du fjerne det. Hvis du har brug for det, skal du opdatere til 3.2.5 og anvende den foreslåede hærdning.


Sådan beskytter WP-Firewall dig (kortfattet)

  • Administrerede, ydeevneoptimerede WAF-regler, der blokerer almindelige angrebssignaturer, herunder PHAR-baserede deserialiseringsforsøg.
  • Malware-scanning og advarsler om mistænkelige filer og ændringer.
  • Virtuel patching-funktion, så dit websted kan beskyttes, mens du udfører nødvendige opdateringer og tests.
  • Overvågning og rapportering, så du kan se angrebsforsøg og effektiviteten af afbødning i næsten realtid.

Nyhed: Beskyt dit websted lige nu med WP-Firewall Free Plan

Titel: Styrk din hjemmeside på få minutter — Start med den gratis beskyttelsesplan

Hvis du er bekymret over denne sårbarhed eller ønsker at beskytte dit WordPress-websted proaktivt, tilbyder vores gratis Basic-plan vigtige beskyttelser, som du kan aktivere med det samme. Basic-planen (gratis) inkluderer en administreret firewall, WAF-regler, malware-scanner, ubegrænset båndbredde og afhjælpning af OWASP Top 10-risici – præcis de forsvar, der hjælper med at blokere den type angreb, der bruges i dette PHAR-deserialiseringsproblem. Tilmeld dig den gratis plan, og aktiver beskyttelse på få minutter: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

(Hvis du har brug for stærkere automatisering og eksperthjælp, tilføjer vores Standard- og Pro-abonnementer automatisk fjernelse af malware, kontrol af IP-tilladelser/afvisninger, månedlige rapporter og automatisk virtuel patching.)


Afsluttende noter — prioritér patching, men glem ikke opfølgning

Denne sårbarhed er både meget alvorlig og nem at forsøge, fordi den ikke kræver godkendelse. Den hurtigste og sikreste rute er at opdatere til Redirection for Contact Form 7 version 3.2.5. Hvis du ikke kan opdatere med det samme, skal du forsvare dig med flere lag: virtuel patching via en WAF, regler på serverniveau for at blokere phar:// og .phar filer, hærdning af filupload og aktiv overvågning af indikatorer for udnyttelse.

Hvis du har brug for support, incidentrespons eller hjælp til at konfigurere beskyttelse og overvågning for flere WordPress-websteder, er vores WP-Firewall-team tilgængeligt for at hjælpe – vores administrerede værktøjer er designet til at levere virtuel patching i nødstilfælde, kontekstuelle WAF-regler og afhjælpningsvejledning til kritiske plugin-sårbarheder som denne.

Pas på dig selv, og handl nu – vinduet mellem afsløring og automatiseret udnyttelse er kort.


wordpress security update banner

Modtag WP Security ugentligt gratis 👋
Tilmeld dig nu
!!

Tilmeld dig for at modtage WordPress-sikkerhedsopdatering i din indbakke hver uge.

Vi spammer ikke! Læs vores privatlivspolitik for mere info.