v1.28.0 — rapportage andere tabel-sets

Nieuw

Rapportage "Andere tabel-sets in deze database" onder Database Prefix: detecteert volledige WP-tabelsets in dezelfde database die niet bij de actieve prefix horen (typisch een oude migratie/test-import). Puur informatief, wijzigt niets.

Aanleiding: mtbarchitecten.nl bleek een c

v1.27.0 — voorkomt corruptie van wp-config.php

Fix

Secure-keys hardening kon wp-config.php stuk schrijven op sites met bestaande salts uit WordPress eigen generator (backticks/backslashes in de waarde) — de oude regex kende geen PHP-string-escaping.

v1.26.1 — fix: markeer als veilig deed echt niets

1.26.0 loste alleen de weergave op. De echte oorzaak: de knoppen waren

-elementen, genest in de grote instellingen-form die de hele pagina omvat — ongeldige HTML, browser negeert het, de klik deed niets.

Fix

• Vervangen door GET-links

v1.26.0 — core integrity scanner + ignore-fix

Vervolg op tessaswinkels.com: index.php en wp-blog-header.php waren geïnfecteerd, maar niets controleerde kernbestanden tegen de officiële WordPress-versie.

Nieuw

• Core Integrity Scanner: wekelijkse checksum-check van root + wp-admin/ + wp-includes/ tegen api.wordpress.org/core/checksums (zelfde principe als wp core verify-checksums). Detectie only.

Fix

• "Markeer als veilig" sloeg de markering wel correct op, maar de tabel toonde de laatst opgeslagen scan-resultaten en filterde pas bij de volgende scan. Werkt nu direct.

Zie changelog.txt voor het volledige verhaal

v1.25.0 — markeer bevindingen als veilig

Feedback na tessaswinkels.com: beoordeelde, onschuldige bevindingen (oud Avada-archief, afgeschermde db-dump) bleven elke week terugkomen.

Nieuw

• "Markeer als veilig"-knop per rij in File Exposure Scanner en Anomaly Scanner.
• Gemarkeerde items verdwijnen permanent uit tabel én mail, terug te zetten via "Genegeerde bevindingen".
• Identificatie op het volledige pad — een normale update van hetzelfde bestand zet de markering niet stilzwijgend weer aan.

Zie changelog.txt voor het volledige verhaal

v1.24.0 — detectie van database-snippet-webshells

Vervolg op v1.23.0, zelfde tessaswinkels.com-hack: naast bestand- en gebruikers-backdoors bleken er ook twee webshells verstopt als WPCode/Insert Headers and Footers-snippets in de database (wp_posts) — onzichtbaar voor elke bestandsscan of checksum-check. Een van de twee stond zelfs als draft.

Nieuw

• Real-time mail bij elke nieuwe of gewijzigde WPCode-snippet (hook save_post_wpcode), ongeacht publish/draft-status.
• Anomaly Scanner krijgt een vierde baseline-diff: PHP-type WPCode-snippets in de database, vangt ook rechtstreekse SQL-writes.

Zie changelog.txt voor het volledige verhaal

v1.23.0 — real-time admin-alert + plugin/mu-plugin anomaly-detectie

Naar aanleiding van de tessaswinkels.com-hack (sept 2026): een backdoor vermomd als plugin en een nep-Wordfence mu-plugin bleven 7 weken onopgemerkt, en 11 rogue administrator-accounts werden pas ontdekt toen de site al door Xel was geblokkeerd wegens gokspam-cloaking.

Nieuw

• Real-time mail bij elke promotie naar administrator (hook set_user_role), ongeacht of dat via het registratieformulier, wp-admin, wp-cli of een script gaat.
• Anomaly Scanner kijkt nu ook een niveau dieper in wp-content/plugins en wp-content/mu-plugins (baseline-diff), waar de bestaande top-level scan overheen keek.

Zie changelog.txt voor het volledige verhaal

v1.22.0 - ?ver= alleen nog bij core-assets

