• Rsync 3.5 släppt – rättar 33 säkerhetsproblem

    Rsync 3.5 har släppts med rättningar för 33 säkerhetsproblem, däribland en kritisk sårbarhet som kunde användas för att kringgå serverns åtkomstkontroller. Uppdateringen innehåller dessutom omfattande förstärkningar av programmets hantering av sökvägar, symboliska länkar, krypterade anslutningar och rsync-servrar.

    Rsync 3.5 har släppts med omfattande säkerhetsförbättringar. Den nya versionen rättar sammanlagt 33 säkerhetsproblem, varav ett klassas som kritiskt och flera som allvarliga.

    Rsync används för att kopiera och synkronisera filer både lokalt och mellan datorer. Programmet förekommer även i många skript, säkerhetskopieringslösningar och servermiljöer. Säkerhetsproblemen i version 3.5 är framför allt resultatet av en omfattande granskning av programmets sökvägshantering och daemonprotokoll.

    Kritisk sårbarhet i proxyprotokollet

    Den allvarligaste sårbarheten har beteckningen CVE-2026-53791 och klassas som kritisk.

    Problemet berör rsync-servrar där inställningen proxy protocol = true används. En klient som anslöt direkt till servern kunde skicka ett manipulerat PROXY-huvud och därigenom förfalska sin ursprungliga IP-adress. Detta kunde användas för att kringgå värdbaserade åtkomstregler.

    I rsync 3.5 godtas en vidarebefordrad adress endast när anslutningen kommer från en uttryckligen angiven och betrodd proxyserver.

    Som en ytterligare säkerhetsåtgärd kommer en server som har proxy protocol = true, men saknar inställningen proxy protocol hosts, nu att neka samtliga anslutningar. Rsync varnar dessutom för konfigurationsfelet när daemonen startas.

    Förstärkt skydd mot sökvägsattacker

    Många av de rättade sårbarheterna handlar om symboliska länkar och otillräckligt skyddade sökvägar. Under vissa omständigheter kunde en angripare få rsync att läsa, skriva eller radera filer utanför den avsedda katalogen.

    Rsync 3.5 inför därför en säkrare metod för att behandla sökvägar komponent för komponent. Bland annat har skyddet förbättrats för följande funktioner:

    • Filterfiler och listor som anges med exempelvis --filter och --files-from.
    • Loggfiler samt filer som används av --write-batch och --read-batch.
    • Mottagarkataloger och temporära kataloger.
    • Alternativen --partial-dir, --backup-dir och --link-dest.
    • Radering av källfiler med --remove-source-files.
    • Bevarande av ACL-rättigheter och utökade attribut.
    • Begränsade rsync-konton som använder verktyget rrsync.

    En särskilt viktig rättning gäller sökvägar som skickas av en ansluten klient. Tidigare kunde symboliska länkar i en rsync-modul under vissa förhållanden styra --partial-dir eller --backup-dir utanför modulens rotkatalog. Dessa sökvägar begränsas nu till det tillåtna området.

    Skydd mot överbelastning och minnesfel

    Version 3.5 rättar även flera problem som kunde användas för att överbelasta eller krascha en rsync-server.

    En angripare kunde bland annat skapa särskilt utformade kedjor med identiska svaga kontrollsummor och därigenom orsaka en kvadratisk ökning av processorbelastningen. Sökningen genom sådana kedjor begränsas nu.

    Andra rättningar omfattar bland annat:

    • Begränsning av antalet Zstandard-trådar som en klient kan begära från en daemon.
    • En tidsgräns för klienter som påbörjar en anslutning men sedan skickar data extremt långsamt.
    • Kontroller mot flera heltalsöverskridningar.
    • Rättningar av skrivningar utanför tilldelat minne.
    • Begränsningar för mängden data som kan skickas i proxyhuvuden och utökade filattribut.

    Standardgränsen för komprimeringstrådar i daemonläge har stärkts så att en fjärrklient inte längre kan starta hundratals trådar genom en enda anslutning.

    hosts deny misslyckas nu säkert

    En sårbarhet i hanteringen av hosts deny kunde tidigare leda till att en klient tilläts ansluta om ett värdnamn i nekandelistan inte gick att slå upp.

    Rsync 3.5 ändrar beteendet så att ett misslyckat namnuppslag i en sådan regel leder till att anslutningen nekas. Programmet använder därmed principen ”fail closed” i stället för att släppa igenom klienten.

    Även tolkningen av vissa regler under auth users har rättats. Gruppnamn som innehöll mellanslag kunde tidigare göra att en nekningsregel eller en regel för skrivskydd inte tillämpades som avsett.

    Säkrare krypterade anslutningar

    Skriptet rsync-ssl, som används för att köra rsync över en krypterad TLS-anslutning, får en viktig säkerhetsförbättring.

    När stunnel användes kontrollerade tidigare versioner inte alltid att servercertifikatet var utfärdat av en betrodd certifikatutfärdare eller att certifikatet tillhörde det begärda värdnamnet. En angripare med möjlighet att påverka nätverkstrafiken kunde därför i vissa situationer utge sig för att vara rsync-servern.

    I rsync 3.5 kräver stunnel-läget korrekt certifikatkontroll och matchning av värdnamnet. Den äldre, osäkra hanteringen kan endast aktiveras genom ett uttryckligt undantag.

    Klienten har även fått skydd mot en skadlig motpart som försöker ändra eller stänga av klientens tidsgräns för in- och utmatning.

    Filnamn kan inte längre manipulera loggar

    Kontrolltecken i filnamn kodas numera innan de skrivs till loggfiler. Det förhindrar att manipulerade filnamn används för att infoga falska loggrader eller skicka terminalkommandon när en administratör öppnar loggen.

    Utvecklarna har också stängt en möjlighet att kringgå --safe-links i kombination med säkerhetskopiering. Osäkra symboliska länkar ska därmed inte längre kunna följa med till säkerhetskopieringsområdet via en alternativ kodväg.

    Vissa ändringar kan påverka befintliga skript

    Den striktare säkerhetsmodellen medför även några beteendeförändringar.

    En mottagare som inte körs i daemonläge följer nu endast en symbolisk länk som används som målkatalog om länken ägs av root eller av den användare som kör rsync. Syftet är att förhindra att en annan lokal användare byter ut målkatalogen och styr filerna till en annan plats.

    Administratörer som använder symboliska länkar, egna proxyinställningar, rrsync eller avancerade alternativ för säkerhetskopiering bör därför testa sina befintliga skript efter uppgraderingen.

    Uppgradering rekommenderas

    På grund av antalet säkerhetsproblem och deras allvarlighetsgrad bör användare och administratörer uppgradera till rsync 3.5 så snart versionen blir tillgänglig i den aktuella Linuxdistributionens paketförråd.

    Exakt vilka äldre versioner som påverkas varierar mellan sårbarheterna. Det är därför inte korrekt att utgå från att samtliga problem berör alla tidigare rsync-versioner. Distributioner kan dessutom välja att föra tillbaka säkerhetsrättningarna till äldre paketversioner.

    Den installerade versionen kan kontrolleras med:

    rsync --version
    

    Serveradministratörer bör särskilt granska installationer där rsync körs som daemon, med höga behörigheter eller genom begränsade SSH-konton.

    Mer information finns i de officiella versionsanteckningarna för rsync 3.5.

    > TEKNISK FAKTARUTA: RSYNC 3.5
    VERSION: 3.5.0
    SLÄPPT: 13 augusti 2026
    SÄKERHETSFEL: 33
    HÖGSTA ALLVARLIGHET: Kritisk
    KRITISK SÅRBARHET: CVE-2026-53791
    BERÖR: Klient, daemon, rrsync, rsync-ssl och sökvägshantering
    root@linux:~$ rsync –version
    REKOMMENDATION: Uppgradera till rsync 3.5 eller ett distributionspaket där säkerhetsrättningarna har förts tillbaka.
  • Stor säkerhetsuppdatering för Debian 13 täpper till 68 sårbarheter

    Debianprojektet har släppt en omfattande säkerhetsuppdatering för Debian 13 ”Trixie”. Uppdateringen rättar 68 säkerhetsproblem i Linuxkärnan, däribland brister som kan orsaka systemkrascher, informationsläckor och i vissa fall ge en angripare fullständig kontroll över datorn.

    Den nya uppdateringen publicerades den 31 juli 2026 och gäller Linuxkärnan 6.12 LTS, som används i Debian 13. Alla användare rekommenderas att installera uppdateringen så snart som möjligt.

    Säkerhetsuppdateringen kommer bara tio dagar efter Debians föregående kärnuppdatering. Den gången rättades 12 sårbarheter. Den nya uppdateringen är betydligt större och omfattar totalt 68 identifierade säkerhetsproblem.

    Vad är Linuxkärnan?

    Linuxkärnan är den centrala delen av operativsystemet. Den fungerar som en länk mellan datorns programvara och dess maskinvara.

    Kärnan hanterar bland annat:

    • processor och arbetsminne
    • hårddiskar och filsystem
    • nätverksanslutningar
    • USB-enheter
    • grafikkort
    • virtuella maskiner
    • användarnas behörigheter

    Ett säkerhetsfel i kärnan kan därför få större konsekvenser än ett fel i ett vanligt program. Om en angripare lyckas utnyttja en kärnsårbarhet kan personen i värsta fall få administratörsbehörighet och ta kontroll över hela systemet.

    Många mindre fel – men några är allvarliga

    De flesta av de 68 sårbarheterna är relativt begränsade och påverkar särskilda drivrutiner, nätverksfunktioner eller filsystem. Bland problemen finns fel som kan leda till felaktig minneshantering, åtkomst utanför tillåtna minnesområden och försök att använda minne som redan har frigjorts.

    Sådana tekniska fel kan bland annat orsaka:

    • systemkrascher
    • överbelastning av datorns resurser
    • informationsläckor
    • obehörig åtkomst
    • höjda användarbehörigheter

    En sårbarhet behöver inte vara enkel att utnyttja för att vara farlig. Många säkerhetsangrepp bygger på att flera mindre brister kombineras för att kringgå systemets skydd.

    Nätverksfel kan orsaka fjärrangrepp

    En av de allvarligaste sårbarheterna är CVE-2026-64530. Problemet finns i Linuxkärnans system för trafikstyrning, som används för att kontrollera och prioritera nätverkstrafik.

    Sårbarheten är ett så kallat use-after-free-fel. Det innebär att kärnan under vissa omständigheter försöker använda ett minnesområde efter att det redan har frigjorts.

    Felet kan orsaka en fjärrutlöst överbelastningsattack, så kallad denial-of-service. Det finns dessutom en möjlig risk för att sårbarheten skulle kunna användas för att köra skadlig kod på den angripna datorn.

    Open vSwitch-fel kan ge rootbehörighet

    Ett annat allvarligt problem är CVE-2026-64531, även kallat OVSwrap. Sårbarheten finns i datapath-funktionen för Open vSwitch.

    Open vSwitch är en virtuell nätverksswitch som ofta används i servrar, molnplattformar, containermiljöer och virtualiserade system.

    En lokal användare som lyckas utnyttja sårbarheten kan höja sina behörigheter och få tillgång till systemets rootkonto. Root är den högsta behörighetsnivån i Linux och ger i praktiken fullständig kontroll över operativsystemet.

    Sårbarheten är framför allt relevant för servrar och system där flera användare, virtuella maskiner eller containrar delar samma maskin.

    Manipulerade NTFS-diskar kan krascha systemet

    Två andra sårbarheter, CVE-2026-64532 och CVE-2026-64533, finns i Linuxkärnans NTFS3-drivrutin.

    NTFS är det filsystem som normalt används av moderna Windowsinstallationer. Linux kan läsa och skriva till NTFS-formaterade hårddiskar och USB-minnen med hjälp av särskilda drivrutiner.

    Sårbarheterna kan utlösas när systemet monterar ett särskilt manipulerat NTFS-filsystem. En angripare skulle exempelvis kunna förbereda ett USB-minne eller en avbildningsfil som får datorn att krascha när innehållet öppnas.

    Felen kan även orsaka minnesskador eller läckage av information från systemets minne.

    Även lagring och virtuella maskiner påverkas

    Uppdateringen rättar också två fel i NVMe over TCP, en teknik som gör det möjligt att använda snabba NVMe-lagringsenheter över ett nätverk.

    Sårbarheterna CVE-2026-64534 och CVE-2026-64535 kan orsaka överbelastning och göra att tjänsten eller hela systemet slutar fungera.

    Dessutom rättas CVE-2026-53365, som finns i virtio-vsock. Funktionen används för kommunikation mellan en fysisk värddator och virtuella maskiner.

    En virtuell gästmaskin kan under vissa förhållanden skicka stora meddelanden utan att resurserna frigörs korrekt. Med tiden kan värddatorns resurser förbrukas, vilket kan leda till kraftigt försämrad prestanda eller systemstopp.

    Uppdatera Debian 13 så snart som möjligt

    Alla som använder Debian 13 ”Trixie” bör installera de senaste uppdateringarna. Det gäller både skrivbordsdatorer, bärbara datorer och servrar.

    Öppna en terminal och kör:

    sudo apt update
    sudo apt full-upgrade
    

    När den nya kärnan har installerats måste datorn startas om:

    sudo reboot
    

    Uppdateringen installerar Linuxkärnan 6.12.100-1.

    Efter omstarten går det att kontrollera vilken kärna som används med:

    uname -r
    

    Det är viktigt att komma ihåg att en ny kärna inte börjar användas direkt efter installationen. Den aktiveras först när datorn har startats om.

    Regelbundna uppdateringar är det viktigaste skyddet

    Det finns inga uppgifter om att alla de rättade sårbarheterna aktivt utnyttjas i omfattande attacker. När tekniska detaljer om säkerhetsfel blir offentliga ökar dock risken för att angripare utvecklar metoder för att utnyttja dem.

    Att regelbundet installera säkerhetsuppdateringar är därför ett av de enklaste och mest effektiva sätten att skydda ett Linuxsystem.

    För Debian 13-användare är rekommendationen tydlig: installera uppdateringen och starta om datorn så snart det är praktiskt möjligt.

    https://lists.debian.org/debian-security-announce/2026/msg00316.html

    root@debian:~# säkerhetsrapport

    [ SYSTEM ] Debian 13 “Trixie”

    [ KERNEL ] Linux 6.12 LTS

    [ UPPDATERAD VERSION ] 6.12.100-1

    [ PUBLICERAD ] 31 juli 2026

    [ SÅRBARHETER ] 68 rättade säkerhetsproblem

    [ RISKER ] Privilegiehöjning, informationsläckor, minnesfel och överbelastningsattacker

    [ ALLVARLIGA FEL ] CVE-2026-64530 och CVE-2026-64531

    [ PÅVERKADE OMRÅDEN ] Nätverk, Open vSwitch, NTFS3, NVMe over TCP och virtio-vsock

    sudo apt update sudo apt full-upgrade sudo reboot

    [ VARNING ] Den nya kärnan börjar användas först efter omstart.

    root@debian:~# uname -r

  • Oracle inför ny styrmodell för MySQL

    Oracle inför en ny styrmodell för MySQL som ska ge tydligare roller för bidragsgivare, tekniska ledare och strategiska beslutsforum. Målet är att öka öppenheten kring utvecklingen, stärka samarbetet med communityn och skapa fler formella vägar för externa aktörer att påverka databasens framtid. Samtidigt är MySQL fortsatt ett Oracle-lett projekt.

    Oracle inför en ny styrmodell för MySQL med tydligare roller för bidragsgivare, tekniska ledare och strategiska beslutsforum. Målet är att öka öppenheten, stärka samarbetet med communityn och skapa tydligare vägar för externa aktörer att delta i utvecklingen av databasen.

    MySQL är en av världens mest använda öppna databaser och används i allt från mindre webbprojekt till stora molntjänster och företagsmiljöer. Oracle, som äger och leder MySQL-projektet, beskriver förändringen som nästa steg i arbetet med att göra utvecklingen mer transparent och inkluderande.

    Tydligare roller för bidragsgivare

    Den nya modellen definierar flera nivåer av deltagande. Communitymedlemmar ska kunna bidra med kod, testning, dokumentation, granskningar och tekniska diskussioner.

    Mer erfarna deltagare kan få rollen som Committers, med ansvar för att granska ändringar och bidra till att hålla kvaliteten i koden. Oracle inför även Mentorer, som ska hjälpa nya bidragsgivare att komma in i projektet.

    För viktiga tekniska områden införs rollen Project Lead. Dessa personer ska ge teknisk vägledning och ansvara för långsiktig utveckling inom sina delar av MySQL, med fokus på stabilitet, prestanda och kompatibilitet.

    Teknisk styrkommitté och säkerhetsgrupp

    Styrmodellen innehåller också en Technical Steering Committee samt en särskild Vulnerability Group. Säkerhetsgruppen ska hantera rapportering av sårbarheter, säkerhetsgranskningar och ansvarsfull offentliggörelse av säkerhetsproblem.

    Det är en viktig del av modellen eftersom MySQL används i många system där säkerhet och tillförlitlighet är avgörande.

    Ny MySQL Steering Committee

    Oracle introducerar även en MySQL Steering Committee. Den ska fungera som ett forum för strategisk vägledning och bredare representation från MySQL-ekosystemet.

    Kommittén ska bidra till diskussioner om långsiktiga prioriteringar, ekosystemets utveckling, communityarbete och framtida förbättringar av styrmodellen. Oracle betonar samtidigt att kommittén inte ska ersätta den tekniska ledningen eller det dagliga utvecklingsarbetet.

    Den första versionen av kommittén kommer att bestå av Oracle, Amazon Web Services och Google Cloud. Enligt Oracle ska fler perspektiv från MySQL-användare inkluderas framöver.

    Fortsatt Oracle-kontroll

    Den nya styrmodellen innebär inte att MySQL blir ett självständigt projekt utanför Oracle. MySQL fortsätter att ledas av Oracle, och den nya styrgruppen verkar inom den struktur som Oracle har satt upp.

    Förändringen kan därför ses som ett steg mot mer organiserad communitymedverkan, snarare än en överföring av kontrollen över projektet.

    Fler öppna diskussioner och utvecklarresurser

    Oracle planerar att fortsätta bygga ut communityarbetet genom offentliga vägkartediskussioner, Contributor Summits, GitHub-samarbete, Early Access-versioner, tekniska designdiskussioner och förbättrade utvecklarresurser.

    Företaget säger också att man vill redovisa fler mätvärden kring MySQL-ekosystemets utveckling, till exempel bidragsgivartillväxt, bugghantering, deltagande i vägkartor och aktivitet i communityprogram.

    En offentlig communitydiskussion är planerad till den 15 juli, och nästa Contributor Summit hålls den 5–6 augusti i Broomfield, Colorado.

    Ett steg mot mer öppenhet

    Oracle framställer den nya styrmodellen som ett sätt att stärka MySQL-communityn och skapa tydligare processer för deltagande. För utvecklare, databasadministratörer och företag som använder MySQL kan förändringen innebära bättre insyn och fler möjligheter att påverka projektets framtid.

    Samtidigt kvarstår den centrala frågan om kontrollen. MySQL förblir ett Oracle-lett projekt, men med den nya modellen öppnas fler formella vägar för communityn och större aktörer i ekosystemet att delta i diskussionen om databasens framtida utveckling.

    https://blogs.oracle.com/mysql/the-next-phase-of-mysql-community-engagement-accelerating-participation-and-collaboration

    Teknisk faktaruta: MySQL:s nya styrmodell

    Projekt: MySQL

    Ägare och huvudansvarig: Oracle

    Typ av programvara: Öppen relationsdatabas

    Syfte med förändringen: Ökad öppenhet, tydligare roller och bättre communitymedverkan

    • Contributors: Bidrar med kod, testning, dokumentation, granskningar och tekniska diskussioner.
    • Committers: Erfarna bidragsgivare som granskar ändringar och hjälper till att hålla kodkvaliteten.
    • Mentors: Vägleder nya bidragsgivare i projektet.
    • Project Leads: Leder tekniska områden inom MySQL med fokus på stabilitet, prestanda och kompatibilitet.
    • Technical Steering Committee: Ger teknisk vägledning för projektets utveckling.
    • Vulnerability Group: Hanterar sårbarhetsrapporter, säkerhetsgranskningar och ansvarsfull publicering.
    • MySQL Steering Committee: Forum för strategiska frågor och bredare representation från ekosystemet.

    Första deltagare i styrgruppen: Oracle, Amazon Web Services och Google Cloud

    Viktigt att notera: MySQL blir inte ett självständigt projekt. Databasen fortsätter att ledas av Oracle.

  • Akrites ska hjälpa öppen källkod att hantera säkerhetshot snabbare

    När AI-verktyg gör det lättare att hitta säkerhetsbrister i öppen källkod ökar också trycket på de utvecklare som måste hantera rapporterna. Därför lanserar Linux Foundation initiativet Akrites, som ska samordna rapportering, åtgärder och offentliggörande av allvarliga sårbarheter i viktiga öppna projekt.

    Akrites ska hjälpa öppen källkod att hantera säkerhetshot snabbare

    Öppen källkod är en grundpelare i dagens digitala samhälle. Den används i allt från mobiltelefoner och molntjänster till banker, myndigheter, sjukhus och artificiell intelligens. Men när så många system bygger på samma öppna komponenter blir säkerheten också en gemensam angelägenhet.

    Linux Foundation har därför lanserat Akrites, ett nytt initiativ som ska förbättra hur allvarliga säkerhetsbrister i öppen källkod rapporteras, hanteras och åtgärdas.

    Bakom satsningen finns flera stora aktörer inom teknik, AI, finans och cybersäkerhet. Bland de medverkande finns bland annat Amazon Web Services, Anthropic, Google, Microsoft, GitHub, Red Hat, NVIDIA, OpenAI, Cisco, IBM, JPMorganChase, Rust Foundation och flera andra organisationer.

    AI hittar fler sårbarheter än tidigare

    En viktig bakgrund till Akrites är att AI-verktyg numera kan hjälpa säkerhetsforskare att hitta sårbarheter i kod mycket snabbare än förr. Det är i grunden positivt. Ju tidigare en brist upptäcks, desto snabbare kan den rättas till.

    Men den nya utvecklingen skapar också problem.

    Många projekt inom fri och öppen källkod drivs av små grupper eller enskilda frivilliga utvecklare. När de plötsligt får stora mängder säkerhetsrapporter kan det bli svårt att hinna kontrollera vilka rapporter som är riktiga, vilka som är dubbletter och vilka som faktiskt är allvarliga.

    Det räcker nämligen inte att bara hitta en sårbarhet. Den måste också bekräftas, bedömas, prioriteras, rättas i koden och ibland samordnas med flera leverantörer innan informationen blir offentlig. Om informationen sprids för tidigt kan angripare utnyttja bristen innan användarna hunnit uppdatera sina system.

    En gemensam säkerhetsgrupp

    Akrites är tänkt att fungera som ett samordnande lager mellan säkerhetsforskare, utvecklare, företag och organisationer. Initiativet ska bland annat skapa ett gemensamt Security Incident Response Team, alltså en grupp som kan hjälpa till vid allvarliga säkerhetsincidenter.

    Projektet ska också använda en standardiserad process för så kallad Coordinated Vulnerability Disclosure. Det betyder att information om sårbarheter hanteras på ett ansvarsfullt och samordnat sätt, så att utvecklare får möjlighet att rätta felet innan detaljerna sprids brett.

    Akrites ska arbeta med etablerade säkerhetsstandarder och verktyg, exempelvis CVE, CWE, CVSS, EPSS, SSVC och VEX. Dessa används för att beskriva, klassificera och prioritera säkerhetsbrister.

    Kan hjälpa övergivna projekt

    En särskilt intressant del av Akrites är att initiativet även kan fungera som en slags “sista utväg” för viktiga öppna projekt som saknar aktiva underhållare.

    Det är ett välkänt problem inom mjukvaruvärlden att många program och bibliotek fortsätter att användas långt efter att de ursprungliga utvecklarna slutat arbeta med dem. Trots det kan dessa komponenter finnas kvar i tusentals andra system.

    Om en allvarlig säkerhetsbrist upptäcks i ett sådant projekt kan det vara oklart vem som egentligen ska ta ansvar för att rätta felet. Där kan Akrites få en viktig roll.

    Upptäckt är bara första steget

    Säkerhet inom öppen källkod handlar inte bara om att hitta fel. Det handlar lika mycket om att ha fungerande rutiner för vad som händer efteråt.

    En sårbarhet måste analyseras. Hur allvarlig är den? Vilka system påverkas? Finns det redan ett angrepp i omlopp? Behöver ett CVE-nummer tilldelas? Ska informationen delas med leverantörer innan den blir offentlig?

    Det är just denna kedja som Akrites vill stärka.

    Om projektet fungerar som tänkt kan det minska mängden dubbla rapporter, förbättra samarbetet mellan utvecklare och företag samt göra att säkerhetsfixar når användarna snabbare.

    Ett viktigt steg för hela ekosystemet

    Öppen källkod bygger på samarbete. Men när mjukvaran används i samhällskritiska system krävs också tydliga strukturer för säkerhet och ansvar.

    Akrites kan därför bli ett viktigt komplement till andra säkerhetsinitiativ inom öppen källkod, till exempel OpenSSF och Alpha-Omega. Men framgången kommer inte bara att avgöras av vilka stora företag som står bakom projektet.

    Det avgörande blir om Akrites lyckas samarbeta med de människor som faktiskt underhåller den öppna koden. Om initiativet underlättar deras arbete, minskar belastningen och leder till snabbare säkerhetsuppdateringar kan det bli ett betydelsefullt steg framåt för hela den öppna mjukvaruvärlden.

    I en tid där AI både kan hjälpa till att hitta säkerhetsbrister och samtidigt öka mängden rapporter är behovet av samordning större än någonsin. Akrites är ett försök att skapa ordning i den nya verkligheten.

    https://www.linuxfoundation.org/press/linux-foundation-and-industry-leaders-launch-akrites-to-defend-critical-open-source-software-against-ai-enabled-cyber-threats

    Teknisk faktaruta: Akrites

    Namn: Akrites

    Organisation: Linux Foundation

    Syfte: Förbättra hantering, samordning och offentliggörande av säkerhetsbrister i öppen källkod.

    Fokusområde: Kritiska sårbarheter i viktiga open source-projekt.

    Bakgrund: AI-verktyg gör det möjligt att hitta fler sårbarheter snabbare, men många projekt saknar resurser för att hantera stora mängder säkerhetsrapporter.

    Arbetssätt: Samordnad sårbarhetsrapportering, verifiering, prioritering, åtgärd och ansvarsfull publicering.

    Standarder och verktyg: CVE, CWE, CVSS, EPSS, SSVC, VEX och TLP.

    Viktiga aktörer: AWS, Anthropic, Google, Microsoft, GitHub, Red Hat, NVIDIA, OpenAI, IBM, Cisco, Rust Foundation och flera andra.

    Betydelse: Akrites kan minska dubbla rapporter, förbättra samarbetet med utvecklare och göra att säkerhetsfixar når användare snabbare.

  • IBM och Red Hat satsar 5 miljarder dollar på säkerhet i öppen källkod

    IBM och Red Hat lanserar Project Lightwell, en satsning på 5 miljarder dollar för att stärka säkerheten i öppen källkod. Genom att kombinera AI-assisterad kodanalys med tusentals ingenjörer vill företagen skapa ett betrott säkerhetslager för företag som är beroende av Linux, Kubernetes, Java, AI-ramverk och andra centrala open source-komponenter.

    IBM och Red Hat lanserar Project Lightwell, ett omfattande initiativ på 5 miljarder dollar som ska stärka säkerheten i den öppna källkod som moderna företag, molnplattformar och AI-system bygger på. Projektet beskrivs som en ny typ av företagsinriktad säkerhetsplattform där AI-assisterad analys kombineras med mänsklig expertis från över 20 000 ingenjörer inom IBM och Red Hat.

    Bakgrunden är att öppen källkod i dag är en grundläggande del av nästan all modern IT-infrastruktur. Operativsystem, molntjänster, utvecklingsverktyg, databaser, AI-ramverk och containerplattformar bygger ofta på komponenter som utvecklas öppet och används av tusentals organisationer världen över. Samtidigt har hotbilden förändrats. Sårbarheter kan upptäckas snabbare än tidigare, inte minst med hjälp av AI, och angripare kan utnyttja brister i mjukvarukedjan innan många organisationer hunnit reagera.

    Project Lightwell ska fungera som ett slags betrott säkerhetslager för företag som är beroende av öppen källkod. IBM beskriver initiativet som en ”trusted enterprise clearinghouse”, alltså en samordnande plattform där sårbarheter kan identifieras, analyseras, valideras, prioriteras och åtgärdas i stor skala. Målet är inte bara att hitta säkerhetsproblem, utan också att testa och kvalitetssäkra patchar innan de används i produktionsmiljöer.

    En central del av satsningen är AI-assisterad ingenjörskonst. AI ska användas för att analysera kod, prioritera risker, hjälpa till med granskning och stödja utvecklingen av korrigeringar. Men IBM och Red Hat betonar samtidigt att arbetet inte enbart bygger på automatisering. Projektet ska backas upp av ett mycket stort team av ingenjörer som kan granska, testa och samordna arbetet med både företagskunder och öppna utvecklarprojekt.

    Project Lightwell riktar sig främst till stora företag och organisationer snarare än till den breda open source-gemenskapen. IBM planerar att erbjuda tjänsten genom kommersiella abonnemang, där kunder får tillgång till validerade säkerhetsfixar, livscykelhantering och produktionsklassad testning. För företag inom exempelvis finans, offentlig sektor, molndrift och AI-utveckling kan detta bli ett sätt att minska risken i sina beroenden av öppen källkod.

    Teknikområdet som omfattas är brett. IBM och Red Hat nämner bland annat Linux, Java, Kubernetes, Kafka, Ansible, Terraform, Flink, Cassandra, AI-ramverk, språkverktyg, oberoende bibliotek och plattformar för dataströmning. Det innebär att Project Lightwell inte bara handlar om Red Hats egna produkter, utan även om komponenter utanför bolagets traditionella produktgränser.

    Clearinghouse-modellen bygger på tre huvudsakliga funktioner. För det första ska företag kunna rapportera känsliga sårbarheter i den mjukvara de använder. För det andra ska Project Lightwell kunna erbjuda validerade patchar för både Red Hat-relaterad kod och fristående open source-komponenter. För det tredje ska IBM och Red Hat samordna ansvarsfull rapportering uppströms, så att korrigeringar också kan komma de öppna projekten till del.

    Det är en viktig balansgång. Öppen källkod bygger på samarbete, transparens och frivilliga eller företagsstödda underhållare. IBM och Red Hat framhåller därför att Project Lightwell inte ska ersätta befintliga säkerhetsprocesser eller de utvecklare som redan underhåller projekten. I stället presenteras satsningen som ett extra lager för samordning, validering och företagsanpassad hantering av säkerhetsproblem.

    För Red Hat ligger initiativet nära bolagets etablerade affärsmodell. Red Hat har länge byggt sin verksamhet på att paketera, underhålla, testa och ge support för öppen källkod i företagsmiljöer. Skillnaden med Project Lightwell är att samma typ av ingenjörsprocesser nu ska kunna tillämpas på ett större ekosystem av open source-komponenter, även sådana som inte ingår direkt i Red Hats egna plattformar.

    Projektet testas redan tillsammans med tidiga användare inom finanssektorn. Bland de organisationer som nämns finns Bank of America, BNY, Citi, Goldman Sachs, JPMorgan Chase, Mastercard, Morgan Stanley, Royal Bank of Canada, State Street, Visa och Wells Fargo. Erfarenheterna från dessa piloter ska enligt IBM användas för att förbättra hur sårbarheter identifieras, valideras och åtgärdas i stor skala.

    Initiativet visar också hur säkerheten kring öppen källkod håller på att bli en strategisk fråga för storföretag. Tidigare har många organisationer förlitat sig på att enskilda projekt, distributioner eller leverantörer hanterar säkerhetsuppdateringar. Med allt mer komplexa beroendekedjor, AI-genererad kod och snabbare sårbarhetsforskning räcker det inte alltid med traditionella processer.

    Project Lightwell kan därför ses som ett försök att bygga en mer industriell modell för säkerhet i öppen källkod. Genom att kombinera AI, storskalig ingenjörskapacitet och samordning med upstream-projekt vill IBM och Red Hat skapa ett system där företag snabbare kan få tillgång till testade och betrodda säkerhetsfixar.

    Samtidigt väcker modellen frågor. Om säkerhetsfixar och validering erbjuds genom kommersiella abonnemang kan det skapa en tydligare uppdelning mellan företagsanpassad open source-säkerhet och den bredare öppna gemenskapens resurser. Hur IBM och Red Hat hanterar balansen mellan kommersiell nytta och bidrag tillbaka till öppna projekt blir därför avgörande för hur Project Lightwell tas emot.

    Klart är att säkerhet i mjukvarans leveranskedja har blivit en av de stora frågorna för hela IT-branschen. När Linux, Kubernetes, Java-bibliotek, AI-ramverk och molnkomponenter utgör grunden för samhällsviktig infrastruktur blir frågan inte längre om öppen källkod används, utan hur den säkras, testas och underhålls över tid.

    Med Project Lightwell vill IBM och Red Hat positionera sig som en central aktör i den utvecklingen. Om satsningen lyckas kan den bli ett viktigt steg mot mer strukturerad, AI-assisterad och företagsanpassad säkerhet för den öppna källkod som stora delar av den digitala världen redan är beroende av.

    https://newsroom.ibm.com/2026-05-28-ibm-and-red-hat-commit-5-billion-to-redefine-the-future-of-open-source-in-the-ai-era

    Fakta: Project Lightwell

    Vad är det?
    Project Lightwell är ett initiativ från IBM och Red Hat för att stärka säkerheten i öppen källkod som används i företag, molnplattformar och AI-system.

    Budget:
    5 miljarder dollar.

    Syfte:
    Att identifiera, analysera, validera och åtgärda sårbarheter i open source-komponenter i stor skala.

    Teknik:
    AI-assisterad kodanalys kombineras med arbete från IBM:s och Red Hats ingenjörer.

    Omfattar bland annat:
    Linux, Java, Kubernetes, Kafka, Ansible, Terraform, Flink, Cassandra, AI-ramverk, språkverktyg och fristående bibliotek.

    Målgrupp:
    Främst stora företag och organisationer som är beroende av öppen källkod i produktion.

    Viktigt att notera:
    Project Lightwell är inte tänkt att ersätta öppna utvecklarprojekt eller befintliga säkerhetsprocesser, utan fungera som ett extra lager för samordning, testning och validering.

  • När Linux sätter gränser för vad som är en säkerhetsbugg

    När antalet AI-genererade sårbarhetsrapporter ökar vill Linuxprojektet dra en tydligare gräns mellan vanliga buggar och verkliga säkerhetshål. Linus Torvalds har nu slagit ihop ny dokumentation som förklarar när ett fel i Linuxkärnan ska behandlas som en säkerhetsbugg, hur rapporter bör skickas in och varför spekulativa AI-fynd inte får belasta säkerhetsteamet i onödan. Resultatet är en mer praktisk hotmodell för Linux – och ett försök att skilja allvarliga angreppsvägar från brus, teorier och dåligt testade rapporter.

    Linuxkärnan är ett av världens viktigaste mjukvaruprojekt. Den används i allt från mobiltelefoner och servrar till routrar, bilar, molntjänster och superdatorer. Därför är frågan om säkerhetsbuggar i Linux inte bara en teknisk detalj för utvecklare, utan något som i förlängningen påverkar stora delar av det digitala samhället.

    Nu har Linus Torvalds slagit ihop ny dokumentation i Linuxkärnan som tydligare förklarar vad som faktiskt räknas som en säkerhetsbugg, hur sådana buggar bör rapporteras och hur utvecklare ska hantera rapporter som tagits fram med hjälp av AI. Dokumentationen ingår i ändringarna för docs-7.1-fixes och bygger bland annat på arbete av Willy Tarreau, känd från HAProxy och underhåll av stabila Linuxkärnor.

    Alla buggar är inte säkerhetshål

    En central poäng i den nya dokumentationen är att inte alla fel i kärnan ska betraktas som säkerhetshål. Linuxprojektet vill i första hand att vanliga buggar ska hanteras öppet, på publika e-postlistor och i den normala utvecklingsprocessen.

    Det finns en praktisk orsak till detta. När fler utvecklare kan läsa, granska och testa en lösning ökar chansen att felet rättas på ett bra sätt. Om en bugg däremot behandlas bakom stängda dörrar av en liten grupp personer finns större risk att viktiga användningsfall missas eller att lösningen inte blir tillräckligt testad.

    Den privata säkerhetslistan är därför tänkt för särskilt allvarliga fall: buggar som är lätta att utnyttja, påverkar många användare och ger en angripare rättigheter som denne inte borde ha på ett korrekt konfigurerat produktionssystem.

    Med andra ord: ett fel blir inte automatiskt ett säkerhetshål bara för att det kan krascha något eller ser farligt ut i teorin. Det avgörande är om felet passerar en verklig säkerhetsgräns.

    Linux får en tydligare hotmodell

    En viktig del av förändringen är att Linuxkärnan nu får en mer uttalad hotmodell. En hotmodell beskriver vad systemet ska skydda mot, men också vad det inte kan eller inte lovar att skydda mot.

    Linuxkärnan ska bland annat skydda användare från varandra på samma system. En vanlig användare ska inte kunna läsa andra användares filer, komma åt deras processminne, spionera på deras processer eller kringgå skydd som styr nätverk och kommunikation.

    Kärnan ska också upprätthålla skydd baserade på så kallade capabilities, alltså särskilda behörigheter som CAP_SYS_ADMIN, CAP_NET_ADMIN och CAP_SYS_PTRACE. En användare utan rätt behörighet ska exempelvis inte kunna ändra nätverksinställningar, manipulera andra användares processer eller påverka kärnans tillstånd.

    Om en bugg gör att en vanlig användare kan få en sådan behörighet, eller göra något som normalt kräver administratörsrättigheter, kan det röra sig om en riktig säkerhetsbugg.

    AI-rapporter har blivit ett problem

    Den nya dokumentationen tar också upp ett modernt problem: AI-assisterade sårbarhetsrapporter.

    AI-verktyg kan vara användbara för att hitta misstänkta buggar i kod, särskilt i gamla eller ovanliga delar av kärnan. Men enligt dokumentationen har många rapporter som skickas till säkerhetsteamet blivit för långa, för spekulativa eller helt enkelt för dåligt verifierade.

    Problemet är inte att AI används. Problemet är när AI-genererade rapporter skickas in utan att någon människa har kontrollerat om felet verkligen går att återskapa, om det har säkerhetspåverkan eller om den föreslagna exploiten faktiskt fungerar.

    Därför säger den nya vägledningen att buggar som hittats med AI normalt ska behandlas som offentliga. Skälet är att flera personer ofta hittar samma typ av AI-upptäckta fel samtidigt. Däremot ska fungerande exploitkod inte publiceras öppet. Rapportören kan i stället säga att en reproducerbar exploit finns och lämna den privat om en ansvarig underhållare ber om det.

    Rapporter ska vara korta, tydliga och testade

    Linuxutvecklarna efterfrågar nu mer disciplinerade rapporter. En bra rapport ska vara kort, skriven i ren text och börja med det viktigaste: vilken fil eller funktion som påverkas, vilka versioner som berörs och vilken konkret påverkan felet har.

    Det räcker inte att skriva att ett fel “kan leda till privilegieeskalering” om det inte är visat. Rapportören bör i stället beskriva vad som faktiskt har testats. Till exempel: kan en vanlig användare få CAP_NET_ADMIN? Kan en process läsa minne den inte ska komma åt? Går felet att återskapa på en normal installation?

    AI-genererade reproducerare ska testas innan de skickas in. Om en AI påstår att en exploit fungerar, men rapportören inte själv har kontrollerat det, riskerar rapporten att ignoreras. Dokumentationen uppmuntrar också till att använda AI för att föreslå och testa fixar, inte bara för att producera fler felrapporter.

    Vad räknas inte som säkerhetsbugg?

    Den nya dokumentationen listar flera typer av problem som normalt inte ska ses som säkerhetshål i Linuxkärnan.

    Det gäller till exempel buggar i gamla, icke-underhållna kärnversioner. Administratörer förväntas hålla sina system uppdaterade, och en sårbarhet måste visas påverka aktivt underhållna versioner för att behandlas som en aktuell säkerhetsfråga.

    Det gäller också osäkra eller ovanliga konfigurationer. Om någon själv har ändrat sysctl-inställningar, filrättigheter eller byggt kärnan med alternativ som uttryckligen sänker säkerheten, är det inte självklart en kärnsårbarhet när något går fel.

    Utvecklingsfunktioner som LOCKDEP, KASAN och FAULT_INJECTION räknas inte heller som produktionsskydd. De är till för testning och felsökning, och kan i sig påverka stabilitet och prestanda.

    Inte heller buggar som kräver orimliga laboratorieförhållanden, modifierad hårdvara, miljarder försök eller redan mycket höga rättigheter ska automatiskt betraktas som säkerhetshål.

    Root som kraschar systemet är inte alltid en sårbarhet

    En annan viktig princip är att åtgärder som kräver full administratörsbehörighet sällan är säkerhetsbuggar i sig. Om root-användaren i den ursprungliga namnrymden kan skriva till en privilegierad enhet och orsaka en kernel oops, är det normalt inte en säkerhetsgräns som brutits. Root hade redan makten att påverka systemet.

    Det Linuxprojektet fokuserar på är i stället när en användare får mer makt än den borde ha. Säkerhetsfrågan uppstår alltså när någon passerar en gräns mellan rättigheter, inte när någon redan har rättigheterna och använder dem på ett destruktivt sätt.

    Användarnamnrymder får särskild förklaring

    Dokumentationen tar även upp CONFIG_USER_NS, alltså stöd för användarnamnrymder. Med denna funktion kan en vanlig användare skapa en isolerad miljö där användaren till synes har fulla rättigheter inom just den miljön.

    Det betyder dock inte att användaren ska kunna påverka hela systemet. En sådan namnrymd får inte ge möjlighet att ändra global systemtid, ladda kärnmoduler, montera blockenheter eller påverka den ursprungliga namnrymden på otillåtet sätt.

    Här blir hotmodellen viktig. En bugg är allvarlig om den gör att isoleringen mellan namnrymder bryts.

    Debuggning är inte alltid tänkt för vanliga användare

    Linux innehåller många kraftfulla verktyg för felsökning och prestandaanalys. Exempel är /proc/kmsg, perf, tracing och debugfs. Dessa kan ge djup insyn i systemet och därmed också bli riskabla om de exponeras fel.

    Den nya dokumentationen betonar att vissa sådana gränssnitt kräver uttryckligt administratörsbeslut. Om en administratör själv ger användare tillgång till känsliga debuggränssnitt är det inte nödvändigtvis ett säkerhetshål i kärnan. Det är en konfigurationsfråga.

    Målet är mindre brus och bättre fixar

    Bakgrunden till förändringen är tydlig: Linuxprojektet vill minska mängden felrapporter som felaktigt märks som säkerhetskritiska. Varje rapport som hamnar fel tar tid från utvecklare och säkerhetsteam. Det gör att verkligt allvarliga problem riskerar att drunkna i brus.

    Samtidigt stänger dokumentationen inte dörren för osäkra fall. Om en rapportör verkligen är osäker på om ett fel är en säkerhetsbugg uppmanas denne fortfarande att rapportera privat. Hellre en extra granskning av ett gränsfall än att en verklig sårbarhet missas.

    Men budskapet är tydligt: kalla inte varje bugg för ett säkerhetshål. Visa vilken säkerhetsgräns som bryts, testa reproduceraren, håll rapporten kort och skicka vanliga buggar till den vanliga utvecklingsprocessen.

    En mognare syn på säkerhet i en AI-tid

    Det här är mer än en intern dokumentationsändring. Det visar hur stora öppna källkodsprojekt anpassar sig till en ny verklighet där AI kan massproducera analyser, hypoteser och rapporter.

    AI kan hjälpa till att hitta riktiga fel. Men den kan också skapa stora mängder halvfärdiga påståenden som människor måste granska. För ett projekt som Linux, där underhållarnas tid är en begränsad resurs, blir kvaliteten på rapporterna avgörande.

    Den nya dokumentationen försöker därför sätta en rimlig balans. Säkerhet ska tas på allvar, men säkerhetsprocessen ska inte överbelastas av spekulationer, dåligt testade AI-fynd eller buggar som egentligen hör hemma i den öppna utvecklingsprocessen.

    I praktiken handlar det om något mycket grundläggande: ett säkerhetshål är inte bara ett fel i kod. Det är ett fel som bryter ett skydd som systemet har lovat att upprätthålla. Linuxprojektets nya dokumentation gör den gränsen tydligare.

    https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=36d49bba19f2c19c933d13b25dcf4eb607a030b3

    Teknisk faktaruta: Linuxkärnans nya säkerhetsdokumentation

    Ämne: Nya riktlinjer för säkerhetsbuggar i Linuxkärnan

    Infört av: Linus Torvalds via dokumentationsändringar i Linuxkärnan

    Pull request: docs-7.1-fixes

    Författare till dokumentationen: Willy Tarreau

    Syfte: Att tydliggöra vad som räknas som en säkerhetsbugg, hur rapporter ska skickas in och hur AI-assisterade buggrapporter ska bedömas.

    Viktiga nyheter:

    • Tydligare gräns mellan vanliga buggar och säkerhetsbuggar.
    • Ny hotmodell för Linuxkärnan.
    • Riktlinjer för AI-genererade och AI-assisterade rapporter.
    • Krav på testade reproducerare och verifierad påverkan.
    • Fokus på buggar som bryter verkliga säkerhetsgränser.

    Exempel på säkerhetspåverkan: En vanlig användare får behörigheter som normalt kräver administratörsrättigheter, exempelvis nätverkskontroll eller åtkomst till andra användares processer.

    Räknas normalt inte som säkerhetsbugg: Fel i gamla kärnversioner, osäkra specialkonfigurationer, utvecklingsfunktioner, teoretiska attacker utan fungerande exploit eller problem som kräver redan höga rättigheter.

    Betydelse: Dokumentationen ska minska brus i säkerhetsrapporteringen och hjälpa utvecklare att fokusera på verkligt allvarliga sårbarheter.

  • 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: sårbarheter

  • Rsync 3.5 släppt – rättar 33 säkerhetsproblem

    Rsync 3.5 har släppts med rättningar för 33 säkerhetsproblem, däribland en kritisk sårbarhet som kunde användas för att kringgå serverns åtkomstkontroller. Uppdateringen innehåller dessutom omfattande förstärkningar av programmets hantering av sökvägar, symboliska länkar, krypterade anslutningar och rsync-servrar. Rsync 3.5 har släppts med omfattande säkerhetsförbättringar. Den nya versionen rättar sammanlagt 33 säkerhetsproblem, varav ett klassas som…

  • Stor säkerhetsuppdatering för Debian 13 täpper till 68 sårbarheter

    Debianprojektet har släppt en omfattande säkerhetsuppdatering för Debian 13 ”Trixie”. Uppdateringen rättar 68 säkerhetsproblem i Linuxkärnan, däribland brister som kan orsaka systemkrascher, informationsläckor och i vissa fall ge en angripare fullständig kontroll över datorn. Den nya uppdateringen publicerades den 31 juli 2026 och gäller Linuxkärnan 6.12 LTS, som används i Debian 13. Alla användare rekommenderas…

  • Oracle inför ny styrmodell för MySQL

    Oracle inför en ny styrmodell för MySQL som ska ge tydligare roller för bidragsgivare, tekniska ledare och strategiska beslutsforum. Målet är att öka öppenheten kring utvecklingen, stärka samarbetet med communityn och skapa fler formella vägar för externa aktörer att påverka databasens framtid. Samtidigt är MySQL fortsatt ett Oracle-lett projekt. Oracle inför en ny styrmodell för…

  • Akrites ska hjälpa öppen källkod att hantera säkerhetshot snabbare

    När AI-verktyg gör det lättare att hitta säkerhetsbrister i öppen källkod ökar också trycket på de utvecklare som måste hantera rapporterna. Därför lanserar Linux Foundation initiativet Akrites, som ska samordna rapportering, åtgärder och offentliggörande av allvarliga sårbarheter i viktiga öppna projekt. Akrites ska hjälpa öppen källkod att hantera säkerhetshot snabbare Öppen källkod är en grundpelare…

  • IBM och Red Hat satsar 5 miljarder dollar på säkerhet i öppen källkod

    IBM och Red Hat lanserar Project Lightwell, en satsning på 5 miljarder dollar för att stärka säkerheten i öppen källkod. Genom att kombinera AI-assisterad kodanalys med tusentals ingenjörer vill företagen skapa ett betrott säkerhetslager för företag som är beroende av Linux, Kubernetes, Java, AI-ramverk och andra centrala open source-komponenter. IBM och Red Hat lanserar Project…

  • När Linux sätter gränser för vad som är en säkerhetsbugg

    När antalet AI-genererade sårbarhetsrapporter ökar vill Linuxprojektet dra en tydligare gräns mellan vanliga buggar och verkliga säkerhetshål. Linus Torvalds har nu slagit ihop ny dokumentation som förklarar när ett fel i Linuxkärnan ska behandlas som en säkerhetsbugg, hur rapporter bör skickas in och varför spekulativa AI-fynd inte får belasta säkerhetsteamet i onödan. Resultatet är en…

  • 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…