# Backdoor v WordPressu: sistematično iskanje stranskih vrat

> Backdoor v WordPressu najdete z WP-CLI: preverite jedro, vtičnike, skrbniške račune, mu-plugins in podatkovno zbirko ter varno zaprite stranska vrata.

Vir: https://phpsos.de/sl/ratgeber/backdoor-wordpress-finden/  
Stanje: 25.10.2026  
Ponudnik: PHP SOS, Nujna pomoč za PHP in varnost strežnikov. Takojšnja pomoč po WhatsAppu: https://wa.me/491736494914?text=Pozdravljeni%2C%20PHP%20SOS%2C%20potrebujemo%20pomo%C4%8D%20z%20na%C5%A1im%20stre%C5%BEnikom%20PHP.%20Podjetje%3A%20%E2%80%A6%20Spletna%20stran%3A%20%E2%80%A6

**Na kratko:** Backdoor v WordPressu najhitreje najdete tako, da jedro in vtičnike z WP-CLI primerjate z uradnimi kontrolnimi vsotami, nato pa ciljno pregledate mu-plugins, nalaganja, `wp-config.php`, skrbniške račune in podatkovno zbirko. Pomembno po PHP2Shell: posodobitev WordPressa ranljivosti PHP ne zapre in obstoječih stranskih vrat ne odstrani.

## Zakaj naj upravljavci WordPressa zdaj pogledajo natančneje

S PHP2Shell sta oktobra 2026 postali znani dve kritični ranljivosti v samem PHP, CVE-2026-109618 in CVE-2026-109619. Omogočata izvajanje škodljive kode brez prijave, ne glede na to, kako vzdrževana je vaša namestitev WordPressa. Popravki obstajajo od 21. 10. 2026, po poročilih medijev pa je bil prvi poskus napada opažen že 17. 10.

