Plugin-navn	Simple Ugle Shortcodes
Type af sårbarhed	Cross-Site Scripting (XSS)
CVE-nummer	CVE-2026-6255
Hastighed	Lav
CVE-udgivelsesdato	2026-05-04
Kilde-URL	CVE-2026-6255

Hastere: Authentificeret bidragyder gemt XSS i Simple Owl Shortcodes (<= 2.1.1) — Hvad WordPress-webstedsejere skal gøre lige nu

En nylig rapport afslører en gemt Cross Site Scripting (XSS) sårbarhed i Simple Owl Shortcodes WordPress-pluginet (<= 2.1.1), der kan initieres af en autentificeret bidragyder. Dette indlæg forklarer risikoen, virkelige angrebsscenarier, detektion og afbødningsmetoder, og hvordan WP-Firewall kan beskytte dit websted med det samme — inklusive en gratis beskyttelsesplan.

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

Kort opsummering: En gemt Cross Site Scripting (XSS) sårbarhed, der påvirker Simple Owl Shortcodes versioner <= 2.1.1 (CVE-2026-6255), blev offentligt afsløret den 4. maj 2026. En autentificeret bruger med bidragyderadgang kan oprette indhold, der bliver en vedholdende XSS payload og kan udføres, når en privilegeret bruger eller websted besøgende udfører en handling. Der er ingen officiel patch på tidspunktet for afsløringen. Nedenfor forklarer vi, hvordan dette fungerer, den reelle risiko for WordPress-websteder, hvordan man opdager udnyttelse, og umiddelbare afbødningsmuligheder — inklusive WAF virtuel patching og andre hærdningstrin, du kan anvende lige nu.

---

Hvorfor dette er vigtigt (fra et WordPress sikkerhedsperspektiv)

Gemt XSS er en af de mest almindeligt udnyttede sårbarheder i indholdsstyringssystemer. Hvad der gør denne specifikke rapport kritisk for webstedsejere er kombinationen af:

• Sårbarheden er gemt — ondsindet script skrives ind i webstedets database og serveres til fremtidige besøgende eller administratorer, snarere end kun at blive reflekteret straks i en enkelt anmodning.
• Muligheden for at blive oprettet af en autentificeret konto med bidragyderrolle — bidragydere er almindelige på multi-forfatter blogs og kan oprette indhold, som redaktører eller administratorer gennemgår.
• Ingen officiel patch er tilgængelig (på tidspunktet for afsløringen), hvilket efterlader webstedsejere udsatte, medmindre de tager kompenserende kontroller.

Succesfuld udnyttelse af en gemt XSS kan føre til sessionsstjæling, privilegiumseskalering, webstedets indholdsforvridning, ondsindede omdirigeringer og distribution af malware eller falske administratorprompter til andre brugere. Selv når den umiddelbare tekniske indvirkning synes begrænset, kan konsekvenserne for omdømme og SEO være betydelige.

---

Hurtig teknisk oversigt (hvad forskere rapporterede)

Forskere fandt, at Simple Owl Shortcodes (plugin) accepterer brugerleveret input — sandsynligvis shortcode-attributter eller indholdsfelter knyttet til dens shortcodes — og gemmer det input i databasen uden tilstrækkelig sanitering eller output-escaping. Når det gemte indhold senere gengives på en side, udføres den ondsindede payload (for eksempel en . tag, hændelseshåndterer som onmouseover, eller en javascript: URI) i offerets browser.

Nøgleoplysninger rapporteret:

• Berørt plugin: Simple Owl Shortcodes
• Sårbare versioner: <= 2.1.1
• Type: Lagret Cross-Site Scripting (XSS)
• Nødvendige rettigheder: Bidragyder (godkendt)
• CVE: CVE-2026-6255
• Rapportdato / offentliggørelse: 4. maj 2026
• Patch-status (som rapporteret): Ingen officiel patch tilgængelig ved offentliggørelse
• Forsker krediteret: MAJidox
• CVSS-score refereret af forskere: 6.5 (moderat)

Note: De præcise interne variabelnavne og skabelonkodeveje er unikke for plugin'et; generelt set er alt, der gemmer ikke-pålidelig input og senere udskriver det i HTML uden korrekt escaping, en kandidat til lagret XSS.

---

Virkelige angrebsscenarier

