Pluginnaam	WordPress Contactlijst Plugin
Type kwetsbaarheid	Cross-site scripting (XSS)
CVE-nummer	CVE-2026-3516
Urgentie	Laag
CVE-publicatiedatum	2026-03-20
Bron-URL	CVE-2026-3516

Geauthenticeerde opgeslagen XSS in de Contactlijst-plugin (CVE-2026-3516) — Wat WordPress-site-eigenaren en -beheerders nu moeten doen

Datum: 20 maart 2026
Auteur: WP-Firewall Beveiligingsteam

Een recent onthulde kwetsbaarheid in de WordPress Contactlijst-plugin (versies <= 3.0.18) kan een geauthenticeerde gebruiker op Contributor-niveau in staat stellen om opgeslagen cross-site scripting (XSS) payloads via de parameter van de plugin in te voegen. _cl_map_iframe Het probleem wordt gevolgd als CVE-2026-3516 en is opgelost in versie 3.0.19. Hoewel de gerapporteerde ernst laag tot gemiddeld is (CVSS 6.5), is opgeslagen XSS een ernstig probleem omdat kwaadaardige scripts op de server blijven bestaan en worden uitgevoerd telkens wanneer getroffen pagina's door gebruikers met de relevante context worden bekeken (inclusief redacteuren, beheerders of openbare bezoekers, afhankelijk van waar de inhoud wordt weergegeven).

Als een WordPress-beveiligingsteam dat een beheerde WAF en incidentresponsdienst exploiteert, willen we je duidelijke, praktische richtlijnen geven. Deze post legt het probleem in eenvoudige technische termen uit, begeleidt je bij detectie en containment, biedt veilige mitigatiestrategieën (inclusief WAF/virtuele patching-handtekeningen die je onmiddellijk kunt toepassen) en legt uit hoe je robuuste herstel- en langdurige verhardingsprocedures kunt volgen.

Opmerking: Als je Contactlijst <= 3.0.18 draait, werk dan zo snel mogelijk bij naar 3.0.19. Als je niet onmiddellijk kunt updaten, pas dan de onderstaande mitigaties toe.

---

Executive summary (snelle conclusies)

• Er bestaat een opgeslagen XSS-kwetsbaarheid in de Contactlijst WordPress-plugin, opgelost in versie 3.0.19. Een gebruiker op Contributor-niveau kan een bewerkte waarde aan de parameter van de plugin leveren _cl_map_iframe die wordt opgeslagen en later kan worden weergegeven, wat leidt tot scriptuitvoering in de context van sitebezoekers of beheerders.
• Impact: sessieovername, privilegeverhoging (via CSRF+XSS-ketens), omleiding naar kwaadaardige sites, inhoudsmanipulatie of persistente beschadiging — afhankelijk van waar de payload wordt weergegeven en welke gebruikers deze bekijken.
• Onmiddellijke acties:
  1. Werk de plugin bij naar 3.0.19 (of later).
  2. Als je niet onmiddellijk kunt updaten, pas dan een WAF/virtuele patch toe die blokkeert _cl_map_iframe waarden die bevatten <iframe>, <script>, of javascript: (voorbeelden hieronder).
  3. Zoek naar geïnjecteerde payloads in de database (zoek naar _cl_map_iframe, <script, <iframe, javascript:).
  4. Beoordeel bijdrageraccounts en beperk tijdelijk de publicatie- of HTML-mogelijkheden.
  5. Volg de stappen voor incidentrespons als je vermoedt dat er een compromis is.
• Op de lange termijn: handhaaf het principe van de minste privileges, verwijder “unfiltered_html” van lagere rollen, voer regelmatig scans uit, schakel automatische plugin-updates in voor kritieke beveiligingsfixes en gebruik beheerde virtuele patching waar onmiddellijke updates niet mogelijk zijn.

---

Wat is precies de kwetsbaarheid?

Technische beschrijving (hoog niveau): de plugin accepteert invoer via een parameter genaamd _cl_map_iframe. Wanneer een gebruiker op Contributor-niveau een bewerkte waarde levert, slaat de plugin die waarde op en geeft deze later weer in een pagina of admin-weergave zonder voldoende sanitization of escaping. Omdat de waarde HTML- en scriptconstructies kan bevatten, kan de opgeslagen inhoud script-tags, gebeurtenishandlers of javascript: URI's bevatten die worden uitgevoerd wanneer de uitvoer in de browser van een slachtoffer wordt weergegeven.

