Kritisk adgangskontrolfejl i Simple History//Udgivet den 2026-06-02//CVE-2026-7459

Plugin-navn	Enkel Historie
Type af sårbarhed	Ødelagt adgangskontrol
CVE-nummer	CVE-2026-7459
Hastighed	Høj
CVE-udgivelsesdato	2026-06-02
Kilde-URL	CVE-2026-7459

Haster: Brudt Adgangskontrol i Simple History (<= 5.26.0) — Hvad WordPress-webstedsejere skal gøre nu

Forfatter: WP-Firewall Sikkerhedsteam
Dato: 2026-06-02
Tags: WordPress, sårbarhed, WAF, Simple History, sikkerhed

Resumé

Den 2. juni 2026 blev en højprioriteret sårbarhed (CVE-2026-7459, CVSS 7.5) offentliggjort for WordPress-pluginet Enkel Historie der påvirker versioner <= 5.26.0. Problemet er en brudt adgangskontrolfejl — i bund og grund en manglende autorisation/nonce-kontrol i en eller flere handlinger — der tillader en autentificeret bruger med abonnentprivilegier at udføre højere privilegerede operationer. I værste fald kan dette føre til overtagelse af konto og fuld kompromittering af webstedet.

Hvis du kører Simple History på et hvilket som helst websted, skal du behandle dette som hastende: opdater til Simple History 5.27.0 straks. Hvis du ikke kan opdatere med det samme, anvend de nævnte afbødninger nedenfor og følg tjeklisten for hændelsesrespons.

Dette indlæg forklarer:

• hvad sårbarheden er, og hvordan den kan misbruges,
• umiddelbare handlinger for at beskytte berørte websteder,
• hvordan man opdager, om et websted er blevet målrettet eller kompromitteret,
• langsigtede anbefalinger til hærdning og overvågning,
• hvordan WP-Firewall kan hjælpe med at beskytte dit websted i dag (inklusive en gratis plan).

Jeg skriver dette som en erfaren WordPress-sikkerhedspraktiker. Trinene nedenfor er praktiske, testet på reelle hændelsesrespons, og skrevet, så du kan handle straks.

---

Hvad der skete (i almindelige termer)

Simple History tilføjede en funktion, der gjorde det muligt for brugere at interagere med plugin-funktionalitet via HTTP-anmodninger (AJAX / REST / admin-post håndterere). En eller flere af disse slutpunkter manglede ordentlige kapabilitetskontroller og/eller nonce-validering. Det er definitionen på en brudt adgangskontrolsårbarhed — koden tillod handlinger uden at verificere, at opkalderen havde ret til at udføre dem.

Fordi sårbarheden er tilgængelig for abonnentniveau-konti (den lavest privilegerede loggede rolle på en standard WordPress-installation), kan angribere:

• Bruge en kompromitteret abonnentkonto, eller
• Oprette en abonnent via åben registrering (hvis aktiveret), eller
• Lokke en legitim abonnent til at klikke på et link (afhængigt af det præcise slutpunkt og om CSRF også er muligt),

og derefter eskalere handlinger for at ændre andre konti, ændre administratorens e-mail/adgangskode, oprette nye administratorer eller foretage andre højpåvirkende ændringer.

Plugin-forfatteren udgav en løsning i Simple History 5.27.0, som tilføjer de rette autorisations/nonce-kontroller og lukker hullet. Behandl ethvert websted, der kører <= 5.26.0, som sårbart, indtil det er opdateret.

---

Hvorfor dette er høj prioritet

En sårbarhed, der tillader lavprivilegerede brugere at udføre administrative handlinger, er en af de mest farlige klasser af fejl i WordPress:

• Abonnentkonti er almindelige (kommentarer, medlemskabswebsteder, eLearning, fora).
• Mange websteder tillader registrering eller har abonnenter oprettet af tredjeparts plugins.
• Angribere kan skalere denne slags udnyttelse: finde websteder med det sårbare plugin og den rigtige konfiguration og automatisere overtagelsesforsøg.
• Når en admin-konto er oprettet eller admin-legitimationsoplysninger ændret, kan angribere installere vedholdende bagdøre, der er svære at opdage og kan omgå mange forsvar.

Givet bredden af WordPress-brug og hvor hurtigt automatiserede scannere og udnyttelsesscripts spreder sig, bør du handle straks.

---

Øjeblikkelige handlinger (hvad man skal gøre i de næste 60–120 minutter)

