Súlyos Linux-kernel sérülékenységek fenyegetik a szervereket
Linux kernel biztonsági riasztás 2026 októberében: súlyos sérülékenységek, jogosultságszerzés és kernel panic
Újabb komoly biztonsági problémák a Linux rendszermagjában
2026 októberében több jelentős biztonsági sérülékenység is napvilágra került a Linux kernelben. A problémák különösen fontosak a tárhelyszolgáltatók, szerverüzemeltetők és vállalati informatikai rendszerek számára, hiszen bizonyos hibák kihasználásával egy támadó rendszergazdai jogosultságot szerezhet, érzékeny adatokat érhet el, vagy akár működésképtelenné teheti az érintett kiszolgálót.
A Linux kernel az operációs rendszer központi eleme. Ez felel a memória kezeléséért, a folyamatok ütemezéséért, a hálózati kommunikációért, a fájlrendszerek működéséért és a hardvererőforrások eléréséért. Egy kernelhibának ezért lényegesen súlyosabb következményei lehetnek, mint egy hagyományos alkalmazás sérülékenységének.
A mostani figyelmeztetések azonban nem jelentik azt, hogy minden Linux-szerver veszélyben lenne, vagy hogy világszerte tömeges kernelösszeomlások történnének. A tényleges kitettség a disztribúciótól, a kernelverziótól, a rendszer konfigurációjától és az alkalmazott biztonsági javításoktól függ.
Infinity Core: hat kernelhiba egyetlen biztonsági közleményben
2026. október 16-án az Infinity Core néven ismert sérülékenységcsoport került nyilvánosságra. A kutatók hat különálló problémát azonosítottak a Linux kernel különböző alrendszereiben.
Ezek között megtalálható a CVE-2026-98260, amely a POSIX CPU-időzítők kezeléséhez kapcsolódik, valamint a CVE-2026-98256, amely a szignálkezelésben előforduló versenyhelyzetet érinti. További hibák jelentek meg a futex mechanizmusban, a memóriakezelésben és a folyamatütemezéshez kapcsolódó komponensekben.
A sérülékenységek egy része helyi jogosultságemelést tehet lehetővé. Ez azt jelenti, hogy a támadónak először valamilyen korlátozott hozzáféréssel kell rendelkeznie az érintett rendszeren, majd ezt kihasználva magasabb jogosultsági szintet érhet el.
A CloudLinux elemzése szerint a CVE-2026-98260 különösen fontos a CloudLinux 9 és 10 rendszerek számára. A gyártó október 21-i tájékoztatásában már javított kernelcsomagokat azonosított ezekhez a rendszerekhez.
A sérülékenységcsoport kapcsán kernelösszeomlási lehetőség is felmerült, de fontos különbséget tenni az elméleti támadási lehetőség, egy laboratóriumi környezetben reprodukált összeomlás és egy ténylegesen megtörtént éles támadás között.
ZDI-CAN-33367: egy tárhelyfiókból akár teljes szerverhozzáférés
Október 22-én egy másik, tárhelyszolgáltatói szempontból különösen veszélyes Linux-kernel sérülékenység került a figyelem középpontjába.
A ZDI-CAN-33367 azonosítójú hiba a Linux hálózati alrendszerében található. A probléma következtében bizonyos feltételek mellett egy helyi felhasználó olyan fájlok tartalmát is módosíthatja, amelyekhez normál esetben csak olvasási jogosultsága lenne.
A sérülékenység azért jelent komoly kockázatot, mert a módosítási lehetőség végül rendszergazdai, vagyis root jogosultság megszerzéséhez vezethet.
Egy megosztott tárhelyszerveren ez különösen érzékeny helyzetet teremt. Elképzelhető például, hogy egy támadó először egy elavult WordPress-bővítményen keresztül kompromittál egy weboldalt. Ezzel még csak az adott tárhely felhasználójának jogosultságait szerzi meg.
Ha azonban az operációs rendszer kernelje is sérülékeny, a támadás következő lépése már a teljes szerver feletti ellenőrzés megszerzése lehet.
Ez veszélyeztetheti az ugyanazon a fizikai vagy virtuális kiszolgálón működő többi ügyfél adatait és szolgáltatásait is.
A CloudLinux tájékoztatása szerint a sérülékenység kihasználhatósága jelentősen függ attól, hogy a nem privilegizált felhasználók létrehozhatnak-e saját Linux-névtereket. A user.max_user_namespaces rendszerparaméter emiatt kulcsszerepet játszik a kitettség megítélésében.
A hiba javítása CloudLinux 9 rendszereken a 5.14.0-687.60.1.el9_8 kernelverziótól érhető el. A CloudLinux 8 esetében külön javított kernelág és eltérő kiadási ütemezés érvényes.
Újabb TCP-hiba: CVE-2026-98432
Október végén további figyelmeztetés jelent meg a CVE-2026-98432 sérülékenységről.
Ez a probléma a Linux kernel IPv4/TCP hálózatkezelésének memóriakezelését érinti. A CloudLinux október 29-i közlése szerint a hiba CloudLinux 8, 9 és 10 rendszereken is jelen van.
A sérülékenység úgynevezett use-after-free memóriakezelési probléma, amely bizonyos körülmények között instabilitást vagy kernelösszeomlást okozhat.
A gyártó szerint a kihasználáshoz speciális, nem alapértelmezett konfiguráció szükséges, ezért a kockázat nem azonos minden szerveren.
A közlemény kiadásakor még nem állt rendelkezésre sem hagyományos kernelfrissítés, sem KernelCare élő javítás ehhez a konkrét hibához.
Ez jól mutatja, hogy a legfrissebb telepíthető kernel sem feltétlenül jelent minden ismert sérülékenységgel szemben teljes védelmet.
Mit jelent valójában a kernel panic?
A kernel panic a Linux operációs rendszer egyik legsúlyosabb hibajelensége. Akkor következik be, amikor a rendszermag olyan állapotba kerül, amelyből már nem tud biztonságosan tovább működni.
Ilyenkor a rendszer lefagyhat, megszakíthatja a szolgáltatásokat, vagy a konfigurációtól függően automatikusan újraindulhat.
Egy tárhelyszolgáltatónál ennek közvetlen következménye lehet a weboldalak, adatbázisok, DNS-szolgáltatások és levelezőrendszerek átmeneti elérhetetlensége.
Ugyanakkor fontos hangsúlyozni, hogy nem minden kernel-sérülékenység okoz kernel panic állapotot. Egyes problémák elsősorban jogosultságemelést vagy információszivárgást tesznek lehetővé, míg mások szolgáltatásmegtagadáshoz vagy rendszerösszeomláshoz vezethetnek.
A biztonsági közleményben szereplő súlyos kernelhiba tehát önmagában még nem bizonyítja, hogy egy adott szerveren tényleges összeomlás történt.
KernelCare: biztonsági javítások újraindítás nélkül
A szerverüzemeltetés egyik legnagyobb kihívása, hogy a hagyományos kernelfrissítések aktiválásához rendszerint újraindítás szükséges.
Egy otthoni számítógépnél ez néhány perc kellemetlenséget jelenthet. Egy több száz weboldalt és levelezőfiókot kiszolgáló gépnél azonban már tervezett szolgáltatáskiesést, ügyféltájékoztatást és utólagos ellenőrzéseket igényelhet.
Erre kínál megoldást a CloudLinux és a TuxCare által fejlesztett KernelCare technológia.
A KernelCare lehetővé teszi, hogy a támogatott Linux-kernel biztonsági javításait a rendszer futása közben alkalmazzák. A javítás így bizonyos esetekben teljes operációsrendszer-újraindítás nélkül aktiválható.
A technológia használatakor azonban két különböző kernelverzióval is találkozhatunk.
A uname -r parancs a rendszerindításkor betöltött kernel verzióját mutatja, míg a kcarectl --uname a KernelCare által biztosított effektív javítási szintet jelzi.
Ez a két verzió eltérhet egymástól anélkül, hogy a rendszer hibásan működne.
A ténylegesen alkalmazott javítások a kcarectl --patch-info paranccsal ellenőrizhetők. A kcarectl --update pedig a rendelkezésre álló élő javítások alkalmazását kezdeményezi.
A KernelCare ugyanakkor nem helyettesít minden hagyományos kernelfrissítést. Csak azokkal a sérülékenységekkel szemben nyújt védelmet, amelyekhez az adott kernelhez kompatibilis élő javítás már rendelkezésre áll.
Miért nem elég, ha a frissítés már telepítve van?
A Linux-rendszereken gyakori helyzet, hogy a rendszergazda telepítette az új kernelcsomagot, a szerver azonban továbbra is a régi rendszermaggal működik.
Ennek oka, hogy az új kernel alapértelmezés szerint csak a következő rendszerindításkor töltődik be.
Egy CloudLinux 9 szerveren például előfordulhat, hogy a telepített, következő indulásra kijelölt kernel 5.14.0-687.61.1.el9_8, miközben az aktuálisan futó kernel még egy korábbi kiadás.
Ilyenkor a frissítés telepítése sikeres volt, de a teljes kernelcsomag javításai még nem aktiválódtak.
A különbség ellenőrzéséhez a uname -r, az rpm -q kernel-core --last és a grubby --default-kernel parancsok használhatók.
Az ellenőrzés különösen fontos olyan rendszereknél, amelyeket hónapok óta nem indítottak újra.
A CageFS és a tűzfal önmagában nem oldja meg a kernelhibákat
A modern tárhelyszolgáltatási környezetekben több különböző biztonsági réteg működik együtt. A CloudLinux CageFS például elkülöníti a tárhelyfelhasználók fájlrendszer-környezetét, míg a tűzfalak és a webalkalmazás-tűzfalak a hálózati és alkalmazásszintű támadások ellen védenek.
Ezek rendkívül fontos eszközök, azonban nem minden kernelhibát képesek megakadályozni.
A CageFS nem jelent külön Linux-kernelt minden tárhelyfiók számára. A kiszolgálón futó felhasználók továbbra is ugyanazon rendszermagot használják.
Ha egy támadó olyan sérülékenységet talál, amely közvetlenül a közös kernel memóriakezelését vagy jogosultsági mechanizmusait érinti, a fájlrendszer elkülönítése önmagában nem feltétlenül nyújt megfelelő védelmet.
Ezért a többrétegű szerverbiztonság mellett a kernel javítási állapotának rendszeres ellenőrzése is elengedhetetlen.
Mit jelent mindez a tárhelyszolgáltatók számára?
A 2026 októberében megjelent sérülékenységek ismét bebizonyították, hogy a Linux-szerverek biztonsága nem egyetlen szoftver vagy biztonsági szolgáltatás telepítésén múlik.
A felelős üzemeltetés része a gyártói sérülékenységi közlemények figyelése, a rendszeres kernel- és csomagfrissítés, a rendelkezésre álló élő javítások ellenőrzése és a szükséges újraindítások előzetes megtervezése.
Különösen fontos a ténylegesen futó és a már telepített kernel közötti különbség ismerete. Ugyanilyen lényeges annak ellenőrzése, hogy egy adott CVE-hez valóban rendelkezésre áll-e javítás az adott Linux-disztribúcióhoz.
Az 1B Telecom álláspontja szerint az üzembiztonság és az információbiztonság nem egymással ellentétes szempontok. A megfelelően megtervezett frissítési stratégia mindkettőt szolgálja.
Ahol rendelkezésre állnak megfelelő élő kernelfoltok, ott mérsékelhető a nem tervezett újraindítások szükségessége. Ahol ilyen javítás nincs, ott a hagyományos kernelfrissítés és a kontrollált újraindítás marad a megfelelő megoldás.
A legfontosabb tanulság: nem az számít, hogy egy Linux-szerver milyen régóta működik megszakítás nélkül, hanem az, hogy a futó rendszermag milyen ismert sérülékenységekkel szemben rendelkezik tényleges védelemmel.
*Források: CloudLinux Security Advisories, CloudLinux Status, TuxCare KernelCare, Trend Micro Zero Day Initiative. A cikk a 2026. október 30-án rendelkezésre álló gyártói információkat tükrözi.*