At forstå, hvordan en rigtig angriber kunne misbruge dette, hjælper med at prioritere modforanstaltninger. Her er praktiske angrebsstrømme:

1. Bidragyder planter payloaden:
   • En bidragyder opretter et indlæg, en side, brugerdefineret indhold eller en shortcode-post, der inkluderer ondsindet markup eller attributter (f.eks., . eller payload indlejret i en shortcode-attribut).
   • Plugin'et gemmer det indhold i databasen.
2. Admin/redaktør udløser udførelse:
   • En redaktør eller administrator åbner indlægget i redaktørens forhåndsvisning eller gennemgår det på frontenden.
   • Det ondsindede script udføres i konteksten af den privilegerede brugers browser. Hvis admin er autentificeret, kan scriptet sende autentificerede anmodninger (CSRF-lignende) eller eksfiltrere sessionscookies og tokens.
3. Angriber eskalerer:
   • Med en admins session eller evne til at udføre handlinger via deres browser kan angriberen oprette nye admin-konti, installere bagdøre, injicere kode på tværs af siden eller bruge siden til at distribuere malware til besøgende.
4. Massesudnyttelse:
   • Hvis en side tillader bidragydere (gæsteforfattere) bredt, kan angribere udnytte mange sider ved at oprette bidragyderkonti (via kompromitterede konti eller social-engineered tilmeldinger) og tilføje payloads.

Selv hvis sårbarheden kun viser indvirkning på lavere privilegerede besøgende i nogle konfigurationer, er lagret XSS en højrisiko kæde, fordi det fungerer som et springbræt til højere værdiindvirkninger (admin-overtagelse, vedvarende injektion på tværs af siden).

---

Øjeblikkelig risikovurderingscheckliste (for sideejere / administratorer)

• Har du Simple Owl Shortcodes installeret, aktivt og på version <= 2.1.1?
• Tillader du bidragydere eller lignende lavprivilegerede konti at oprette indlæg eller kortkoder?
• Gennemgår redaktører/admins indhold i browseren (frontend-forhåndsvisning) uden sanitering?
• Har du modtaget nogen advarsler i dine sikkerhedslogs eller WAF for mistænkelige POSTs, der indeholder . eller javascript: nyttelaster?
• Har du opdaterede sikkerhedskopier og overvågning på plads?

Hvis svaret på nogen af de første to spørgsmål er “ja”, skal dette betragtes som et højprioriteret operationelt punkt, indtil plugin'et er opdateret eller sårbarheden er afhjulpet.

---

Øjeblikkelige handlinger, du bør tage (ordnet efter prioritet)

1. Tjek plugin-status og opdater, hvis en opdatering bliver tilgængelig
   Hvis plugin-forfatteren frigiver en opdateret version, skal du opdatere med det samme og verificere test-siderne for eventuelle visningsregressioner.
2. Hvis der ikke er nogen opdatering tilgængelig, skal du deaktivere eller fjerne plugin'et
   Hvis funktionen leveret af plugin'et ikke er essentiel, skal du midlertidigt deaktivere eller fjerne den for at eliminere angrebsoverfladen. Dette er den enkleste og mest pålidelige afhjælpning.
3. Begræns bidragyderadgang og revider brugerkonti
   Midlertidigt tilbagekalde bidragyderprivilegier eller ændre den redaktionelle arbejdsgang, så bidragydere ikke kan offentliggøre eller indsende indhold, der vises uden gennemgang.
   Revider brugerkonti for mistænkelige tilmeldinger eller ukendte e-mails.
4. Anvend en WAF virtuel opdatering (anbefales)
   Brug din webapplikationsfirewall til at blokere udnyttelsesnyttelaster, der retter sig mod plugin'et (vi leverer regelsæt til dette - se eksempelregler nedenfor). Virtuel opdatering er hurtig og holder dit site beskyttet, selv før en opdatering fra en upstream-leverandør er tilgængelig.
5. Scann for injiceret indhold og oprydning
   Udfør en site-omfattende integritets- og malware-scanning for at finde gemte nyttelaster (søg i databasen efter ., onmouseover, javascript:, eller mistænkelige base64 blobs).
   Fjern alt ondsindet indhold, du finder, og tjek for nytilføjede admin-brugere eller ændrede kerne/plugin-filer.
