# A javítás és a támadás közötti időablak

> A javítás és a támadás közötti időablak elmagyarázva: a PHP2Shell fázisai, hogyan mérheti a saját ablakát, és mely lépésekkel rövidítheti le.

Forrás: https://phpsos.de/hu/blog/zeitfenster-patch-angriff/  
Á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 javítás és a támadás közötti időablak a PHP2Shellnél negatív volt: médiabeszámolók szerint az első támadási kísérlet már 2026. október 17-én történt, négy nappal a frissítések előtt. Az üzemeltetők számára ezért nem az a kérdés, hogy „Mennyi idő marad?”, hanem hogy „Mennyi ideig van nyitva a szerverem?”. Ez a személyes ablak csak akkor zárul be, ha a frissítés telepítve van, és az összes PHP-folyamat újraindult.

## A kiindulópont: támadások a javítás előtt

Sokáig kényelmes feltevés élt: a biztonsági frissítés és az első támadások között eltelik néhány nap, elég a következő karbantartási ablakra. A PHP2Shell megcáfolta ezt a feltevést. Az Amazonra hivatkozó médiabeszámolók szerint az első támadási kísérletet már október 17-én megfigyelték. A Cloudflare szintén korai támadásokról számolt be. A javítások október 21-én 14:00 UTC-kor érkeztek.