1. Lav en liste over berørte websteder
   • Find alle WordPress-websteder, du administrerer, og tjek versionen af Simple History-pluginet. Ethvert websted med Simple History installeret og en version <= 5.26.0 er sårbart.
   • Hvis du bruger fjernadministration eller en webstedsliste, skal du eksportere plugin-versioner eller forespørge plugins via WP-CLI.
2. Opdater nu (foretrukket)
   • Opdater Simple History til 5.27.0 straks. Dette er den mest effektive afbødning.
   • Hvis du bruger auto-opdateringsværktøjer eller administrerede tjenester, skal du skubbe opdateringen nu.
   • Efter opdatering skal du bekræfte plugin-versionen i admin og bekræfte, at webstedet fungerer korrekt.
3. Hvis du ikke kan opdatere med det samme — midlertidige afbødninger
   • Deaktiver pluginet (Plugins > Installerede Plugins → deaktiver Simple History). Dette er sikkert og forhindrer, at den sårbare kode udføres.
   • Hvis deaktivering vil bryde kritisk funktionalitet, og du ikke kan gøre det, skal du begrænse adgangen til plugin-endepunkter:
     • Bloker plugin AJAX- eller REST-anmodninger på webserver-/WAF-niveau (eksempler nedenfor).
     • Deaktiver brugerregistrering (Indstillinger > Generelt), hvis åben registrering ikke er påkrævet.
     • Begræns midlertidigt webstedet til kun indloggede brugere ved hjælp af en vedligeholdelsesside eller HTTP-godkendelse.
   • Rotér adgangskoder og udløb sessioner for administratorer og alle privilegerede brugere (se hændelsesrespons nedenfor).
4. Hærdningstrin, der skal anvendes straks
   • Håndhæve stærke adgangskoder for alle konti med forhøjede roller.
   • Aktiver to-faktor autentificering for administrator og alle privilegerede konti.
   • Begræns muligheden for at oprette brugere til kun betroede roller.
   • Hvis du ikke har en WAF aktiveret, overvej at aktivere en straks for at blokere udnyttelsesforsøg.

---

Hvordan en angriber kunne misbruge denne sårbarhed (angrebsscenarier)

De præcise implementeringsdetaljer for udnyttelsen afhænger af, hvilken endpoint der var sårbar, men almindelige scenarier inkluderer:

• Abonnent → opret eller ændre en administrator konto
  • En abonnent kalder en plugin-handling, der accepterer et brugernavn/e-mail og udfører en opdatering på en anden bruger uden at verificere rettigheder. Angriberen indstiller admin e-mail/adgangskode eller opretter en ny administrator.
• Abonnent → nulstil admin adgangskode via en intern proces
  • Plugin'et kan have en endpoint, der kan misbruges til at udløse nulstilling af adgangskode eller indstille bruger meta felter uden rettighedskontroller.
• Abonnent → udfør vilkårlige handlinger, der fører til kodeudførelse
  • Efter at have fået admin-rettigheder, installerer angriberen et bagdørs-plugin eller ændrer tema-filer for at forblive ved magten.

Nogle udnyttelseskæder kan kombinere:

• En offentlig registreringsformular til at oprette en abonnentkonto, derefter den brudte adgangskontrol endpoint for at eskalere.
• Social engineering for at få en eksisterende abonnent til at klikke på et ondsindet link (hvis CSRF er muligt).

På grund af disse muligheder, behandl sårbarheden som en fuld overtagelsesrisiko, indtil det modsatte er bevist.

---

Hvordan man opdager, om dit site blev målrettet eller kompromitteret.

Hvis du allerede er blevet kompromitteret, så kig efter følgende indikatorer. Undersøg straks eventuelle positive matches.

1. Anomalier i brugerkonti
   • Nye brugere med Administrator rolle oprettet for nylig.
   • Administrator e-mails eller brugernavne ændret uventet.
   • Brugere med mismatchede roller i wp_users / wp_usermeta tabellerne.

   Nyttige WP‑CLI-kommandoer:

   wp bruger liste --role=administrator --fields=ID,user_login,user_email,registered,display_name

   wp bruger liste --felt=ID --format=csv --rolle=administrator --efter=7dage

2. Godkendelse og sessionsanomalier
   • Nye sessioner for admin-konti fra usædvanlige IP-adresser eller lande.
   • Login-begivenheder på mærkelige tidspunkter (tjek webserverlogfiler og eventuelle godkendelseslogfiler).
