# A PHP2Shell öt percben: tájékoztató az ügyvezetésnek

> A PHP2Shell öt percben: a helyzet, az üzleti kockázat, öt kérdés az IT-nek, és azok a döntések, amelyeket az ügyvezetőknek ma meg kell hozniuk.

Forrás: https://phpsos.de/hu/blog/php2shell-briefing-geschaeftsfuehrung/  
Állapot: 2026. 10. 25.  
Szolgáltató: PHP SOS, PHP-vészhelyzeti segítség és szerverbiztonság. Azonnali segítség WhatsAppon: https://wa.me/491736494914?text=%C3%9Cdv%C3%B6zl%C3%B6m%2C%20PHP%20SOS%21%20Seg%C3%ADts%C3%A9gre%20van%20sz%C3%BCks%C3%A9g%C3%BCnk%20a%20PHP-szerver%C3%BCnkkel.%20C%C3%A9g%3A%20%E2%80%A6%20Weboldal%3A%20%E2%80%A6

**Röviden:** A PHP2Shell PHP biztonsági rés két kritikus hibából áll a PHP-ban, amely a legtöbb weboldal és webshop alapja. A támadók ezeken keresztül jelszó nélkül kártékony kódot futtathatnak webszervereken. A BSI (a német szövetségi információbiztonsági hivatal) narancs szinttel figyelmeztet, és azt javasolja: azonnal frissíteni, különben az érintett szervereket átmenetileg leválasztani a hálózatról. Az ügyvezetés számára ez ma azt jelenti: tisztázni a felelősséget, követelni a frissítést és az igazolást, dönteni a leállításról, és mindent dokumentálni.

## A helyzet három mondatban

2026. október 21-én a PHP-projekt frissítéseket tett közzé két kritikus biztonsági résre, amely PHP2Shell néven ismert. Maga a PHP érintett, nem egy bizonyos termék, tehát potenciálisan minden PHP-vel futó weboldal, webshop és portál. A BSI 3-as / narancs riasztási szintet hirdetett, biztonsági cégek támadási kísérletekről számolnak be, széles körben megerősített sikeres támadások a BSI szerint kezdetben nem voltak ismertek.

Hatóságok, például a BKA és több város médiabeszámolók szerint elővigyázatosságból leállították weboldalaikat. Ez elővigyázatosság volt, nem támadás jele.

## Mit jelent a PHP biztonsági rés az ügyvezetésnek és a vállalatnak

A kérdés nem az, hogy használ-e PHP-t. Szinte minden vállalat használ valahol: weboldal, webshop, álláskeresői portál, ügyfélterület, intranet, ticketrendszer, ügynökségi mikrooldal. A kérdés az, hogy ezek a rendszerek naprakészek-e, és ki felelős értük.

