Kritikus cPanel biztonsági frissítés megjelent – CVE-2026-67401
Frissítés – 2026. szeptember 8.
Megjelent a CVE-2026-67401 javítása
A cPanel megerősítette, hogy a CVE-2026-67401 egy kritikus SQL injection sérülékenység a cPanel & WHM EmailTrack funkciójában.
A gyártó szerint egy levelezésre jogosult cPanel-fiók speciálisan kialakított bemenettel root tulajdonú fájl létrehozását idézheti elő a szerver tetszőleges elérési útján. A kihasználáshoz nincs szükség root hozzáférésre, és a sérülékenység veszélyeztetheti a szerver integritását.
A cPanel közlése szerint jelenleg nincs tudomásuk aktív kihasználásról. A részletes exploit-információk továbbra is korlátozottak, ezért a frissítést sürgősen javasolják.
Minimum javított verziók
- cPanel 110: 11.110.0.143 vagy újabb
- cPanel 134: 11.134.0.55 vagy újabb
- cPanel 136: 11.136.0.39 vagy újabb
- cPanel 138: 11.138.0.4 vagy újabb
- wp138: 11.138.1.9 vagy újabb
Az azonnali frissítéshez root jogosultsággal:
/scripts/upcp --forceA frissítés után ellenőrizni kell, hogy a szerver az adott ághoz tartozó minimum javított buildet vagy annál újabbat futtatja.
A cPanel előzetes biztonsági értesítést küldött üzemeltetőinek egy 2026. szeptember 8-án várható kritikus cPanel & WHM biztonsági frissítésről. A javítás a TSR-2026-09-08 biztonsági kiadás részeként érkezik.
English version: Critical cPanel security update coming September 8, 2026
A sérülékenység technikai részleteit egyelőre szándékosan nem hozták nyilvánosságra. Az előzetes tájékoztatás alapján a hibát a cPanel saját belső biztonsági felülvizsgálata során azonosították, és a vállalat jelenleg nem tud arról, hogy azt aktívan kihasználnák.
A pontosan érintett cPanel & WHM verziókat, a minimum javított buildszámokat és a technikai részleteket csak a biztonsági frissítés kiadásakor teszik közzé.
A kiadás pontos időpontja egyelőre nem ismert
A cPanel a dátumot, 2026. szeptember 8-át már közölte, pontos megjelenési időpontot azonban nem adott meg.
Ez üzemeltetési szempontból fontos részlet. Jelenleg tehát nem lehet biztosan tudni, hogy a javítás magyar idő szerint reggel, délután vagy este válik elérhetővé.
A cPanel azt ígéri, hogy a patch publikálásakor újabb értesítést küld, amely már tartalmazza az érintett verziókat, a javított buildszámokat és a szükséges helyreállítási, illetve frissítési lépéseket.
Mit tudunk jelenleg a sérülékenységről?
Az előzetes tájékoztatás szándékosan kevés technikai információt tartalmaz.
Ami jelenleg biztosan tudható: a cPanel & WHM terméket érintő sérülékenységet kritikus súlyosságúnak minősítették. A hibát belső security review során fedezték fel. A cPanel közlése szerint jelenleg nincs tudomásuk aktív kihasználásról.
A teljes érintett verziótartomány még nem nyilvános, így jelenleg nem lenne szakmailag helyes találgatni sem a támadás módjáról, sem arról, hogy szükséges-e hozzá hitelesített cPanel-fiók, távoli hozzáférés vagy valamilyen speciális szerverkonfiguráció.
CVE-azonosítót sem közöltek még.
Ezek várhatóan a TSR-2026-09-08 megjelenése után derülnek ki.
Az automatikus frissítés most különösen fontos
A cPanel előzetes értesítése szerint az automatikus napi frissítésre konfigurált támogatott rendszerek automatikusan megkapják a javított buildet.
Érdemes azonban már a kiadás előtt ellenőrizni, hogy egy szerver valóban képes-e automatikusan fogadni a biztonsági frissítéseket.
Az egyik első ellenőrizendő fájl:
cat /etc/cpupdate.confEgy megfelelően konfigurált rendszerben például az alábbi beállítások szerepelhetnek:
CPANEL=release
RPMUP=daily
SECURITY_UPDATES=hourly
UPDATES=dailyA SECURITY_UPDATES=hourly beállítás különösen fontos, mert lehetővé teszi, hogy a rendszer óránként ellenőrizze az aktuális főverzióhoz kiadott security frissítéseket.
Ez egy kritikus sérülékenységnél jelentősen lerövidítheti a javítás megjelenése és a telepítés közötti időt.
Érdemes a cron feladatokat is ellenőrizni
Nem elég kizárólag a konfigurációs fájlt megnézni.
A cPanel biztonsági ellenőrzése külön cron feladatból is futtatható:
/usr/local/cpanel/scripts/upcp --securityA root crontabban például így ellenőrizhető:
crontab -l | grep -Ei 'upcp|cpanel'Fontos az is, hogy maga a cron szolgáltatás működjön:
systemctl is-active crondEgy kritikus security release megjelenése nem ideális időpont arra, hogy akkor derüljön ki: a szerver valójában nem végzi el megfelelően az automatikus frissítéseket.
Ellenőrizzük a tényleges cPanel verziót
A telepített cPanel & WHM verzió egyszerűen lekérdezhető:
/usr/local/cpanel/cpanel -VA kiválasztott update tier és az elérhető verzió szintén ellenőrizhető a WHM API segítségével:
/usr/local/cpanel/bin/whmapi1 --output=jsonpretty get_update_availabilityAz API többek között a következő adatokat mutatja:
current_version
newest_version
tier
update_availableEz azért hasznos, mert nemcsak azt látjuk, milyen verzió fut a gépen, hanem azt is, hogy az adott release tieren elérhető-e újabb build.
Az általunk ellenőrzött CloudLinux 8 alapú cPanel rendszereken 2026. szeptember 7-én a RELEASE tier aktuális verziója 136.0.38 volt.
Az EOL rendszerek különösen fontosak
A cPanel előzetes értesítésében külön felhívta a figyelmet az End of Life verziókra.
Ha egy szerver már nem támogatott cPanel & WHM verziót futtat, előfordulhat, hogy arra nem készül javítás. Ilyen esetben először támogatott verzióra kell frissíteni.
Ez kritikus sérülékenységnél különösen fontos, mert egy EOL rendszer akkor is sérülékeny maradhat, ha egyébként az automatikus frissítési mechanizmus működik.
A pontos támogatott verziók a TSR-2026-09-08 kiadásakor válnak ismertté.
Nemcsak a cPanel verzióját érdemes ellenőrizni
Egy biztonsági frissítés telepítésének sikere nem kizárólag a cPanel konfigurációján múlik.
Érdemes ellenőrizni a szabad tárhelyet:
df -h /usr /var /home /tmpvalamint a csomagkezelés állapotát:
yum checkCloudLinux rendszereken a kernel- és LVE-modulok állapotának vizsgálata is indokolt lehet:
rpm -qa | grep '^kmod-lve' | sortEgy saját, a TSR-2026-09-08 kiadására történő előkészítés során két CloudLinux 8 kiszolgálónkon is több régi kmod-lve csomagot találtunk az aktuális verzió mellett.
Az egyik rendszeren például:
kmod-lve-2.0-49.el8.x86_64
kmod-lve-2.0-50.el8.x86_64
kmod-lve-2.1-61.1.el8.x86_64volt egyszerre telepítve.
Egy korábbi cPanel frissítési naplóban már megjelent az ehhez kapcsolódó csomagfüggőségi probléma:
Problem: package kmod-lve requires
kernel(oops_in_progress),
but none of the providers can be installedA régi, redundáns kmod-lve csomagok ellenőrzött eltávolítása után csak az aktuális verzió maradt a rendszeren, a yum check pedig hibamentesen futott le.
A kmod-lve eltávolítása közben a dnf látszólag megállhat
A régi kernelmodul-csomagok eltávolításakor érdekes jelenséggel is találkoztunk.
A dnf több percig ennél a pontnál maradt:
Running scriptlet: kmod-lveElső ránézésre úgy tűnhetett, hogy a folyamat beragadt.
Egy második SSH kapcsolatból azonban látható volt, hogy a háttérben valójában kernelmodul-karbantartás zajlik:
dnf
└─ rpm scriptlet
└─ weak-modules --remove-modules
└─ dracutA dracut sorban újraépítette az érintett kernelek initramfs állományait, majd a folyamatban depmod is futott.
Ez fontos gyakorlati tapasztalat: ilyen helyzetben nem célszerű Ctrl-C-vel vagy kill -9 paranccsal megszakítani az RPM tranzakciót csak azért, mert néhány percig nem jelenik meg új sor a terminálban.
A folyamat végül szabályosan:
Complete!állapottal zárult.
KernelCare mellett nem feltétlenül kell azonnal rebootolni
Az ellenőrzött szervereken KernelCare is működött.
Emiatt a fizikailag futó kernel és a KernelCare által biztosított effektív kernelverzió eltérhet.
Ez egyszerűen ellenőrizhető:
uname -r
kcarectl --unameAz egyik rendszerünkön például:
uname -r
4.18.0-553.111.1.lve.el8.x86_64miközben:
kcarectl --uname
4.18.0-553.141.2.lve.el8volt az effektív KernelCare állapot.
Ez lehetővé tette, hogy az előkészítő csomagtakarítást elvégezzük anélkül, hogy egy nem tervezett esti kernel upgrade-et és rebootot kellett volna végrehajtani.
A teljes kernel-frissítést külön karbantartási ablakra lehet hagyni.
Egy frissítés akkor hasznos, ha telepíthető is
A kritikus sérülékenységeknél általában mindenki a patch megjelenését várja.
Üzemeltetői szempontból azonban legalább ennyire fontos, hogy amikor a javítás valóban elérhetővé válik, ne akkor kelljen elkezdeni hibás package dependency-ket, betelt fájlrendszereket vagy nem működő update cronokat javítani.
Az utolsó cPanel frissítés naplója egyszerűen ellenőrizhető:
tail -100 /var/cpanel/updatelogs/lastA korábbi naplók pedig a:
/var/cpanel/updatelogs/könyvtárban találhatók.
Egy kritikus patch megjelenése előtt érdemes ezekben is ellenőrizni, hogy az utóbbi frissítések valóban sikeresen zárultak-e.
Mi történik szeptember 8-án?
A következő lépés a TSR-2026-09-08 tényleges publikálása lesz.
Amikor a javítás megjelenik, elsősorban az alábbi információkat kell azonnal ellenőrizni:
- a sérülékenység CVE-azonosítóját;
- a pontosan érintett cPanel & WHM verziókat;
- a támadás feltételeit;
- szükséges-e hozzá hitelesítés;
- milyen jogosultság szerezhető sikeres kihasználással;
- a minimum biztonságos buildszámokat;
- szükséges-e külön manuális beavatkozás;
- rendelkezésre áll-e kompromittáltság-ellenőrző eljárás;
- és ismert-e már aktív kihasználás.
Ezekről az információkról a TSR-2026-09-08 publikálását követően külön technikai elemzésben számolunk be.
Most van idő felkészülni
A jelenlegi helyzet kedvezőbb annál, mint amikor egy kritikus sérülékenység és a hozzá tartozó javítás előzetes figyelmeztetés nélkül válik nyilvánossá.
Most legalább egy nappal előre tudható, hogy kritikus cPanel & WHM security release érkezik.
A sérülékenység részletei még nem ismertek, ezért jelenleg nem a találgatás a feladat.
A helyes előkészület az, hogy ellenőrizzük a cPanel verziót, a release tiert, az automatikus security update-et, a cron működését, a csomagkezelő állapotát, a rendelkezésre álló tárhelyet, a kernelmodulokat és az utolsó frissítések naplóit.
Így amikor a TSR-2026-09-08 megjelenik, már csak egy lényegi kérdés marad:
a szerver megkapta-e a javított buildet?
English version: Critical cPanel security update coming September 8, 2026