Ez az írás elmagyarázza, hogyan keletkeznek ilyen időablakok, és hogyan rövidítheti le a sajátját. A pontos időrendet a [PHP2Shell idővonal](https://phpsos.de/hu/ratgeber/php2shell-chronologie/) tartalmazza.

## A javítás és a támadás közötti időablak fázisai

Egy biztonsági rés körül több fázis különböztethető meg. A PHP2Shellnél így néztek ki:

| Fázis | Általában | A PHP2Shellnél |
|---|---|---|
| Az ismertté válás előtt | A rést csak a felfedezők és a gyártó ismeri | a javítás fejlesztése embargó alatt |
| Első támadások javítás nélkül | A támadók kihasználják a rést, mielőtt frissítés létezne | médiabeszámolók szerint az első kísérlet október 17-én |
| Előzetes bejelentés | A gyártó bejelenti a frissítést | október 20., a php.net bejelenti a kiadást |
| A javítás elérhető | Megjelenik a frissítés és a biztonsági közlemény | október 21., 14:00 UTC |
| A javítás kiértékelése | A kutatók és a támadók elemzik a változásokat | a watchTowr saját közlése szerint reprodukálta a CVE-2026-109618-at |
| Széles körű kihasználás | automatizált kampányok javítatlan szerverek ellen | a BSI várta; megerősített, széles körű sikeres támadások kezdetben nem voltak ismertek |
| Az Ön javítása | frissítés és újraindítás az Ön szervereinek | egyedi |

Az utolsó sor az egyetlen, amelyet befolyásolhat. Mindent előtte mások határoznak meg.

## Miért növeli maga a javítás a nyomást

Egy biztonsági frissítés bezárja a rést, de egyúttal láthatóvá is teszi. A nyílt forráskódú projektek, például a PHP forráskód-változásai nyilvánosak. Aki összehasonlítja a régi és az új verzió közötti különbségeket, megtudja, hol volt a hiba. Ez nem szemrehányás a PHP-projektnek, hanem a nyílt szoftver normális esete, és az alapja annak, hogy a disztribúciók backportokat készíthessenek.

Az üzemeltetők számára ebből következik: a javítás utáni minden nappal nő azok száma, akik tudják, hogyan működik a rés. Egyidejűleg csökken a javítatlan szerverek száma. A megmaradók ezzel a kézenfekvő célpontok lesznek. Hogyan szállítja a PHP a biztonsági frissítéseket a verziógondozása keretében, azt a [PHP kiadási ciklusa](https://phpsos.de/hu/php/release-zyklus/) írás magyarázza.

> **Azonnal cselekedjen:**
> Ha a szervere október 17. és az Ön javítása között elérhető volt, a nyomok ellenőrzése is hozzátartozik. Mentse a naplókat október 20-tól, mielőtt a rotáció miatt elvesznének.

## Mérje meg a saját időablakát

A személyes időablaka legkésőbb a javítások közzétételével kezdődik, és az utolsó PHP-folyamat újraindításával ér véget. Rögzítse minden szerverre:

- **Tudomásszerzés:** Mikor értesült valaki a vállalatnál a résről?
- **Elérhetőség:** Mikor állt rendelkezésre a disztribúciója vagy a tárhelyszolgáltatója csomagja?
- **Telepítés:** Mikor telepítették?
- **Újraindítás:** Mikortól nem futott már régi PHP-folyamat?

Éppen az újraindítást felejtik el gyakran. A telepített frissítés csak akkor hat, ha a régi folyamatok leálltak. Hogyan ellenőrizze ezt, azt a [PHP-FPM és az összes PHP-folyamat újraindítása](https://phpsos.de/hu/php2shell/php-fpm-neustart/) írja le. Hogy futnak-e még a frissítés előtti folyamatok, azt egy pillantás az indítási időkre mutatja:

```bash
# Az összes PHP-folyamat indítási idejének kijelzése
ps -eo pid,lstart,cmd | grep -E "php-fpm|php-cgi|lsphp" | grep -v grep
```

Ha az indítási idő a frissítés telepítése előtt van, az ablak még nyitva van.

### Miért függ az ablaka a beszerzési úttól

Hogy milyen gyorsan tud javítani, az nemcsak Öntől függ, hanem attól is, honnan származik a PHP-je. A disztribúciók beszámolók szerint a backportokat részben még október 21-én kiszállították. Aki harmadik féltől származó tárolóból szerzi be a PHP-t, annak a tempójára van utalva. Aki konténereket használ, annak újra kell építenie és ki kell gördítenie az image-eket, a futó konténerben végzett puszta frissítés nem elég. A megosztott tárhelynél pedig a tárhelyszolgáltató határozza meg az időpontot.

Ha ismeri minden szerver beszerzési útját, azt is tudja, hol marad nyitva a legtovább az ablaka. Pontosan ott éri meg a legjobban az előkészület, például egy tárhelyszolgáltatóval kötött megállapodással vagy az új konténerképekhez kipróbált folyamattal.

## Így rövidítse le az időablakot legközelebb

1. **Iratkozzon fel a közleményekre:** A php.net és a disztribúciója biztonsági közleményeit közvetlenül kapja meg, ne a sajtón keresztül.
2. **Határozza meg a felelősséget:** Minden szerverhez egy felelős személy helyettesítéssel.
3. **Használjon automatizmust, ahol megfelel:** A disztribúció biztonsági frissítései automatikusan telepíthetők. Hogy mi szól mellette és mi ellene, azt az [Automatikus biztonsági frissítések](https://phpsos.de/hu/blog/automatische-sicherheitsupdates/) írja le.
4. **Tervezze be az újraindítást:** A PHP-szolgáltatások újraindítása a folyamat fix része, nem az utómunkáé.
5. **Készítsen elő vészutat:** vészhelyzeti oldal és döntés az átmeneti leállításról, ha egy frissítés nem lehetséges azonnal.
6. **Vezessen igazolást:** Dokumentálja a telepítés és az újraindítás időpontját, hogy később igazolni tudja az ablakát.

Egy tartós folyamatot, amely ezeket a pontokat egybefogja, a [Javításkezelési folyamat](https://phpsos.de/hu/blog/patch-management-prozess/) írás ír le.

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

- **Javítás és újraindítás:** Telepítjük a frissítést, és biztosítjuk, hogy ne fusson többé régi PHP-folyamat.
- **Az időablak igazolása:** Szerverenként dokumentáljuk a telepítést és az újraindítást időponttal.
- **Nyomok ellenőrzése:** Arra az időre, amíg a szervere nyitva volt, mentjük a naplókat, és feltűnő jelenségeket keresünk.
- **Folyamat a jövőre:** Önnel közösen kialakítjuk a jelentési útvonalakat, a felelősségeket és a frissítési folyamatokat.

További információ a [PHP-javítási szolgáltatás](https://phpsos.de/hu/leistungen/php-patch-service/) oldalon.

## Összegzés

A PHP2Shellnél nem volt türelmi idő. A javítás és a támadás közötti időablak kritikus réseknél ma gyakran nulla vagy akár negatív. Amit irányíthat, az a saját ablaka: az újraindítással ér véget, és előkészülettel napokról órákra rövidíthető.


## Gyakori kérdések

**Mennyi idő marad egy biztonsági frissítés után a támadásokig?**  
Rögzített határidő nincs. A PHP2Shellnél médiabeszámolók szerint az első támadási kísérletet már október 17-én megfigyelték, vagyis négy nappal a javítások előtt. Elterjedt szoftver kritikus réseinél abból kell kiindulnia, hogy gyakorlatilag nincs türelmi idő.

**Mi az a zero-day?**  
Olyan rés, amelyet megtámadnak, mielőtt frissítés elérhető lenne. A gyártónak bizonyos értelemben nulla napja volt a kijavításra. Utána gyakran ismert vagy N-day résről beszélnek, amelyhez már van javítás.

**Miért gyakoribbak a támadások gyakran a javítás után?**  
A javítással nyilvánossá válik, hol volt a hiba. A biztonsági kutatók és a támadók kiértékelhetik a változásokat. Egyidejűleg sok szerver még napokig vagy hetekig javítatlan marad, és ezáltal kifizetődő célpont.

**Mikor van a szerverem valóban védve?**  
Ha a frissítés telepítve van, és az összes PHP-folyamat újraindult. Az új fájlok önmagukban nem hatnak, amíg régi folyamatok futnak a memóriában. A személyes időablaka vége tehát az újraindítás, nem a letöltés.

## Források

- [php.net: biztonsági közlemények](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [BleepingComputer: PHP ships emergency patches for critical PHP2Shell flaws](https://bleepingcomputer.com/news/security/php-ships-emergency-patches-for-critical-php2shell-flaws)
- [Help Net Security: PHP2Shell vulnerabilities patched](https://helpnetsecurity.com/2026/10/21/php2shell-php-vulnerabilities-patched-cve-2026-109618-cve-2026-109619)