Pluginnaam	voegvrije ruimte toe
Type kwetsbaarheid	CSRF
CVE-nummer	CVE-2026-6701
Urgentie	Laag
CVE-publicatiedatum	2026-05-04
Bron-URL	CVE-2026-6701

Cross-Site Request Forgery (CSRF) gekoppeld aan Stored Cross‑Site Scripting (XSS) in addfreespace <= 0.1.3 — Wat WordPress-site-eigenaren moeten weten en doen

Een recent onthulde kwetsbaarheid die van invloed is op de voegvrije ruimte toe WordPress-plugin (versies <= 0.1.3) is toegewezen CVE‑2026‑6701. De kwetsbaarheid is een CSRF (Cross‑Site Request Forgery) probleem dat kan worden gekoppeld aan een opgeslagen XSS (Cross‑Site Scripting) toestand. Hoewel de algehele CVSS-score relatief laag is (4.3), kan het risico in de echte wereld hoger zijn dan het nummer suggereert — vooral wanneer aanvallers sites targeten in massacampagnes of vertrouwen op het misleiden van bevoorrechte gebruikers om te interageren met een vervaardigde link of pagina.

Als het beveiligingsteam voor WP‑Firewall willen we uitleggen, in eenvoudige taal en met specifieke richtlijnen, wat dit probleem betekent, hoe het kan worden misbruikt, hoe je exploitatie kunt detecteren, en — het belangrijkste — wat je nu kunt doen om je sites te beschermen. Deze gids is geschreven voor site-eigenaren, beheerders, ontwikkelaars en hostingteams.

---

Executive summary (snelle conclusies)

• Een kwetsbaarheid in addfreespace (<= 0.1.3) stelt een aanvaller in staat om verzoeken in te dienen die niet zijn beschermd tegen CSRF. Als een bevoorrechte gebruiker (beheerder of andere hooggeprivilegieerde rol) wordt misleid om een kwaadaardige pagina te bezoeken of op een kwaadaardige link te klikken, kan de aanvaller JavaScript-payloads opslaan in de site (opgeslagen XSS).
• Opgeslagen XSS uitgevoerd in een admin-context kan leiden tot accountovername, privilege-escalatie, datadiefstal of het installeren van persistente achterdeuren.
• Er is op het moment van publicatie geen officiële plugin-patch beschikbaar. Onmiddellijke mitigaties worden sterk aanbevolen.
• Aanbevolen onmiddellijke acties: deactiveer of verwijder de plugin; beperk de toegang tot de plugin-beheerpagina's; pas WAF-regels of virtuele patches toe; scan op geïnjecteerde scripts en verdachte wijzigingen; reset admin-gegevens en roteer sleutels; en implementeer langdurige verharding.
• WP‑Firewall-gebruikers kunnen virtuele patching, beheerde WAF-regels en actieve scanning toepassen om het risico onmiddellijk te verminderen.

---

Waarom CSRF gekoppeld aan opgeslagen XSS gevaarlijk is (in menselijke termen)

CSRF en XSS zijn verschillende aanvalstypen, maar wanneer ze worden gecombineerd, worden ze krachtig:

• CSRF: Een aanvaller misleidt een ingelogde gebruiker (vaak een beheerder) om een actie uit te voeren die ze niet van plan waren — bijvoorbeeld door hen te laten klikken op een link of een webpagina te bezoeken die een verzoek doet aan de kwetsbare site. Correct gecodeerde WordPress-beheeracties bevatten nonce-controles en capaciteitscontroles om dit te voorkomen. In dit geval faalde de plugin om de oorsprong/nonce correct te valideren.
• Opgeslagen XSS: Als een aanvaller willekeurige JavaScript kan laten opslaan in de database van de website (bijv. in een pluginoptie of aangepast veld), zal die code worden uitgevoerd telkens wanneer de opgeslagen inhoud wordt weergegeven in de admin- of frontend-context zonder juiste escaping.

