Beskyt dit WordPress Site

Hvad testen indeholder

Denne sikkerhedstest analyserer en WordPress-installations opsætning, headers, filadgang og konfiguration for at identificere svagheder, misconfigurations og forbedringsmuligheder. Nedenfor gennemgås alle testområder med forklaring. Hvert punkt angiver også, om fundet påvirker sikkerhedsscoren, eller om det er rent informativt.

WordPress-detektion

Testen analyserer HTML-output for at afgøre, om websitet kører WordPress, ved at lede efter karakteristiske elementer som wp-content og wp-includes. Versionsnummeret aflæses fra op til tre uafhængige kilder: generator-meta-tagget på forsiden, <generator> i RSS-feedet og ?ver= på WordPress’ egne stylesheets i wp-includes/css/. Rapporten viser, hvilke kilder versionen er aflæst fra, og advarer, hvis kilderne er uenige (typisk pga. cache). Er versionen skjult alle tre steder, vurderes den ikke.

WordPress versionskontrol

Versionen slås op i WordPress.org’s officielle versionsdata, som for hver eneste udgivne version angiver, om den er nyeste, forældet men sikkerhedspatchet eller usikker. WordPress bagudporterer sikkerhedsrettelser til ældre grene (fx 6.7.x), så en gammel version kan sagtens være fuldt patchet. Derfor vurderes sitet altid ud fra sin egen gren:

• Usikker (rødt, Kritisk): Sitet mangler én eller flere sikkerhedsudgivelser på sin egen gren. Rapporten viser hvilke, samt den mindste version, der skal opdateres til.
• Forældet, men patchet (medium): Sitet har alle sikkerhedsrettelser for sin gren, men kører ikke nyeste hovedversion. Kun nyeste version er officielt understøttet af WordPress.
• Nyeste version (grønt).

Herudover nævnes navngivne, kritiske sårbarhedskæder kun, hvor det er sikkert, at den fundne version er ramt:

• CVE-2026-63030 / CVE-2026-60137 (“wp2shell”) – aktivt udnyttet pre-auth fjernkørsel af kode via REST API’ets batch-endpoint. Version 6.9.0–6.9.4 og 7.0.0–7.0.1 er fuldt sårbare; 6.8.0–6.8.5 er ramt af SQL-injection-delen.
• CVE-2026-64638 (“XSS2Shell”) – pre-auth XSS i login-siden, der kan eskalere til kodeudførelse, hvis en indlogget administrator klikker på et forberedt link. Nævnes for 6.8.0–6.8.6, 6.9.0–6.9.5 og 7.0.0–7.0.2. Ældre grene er også ramt, men har fået rettelsen bagudporteret; de fanges af tjekket for manglende sikkerhedsudgivelser ovenfor.

SSL/HTTPS og certifikatkontrol

Testen forsøger at etablere en reel HTTPS-forbindelse til domænet – uafhængigt af om I indtastede “http://” eller “https://” i formularen – og verificerer certifikatkæden og at certifikatet matcher domænet. Derefter hentes certifikatets metadata direkte fra serveren: udsteder, gyldighedsperiode (advarsel ved under 30 dage), nøgletype og -styrke, signaturalgoritme samt den TLS-protokol, forbindelsen blev etableret med. Et certifikat med RSA-nøgle under 2048 bit eller SHA-1/MD5-signatur markeres rødt. Testen kan derimod ikke se serverens OpenSSL-version, om forældede protokoller (TLS 1.0/1.1) stadig accepteres, eller hvilke cipher suites serveren tilbyder – se Hvad testen ikke kan afgøre udefra.

Caching og CDN

Testen analyserer HTTP-headere for tegn på edge- og page-caching samt brug af CDN-lag (Cloudflare, Varnish, LiteSpeed Cache m.fl.). Dette er rent informativt og påvirker ikke sikkerhedsscoren – caching er en performance-/infrastrukturegenskab, ikke i sig selv en sikkerhedskontrol.

HTTP → HTTPS-omdirigering

Testen tilgår websitet direkte via http:// og kontrollerer, om serveren automatisk omdirigerer (301/302/307/308) til https://. Uden en tvungen omdirigering risikerer besøgende, links og bots at ende på en usikker forbindelse, selvom certifikatet er korrekt opsat.

HSTS (Strict-Transport-Security)

Testen kontrollerer om HSTS-headeren er sat, og om den har en tilstrækkelig max-age (mindst ca. 6 måneder), samt om includeSubDomains er aktiveret. HSTS tvinger browseren til kun at bruge HTTPS og forhindrer downgrade-angreb som SSL Stripping.

Server- og PHP-versionslækage

Testen undersøger Server– og X-Powered-By-headerne. Rent informativt (“none”) – security-by-obscurity-effekten er begrænset, og angribere behøver sjældent et præcist versionsnummer for at angribe WordPress, men det koster intet at skjule det via hosting-panel eller expose_php = Off.

