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

A Nemzeti Kiberbiztonsági Intézet 2026. szeptember 23-i riasztása a CVE-2026-94127 jelű, aktívan kihasznált kritikus BIG-IP APM-hibára figyelmeztet, és a 17.1.0–17.1.3, a 17.5.0–17.5.1, valamint a 21.1.0 kiadást sorolja fel érintettként. Az érintett virtuális szerveren APM-hozzáférési házirendnek és OAuth-profilnak is lennie kell; ilyen beállítás mellett a heapalapú puffertúlcsordulás hitelesítés nélküli távoli kódfuttatást tehet lehetővé.

A kihasználás már megkezdődött, ezért a javítás előtti aktivitás felderítése is számít. Az üzemeltetőnek a kitettség eldöntéséhez a telepített modulnál többet kell tudnia: a konkrét OAuth-szerepkört, a virtuális szerverhez rendelt profilokat és a futó kiadást együtt kell megállapítania.

Melyik BIG-IP APM-konfiguráció érintett?

A döntést virtuális szerverenként érdemes meghozni, mert az APM telepítése vagy egy OAuth-funkció használata önmagában nem írja le a tényleges támadási felületet. Az engedélyezési kiszolgáló szerepében a rendszer az OAuth-engedélyezési folyamatot szolgálja ki; az OAuth Client és a Resource Server eltérő szerepkör. A hiba szempontjából a kéréseket fogadó virtuális szerver beállítása fontos: ott találkozik a hozzáférési házirend az OAuth-profillal, ezért egy eszközön belül is eltérhet az egyes szolgáltatások kitettsége. A közölt feltétel szerint a kizárólag e két utóbbi szerepben működő, Authorization Server-profilt nem használó telepítés kívül esik ezen a sérülékeny körön.

1. Van APM-hozzáférési házirend a virtuális szerveren? Ha nincs, a leírt konfigurációs feltétel itt nem teljesül. Más virtuális szerverek beállítását ettől még külön kell megítélni.
2. Ugyanezen a virtuális szerveren van OAuth-profil, és az APM Authorization Serverként működik? Ha csak OAuth Client vagy Resource Server szerepet lát el, Authorization Server-profil nélkül, a közölt sérülékenység nem érinti ezt a konfigurációt. Ha a két feltétel együtt fennáll, a kiadást kell ellenőrizni.
3. Érintett kiadás fut javítás nélkül? Ilyenkor a hotfix telepítése és a korábbi forgalom vizsgálata egyaránt sürgős. Egy másik, már javított példány állapota nem ad választ erre a virtuális szerverre.

A riasztásban felsorolt kiadások a szoftverágat szűrik; a tényleges kitettséget az előbbi házirend és OAuth-profil együttes jelenléte, valamint a javítás állapota határozza meg. Ezért a nyilvántartásban egy verziószám mellé az adott virtuális szerver szerepkörét is oda kell tenni.

A hotfix az adott verzióághoz tartozik

A kanadai kiberbiztonsági központ 2026. szeptember 22-i közleménye az F5 által jelzett aktív kihasználás mellett a CISA aznapi KEV-felvételét és a három mérnöki hotfixet is közli: Hotfix-BIGIP-17.1.3.5.0.41.14-ENG, Hotfix-BIGIP-17.5.1.9.0.160.12-ENG, Hotfix-BIGIP-21.1.0.2.0.30.22-ENG. Az azonosítókban szereplő kiadásszám és a futó rendszer verziója együtt jelöli ki a megfelelő csomagot; egy másik ághoz tartozó hotfix nem helyettesíti azt. A telepített csomag nevét ezért ugyanúgy érdemes rögzíteni, mint az alapverziót.

Ha a javítás telepítése késik, az átmeneti kockázatcsökkentésnek a sérülékeny virtuális szerverre kell vonatkoznia. Az érintett szolgáltatás hozzáférési útvonalát és a változtatási ablakot külön kell megtervezni. A közölt feltétel miatt az APM egészére alkalmazott általános besorolás nem mutatja meg, melyik virtuális szerver fogadja a sérülékeny OAuth-forgalmat.

Mit kell megőrizni és keresni a javítás előtt?

Az aktív kihasználás miatt egy sikeres hotfixtelepítés nem zárja le a korábbi állapot vizsgálatát. A vizsgálathoz még a módosítás előtt érdemes megőrizni az érintett időszak APM- és auditnaplóit, az OAuth-statisztikákat, valamint az esetleges TMM-magfájlokat. A virtuális szerver változtatás előtti konfigurációját is célszerű elmenteni, hogy az utólagos elemzés a naplókat a ténylegesen hozzárendelt házirendhez és OAuth-profilhoz köthesse. Így a későbbi elemzés össze tudja kötni az OAuth-kérések időpontját a készüléken történt további eseményekkel, és nem csak a javítás utáni állapot látszik.

A CERT-EU vizsgálati útmutatója a /var/log/apm napló 01990004:3 azonosítójú invalid_token hibájánál különösen a rövid időn belül egy IP-címhez köthető legalább tíz előfordulást emeli ki, továbbá a total_failed számláló megmagyarázatlan emelkedését, a /var/log/audit gyanús parancsait és a TMM-magfájlokat is vizsgálati jelként kezeli. Ugyanez az útmutató az F5 ügyfélszolgálatától kérhető, iRule-alapú átmeneti védelmet is említi arra az esetre, ha a hotfix azonnali telepítése nem lehetséges. A naplóesemények száma vizsgálati támpont, önmagában nem bizonyítja, hogy a támadó kódot futtatott.

A jelek időbeli kapcsolata többet mond, mint bármelyik külön: az ismétlődő OAuth-hitelesítési hibák után megjelenő gyanús parancsok, majd egy TMM-leállás emberi elemzést indokolnak. A TMM-magfájl önmagában nem bizonyít kihasználást, de megőrzendő, mert a naplókkal összevetve segíthet tisztázni a történteket. A vizsgálatot az érintett virtuális szerver javítás előtti időszakára kell kiterjeszteni; a megfigyelt jelek esetén incidenskezelési eljárás szükséges.

A vizsgálat kimenetele a további teendőket is módosítja. Gyanús naplósorozat esetén a változtatás időpontját, a megőrzött bizonyítékokat és a gyanús parancsokat egy incidens idővonalán kell összerendezni; így dönthető el, hogy a javítás mellett helyreállításra és az érintett hozzáférések felülvizsgálatára is szükség van-e.

Olvassa el ezt is:

• n8n vagy Make: az önálló üzemeltetés ára nem csak a szerverdíj
• RAG vagy finomhangolás: a változó tudást nem érdemes a modellbe égetni
• MCP vagy function calling? A csere nem mindig egyszerűsítés