Fix: de toggle "Verwijder WordPress versie" haalde ?ver= ook weg bij thema- en plugin-assets. Daardoor bleef de browser van bezoekers oude JS/CSS serveren en kwam een uitgerolde wijziging niet aan.

Vanaf nu verdwijnt ?ver= alleen nog bij /wp-includes/ en /wp-admin/ - daar staat het WordPress-versienummer in. Thema- en plugin-assets houden hun versienummer en dus hun cache-busting.

Geen instelling gewijzigd: wie de toggle aan had, houdt hem aan.

v1.21.2 — advies-regel onder elke toggle

De omschrijvingen op de instellingenpagina legden uit wát een optie doet, maar niet wat je moet kiezen. Bij een nieuwe site moest je dat elke keer opnieuw afleiden.

Onder elke toggle staat nu groen Aanbevolen: aan laten of grijs Standaard uit, met daarachter de voorwaarde waaronder je afwijkt. Bijvoorbeeld:

• REST-userlijst → aan laten; uit alleen als een externe koppeling of headless frontend die lijst anoniem uitleest
• Archieven in uploads blokkeren → standaard uit; aanzetten als de site geen zips uit de mediabibliotheek aanbiedt
• Plugin-lockdown → aan op klantsites, met de waarschuwing dat dit zonder MCM_SECURITY_OWNERS in wp-config óók voor jezelf de plugin-updates verbergt
• Malicious URL-filter → uit laten, met de reden erbij (44% valse treffers op legitieme URLs)

26 toggles hebben een expliciet advies met voorwaarde; de overige 28 (versie verbergen, readme blokkeren, en dergelijke) leiden hun advies af uit de profielen: zit een toggle in Basic, dan is "aan laten" het advies. Zo is er geen tweede lijst om bij te houden, en krijgen de voor-de-hand-liggende opties geen overbodige voorwaarde. Getest: 54 van 54 toggles krijgen een regel.

v1.21.1 — gereserveerde logins blokkeren, scanner herkent eigen .htaccess

Scherpstelling van 1.21.0 op basis van wat er op de eigen sites uitkwam, plus een duidelijker scheiding tussen deze plugin en de Site Optimizer.

Nieuw: gereserveerde gebruikersnamen weigeren bij registratie
Onze lijst (admin, administrator, root, test, demo, wordpress, webmaster, beheer(der), sysadmin, superadmin) hangt in WordPress' eigen illegal_user_logins. De core past dat filter toe in wp_insert_user() én in de registratievalidatie, dus het dekt WP-registratie, WooCommerce-klantregistratie en handmatig aanmaken in de backend. Aanpasbaar met mcm_security_reserved_logins.

Aanleiding: op susenso.nl had een bot in oktober 2025 de login admin geclaimd — rol customer, 0 orders, 0 content. Bestaande accounts worden hier niet door geraakt; die staan in de user-audit.

Gewijzigd: user-audit alleen voor accounts met verhoogde rechten
Klantaccounts horen bij de nep-/botaccountmodule van de Site Optimizer (met veiligheidsslot en CSV-backup). Ze worden hier nog wél gesignaleerd als één regel met doorverwijzing. Daarmee verdwijnt ook een valse melding: een echte klant wiens login gelijk is aan de domeinnaam werd onterecht gevlagd — die regel geldt nu alleen bij verhoogde rechten.

Fix: de scanner herkent zijn eigen .htaccess-blokkades
Webroot-bevindingen keken alleen naar een blanket deny op mapniveau, niet naar scoped <Files>/<FilesMatch>-regels. Een debug.log die door onze eigen block_log_txt_files-regel al 403 gaf, bleef daardoor wekelijks als HIGH gemeld worden. Zo'n bevinding zakt nu naar LOW met "— geblokkeerd via .htaccess".

Geverifieerd op echte sites: jouwtuin gaat naar 0 mailwaardige bevindingen, terwijl de 10 publiek downloadbare zips op mcmwebsites.nl MEDIUM blijven.