Plugin-navn	Indholdssynlighed for Divi Builder
Type af sårbarhed	Vilkårlig kodeeksekvering
CVE-nummer	CVE-2026-1829
Hastighed	Medium
CVE-udgivelsesdato	2026-06-04
Kilde-URL	CVE-2026-1829

Authentificeret bidragyder RCE i Indholdssynlighed for Divi Builder (CVE-2026-1829) — Hvad WordPress-webstedsejere skal gøre nu

Forfatter: WP-Firewall Sikkerhedsteam
Dato: 2026-06-04

Oversigt

• Sårbarhed: Vilkårlig kodeeksekvering (fjernkodeeksekvering) i Indholdssynlighed for Divi Builder WordPress-plugin, der påvirker versioner <= 4.02.
• CVE: CVE-2026-1829
• Sværhedsgrad: Høj / CVSS 8.8 (Patchstack klassifikation)
• Påkrævet privilegium: Authentificeret bruger med bidragyderrolle
• Patchet i: 5.00
• Risiko: Angribere kan eskalere en lavprivilegeret konto til at udføre vilkårlig kode på serveren — brugt i massekompromitteringskampagner.

Som WP-Firewall sikkerhedsteamet betragter vi denne sårbarhed som en reel og umiddelbar trussel mod WordPress-websteder, der bruger Indholdssynlighed for Divi Builder-pluginet. Nedenfor forklarer jeg, hvad fejlen betyder, hvordan angribere kan misbruge den, hvordan man hurtigt kan mindske risikoen, hvordan man opdager udnyttelse, og hvordan vi anbefaler både nød- og langsigtet afhjælpning og hærdning.

Hvis du administrerer WordPress-websteder, så læs dette omhyggeligt og handle nu — især hvis dit websted tillader brugere på bidragyderniveau at logge ind.

---

Hvad skete der? Overordnet oversigt

En sårbarhed i “Indholdssynlighed for Divi Builder” pluginet (versioner op til 4.02) tillader en autentificeret angriber med bidragyderprivilegier at udføre vilkårlig kodeeksekvering i hostingmiljøet. Dette er ikke en simpel indholdsinjektion — det er evnen til at få webstedet til at udføre angriberleveret kode, der kører på serveren. Når det udnyttes, kan angribere installere bagdøre, pivotere til andre websteder på den samme server, stjæle legitimationsoplysninger eller udføre defacements og spamkampagner.

Sårbarheden er blevet offentligt offentliggjort og tildelt CVE-2026-1829. En sikkerhedsopdatering er tilgængelig i version 5.00 af pluginet. Mange websteder halter dog bagefter med opdateringer eller kan muligvis ikke opdatere med det samme på grund af tilpasninger, integrationstest eller hostingbegrænsninger. Det er her hurtig afhjælpning og opdagelse er afgørende.

---

Hvorfor denne sårbarhed er farlig

En bidragyderkonto er almindeligt tilgængelig på multi-forfatter blogs, fællesskabswebsteder og platforme, der accepterer indhold fra ikke-betroede bidragydere. Bidragydere får normalt lov til at oprette og redigere deres egne indlæg, men kan ikke installere plugins eller ændre temaer. Når et plugin tillader en angriber på bidragyderniveau at nå server-side eksekvering, omgår det effektivt privilegietmodellen:

• Angribere har ikke brug for admin-legitimationsoplysninger for fuldt ud at kompromittere et websted.
• Udnyttelser er trivielle at skalere — et automatiseret script kan bevæbne ethvert websted, der udsætter det sårbare plugin.
• Når kodeeksekvering er opnået, kan angribere opretholde vedvarende adgang, selv efter pluginopdateringer, medmindre bagdøre fjernes.
• Sårbarheden kortlægges til OWASP A3 (Indsprøjtning) mønstre; pluginet tillader usikker input at påvirke serveradfærd.

Fordi bidragyderkonti er lettere at opnå end admin-konti, og websteder ofte har mange bidragydere, er udnyttelsesoverfladen stor. Automatiserede udnyttelsesscannere og bots scanner typisk efter sådanne sårbarheder og forsøger udnyttelse umiddelbart efter offentliggørelse.

---

Teknisk analyse (hvad der sandsynligvis gik galt)