3. Filsystemændringer
   • For nylig ændrede filer i wp-content/plugins, wp-content/themes eller wp-content/uploads.
   • Mistænkelige PHP-filer tilføjet i uploads eller tilfældige mapper.
   • Se efter base64-kodede payloads, eval() eller obfuskeret kode.

   Eksempler:

   find wp-content -type f -mtime -7 -print
   

4. Ændrede indstillinger, planlagte opgaver eller hooks
   • Tjek wp_options for usædvanlige værdier i aktive_plugins, cron, eller pluginindstillinger.
   • Se efter uventede planlagte begivenheder:

   wp cron begivenhed liste --forfald
   

5. Udegående netværksaktivitet
   • Uventede udgående forbindelser fra serveren (tjek firewall-logfiler, netstat eller hostudbyderens logfiler).
   • Nye processer eller planlagte opgaver, der kalder eksterne websteder.
6. Logbeviser
   • Inspicer webserverens adgangslogfiler for POST/GET-anmodninger, der rammer plugin-endepunkter eller admin-ajax.php med usædvanlige parametre.
   • Se efter anmodninger fra den samme IP, der opretter en abonnent og derefter udfører hævede handlinger.
7. Brug pluginets egne logfiler
   • Ironisk nok logger Simple History begivenheder. Hvis pluginet blev logget, mens det var sårbart, skal du gennemgå pluginets egne logfiler for at opdage anomaløse handlinger og tidsstempler.

Hvis du finder beviser for kompromittering, isoler stedet (tag det offline eller aktiver vedligeholdelsestilstand), bevar logfiler og følg tjeklisten for hændelsesrespons nedenfor.

---

Tjekliste for håndtering af hændelser (hvis du har mistanke om kompromittering)

1. Isoler og bevar
   • Sæt stedet i vedligeholdelsestilstand eller afbryd fra netværket, hvis det er muligt.
   • Bevar logfiler (webserver, database, plugin-logfiler, WAF-logfiler) og tag snapshots af filsystemet.
   • Eksporter en database dump til offline analyse.
2. Rotér legitimationsoplysninger og tilbagekald sessioner.
   • Nulstil adgangskoder for alle administrator-konti straks.
   • Afslut aktive sessioner (brug plugins eller WP‑CLI til at udløbe sessioner).
   • Rotér eventuelle API-nøgler, SSH-nøgler eller andre hemmeligheder, der er til stede på stedet/serveren.
3. Rens eller gendan
   • Hvis stedet blev kompromitteret, er en ren gendannelse fra en kendt god backup før kompromitteringen den sikreste mulighed.
   • Hvis gendannelse ikke er mulig, fjern bagdøre og ondsindede filer omhyggeligt (kun af erfarne respondenter). Se efter webshells og obfuskeret kode.
   • Geninstaller WordPress-kernen, temaet og plugins fra originale kilder.
4. Genanvend sikkerhedskontroller.
   • Opdater Simple History til 5.27.0 eller senere.
   • Hærd stedet med stærke adgangskoder, 2FA og princippet om mindst privilegium.
   • Patch serversoftware og PHP til understøttede versioner.
5. Overvågning efter hændelsen
   • Hold stedet under tæt overvågning i mindst 30 dage efter afhjælpning.
   • Overvåg logfiler for gentagne adgangsforsøg eller mistænkelig aktivitet.
6. Rapportér og koordiner
   • Hvis kompromitteringen påvirker kunder eller brugere, forbered offentliggørelse og afhjælpningskommunikation i henhold til lokale regler.
   • Hvis du er en tjenesteudbyder, så lad dine kunder vide, hvad du har gjort, og hvad de kan forvente.

---

Midlertidige tekniske afhjælpninger, du kan anvende nu

Hvis en øjeblikkelig opdatering ikke er mulig, kan du anvende en eller flere af disse afbødninger for at begrænse eksponeringen:

1. Deaktiver plugin'et
   • Simpleste og mest pålidelige. Bryder plugin-funktionalitet, men forhindrer udnyttelse.
2. Bloker plugin-endepunkter ved webserveren

   Eksempel: deaktiver adgang til en kendt AJAX-endepunktssti fra ikke-administrator IP'er. Erstat endepunktssti med den faktiske sti observeret i din installation.

   Nginx eksempel:

   # Bloker adgang til plugin-handling fra offentlig
   

   Apache (.htaccess) eksempel:

   <If "%{REQUEST_URI} =~ m#admin-ajax\.php# and %{QUERY_STRING} =~ /action=simple_history_some_action/">
       Require all denied
   </If>
   

   Bemærk: Disse eksempler er generiske. Du skal inspicere din sides nøjagtige endepunkter og parametre, før du blokerer.

