PHP2Shell idővonal: kronológia 2026. október 17-től 25-ig

Röviden: A PHP2Shell idővonala eddig négy igazolt dátumot ölel fel: egy első megfigyelt támadási kísérletet 10. 17-én, a php.net előzetes bejelentését 10. 20-án, a javításokat 10. 21-én német idő szerint 16 órakor, és egy újabb közleményt a CVE-2026-115560-ról 2026. 10. 23-án. Az üzemeltetők számára ebből ez következik: javítani, az összes PHP-folyamatot újraindítani, és a naplókat legkésőbb 10. 20-tól lementeni.

Miért fontos az üzemeltetőknek a PHP2Shell idővonala

Egy ilyen súlyos résnél nem csak az számít, hogy a szervere ma javítva van-e. Az is döntő, hogy mennyi ideig volt előtte sebezhető. Ez az időablak határozza meg, mely naplókat ment le, mely fájlokat vizsgál meg, és kizárhatja-e megalapozottan a feltörést.

A PHP2Shell magát a PHP-t érinti, nem egyetlen CMS-t. Két kritikus rés, a CVE-2026-109618 és a CVE-2026-109619 lehetővé teszi kártékony kód távoli futtatását bejelentkezés nélkül. Mindkettő CVSS v4.0 szerint 9,2 értékű. Közérthető bevezetőt a Mi az a PHP2Shell? oldalon talál.

Az alábbi kronológia csak olyan dátumokat tartalmaz, amelyek a 2026. 10. 25-i állapot szerint igazoltak. Ahol egy adat médiabeszámolókon alapul, azt jeleztük.

Október 17.: az első megfigyelt támadási kísérlet

Médiabeszámolók szerint 2026. 10. 17-én megfigyeltek egy első támadási kísérletet, amelyet az Amazon jelentett. Ez négy nappal a javítások előtt volt. Volt tehát egy időszak, amelyben már kíséreltek meg támadásokat, de még nem létezett frissítés.

Hogy ebben a szakaszban hány támadás volt sikeres, és volt-e egyáltalán, az nem igazolt. A saját vizsgálata szempontjából a következmény a fontos: egy szerver, amely ma javítva van, korábban feltörhették. A javítás nem távolítja el a bejuttatott kártékony szoftvert, és nem bizonyítja, hogy korábban nem történt semmi.

Október 20. és 21.: előzetes bejelentés és javítások

2026. 10. 20-án a PHP-projekt a php.net-en bejelentette a biztonsági frissítéseket. 2026. 10. 21-én 14:00 UTC-kor, vagyis német idő szerint 16 órakor megjelentek a javított verziók.

A PHP 8.1 és régebbi verziókhoz már nincsenek hivatalos frissítések, csak minimális forráskód-backportok a 7.4, 8.0 és 8.1 verzióhoz. A szakmai sajtó szerint szinte az összes verzió érintett egészen a PHP 5.4-ig visszamenőleg. Érintettek a PHP-FPM, az Apache mod_php-val, a php-cgi, a FrankenPHP és a LiteSpeed üzemmódok. A PHP-csapat a legnagyobb kockázatot a mod_php esetében látja, ahol már azelőtt bemutattak egy exploitot, hogy az alkalmazáskód egyáltalán futna.

A disztribúciók és a tárhelyszolgáltatók részben backportokat telepítenek. Ilyenkor például a Plesk továbbra is 8.2.34-et jelez, noha a szerver javítva van. Mérvadó a csomag állapota és a szolgáltató igazolása, nem a kijelzett verziószám. Hogyan ellenőrizheti ezt szabályosan, azt a A PHP-verzió és a javítási állapot helyes ellenőrzése oldal írja le.

Október 23.: közlemény a CVE-2026-115560-ról

2026. 10. 23-án a PHP-projekt újabb közleményt tett közzé, ezúttal a CVE-2026-115560-ról. Eszerint a kihasználás csak szokatlan konfigurációnál lehetséges: a konfigurációban a serialize_handler értéke php_binary vagy php_serialize, az alkalmazás a session_start() előtt ini_set()-tel php-ra állítja át, és a session upload progress aktív.