Offentlige adviseringer beskriver vilkårlig kodeeksekvering udløst af en autentificeret bidragyder. Selvom vi ikke vil nævne specifikke interne kodeveje, er dette de almindelige rodårsager, der producerer denne klasse af sårbarhed:

• Pluginet accepterer brugerstyret input (postmeta, shortcode-attributter, AJAX-payloads eller filuploads) og inkluderer eller udfører senere disse data på serveren uden korrekt sanitering og escaping.
• En server-side rutine kan direkte evaluere indhold (for eksempel via PHP's eval eller ved at inkludere en fil eller skabelonsti konstrueret fra brugerinput).
• Plugin'et kan eksponere en administrativ AJAX-handling eller REST-endepunkt, der ikke tjekker kapabiliteter korrekt, hvilket tillader lavere privilegerede roller at udføre operationer, der er beregnet til redaktører eller administratorer.
• Filupload-håndterere, der tillader PHP-filer (eller filer, der kan omdannes til eksekverbar kode) uden at validere MIME-typer eller begrænse lagringssted.

Fordi sårbarheden tillader kodeeksekvering, er det effektivt en injektionsfejl: dårlig input påvirker applikationsflowet på en måde, der fører til vilkårlige kommandoer eller PHP-kodeeksekvering.

Vigtig: Selv hvis plugin'et ikke kalder eval eksplicit, kan en angriber nogle gange kæde flere adfærd sammen (f.eks. skrive til en tema- eller plugin-fil via en filskrivnings-API, narre kode til at inkludere den fil eller plante en bagdør via brugerdefinerede skabeloner) for at opnå RCE.

---

Hvem bliver berørt?

• Enhver WordPress-side, der kører Content Visibility for Divi Builder plugin-versioner 4.02 eller tidligere.
• Sider, der har Contributor-konti (eller brugerroller, der svarer til Contributor-kapabilitet), og hvor disse brugere kan få adgang til den sårbare funktionalitet.
• Multisite-netværk, hvor plugin'et er netværksaktiveret, og Contributors findes på undersider.

Hvis du hoster CMS-platforme med brugergenereret indhold (gæsteforfattere, åbne indsendelser, multi-forfatter blogs), så behandl dette som kritisk, selvom du mener, at Contributors er “betroede” - angribere opretter rutinemæssigt falske contributor-konti.

---

Øjeblikkelige handlinger - gør dette nu (ordnet)

1. Bekræft plugin-version
   • Log ind og tjek plugin-versionen. Hvis den er <= 4.02, er siden sårbar.
2. Opdater plugin'et
   • Hvis muligt, opdater Content Visibility for Divi Builder til version 5.00 eller senere straks. Dette er den enkleste og anbefalede løsning.
3. Hvis du ikke kan opdatere straks, reducer risikoen:
   • Deaktiver midlertidigt plugin'et (deaktiver det), indtil en opdatering eller sikker tidslinje er tilgængelig.
   • Begræns Contributor-adgang: ændre brugerroller, så nye eller uverificerede contributors ikke kan logge ind eller poste, indtil siden er sikker.
   • Fjern eller begræns plugin'ets endepunkter ved hjælp af WAF-regler eller webserveradgangsregler (eksempelvejledning følger).
   • Hærd filupload-mapper: forbyd eksekvering af PHP fra /wp-content/uploads/ via .htaccess eller serverkonfiguration.
4. Tænd for proaktiv beskyttelse (WAF / virtuel patching)
   • Implementer en webapplikationsfirewall, der kan anvende en virtuel patch eller blokere udnyttelsesmønstre. Konfigurer den til at blokere mistænkelige POST'er/parametre og til at karantæne anmodninger fra ukendte contributors, der berører sårbare endepunkter.
5. Rotér legitimationsoplysninger og nøgler
   • Hvis kompromis mistænkes eller for at være sikker efter patching, roter administratoradgangskoder, API-nøgler og eventuelle nøgler, der er gemt i wp-config.php, som er tilgængelige eller sandsynligvis genbruges.
6. Scan siden straks
   • Udfør en fuld site-malware- og integritetsscanning (filer og database) for at tjekke for bagdøre, uventede PHP-filer, ændrede kernefiler eller rogue databaseposter.

---

Hurtige WAF-regelforslag (eksempler — test før implementering)

Nedenfor er generiske eksempelregler for at reducere udnyttelsesrisiko, når øjeblikkelige pluginopdateringer ikke er mulige. Test først i et staging-miljø; alt for brede regler kan bryde funktionaliteten.

• Bloker POST-anmodninger til specifikke plugin-endepunkter fra brugere på Contributor-niveau:
  • Identificer plugin-specifikke AJAX-handlinger eller REST-ruter (f.eks. /wp-admin/admin-ajax.php?action=PLUGIN_ACTION_NAME eller /wp-json/PLUGIN_NAMESPACE/*) og blokér anmodninger fra ikke-administrator sessioner.
• Bloker mistænkelige nyttelaster:
  • Afvis anmodninger, der indeholder almindelige PHP-funktionsnavne i formularfelter (exec, shell_exec, system, passthru, base64_decode, eval), når de kommer fra contributor-konti.
• Forhindre filupload, der udføres som PHP:
  • Afvis anmodninger, der forsøger at oprette eller ændre PHP-filer under /wp-content/uploads/.

Eksempel nginx-regel (konceptuel):

location ~* /wp-content/uploads/.*\.(php|phtml|php5|phar)$ {

Eksempel .htaccess for at stoppe PHP-udførelse i uploads:

<FilesMatch "\.(php|php5|phtml)$">
  Order Deny,Allow
  Deny from all
</FilesMatch>

Bemærk: Disse er forebyggende lag; de erstatter ikke patchen. Nogle udnyttelser bruger kreative kæder, der kan omgå enkle regler, så kombiner virtuel patching med pluginopdateringer og overvågning.

---

Detektion: tegn på udnyttelse

Hvis pluginet blev udnyttet, er her indikatorer at lede efter:

• Nye eller ændrede filer, du ikke har placeret, især PHP-filer i:
  • /wp-content/uploads/
  • /wp-content/plugins/ (uventede filer)
  • Temakataloger: /wp-content/themes/[theme]/ (ukendte filer)
• Ukendte administratorbrugere eller contributor-brugerkonti, der er oprettet for nylig.
• Mistænkelige planlagte opgaver (wp-cron jobs) eller ukendte hooks i databasen.
• Udbundne forbindelser fra serveren til ukendte IP'er eller domæner (beacons og C2).
• Høj CPU-brug eller processer, der genereres af PHP, der optræder usædvanligt ofte.
• Webserverlogs eller applikationslogs viser usædvanlige POST-anmodninger til plugin-endepunkter, indsendelser, der indeholder kodede payloads (base64 / gzip), eller gentagne anmodninger fra den samme IP.
• Ændrede kernefiler (sammenlign med rene kopier) eller database-rækker med injiceret kode (f.eks. tags eller <?php i indhold gemt i indstillinger eller postmeta).

Hvis du ser nogen af disse, antag kompromittering og følg tjeklisten for hændelsesrespons nedenfor.

---

Hændelsesrespons playbook (hvis du mistænker eller har bekræftet kompromittering)

1. Isolere
   • Tag sitet offline eller sæt det i vedligeholdelsestilstand.
   • Begræns adgangen til wp-admin til dine IP-adresser via webserverregler eller HTTP-godkendelse.
2. Bevar beviser
   • Tag sikkerhedskopier af hele siden (filer + DB) til retsmedicinsk analyse, før du foretager ændringer.
   • Download relevante logfiler (webserver, PHP, database logfiler) og bevar tidsstempler.
3. Identificer omfang
   • Scan for webshells og bagdøre ved hjælp af betroede malware-scannere og manuel inspektion.
   • Søg efter uventede ændringer i kerne/plugin/tema filer og mistænkeligt indhold i indstillings- og postmeta-tabeller.
4. Fjern bagdøre og gendan filer.
   • Erstat kerne WordPress-filer og kendte gode plugins/temaer fra officielle kilder.
   • Fjern ukendte PHP-filer og eventuelle opdagede webshells.
   • Hvis du har en ren sikkerhedskopi fra før kompromitteringen, overvej at gendanne, og opdater derefter alt.
5. Roter legitimationsoplysninger og hemmeligheder
   • Nulstil adgangskoder for alle administrator- og privilegerede konti.
   • Rotér API-nøgler og eventuelle legitimationsoplysninger i konfigurationsfiler eller eksterne tjenester.
   • Tving nulstilling af adgangskode-e-mails til alle brugere, hvis brugerdata kan være påvirket.
6. Patch og opdater
   • Opdater det sårbare plugin til den patchede version (5.00+) og opdater alle andre plugins, temaer og WordPress-kerne til de nyeste kompatible versioner.
7. Hærdning og overvågning
   • Geninstaller eller håndhæve et WAF/virtuel patching lag.
   • Aktivér logning og alarmer for mistænkelig wp-admin aktivitet, filændringer og loginforsøg.
   • Scan regelmæssigt og udfør ugentlige integritetskontroller.
8. Rapportér
   • Hvis data eller brugerkonti kan være blevet eksponeret, følg juridiske/regulatoriske meddelelsesretningslinjer.
   • Informer hostingudbyderen, så de kan tjekke for lateral bevægelse til andre kunder.

---

Langsigtet afhjælpnings- og hærdningscheckliste

Foretag disse ændringer for at reducere risikoen for lignende problemer fremadrettet:

• Princippet om mindste privilegier
  • Overvej om bidragydere har brug for loginadgang. Brug indsendelsesformularer, post via e-mail eller manuel import hvis muligt.
  • Giv kun de minimale muligheder, der kræves for hver brugerrolle.
• Begræns redigering af plugins og temaer
  • Indstil define('DISALLOW_FILE_EDIT', sand) i wp-config.php for at forhindre redigering via admin UI.
  • Overvej at begrænse installation af plugins/temaer til betroede administratorer kun.
• Hærd uploads-mappen
  • Bloker udførelse af PHP inden for uploads, cache og andre skrivbare mapper på webserveren.
• Gennemgå og reducer plugin-overfladen
  • Fjern plugins, du ikke aktivt bruger. Hver plugin øger angrebsoverfladen.
  • Vurder plugins før installation; foretræk aktivt vedligeholdte og velanmeldte plugins.
• Anvend robust filintegritetsmonitorering
  • Oprethold checksums af kernefiler og giv besked, når uventede ændringer opstår.
• Håndhæve stærkere autentificering
  • Brug stærke adgangskoder, unikke admin-konti, og opfordr til to-faktor autentificering for admin/redaktørkonti.
• Implementer en WAF og virtuel patching
  • En god WAF kan blokere udnyttelsesforsøg selv før et plugin bliver patched.
• Regelmæssige sikkerhedskopier og gendannelsestest
  • Sørg for, at sikkerhedskopier er tilgængelige offsite, uforanderlige når muligt, og at du tester gendannelser periodisk.
• Hændelses playbook & runbooks
  • Dokumenter en intern proces for folk at følge i tilfælde af meddelelse om en sårbarhed eller aktiv kompromittering.

---

Hvordan WP-Firewall hjælper — øjeblikkelig og løbende beskyttelse

Hos WP-Firewall hjælper vi webstedsejere med at beskytte deres WordPress-installationer mod denne præcise type trussel. Vores lagdelte tilgang dækker:

• Administreret WAF med virtuel patching
  • Når en ny sårbarhed som denne offentliggøres, opbygger og implementerer vores trusselsintelligenshold signaturer for at blokere udnyttelsesforsøg for kunder, selv før hver side er opdateret.
  • Virtuelle patches er justeret for at minimere falske positiver, men blokere almindelige udnyttelsesmønstre for sårbarheden.
• Malware-scanning og oprydning
  • Fuld filscanning på tværs af temaer, plugins og uploads for at opdage webshells, PHP bagdøre og indikatorer for kompromittering.
  • Automatiske og manuelle oprydningsmuligheder for inficerede filer og ondsindede ændringer.
• OWASP Top 10 afbødning
  • Kerne regelsæt for at reducere injektion og andre almindelige vektorer (XSS, SQLi, filuploadmisbrug).
  • Ratebegrænsning og adfærdsbaseret blokering for at stoppe automatiserede masseudnyttelseskampagner.
• Overvågning og alarmer
  • Filændringsdetektion med alarmer.
  • Overvågning af login og admin-handlinger for at advare om mistænkelig bidragsyderaktivitet.
• Incident support og playbooks
  • Vejledning og eskalering via vores supportkanaler, herunder muligheder for retsmedicinsk undersøgelse og gendannelse af siden.

Disse funktioner er designet til at give dig øjeblikkelig beskyttelse, mens du opdaterer plugins og udfører fuld afhjælpning. Med andre ord: selvom en opdatering ikke er mulig det øjeblik, du læser dette, har du pålidelige afbødningsmuligheder.

---

Anbefalede nød WAF-regler, vi implementerer for lignende problemer

Når vores team ser en sårbarhed, der tillader lavprivilegeret RCE, anvender vi typisk en kombination af disse beskyttelser (tilpasset pr. side):

• Bloker anmodninger, der forsøger at skrive PHP-filer ind i skrivbare mapper.
• Bloker mistænkelige AJAX- og REST-opkald til plugin-specifikke ruter, når de kommer fra ikke-admin sessioner.
• Opdag og blokér payloads, der indeholder base64-kodede strenge eller almindelige PHP-funktionsnavne i formularfelter.
• Ratebegræns POST-anmodninger til administrative slutpunkter for at forhindre automatiseret misbrug.
• Geo-blokering for pludselige stigninger i udnyttelsestrafik, når det er passende.

Disse regler er beregnet som midlertidige virtuelle patches, indtil plugin'et er patched og testet. De reducerer eksponeringsvinduet uden at kræve nedetid for sideejeren.

---

Detektionsplaybook — forespørgsler og scanninger, der skal køres lige nu

1. Fil søgning på server (eksempler)
   • Find PHP-filer i uploads:

     find /path/to/wp-content/uploads -type f -iname "*.php"

   • Nyligt ændrede filer:

     find /path/to/wordpress -type f -mtime -14 -ls

2. Databasekontroller
   • Søg efter PHP-tags i postmeta/options:

     SELECT * FROM wp_options WHERE option_value LIKE '%<?php%' LIMIT 50;
             

3. Loganalyse
   • Se efter gentagne POSTs til admin-ajax.php eller REST-endepunkter, der kommer fra de samme IP-adresser.
   • Søg efter anmodninger, der indeholder “base64_decode”, “eval(“, eller lange kodede payloads.
4. Netværk / udgående
   • Tjek for usædvanlige udgående DNS-opslag eller forbindelser, der indikerer beaconing:

     netstat -plant | grep php
             

   • Inspicer serverens DNS-logs for usædvanlige domæneopløsninger.
5. Bruger konti
   • Liste over nyligt oprettede brugere og konti med bidragyder- eller højere roller.

Hvis du er usikker eller finder mistænkelige elementer, indsamle beviser, tage en sikkerhedskopi og kontakte din hostingudbyder eller sikkerhedsteam.

---

Virkelige udnyttelsesscenarier (illustrative)

• Scenarie A: Et site, der accepterer gæstebidragyderindlæg, giver en angriber mulighed for at udforme postmeta eller shortcode-parametre, der accepteres af plugin'et og senere evalueres af serveren. Angriberen planter en lille webshell, der forbliver i uploads og aktiveres senere gennem en udformet anmodning. Dette resulterer i vilkårlig kommandoudførelse på værten.
• Scenarie B: Plugin'et eksponerer et REST-endepunkt, der ikke tjekker kapabilitet korrekt. Et script itererer over WordPress-sider, identificerer endepunktet og udnytter det ved hjælp af bidragyderkonti, der selvregistrerer eller købes fra legitimationsdump. Udnyttelsen skriver en PHP-bagdør til temaets bibliotek og bruger den til at oprette en admin-konto.

Dette er ikke teoretisk — misbrug af bidragyderkonti og dårligt beskyttede plugin-endepunkter er et almindeligt mønster, vi observerer under masseudnyttelseskampagner.

---

Kommunikationsvejledning til webstedsejere og administratorer

Hvis dit site tillader eksterne bidragydere, tag disse skridt for at kommunikere internt eller eksternt (hvis nødvendigt):

• Intern: Informer straks dine redaktør- og administratorhold om sårbarheden og de midlertidige foranstaltninger, du tager (deaktivering, rollebegrænsninger, anvendelse af WAF-regler).
• Bidragydere: Hvis bidragyderarbejdsgange er påvirket, forklar den midlertidige suspension af publiceringsrettigheder, indtil sitet er sikret, og accepter indhold via alternative kanaler.
• Klienter / Interessenter: Hvis du administrerer sites for klienter, underret dem hurtigt om risikoen og afhjælpningsplanen. Hvis der er sket et kompromis, vær gennemsigtig omkring detektion, inddæmning og afhjælpningsskridt.

Vær forsigtig med ikke at offentliggøre tekniske udnyttelsesdetaljer for tidligt - at dele for meget kan hjælpe angribere med at skabe mere målrettede udnyttelser.

---

Sikre dit site i dag — Start med WP-Firewall gratis plan

Hvis du leder efter øjeblikkelig, administreret beskyttelse, mens du opdaterer og udfører afhjælpning, kan du overveje at starte med WP-Firewall Basic (Gratis) planen. Vores gratis plan giver essentielle beskyttelser, som hver WordPress-side har brug for: en administreret firewall med WAF-regler, ubegribelig båndbredde til beskyttelsestrafik, en malware-scanner og afhjælpning af OWASP Top 10-risici. For sider, der har brug for automatisk fjernelse eller strammere kontrol, tilføjer vores betalte niveauer automatisk malware-fjernelse, IP-blacklisting/hvidlisting, månedlige rapporter, automatisk virtuel patching og fuldt administrerede sikkerhedstjenester.

Kom i gang nu og anvend virtuel patching på din side, mens du anvender permanente opdateringer.

---

Efter afhjælpning - kontinuerlig sikkerhedsholdning.

Patching af denne plugin er nødvendigt, men ikke tilstrækkeligt. Sikkerhed er en løbende proces:

• Hold plugins, temaer og kerne WordPress opdateret - etabler en vedligeholdelsesrytme.
• Brug staging-miljøer til at validere opdateringer, før du skubber til produktion.
• Gennemgå regelmæssigt brugerroller og reducer antallet af konti med forhøjede privilegier.
• Hold automatiserede sikkerhedskopier og test gendannelsesprocedurer.
• Abonner på sårbarhedsfoder og oprethold en WAF med virtuelle patching-funktioner for at reducere eksponeringsvinduer.
• Gennemgå logs og alarmer ugentligt; opsæt e-mail/SMS-alarm for høj alvorlige hændelser.

Efter vores erfaring er sider, der kombinerer rettidig patching med proaktive WAF-beskyttelser og rollehygiejne, langt mindre tilbøjelige til at blive fuldstændig kompromitteret i de første uger efter en offentliggørelse.

---

Endelige anbefalinger (praktisk tjekliste, du kan handle på inden for de næste 24 timer).

1. Tjek plugin-version. Opdater til 5.00 eller nyere nu, hvis muligt.
2. Hvis du ikke kan opdatere med det samme: deaktiver plugin'et, begræns bidragyderlogins og anvend WAF-regler.
3. Udfør en fuld fil- og databasescanning for indikatorer på kompromittering.
4. Rotér legitimationsoplysninger og API-nøgler, hvis du mistænker eksponering.
5. Bevar logs og sikkerhedskopier til undersøgelse, hvis udnyttelse mistænkes.
6. Overvej at implementere vores gratis WP-Firewall Basic (Gratis) plan for øjeblikkelig administreret beskyttelse: https://my.wp-firewall.com/buy/wp-firewall-free-plan/
7. Efter fjernelse af sårbarheden, vedtag langsigtede hærdningspraksisser: deaktiver filredigeringsværktøjet, forbyd PHP-udførelse i uploads og reducer unødvendige plugins.

---

Om denne rådgivning

Denne analyse er skrevet af WP-Firewall sikkerhedsteamet for at hjælpe WordPress-webstedsejere, webmasters og udviklere med at forstå og reagere på det autentificerede Contributor fjernkodeeksekveringsproblem i Content Visibility for Divi Builder (CVE-2026-1829). Vores anbefalinger er praktiske og designet til at blive anvendt af webstedsejere med almindelige niveauer af teknisk adgang. Hvis du har brug for praktisk assistance, inkluderer vores administrerede planer hændelsesrespons, oprydning og løbende overvågning.

Hvis du foretrækker øjeblikkelig afbødning og ekspertløsning, så udforsk de beskyttelser og administrerede tjenester, der er tilgængelige gennem WP-Firewall, og sikr dit websted i dag: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

---

Hvis du har brug for en tilpasset afhjælpningscheckliste til dit specifikke websted (tema, tilpasninger, multisite-miljø), så svar med:

• WordPress-version
• Indholdssynlighed for Divi Builder-pluginversion
• Hosting-type (delt, VPS, administreret)
• Om du tillader contributor-konti, og hvordan de registrerer sig

Vi vil forberede en skræddersyet plan, der dækker nødafbødning, detektionstrin og en sikker opgraderingsvej.