3. Begræns adgang efter rolle via en lille mu-plugin

   Tilføj en must-use plugin, der nægter adgang til specifikke plugin-handlinger, medmindre brugeren er administrator.

   Eksempel mu-plugin (placeres i wp-content/mu-plugins/disable-simple-history.php):

   <?php;
   

   Juster betingelsen for at matche plugin'ets anmodningsparametre.

4. Bloker kendte dårlige IP-områder og begræns registrering
   • Deaktiver åben registrering (Indstillinger → Generelt → Medlemskab).
   • Brug .htaccess, Nginx eller din hostingkontrolpanel til at blokere mistænkelige IP'er.
5. Tilføj en WAF-regel (anbefales til værter og webstedsejere)
   • Konfigurer WAF til at blokere anmodninger, der forsøger rolleopgraderingshandlinger fra ikke-administrator autentificerede sessioner.
   • Hvis du kører WP-Firewall, skal du aktivere den virtuelle patchingregel for denne sårbarhed for at blokere udnyttelsesforsøg, indtil du opdaterer plugin'et.

---

Hærdning & forebyggelse: langsigtede anbefalinger

For at reducere risikoen for lignende sårbarheder i fremtiden:

1. Mindste privilegium & rollehygiejne
   • Gennemgå regelmæssigt brugerroller. Fjern unødvendige konti og tilbagekald admin-rettigheder, hvor det ikke er nødvendigt.
   • Brug rolleadskillelse: opret redaktør-/lederroller til indholdsopgaver, ikke admin.
2. Omfavn opdateringer og testning
   • Hold WordPress core, plugins og temaer opdaterede.
   • Test plugin-opdateringer i et staging-miljø før produktion, når det er muligt.
3. Brug to-faktor autentificering
   • 2FA for administratorer og andre privilegerede brugere reducerer risikoen for kontoovertagelse, selvom legitimationsoplysninger lækkes.
4. Brug en webapplikationsfirewall og virtuel patching
   • En WAF kan blokere udnyttelsesforsøg mod kendte sårbarheder, før du opdaterer. Virtuel patching giver dig tid til at anvende en ordentlig opdatering.
   • Konfigurer din WAF til at logge blokerede forsøg, så du kan opdage målrettede scanninger.
5. Implementer logning og advarsler
   • Hold detaljerede logfiler over administrative handlinger og login-forsøg. Konfigurer alarmer for ny admin-oprettelse eller masseændringer af brugere.
6. Sikker udviklingspraksis for plugin-forfattere (til plugin-vedligeholdere, der læser dette)
   • Tjek altid kapabiliteter (current_user_can()) på handlinger og verificer nonces for enhver handling, der ændrer tilstand.
   • Brug REST API tilladelsescallbacks, der tjekker kapabiliteter korrekt.
   • Test endpoints for mindst privilegium overtrædelser under sikkerhedsanmeldelser.

---

Praktiske tjek og kommandoer, du kan køre nu

• Tjek plugin-version:

  wp plugin status simple-history --field=version

• Opdater plugin:

  wp plugin opdatering simple-history

• Deaktiver plugin:

  wp plugin deaktiver simple-history

• Liste over administratorbrugere:

  wp user list --role=administrator --fields=ID,user_login,user_email,registered --format=table

• Søg efter nyligt ændrede filer:

  find . -type f -mtime -7 -print

• Søg efter mistænkelige PHP-mønstre:

  grep -R --exclude-dir=vendor -E "eval\(|base64_decode\(|gzinflate\(" .

• Inspicer webserverlogfiler for mistænkelige POSTs:

  # Nginx eksempel
  

---

Eksempel på WAF-regellogik (konceptuel)

Nedenfor er en konceptuel WAF-regel, du kan implementere i din Web Application Firewall eller serverregler. Indsæt ikke som‑er uden at teste.

• Bloker anmodninger til plugin AJAX-handlinger eller REST-endepunkter, hvis:
  • Anmodningen stammer fra en logget‑ind bruger, der ikke er administrator OG
  • Anmodningen forsøger at ændre andre brugere eller ændre roller.

Hvis request.uri indeholder "/admin-ajax.php" eller request.uri starter med "/wp-json/simple-history/"

Hvis du bruger administrerede firewall-regler fra en betroet udbyder, skal du aktivere reglen for denne Simple History sårbarhed. Dette er den mest ligetil midlertidige beskyttelse.

---