Ha egy támadás sikerül, a támadó a legrosszabb esetben átveheti a szervert. Lehetséges következmények: adatszivárgás, manipulált tartalmak, átirányítások csaló oldalakra, a webshop kiesése vagy a szerver további támadásokra való felhasználása. Ha személyes adatok érintettek lehetnek, bejelentési kötelezettségek is adódnak; a GDPR 33. cikke szerinti határidő általában 72 óra. A részleteket a [GDPR-bejelentési kötelezettség](https://phpsos.de/hu/compliance/dsgvo-meldepflicht-72-stunden/) oldalon találja. Ez nem jogi tanácsadás.

Hogy éles helyzetben jellemzően milyen költségek merülnek fel, azt a [Egy feltörés költségtételei](https://phpsos.de/hu/blog/kostenposten-eines-hacks/) írás sorolja be.

### Hol hagyják figyelmen kívül gyakran a PHP-t a vállalatoknál

A főoldalt a legtöbben szem előtt tartják. Inkább a peremrendszerek maradnak ki: egy külső szolgáltató álláskeresői portálja, egy korábbi kampány landing oldala, egy partnerterület kereskedőknek, a támogatás ticketrendszere, egy saját szerveren lévő fájlfelhő vagy egy hálózati tároló webes felülete. Az ügynökségek tesztrendszerei is gyakran nyilvánosan elérhetők, és ugyanazon a szerveren futnak, mint a valódi weboldal.

Az ügyvezetés számára a tanulság egyszerű: az IT-nek feltett kérdés nem az, hogy „Javítva van a weboldalunk?”, hanem hogy „Javítva van minden PHP-s rendszerünk, a szolgáltatóké is?”. A két kérdés közötti különbség gyakran éppen az a hely, ahol egy támadás sikerrel jár.

### Mi nem a helyzet

Ugyanilyen fontos a lefelé történő besorolás. A PHP2Shell nem ok olyan aktivizmusra, amely a szükségesnél jobban zavarja az üzemet. Aki igazoltan javított, az összes PHP-folyamatot újraindította, és az ellenőrzés során nem talál feltűnő jelenségeket, visszatérhet a rendes működéshez. Az átmeneti leállítás a tisztázatlan esetek lehetősége, nem mindenkire vonatkozó kötelezettség.

## Öt kérdés az IT-nek vagy a szolgáltatójának

Ezeket a kérdéseket ma felteheti. A válaszoknak írásban kell érkezniük.

1. **Mely rendszereink futnak PHP-vel?** Egy lista címmel, céllal és üzemeltetővel.
2. **Javítva van minden rendszer?** Javított 8.5.12, 8.4.27, 8.3.36 vagy 8.2.35 verzió, vagy a szolgáltató által megerősített backport.
3. **Újraindították az összes PHP-folyamatot?** Újraindítás nélkül a frissítés nem hat.
4. **Mi a helyzet a PHP 8.1-es vagy régebbi rendszerekkel?** Ezekhez nincsenek hivatalos frissítések. Mi a terv?
5. **Ellenőrizték, hogy a frissítés előtt történt-e valami?** Mentették a naplókat október 20-tól, kerestek nyomokat?

Ha a weboldala tárhelyszolgáltatónál van, egy hivatalos megkeresés segít. Mintát a [A tárhelyszolgáltató PHP-frissítési igazolásának kérése](https://phpsos.de/hu/ratgeber/hoster-patch-status-erfragen/) útmutató kínál.

## A döntések, amelyeknek ma meg kell születniük

| Döntés | Lehetőségek | Alap |
|---|---|---|
| Ki vezet? | egy belső felelős személy, egy külső partner | a felelősségnek egyértelműnek kell lennie |
| Nem javított rendszerek | azonnali javítás, átmeneti intézkedések, átmeneti leállítás | BSI-ajánlás, adathelyzet, bevételi jelentőség |
| Nyomok ellenőrzése | belső, külső, csak feltűnő jelenségek esetén | a szerveren lévő adatok védelmi igénye |
| Kommunikáció | belső tájékoztatás, ügyfelek felkészítése, várakozás | az ellenőrzés utáni helyzet |
| Régi rendszerek | migráció tervezése, izolálás, leállítás | PHP 8.1 és régebbi hivatalos frissítések nélkül |

> **Fontos:**
> Rögzítse, ki mikor mit döntött el, és milyen információs alapon. Egy rövid, keltezett feljegyzés elegendő. Utólag a biztosítókkal, ügyfelekkel vagy felügyeleti szervekkel szemben gyakran többet ér bármilyen utólagos magyarázatnál.

Hogy ez a dokumentáció miért fontos a vezetésnek, azt az [Az ügyvezetés felelőssége IT-biztonsági rések esetén](https://phpsos.de/hu/compliance/geschaeftsfuehrer-haftung/) oldal magyarázza. Ez általános tájékoztatás, nem jogi tanácsadás.

## Amit nem szabad elhinnie

Három állítást hallanak jelenleg gyakran az ügyvezetők, és mindhárom téves:

- **„Frissítettük a WordPresst, tehát biztonságban vagyunk.”** A rés a PHP-ban van, nem a CMS-ben. Egy CMS-frissítés nem zárja be.
- **„Túl kicsik vagyunk, minket senki sem támad.”** A támadások automatizáltan zajlanak. Sebezhető szervereket keresnek, nem ismert neveket.
- **„A frissítés fent van, ezzel a téma elintézett.”** Egy javítás nem távolítja el a korábban bejuttatott kártékony szoftvert, és nem bizonyítja, hogy nem történt semmi.

## Hogyan segít konkrétan a PHP SOS?

- **Helyzetkép a vezetésnek:** Rövid áttekintést készítünk a PHP-rendszereiről, rendszerenkénti állapottal és ajánlással.
- **Végrehajtás:** Javítunk, újraindítunk, vagy átmeneti intézkedéseket alkalmazunk ott, ahol a frissítés még nem lehetséges.
- **Ellenőrzés:** Mentjük a naplókat, és támadás nyomait keressük.
- **Igazolás:** Dokumentációt kap, amelyet belsőleg és harmadik felekkel szemben is felhasználhat.

A folyamatot a [PHP2Shell azonnali segítség](https://phpsos.de/hu/leistungen/php2shell-soforthilfe/) írja le.

## Összegzés

A PHP2Shell egy műszaki rés vezetési feladattal. A technikát a szakemberek intézik. Az ügyvezetés gondoskodik arról, hogy valaki felelős legyen, hogy az öt kérdésre válaszoljanak, és hogy a döntések tudatosan szülessenek és dokumentálva legyenek. Ez belefér egy délelőttbe, ha ma elkezdődik.


## Gyakori kérdések

**Magának az ügyvezetésnek kell foglalkoznia a PHP2Shellel?**  
A műszaki végrehajtással nem, az irányítással igen. Az ügyvezetésnek gondoskodnia kell arról, hogy a felelősségek világosak legyenek, a BSI ajánlását végrehajtsák, és az olyan döntéseket, mint az átmeneti leállítás, tudatosan hozzák meg és dokumentálják.

**Hogyan magyarázom el a rést egy mondatban?**  
A PHP-ban, abban a szoftverben, amelyen a legtöbb weboldal és webshop fut, két kritikus hiba van, amelyeken keresztül idegenek jelszó nélkül programokat indíthatnak a szerveren; elérhető egy frissítés, amelyet telepíteni kell.

**Mibe kerül, ha nem teszünk semmit?**  
Ezt nem lehet átalánymértékben megadni. Egy sikeres támadás lehetséges következményei: leállási idő, adatszivárgás, bejelentési kötelezettségek, a tisztítás és a forenzika költségei, valamint az ügyfelek bizalmának elvesztése. Egy ellenőrzéssel végzett frissítés általában jóval kevesebb ráfordítással jár.

**Elég, ha a tárhelyszolgáltató gondoskodik róla?**  
Megosztott tárhelynél általában a tárhelyszolgáltató telepíti a frissítést. Kérje ezt írásban megerősíteni, a PHP-folyamatok újraindításával együtt. Hogy a frissítés előtt történt-e valami, arra a megerősítés nem válaszol; ahhoz a weboldal ellenőrzése kell.

## Források

- [BSI: a német Szövetségi Információbiztonsági Hivatal](https://www.bsi.bund.de/)
- [php.net: biztonsági közlemények](https://www.php.net/)
- [GDPR 33. cikk: bejelentés a felügyeleti hatóságnak](https://dsgvo-gesetz.de/art-33-dsgvo/)