Kdor je bil v tem obdobju ranljiv, naj išče sledi. WordPress je pri tem tipična tarča, ker so številne namestitve podobno zgrajene in napadalci poznajo skrivališča. Kaj morajo upravljavci glede PHP2Shell storiti na splošno, piše na strani [WordPress in PHP2Shell](https://phpsos.de/sl/plattformen/wordpress/).

Naslednja preverjanja po možnosti izvedite na kopiji ali po varnostnem kopiranju. Ukazi samo berejo in nič ne spremenijo.

## Po čem backdoor opazite v vsakdanu

Stranska vrata so zasnovana tako, da ostanejo neopazna. Kljub temu obstajajo znaki, ki jih opazite tudi brez tehničnega znanja. Sem sodijo preusmeritve na tuje strani, ki se pojavijo samo pri obiskovalcih iz Googlovega iskanja ali samo na mobilnih napravah. Sumljive so tudi nove strani z oglasi za zdravila, igre na srečo ali kopije blagovnih znamk, ki se pojavijo v iskalnem indeksu, ne pa v zaledju WordPressa.

Dodatni namigi so opozorila Googla ali brskalnika, pritožbe strank zaradi neželene pošte z vaše domene, nenadoma močno povečana poraba računskega časa pri ponudniku gostovanja ali skrbniki, ki jih v ekipi nihče ne pozna. Nobeden od teh znakov sam ne dokazuje backdoora. Če jih nastopi več hkrati, naslednjih preverjanj ne odlašajte.

Obratno velja: če nič od tega ne pade v oči, to ne pomeni, da je namestitev čista. Prav stranska vrata, ustvarjena samo za poznejši dostop, navzven pogosto sploh nimajo učinka.

## Iskanje backdoora v WordPressu: preverite jedro in vtičnike

WP-CLI lahko datoteke jedra WordPressa in vtičnikov iz uradnega imenika primerja z objavljenimi kontrolnimi vsotami. Vsako odstopanje je konkretno preverjanje.

```bash
cd /var/www/meine-seite
# Datoteke jedra glede na uradne kontrolne vsote
wp core verify-checksums
# Vtičniki iz uradnega imenika
wp plugin verify-checksums --all
# Nameščene različice in stanje
wp plugin list
wp theme list
```

Komercialnih vtičnikov in tem na ta način ni mogoče preveriti. Zanje pomaga samo primerjava s sveže prenesenim izvirnim paketom ponudnika. Neznani vtičniki, ki jih v ekipi ni namestil nihče, so vedno sumljivi, tudi če so videti deaktivirani.

## Značilna skrivališča v datotečnem sistemu

Nekatera mesta se pri kompromitiranih namestitvah WordPressa pojavljajo znova in znova:

- `wp-content/mu-plugins/`: nalaga se samodejno in se ne pojavi na običajnem seznamu vtičnikov.
- `wp-content/uploads/`: tja sodijo slike in dokumenti, ne datoteke PHP.
- `wp-config.php`: dodatne vrstice `include` ali `require` na začetku ali koncu.
- `.htaccess` in `.user.ini` v spletni mapi in podmapah: nepričakovane preusmeritve ali samodejno predhodno naložene datoteke.
- Datoteke v glavni mapi, katerih imena spominjajo na jedrne datoteke WordPressa, a ne sodijo zraven.

```bash
# Datoteke PHP v mapi za nalaganje
find wp-content/uploads -type f -name "*.php*"
# Vsebina must-use vtičnikov
ls -la wp-content/mu-plugins/
# Vse datoteke .htaccess in .user.ini z datumom spremembe
find . \( -name ".htaccess" -o -name ".user.ini" \) -exec ls -la {} +
# Nedavno spremenjene datoteke PHP
find . -type f -name "*.php" -newermt "2026-10-17" -ls
```

Splošne vzorce iskanja zakrite kode opisuje vodnik [Prepoznavanje in odstranitev webshellov](https://phpsos.de/sl/ratgeber/webshell-erkennen/).

## Preverite uporabnike, podatkovno zbirko in načrtovana opravila

Številna stranska vrata sploh niso v datotečnem sistemu. Dodaten skrbniški račun napadalcem pogosto zadošča, da se pozneje vrnejo.

```bash
# Vsi skrbniki z datumom registracije
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
# Načrtovana opravila v WordPressu
wp cron event list
# Naslov spletne strani (manipulacije vodijo do preusmeritev)
wp option get siteurl
wp option get home
# Prispevki z vdelanimi skriptami
wp db query "SELECT ID, post_title FROM $(wp db prefix)posts WHERE post_content LIKE '%<script%'"
```

Preverite tudi opcije z nenavadno velikimi vsebinami in gradnike s tujo kodo. Zadetki samodejno ne pomenijo napada, saj skripte uporabljajo tudi sledilne kode ali vdelani zemljevidi. Odločilno je, ali vsebino kdo v ekipi pozna.

> **Pomembno:**
> Po najdbi zamenjajte vsa gesla in varnostne ključe v `wp-config.php`. Sicer obstoječe prijave napadalcev ostanejo veljavne.

## Zapiranje stranskih vrat in preprečevanje vrnitve

Če ste backdoor našli, je ponovna namestitev praviloma varnejša od popravljanja posameznih datotek. Preizkušeno je to zaporedje:

1. Zavarujte sledi: dnevnike, sumljive datoteke in izvoz podatkovne zbirke shranite z datumom.
2. PHP posodobite na odpravljeno stanje in znova zaženite vse procese PHP.
3. Jedro WordPressa, vtičnike in teme na novo namestite iz izvirnih virov.
4. Nalaganja in podatkovno zbirko prevzemite po preverjanju, tuje račune izbrišite, zamenjajte vse dostope.
5. Izvajanje PHP v mapi za nalaganje preprečite na ravni strežnika.

Za Nginx zadošča blok v konfiguraciji strežnika:

```nginx
location ~* ^/wp-content/uploads/.*\.php$ {
    deny all;
}
```

Pri Apacheju enako dosežete s pravilom v konfiguraciji strežnika za mapo za nalaganje. Datoteka `.htaccess` v sami mapi za nalaganje je šibkejša, ker jo lahko napadalec s pravicami pisanja znova spremeni.

Po čiščenju načrtujte nekaj tednov strožjega opazovanja. Novi skrbniki, nove datoteke PHP in spremembe v `wp-config.php` bi se morali v tem času takoj izpostaviti, na primer z rednim preverjanjem z WP-CLI ali nadzorom datotek na strežniku.

Kako nato pravice datotek nastavite tako, da lahko WordPress piše samo tam, kjer je potrebno, kaže vodnik [Pravice datotek na spletnem strežniku](https://phpsos.de/sl/ratgeber/dateirechte-webserver/).

## Kako PHP SOS pomaga konkretno?

- Stanje namestitve zavarujemo, še preden se karkoli spremeni.
- Jedro, vtičnike, teme, podatkovno zbirko, račune in konfiguracijo strežnika preverimo glede stranskih vrat.
- WordPress znova postavimo iz čistih virov in prevzamemo samo preverjene vsebine.
- Strežnik in namestitev utrdimo ter dokumentiramo, kaj je bilo najdeno in odpravljeno.

Potek čiščenja opisuje storitev [Odstranitev zlonamerne programske opreme in webshellov](https://phpsos.de/sl/leistungen/malware-entfernung/).


## Pogosta vprašanja

**Ali posodobitev WordPressa zapre ranljivost PHP2Shell?**  
Ne. PHP2Shell je v interpreterju PHP, ne v WordPressu. Posodobitev WordPressa, tem ali vtičnikov tega ne spremeni; odločilni sta stanje PHP na strežniku in ponovni zagon vseh procesov PHP.

**Ali varnostni vtičnik najde vse backdoore?**  
Ne zanesljivo. Vtičnik teče znotraj kompromitirane namestitve in je lahko sam manipuliran. Dopolnite ga s preverjanji od zunaj, na primer s kontrolnimi vsotami WP-CLI in primerjavo s čistimi izvirnimi datotekami.

**Kaj so mu-plugins in zakaj so sumljivi?**  
Must-use vtičniki v mapi wp-content/mu-plugins se naložijo samodejno in se ne pojavijo na običajnem seznamu vtičnikov. Napadalci to radi izkoriščajo, ker upravljavci to mapo redko pregledajo.

**Ali je backdoor lahko tudi v podatkovni zbirki?**  
Da. Škodljiva koda ali preusmeritve so pogosto shranjene v opcijah, prispevkih ali gradnikih. Poleg tega napadalci pogosto ustvarijo lastne skrbniške račune, ki jih najdete v tabeli uporabnikov.

## Viri

- [WordPress.org](https://wordpress.org/)
- [php.net: varnostna obvestila](https://www.php.net/)
- [OWASP Cheat Sheet Series](https://cheatsheetseries.owasp.org/)