Hvorfor plugin-opdateringer og WAF'er betyder noget (virkeligheden)

I adskillige hændelser, vi har undersøgt, har en lille manglende funktion eller nonce-kontrol i et plugin været alt, hvad en angriber har brug for for at få administratoradgang. Automatiserede scannere opdager hurtigt sårbare plugin-versioner på tværs af tusindvis af websteder; når udnyttelsen er triviel (abonnent kan eskalere), itererer angribere og massen udnytter.

En lagdelt tilgang — rettidige opdateringer, brugerrollehygiejne og en WAF, der giver virtuel patching — forhindrer både opportunistiske og målrettede angreb. WAF'en erstatter ikke opdateringer, men når den bruges korrekt, giver den dig luft til at teste og implementere patches uden at være straks sårbar.

---

WP‑Firewall hjælper med at beskytte dine websteder

Beskyt dit websted lige nu — start med gratis administreret firewall-beskyttelse

Hvis du ønsker øjeblikkelig, praktisk beskyttelse, mens du opdaterer Simple History og udfører en hændelsesgennemgang, tilbyder WP‑Firewall en gratis Basic-plan, der giver essentielle beskyttelseskomponenter:

• Administreret firewall med øjeblikkelige virtuelle patch-regler for kendte sårbarheder
• Ubegribelig båndbredde og højtydende anmodningsfiltrering
• Web Application Firewall (WAF), der afbøder OWASP Top 10-risici
• Malware-scanner til at opdage almindelige webshells og anomalier

Opgraderingsmuligheder (Standard, Pro) tilføjer funktioner som automatisk malwarefjernelse, IP-blacklist/hvidlistekontrol, månedlige sikkerhedsrapporter og automatisk virtuel patching for nye sårbarheder — nyttigt hvis du administrerer mange websteder eller kræver en hands-off sikkerhedsholdning.

Start en gratis Basic-plan i dag og få beskyttelse, mens du patcher: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

---

Endelig tjekliste — handling du bør tage nu

1. Tjek alle websteder for Simple History og bekræft version.
2. Opdater til Simple History 5.27.0 straks. Hvis du ikke kan:
   • Deaktiver plugin'et, eller
   • Anvend midlertidige WAF / webserver blokeringer, og
   • Deaktiver registrering, hvis det ikke er nødvendigt.
3. Rotér administratoradgangskoder og afslut aktive sessioner.
4. Gennemgå brugere og se efter nye eller ændrede administrator konti.
5. Scann for webshells og mistænkelige filændringer.
6. Aktiver 2FA for administratorer og privilegerede konti.
7. Aktiver logning og tilføj alarmer for ny oprettelse af administratorer eller rolleændringer.
8. Overvej at aktivere WP‑Firewall eller en anden WAF for at blokere udnyttelsesforsøg indtil fuld afhjælpning.

---

Afsluttende tanker

En brudt adgangskontrol sårbarhed, der kan nås af abonnentkonti, er en “et klik til katastrofe” klasse af risiko for WordPress-websteder. Vær ikke selvtilfreds - tjek dine installationer nu. Hvis du administrerer flere websteder, så behandl dette som en højprioritets patch-kørsel. Brug denne mulighed for at styrke dine opdateringsprocesser, forstærke brugerroller og implementere en WAF for at købe tid mod hurtige angreb.

Hvis du har brug for hjælp til at triagere en hændelse eller anvende afbødninger på tværs af mange websteder, kan vores sikkerhedsteam hjælpe med analyse, oprydninger og langsigtede hærdningsprogrammer. Sørg for at bevare logs og beviser, hvis du mistænker kompromittering - de er afgørende for en vellykket genopretning.

Hold dig sikker, og patch hurtigt.

— WP-Firewall Sikkerhedsteam

---

Bilag: Nyttige ressourcer og kommandoer (resumé)

• Opdater plugin via WP‑Admin eller WP‑CLI:

  wp plugin opdatering simple-history

• Deaktiver plugin:

  wp plugin deaktiver simple-history

• List administratorbrugere:

  wp-brugerliste --rolle=administrator

• Find nyligt ændrede filer:

  find . -type f -mtime -7 -print

• Hurtig filscanning for obfuskation:

  grep -R --exclude-dir=vendor -E "eval\(|base64_decode\(|gzinflate\(" .

Hvis du ønsker en tjekliste PDF eller hjælp til at anvende midlertidige WAF-regler på tværs af flere websteder, så kontakt vores supportteam via dit WP‑Firewall dashboard.