| Plugin-navn | WP Kundeområde |
|---|---|
| Type af sårbarhed | Traversering af sti |
| CVE-nummer | CVE-2026-42661 |
| Hastighed | Medium |
| CVE-udgivelsesdato | 2026-05-03 |
| Kilde-URL | CVE-2026-42661 |
Haster: Sti Traversal Sårbarhed i WP Kundeområde (<= 8.3.4) — Hvad WordPress hjemmesideejere skal gøre nu
En dybdegående analyse af den nylige sti traversal sårbarhed (CVE-2026-42661), der påvirker WP Kundeområde plugin versioner <= 8.3.4. Risikovurdering, detektion og øjeblikkelige afbødninger fra perspektivet af en WordPress sikkerheds- og WAF-leverandør.
Forfatter: WP-Firewall Sikkerhedsteam | Dato: 2026-05-01
Oversigt: En sti traversal sårbarhed i WP Kundeområde plugin (versioner <= 8.3.4) er blevet tildelt CVE-2026-42661 og klassificeret som medium prioritet med stærkt påvirkningspotentiale (CVSS ~8.8). Dette indlæg forklarer problemet, risiciene, hvordan angribere kan udnytte det, indikatorer at se efter, og konkrete afbødningsskridt — inklusive øjeblikkelige virtuelle patchmuligheder, som en Web Application Firewall (WAF) kan tilbyde, mens du opdaterer til den patched version (8.3.5).
Indholdsfortegnelse
- Resumé
- Hvad er WP Kundeområde, og hvorfor er dette vigtigt
- Sårbarhedsoverblik (CVE-2026-42661)
- Hvorfor sti traversal er farligt — virkelige konsekvenser
- Udnyttelsesscenarier og angriberkrav
- Detektion: logs, indikatorer for kompromittering (IOCs) og retsmedicinske pegepinde
- Umiddelbare skridt, hver ejer af en side bør tage
- Hvordan en WAF kan afbøde, mens du patcher (praktiske regler og eksempler)
- Post-patch hærdning og langsigtet forebyggelse
- Hændelsesrespons og genopretningscheckliste
- Hvordan WP-Firewall hjælper med at beskytte dig nu (inklusive gratis plan)
- Endelige anbefalinger og tidslinje
Resumé
En sti traversal sårbarhed blev offentliggjort i WP Kundeområde plugin (versioner op til og med 8.3.4). Den tillader angribere med visse plugin-niveau privilegier at anmode om filer uden for de tilsigtede mapper, hvilket potentielt eksponerer følsomme filer såsom konfigurationsfiler, sikkerhedskopier eller andre fortrolige data. Udvikleren har patched dette problem i version 8.3.5 — opdatering er den definitive løsning.
Hvis du administrerer WordPress-sider, der bruger WP Kundeområde, skal du betragte dette som en hastende sikkerhedsopgave: opdater plugin'et straks. Hvis du ikke kan opdatere straks (vedligeholdelsesvinduer, kompatibilitetsverifikation osv.), skal du implementere virtuelle patches med en WAF og følge hærdningsskridtene nedenfor. Dette indlæg guider dig gennem teknisk kontekst, detektion, afbødning og genopretning — fra erfarne WordPress sikkerhedsingeniørers synspunkt.
Hvad er WP Kundeområde, og hvorfor er dette vigtigt
WP Kundeområde er et plugin, der ofte bruges af organisationer til at oprette private områder på WordPress-sider til deling af dokumenter, private sider og kundespecifikt indhold. Plugin'et kan introducere brugerdefinerede roller og slutpunkter til at servere private filer.
Fordi plugin'et interagerer med filopbevaring og brugerdefineret adgangskontrollogik, kan en sårbarhed, der tillader sti traversal, omgå tilsigtede beskyttelser og eksponere følsomt indhold. Sider, der opbevarer PII, kontrakter, fakturaer, interne dokumenter eller app-sikkerhedskopier via dette plugin, bør antage øget risiko og handle hurtigt.
Sårbarhedsoverblik (CVE-2026-42661)
- Sårbarhedstype: Sti Traversal (forkert validering af sti eller filnavn input)
- Berørte versioner: WP Kundeområde <= 8.3.4
- Patchet i: WP Customer Area 8.3.5
- CVE ID: CVE-2026-42661
- Klassifikation: Brudt Adgangskontrol / Sti Traversering (OWASP A1 klasse)
- Patchstack/CVE tidslinje (offentliggørelse): offentliggjort 1. maj 2026
Hvad problemet betyder i praktiske termer:
- Plugin'et fejler i at validere eller kanonalisere brugerleverede filidentifikatorer eller anmodningsparametre, der kortlægger til filstier.
- En ondsindet aktør, der kan nå det sårbare endpoint — og som har mindst den brugerdefinerede rolle eller privilegium, der kræves af plugin-endpointet — kan manipulere sti-værdier (for eksempel ved at bruge ../ sekvenser eller kodede traverseringsværdier) for at læse filer uden for den tilsigtede mappe.
- Dette kan tillade læsning af filer som wp-config.php, .htaccess, sikkerhedskopier, miljøfiler eller andre følsomme artefakter, der findes på webserveren.
Note: Sårbarheden er knyttet til en brugerdefineret rollecheck, hvilket betyder, at den ikke nødvendigvis kan udnyttes af anonyme besøgende på et standard WordPress-site — men roller er ofte forkert konfigureret, og nogle sider udsætter registrerings- eller lavprivilegerede brugeroprettelsesflows, der kan misbruges. Derfor er risikofladen ikke triviel.
Hvorfor sti traversal er farligt — virkelige konsekvenser
En sti traverseringssårbarhed er et højrisiko-problem, fordi det ofte fører direkte til informationslækage. De mest alvorlige konsekvenser inkluderer:
- Udsættelse af wp-config.php (databaselegitimationsoplysninger, salte, nøgler)
- Udsættelse af sikkerhedskopiarkiver (der indeholder data og muligvis legitimationsoplysninger)
- Udsættelse af private dokumenter (kontrakter, fakturaer, PII)
- Opdagelse af andre server-side hemmeligheder eller miljøfiler
- Facilitering af yderligere kompromittering (legitimationsoplysning genbrug eller lateral bevægelse)
Selv hvis direkte kodeeksekvering ikke opnås, giver de data, der opnås via traversering, ofte alt, hvad en angriber har brug for til at eskalere: databaselegitimationsoplysninger til at dump brugerkonti, SMTP-legitimationsoplysninger til at pivotere til phishing, API-nøgler til at misbruge integrationer osv.
Udnyttelsesscenarier og angriberkrav
At forstå, hvordan en angriber kan udnytte dette, hjælper med at prioritere afbødninger.
Sandsynlige angriberveje:
- Authentificeret lavprivilegeret bruger
- Hvis dit site tillader brugerregistreringer, kan en angriber oprette en konto og, gennem et sårbart endpoint, forsøge at udnytte traverseringsstier. Mange sider er afhængige af plugin-niveau rollechecks, der er utilstrækkeligt restriktive.
- Kompromitteret brugerkonto
- Hvis en konto med den krævede plugin-specifikke rolle allerede er kompromitteret (f.eks. via credential stuffing), kan angriberen bruge den konto til at få adgang til det sårbare endpoint.
- Målrettet trussel mod et site med eksponerede endpoints og forudsigelige filstier
- Angribere kan scanne efter WP Customer Area endpoints og derefter prøve traversal payloads for at enumerere filer.
Nødvendige privilegier: Sårbarheden kræver en plugin-niveau “custom role” privilegium efter design (ifølge offentliggjort analyse). Det betyder, at ren anonym udnyttelse er mindre sandsynlig — men rollefejlkonfigurationer og auto-registreringsfunktioner kan stadig muliggøre angribere.
Almindelige traversal vektorer (illustrative, ikke eksekverbare):
- ../ (dot-dot) sekvenser i parametre
- URL-encoded variations of ../ (, /)
- Null byte eller blandet kodning tricks (mindre effektive i moderne PHP, men nogle gange brugt)
- Sti normalisering bypass via Windows-stil separatorer (\) på dårligt normaliserede systemer
Vi vil ikke give konkret exploit kode her, men forsvarere skal genkende disse mønstre.
Detektion: logs, indikatorer for kompromittering (IOCs) og retsmedicinske pegepinde
Hvis du er ansvarlig for et WordPress site, der kører WP Customer Area (<=8.3.4), skal du straks tjekke følgende.
Server- og applikationsniveau indikatorer:
- Unusual GET or POST requests to WP Customer Area endpoints that include ../, , or other traversal characters in parameters.
- Anmodninger om kendte følsomme filnavne via plugin endpoints (wp-config.php, .env, .htpasswd, backup.zip, database backup filnavne).
- Uventede 200/403 svar, hvor 404'er forventes, når der forespørges om usædvanlige filstier.
- Pludselige downloads af store filer fra plugin-styrede download endpoints.
WordPress-logs (hvis tilgængelige):
- Se efter brugeraktivitet via plugin'ens custom role konti, der udfører filadgangsaktioner, de ikke burde lave.
- Autentifikationslogs, der viser nye konti oprettet eller adgangskode nulstillinger efterfulgt af filadgang.
Webserverlogfiler:
- Søg adgangslogs for traversal payloads (../ eller URL-kodede varianter) rettet mod plugin-kataloger.
- Tjek download svarkoder og svarstørrelser — store eller binære svar efter traverseringsforsøg er et rødt flag.
Filsystem:
- Tjek for nye eller ændrede filer under wp-content/uploads eller plugin-mapper, som du ikke forventede; traversal kan parres med filskrivningssårbarheder eller misbrug for at hente sikkerhedskopier, men det kan også afsløre filer efterladt af angribere.
Indikatorer for kompromittering at se efter:
- Uventet offentliggørelse af wp-config.php eller andre følsomme filindhold i logs eller på disk.
- Ukendte admin-konti eller plugin-konfigurationer ændret.
- Udbundne forbindelser, især til ukendte IP'er, fra din webserver (kan indikere eksfiltrationsværktøjer).
Hvad der skal indsamles:
- Gem logs, der dækker tidsvinduet siden offentliggørelse.
- Eksporter Apache/nginx adgangs- og fejl-logfiler samt PHP-FPM logs.
- Tag et filsystemsnapshot (kun læse-adgang) til undersøgelse. Hvis du mistænker kompromittering, overvej en retsmedicinsk tilgang først — slet ikke beviser uden omtanke.
Umiddelbare skridt, hver ejer af en side bør tage
- Opdater plugin'et til 8.3.5 (eller senere) straks.
- Dette er den eneste garanterede løsning. Opdater alle sider, der bruger WP Customer Area uden forsinkelse.
- Hvis du ikke kan opdatere straks — anvend virtuel patching med en WAF.
- Bloker traverseringsmønstre til de sårbare slutpunkter (detaljer nedenfor).
- Begræns adgangen til plugin-slutpunkter
- Begræns adgangen til IP-områder eller kun autentificerede brugere, hvis din arbejdsgang tillader det.
- Revider brugerkonti og roller
- Fjern eller begræns konti med forhøjede plugin-roller. Håndhæv stærke adgangskoder og MFA for admin-brugere.
- Roter hemmeligheder
- Hvis du opdager beviser for, at wp-config.php eller andre hemmelige filer kan være blevet eksponeret, roter DB-adgangskoder, API-nøgler og salte straks.
- Scan for kompromitteret
- Udfør en grundig malware-scanning og filintegritets-scanning. Se efter webshells, mistænkelige tidsstempelændringer og ukendte cron-jobs.
- Bevar logfiler
- Behold kopier af logs og filsnapshot til undersøgelse og overholdelse.
Hvordan en WAF kan afbøde, mens du patcher (praktiske regler og eksempler)
Hvis du administrerer dusinvis eller hundreder af WordPress-sider, kan øjeblikkelige opdateringer blive forsinket. En WAF giver en effektiv nødforanstaltning ved at blokere udnyttelsesforsøg ved kanten. Nedenfor er praktiske, implementeringsuafhængige regelanbefalinger, du kan tilpasse, uanset om du administrerer en host-niveau firewall eller plugin-baseret WAF.
Vigtig: Dette er forsvarsmønstre, ikke udnyttelsesopskrifter.
Generel strategi:
- Bloker ondsindede sti-gennemtrængningspayloads på HTTP-anmodningslaget, der retter sig mod plugin-endepunkter.
- Stram reglerne for endepunkter, der leverer filer eller accepterer filidentifikatorer.
- Tilføj positive tilladelseslister, hvor det er muligt (accepter kun forventede filnavnemønstre).
- Begræns hastigheden for mistænkelige mønstre for at bremse enhver automatiseret scanning eller brute-force.
Foreslået WAF-regelliste (konceptuel — tilpas syntaksen til din WAF):
- Bloker rå dot-dot sekvenser
- Betingelse: Anmodnings-URI, forespørgselsstreng eller specifik parameter indeholder ../ eller ..\
- Bloker handling: Afvis med 403 eller udfordring (CAPTCHA)
- Årsag: Klassisk gennemtrængningsmønster.
- Bloker almindelig URL-kodet gennemtrængning
- Condition: URI or parameters contain , / (case-insensitive), etc.
- Bloker handling: Afvis
- Årsag: Kodninger bruges til at undgå naive filtre.
- Bloker dobbeltkodede eller blandede kodningsforsøg
- Betingelse: URI dekoder til gennemtrængningsmønstre efter % dekodning mere end én gang
- Bloker handling: Afvis
- Årsag: Forhindre normalisering bypasses.
- Håndhæve strengt tilladt filnavnemønster for pluginens filparameter
- Hvis pluginen forventer fil-ID'er eller slugs (alfanumeriske + understregninger + bindestreger):
- Betingelse: Parameter matcher IKKE tilladt regex (f.eks. ^[A-Za-z0-9_\-\.]+$)
- Blok: Afvis
- Årsag: Tillad kun forventede sikre tokens.
- Hvis pluginen forventer fil-ID'er eller slugs (alfanumeriske + understregninger + bindestreger):
- Bloker anmodninger om følsomme filnavne til plugin-endepunkter
- Betingelse: Forespørgsel/URL indeholder filnavne som wp-config.php, .env, .htaccess, backup.zip
- Handling: Nægt
- Årsag: Defender-niveau sortliste for adgang til følsomme filer.
- Rate-begræns download-endepunkter
- Betingelse: Høj anmodningsrate for filrelaterede endepunkter fra enkelt-IP'er
- Handling: Dæmp eller udfordr
- Årsag: Reducer automatiserede scanninger og eksfiltrationsforsøg.
- Bloker mistænkelige brugeragenter og scanningsmønstre
- Betingelse: Kendte dårlige UA-mønstre eller tom UA kombineret med traverseringsforsøg
- Handling: Nægt
- Årsag: Automatiserede scannere bruger ofte usædvanlige UAs.
- Anvend geo- eller IP-baserede restriktioner, hvor forretningen tillader det
- Betingelse: Anmodninger til administrative eller filendepunkter, der kommer fra uventede lande/IP-områder
- Handling: Bloker eller udfordr
- Årsag: Reducer angrebsoverfladen.
- 16. Opret advarsler for blokerede begivenheder, der matcher ovenstående mønstre. Dette giver synlighed i forsøg på udnyttelse.
- For enhver match, generer alarmer til drift og registrer fuld anmodning/svar til hurtig triage.
Praktisk eksempel (pseudokode regel):
IF request.path begins_with /wp-content/plugins/wp-customer-area/ AND (params contains “../” OR params contains “” OR params matches sensitive-filenames) THEN BLOCK and ALERT.
Noter om falske positiver:
- Test regler i detekteringskun tilstand før blokering, hvis du har komplekse arbejdsgange med legitime kodede værdier.
- Brug tilladelseslister (positiv validering) frem for store sortlister, hvor det er muligt — dette reducerer falske positiver og er sikrere.
Hvorfor WAF virtuel patching er vigtigt
- En WAF giver dig tid til at teste plugin-opdateringen og rulle den ud uden at efterlade siderne helt udsatte.
- Virtuel patching stopper generiske masse-scannere og mange tilpassede udnyttelsesforsøg hurtigt, hvilket reducerer chancen for succesfuld eksfiltrering.
Post-patch hærdning og langsigtet forebyggelse
Når du har opdateret til WP Customer Area 8.3.5 eller senere, skal du følge disse hærdningstrin for at reducere fremtidig risiko:
- Princippet om mindste privilegier
- Begræns plugin-specifikke roller og kapaciteter. Fjern ubrugte roller og sørg for, at kun nødvendige brugere har adgang til fil-serverende endepunkter.
- Hærd filtilladelser
- Sørg for, at webserverbrugeren ikke kan skrive til plugin- eller kerne-mapper undtagen hvor det er nødvendigt.
- Forhindre offentlig læseadgang til mapper, der skal være private (brug filsystem-niveau beskyttelser, fjern verdenslæselige hvor det er upassende).
- Fjern eller begræns direkte filbrowsing
- Deaktiver mappeliste via webserverkonfigurationer (nginx: autoindex off; Apache: Options -Indexes).
- Brug sikker midlertidig og backup-lagring
- Hold backups uden for webroden og begræns direkte HTTP-adgang til backup-filer.
- Anvend bedste praksis for inputvalidering
- Når du opretter tilpassede endepunkter, skal du sikre, at parametre, der kortlægger til filer, valideres, kanoniseres og nægter eventuelle traversal tokens.
- Aktivér logning og overvågning
- Behold adgangslogs i mindst 90 dage (juster for overholdelsesbehov), centraliser logs, og sæt alarmer for mistænkelige mønstre.
- Automatiser opdateringer eller staging-test
- Brug et staging-miljø til at validere plugin-opdateringer og aktiver auto-opdateringer, efter du har bekræftet kompatibilitet for ikke-kritiske sider.
- Brug flerlagsbeskyttelser
- Kombiner værtshærdning, WAF-beskyttelser og overvågning for dybdeforsvar.
Hændelsesrespons og genopretningscheckliste
- Isolere
- Tag midlertidigt siden offline (vedligeholdelsestilstand) eller blokér mistænkelig trafik via WAF-regler og vært-niveau firewall.
- Bevar beviser
- Tag snapshot af serveren, databasen og logs i skrivebeskyttet form til retsmedicinsk analyse.
- Opdater og patch
- Anvend plugin-patchen (8.3.5+) straks. Patch alle andre plugins og WordPress-kernen.
- Roter hemmeligheder
- Skift databaseadgangskoder, eventuelle API-nøgler fundet i wp-config.php og WordPress-salte. Tilbagekald og genudsted legitimationsoplysninger for integrationer efter behov.
- Scan for webshells og bagdøre
- Brug flere scanning værktøjer og manuelle gennemgange for at finde injicerede PHP-filer, ændrede plugin-filer, cron-opgaver og mistænkelige poster i wp_options.
- Vurder omfanget af dataeksponering
- Bestem hvilke filer der blev tilgået, og om PII eller legitimationsoplysninger blev lækket. Kommuniker med berørte interessenter i henhold til juridiske og regulatoriske forpligtelser.
- Rens eller gendan
- Hvis kompromis er bekræftet, genskab siden fra en kendt god backup eller genudsend kerne- og plugin-filer fra betroede kilder, og gendan indhold fra en verificeret sikker backup.
- Gennemgang efter hændelsen
- Udfør en årsagsanalyse og implementer kontroller for at forhindre gentagelse. Opdater køreplaner og overvågning.
Hvordan WP-Firewall hjælper med at beskytte dig nu
Få øjeblikkelig, administreret beskyttelse med WP-Firewall Free Plan
Hvis du ønsker en hurtig måde at reducere risikoen, mens du opdaterer plugins og gennemfører kontroller, tilbyder WP-Firewall en gratis Basic-plan, der inkluderer en administreret firewall, ubegribelig båndbredde, WAF-beskyttelser, en malware-scanner og afbødning af OWASP Top 10-risici. Den gratis plan er designet til at dække kritiske angrebsveje, herunder sti-gennemgangsmønstre og almindelige fil-afsløringsforsøg — hvilket giver et praktisk sikkerhedsnet for webstedsejere, der ikke kan opdatere med det samme. Tilmeld dig WP-Firewalls Basic (Gratis) plan og sæt et erfarent sikkerhedslag foran dit WordPress-websted: https://my.wp-firewall.com/buy/wp-firewall-free-plan/
Hvis du har brug for mere avanceret automatisering, tilbyder vores Standard- og Pro-planer automatisk malwarefjernelse, IP-blacklisting/hvidlisting, månedlige rapporter, automatisk virtuel patching og administrerede tjenester, der hjælper dig med hurtigt at lukke huller uden at efterlade websteder udsatte.
Test efter patching og validering af beskyttelse
Efter opdatering af plugin'et og/eller anvendelse af WAF-regler, valider at beskyttelserne fungerer, og at du ikke har brudt legitim funktionalitet:
- Funktionel testning
- Udfør plugin-arbejdsgange i et staging-miljø. Bekræft at legitime fil-downloads og uploads fungerer.
- Test brugerrejser på tværs af roller (ejer, kunde, administrator) for at sikre, at der ikke er nogen regression.
- Sikkerhedstestning
- Kør en sårbarhedsscanning (ikke-destruktiv), der tjekker for sti-gennemgangsindikatorer og bekræfter, at endpointet opfører sig sikkert.
- Brug serverlogfiler til at teste, om blokerede anmodninger vises som tilsigtet.
- Tjek for falske positiver
- Hvis du har implementeret WAF-regler i blokeringstilstand, gennemgå logfiler for blokerede legitime anmodninger og juster hvidlister efter behov.
- Overvåge
- Hold forhøjet overvågning i 7–14 dage efter implementering. Hold øje med gentagne blokerede forsøg og eventuelle uforklarlige filadgangs hændelser.
Bedste praksis for forebyggelse i den virkelige verden for WordPress-teams
- Lager plugins & tilstedeværelse: Vær opmærksom på, hvor fil-serverende plugins er installeret, og hvem der har adgang.
- Stram registrering og rolle tildeling: Undgå automatisk registrering i roller, der kan få adgang til filer.
- Hold et staging-site til plugin-opgraderinger: Valider funktionel kompatibilitet før masseopdatering.
- Implementer sikre backup-praksisser: Opbevar backups uden for webroot og krypter dem.
- Håndhæv stærk legitimationshygiejne: MFA, unikke adgangskoder og politikker for rotation af legitimationsoplysninger.
- Brug forsvar i dybden: Kombiner host-hærdning, WAF og periodiske manuelle revisioner.
Endelige anbefalinger og tidslinje
Øjeblikkelig (inden for timer)
- Opdater WP Customer Area til 8.3.5 på alle sites.
- Hvis du ikke kan opdatere med det samme, aktiver WAF virtuel patching for at blokere traversal mønstre og begrænse hastigheden på fil-endepunkter.
- Gennemgå logs for indikatorer på traversal angreb og bevar dem.
Kortsigtet (1–3 dage)
- Tjek alle brugerroller og tilladelser relateret til pluginet.
- Rotér kritiske legitimationsoplysninger, hvis du opdager eksponering.
- Udfør en fuld site malware- og integritetsscanning.
Mellemlang sigt (1–4 uger)
- Hærd fil-tilladelser, deaktiver katalogvisning, flyt backups væk fra webroot.
- Implementer kontinuerlig overvågning og alarmering for fil-adgangs anomalier.
- Overvej en administreret beskyttelsesplan, hvis du driver flere klient-sites.
Langsigtet
- Vedtag en politik for hurtig patching kombineret med staging-verifikation.
- Implementer mindst privilegium på tværs af alle plugins og brugerdefinerede roller og hold et centralt lager af sikkerhedsaktiver.
Afsluttende tanker
Sti traversal problemer forbliver blandt de mest almindeligt udnyttede sårbarheder i webapplikationer, fordi de ofte kun kræver mindre fejl i inputvalidering for at medføre alvorlig dataeksponering. Den offentlige offentliggørelse af CVE-2026-42661 bør betragtes som en udløser til at gennemgå din samlede fil-adgangsmodel, ikke kun det enkelte plugin. Opdater straks, hærd adgang, og brug en lagdelt forsvarsstrategi — virtuel patching via en WAF er et effektivt sikkerhedsnet, mens du implementerer permanente løsninger.
Hvis du administrerer flere WordPress-sider og ønsker hjælp til at automatisere de beskyttende skridt, der er beskrevet ovenfor (administrerede WAF-regler, scanning og hærdningsskabeloner), tilbyder WP-Firewall værktøjerne og de administrerede regelsæt til at reducere eksponering og driftsbyrde. Husk: patches retter kode, men lagdelt sikkerhed forhindrer udnyttelse i risikovinduet.
Hold dig sikker, og hvis du ønsker assistance til at implementere beskyttelser på tværs af din flåde eller udføre tjeklisten for hændelsesrespons ovenfor, er WP-Firewall-teamet tilgængeligt for at hjælpe.
Referencer & yderligere læsning
- CVE-2026-42661 (offentliggørelse)
- OWASP Top Ti: Brudt adgangskontrol og sti-gennemgang baggrund
- Bedste praksis for hårdning af WordPress-plugins