Belangrijkste kenmerken:

• Aangetaste versies: Contactlijst-plugin <= 3.0.18
• Gepatcht in: 3.0.19
• CVE: CVE-2026-3516
• Vereiste rechten voor uitbuiting: Contributor (geauthenticeerd)
• Aanvalstype: Opgeslagen Cross-Site Scripting (XSS)
• Primaire risicovector: Persistente code geïnjecteerd in site-uitvoer (kan beheerders en frontend-bezoekers beïnvloeden)

Waarom het belangrijk is: Opgeslagen XSS is persistent. In tegenstelling tot gereflecteerde XSS (die als een onmiddellijke reactie wordt geactiveerd), overleven opgeslagen XSS-payloads in de database en worden ze uitgevoerd telkens wanneer de getroffen pagina of admin-weergave wordt geladen. Dit stelt een aanvaller in staat om in de loop van de tijd een breed scala aan slachtoffers te bereiken en leidt voor WordPress vaak tot overname van accounts (cookie-diefstal), CSRF-ketens of de invoeging van achterdeurtjes en aanvullende kwaadaardige inhoud.

---

Aanvalscenario's en impact in de echte wereld

Een aanvaller die een Contributor-account kan registreren of controleren (of een kan compromitteren) kan een payload injecteren die door de plugin wordt opgeslagen en later wordt weergegeven in een admin-dashboard of openbare pagina. Hier zijn enkele plausibele aanvalsketens en impacten:

• Sessiediefstal: Als een administrator of redacteur een pagina bezoekt met een kwaadaardige opgeslagen payload, kan de aanvaller proberen cookies of tokens te stelen (tenzij beveiligingsvlaggen/HttpOnly/CSP dit voorkomen) en deze vervolgens hergebruiken om zich voor te doen als de admin.
• Privilege-escalatie: In combinatie met andere kwetsbaarheden (of zwakke wachtwoorden) kan een aanvaller XSS gebruiken om administratieve acties te triggeren via verborgen verzoeken (CSRF), zoals het aanmaken van een nieuwe admin-gebruiker of het wijzigen van opties.
• Inhoud en SEO vergiftiging: Geïnjecteerde scripts kunnen de site-inhoud wijzigen, spam injecteren of organisch verkeer omleiden naar kwaadaardige landingspagina's.
• Persistente achterdeur: Een XSS kan fungeren als een initiële toegang om server-side achterdeurtjes te installeren (bijvoorbeeld door een kwaadaardige plugin te uploaden als admin-gegevens zijn gestolen of door code in thema- of pluginbestanden in te voegen).
• Reputatie en juridisch: Belediging, malware-distributie of besmette inhoud kan de merkreputatie schaden en de site-eigenaar blootstellen aan regelgevende zorgen.

Hoewel de vereiste bevoegdheid Contributor is (niet publiek ongeauthenticeerd), verlenen veel beheerders Contributor of hoger aan externe auteurs, aannemers of leden van de gemeenschap. Dit maakt dit een belangrijk operationeel risico.

---

Hoe exploiteerbaar is dit in de praktijk?

De exploiteerbaarheid hangt af van verschillende factoren:

• Of de plugin-uitvoer zichtbaar is voor gebruikers met hogere privileges (beheerders/redacteuren) of het publiek. Als alleen contributors de opgeslagen inhoud kunnen bekijken, is de impact verminderd; als beheerders het bekijken op een opties-pagina of de openbare pagina het weergeeft, is de impact hoog.
• Of cookies, tokens of beschermingen zoals HttpOnly, SameSite of CSP aanwezig zijn. Goede HTTP-beveiligingsheaders verminderen enkele risico's, maar elimineren XSS niet.
• Blootstelling van Contributor-toegang: als je registraties of gastbijdragen toestaat zonder strikte moderatie, neemt het risico toe.

Omdat veel sites gebruikersinzendingen accepteren, en omdat Contributor-accounts soms worden gebruikt door externe teams, beschouwen we dit als een significant beveiligingsevenement dat remedie vereist.

---

Onmiddellijke detectie en jacht (waarop te letten)