PHP-version og kritiske PHP-sårbarheder

Afslører X-Powered-By en PHP-version, sammenholdes den med rettelserne for de kritiske PHP-sårbarheder CVE-2026-109618 / CVE-2026-109619 (fjernkørsel af kode i selve PHP-fortolkeren, rettet 21. oktober 2026 i PHP 8.5.12, 8.4.27, 8.3.36 og 8.2.35). En upstream-version under disse markeres rødt (Kritisk), og PHP 8.1 eller ældre, der ikke får officielle rettelser, markeres ligeledes rødt. Distributionsbyggede versioner (fx 8.2.7-1~deb12u1) vurderes ikke, fordi Debian, Ubuntu m.fl. bagudporterer rettelser uden at ændre versionsnummeret. Bemærk også, at nogle hostingudbydere (fx Simply.com) har mitigeret på serverniveau. Er PHP-versionen skjult, kan dette ikke testes udefra.

WP_DEBUG og synlige PHP-fejl

HTML-output scannes for synlige PHP-fejl (Notice, Warning, Deprecated), som indikerer fejlkonfiguration og kan afsløre filstier og anden intern information. Markeret “medium” – en synlig “Undefined array key” er information disclosure, men ikke i sig selv en kritisk sårbarhed.

debug.log synlighed

Testen forsøger at indlæse wp-content/debug.log. Indholdet scannes desuden for mønstre der ligner adgangskoder, API-nøgler eller tokens. Findes sådanne mønstre, eskaleres fundet til at indgå direkte i den samlede Kritisk-vurdering; findes loggen uden tydelige secrets, er den stadig markeret rødt, men trækker “kun” den samlede prioritet op til Medium.

Permissions-Policy header

Denne header styrer adgangen til browserfunktioner som kamera, mikrofon og geolocation. Rent informativt (“none”) – relevant hærdning hvis siden bruger den slags funktioner, men fravær er ikke en WordPress-sårbarhed.

Content-Security-Policy (CSP)

Testen gennemgår websitets CSP og vurderer, om den er sat, samt om den indeholder svækkelser som 'unsafe-inline' eller 'unsafe-eval' (straffes ikke – almindeligt i Elementor-baserede sites). CSP beskytter mod XSS, og frame-ancestors-direktivet er den moderne erstatning for X-Frame-Options til clickjacking-beskyttelse. Manglende CSP er markeret “medium”.

Primære sikkerhedsheadere

• X-Content-Type-Options: Forhindrer MIME-sniffing.
• Referrer-Policy: Kontrollerer hvor mange referrer-oplysninger browseren sender.
• X-Frame-Options: Legacy clickjacking-beskyttelse. Markeres kun som et problem, hvis CSP’ens frame-ancestors heller ikke er sat – de to dækker samme formål, og bør ikke straffes hver for sig.
• X-XSS-Protection: Legacy header som moderne browsere ignorerer, og som OWASP/MDN ikke længere anbefaler at aktivere. Påvirker ikke scoren uanset resultat.

Moderne browserisolation (COOP, COEP, CORP)

Disse headere beskytter mod avancerede angreb som Spectre og styrer, om websitet må dele browsing-kontekst med andre websites. Rent informativt (“none”) – de er relevante for webapps med særlige cross-origin-krav, men er ikke et generelt hærdningskrav til et almindeligt WordPress-site, og bør ikke give tre separate fejlpoint.

• Cross-Origin-Opener-Policy (COOP)
• Cross-Origin-Embedder-Policy (COEP)
• Cross-Origin-Resource-Policy (CORP)

Cookies og sessionbeskyttelse

Session- og login-cookies analyseres for Secure, HttpOnly og SameSite. Bemærk: scanneren kalder websitet uden at være logget ind, og WordPress sætter kun login-cookies for en autentificeret bruger – derfor vil dette tjek ofte ikke kunne observere nogen login-cookie overhovedet. I så fald vises det tydeligt som “kunne ikke testes eksternt uden login”, fremfor stiltiende at springes over.

Skjult/flyttet login-side

Testen tjekker om wp-login.php svarer med WordPress’ almindelige loginformular på standardstien, eller om login-siden er flyttet/skjult (fx via Solid Security, Kadence Security eller WPS Hide Login). Rent informativt (“none”) uanset resultat: det er IKKE en sårbarhedsrettelse – en angriber kan stadig forsøge brute-force via XML-RPC eller REST API’et, selvom login-siden skjules – men kan reducere støj fra automatiserede scannere og opportunistiske bots.

XML-RPC adgang

XML-RPC har historisk været et mål for brute-force og DDoS-angreb, men er stadig en legitim WordPress-funktion (bruges bl.a. af Jetpack og visse Application Passwords-integrationer). Testen sender en forespørgsel til xmlrpc.php og bekræfter et gyldigt XML-RPC-svar. Markeret “medium” – den reelle risiko opstår primært i kombination med en forældet kerne, hvilket indgår særskilt i den samlede prioritetsvurdering.