Koppelen: Een niet-geauthenticeerde aanvaller maakt een pagina die een POST/GET indient naar het kwetsbare plugin-eindpunt op de achtergrond of wanneer een sitebeheerder deze bezoekt. Als de plugin de JavaScript-payload van de aanvaller opslaat (en deze later zonder escaping weergeeft), wordt de payload uitgevoerd in de context van de browser van de beheerder. Van daaruit kan een aanvaller authenticatiecookies stelen, acties uitvoeren als die gebruiker (berichten maken, plugins/thema's installeren, gegevens exporteren) en persistente toegang verkrijgen.

Zelfs als een aanvaller de beheerder nodig heeft om één interactie uit te voeren (bijv. op een link klikken), kan die enkele klik alles zijn wat ze nodig hebben om over te schakelen naar een volledige compromittering.

---

Technische oorzaken (wat er misging)

Op basis van de gerapporteerde details en typische exploitpatronen geeft de keten meestal de volgende fouten in de plugin-code aan:

1. Ontbrekende CSRF-bescherming
   • Geen gebruik van WordPress nonces (bijv. wp_create_nonce / check_admin_referer) voor statusveranderende acties.
   • Geen validatie van de aanvraagbron of referer-header om te waarborgen dat de aanvraag afkomstig is van een vertrouwde admininterface.
2. Onvoldoende capaciteitscontrole
   • Plugin-eindpunten hebben mogelijk geen juiste gebruikerscapaciteitscontroles (current_user_can) of handhaven de juiste capaciteit voor de taak.
3. Ontbrekende of onvoldoende gegevenssanitatie en output-escaping
   • Gevaarlijke door gebruikers aangeleverde gegevens worden zonder sanitatie in de database opgeslagen (bijv. met sanitize_text_field, wp_kses_post) en later zonder escaping weergegeven (bijv. esc_html, esc_attr, of juiste kses-filtering).
4. Admininterfaces die schrijfbare eindpunten blootstellen die toegankelijk zijn via niet-geauthenticeerde HTTP-methoden
   • Actiehooks of AJAX-eindpunten die POST-aanvragen accepteren zonder de juiste bescherming.

Het nettoresultaat: een aanvaller kan een statuswijziging (inhoud opslaan) activeren met de browser van een slachtoffer, en de opgeslagen inhoud kan later worden weergegeven en uitgevoerd.

---

Hoe een aanval zich typisch zou ontvouwen (hoog niveau)

1. De aanvaller identificeert het kwetsbare plugin-eindpunt (bijvoorbeeld een admin-actielink gebruikt door addfreespace).
2. De aanvaller maakt een webpagina die een POST (of GET) naar dat eindpunt maakt met een payload die JavaScript bevat (een opgeslagen XSS-vector). De formulierindiening bevat de parameters die door de plugin worden verwacht.
3. Een administrator (of een andere bevoegde gebruiker) bezoekt de kwaadaardige pagina of klikt op een link terwijl hij is geauthenticeerd op de kwetsbare WordPress-site.
4. Omdat de plugin geen CSRF-bescherming heeft, wordt de aanvraag geaccepteerd en wordt de kwaadaardige JavaScript in de database opgeslagen (bijv. in een optie, postmeta of plugin-gecontroleerd veld).
5. Wanneer de site (of de adminpagina) later die opgeslagen waarde zonder sanitatie/escaping weergeeft, wordt de JavaScript uitgevoerd in de context van de browser van de admin.
6. De JavaScript kan dan:
   • Cookies of lokale opslag lezen (en deze exfiltreren);
   • Geauthenticeerde aanvragen doen met de inloggegevens van de admin (bijv. nieuwe admin-gebruikers aanmaken, plugins installeren);
   • Laad externe scripts om verdere acties uit te voeren of om persistentie te behouden.

Opmerking: De belangrijkste stap is dat de bevoegde gebruiker een actie uitvoert (bijv. een pagina bezoeken). Zonder die interactie kan CSRF normaal gesproken niet worden geactiveerd. Dat gezegd hebbende, klikken veel beheerders op links of openen ze pagina's, en bedreigingsactoren maken op grote schaal gebruik van dat gedrag.

---

Impact — wat aanvallers kunnen bereiken

Opgeslagen XSS uitgevoerd in een administratieve browsersessie kan mogelijk maken:

• Overname van accounts (stelen van sessiecookies of OAuth-tokens).
• Creatie van nieuwe administratieve gebruikers.
• Installatie van achterdeurtjes (kwaadaardige plugins/thema's) of geplande taken die persistentie behouden.
• Gegevensexfiltratie: export van berichten, media of gebruikersgegevens.
• Defacing van de site of injectie van drive-by malware om bezoekers te infecteren.
• Pivoteren naar hostingcontrole of database-toegang via verdere exploitatie.

Hoewel de CVSS laag is, kan de zakelijke impact ernstig zijn als de aanvaller persistentie bereikt of een productie-site overneemt.

---

Onmiddellijke acties die je moet ondernemen (incident-respons stijl)

Als je WordPress-sites draait die addfreespace (<= 0.1.3) gebruiken, behandel de situatie als urgent:

1. Deactiveer de plugin nu
   • Log in op wp-admin en deactiveer addfreespace. Als je geen toegang hebt tot wp-admin, hernoem de pluginmap via SFTP/SSH (wp-content/plugins/addfreespace -> addfreespace.gehandicapt).
2. Verwijder de plugin
   • Als je het niet strikt nodig hebt, verwijder het dan uit de codebase. Soms is het verwijderen van de plugin de veiligste kortetermijnoptie totdat een gepatchte versie wordt uitgebracht.
3. Zet de site in onderhoudsmodus terwijl je onderzoekt
   • Verminder het aanvalsvlak terwijl je scant.
4. Pas onmiddellijk WAF/virtuele patching toe.
   • Blokkeer verzoeken naar de admin-eindpunten van de plugin en sta verdachte POST-verzoeken met scriptachtige payloads niet toe.
   • Als je WP‑Firewall gebruikt, schakel dan de beheerde WAF-regels en virtuele patching in voor deze kwetsbaarheid om exploitatiepogingen te blokkeren, zelfs terwijl de plugin aanwezig blijft.
5. Scan op geïnjecteerde payloads en verdachte DB-invoeren.
   • Zoek in berichten, opties, gebruikersmeta en andere opslag naar <script, onerror=, onload=, of andere JS-gebeurtenisbehandelaars die onverwacht lijken.
   • Voorbeeld (defensief, voer uit als admin via WP‑CLI of databaseclient):
     • wp db query "SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%<script%'"
     • wp db query "SELECT option_name FROM wp_options WHERE option_value LIKE '%<script%'"
   • Opmerking: De exacte bovenstaande queries gaan uit van standaard tabelprefixen. Pas aan voor aangepaste prefixen en productieveiligheid.
6. Draai inloggegevens en geheimen
   • Reset wachtwoorden voor alle beheerdersgebruikers.
   • Draai API-sleutels, serviceaccountreferenties en sleutels in wp-config.php als je vermoedt dat er een compromis is.
7. Beoordeel gebruikersaccounts en rollen
   • Zoek naar onverwachte beheerdersaccounts of gebruikers met verhoogde privileges.
8. Bekijk server- en toegangslogs
   • Inspecteer webserverlogs en auditsporen op verdachte POST-verzoeken of verzoeken naar plugin-eindpunten.
9. Herstel vanaf een bekende goede back-up als je wijzigingen detecteert die je niet veilig kunt schoonmaken.
   • Als je achterdeurtjes of onverklaarde wijzigingen vindt, kan een schone herstel de snelste oplossing zijn.
10. Versterk admin toegang
    • Handhaaf 2‑factor authenticatie (2FA) voor alle bevoorrechte accounts.
    • Beperk de toegang tot het admingebied per IP indien mogelijk.
    • Gebruik sterke, unieke wachtwoorden en een accountvergrendelingsbeleid.

---

Hoe een opgeslagen XSS van deze kwetsbaarheid te detecteren (indicatoren van compromittering)

Zoek naar de volgende tekenen:

• Onverwachte JavaScript in berichten, pagina's, opties of widgetinhoud.
• Nieuwe admin gebruikers of onverwachte wijzigingen in gebruikersrollen.
• Admin interface-inhoud die vreemde waarschuwingen, pop-ups of omleidingen weergeeft.
• Uitgaande verzoeken van de site naar onbekende derde partijen (wat duidt op exfiltratie of callback).
• Serverlogs die POST-verzoeken naar plugin-eindpunten tonen van ongebruikelijke verwijzers of gebruikersagenten.
• Verhoogd CPU-gebruik of cron-taken die onverwacht zijn gepland (wat duidt op backdoors).

Nuttige defensieve controles:

• WP-CLI zoekopdracht naar script-tags in berichten en opties:
  • wp db query "SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%<script%'" --limit=100
  • wp db query "SELECT option_id, option_name FROM wp_options WHERE option_value LIKE '%<script%'" --limit=100
• Scan met een vertrouwde malware-scanner (site-zijde of host-niveau) om bekende backdoors en webshells te detecteren.
• Vergelijk huidige bestanden met een schone snapshot of de oorspronkelijk verspreide bestanden van de plugin om gewijzigde bestanden te vinden.

Wanneer je verdachte inhoud vindt, isoleer het en voer het niet uit in een live browser. Behandel het als kwaadaardig totdat het tegendeel is bewezen.

---

Code-niveau herstelrichtlijnen voor ontwikkelaars

Als je de plugin onderhoudt of thema's/plugins ontwikkelt, zijn dit de essentiële defensieve coderingspraktijken die je moet volgen om zowel CSRF als opgeslagen XSS te voorkomen:

1. Gebruik nonces en verifieer ze bij elke statusveranderende aanvraag
   • Bij het genereren van een formulier of een link die een statuswijziging uitvoert:

     $nonce = wp_create_nonce( 'my_plugin_action' );

     Neem het op in formulieren of AJAX:

     <input type="hidden" name="_wpnonce" value="" />

   • Bij het afhandelen van verzoeken:

     check_admin_referer( 'my_plugin_action' ); // of check_ajax_referer voor AJAX

2. Controleer gebruikerscapaciteiten
   • Voordat u acties uitvoert, verifieer:

     if ( ! current_user_can( 'manage_options' ) ) { wp_die( 'Onvoldoende machtigingen' ); }

3. Maak invoer schoon voordat u opslaat
   • Gebruik geschikte sanitizers:
     • sanitize_text_field(), sanitize_email(), intval(), floatval()
     • Voor HTML-invoer: wp_kses_post() of wp_kses() met een veilige toegestane lijst
4. Escape bij output
   • Escapede altijd gegevens bij het afdrukken:
     • esc_html(), esc_attr(), wp_kses_post() afhankelijk van de context.
5. Gebruik de REST API en controleer permissie callbacks
   • Voor REST-eindpunten, implementeer permission_callback die mogelijkheden en nonces verifieert.
6. Valideer verwachte datatypes en lengtes
   • Handhaaf maximale lengtes en toegestane tekens.

Voorbeeld (defensieve pseudo-code):

// In het formulier:
wp_nonce_field( 'my_plugin_save_settings', '_wpnonce', true );

// In de verzendhandler:
if ( ! current_user_can( 'manage_options' ) ) {;

Voor HTML-invoer die beperkte tags moet toestaan:

$allowed = array(;

---

WAF en virtuele patching — praktische regels om nu te implementeren

Als je een WAF (toepassingsfirewall) zoals WP‑Firewall hebt, kun je defensieve regels maken die exploitatiepogingen blokkeren, zelfs voordat een officiële pluginpatch is uitgebracht. Overweeg de volgende hoog-niveau benaderingen:

1. Blokkeer verdachte POST/GET-inhoud naar plugin-eindpunten
   • Maak een regel om verzoeken te inspecteren die gericht zijn op plugin-beheeracties of plugin-bestanden. Als de verzoekbody script-tags of veelvoorkomende XSS-gebeurtenishandlers (onerror, onload, javascript:) bevat, blokkeer dan het verzoek.
2. Handhaaf de aanwezigheid van referer of oorsprong voor admin POST's
   • Blokkeer of daag (CAPTCHA) POST's uit naar wp-admin/admin-post.php, admin-ajax.php, of plugin-specifieke eindpunten die geen geldige referer of _wpnonce-parameter bevatten.
3. Beperk en daag anonieme verzoeken naar administratieve eindpunten uit
   • Veel exploitatiepogingen zijn geautomatiseerd. Rate limiting vermindert grote geautomatiseerde aanvallen.
4. Virtueel patchen: onderschep bekende exploitpatronen
   • Blokkeer verzoeken die overeenkomen met de exacte parameter namen of URL-patronen die door de kwetsbare plugin worden gebruikt wanneer ze verdachte inhoud bevatten.
5. Blokkeer verzoeken die proberen opties te creëren/wijzigen met scriptinhoud
   • Als een verzoek probeert wp_options of velden die vaak door de plugin worden gebruikt bij te werken met <script in de payload, blokkeer het.

Voorbeeld van een conceptuele firewallregel (pseudo):

ALS request.path OVEREENKOMT MET "/wp-admin/admin-post.php" OF "/wp-admin/*addfreespace*" EN request.method IN (POST, GET) DAN

Opmerkingen:

• Vermijd te brede regels die kunnen leiden tot valse positieven. Test eerst in monitor modus.
• Gebruik regels in combinatie met logging en waarschuwingen zodat je snel kunt aanpassen.

Als je een WP‑Firewall-gebruiker bent, schakel dan de beheerde regels in die gericht zijn op CSRF/XSS-exploitatiepatronen en schakel virtueel patchen in voor addfreespace-kwetsbaarheden. Dit biedt onmiddellijke bescherming terwijl je langere termijn herstelmaatregelen volgt.

---

Checklist na herstel (wat te doen nadat je de plugin hebt verwijderd of een patch hebt toegepast)

1. Bevestig dat de plugin is verwijderd of is bijgewerkt naar een gepatchte versie wanneer deze beschikbaar is.
2. Scan de hele site opnieuw op kwaadaardige code, webshells en gewijzigde bestanden.
3. Controleer de database op opgeslagen payloads en verwijder of saniteer ze.
4. Draai inloggegevens: adminwachtwoorden, SSH-sleutels, API-sleutels.
5. Herissueer eventuele gelekte tokens of sleutels die mogelijk zijn blootgesteld.
6. Herstel een schone back-up als je niet volledig kunt garanderen dat de site schoon is.
7. Monitor logs en inbraakdetectie op herhaalde pogingen.
8. Documenteer het incident, je acties en eventuele lessen die zijn geleerd.

---

Hoe te communiceren met klanten en belanghebbenden (als je andere sites beheert)

• Kort en feitelijk: leg de getroffen plugin uit, de versies, het risiconiveau en de acties die je hebt ondernomen (deactiveren/verwijderen, scannen, WAF-regels geïmplementeerd).
• Bied geruststelling: geef exacte mitigaties op (WAF-regels in werking, scannen voltooid, inloggegevens gedraaid, back-ups gebruikt).
• Geef richtlijnen: instrueer eindgebruikers om wachtwoorden te wijzigen als ze zijn ingelogd tijdens de blootstellingsperiode, en om op verdachte activiteiten te letten.
• Bied follow-up aan: plan een volledige beveiligingsreview als er aanwijzingen voor compromittering worden gevonden.

---

Hardening-checklist die standaardpraktijk zou moeten zijn (het voorkomen van soortgelijke problemen)

• Handhaaf 2FA voor elk administratief account.
• Beperk de toegang tot het admingebied via een IP-toegangslijst waar mogelijk.
• Schakel bestandsbewerking in wp-admin uit:

  define( 'DISALLOW_FILE_EDIT', true );

• Handhaaf het principe van de minste privileges: geef gebruikers alleen de mogelijkheden die ze absoluut nodig hebben.
• Houd de WordPress-kern, thema's en plugins up-to-date.
• Installeer en voer een gerenommeerde site-scanner en een beheerde WAF uit.
• Gebruik sterke, unieke wachtwoorden en een gecentraliseerd geheimenbeheerbeleid.
• Maak dagelijks (of vaker) back-ups met onveranderlijke back-ups die offsite zijn opgeslagen.
• Controleer de plugin-code voordat je plugins van onbekende auteurs of items met lage downloads installeert.

---

Als je verdachte JavaScript in je DB vindt — veilige opruimingsrichtlijnen

• Bezoek geen pagina's die de verdachte inhoud weergeven in een admin-browser sessie voordat je deze hebt schoongemaakt.
• Exporteer de verdachte rij(en) uit de DB naar een veilige quarantaineruimte en analyseer ze offline of op een geïsoleerde machine.
• Verwijder of saniteer vermeldingen met veilige functies (wp_update_post met gesaniteerde inhoud, update_option met gesaniteerde inhoud).
• Als je onzeker bent over de omvang van de compromittering, herstel dan vanaf een geverifieerde schone back-up en pas patches en hardening opnieuw toe.

---

Waarom een lage CVSS niet betekent “geen probleem”

Geautomatiseerde massale exploitatie en sociale engineering zijn afhankelijk van aaneengeschakelde, laagcomplexe stappen. Een kwetsbaarheid die “alleen maar” vereist dat een admin op een link klikt, kan extreem krachtig zijn wanneer aanvallers tienduizenden phishing-e-mails verzenden of andere websites compromitteren om de exploit in te bedden. Opgeslagen XSS uitgevoerd onder een admin-context is bijzonder gevoelig. Behandel kwetsbaarheden met een praktische risicoanalyse: eenvoud van exploitatie, aantal getroffen sites en de potentiële winst voor de aanvaller. In veel gevallen zijn onmiddellijke virtuele patches en het verwijderen van plugins verstandig, zelfs voor lage CVSS-scores.

---

Snelle incidentrespons playbook (één pagina)

1. Deactiveer de plugin (of hernoem de pluginmap).
2. Zet de onderhoudsmodus aan en blokkeer verkeer indien nodig.
3. Schakel WAF/virtuele patchregels in voor de plugin.
4. Scan de database op script-tags en verdachte vermeldingen; quarantainede gevonden items.
5. Scan het bestandssysteem op gewijzigde bestanden en webshells.
6. Draai admin-wachtwoorden en API-sleutels rond.
7. Controleer logs en gebruikersaccounts.
8. Herstel vanuit schone back-ups indien nodig.
9. Versterk de admin-toegang (2FA, IP-toegangslijst).
10. Herintroduceer de plugin alleen wanneer deze is gepatcht en na volledige QA.

---

Probeer het WP‑Firewall Basic (Gratis) plan — Essentiële bescherming zonder de prijskaart.

Als je op zoek bent naar onmiddellijke, praktische bescherming terwijl je de bovenstaande stappen volgt, overweeg dan om je aan te melden voor het WP‑Firewall Basic (Gratis) plan. Het bevat essentiële bescherming die helpt bij het blokkeren van exploitatiepogingen en snel je blootstelling vermindert:

• Beheerde firewall en WAF om bekende exploitpatronen te blokkeren
• Onbeperkte bandbreedte — de firewall beperkt je verkeer niet.
• Malware-scanner om veelvoorkomende backdoors en kwaadaardige payloads te detecteren.
• Mitigatie voor OWASP Top 10-risico's om veelvoorkomende aanvalsvectoren te verminderen.

U kunt zich registreren voor het gratis plan en deze beschermingen snel implementeren op: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

---

Laatste woorden van het beveiligingsteam van WP‑Firewall

Kwetsbaarheden zoals de addfreespace CSRF→stored‑XSS-keten herinneren eraan dat zelfs kleine of niche-plugins een buitensporig risico kunnen introduceren. Het goede nieuws: u kunt onmiddellijk effectieve actie ondernemen. Deactiveer of verwijder de plugin, pas WAF-regels en virtuele patches toe, scan op injecties, roteer inloggegevens en versterk de administratieve toegang. Als u meerdere websites beheert (als een bureau of host), automatiseer dan het scannen en virtueel patchen om de blootstellingsperiode op alle sites te verkorten.

We zijn toegewijd aan het helpen van site-eigenaren om risico's snel en met vertrouwen te verminderen. Als u praktische hulp, dreigingsjacht of op maat gemaakte virtuele patchregels nodig heeft, is WP‑Firewall beschikbaar om ondersteuning te bieden bij opruiming en langdurige verdediging.

Blijf veilig en geef prioriteit aan snelle mitigatie wanneer een kwetsbaarheid wordt onthuld - de tijd tussen onthulling en actieve exploitatie is vaak korter dan u verwacht.

— WP‑Firewall Beveiligingsteam

---

Bijlage: Snelle referentiecommando's (defensief)

• Zoek naar script-tags in berichten (pas de tabelprefix aan indien nodig):

  wp db query "SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%<script%';"

• Zoek wp_options naar scriptachtige inhoud:

  wp db query "SELECT option_id, option_name FROM wp_options WHERE option_value LIKE '%<script%';"

• Lijst recent gewijzigde bestanden (laatste 7 dagen) op een UNIX-host:

  find /pad/naar/wordpress -type f -mtime -7 -print

Vergeet niet: voer deze commando's alleen uit met de juiste toegang en back-ups, en vermijd het blootstellen van de site aan verder risico tijdens het onderzoek.