| Plugin-navn | Envira Foto Galleri |
|---|---|
| Type af sårbarhed | Cross-Site Scripting (XSS) |
| CVE-nummer | CVE-2026-5361 |
| Hastighed | Lav |
| CVE-udgivelsesdato | 2026-05-13 |
| Kilde-URL | CVE-2026-5361 |
Envira Photo Gallery Stored XSS (CVE-2026-5361) — Hvad WordPress-webstedsejere skal gøre nu
Den 13. maj 2026 blev en sårbarhed, der påvirker Envira Photo Gallery-pluginet, offentliggjort: autentificeret (forfatter) lagret Cross‑Site Scripting (XSS) i versioner <= 1.12.4, sporet som CVE‑2026‑5361. Dette problem blev rettet i version 1.12.5.
Som teamet bag WP‑Firewall — en administreret WordPress Web Application Firewall og webstedssikkerhedstjeneste — ønsker vi at give webstedsejere og administratorer en klar, praktisk briefing: hvad denne sårbarhed er, hvordan den kan udnyttes, den sandsynlige indvirkning, detektionsstrategier, umiddelbare afbødninger og langsigtet hærdning. Vi vil også forklare de beskyttelser, en moderne WAF kan give (inklusive virtuel patching), mens du anvender opdateringer og rydder op, hvis det er nødvendigt.
Dette er skrevet ud fra praktisk erfaring med hændelsesrespons og WAF-drift. Forvent klare, handlingsorienterede instruktioner, du kan anvende i dag.
Hurtig opsummering
- Berørt plugin: Envira Photo Gallery (WordPress-plugin)
- Sårbare versioner: <= 1.12.4
- Rettet version: 1.12.5
- Sårbarhedstype: Gemt Cross‑Site Scripting (XSS)
- Påkrævet privilegium: Forfatter (autentificeret bruger)
- Udnyttelseskompleksitet: Kræver brugerinteraktion (f.eks. en privilegeret bruger, der ser et tilpasset galleri eller klikker på et link)
- Rapporteret CVSS: 5.9 (medium / lav afhængigt af konteksten)
- CVE: CVE‑2026‑5361
Opdater til Envira Photo Gallery 1.12.5 eller senere straks, hvis du bruger dette plugin. Hvis du ikke kan opdatere straks, anvend de kompensatoriske kontroller, der er beskrevet nedenfor.
Hvad er gemt XSS, og hvorfor er dette vigtigt for WordPress-websteder
Lagret XSS betyder, at en angriber kan placere (lagre) ondsindet JavaScript i et sted, der senere vil blive serveret til andre brugere. I en typisk WordPress-plugin-kontekst opstår lagret XSS, når brugerleveret indhold (titel, billedtekst, felt, meta osv.) gemmes i databasen uden korrekt sanitering eller escaping, og senere outputtes på sider, hvor browsere vil udføre det som script.
Nøgleårsager til, at lagret XSS er farligt:
- Det kan køre i konteksten af en anden brugers browser: hvis en administrator eller en logget ind bruger med flere privilegier ser siden, kører det injicerede script med den brugers session og kapaciteter.
- Det muliggør sessionstyveri, uautoriserede handlinger, omdirigering, vedholdenhed og plantning af yderligere malware eller bagdøre.
- Det kan bruges som et indledende fodfæste for yderligere kompromittering af webstedet, især hvis det udføres af en administrator.
I dette specifikke tilfælde med Envira Photo Gallery tillader sårbarheden en autentificeret forfatterrolle (eller højere) at injicere lagrede scriptpayloads i galleri-relaterede felter på en måde, der vil blive udført under bestemte omstændigheder. Derfor klassificerer vi det krævede privilegium som forfatter — hvilket betyder, at enhver konto, der kan oprette eller redigere gallerier eller galleri metadata, potentielt kan lagre en payload.
Realistiske udnyttelsesscenarier
At forstå mulige angrebsveje hjælper dig med at prioritere afhjælpning.
- Angrebskæde, der involverer forfatterrollen
- En ondsindet eller kompromitteret forfatter opretter/redigerer et galleri og injicerer en scriptpayload i et felt (titel, billedtekst, beskrivelse osv.).
- Når en bruger med højere privilegier (redaktør/administrator) besøger galleriets administrationsskærm, indlægsliste eller en forhåndsvisningsside, der gengiver det felt, udføres det gemte script i brugerens browser med højere privilegier.
- Scriptet kan udføre handlinger på vegne af brugeren med højere privilegier (for eksempel oprette en ny admin-bruger, redigere indstillinger eller eksfiltrere cookies/tokens).
- Angriberen bruger derefter disse forhøjede privilegier til at plante vedholdende bagdøre eller uploade ondsindede filer.
- Besøgsudløst misbrug (offentlig visning)
- Hvis plugin'et viser det ondsindede felt på offentlige galleri-sider, kan payloaden køre i enhver besøgendes browser, hvilket muliggør omdirigeringer, ondsindet reklame eller brugermålrettede svindelnumre.
- Selvom CVSS og rådgivningen bemærker, at brugerinteraktion er påkrævet, kunne selv social engineering (sending af et tilpasset link) få en admin eller privilegeret bruger til at se payloaden.
- Massesudnyttelse vs. målrettet kompromis
- Denne type sårbarhed kan bruges i masseudnyttelseskampagner, hvor angribere tilmelder sig som forfattere på flere WordPress-sider, der tillader offentlige registreringer, eller hvor forfatterkonti er svagt styret.
- Det er også nyttigt i målrettede angreb mod en specifik side, hvor angriberen enten allerede kontrollerer en forfatterkonto eller kan købe/infiltrere en.
Øjeblikkelige handlinger (den korte tjekliste - gør disse først)
- Opdater Envira Photo Gallery til 1.12.5 eller senere.
- Dette er det eneste mest vigtige skridt. Patchning fjerner den sårbare kodevej.
- Hvis du ikke kan opdatere med det samme:
- Deaktiver midlertidigt Envira Photo Gallery-plugin'et på den live side.
- Eller begræns adgangen til plugin-skærme (se rolleændringer nedenfor).
- Sæt siden i vedligeholdelsestilstand for kritiske miljøer, mens du patcher og tester.
- Tjek forfatterkonti:
- Gennemgå alle brugere med forfatter- eller lignende roller. Fjern eller suspender eventuelle konti, du ikke genkender.
- Kræv adgangskodeændringer for forfattere og højere, hvis du mistænker kompromittering.
- Håndhæve princippet om mindst privilegium:
- Flyt brugeropgaver, der ikke kræver forfatterrettigheder, til bidragyderroller, hvor det er muligt.
- Deaktiver konto registrering, hvis det ikke er nødvendigt.
- Aktivér dine WAF-beskyttelser eller implementer virtuelle patch-regler (se WAF-sektionen nedenfor).
- Scann for indikatorer på kompromittering (IOC) og ondsindet indhold i gallerier og databaser (detaljeret nedenfor).
- Backup: tag en frisk backup (filer + DB) før du foretager omfattende ændringer, og opbevar backups offsite.
Hvis du er usikker eller har brug for hjælp, involver din webudvikler eller hostingudbyder og del denne tekniske vejledning.
Hvordan man opdager, om sårbarheden blev udnyttet på dit site
Gemt XSS efterlader forskellige artefakter afhængigt af hvordan det blev brugt. Disse er praktiske detektionstrin, du hurtigt kan udføre:
- Søg databasen efter script-tags
- Brug SQL-forespørgsler til at lede efter almindelige mønstre i plugin-tabeller:
- VÆLG * FRA wp_posts HVOR post_content LIGNER ‘%<script%’;
- VÆLG * FRA wp_postmeta HVOR meta_value LIGNER ‘%<script%’;
- Tjek eventuelle tabeller, der er præfikset med envira_ eller lignende plugin-tabeller.
- Søg efter almindelige XSS-obfuskationsmønstre
- Attackers often obfuscate script tags, e.g., “”, event handlers (onload=), javascript: URIs, encoded payloads (script).
- Forespørg efter “onerror=”, “onload=”, “javascript:”, “iframe”, “<svg onload”, eller kodede ækvivalenter.
- Inspicer galleri titler, billedtekster, beskrivelser
- I plugin UI, gennemgå nyligt oprettede/opdaterede gallerier og undersøg titler, billedtekster, slugs og eventuelle brugerdefinerede HTML-felter for uventet indhold.
- Webserverlogfiler & WAF-logfiler
- Se efter usædvanlige POST-anmodninger til gallerioprettelses-/redigeringsendepunkter og enhver adgang fra usædvanlige IP'er på tidspunkter, hvor du ikke foretog ændringer.
- Tjek for gentagne indsendelsesmønstre fra enkelt-IP'er, hvilket muligvis indikerer automatiserede forsøg.
- Browserhistorik & admin-sessioner
- Hvis du mistænker tyveri af admin-sessioner, skal du tjekke for mistænkelige cookies eller sessions tokens i logfiler eller for usædvanlig admin-aktivitet i WordPress aktivitetslogfiler (plugins som aktivitetslog kan hjælpe).
- Filsystemændringer
- Kig efter nytilføjede PHP-filer, ændrede plugin-/tema-filer eller filer i uploads-mapper med mistænkelige filnavne (f.eks. php-filer i /wp-content/uploads). Opbevaring af XSS-udnyttelse går ofte forud for eller ledsager filuploads/bagdøre.
- Eksterne indikatorer
- Hold øje med Google Safe Browsing eller hostingudbyderens advarsler, uventede omdirigeringer eller klager fra brugere om ondsindet adfærd.
Hvis du finder injicerede scripts, skal du behandle dette som et kompromis: isoler, rengør og følg retningslinjerne for hændelsesrespons nedenfor.
Trin-for-trin afhjælpning og oprydning (hvis du finder IOCs)
Hvis du opdager ondsindede payloads eller beviser for udnyttelse, skal du følge disse trin i rækkefølge. Hvis du er usikker, skal du få professionel hjælp.
- Karantæne siden
- Sæt siden i vedligeholdelsestilstand og deaktiver brugerregistreringer.
- Hvis det er muligt, skal du frakoble siden fra netværket eller begrænse indgående adgang under analysen.
- Snapshot/Sikkerhedskopi
- Lav en kopi af de nuværende filer og DB til retsmedicinske formål og offline analyse før rengøring.
- Opdater plugin til 1.12.5 (eller nyeste)
- Hvis plugin'et selv indeholder bagdøre eller ændrede filer, kan en simpel opdatering ikke være nok - men du skal stadig lappe sårbarheden.
- Fjern det ondsindede indhold
- Brug databaseforespørgsler til at fjerne gemte script-tags eller ondsindede meta-indgange:
- Eksempel (kør forsigtigt):
- OPDATER wp_posts SÆT post_content = ERSTAT(post_content, ‘’, ”) HVOR post_content LIGNER ‘%<script%’;
- Vær forsigtig: ændringer er irreversible, medmindre du har pålidelige sikkerhedskopier.
- Gendan rene filer
- Erstat ændrede plugin-/tema-filer med kendte gode kopier fra officielle plugin-udgivelser.
- Hvis du finder PHP-filer i /wp-content/uploads, skal du fjerne dem efter gennemgang.
- Roter legitimationsoplysninger og hemmeligheder
- Nulstil adgangskoder for alle admin/redaktør/forfatterkonti.
- Nulstil API-nøgler, tokens og servicelegitimationsoplysninger, der bruges af siden.
- Tjek for vedholdenhed
- Søg wp_options, planlagte opgaver (wp_cron), mu-plugins og webhooks for vedholdenhedsmekanismer.
- Se efter mistænkelige planlagte begivenheder eller ukendte cron-jobs.
- Scan igen
- Kør en malware-scanning på siden for at bekræfte fjernelse.
- Scann igen efter rengøring for at sikre, at der ikke er skjulte bagdøre tilbage.
- Hærdning og forebyggelse
- Anvend de forebyggende foranstaltninger i næste afsnit (WAF-regler, mindst privilegium, inputvalidering, CSP, auto-opdateringer).
- Rapportering efter hændelsen
- Dokumenter tidslinjen, fund, afhjælpningstrin og lærte lektioner.
- Overvej ekstern rapportering, hvis følsomme data blev eksponeret.
Hvordan en WAF (og WP-Firewall) hjælper: virtuel patching og detektion
Mens den definitive løsning på en kode-sårbarhed er at opdatere plugin'et, giver en korrekt konfigureret Web Application Firewall (WAF) dig afgørende tid og beskyttelse — især i administrerede eller højrisiko-miljøer, hvor øjeblikkelige plugin-opdateringer ikke er mulige.
Her er hvordan en WAF hjælper i dette tilfælde:
- Virtuel patching
- WAF'en kan blokere eller sanere anmodninger, der forsøger at udnytte de sårbare slutpunkter (for eksempel POST-anmodninger, der inkluderer script-tags eller mistænkelige payload-mønstre sendt til gallerioprettelses-/redigeringsslutpunkter).
- Virtuel patching er et nødbeskyttelse: det forhindrer angreb mod sårbar kode uden at ændre plugin-kildekoden.
- Blokering af ondsindede payloads
- WAF'en kan opdage og blokere almindelige XSS-mønstre (script-tags, hændelseshåndterere, javascript: URIs, kodede payloads) i både POST-kroppe og URL-parametre.
- Den kan håndhæve validering, der fjerner eller afviser input, der indeholder eksekverbart indhold.
- Rate-limiting og bot-mitigation
- En WAF kan begrænse anmodningshastigheder og dæmpe mistænkelig adfærd (f.eks. gentagne formularindsendelser) for at frustrere automatiserede udnyttelsesforsøg.
- Adgangskontroller efter rolle og slutpunkt
- Anvend regler for at begrænse adgangen til admin- eller plugin-slutpunkter til specifikke IP'er eller intervaller, eller kun til brugere, der præsenterer en gyldig session og forventede cookie-mønstre.
- Alarmering og logning
- WAF-logfiler giver tidlige detektionssignaler og beviser for angrebsforsøg, nyttige til hændelsesrespons og retsmedicinsk analyse.
- Beskyttelse efter kompromittering
- Selv efter et indledende kompromis kan en WAF forhindre laterale handlinger (for eksempel blokere forsøg på at inkludere eksterne payloads eller blokere udgående forbindelser i nogle opsætninger).
Hos WP‑Firewall implementerer vi rutinemæssigt skræddersyede virtuelle patches for nye plugin-sårbarheder, der blokerer exploit payloads, så snart en ny advisering offentliggøres. Virtuel patching er ikke en erstatning for opdatering, men det er en effektiv nødforanstaltning for sider, der ikke kan patches med det samme.
Anbefalede WAF-regel eksempler (konceptuelle)
Nedenfor er konceptuelle regelmønstre, som en WAF hurtigt bør anvende for denne type lagret XSS-risiko. Implementeringsspecifikationer afhænger af dit WAF-system og pluginets endpoint-navne. Inkluder ikke rå exploit payloads i logs, der kan udsætte brugere eller systemer.
- Bloker eller saniter POST/PUT-anmodninger til plugin-endpoints, hvor gallerier oprettes/opdateres, hvis payloads inkluderer:
- “<script”, “script”, “onerror=”, “onload=”, “javascript:”, “svg onload”, or other event handlers.
- Afvis indholdstype-mismatch for filuploads (tillad kun forventede billed MIME-typer).
- Afvis formularindsendelser, hvor tekstfelter indeholder tags eller HTML, medmindre det er eksplicit tilladt og saniteret af serveren.
- Dæmp gentagne forsøg på at oprette gallerier pr. IP-adresse for at blokere brute force eller masseindsendelsesforsøg.
- Bloker brugen af iframe, objekt, embed-tags inde i plugin-indholdsfelter.
Hvis du bruger WP‑Firewall, vil vores team implementere tilpassede regelsæt for denne specifikke sårbarhed, der beskytter din side på få minutter, mens du planlægger opdateringer og oprydning.
Hærdningsanbefalinger for at reducere fremtidig XSS-risiko
Behandl denne sårbarhed som en mulighed for at hæve din sikkerhedsbaseline. Disse er operationelle ændringer, der reducerer din eksponering:
- Håndhæve mindst privilegium og interne politikker
- Tildel kun forfatter- eller højere roller til betroede brugere.
- Implementer multifaktorautentifikation for alle redaktør/admin-konti.
- Hærd indholdsintrædelsesveje
- Begræns muligheden for at indtaste HTML i felter, der ikke kræver det.
- Hvis HTML er nødvendigt, anvend en streng HTML-sanitizer, der kun tillader hvidlistede tags.
- Brug auto-opdateringspolitikker
- Aktiver auto-opdateringer for plugins, hvor det er passende, eller brug en staging-arbejdsgang, der muliggør hurtig test, før opdateringer rulles ud til produktion.
- Implementer Content Security Policy (CSP)
- En striks CSP (f.eks. forbyde inline scripts) reducerer risikoen for nogle XSS-varianter. Bemærk: CSP er en forsvar-i-dybden kontrol og kræver omhyggelig testning.
- Sanitere og undslippe ved output
- Plugin- og temaudviklere skal undslippe al output. Webstedsejere bør foretrække plugins, der renser input og undslipper output.
- Overvåg for mistænkelig aktivitet
- Implementer aktivitetslogs for brugerhandlinger (oprettelse/redigering af indlæg, installation af plugins) og gennemgå dem regelmæssigt.
- Begræns brugerregistrering og automatiser verifikation.
- Hvis dit websted tillader offentlige registreringer, kræv e-mailverifikation og moderation før kontooprettelse.
- Regelmæssig scanning og penetrationstest.
- Planlæg periodiske sårbarhedsscanninger og tests for at finde problemer, før angribere gør det.
Praktiske SQL- og WP-CLI-tjek (eksempler).
Brug disse som startpunkter for efterforskning. Tag altid backup, før du kører destruktive kommandoer.
- Find indlæg med script-tags:
wp db query "SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%<script%' LIMIT 100;"
- Find meta, der indeholder mistænkelig HTML:
wp db query "SELECT post_id, meta_key FROM wp_postmeta WHERE meta_value LIKE '%<script%' LIMIT 100;"
- Søg uploads efter PHP-filer (farlige):
find wp-content/uploads -type f -name "*.php"
- List brugere med forfatter+ roller:
wp bruger liste --rolle=forfatter
- Tving adgangskodeændring for rolle:
wp bruger opdatering --bruger_adgang=
Hvis du ikke er komfortabel med disse kommandoer, bed din administrator eller administrerede sikkerhedsudbyder om at køre dem.
Indikatorer for kompromittering (IoCs) at se efter
- Nyoprettede admin-brugere eller ændringer til brugerroller, du ikke har godkendt.
- Uventede indlæg eller gallerier med mærkeligt indhold eller kodede strenge.
- PHP-filer opdaget i /wp-content/uploads.
- Underlige udgående forbindelser, der stammer fra dit websted (tjek hostinglogs).
- WAF-advarsler for XSS-mønstre, der retter sig mod dine galleri-endepunkter.
Hvis du finder nogen af disse, skal du behandle det som hastende og starte remediation-tjeklisten ovenfor.
Incident response plan (højt niveau)
- Opdag: brug scanningerne og forespørgslerne ovenfor + WAF-advarsler.
- Indhold: deaktiver den sårbare plugin eller anvend virtuel patching; begræns brugeradgang.
- Udslet: fjern injiceret indhold, erstat modificerede filer, roter hemmeligheder.
- Gendan: gendan tjenester, overvåg nøje for reinfektion.
- Lærdomme: opdater hændelsesplaybooks og hårdningspolitikker.
WP‑Firewall-kunder har mulighed for at modtage administreret hændelsessupport og hurtig virtuel patch-udrulning, mens de renser og opdaterer plugins.
Hvorfor rettidig patching betyder noget (og hvorfor vi presser WAF + opdatering sammen)
Patching af plugin fjerner den faktiske sårbarhed, men virkelige operationer skaber ofte forsinkelse mellem offentliggørelse og opdatering (ændringskontrol, test, forretningsbegrænsninger). I den periode:
- Virtuel patching giver dig forsvar, mens du planlægger opdateringer.
- Fuld remediation kræver både kodefix og oprydning, hvis udnyttelse er sket.
- WAF-regler reducerer risikoen for masseautomatiseret udnyttelse og giver sikkerhedsteams logdata til retsmedicinsk analyse.
Vi anbefaler en kombineret tilgang: anvend virtuelle patches fra WP‑Firewall (hvis du er kunde), og planlæg derefter øjeblikkelige plugin-opdateringer i et kontrolleret vedligeholdelsesvindue. Efter det, udfør oprydningsscanninger og privilegiegennemgange.
Kommunikation med interessenter
Når du underretter webstedsejere, kunder eller interne interessenter:
- Vær gennemsigtig omkring sårbarheden og den potentielle indvirkning.
- Del remediation-tidslinjen: virtuel patch anvendt (tid), plugin opdateret (tid), scanninger afsluttet (tid).
- Dokumenter handlinger og bevar logs til eventuel nødvendig overholdelse eller retsmedicinsk gennemgang.
Få beskyttelse nu: Få øjeblikkelig gratis beskyttelse med WP‑Firewall
Hvis du ønsker en hurtig, omkostningsfri måde at få defensiv dækning, mens du håndterer opdateringer, så overvej vores gratis Basisplan. Den giver essentiel beskyttelse, der er særligt nyttig for nyligt offentliggjorte plugin-sårbarheder:
- Grundlæggende (Gratis): essentiel beskyttelse — administreret firewall, ubegribelig båndbredde, WAF, malware scanner og afbødning for OWASP Top 10 risici.
- Standard ($50/år): alt i Basic plus automatisk fjernelse af malware og muligheden for at blackliste/whiteliste op til 20 IP-adresser.
- Pro ($299/år): alle standardfunktioner plus månedlige sikkerhedsrapporter, automatisk sårbarheds virtuel patching og premium managed-service tilføjelser.
Tilmeld dig den gratis Basic-plan og få et administreret WAF-regelsæt hurtigt implementeret for at beskytte dit site, mens du opdaterer plugins og gennemgår konti:
https://my.wp-firewall.com/buy/wp-firewall-free-plan/
(Hvis du administrerer flere sites eller har brug for accelereret hændelsesrespons, giver vores Standard- og Pro-niveauer automatiseret oprydning og virtuel patching, der kan reducere tid-til-afbødning betydeligt.)
Endelig tjekliste — hvad du skal gøre lige nu (10 minutter til 24 timer)
- Opdater Envira Photo Gallery til 1.12.5 (eller deaktiver plugin) — så hurtigt som muligt.
- Gennemgå og verificer alle forfatterkonti — fjern eller suspender ukendte konti og tving adgangskodeændringer.
- Hvis du har en WAF, skal du sikre, at reglerne er aktive for XSS-mønstre og galleri-endepunkter.
- Kør hurtige DB-søgninger efter <script og andre mistænkelige strenge i indlæg, postmeta og plugin-tabeller.
- Tjek uploads for uventede PHP-filer.
- Rotér administratoradgangskoder og API-tokens, hvis du mistænker kompromittering.
- Tag backup af det nuværende site snapshot til retsmedicinsk analyse.
- Planlæg en fuld malware-scanning og en dybere hændelsesrespons, hvis du finder IOCs.
- Overvej at aktivere CSP og stramme input/output-sanitization for indgangspunkt.
- Tilmeld dig WP-Firewall beskyttelse (gratis plan) for administreret WAF og malware-scanning, mens du arbejder med afhjælpning: https://my.wp-firewall.com/buy/wp-firewall-free-plan/
Afsluttende tanker fra WP‑Firewall
Denne Envira Photo Gallery gemte XSS-advarsel er en påmindelse om, at WordPress-økosystemer er dynamiske: kraftfulde plugin-funktioner er ofte ledsaget af angrebsoverflade. Den hurtigste måde at forblive sikker på er en lagdelt tilgang:
- Hold software opdateret,
- Håndhæve mindst privilegium og stærk autentificering,
- Brug en WAF, der kan give virtuel patching og logbeviser,
- Og oprethold overvågnings- og backuppraksis.
Hvis du har brug for hjælp til at implementere nogen af de ovenstående trin - fra virtuel patch-udrulning til retsmedicinsk oprydning - er vores sikkerhedsteam klar til at hjælpe WP‑Firewall-kunder. Selv hvis du er ejer af en lille hjemmeside, giver den gratis Basic-plan dig øjeblikkelig administreret WAF-dækning og scanning for at reducere risikoen, mens du retter og renser.
Hold dig sikker, og behandl plugin-opdateringer som kritiske - ikke valgfrie.
— WP-Firewall Sikkerhedsteam
Referencer og yderligere læsning
- Leverandørens sikkerhedsanbefaling og CVE: CVE‑2026‑5361 (Envira Photo Gallery gemt XSS)
- Generel XSS-afbødning og bedste praksis: OWASP XSS Forebyggelses Cheat Sheet
- WordPress-hærdningsretningslinjer og anbefalinger til mindst privilegeret adgang
(Hvis du ønsker praktisk hjælp med scanning, virtuel patching eller hændelsesrespons, tilmeld dig på https://my.wp-firewall.com/buy/wp-firewall-free-plan/ og vores team vil prioritere vejledt support til denne rådgivning.)
