Aktiv exploatering och kritisk påverkan
CISA lade den 22 september 2026 till CVE-2026-94127 i katalogen Known Exploited Vulnerabilities. F5 har samtidigt bekräftat exploatering i verkliga angrepp. Sårbarheten finns i BIG-IP Access Policy Manager, APM, och har CVSS 3.1: 9,8 av 10, Critical. En angripare behöver varken konto eller användarinteraktion för att försöka utnyttja felet.
LabOps IT klassificerar åtgärden som Akut. BIG-IP APM placeras ofta i en central och internetnära roll för fjärråtkomst, autentisering och publicering av interna tjänster. Fjärrkodskörning på en sådan gateway kan ge åtkomst till känslig trafik, autentiseringsflöden och angränsande system. CISA anger den 25 september som åtgärdsdatum för berörda amerikanska federala verksamheter, vilket understryker den korta riskhorisonten.
Den sårbara konfigurationen
Felet är en heapbaserad buffertöverskrivning, CWE-122. Det påverkar virtuella servrar där både en APM access policy och en OAuth-profil är konfigurerade. Särskilt utformad trafik kan då utlösa minnesfelet och leda till körning av godtycklig kod på enheten. CERT-EU beskriver konsekvensen som oautentiserad RCE och möjlig full systemkompromettering.
Alla BIG-IP-installationer är alltså inte automatiskt sårbara. Inventeringen måste koppla programversion till faktisk konfiguration. Kontrollera vilka virtuella servrar som använder APM, vilka som har OAuth-profil och om de är exponerade mot internet eller andra mindre betrodda nät. Att en miljö inte använder OAuth för vanlig inloggning är inte tillräckligt bevis; granska den aktiva konfigurationen.
Berörda versioner och rätt hotfix
De verifierade berörda grenarna är BIG-IP APM 17.1, 17.5 och 21.1. F5 distribuerar korrigeringen som engineering hotfix, och exakt paket måste matcha den installerade grenen.
| Produktgren | Berörd nivå | Korrigerad hotfix | |---|---|---| | BIG-IP APM 17.1 | 17.1.0 till och med 17.1.3 före hotfix | Hotfix-BIGIP-17.1.3.5.0.41.14-ENG | | BIG-IP APM 17.5 | 17.5.0 till och med 17.5.1 före hotfix | Hotfix-BIGIP-17.5.1.9.0.160.12-ENG | | BIG-IP APM 21.1 | 21.1.0 före hotfix | Hotfix-BIGIP-21.1.0.2.0.30.22-ENG |
Hämta paketet via F5:s officiella supportkanal och följ leverantörens instruktioner för den aktuella plattformen och HA-topologin. Installera inte en hotfix avsedd för en annan gren. Säkerställ dessutom att supporten bekräftar om senare kumulativa versioner redan innehåller korrigeringen innan ni väljer målversion.
Gör detta i rätt ordning
Börja med att bevara forensiska spår. Samla loggar, konfigurationsbackup, versionsinformation, kärnfiler och relevanta tidsstämplar innan en omstart eller uppgradering förändrar tillståndet. Dokumentera vilken virtuell server som exponerats och från vilka nät den varit nåbar.
Inventera därefter alla BIG-IP-system centralt och lokalt. Identifiera APM-modulen, version, installerade hotfixar, OAuth-profiler och kopplade access policies. Prioritera internetexponerade noder och aktiva HA-medlemmar, men kontrollera även standby-enheter eftersom de kan bli aktiva vid fel eller under underhåll.
Installera sedan rätt engineering hotfix. I ett HA-par bör uppgraderingen följa F5:s ordinarie procedur med validering mellan noderna. Planera för påverkan på pågående sessioner, autentisering och failover. Testa VPN, publicerade applikationer, SSO och tokenflöden efter varje steg.
Mitigering om patchning måste vänta
F5 tillhandahåller en iRule-baserad mitigering för den berörda virtuella servern. Den ska begäras från F5 Support. CISA anger att iRule kan användas tillfälligt och att den slutliga leverantörspatchen ska installeras så snart den forensiska kontrollen är genomförd.
Mitigeringen är inte ett skäl att skjuta upp uppdateringen. Begränsa samtidigt managementgränssnitt till betrodda administrationsnät, verifiera att onödiga virtuella servrar är avstängda och minska nätåtkomst till APM där verksamheten tillåter det. Ändringar i access policies eller OAuth-profiler kan påverka autentisering och måste testas, dokumenteras och kunna återställas.
Sök efter tecken på intrång
CERT-EU återger flera indikatorer från F5. Granska /var/log/apm efter upprepade OAuth-fel, särskilt tio eller fler fel från samma IP-adress under kort tid. Kontrollera även om statistiken total_failed i tmctl global_oauth_stat ökar utan legitim förklaring.
Om OAuth-fel sammanfaller med misstänkta kommandon i /var/log/audit krävs manuell incidentanalys. Undersök också TMM-kärnfiler och SIGABRT-händelser. En kärnfil ensam bevisar inte exploatering, men kombinationen av OAuth-fel, ovanliga kommandon och efterföljande TMM-avbrott är särskilt allvarlig. Granska administrativa konton, access policies, nya objekt och oväntade konfigurationsändringar.
En hotfix avlägsnar sårbarheten men rensar inte automatiskt en redan komprometterad enhet. Vid fynd ska BIG-IP isoleras enligt incidentplan, autentiseringsuppgifter och relevanta hemligheter roteras och angränsande system kontrolleras. Bedöm även om tokens, sessionsdata eller publicerade backend-tjänster kan ha exponerats.
Verifiera skyddet före återgång till normal drift
Efter teknisk uppdatering bör förändringen godkännas mot en tydlig kontrollista. Bekräfta att varje klusternod visar rätt engineering hotfix, att konfigurationssynkroniseringen är frisk och att ingen äldre nod kan ta över trafiken utan korrigeringen. Kontrollera även att iRule-mitigeringen hanteras enligt F5:s instruktioner när permanent fix är installerad; lämna inte tillfälliga regler utan dokumenterat beslut.
Spara testresultat, loggutdrag och versionsbevis tillsammans med ändringsärendet. Det ger både spårbarhet och ett tydligt underlag för incidentgruppen om senare indikatorer upptäcks. Fortsatt övervakning av OAuth-fel och administrativa ändringar bör ligga kvar under en förhöjd observationsperiod.
Driftpåverkan
Uppdateringen kan påverka fjärråtkomst, SSO och publicerade applikationer. Ett HA-par minskar avbrottet men eliminerar inte risken för sessionsbortfall eller felaktig failover. Bekräfta konfigurationssynkronisering, trafikgrupper, hälsokontroller och certifikat före underhåll. Ha en återställningsplan och en separat administrativ väg om APM-tjänsten blir otillgänglig.
Efter uppdateringen ska installerad hotfix verifieras på varje nod. Kör funktionsprov för autentisering, tokenutbyte, utloggning och åtkomst till bakomliggande tjänster. Fortsätt loggövervakningen även efter patchning eftersom tidigare exploatering kan ha lämnat kvar åtkomst eller förändringar.
LabOps IT:s bedömning
Kombinationen av CVSS 9,8, oautentiserad RCE, aktiv exploatering och en internetnära säkerhetsprodukt gör detta till en av de mest brådskande uppdateringarna just nu. Det konfigurationsberoende villkoret minskar antalet berörda system men får inte användas som antagande utan verifiering.
Prioritera bevarande av spår och snabb hotfix i samma incidentnära arbetsflöde. Organisationer som använder berörd APM- och OAuth-konfiguration bör behandla miljön som potentiellt exponerad fram till dess att loggarna granskats, hotfixen installerats och funktion samt integritet verifierats.