6. Hærd admin-konti
   Håndhæve stærke adgangskoder, brug to-faktor autentificering for alle redaktører og administratorer, roter nøgler og adgangskoder, og udløb gamle sessioner. Overvej at tvinge logud for alle brugere efter en mistænkt hændelse.
7. Tilføj defensive HTTP-overskrifter
   Tilføj Content-Security-Policy (CSP) overskrifter for at reducere virkningen af XSS ved at forbyde inline scripts og begrænse scriptkilder.
   Brug X-Content-Type-Options: nosniff, X-Frame-Options: DENY/SAMEORIGIN, og Referrer-Policy.
8. Overvåg logs og brugeraktivitet
   Hold øget logging og alarmering for forsøg på at oprette eller redigere indlæg, der inkluderer mistænkelige payloads.
   Gennemgå nylige redaktør/admin-aktiviteter for anomalier.

---

Hvordan en WAF / virtuel patch kan beskytte dig lige nu (konkrete retningslinjer)

Når et plugin har en kendt gemt XSS, og der ikke er en umiddelbar patch tilgængelig, er en WAF med virtuel patching en af de hurtigste og mest effektive måder at mindske risikoen på. En virtuel patch blokerer ondsindede anmodninger ved kanten — før indhold når applikationen og databasen — eller blokerer levering af gemt ondsindet indhold til besøgende på siden.

Nyttige afbødningsstrategier for WAF-regler:

• Bloker POST-anmodninger, der indsender script-tags eller farlige attributter i parametre, der ofte bruges af shortcodes (f.eks. enhver parameter, der indeholder “<script“, “javascript:“, “onmouseover=”, “onerror=”, “innerHTML=”, eller mistænkelige base64 payloads).
• Bloker anmodninger med indholdstype-mismatch (f.eks. text/html i POSTs, hvor formulardata forventes).
• Rate-limite eller blokér anmodninger, der opretter flere indlæg/programmatisk indhold over kort tid (voldsom indholdsskabelse er mistænkelig).
• Nægt adgang til wp-admin-sider fra usædvanlige IP'er og kræv login-only handling for operationer, der ændrer shortcodes.
• Overvåg og blokér gemte data, der indeholder rå HTML i felter, der normalt skal være almindelig tekst.

Nedenfor er eksempler på ModSecurity-stilregler, du kan tilpasse til dit hosting/WAF-miljø. Disse er eksempler til demonstration og bør testes omhyggeligt for at undgå falske positiver.

Advarsel: Test regler i staging, før de anvendes i produktion. Overdreven aggressive regler kan bryde legitim funktionalitet (shortcodes accepterer ofte HTML eller markup).

# Example ModSecurity rule - block attempts to POST script tags or event handlers
SecRule REQUEST_METHOD "POST" "phase:2,chain,deny,status:403,msg:'Block XSS payload containing script or event handlers',log"
  SecRule REQUEST_BODY "(?i)<\s*script\b" "t:none,t:lowercase"
  SecRule REQUEST_BODY "(?i)on(mouse|error|click|load)\s*=" "t:none,t:lowercase,allow"

# Example - block javascript: URIs in parameters
SecRule REQUEST_BODY "(?i)javascript\s*:" "phase:2,deny,id:1001002,msg:'Block javascript: URI in request body'"

# Example - block encoded script tags (basic)
SecRule REQUEST_BODY "(?i)%3C%2F?script%3E" "phase:2,deny,id:1001003,msg:'Blocked encoded script tag in request body'"

# Example - block suspicious base64 blobs in fields that should be short text
SecRule REQUEST_BODY "([A-Za-z0-9+/]{100,}={0,2})" "phase:2,log,deny,id:1001004,msg:'Block suspicious large base64 payload in request body'"

# Example - whitelist control: allow html if it matches allowed patterns (be careful!)
# Not shown here — better to block and review than to try to create a broad whitelist without testing.

Hvis du bruger WP-Firewall-tjenesten, kan vores team straks skubbe målrettede virtuelle patching-regler for denne sårbarhed, tilpasset til at blokere udnyttelsesforsøg, mens det minimerer indvirkningen på legitim sidefunktionalitet.

---

Tema-niveau og kode-niveau hårdføring (midlertidige udvikler-side løsninger)