Als je een beveiligingsscan of forensische zoektocht uitvoert, zoek dan naar verdachte opgeslagen inhoud en HTTP-verzoeken die overeenkomen met XSS-patronen. De volgende veilige, niet-exploitatieve queries en controles helpen je verdachte items te vinden:

Databasezoekopdracht (zoek naar niet-geëscape HTML of iframe/script-strings):

-- Zoek wp_options naar door plugins opgeslagen waarden;

WP-CLI tekstzoekopdracht:

# Zoek de database naar verdachte markers

Log- en toegangsbeoordeling:

• Inspecteer toegangslogs op POST/PUT-verzoeken die bevatten _cl_map_iframe parameters.
• Zoek naar ongebruikelijke admin-paginaweergaven of herhaalde inhoudsindieningen van bepaalde accounts.
• Controleer de wijzigingsgeschiedenis voor pluginoptiepagina's en controleer wie die waarden voor het laatst heeft bewerkt.

Beoordeling van gebruikersaccounts:

• Lijst bijdragersgebruikers en identificeer accounts die recent zijn aangemaakt of met ongebruikelijke metadata (verdachte IP's, wegwerp-e-maildomeinen).
• Deactiveer tijdelijk of reset wachtwoorden voor accounts die je niet kunt verifiëren.

Bestandsysteemcontroles:

• Scan op onverwachte PHP-bestanden, nieuwe plugin/thema-bestanden of gewijzigde kernbestanden.
• Gebruik beschikbare malware-scanners om te zoeken naar backdoors en web shells.

---

Beperkings- en onmiddellijke mitigatiestappen

1. Update de plugin (voorkeur)
   Werk de Contactlijst onmiddellijk bij naar versie 3.0.19 of later. Dit verwijdert de kwetsbaarheid.
2. Virtuele patch / WAF-regel (als je niet onmiddellijk kunt updaten)
   Pas een WAF-regel toe om verzoeken te blokkeren of te saneren waarbij de _cl_map_iframe parameter HTML-tags bevat of javascript: URI's.
   Voorbeeld ModSecurity-regel (illustratief; pas ID's aan en stem af op jouw omgeving):

# ModSecurity-regel om _cl_map_iframe te blokkeren wanneer het script/iframe/javascript bevat:"

3. Voorbeeld Nginx (lua of standaard controle) snippet (illustratief):

# Eenvoudige Nginx if-blok (mogelijk niet geschikt voor elke setup)

4. Belangrijk: Test elke WAF-regel op staging of met alleen logging voordat je deny afdwingt in productie. Valse positieven kunnen legitiem gedrag verstoren.
5. Blokkeer indienpunten voor niet-vertrouwde gebruikers
   Als de plugin een eindpunt voor opslaan blootstelt _cl_map_iframe, beperk de toegang tot publicatierollen of alleen geauthenticeerde editor/admin-sessies totdat deze zijn gepatcht.
6. Verstevig rolcapaciteiten
   Verwijder de “unfiltered_html” mogelijkheid van Contributor-rollen (indien ingeschakeld) en zorg ervoor dat gewone bijdragers geen ruwe HTML kunnen indienen.
   Beperk wie bestanden kan uploaden of inhoud kan publiceren zonder beoordeling.
7. Sanitize opgeslagen waarden
   Als je de sitecode beheert en de plugin die waarde opslaat in opties of postmeta, voeg dan een tijdelijke filter toe om de waarde te saniteren bij opslaan met wp_kses() om gevaarlijke tags te verwijderen:

add_filter( 'update_option_contact_list_map_iframe', 'wpfirewall_sanitize_cl_map_iframe' );

7. Opmerking: Gebruik dit alleen als een tijdelijke mitigatie als je niet kunt updaten. De juiste langetermijnoplossing is de plugin-update.
8. Pas Content Security Policy (CSP) toe.
   Het toevoegen van een CSP die scriptbronnen beperkt en inline scripts verbiedt, vermindert de impact van XSS. Voorbeeldheader:

Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'; frame-ancestors 'none'

8. CSP kan lastig zijn; test grondig om te voorkomen dat legitieme functionaliteit wordt verbroken.

---

Aanbevolen WAF/virtuele patch-handtekeningen en afstemming

Hieronder staan veilige, generieke handtekeningbenaderingen om de meest waarschijnlijke exploitpogingen te stoppen. Ze vermijden het onthullen van exploitatiestappen, maar bieden uitvoerbare bescherming die je kunt toepassen in een beheerde WAF of op je hosting-firewall.

1. Parameter-gebaseerde blokkering
   Blokkeer of log verkeer waar de parameter _cl_map_iframe bevat <script, <iframe, onerror=, onload=, of javascript:.
   Regex voorbeeld (converteer naar uw WAF-syntaxis):

(?i)(<\s*(script|iframe)|on\w+\s*=|javascript:)

2. HTML-attribuut filtering
   Verwerp verzoeken waarbij HTML-attribuutinjectie wordt geprobeerd in parameters (bijv. gebeurtenisbehandelaars of data-URI's).
3. Handhaving van output-sanitization
   Waar mogelijk, afdwingen dat de bekende opslag sleutels van de plugin alleen veilige waarden bevatten (numerieke ID's, booleaanse vlaggen of beperkte URL's). Als de plugin een iframe-URL accepteert (kaart insluiten), zorg ervoor dat invoer overeenkomt met een veilig patroon zoals ^https?://(www\.)?trusted-map-provider\.com/.
4. Blokkeer inhoudstypen
   Als de parameter alleen een URL nodig heeft, wijs inhoud af die bevat < of > tekens.
5. Beperk verdachte accounts
   Als een account plotseling meerdere configuratiewijzigingen van de plugin begint in te dienen, beperk dan of vereis 2FA voor rolverhoging.

Implementatienotities:

• Zet nieuwe regels 24–48 uur in een logging-only modus en bekijk logs op valse positieven.
• Vermijd brede “blokkeer alles met <iframe ergens” zonder controle; sommige legitieme insluitingen kunnen iframe-tags gebruiken. Focus in plaats daarvan op de exacte plugininvoer en context.
• Zorg ervoor dat de WAF-regel is beperkt tot de exacte URI of beheerderspagina die door de plugin wordt gebruikt om collateral effecten te verminderen.

---

Hoe te jagen op opgeslagen payloads (veilige stappen)

Als u wilt controleren op bestaande geïnjecteerde inhoud, doe dit dan voorzichtig en vermijd het uitvoeren van verdachte inhoud in een browser als beheerder. Gebruik server-side controles en veilige weergave:

1. Zoek in de database (zoals eerder getoond) naar voorkomens van <script, <iframe, javascript: En '_cl_map_iframe'.
2. Exporteer verdachte velden naar een tekstbestand en bekijk ze offline (niet weergeven in een beheerdersbrowser).
3. Als je verdachte payloads vindt:
   • Vervang de payload door een veilige waarde of een lege string.
   • Noteer de tijdstempel en de gebruiker die deze heeft aangemaakt (van wp_berichten/wp_postmeta of wp_opties) en bewaar logs voor onderzoek.
   • Draai wachtwoorden voor getroffen accounts.
4. Controleer toeganglogs voor dezelfde periode (zoek naar POSTs van gebruikers-IP's).
5. Scan de site op aanvullende indicatoren van compromittering: gewijzigde pluginbestanden, nieuwe PHP-bestanden of geplande taken die naar externe hosts wijzen.

Voorbeeld WP-CLI-opdracht om optie-waarden veilig te dumpen:

# Dump optie-waarden die mogelijk plugininstellingen bevatten

---

Checklist voor incidentrespons (als u vermoedt dat er sprake is van een inbreuk)

1. Bevatten
   • Pas de WAF-regel toe in blokkermodus.
   • Zet de site tijdelijk in onderhoudsmodus indien nodig.
   • Deactiveer de getroffen plugin als je dit veilig kunt doen.
2. Bewijsmateriaal bewaren
   Verzamel database-exporten, webserverlogs en snapshots van pluginconfiguraties.
   Verwijder logs niet onmiddellijk; bewaar ze voor forensische analyse.
3. Uitroeien
   Verwijder geïnjecteerde inhoud uit de database en pagina's (na vastlegging).
   Scan en reinig bestanden. Als je achterdeurtjes vindt, verwijder ze dan en vervang bestanden door schone kopieën van vertrouwde bronnen.
   Werk de plugin bij naar 3.0.19, werk alle andere plugins, thema's en de WordPress-kern bij.
4. Herstellen
   Draai wachtwoorden voor admin-accounts, database-inloggegevens en API-sleutels.
   Herstel eventuele gelekte geheimen (OAuth-tokens, API-sleutels).
   Heropen de site zodra je een schone staat hebt bevestigd en de patch/WAF-regel hebt toegepast.
5. Acties na het voorval
   Voer een rootcause-analyse uit. Hoe is het Contributor-account aangemaakt of gecompromitteerd?
   Versterk accountprovisioning en controleer roltoewijzingen.
   Schakel monitoring en geplande malware-scans in.
6. Rapporteren.
   Als u een siteprovider bent of meerdere sites beheert, informeer dan de getroffen klanten en geef herstelinstructies.

---

Versterking en aanbevolen praktijken op lange termijn

• Handhaaf het principe van de minste privilege: geef alleen Contributor of hoger aan gebruikers die het echt nodig hebben. Geef de voorkeur aan Editor of Admin voor vertrouwde, gecontroleerde accounts en beperk publicatierechten.
• Verwijder de unfiltered_html-mogelijkheid voor niet-beheerder gebruikers. Deze mogelijkheid stelt accounts in staat om ruwe HTML en scripts op te nemen, wat het aanvalsvlak vergroot.
• Houd plugins, thema's en de WordPress-kern up-to-date en gebruik automatische updates voor beveiligingspatches waar nodig.
• Gebruik multi-factor authenticatie voor admin- en editoraccounts.
• Implementeer staging-sites en controleer pluginwijzigingen of upgrades voordat u deze naar productie doorvoert.
• Schakel een Web Application Firewall (WAF) in die wordt onderhouden door een beveiligingsteam en ondersteuning biedt voor virtuele patches wanneer onmiddellijke pluginupdates niet beschikbaar zijn.
• Maak gebruik van Content Security Policy (CSP) en andere beveiligingsheaders (X-Frame-Options, X-XSS-Protection, Referrer-Policy).
• Regelmatige back-ups: zorg ervoor dat u geverifieerde, geteste back-ups en een herstelplan heeft.
• Geplande scans: voer geautomatiseerde malware- en integriteitscontroles uit (bestandswijzigingen, ongebruikelijke PHP-bestanden).

---

Voorbeeld van veilige server-side sanering (ontwikkelaarsrichtlijnen)

Als u aangepaste code of integratiepunten voor deze plugin onderhoudt, saniteer en valideer dan alles server-side. Als de plugin bijvoorbeeld een URL of insluitcode opslaat, geef dan de voorkeur aan het opslaan van het domein of een insluittoken in plaats van ruwe HTML. Gebruik wp_kses() om veilige tags waar nodig op de witte lijst te zetten:

// Example: sanitize iframe map embed by whitelisting only allowed attributes or by extracting the src
function sanitize_contact_map_input( $input ) {
    // Option A: allow only a small set of tags (no script/iframe)
    $allowed = array(
        'a' => array( 'href' => true, 'title' => true, 'rel' => true ),
        'br' => array(),
        'em' => array(),
        'strong' => array(),
    );
    return wp_kses( $input, $allowed );
}

// Option B: if the plugin expects a URL, parse and validate the URL
function validate_map_url( $url ) {
    $url = trim( $url );
    if ( empty( $url ) ) {
        return '';
    }
    if ( wp_http_validate_url( $url ) === false ) {
        return '';
    }
    // Optionally restrict to trusted map providers:
    $allowed_hosts = array( 'maps.example.com', 'www.maps.example.com' );
    $host = parse_url( $url, PHP_URL_HOST );
    if ( ! in_array( $host, $allowed_hosts, true ) ) {
        return '';
    }
    return esc_url_raw( $url );
}

---

Monitoring en waarschuwingen om onmiddellijk toe te voegen

• Waarschuw bij wijzigingen in pluginoptiewaarden die overeenkomen met HTML-tags of javascript: snaren.
• Meld plotselinge configuratiewijzigingen in de Contactlijst-plugininvoeren.
• Volg pieken in mislukte aanmeldingen en ongebruikelijke bijdrageractiviteit.
• Stel periodieke DB-scans in voor verdachte patronen en automatische quarantaines van gedetecteerde overeenkomsten (log eerst, quarantaineren na validatie).

---

Waarom WAF + plugin-updates belangrijk zijn (en hoe wij helpen)

Plugin-updates verhelpen de onderliggende problemen in de code. WAF's bieden een vangnet voor wanneer updates niet onmiddellijk kunnen worden toegepast (bijv. compatibiliteitstests, staging of vertragingen van de leverancier). Bij WP-Firewall combineren we beheerde WAF-regels en continue monitoring met kwetsbaarheidsinformatie om zowel onmiddellijke virtuele patching als langdurige herstelrichtlijnen te bieden.

Als je een beheerde firewall gebruikt, zorg er dan voor dat regels die specifiek zijn voor deze plugin en parameter snel naar je site worden gepusht. Als je je eigen WAF beheert, pas dan de gerichte handtekeningen hierboven toe en test eerst in logmodus.

---

Begin met het WP-Firewall Gratis Plan — Bescherm je site zonder vertraging

Titel: Beveilig je WordPress-site vandaag nog met WP-Firewall Gratis Bescherming

Als je onmiddellijke, basisbescherming wilt terwijl je de plugin-update en opruimstappen implementeert, biedt ons WP-Firewall Basis (Gratis) plan essentiële verdedigingen die de meest voorkomende exploitpatronen blokkeren en je ademruimte geven om veilig te herstellen. Het gratis plan omvat:

• Beheerde firewall met WAF-regels die kunnen worden aangepast voor plugin-specifieke virtuele patches
• Onbeperkte bandbreedte en bescherming aan de rand
• Malware-scanner voor snelle ontdekking van verdachte bestanden en geïnjecteerde inhoud
• Mitigaties die de OWASP Top 10-aanvalstypen aanpakken

Meld je nu aan om beheerde bescherming en virtuele patching in te schakelen terwijl je de Contactlijst patcht en je incidentrespons uitvoert: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

Als je een hoger niveau van automatisering en hands-off herstel verkiest, voegen onze betaalde plannen automatische malwareverwijdering, IP-blacklisting/witlisting, maandelijkse beveiligingsrapportage en geavanceerde virtuele patching toe. Kies het plan dat past bij het niveau van controle en ondersteuning dat je site nodig heeft.

---

Eindchecklist — wat nu te doen

1. Update de Contactlijst naar 3.0.19 (of later) — hoogste prioriteit.
2. Als u niet onmiddellijk kunt updaten:
   • Pas een WAF-regel toe om de _cl_map_iframe parameter.
   • Bijdragercapaciteiten te verstrakken en accounts te herzien.
3. Zoek in uw database naar <script, <iframe, javascript:, En _cl_map_iframe invoer en verwijder of neutraliseer verdachte inhoud.
4. Draai wachtwoorden voor accounts die in logs verschijnen rond verdachte activiteit, en schakel 2FA in voor alle bevoorrechte accounts.
5. Voer een volledige site-malwarescanner uit en controleer de bestandsintegriteit.
6. Bewaar bewijs en volg een incidentresponsproces als je tekenen van succesvolle exploitatie vindt.
7. Zet langdurige verharding in (minimale privileges, automatische beveiligingsupdates waar mogelijk, CSP en veilige headers, beheerde virtuele patching).

---

Bronnen en verder lezen

• Raadpleeg de release-opmerkingen en changelog van de plugin-ontwikkelaar en upgrade naar 3.0.19.
• Als je meerdere sites beheert, geef prioriteit aan sites met waardevolle admin- of redacteursrollen en sites die inhoud van externe bijdragers accepteren.
• Voor beheerde bescherming en virtuele patching-opties, overweeg een WAF met ondersteuning voor de implementatie van aangepaste regels en realtime monitoring.

---

Als je hulp nodig hebt bij het toepassen van een gerichte WAF-regel, het opsporen van geïnjecteerde inhoud of het uitvoeren van een veilig opruimplan, kan ons WP-Firewall-team helpen. We bieden beheerde virtuele patching, scannen en herstelworkflows die zijn ontworpen voor WordPress-sites van alle groottes.

Blijf veilig en patch snel — opgeslagen XSS is verraderlijk, maar met de juiste combinatie van updates, WAF-bescherming en operationele verharding kun je exploitatie stoppen en het vertrouwen in je site herstellen.