• Nginx 1.31 släpps med forward proxy-stöd och flera säkerhetsfixar

    Nginx är en av internets viktigaste byggstenar. Den används för att leverera webbsidor, fördela trafik mellan servrar och fungera som mellanhand mellan användare och webbapplikationer. Med Nginx 1.31 tar projektet ett nytt steg: webbservern får stöd för HTTP forward proxy, samtidigt som flera säkerhetshål i moderna webbprotokoll som HTTP/2 och HTTP/3 täpps till.

    För de flesta internetanvändare är Nginx osynligt. Ändå är det ofta just Nginx som står mellan webbläsaren och den webbplats man besöker. Programmet fungerar som en effektiv trafikdirigent: det tar emot förfrågningar, skickar dem vidare till rätt server och ser till att svaren kommer tillbaka snabbt.

    Nginx har länge varit känt som webbserver och reverse proxy. En reverse proxy står framför en eller flera servrar och tar emot trafik från internet. Den kan till exempel skicka besökare vidare till rätt webbserver, avlasta systemet eller hantera krypterade HTTPS-anslutningar.

    Med Nginx 1.31 introduceras en funktion som gör att programmet även kan användas på ett annat sätt: som HTTP forward proxy.

    Vad är en forward proxy?

    En forward proxy fungerar från andra hållet jämfört med en reverse proxy. I stället för att skydda och styra trafiken in till en webbplats används den av klienter som vill nå ut till internet.

    Man kan likna det vid en reception. I stället för att varje dator kontaktar webben direkt skickar den sin begäran till proxyn. Proxyn gör sedan själva kontakten med omvärlden och skickar tillbaka svaret.

    Detta kan användas för att:

    samla internettrafik via en central punkt
    kräva inloggning innan trafik släpps vidare
    logga eller styra åtkomst
    skapa kontrollerade miljöer för företag, skolor eller labb

    Den nya modulen ngx_http_tunnel_module gör det möjligt för Nginx att hantera sådan trafik via CONNECT-metoden. CONNECT används ofta när HTTPS-trafik ska tunnlas genom en proxy.

    Det betyder att Nginx nu får en mer flexibel roll. Från att främst ha varit en servernära komponent kan den även användas som kontrollerad mellanhand för klienttrafik.

    Inloggning till proxyn

    En viktig del av den nya funktionen är stöd för proxyautentisering. Det innebär att användaren kan behöva logga in innan proxyn tillåter trafik.

    I Nginx 1.31 kan detta göras med direktiv som:

    auth_basic
    satisfy
    auth_delay

    För en administratör betyder det att forward proxy-funktionen inte behöver vara helt öppen. Det är viktigt, eftersom en öppen proxy snabbt kan missbrukas för anonym trafik, spam, attacker eller kringgående av nätverksregler.

    Med autentisering kan proxyn i stället användas i mer kontrollerade miljöer där bara godkända användare får tillgång.

    Smartare lastbalansering med least_time

    En annan nyhet i Nginx 1.31 är direktivet least_time i upstream-blocket. Det låter Nginx välja backend-server baserat på svarstid.

    Traditionell lastbalansering kan exempelvis bygga på att skicka varannan förfrågan till server A och varannan till server B. Det fungerar i enkla miljöer, men tar inte alltid hänsyn till hur servrarna faktiskt mår.

    Om en server är långsam, hårt belastad eller har problem kan svarstiden bli högre. Med least_time kan Nginx i stället väga in hur snabbt servrarna svarar och styra trafiken mot den som för tillfället verkar mest effektiv.

    Det är lite som att välja kö i mataffären. Man går inte nödvändigtvis till den kö som ser kortast ut, utan till den som faktiskt rör sig snabbast.

    Funktionen kan användas både för vanlig HTTP-trafik och för stream-trafik.

    ALPN för säkra upstream-anslutningar

    För stream-modulerna introduceras även direktivet proxy_ssl_alpn.

    ALPN står för Application-Layer Protocol Negotiation. Det är en teknik som används under TLS-anslutningar för att komma överens om vilket protokoll som ska användas.

    Det kan exempelvis vara relevant när en server kan tala flera olika protokoll över samma krypterade anslutning. Med proxy_ssl_alpn får administratören bättre kontroll över vilket protokoll Nginx ska välja när den ansluter till SSL-baserade upstream-servrar.

    Säkerhetsfixar i flera moduler

    Nginx 1.31 är inte bara en funktionsrelease. Den innehåller också flera säkerhetsfixar.

    En av de åtgärdade bristerna är CVE-2026-42926, en sårbarhet i HTTP/2-hanteringen i ngx_http_proxy_module. Problemet är kopplat till direktivet proxy_set_body och kan beskrivas som en request injection-sårbarhet.

    En sådan sårbarhet innebär att en angripare i vissa situationer kan påverka hur en förfrågan tolkas eller vidarebefordras. I proxyprogramvara är detta särskilt känsligt, eftersom proxyn står mitt i trafikflödet.

    En annan viktig fix gäller CVE-2026-42945, en heap buffer overflow i ngx_http_rewrite_module. Minnesfel av detta slag kan i värsta fall leda till att angripare får möjlighet att köra kod.

    Även följande sårbarheter har åtgärdats:

    CVE-2026-42946 – heap buffer overread i ngx_http_scgi_module och ngx_http_uwsgi_module
    CVE-2026-42934 – buffer overread kopplad till UTF-8-avkodning i charset_map i ngx_http_charset_module
    CVE-2026-40460 – adressförfalskning i HTTP/3 och QUIC connection migration
    CVE-2026-40701 – use-after-free vid DNS-svarshantering när ssl_ocsp används

    Det tekniska språket kan låta avskräckande, men i praktiken handlar det om samma grundproblem som ofta förekommer i systemprogramvara: data måste tolkas exakt rätt, minne måste hanteras korrekt och nätverkstrafik får inte kunna lura servern att göra något oväntat.

    HTTP/2 och HTTP/3 blir striktare

    HTTP/2 och HTTP/3 är modernare versioner av webbens grundprotokoll. De är byggda för högre prestanda och bättre hantering av många samtidiga anslutningar.

    Men när gamla och nya protokoll möts uppstår ibland risker. Vissa headers som används i HTTP/1.1 hör inte hemma i HTTP/2 och HTTP/3. Om de ändå släpps igenom kan det skapa oväntade beteenden i kedjan mellan klient, proxy och backend-server.

    Därför avvisar Nginx 1.31 nu HTTP/2- och HTTP/3-förfrågningar som innehåller anslutningsspecifika headers som:

    Connection
    Proxy-Connection
    Keep-Alive
    Transfer-Encoding
    Upgrade

    Headern TE tillåts bara när den är satt till trailers.

    Detta gör hanteringen mer strikt och minskar risken för felaktig tolkning av trafik.

    WebDAV får hårdare kontroller

    Även WebDAV-modulen har förstärkts. WebDAV gör det möjligt att hantera filer på en server via HTTP, till exempel kopiera, flytta eller ändra resurser.

    I Nginx 1.31 avvisas nu COPY– och MOVE-förfrågningar om källan och destinationen är samma plats, eller om de har ett förälder–barn-förhållande.

    Det kan låta som en liten detalj, men den typen av kontroller är viktiga. Utan dem kan filoperationer skapa logiska konflikter, oändliga kopieringsproblem eller andra oönskade effekter.

    Mindre brus i loggarna

    Versionen innehåller också mindre förändringar som påverkar drift och felsökning. Bland annat har loggnivån sänkts för vissa SSL-relaterade fel.

    För systemadministratörer kan detta vara välkommet. Alla fel är inte lika allvarliga, och för höga loggnivåer kan göra det svårare att hitta verkligt viktiga problem i stora loggfiler.

    Det finns även ett nytt configure-alternativ för att kunna inaktivera upstream sticky-modulen, samt fixar för HTTP/2 backend keepalive när proxy_set_body eller proxy_pass_request_body används.

    Varför är Nginx 1.31 viktig?

    Nginx 1.31 är intressant därför att den både breddar vad Nginx kan göra och stärker säkerheten i befintliga funktioner.

    Forward proxy-stödet gör att Nginx kan användas i fler nätverksroller än tidigare. Samtidigt visar säkerhetsfixarna hur komplex modern webbtrafik har blivit. HTTP/2, HTTP/3, TLS, OCSP, QUIC, WebDAV och olika proxyfunktioner skapar tillsammans ett kraftfullt men avancerat ekosystem.

    Ju fler lager som finns i trafikkedjan, desto viktigare blir det att varje del tolkar data på rätt sätt.

    Sammanfattning

    Nginx 1.31 är en viktig mainline-version för administratörer och tekniskt intresserade. Den stora nyheten är stödet för HTTP forward proxy via ngx_http_tunnel_module, men minst lika viktigt är de många säkerhetsfixarna i HTTP/2, HTTP/3, OCSP och flera centrala moduler.

    För den som driver Nginx i produktion är detta en version att granska noggrant. Särskilt gäller det installationer som använder avancerad proxyhantering, HTTP/2, HTTP/3, WebDAV, SCGI, uWSGI eller OCSP.

    Nginx fortsätter därmed att utvecklas från en snabb webbserver till ett allt mer mångsidigt verktyg för modern internettrafik.

    https://github.com/nginx/nginx/releases/tag/release-1.31.0

    Teknisk faktaruta: Nginx 1.31

    Version: Nginx 1.31

    Utgåva: Mainline-release

    Största nyheten: HTTP forward proxy-stöd via ngx_http_tunnel_module och CONNECT-metoden.

    Proxyautentisering: Stöd via auth_basic, satisfy och auth_delay.

    Lastbalansering: Nytt least_time-direktiv för att balansera trafik baserat på svarstid.

    Stream-moduler: Nytt proxy_ssl_alpn-direktiv för ALPN-val mot SSL-upstreams.

    Säkerhetsfixar: Åtgärdar sårbarheter i HTTP/2, HTTP/3, OCSP, WebDAV, rewrite-, proxy-, charset-, SCGI- och uWSGI-moduler.

    Berörda CVE:er: CVE-2026-42926, CVE-2026-42945, CVE-2026-42946, CVE-2026-42934, CVE-2026-40460 och CVE-2026-40701.

    Rekommendation: Administratörer som använder Nginx med HTTP/2, HTTP/3, OCSP, WebDAV eller avancerade proxyfunktioner bör granska uppdateringen noggrant.

  • Nödbroms i Linuxkärnan ska kunna stoppa farliga funktioner

    När allvarliga säkerhetshål i Linuxkärnan blir offentliga kan tiden fram till en färdig uppdatering vara kritisk. Nu diskuteras ett nytt förslag om en så kallad killswitch, en nödbroms som tillfälligt kan stänga av sårbara funktioner i kärnan. Målet är inte att laga felet direkt, utan att minska risken för angrepp medan administratörer väntar på en riktig säkerhetsuppdatering.

    Linuxkärnan är hjärtat i cirka 10 miljarder datorer, servrar, mobiler och inbyggda system. När en allvarlig sårbarhet upptäcks i kärnan kan konsekvenserna därför bli stora. Nu diskuterar Linuxutvecklare ett nytt förslag som skulle kunna ge systemadministratörer en slags nödbroms: en möjlighet att tillfälligt stänga av en sårbar funktion innan en riktig säkerhetsuppdatering finns på plats.

    Bakgrunden är flera färska CVE-rapporter om allvarliga säkerhetsbrister i Linuxkärnan. När en sårbarhet blir offentlig kan angripare snabbt börja undersöka hur den kan utnyttjas. Samtidigt kan det ta tid innan färdiga säkerhetsuppdateringar har nått alla distributioner, servrar och användare. Det är just detta mellanläge som den föreslagna funktionen försöker hantera.

    Så fungerar den föreslagna killswitchen

    Förslaget kommer från Sasha Levin, ingenjör på NVIDIA och en av de ansvariga för stabila Linuxkärnor. Hans patch går ut på att administratörer ska kunna peka ut en viss kernel-funktion och säga åt systemet att inte längre köra den.

    I stället för att funktionen körs som vanligt ska den direkt avbrytas och returnera ett fel. Det lagar inte själva säkerhetshålet, men det kan göra att angriparen inte längre når den farliga kodvägen.

    Man kan jämföra det med att stänga av en trasig hiss i ett hus. Hissen är fortfarande trasig, men ingen kan använda den förrän reparatören har varit där. På samma sätt kan en känslig del av Linuxkärnan göras otillgänglig tills en riktig säkerhetsuppdatering finns installerad.

    Inte en ersättning för säkerhetsuppdateringar

    Det är viktigt att förstå att detta inte är livepatching. Vid livepatching ersätts eller korrigeras kod i ett körande system. Den här killswitchen gör något enklare och grövre: den blockerar en utvald funktion från att köras.

    Det betyder att en riktig kerneluppdatering fortfarande behövs. Killswitchen är tänkt som en tillfällig skyddsåtgärd, inte som en permanent lösning.

    För servrar och kritiska system kan detta ändå vara värdefullt. Alla miljöer kan inte startas om direkt, och alla distributioner får inte färdiga säkerhetspaket samtidigt. Under tiden kan en administratör vilja minska risken genom att stänga av just den funktion som är kopplad till sårbarheten.

    Exempel: AF_ALG och andra sällan använda delar

    I patchen nämns bland annat AF_ALG, ksmbd, nf_tables, vsock och ax25 som exempel på kodvägar där en sådan metod kan vara användbar.

    Alla dessa funktioner används inte på varje Linuxsystem. En vanlig webbserver kanske inte behöver vissa nätverks- eller kryptorelaterade gränssnitt. Om en allvarlig sårbarhet upptäcks där kan det därför vara rimligare att tillfälligt stänga av funktionen än att låta systemet vara oskyddat.

    Ett konkret exempel i förslaget är en självtest som hänvisar till CVE-2026-31431. Testet visar hur killswitchen skulle kunna blockera den berörda AF_ALG-vägen. En annan sårbarhet, Dirty Frag, används inte som direkt testfall, men den visar samma typ av problem: ibland blir allvarliga kernelbuggar kända innan skyddet har hunnit nå ut till alla användare.

    Styrs via securityfs

    Den föreslagna funktionen ska exponeras via Linuxkärnans securityfs-gränssnitt. Det innebär att en privilegierad administratör kan aktivera en killswitch för en viss funktion under körning.

    När den väl är aktiverad börjar funktionen omedelbart misslyckas i stället för att köras. Ändringen gäller tills den stängs av igen eller tills systemet startas om.

    Det gör funktionen snabb att använda i ett nödläge. Administratören behöver inte nödvändigtvis kompilera om kärnan eller starta om maskinen bara för att blockera den berörda kodvägen.

    En kraftfull men riskabel metod

    Samtidigt är detta inget verktyg för ovana användare. Linuxkärnan är komplex, och många funktioner används indirekt av andra delar av systemet. Om fel funktion stängs av kan program sluta fungera, nätverkstjänster brytas eller systemet bete sig oväntat.

    Förslaget innehåller inte heller någon automatisk kontroll som avgör om det är säkert att stänga av en viss funktion. Det är upp till administratören att förstå vad funktionen gör och vilka konsekvenser det får att blockera den.

    Detta gör killswitchen till ett verktyg för akuta säkerhetslägen, särskilt i servermiljöer där administratörer redan har god kunskap om systemets användning.

    Varför förslaget är intressant

    Det mest intressanta med förslaget är att det försöker lösa ett praktiskt problem i säkerhetsarbetet: tiden mellan avslöjad sårbarhet och installerad uppdatering.

    När en sårbarhet väl är offentlig börjar klockan ticka. Angripare kan läsa tekniska detaljer, analysera patchar och försöka skapa fungerande angrepp. Samtidigt kan stora organisationer behöva testa uppdateringar innan de rullas ut brett.

    En enkel nödbroms skulle kunna ge administratörer ett extra handlingsalternativ. I stället för att välja mellan att vänta eller att uppdatera omedelbart kan de tillfälligt blockera den mest utsatta funktionen.

    Än så länge bara ett förslag

    Killswitchen är ännu inte en del av Linuxkärnan. Patchen granskas fortfarande av utvecklare, och det är inte säkert att den accepteras i sin nuvarande form.

    Om funktionen någon gång införs kan den bli ett viktigt verktyg för säkerhetsansvariga. Men den kommer sannolikt att användas med försiktighet. Att stänga av delar av kärnan är en kraftfull åtgärd, men också en som kräver god förståelse för systemet.

    I grunden handlar förslaget om att ge administratörer mer kontroll i ett kritiskt ögonblick. När en allvarlig sårbarhet redan är känd, men den färdiga uppdateringen ännu inte är installerad, kan även en tillfällig spärr vara skillnaden mellan ett öppet säkerhetshål och ett betydligt svårare angrepp.

    https://lore.kernel.org/all/20260507070547.2268452-1-sashal@kernel.org

    Teknisk fakta: föreslagen killswitch i Linuxkärnan

    Typ av funktion:
    Tillfällig säkerhetsåtgärd för Linuxkärnan.

    Syfte:
    Att kunna blockera en sårbar kernel-funktion efter att en allvarlig sårbarhet blivit offentlig, men innan en färdig säkerhetsuppdatering har installerats.

    Föreslagen av:
    Sasha Levin, ingenjör på NVIDIA och medansvarig för stabila Linuxkärnor.

    Så fungerar det:
    En administratör kan aktivera en spärr för en viss kernel-funktion. När funktionen anropas körs den inte vidare, utan returnerar ett fel direkt.

    Styrs via:
    Linuxkärnans securityfs-gränssnitt.

    Exempel på berörda områden:
    AF_ALG, ksmbd, nf_tables, vsock och ax25.

    Inte samma sak som:
    Livepatching. Funktionen ersätter inte sårbar kod med korrigerad kod, utan stoppar bara den utpekade funktionen från att köras.

    Risker:
    Om fel funktion stängs av kan systemfunktioner sluta fungera eller ge oväntade fel. Förslaget innehåller inga automatiska säkerhetskontroller som avgör om en funktion är trygg att blockera.

    Status:
    Förslaget är under granskning och är ännu inte accepterat i Linuxkärnan.

    Slutsats:
    Killswitchen är tänkt som en nödbroms för erfarna administratörer, inte som en ersättning för riktiga kerneluppdateringar.

  • Dirty Frag: ny Linux-sårbarhet kan ge lokal användare root-behörighet

    Dirty Frag är en ny sårbarhet i Linux-kärnan som kan låta en lokal användare eller process höja sina rättigheter till root. Problemet berör bland annat IPsec ESP/XFRM och RxRPC och är särskilt allvarligt på servrar, containerplattformar, CI/CD-runners och andra system där obetrodd kod kan köras. Eftersom publik exempelkod finns tillgänglig bör administratörer uppdatera kärnan och starta om berörda system så snart säkerhetsfixar finns i den egna distributionen.

    Kort efter att sårbarheten Copy Fail blev känd har ännu ett allvarligt Linux-problem dykt upp. Den nya sårbarheten kallas Dirty Frag och berör Linux-kärnan, alltså den centrala delen av operativsystemet som styr hårdvara, minne, nätverk och processer.

    Dirty Frag är ingen fjärrsårbarhet. Det betyder att en angripare inte kan utnyttja den direkt över internet utan att först ha någon form av lokal åtkomst till systemet. Men på servrar, containermiljöer, CI/CD-system och delade Linux-maskiner kan det ändå vara mycket allvarligt. En vanlig användare, en komprometterad container eller ett byggjobb i en CI-miljö kan i värsta fall höja sina rättigheter och få root-behörighet.

    Vad är Dirty Frag?

    Dirty Frag är en lokal privilegieeskaleringssårbarhet i Linux-kärnan. Den består egentligen av två närliggande problem:

    CVE-2026-43284 berör Linux-kärnans hantering av IPsec ESP/XFRM.

    CVE-2026-43500 berör RxRPC, ett protokoll som bland annat används tillsammans med AFS, Andrew File System.

    Gemensamt för problemen är att de handlar om hur Linux hanterar sidor i minnet via page cache. Page cache används för att snabba upp åtkomst till filer och data genom att hålla information i minnet. När kärnan hanterar buffertar på fel sätt kan data som egentligen inte ska kunna ändras ändå påverkas.

    Det är därför Dirty Frag jämförs med tidigare sårbarheter som Dirty Pipe och Copy Fail. Alla dessa hör hemma i samma bredare familj av problem där felaktig minnes- eller cachehantering kan ge en angripare möjlighet att skriva till data på ett sätt som inte borde vara möjligt.

    Varför är detta farligt?

    På en vanlig hemdator är risken främst aktuell om någon redan kan köra kod lokalt på datorn. På servrar är situationen annorlunda.

    Dirty Frag är särskilt allvarlig i miljöer där många användare, tjänster eller containrar delar samma Linux-kärna. Det gäller till exempel:

    • webbhotell
    • fleranvändarservrar
    • containerhostar
    • Kubernetes-noder
    • CI/CD-runners
    • byggservrar
    • system där externa eller mindre betrodda jobb får köras

    I sådana miljöer kan en användare eller process som egentligen ska vara begränsad till en låg behörighetsnivå försöka ta sig upp till root. Root är Linux-världens administratörskonto och har i praktiken full kontroll över systemet.

    Liknar Copy Fail, men är inte samma sak

    Dirty Frag påminner om Copy Fail genom att båda kan leda till lokal root-åtkomst. Men de utnyttjar inte samma kodvägar i kärnan.

    Copy Fail påverkade Linux-kärnans kryptodelar via algif_aead.

    Dirty Frag berör i stället nätverksrelaterade delar av kärnan, framför allt IPsec ESP/XFRM och RxRPC.

    Det gör att Dirty Frag är en separat sårbarhet, även om den tekniskt ligger nära samma typ av page-cache-problem som Copy Fail.

    IPsec, ESP och RxRPC – vad betyder det?

    IPsec är en teknik för att skydda nätverkstrafik, ofta i samband med VPN-lösningar. ESP står för Encapsulating Security Payload och är en del av IPsec som används för att kryptera och skydda datapaket.

    RxRPC är ett protokoll som bland annat används av AFS, ett distribuerat filsystem. Det är inte lika vanligt i vanliga skrivbordsmiljöer, men kan finnas i vissa server- och institutionsmiljöer.

    Problemet uppstår när Linux-kärnan hanterar vissa nätverkspaket och sidbaserade buffertar på ett sätt som gör att data kan ändras på plats, trots att bufferten inte borde betraktas som privat för just den operationen.

    Förenklat uttryckt: kärnan tror att den får skriva direkt i ett minnesområde, men minnesområdet kan i själva verket delas eller vara kopplat till annan data. Det kan öppna för manipulation av page cache och i förlängningen privilegieeskalering.

    Kan Dirty Frag användas för container escape?

    Den primära effekten är lokal privilegieeskalering på den sårbara värden. Men i containermiljöer kan problemet bli extra känsligt.

    Eftersom containrar delar kärna med värdsystemet kan en sårbarhet i kärnan ibland användas för att bryta sig ut ur containern. Canonical har pekat på att Dirty Frag är relevant i miljöer där containrar kör obetrodda arbetslaster. Det finns dock ingen offentlig container-escape-demonstration som bevisar ett sådant scenario.

    Trots det bör containerhostar, Kubernetes-noder och CI-system behandla Dirty Frag som en högprioriterad säkerhetsfråga.

    Vilka system påverkas?

    Dirty Frag berör flera stora Linuxdistributioner och serverplattformar. Bland de system som uppges vara påverkade finns bland annat Ubuntu, Debian, Red Hat Enterprise Linux, AlmaLinux, openSUSE, SUSE och OpenShift.

    Även moderna kärnversioner påverkas, inklusive Linux 7.0 före de korrigerade versionerna. Patchar har börjat dyka upp i nya kärnversioner och i distributionernas egna säkerhetsuppdateringar, men tillgången varierar mellan olika distributioner och versioner.

    För administratörer innebär det att man inte bara ska titta på den generella Linux-kärnans versionsnummer, utan också följa den egna distributionens säkerhetsråd. Distributioner bakportar ofta säkerhetsfixar till äldre kärnor utan att byta till en helt ny huvudversion.

    Så skyddar man sig

    Den rekommenderade lösningen är att installera en uppdaterad kärna från den egna distributionen och sedan starta om systemet. En kärnuppdatering börjar normalt inte skydda systemet fullt ut förrän maskinen faktiskt har startats om med den nya kärnan.

    Tillfälliga skyddsåtgärder kan vara att blockera de berörda modulerna om de inte används:

    Därefter kan initramfs behöva byggas om:

    Om modulerna redan är laddade kan de i vissa fall tas bort med:

    Men detta ska göras med försiktighet. Om systemet använder IPsec, strongSwan, Libreswan, AFS, RxRPC eller liknande funktioner kan blockeringen störa nätverk, VPN-anslutningar eller filsystem.

    Tillfällig åtgärd är inte samma sak som patch

    Att svartlista moduler kan minska attackytan, men det är ingen fullgod ersättning för en riktig säkerhetsuppdatering. Dessutom måste alla berörda delar hanteras. Om bara en av de sårbara komponenterna blockeras kan den andra fortfarande vara exploaterbar.

    Därför bör svartlistning främst ses som en tillfällig åtgärd för system där funktionerna inte används. Den långsiktiga lösningen är alltid att installera en korrigerad kärna.

    Viktigast för systemadministratörer

    Dirty Frag visar ännu en gång varför kärnuppdateringar är kritiska på Linuxsystem. Även om Linux har ett starkt säkerhetsrykte är kärnan mycket komplex, och små fel i minneshantering, nätverkskod eller cachelogik kan få stora konsekvenser.

    För vanliga användare är rådet enkelt: installera säkerhetsuppdateringar när de blir tillgängliga och starta om datorn.

    För administratörer är rådet mer brådskande: kontrollera vilka system som kör sårbara kärnor, prioritera servrar med flera användare eller obetrodda arbetslaster, uppdatera kärnan, starta om och använd tillfälliga mitigeringar där det är lämpligt.

    Dirty Frag är inte en fjärrattack, men i moderna Linuxmiljöer där containrar, automatiserade jobb och delade resurser är vanliga kan en lokal sårbarhet snabbt bli ett allvarligt hot.

    https://nvd.nist.gov/vuln/detail/CVE-2026-43284

    Teknisk faktaruta: Dirty Frag

    Namn: Dirty Frag

    Typ: Lokal privilegieeskalering i Linux-kärnan

    Risk: En lokal användare, container eller process kan i vissa fall höja sina rättigheter till root.

    Berörda områden: IPsec ESP/XFRM och RxRPC

    CVE-nummer: CVE-2026-43284 och CVE-2026-43500

    Påverkan: Servrar, containerhostar, Kubernetes-noder, CI/CD-runners och delade Linuxsystem är särskilt utsatta.

    Inte fjärrkörning: Dirty Frag kräver lokal kodkörning och är inte en direkt fjärrattack över internet.

    Rekommenderad åtgärd: Installera uppdaterad Linux-kärna från den egna distributionen och starta om systemet.

    Tillfällig mitigering: Blockera modulerna esp4, esp6 och rxrpc om de inte används.

    Varning: Att blockera dessa moduler kan påverka IPsec VPN, strongSwan, Libreswan, AFS och andra nätverksfunktioner.

  • X.Org lever vidare – och får nya säkerhetsfixar 2026

    X.Org må vara en veteran i Linuxvärlden, men tekniken lever fortfarande vidare i kulisserna. Nu har projektet täppt till fem nya säkerhetsbrister, vilket visar att den gamla grafikstacken ännu spelar en viktig roll, inte minst genom XWayland i moderna Wayland-baserade system.

    Trots att mycket av utvecklingen på Linux-skrivbordet i dag kretsar kring Wayland är X.Org ännu inte historia. Tvärtom visar de senaste säkerhetsuppdateringarna att den gamla grafikstacken fortfarande underhålls, åtminstone när det gäller att täppa till allvarliga sårbarheter.

    I den nya utgåvan av X.Org Server 21.1.22 och XWayland 24.1.10 har utvecklarna rättat fem nyupptäckta säkerhetsbrister. Det handlar om flera typer av minnesfel, bland annat integer underflow, läsningar utanför tillåtna minnesområden, use-after-free och buffertöverskridning. Sådana fel är särskilt viktiga att åtgärda eftersom de i värsta fall kan leda till krascher, instabilitet eller att skadlig kod kan utnyttja systemet.

    Det som gör nyheten extra intressant är att X.Org ofta beskrivs som en gammal teknik på väg bort. På många moderna Linuxsystem är det numera Wayland som står i centrum. Ändå fortsätter X.Org att spela en viktig roll, framför allt genom XWayland, som fungerar som ett kompatibilitetslager för äldre X11-program. Det betyder att även användare som i praktiken kör Wayland fortfarande kan påverkas av sårbarheter i kod som har sitt ursprung i X.Org-världen.

    De fem säkerhetsbristerna som nu har täppts till visar också något större om dagens Linuxekosystem: gamla system försvinner sällan över en natt. I stället lever de kvar som underliggande komponenter, bibliotek eller kompatibilitetslager långt efter att en ny teknik tagit över rampljuset. X.Org må inte längre vara framtiden, men det är fortfarande en del av nutiden.

    Utöver säkerhetsfixarna innehåller den nya versionen också ett antal stabilitets- och kvalitetsförbättringar. Flera utvecklare har bidragit med rättningar som förbättrar felhantering, minneshantering, byggsystem och drivrutinsstöd. Det handlar alltså inte bara om akuta säkerhetsproblem, utan också om det löpande underhåll som krävs för att hålla gammal, komplex kod användbar.

    Sammantaget visar uppdateringen att X.Org fortfarande hålls vid liv, inte genom nya stora funktioner utan genom nödvändigt underhåll. Det säger mycket om hur teknikhistoria fungerar i praktiken. Även när något anses vara på väg ut kan det fortsätta vara avgörande i många år, särskilt när annan modern teknik fortfarande lutar sig mot det för bakåtkompatibilitet.

    Att X.Org får säkerhetsfixar även 2026 är därför inte bara en teknisk detalj. Det är också en påminnelse om att digital infrastruktur ofta är byggd i lager, där även äldre delar måste skyddas och underhållas. Framtiden må heta Wayland, men X.Org är ännu inte helt borta från scenen.

    https://lists.x.org/archives/xorg-announce/2026-April/003678.html

    FAKTARUTA // X.ORG 2026

    Versioner: X.Org Server 21.1.22, XWayland 24.1.10

    Nya säkerhetsfixar: 5

    CVE: 33999, 34000, 34001, 34002, 34003

    Problemtyper: minnesfel, bounds-fel, use-after-free, buffertöverskridning

    Betydelse: påverkar inte bara rena X.Org-system utan även Wayland-system som använder XWayland

    Läget: X.Org utvecklas inte längre med fokus på nya funktioner, men hålls vid liv genom säkerhets- och stabilitetsuppdateringar