Hvis det ikke er en mulighed at fjerne plugin'et, og du ikke kan anvende en WAF-regel med det samme, kan en midlertidig tema-niveau eller mu-plugin patch hjælpe med at afbøde problemet, indtil en ordentlig plugin-patch er tilgængelig.

1. Rens output fra shortcodes før det ekkoes:
   • Når plugin'et udskriver bruger-kontrollerede attributter eller indhold, skal du sikre, at skaberne bruger escaping-funktioner:
     • esc_html() til tekst
     • esc_attr() for attributværdier
     • wp_kses_post() (eller en brugerdefineret wp_kses() tilladt liste) for renset HTML

   Eksempel: tvinge-rensning i en lille mu-plugin, der filtrerer den gengivne output fra shortcodes (konceptuelt eksempel):

   <?php
   

2. Rens gemte meta felter og shortcode attributter ved gem:

   Bruge sanitize_text_field() eller wp_kses() når du opsnapper post_meta eller shortcode indhold, der gemmes. Dette kræver, at du tilslutter dig plugin'ets gemmeflow eller generiske WordPress hooks med forsigtighed.

3. Escaping af shortcodes ved gengivelse:

   Hvis plugin'et giver hooks til gengivelse, brug add_filter til at opsnappe output og køre det gennem wp_kses_post() eller et strengere sæt regler.

Vigtig: Disse udvikler-niveau afbødninger kræver testning. De kan bryde gyldig funktionalitet (nogle shortcodes forventer HTML eller inline scripts). Brug som en midlertidig løsning, mens du får en testet patch.

---

Detektion: hvordan man finder gemte payloads og indikatorer

Hvis du mistænker, at din side kan være blevet målrettet, så kig efter disse tegn:

• Nye indlæg eller revisioner forfattet af ukendte bidragydere.
• Databaseposter (post_content, postmeta, options, brugerdefinerede tabeller), der indeholder:
  • tags
  • ved mouseover=, en fejl=, onclick= attributter
  • javascript: URIs
  • lange base64-kodede strenge
• Uventede omdirigeringer eller popups, når du ser indhold i en admin/redaktør browser session.
• Usædvanlige udgående anmodninger fra admin browser sessioner til ukendte domæner (exfiltration).
• Ændrede kerne filer eller plugin filer (tjek fil integritet).
• Mistænkelig oprettelse af admin brugere eller ændringer i kerneindstillinger.

Værktøjer og trin til at udføre en ren søgning:

• Brug en databasesøgning (via phpMyAdmin eller WP-CLI) til at søge post_indhold og postmeta:
  
  wp db query "SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%<script%';"
• Brug WP-CLI til at søge indlæg:
  
  wp post list --post_type=post,page --format=ids | xargs -n1 -I % sh -c 'wp post get % --field=post_content | grep -i "<script" && echo "Fundet i indlæg %"'
• Brug et malware scanner plugin eller ekstern scanningsservice til at gennemgå fil- og databaseindhold.
• Eksporter mistænkeligt indhold til et staging-miljø for sikker analyse (åbn ikke inficeret indhold i en browser på din admin-maskine).

---

Incident response tjekliste (hvis du finder ondsindet indhold eller tegn på udnyttelse)

1. Sæt siden i vedligeholdelses-/kun-læse tilstand (hvis muligt) for at forhindre yderligere admin handlinger og indholdsændringer.
2. Tag en fuld backup (filer og database) og et snapshot af serverlogfiler til retsmedicinske formål.
3. Fjern ondsindet indhold fra databasen (eller gendan en ren backup) og fjern eventuelle nyoprettede admin brugere.
4. Rotér alle relevante legitimationsoplysninger: admin adgangskoder, database legitimationsoplysninger (hvis kompromitteret), API nøgler og hemmeligheder gemt i wp-config.php.
5. Scann for webshells og ændrede filer. Gennemgå wp-indhold/plugins, temaer og uploads mapper.
6. Genopbyg kompromitterede filer fra en kendt god kilde (kerne / plugin / tema installationer).
7. Geninstaller eller opdater plugin'et til en patch-version, når den er tilgængelig; indtil da, fjern/deaktiver.
8. Kør scanninger igen og bekræft, at der ikke er ondsindet JS eller vedholdenhed tilbage.
9. Underret interessenter og, hvis nødvendigt, informer brugere om nulstilling af legitimationsoplysninger og risici.
10. Hærd miljøet for at forhindre fremtidig pivotering (firewall-regler, princippet om mindst privilegium, overvågning).

