
A PHP2Shell miatt leállt a magyarorszag.hu, de már támadási kísérleteket látnak

A PHP2Shell miatt elővigyázatosságból leállított magyarorszag.hu 2026. október 22-én 15:15-kor újraindult a kormány tájékoztatása szerint. A Tudományos és Technológiai Minisztérium nem talált kibertámadásra utaló jelet. A korlátozás idején a portálon keresztüli ügyintézés szünetelt, és néhány más kormányzati weboldal elérését is korlátozták.
A Nemzeti Kiberbiztonsági Intézet október 22-i összefoglalója szerint a PHP javításai október 21-én megjelentek, miközben fenyegetettségi megfigyelők már kihasználási kísérletekről számoltak be. A megfigyelt támadási aktivitás és a magyar portál állapota külön kérdés: a közölt kísérletek önmagukban nem jelentenek sikeres behatolást a magyarorszag.hu rendszerébe. Az üzemeltetők számára ezért a telepített javítás és a helyi naplók ellenőrzése egyaránt fontos.
Mi történt a leállás és az újraindítás között?
A PHP sérülékenységeiről szerdán jelent meg a biztonsági riasztás és a javított kiadások. A kormányzati portált szerdáról csütörtökre virradó éjjel kapcsolták le, hogy az érintett szolgáltatásoknál elvégezhessék a szükséges biztonsági intézkedéseket. A csütörtök délutáni újraindítás azt jelenti, hogy a magyarorszag.hu esetében az elővigyázatossági kiesés ugyanazon a napon véget ért; a többi korlátozott felület állapotát ebből nem lehet megállapítani.
A döntés az állampolgári adatok védelmét szolgálta, és az ügyintézési felület elérhetőségét érintette közvetlenül. Aki a leállás idején próbált ügyet intézni, a portált átmenetileg nem használhatta. A visszakapcsolásról szóló közlés a magyarorszag.hu működésének helyreállítását rögzíti, de nem ad külön újraindítási időpontot minden érintett kormányzati oldalra. Az egyes szolgáltatások állapotát ezért a saját üzemeltetőjük közlése alapján lehet megítélni.
A Semmelweis Egyetemen az érintett oldalak fokozatosan térnek vissza
A Semmelweis Egyetem informatikai tájékoztatása szerint a PHP2Shell sérülékenységben érintett weboldalakat leállítják, majd a frissítés után fokozatosan kapcsolják vissza. Addig egyes webes szolgáltatásokban fennakadások lehetnek. Az egyetemi közlés nem sorolja fel az érintett oldalakat, így a kormányzati portál helyreállásából az egyetemi felületek pillanatnyi elérhetősége sem következik.
Ez a két intézményi helyzet más időzítést mutat. A magyarorszag.hu újraindításáról konkrét időpontot közöltek, az egyetemnél viszont az érintett weboldalak frissítéséhez kötött, fokozatos visszaállás szerepel. Az egyetem tájékoztatása weboldalakról és egyes szolgáltatások fennakadásáról szól; nem állítja, hogy minden egyetemi felület vagy a betegellátás leállt volna. Egy állami portál elérhetősége tehát nem jelzi automatikusan más magyar intézmények szolgáltatásainak állapotát.
Mely PHP-verziók kapták meg a javítást?
A PHP2Shell név két, CVE-2026-109618 és CVE-2026-109619 azonosítójú sérülékenységet fog össze. Mindkettő 9,2-es CVSS-pontszámú, és hitelesítés nélküli távoli kódfuttatást tehet lehetővé. A hibák a PHP futtatókörnyezetében vannak: egy tartalomkezelő vagy webalkalmazás saját frissítése önmagában nem bizonyítja, hogy a kiszolgáló PHP-ja is javított. A vizsgálatnak a ténylegesen webes kéréseket kezelő példányra kell kiterjednie.
Az első javított kiadások az egyes támogatott ágakban a következők:
- PHP 8.2: 8.2.35.
- PHP 8.3: 8.3.36.
- PHP 8.4: 8.4.27.
- PHP 8.5: 8.5.12.
A PHP 8.1-es és régebbi ágaihoz a projekt már nem ad ki szokásos új verziót. Egy Linux-disztribúció vagy hosszú támogatást nyújtó szolgáltató ugyanakkor a javítást régebbi verziószámú csomagba is beépítheti. Ilyen környezetben a rövid PHP-verzió önmagában félrevezető lehet: a teljes telepített csomagverziót, a csomag forrását és a szolgáltató mindkét hibára vonatkozó javítási közleményét kell összevetni. A telepítést követően a futó PHP-folyamatok újraindítása is szükséges lehet, különben a régi kód maradhat memóriában.
Mi csökkenti a kitettséget, és milyen jelekre kell figyelni?
A végleges intézkedés a javított PHP telepítése minden érintett, internet felől elérhető rendszerben. Ahol ez még nem történt meg, az érintett szolgáltatás külső elérésének korlátozása vagy ideiglenes leállítása csökkenti a kitettséget. A konfigurációs módosítások és a webalkalmazás-tűzfal szabályai átmeneti mérséklések; nem helyettesítik a javítást. A leállítás különösen indokolt lehet ott, ahol a használt PHP-csomag javítottsága egyelőre nem igazolható.
Az ellenőrzés nem állhat meg a nyilvános főoldalnál. A régi adminisztrációs felületek, a külön futó webhelyek, a konténerek és a külső termékekbe épített PHP-példányok eltérő csomagot használhatnak. A parancssorból lekérdezett verzió sem feltétlenül ugyanaz, mint amelyik a webes kéréseket kiszolgálja. A tényleges futtatókörnyezet, a javított csomag telepítése és az újraindított folyamatok együtt adnak érdemi választ arra, hogy egy felület visszakapcsolható-e.
A naplókban a szokatlanul ismétlődő webes kérések, a szerverhibák halmozódása és a PHP-munkafolyamatok váratlan leállása vizsgálatot indokolhat. Erősebb figyelmeztető jel, ha webkiszolgálói folyamatból parancsértelmező indul, vagy a szerver nem várt külső kapcsolatot kezdeményez. Egyetlen hibaüzenet vagy sikertelen kérés nem bizonyít behatolást: az időpontot, a forráscímet, az érintett folyamatot és a többi naplóbejegyzést együtt kell értékelni. A javítás után észlelt rendellenesség külön incidensvizsgálatot igényelhet, mert a frissítés a korábban történt esetleges hozzáférést nem vizsgálja ki.
Olvassa el ezt is:
Kapcsolódó cikkek


OpenAI-ágensek adatoldalakat támadtak – több kísérlet elbukott

A mentőszervert bányagéppé teszik – az Ahsay korábbi javítása sem elég

Az MI felgyorsítja a támadásokat, de egy 2020-as hiba viszi a találatok 58%-át

Az F5 kritikus hibáját már kihasználják, de nem minden APM-beállítás érintett

4 millió eurót kapott a Fleuret – a pentestből folyamatos szolgáltatás lesz
Iratkozzon fel hírlevelünkre
A legfrissebb Web3-, MI- és kriptohírek egyenesen a postafiókjába.