A megoldás egyszerű, és attól függetlenül be kell állítani, hogy ismeri-e ezt a konstellációt a saját környezetében:

; a php.ini-ben, az FPM-poolban vagy a szerverkonfigurációban
; nem ini_set()-tel vagy .user.ini-ben
session.upload_progress.enabled = 0

Ezután indítsa újra az összes PHP-workert. A teljes advisory a következő rendes hibajavító kiadással fog megjelenni. Addig ez a beállítás az ajánlott átmeneti megoldás.

Október 25-i állapot: helyzet és nyitott kérdések

A BSI (a német Szövetségi Információbiztonsági Hivatal) 3. riasztási szintet (narancs) hirdetett. Azonnali frissítést javasol, és ha ez nem lehetséges azonnal, a webszerverek átmeneti lekapcsolását a hálózatról. A BSI gyors, nagy léptékű kihasználással számolt; széles körben megerősített sikeres támadásokról a BSI szerint kezdetben nem volt tudomás. A BSI értékelését a Mit javasol a BSI a PHP2Shell kapcsán oldal foglalja össze.

A Cloudflare megfigyelt támadási kísérletekről számolt be, és védelmi szabályokat vezetett be, de arra figyelmeztet, hogy a pusztán a kéréseket vizsgáló szabályok nem elegendők. A Palo Alto Networks (Unit 42) több mint 22,6 millió kitett, potenciálisan sebezhető példányt számolt össze. Megerősített Indicators of Compromise nincsenek közzétéve; a felismerés viselkedéselemzésen alapul.

Egyes szolgáltatók elővigyázatosságból offline állapotba helyezték weboldalaikat. Ez nem jelenti automatikusan, hogy ezeket az oldalakat feltörték. Ennek az áttekintésnek az állapota szerint főként az nyitott, hogy a javítás előtti időben ténylegesen hány szervert törtek fel.

Mit jelent az idővonal a naplóira és a vizsgálataira nézve

Az adatokból három időszak adódik: 10. 17. előtt, 10. 17. és a saját javítási és újraindítási időpontja között, valamint ezután. A középső időszak a kritikus. Minél tovább tartott Önnél, annál alaposabbnak kell lennie a vizsgálatnak.

Egyszerű módja annak, hogy a naplókat változatlanul lementse, és rögzítse az állapotot:

# Naplók együttes mentése (az útvonalakat igazítsa a saját rendszeréhez)
sudo tar czf /root/logs-sicherung-$(date +%F).tar.gz /var/log/apache2 /var/log/nginx /var/log/php*
# Ellenőrző összeg a későbbi igazoláshoz
sha256sum /root/logs-sicherung-*.tar.gz
# Mennyi ideig őrzi meg a rendszer a naplókat?
grep -R "rotate" /etc/logrotate.d/

Jegyezze fel azt is, hogy pontosan mikor telepítette a frissítést, és mikor indította újra a PHP-folyamatokat. Az új fájlok önmagukban nem védenek, amíg a régi folyamatok a memóriában futnak. Hogyan értékelheti ki a lementett naplókat, azt a Webszerver-naplók kiértékelése egy támadás után útmutató írja le.

Hogyan segít konkrétan a PHP SOS?

• Önnel együtt meghatározzuk a szervere tényleges sebezhetőségi ablakát: csomagállapot, javítás időpontja, az összes worker újraindítása.
• Követhető módon lementjük a naplókat és a rendszerállapotot, mielőtt bármit megváltoztatnánk.
• Viselkedési anomáliákat keresünk, például új PHP-fájlokat, idegen folyamatokat és szokatlan kimenő kapcsolatokat.
• Az eredményt úgy dokumentáljuk, hogy a vezetőség, az adatvédelmi felelősök és a biztosítók dolgozni tudjanak vele.

Az egyes lépéseket a PHP2Shell azonnali segítség oldalunk írja le.

Gyakori kérdések

Források

• php.net: biztonsági közlemények
• PHP 8 ChangeLog
• BSI: Bundesamt für Sicherheit in der Informationstechnik (a német Szövetségi Információbiztonsági Hivatal)
• TechTarget: PHP2Shell, 22M exposed servers at risk