Hvis du bruger WP-Firewall administrerede tjenester, kan vores hændelsesrespons-team hjælpe med at triagere, rense og sikre kompromitterede sider hurtigt.

---

Anbefalinger til langvarig hærdning

• Hærd brugerroller og redaktionelle arbejdsgange:
  • Begræns bidragende konti fra at uploade filer eller oprette kortkoder.
  • Brug redaktionelle godkendelsesarbejdsgange, så redaktører kan forhåndsvise og rense indhold, før det offentliggøres.
• Hold WordPress-kernen, temaerne og plugins opdaterede.
• Brug princippet om mindst privilegium for alle konti.
• Implementer to-faktor autentificering og begræns wp-admin adgang efter IP, hvor det er muligt.
• Brug stærk, rollebaseret adgangskontrol og fjern ubrugte konti.
• Håndhæve strenge Content-Security-Policy (CSP) overskrifter for at begrænse, hvor scripts kan indlæses fra.
• Vedtag server-side scanning, WAF virtuel patching og kontinuerlig overvågning for filintegritet og unormal admin aktivitet.
• Oprethold hyppige, automatiserede sikkerhedskopier gemt off-site og test gendannelsesprocedurer.

---

Eksempel på Content-Security-Policy (CSP) for at mindske XSS påvirkning

En streng CSP kan betydeligt reducere virkningen af en XSS sårbarhed ved at forhindre inline script udførelse og fjern script indlæsning. Juster til dit sites behov (test omhyggeligt).

Content-Security-Policy:;

Noter:

• Undgå ‘unsafe-inline’ i script-src — flyt i stedet scripts til eksterne filer med subresource integritet, når du kan.
• CSP er en dybdeforsvarskontrol; kombineret med WAF og sanitering hjælper det med at sænke risikoen.

---

Hvordan WP-Firewall hjælper — praktiske beskyttelser, vi anvender

Som en applikationslag, WordPress-bevidst firewall og sikkerhedstjeneste, tilbyder vi flere mekanismer, der beskytter sider mod denne klasse af sårbarhed:

• Hurtig virtuel patching: vi implementerer målrettede regler for at blokere kendte udnyttelsespayloads for offentliggjorte sårbarheder. Dette køber tid, indtil plugin-forfattere offentliggør testede patches.
• Adfærdsbaseret detektion: vi holder øje med mistænkelige mønstre for indholdsskabelse, unormale POST-payloads og forsøg på at injicere script-tags eller begivenhedshåndterere.
• Administreret regeljustering: vi justerer regler for at blokere angrebspayloads, mens vi minimerer falske positiver for legitime anvendelser af shortcodes eller HTML.
• Post-udnyttelsesdetektion og oprydningsvejledning: vi tilbyder scanning for at opdage gemte payloads og ændrede filer samt trin-for-trin afhjælpning.
• Alarmer og rapportering: realtidsalarmer når udnyttelsesforsøg opdages, plus rapporter for at hjælpe dig med at forstå virkningen.

Hvis du driver flere websteder, eller hvis dit websted har mere end et par redaktører og bidragydere, hjælper disse beskyttelser med at reducere din operationelle belastning og mindske risikoudsættelse.

---

Praktisk eksempel: en WAF-regel justeret til Simple Owl Shortcodes udnyttelsesforsøg

Nedenfor er et konkret regel eksempel, du kan tilpasse. Dette eksempel retter sig mod anmodninger, der inkluderer mistænkelige HTML-mønstre i POST-kroppe — især dem, der sandsynligvis bruges til at injicere ondsindet script i shortcodes eller indhold.

# Block stored-XSS payloads in POST bodies where the body contains <script> or event handlers
SecRule REQUEST_METHOD "POST" "phase:2,chain,deny,status:403,log,msg:'Block potential stored XSS payload (script tag or event handler)'" \n  SecRule REQUEST_BODY "(?i)(<\s*script\b|on\w+\s*=|javascript\s*:|%3cscript%3e|%3c%2fscript%3e)" "t:none,t:lowercase,log,id:1002001"

Testning og whitelist:

• Test først i en overvågningsmode (log-only): fjern ‘deny’ og sæt ‘pass,log’ for at observere virkningen.
• Tilføj eksplicitte whitelister for kendte legitime shortcodes, der kræver HTML (meget omhyggeligt).