Følsomme filer

Testen forsøger at detektere om kritiske filer som wp-config.php, .htaccess og install.php utilsigtet returnerer HTTP 200 med reelt indhold. For install.php ledes der specifikt efter markører fra selve WordPress-installationsguiden (fx felter til databasenavn eller sprogvalg) i stedet for en generisk “ligner det en 404-side”-vurdering, da en reelt eksponeret installationsguide er en ægte HTML-side og ellers fejlagtigt ville blive klassificeret som beskyttet. readme.txt tjekkes stadig, men er rent informativt (“none”) – at vide, at sitet kører WordPress (og evt. et versionsnummer, der ikke nødvendigvis er korrekt), er ikke i sig selv en sårbarhed.

.git-mappe eksponering

Testen tjekker om .git/config er offentligt tilgængelig. Dette opstår typisk, når et Git-repository ved en fejl uploades sammen med sitets filer ved deploy. Er mappen åben, kan en angriber ofte downloade hele kildekoden og commit-historikken, herunder tidligere versioner af filer der kan indeholde nøgler eller adgangskoder. Indgår direkte i den kritiske prioritetsvurdering.

.env-fil eksponering

Testen tjekker om en .env-fil er offentligt tilgængelig i webroden. Sådanne filer kan indeholde database-adgangskoder, API-nøgler og andre hemmeligheder. Indgår direkte i den kritiske prioritetsvurdering.

Brugerenumerering via ?author=1

Testen tilgår /?author=1 og undersøger, om WordPress omdirigerer til en URL af typen /author/brugernavn/. Rent informativt (“none”) – WordPress Security Team betragter offentlige bruger-/forfatteridentifikatorer som ikke-følsomme, og det er tilsigtet standardadfærd. Kontrollen er en hærdnings-/informationskontrol, ikke en sårbarhed i sig selv.

Directory browsing

Tjekker om der er åben mappelisting i wp-content/uploads. Det kan give angribere indsigt i filstrukturer og uforventede uploads. Markeret “bad”.

REST API (generel adgang)

Testen undersøger om /wp-json/ er offentligt tilgængelig. Det er normalt og forventet for moderne WordPress-installationer. Rent informativt.

REST API – brugerliste

Specifikt analyseres /wp-json/wp/v2/users. Rent informativt (“none”) hvis den er offentlig – samme begrundelse som ved ?author=1: WordPress betragter brugernavne/bruger-ID’er som ikke-hemmelige. Er endpointet derimod begrænset (401/403), markeres det positivt (“good”).

security.txt

Tjekker om /.well-known/security.txt findes. Der angives kontaktinformation for sikkerhedsresearchere. Rent informativt (“none”) uanset resultat – det er governance/responsible disclosure, ikke en hærdningsforanstaltning, og bør ikke kunne løfte scoren.

Hvad testen ikke kan afgøre udefra

En ekstern scanning ser kun det, sitet viser til omverdenen. En “Lav”-prioritet betyder derfor ikke, at sitet er sikkert – kun at det, der kan ses udefra, ser fornuftigt ud. Følgende kræver adgang til sitet, serveren eller hostingudbyderen:

• PHP-version og PHP-sårbarheder: Kun synlig, hvis serveren selv afslører den. Om sitet er beskyttet mod CVE-2026-109618 / CVE-2026-109619 bekræftes i WP-admin under Værktøjer → Webstedsstatus → Info → Server eller hos hostingudbyderen.
• Serverens TLS-opsætning og OpenSSL: OpenSSL-versionen (fx om rettelserne fra 29. september 2026 er installeret), om TLS 1.0/1.1 stadig accepteres, svage cipher suites og om certifikatets private nøgle er kompromitteret. En fuld TLS-analyse kræver et dedikeret værktøj som Qualys SSL Labs.
• Plugins og temaer: Den hyppigste årsag til hackede WordPress-sites, men kan ikke opgøres pålideligt udefra.
• Alt indefra: Brugerkonti og adgangskoder, to-faktor-login, filrettigheder, backups, malware i filer eller database samt serverens øvrige software.

Kendt begrænsning ved sikkerhedsscoren

Alle tests, der påvirker scoren, vægtes i denne udgave lige tungt (good = 1 point, medium = 0,5, bad = 0), uanset reel exploitability. Den samlede Kritisk/Medium/Lav-prioritetsvurdering kompenserer for dette ved eksplicit at fremhæve de fund, der reelt er alvorlige (eksponerede secrets, kendte RCE-kæder m.m.), men selve /10-tallet bør læses som en grov pejling, ikke en præcis risikoscore. En vægtet scoringsmodel er en planlagt fremtidig forbedring.