Etikett: cve

  • Nginx 1.31 släpps med forward proxy-stöd och flera säkerhetsfixar

    Nginx är en av internets viktigaste byggstenar. Den används för att leverera webbsidor, fördela trafik mellan servrar och fungera som mellanhand mellan användare och webbapplikationer. Med Nginx 1.31 tar projektet ett nytt steg: webbservern får stöd för HTTP forward proxy, samtidigt som flera säkerhetshål i moderna webbprotokoll som HTTP/2 och HTTP/3 täpps till. För de…

  • Nödbroms i Linuxkärnan ska kunna stoppa farliga funktioner

    När allvarliga säkerhetshål i Linuxkärnan blir offentliga kan tiden fram till en färdig uppdatering vara kritisk. Nu diskuteras ett nytt förslag om en så kallad killswitch, en nödbroms som tillfälligt kan stänga av sårbara funktioner i kärnan. Målet är inte att laga felet direkt, utan att minska risken för angrepp medan administratörer väntar på en…

  • Dirty Frag: ny Linux-sårbarhet kan ge lokal användare root-behörighet

    Dirty Frag är en ny sårbarhet i Linux-kärnan som kan låta en lokal användare eller process höja sina rättigheter till root. Problemet berör bland annat IPsec ESP/XFRM och RxRPC och är särskilt allvarligt på servrar, containerplattformar, CI/CD-runners och andra system där obetrodd kod kan köras. Eftersom publik exempelkod finns tillgänglig bör administratörer uppdatera kärnan och…

  • X.Org lever vidare – och får nya säkerhetsfixar 2026

    X.Org må vara en veteran i Linuxvärlden, men tekniken lever fortfarande vidare i kulisserna. Nu har projektet täppt till fem nya säkerhetsbrister, vilket visar att den gamla grafikstacken ännu spelar en viktig roll, inte minst genom XWayland i moderna Wayland-baserade system. Trots att mycket av utvecklingen på Linux-skrivbordet i dag kretsar kring Wayland är X.Org…