---

Kommunikations bedste praksis, når dit websted kan blive påvirket

• Hvis dit websted er kundevendt, forbered en kort gennemsigtig meddelelse (ingen behov for tekniske detaljer), hvis du skal tage webstedet offline for oprydning.
• Internt, samle beviser (logs, DB-poster, tidsstempler, brugerhandlinger), så en hændelsesbehandler kan handle hurtigt.
• Hvis hændelsen påvirker brugerlegitimationsoplysninger, tvinge adgangskodeændringer og kommunikere trin for brugere at tage.

---

Ofte stillede spørgsmål

Spørgsmål: Kan en bidragyder-niveau bruger virkelig føre til fuld overtagelse af webstedet?
EN: Ja. Gemte XSS er især farligt, fordi payloaden består og kan udføres i konteksten af en privilegeret bruger (redaktør/admin), når de ser eller forhåndsviser indhold. Derfra kan sessionstokens og autentificerede anmodninger misbruges.

Spørgsmål: Er en WAF nok i sig selv?
EN: En WAF er en meget effektiv, øjeblikkelig afbødning (virtuel patching), men bør bruges i kombination med kodefixer, brugerrollehårdnedgørelse, scanning, sikkerhedskopier og hændelsesresponsplaner. Forsvar i dybden er essentielt.

Spørgsmål: Vil deaktivering af shortcodes bryde mit websted?
EN: Muligvis. Mange temaer og indhold er afhængige af shortcodes. Hvis plugin'et ikke er essentielt, er det en sikker måde at fjerne angrebsoverfladen ved midlertidigt at deaktivere det, men planlæg altid og test ændringen (især på højtrafiksteder).

---

Genopretning & opfølgning

Efter anvendelse af afbødninger (WAF-regler, sandboxing, fjernelse af plugin, osv.):

• Gen-scann og bekræft, at siden er ren.
• Gendan fra en ren backup, hvis du opdager dybere kompromittering.
• Genintroducer plugin'et først, efter at en leverandørpatch er blevet verificeret, eller efter at du har en pålidelig virtuel patch på plads.
• Gennemfør en efter-hændelse-gennemgang og forbedr arbejdsgange for at forhindre lignende eksponeringer (f.eks. begræns bidragyderes muligheder).

---

Beskyt din side nu — start med vores gratis plan

Begynd straks at beskytte din WordPress-side med vores grundlæggende gratis plan. Den inkluderer essentielle beskyttelser, der stopper mange udnyttelsesforsøg, før de når din side: administreret firewall, ubegribelig båndbredde, en robust WAF, malware-scanning og afbødning for OWASP Top 10-risici. Du kan opgradere senere for automatisk malwarefjernelse, virtuel patching, månedlige sikkerhedsrapporter og premium supportmuligheder.

Læs mere og tilmeld dig her: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

---

Afsluttende ord fra WP-Firewall sikkerhedsteamet

Denne Simple Owl Shortcodes gemte XSS-afsløring er en påmindelse om, at tredjeparts plugins og brugerrettede funktioner ofte er den primære angrebsoverflade for WordPress-sider. Vi anbefaler, at du handler nu:

• Vurder din eksponering (kører du plugin'et og tillader bidragyderkonti?)
• Anvend øjeblikkelige afbødninger (deaktiver plugin'et, hvis muligt, eller virtuel patch med en WAF)
• Revider indhold og brugere for ondsindede indtastninger
• Styrk admin-arbejdsgange og overvåg aktivitet kontinuerligt

Hvis du ønsker hjælp til at triagere dette problem på din side, kan vores team hos WP-Firewall hjælpe med virtuel patching, oprydning og langsigtet hærdning. Den hurtigste vej til at stoppe udnyttelse i realtid er at blokere ondsindede indtastninger ved kanten — og at fjerne eller sanere eventuelle gemte payloads, der allerede er til stede i systemet.

Hold dig sikker, og hvis du har brug for rådgivning tilpasset dit miljø, så kontakt vores sikkerhedsteam — vi arbejder med hjemmesideejere hver dag for at lukke eksponeringsvinduer som dette, før de udvikler sig til en fuld hændelse.

— WP-Firewall Sikkerhedsteam