Välkommen till denna veckas Tech Talk! I denna utgåva undersöker vi en rad olika cybersäkerhetsutvecklingar, från en kritisk sårbarhet i Canon-skrivarens drivrutiner som möjliggör utnyttjande av Windows-kärnan, till Frankrikes storskaliga phishing-medvetenhetskampanj som involverar mer än 2,5 miljoner studenter. Vi kommer också att titta på en kontroversiell WordPress-funktion som introducerades 2022 och som sedan dess visat sig vara sårbar för missbruk, samt den senaste CVSS 10.0-rankade sårbarheten som upptäckts i Apache Parquet och som kräver omedelbar uppmärksamhet.
Under tiden överväldigar AI-botar som söker efter ny data öppna plattformar, Gmails påstående om end-to-end-kryptering håller inte helt, och Oracle väcker frågor med sin tystnad på flera fronter. I USA har Utah antagit App Store Accountability Act, vilket potentiellt förändrar hur mobilmarknader regleras. Och när Microsoft fortsätter att strama åt sitt ekosystem kommer Windows 11 nu att kräva ett Microsoft-konto för installation. Dessutom kommer vi att lyfta fram oväntat ledarskap inom cybersäkerhet från hushållssektorn, svara på insiktsfull feedback från lyssnare och utforska den växande betydelsen av Multi-Perspective Issuance Corroboration, en term som certifikatutfärdare inte längre kan ignorera.
1. Canon-skrivarattacken väcker oro, medan Fisher & Paykel sätter en ny standard för IoT-säkerhet
Denna vecka har två helt olika historier om vardagsteknikprodukter erbjudit en kraftfull kontrast. Å eDenna vecka har två mycket olika historier som involverar vardagsteknologiprodukter erbjudit en kraftfull kontrast. Å ena sidan har vi en kritisk sårbarhet i skrivardrivrutiner med allvarliga säkerhetsimplikationer. Å andra sidan har vi en hushållsapparattillverkare som gör säkerhet rätt och höjer ribban för hela branschen.
Canon-skrivarens drivrutiner innehåller hög risk-sårbarhet
Microsofts Offensive Research and Security Engineering (MORSE) team har avslöjat en betydande sårbarhet i Canon-skrivarens drivrutiner som påverkar ett brett spektrum av konsument- och företagsmodeller. Denna sårbarhet, rankad 9,4 på CVSS-skalan, tillåter skadliga aktörer att kompromettera Windows-system och i vissa fall få kodexekvering på kärnnivå. Sårbarheten härrör från en brist i hur drivrutinen bearbetar Enhanced Metafile (EMF) utskriftsdata. Det öppnar dörren för avsiktlig minneskorruption, vilket gör det möjligt för angripare att köra skadlig kod på systemet. Eftersom drivrutinerna är digitalt signerade av Microsoft kan de missbrukas även på maskiner som inte har Canon-skrivare installerade. Denna teknik, känd som “Bring Your Own Vulnerable Driver” (BYOVD), tillåter angripare att ladda dessa signerade men sårbara drivrutiner på ett system och utnyttja dem för att få djup åtkomst. Canon har erkänt problemet och arbetar med att släppa uppdaterade drivrutiner för att lösa sårbarheten. Tills dessa uppdateringar är allmänt tillämpade kvarstår hotet på system som har dessa drivrutiner installerade eller som kan luras att ladda dem.
Varför det är viktigt
Drivrutinsårbarheter är bland de farligaste typerna av brister eftersom de fungerar i hjärtat av systemet. När de utnyttjas kringgår de flesta säkerhetsåtgärder och ger angripare åtkomst till Windows-kärnan. Denna upptäckt förstärker behovet av att organisationer inte bara håller drivrutiner uppdaterade, utan också övervakar användningen av äldre eller sällan använda drivrutiner i sina miljöer. Det faktum att signerade drivrutiner kan användas för att starta attacker mot system som inte ens äger den associerade hårdvaran är ett perfekt exempel på hur förtroendet för mjukvaruförsörjningskedjan kan vapeniseras. Organisationer måste svara genom att implementera bättre synlighet på slutpunktsnivå, inaktivera onödig drivrutinsladdning och vara uppmärksamma på uppdateringar från leverantörer som Canon.
Nu, i skarp kontrast till detta, låt oss vända oss till ett företag som gör IoT-säkerhet exakt rätt.
Fisher & Paykel: En överraskande ledare inom säkerhet för anslutna enheter
Det är inte ofta som en hushållsapparattillverkare gör rubriker inom cybersäkerhetsområdet av rätt skäl. Men Fisher & Paykel, ett nyzeeländskt apparatmärke, har gjort just det med en anmärkningsvärt omfattande och transparent strategi för att säkra sina anslutna produkter. Deras offentligt tillgängliga cybersäkerhetspolicy beskriver ett åtagande till vad de kallar “säkerhet genom design”, “säkerhet som standard” och “försvar i djupet”. Dessa är inte bara modeord. De har detaljerat hur kryptering, säker autentisering och bästa praxis för mjukvaruutveckling integreras i varje steg, från design till tillverkning till support efter distribution. Företaget använder moderna Wi-Fi-protokoll som WPA3 direkt ur lådan och säkerställer att alla säkerhetsfunktioner är aktiverade automatiskt när en ansluten apparat först ställs in. De utför också regelbundna penetrationstester, uppmuntrar ansvarsfull avslöjande och arbetar aktivt med etiska hackare. Deras IoT-produkter har fått guldnivåcertifiering från Underwriters Laboratories IoT Security Rating-program, vilket ytterligare bekräftar deras mognad inom detta område. De går till och med så långt som att tillhandahålla detaljerad användarvägledning om hemnätverkssäkerhet, inklusive hur man segmenterar IoT-enheter från känsliga system som bank- eller arbetsmiljöer.
Varför det är viktigt
Denna typ av engagemang är sällsynt, och det är något vi tycker förtjänar allvarlig erkännande. För många IoT-tillverkare tar genvägar med säkerhet, ofta genom att skicka enheter med svaga standardlösenord, föråldrad mjukvara eller ingen tydlig patchmodell. Fisher & Paykel bevisar att det är möjligt att bygga anslutna enheter som är säkra, användarvänliga och transparenta. Deras proaktiva inställning till säkerhet bör fungera som en modell för hela branschen. Vi är särskilt imponerade av deras fokus på standardiserade skydd, lager av säkerhet och öppenhet med kunder. Om fler leverantörer tog denna inställning skulle attackytan i smarta hem och företag minska dramatiskt. Detta är vad “säker som standard” borde se ut. Bra gjort.
2. Frankrike testar phishing på 2,5 miljoner elever – och barnen klarade sig förvånansvärt bra
I en kreativ och storskalig insats för att främja medvetenhet om cybersäkerhet genomförde den franska regeringen nyligen en phishing-simulering som riktade sig till mer än 2,5 miljoner mellanstadie- och gymnasiestudenter. Det falska betet var en länk som lovade tillgång till fusk-koder och knäckta spel, vilket istället omdirigerade studenterna till en utbildningsvideo om phishing-medvetenhet.
Enligt CNIL, Frankrikes dataskyddsmyndighet, klickade cirka 210 000 studenter på länken. Även om det antalet kan låta högt, representerar det bara ungefär en av tolv deltagare. Som jämförelse ser många phishing-simuleringar i företagsvärlden klickfrekvenser närmare en av tre.
Varför det är viktigt
Denna initiativ är ett utmärkt exempel på hur cybersäkerhetsutbildning kan börja tidigt och ändå vara mycket effektiv. Genom att använda realistiskt, åldersrelevant bete och göra lektionen till en omedelbar lärandeupplevelse levererade programmet både påverkan och insikt. Vi är uppmuntrade av resultaten. Inte bara visade studenterna bättre medvetenhet om phishing än många arbetande vuxna, men kampanjen visade också att medvetenhetsträning inte behöver vara torr eller teknisk för att vara effektiv. Frankrikes kampanj återspeglar den
3. WordPress-funktion möjliggör smygande skadeprogram – och används aktivt
Med WordPress som driver mer än 500 miljoner webbplatser globalt, förblir det en av de viktigaste och mest målinriktade plattformarna på internet. Därför måste alla säkerhetsrelaterade designbeslut i WordPress övervägas noggrant. En funktion som lades till 2022 är nu under granskning för att skapa en dold väg för angripare.
Funktionen kallas “Must Use Plugins” eller mu-plugins. Den tillåter plugin-filer att läggas till i en specifik mapp inuti WordPress-installationen. När de väl är placerade där aktiveras pluginet automatiskt och kan inte inaktiveras från administratörspanelen. Det enda sättet att ta bort det är genom att manuellt radera filen från servern. Ursprungligen var detta tänkt att hjälpa webbhotell att säkerställa att viktig funktionalitet inte kunde stängas av av misstag. Men angripare har upptäckt att mu-plugins-mappen är en perfekt plats att installera skadlig kod.
Enligt GoDaddys Sucuri-säkerhetsteam har hotaktörer aktivt använt denna metod för att köra skadlig kod på komprometterade webbplatser utan att bli upptäckta. Eftersom mu-plugins inte visas tillsammans med vanliga plugins i administratörspanelen, och eftersom många säkerhetsverktyg inte skannar denna katalog, använder angripare den för att distribuera bakdörrar, webbshells, SEO-spam och trafikomdirigeringar. Skalan och variationen av dessa attacker tyder på att denna teknik blir alltmer populär i kriminella kretsar. Sucuri rekommenderar att administratörer regelbundet inspekterar mu-plugins-mappen. Om den inte används bör den raderas och övervakas för att förhindra framtida missbruk.
Varför det är viktigt
Detta är ett tydligt exempel på hur en funktion designad för bekvämlighet snabbt kan bli en ansvarsskyldighet när den saknar ordentlig tillsyn. Genom att tillåta plugins att tyst aktiveras och döljas från standardkontroller, tar mu-plugins-systemet bort viktiga lager av synlighet och ansvarsskyldighet. Säkerhet bör aldrig förlita sig på osynlighet. Alla filer som kan köra kod på en live-webbplats bör vara tydligt synliga för både administratörer och säkerhetssystem. På Sidia Tech anser vi att WordPress-webbplatsägare bör behandla mu-plugins som en privilegierad funktion. Den bör endast användas i kontrollerade miljöer, med strikt loggning och integritetskontroller på plats. När en design ger angripare en dold dörr och en välkomstmatta är det bara en tidsfråga innan den missbrukas. WordPress-gemenskapen måste omvärdera denna funktion eller riskera att den blir en permanent svag punkt.
4. Oracle står inför anklagelser om intrång, men förblir tyst trots SEC-krav
Denna vecka är alla ögon riktade mot Oracle, och inte av de skäl företaget skulle vilja. Moln- och företagsprogramvarujätten, som för närvarande tävlar om att hantera TikToks amerikanska datainfrastruktur, står inför allvarliga frågor efter rapporter om två betydande cybersäkerhetsintrång och en pågående brist på offentliggörande.
Enligt källor som citeras av Bloomberg, drabbades Oracle Health av ett intrång i slutet av januari, under vilket angripare påstås ha stulit medicinsk data från företagets servrar. Den stulna datan används nu enligt uppgift för att utpressa vårdgivare i USA. Trots allvaret i incidenten har Oracle inte offentligt erkänt intrånget, och har inte heller lämnat in en obligatorisk rapport till U.S. Securities and Exchange Commission. Det skulle vara oroande nog. Men kort därefter dök en andra incident upp. I början av mars påstod en hotaktör med aliaset rose87168 att ha komprometterat Oracle Clouds federerade SSO-inloggningssystem, vilket exponerade kontodata kopplade till så många som sex miljoner användare.
Även om Oracle officiellt har förnekat att något intrång har inträffat, kunde cybersäkerhetsjournalisten Lawrence Abrams från BleepingComputer verifiera äktheten av läckt data genom att kontakta berörda företag direkt. Organisationer som kontaktades av BleepingComputer bekräftade anonymt att LDAP-displaynamn, e-postadresser och annan identitetsinformation i proverna var korrekta och tillhörde dem. Dessutom delade angriparen e-postmeddelanden som verkar visa dem kommunicera med Oracle, både genom företagets officiella säkerhetskontakt och genom en obekräftad ProtonMail-adress.
Även om dessa detaljer inte alla kan verifieras oberoende, målar kombinationen av tekniska bevis och bekräftelse från drabbade företag en trovärdig bild av en allvarlig kompromiss. För att göra saken värre, fann CloudSEK-analytiker bevis på att Oracles infrastruktur kan ha kört föråldrad och sårbar middleware-programvara vid tidpunkten för intrånget. Specifikt rapporterades servern i fråga använda Oracle Fusion Middleware 11g, som påverkas av CVE-2021-35587, en känd sårbarhet i Oracle Access Manager. Oracle har sedan dess tagit servern offline.
Trots allt detta har Oracle vägrat att bekräfta eller förneka detaljerna i någon av incidenterna och har inte lämnat in det nödvändiga offentliggörandet som krävs enligt SEC Rule 1.05, vilket kräver att börsnoterade företag rapporterar materiella cybersäkerhetsincidenter inom fyra arbetsdagar efter att ha fastställt att incidenten är materiell.
Varför det är viktigt
I den nuvarande reglerings- och hotmiljön är tystnad inte ett alternativ. Oracles brist på transparens, om dessa rapporter är korrekta, är inte bara ett kommunikationsfel, utan potentiellt ett brott mot federal lag. Som ett företag som anförtrotts känslig data, särskilt inom hälso- och företagsidentitetssystem, har Oracle en skyldighet att erkänna intrång, informera kunder och följa offentliggörandelagar. Oavsett om intrången är fullt bekräftade eller inte, underminerar den omgivande bevisningen och Oracles totala brist på offentlig engagemang förtroendet vid en kritisk tidpunkt.
Ur ett säkerhetsperspektiv belyser dessa rapporter också hur föråldrad infrastruktur fortsätter att vara en av de största ansvarsområdena inom företags-IT. När en stor leverantör kör föråldrad programvara på offentligt exponerade system är riskerna enorma, inte bara för deras egen organisation, utan för varje kund som förlitar sig på dem. Transparens bygger förtroende. Tystnad inför en växande mängd bevis gör motsatsen. Om Oracle vill leda inom företagsäkerhet måste de leda genom exempel.
5. Utah undertecknar banbrytande lag om barns säkerhet online, vilket flyttar ansvaret till appbutiker
Utah har officiellt undertecknat en ny lagstiftning som kan omforma hur åldersverifiering fungerar på mobila plattformar över hela USA. Guvernör Spencer Cox har antagit App Store Accountability Act (S.B. 142), som träder i kraft den 6 maj 2026, vilket ger appbutiker och utvecklare drygt ett år att förbereda sig för dess krav.
Den nya lagen kräver att Apple och Google verifierar åldern på användare som får tillgång till deras appbutiker. För användare under 18 år krävs också uttryckligt föräldrasamtycke innan de kan ladda ner eller använda åldersbegränsade appar. Avgörande är att ansvaret för efterlevnad nu placeras på appbutiksplattformarna, snarare än på enskilda apputvecklare. Det innebär att ansvaret för efterlevnad faller på Apple och Google, inte på appar som Instagram, Snapchat eller X.
Denna lag är den första i sitt slag i USA och introducerar en grundläggande förändring i hur online åldersverifiering kan hanteras framöver. Det är troligt att den kommer att möta juridiska utmaningar, särskilt kring frågor om integritet, digitala rättigheter och genomförbarhet. Men dess antagande påverkar redan lagstiftningssamtal i andra amerikanska delstater, inklusive Kalifornien och South Carolina, som nu förväntas införa liknande lagförslag.
En av lagens sponsorer, senator Todd Weiler, beskrev lagstiftningen som ett skydd för barn som kanske inte fullt ut förstår eller samtycker till användarvillkoren för de appar de använder. Han pekade på plattformar som Instagram, som tekniskt sett är klassade som lämpliga för 12-åringar men ofta utsätter unga användare för innehåll och interaktioner långt bortom vad den klassificeringen skulle antyda. Det finns fortfarande frågor om hur lagen kommer att hantera appar som redan är installerade på enheter före lagens ikraftträdande. Det är oklart om dessa kommer att undantas från framtida restriktioner eller omfattas av retroaktiv efterlevnad.
Varför det är viktigt
Vi anser att Utahs lag är ett betydande och efterlängtat steg i den pågående diskussionen om digitalt ansvar och barns säkerhet. Det nuvarande systemet förlitar sig till stor del på självdeklaration av ålder, vilket är lätt att kringgå och lämnar barn utsatta för innehåll och interaktioner de kanske inte är beredda på. Genom att kräva att Apple och Google verkställer åldersbegränsningar på plattformsnivå, adresserar Utah en av de grundläggande strukturella svagheterna i appbaserade ekosystem. Om det implementeras väl kan denna metod göra åldersanpassade digitala upplevelser lättare att genomdriva och mer konsekventa över appar.
Men reglering ensam kommer inte att räcka. Teknisk implementering kommer att vara avgörande. Åldersindikatorer bör vara API-läsbara, och föräldrasamtyckesprocesser måste vara säkra, användarvänliga och integritetsrespekterande. Om det görs rätt kan detta representera en ny standard för att balansera säkerhet, användbarhet och autonomi för yngre användare i den digitala tidsåldern. Vi kommer att följa hur Apple, Google och andra intressenter svarar när branschen börjar anpassa sig till en ny regleringsverklighet.
6. AI-crawlers överbelastar öppen källkods-infrastruktur och det börjar likna en DDoS
I deras oändliga jakt på mer data orsakar AI-företag nu verklig skada på det öppna internet—ofta utan att ens inse det. Ett växande antal fria och öppna källkodsprojekt (FOSS) rapporterar vad som motsvarar oavsiktliga distribuerade överbelastningsattacker (DDoS), orsakade av aggressiva och oreglerade AI-botar som skrapar deras webbplatser och arkiv.
Det började med ett blogginlägg med titeln “A Desperate Cry for Help” av utvecklaren Xe Iaso, som beskrev hur deras Gitea-instans upprepade gånger togs offline av AI-crawler-trafik, påstås härstamma från Amazon. Trots att de implementerade standardförsvar som robots.txt-filer, användaragentblockering och trafikfiltrering, anpassade sig crawlers, undvek upptäckt med spoofade användaragenter och roterande IP-adresser. Till slut tvingades Iaso att flytta sin server bakom en VPN och implementera “Anubis”, ett specialbyggt proof-of-work-system som tvingar webbklienter att lösa ett beräkningspussel innan de beviljas åtkomst.
GNOME har sedan dess antagit en liknande lösning, och KDE- och Fedora-underhållare har också rapporterat störningar från AI-botar, varav några spårades tillbaka till stora företagsmoln-IP-områden, inklusive de som är associerade med Alibaba. Ny data visar hur allvarlig situationen har blivit. Vissa projekt rapporterar nu att upp till 97 procent av deras inkommande trafik genereras av AI-crawlers. I fallet med Read the Docs minskade blockering av kända AI-botar omedelbart deras bandbreddsanvändning med 75 procent, vilket sparade ungefär $1 500 per månad i värdkostnader. Ännu mer oroande är att dessa crawlers inte bara får åtkomst till hemsidans innehåll—de träffar resursintensiva slutpunkter som git-loggar, blame-historik och fullständig commit-metadata. Detta beteende utgör en betydande börda för små team som saknar resurser att skala sin infrastruktur därefter.
Varför det är viktigt
Detta är ett allvarligt och växande problem som slår mot kärnan av vad som gör öppen källkodsutveckling möjlig. Öppen infrastruktur bygger på välvilja, respekt och samarbete. AI-företag som skrapar öppna plattformar utan samordning eller samtycke använder inte bara offentlig data, de utnyttjar generositeten och arbetet från de samhällen som driver mycket av den digitala världen.
Vi stöder innovation inom AI, men innovation bör aldrig ske på bekostnad av att undergräva hållbarheten i de system den är beroende av. AI-företag måste gå bortom “crawl first, ask questions later”-mentaliteten. Hastighetsbegränsning, korrekt användaragentidentifiering och öppen kommunikation med projektunderhållare är det absoluta minimum. Vi tror också att det finns utrymme för reglering. Data är inte gratis bara för att den är offentlig, och infrastrukturen som används för att vara värd för den är inte oändlig. Utan gränser eller ansvar riskerar detta beteende att bränna ut de människor och plattformar som modern AI är beroende av.
Projekt som Anubis och Cloudflares nya AI Labyrinth visar löfte om att bekämpa detta, men de är kortsiktiga försvar. Den långsiktiga lösningen kommer att kräva antingen ansvarsfull självreglering från AI-företag eller rättsliga ramar som skyddar digitala allmänningar från att bli utarmade av automatisering. Låt oss vara tydliga: öppen källkodsmjukvara driver allt från global finans till folkhälsa till nationellt försvar. Det är inte förbrukningsbart. Det är grundläggande. Och om vi tillåter det att tyst kvävas av bandbreddsräkningar och skrapningsöverbelastning, förlorar vi alla.
7. Inget Microsoft-konto? Då ingen Windows 11-installation
Om du nyligen har försökt att ställa in en ny Windows 11-maskin med endast ett lokalt konto och funnit processen svårare, eller nästan omöjlig, så inbillar du dig inte. Microsoft har nu formellt tagit bort stöd för att kringgå kontoinloggning under installationen, vilket innebär att framöver kommer ett Microsoft-konto och internetanslutning att krävas för alla nya Windows 11-installationer.
Denna förändring introducerades tyst i Microsofts Windows 11 Insider Preview Build 26200.5516, som en del av Dev-kanalen. Begraven i en lista över diverse ändringar, angav Microsoft att de tar bort bypassnro.cmd-skriptet, en känd metod för att hoppa över kontoinställning och förbli offline. Uppdateringen noterar att detta drag är avsett att “förbättra säkerhet och användarupplevelse”, även om Microsoft inte har utvecklat hur dessa krav uppnår dessa mål.
Den bredare implikationen är tydlig: Microsoft vill att alla användare ska vara knutna till dess ekosystem från allra första början, från installationsskärmen. Även om detta krav har funnits i olika former under en tid, markerar detta första gången Microsoft har gjort policyn officiell i offentlig dokumentation.
Varför det är viktigt
Detta är en tydlig signal om att eran av fristående lokala Windows-installationer går mot sitt slut. För individer eller organisationer som har föredragit att använda offline-system för integritet, testning eller specialiserade arbetsflöden, kan denna policyändring innebära både logistiska och filosofiska utmaningar. Ur ett säkerhetsperspektiv är Microsofts önskan att standardisera identitet och anslutning under installationen meningsfull i vissa sammanhang. Funktioner som molnåterställning, realtidsövervakning av hot och synkronisering över enheter är beroende av att användare är online och autentiserade.
Men bristen på flexibilitet för avancerade användare och integritetsmedvetna organisationer är oroande. Vi förväntar oss också att, som med tidigare begränsningar, oberoende utvecklare och systemadministratörer snart kommer att släppa nya lösningar. Detta har varit ett konsekvent mönster i Windows historia, där community-verktyg ofta dyker upp som svar på plattformsbeslut som begränsar användarkontroll.
På SidiaTech anser vi att säkerhet och användbarhet inte bör ske på bekostnad av användarautonomi. Att kräva internetåtkomst och molnidentitet på OS-nivå kan gynna vissa användare, men det bör inte vara det enda alternativet. Organisationer som hanterar känsliga system, luftgapade nätverk eller anpassade distributionsmiljöer behöver alternativ. Som alltid rekommenderar vi att noggrant följa hur dessa förändringar utvecklas i produktionsversionen av Windows 11 och överväga om mer flexibla distributionsmodeller som Windows LTSC eller andra operativsystem kan vara mer lämpliga för specifika användningsfall.
8. Gmails nya “end-to-end-kryptering” är inte riktigt vad det låter som
Förra veckan tillkännagav Google en ny krypteringsfunktion för Gmail-företagsanvändare, och marknadsförde den som “end-to-end-kryptering” (E2EE). Vid första anblicken låter det som ett stort steg framåt för e-postintegritet. Men som ofta är fallet med säkerhetsterminologi i marknadsföring, är verkligheten lite mer nyanserad.
Krypteringen sker faktiskt på avsändarens och mottagarens webbläsare. Meddelanden krypteras i avsändarens webbläsare och förblir krypterade under överföringen, och dekrypteras först när de når mottagarens enhet. Så långt, så bra. Men arkitekturen som Google har byggt kring denna process introducerar betydande skillnader från vad som vanligtvis anses vara sann end-to-end-kryptering.
Googles system använder en Key Access Control List (KACL), som är värd och hanteras av avsändarens organisation. Denna nyckelserver genererar och levererar tillfälliga symmetriska nycklar som används för kryptering och dekryptering. När ett meddelande skickas krypterar webbläsaren det med en nyckel från KACL. Mottagarens webbläsare ansluter senare till samma KACL-server för att hämta nyckeln och dekryptera meddelandet, men först efter att ha autentiserat genom en tredje parts identitetsleverantör som Okta eller Ping.
Denna process möjliggör strikt åtkomstkontroll men innebär också att avsändarens organisation behåller den slutliga auktoriteten över krypteringsnycklarna. Google hänvisar till detta system som Client-Side Encryption (CSE). Det är en smart design som syftar till att balansera användbarhet och regulatorisk efterlevnad. Avgörande är att Google betonar att de aldrig ser det dekrypterade innehållet, och att kryptering och dekryptering sker helt på slutanvändarens enheter. Men eftersom organisationens administratörer hanterar nycklarna kan de teoretiskt dekryptera alla meddelanden som skickas med detta system.
Denna uppsättning positioneras som ett alternativ till S/MIME, den nuvarande industristandarden för företags-e-postkryptering, som är notoriskt svår att distribuera och hantera. Jämfört med detta är Gmails nya lösning enklare och mer skalbar, särskilt för organisationer som är föremål för strikta regulatoriska krav kring kryptering och dataskydd.
Varför det är viktigt
Detta är en smart lösning för ett mycket specifikt problem. För företag som arbetar inom regering, sjukvård eller juridiska sektorer där dataskyddsreglerna är stränga, gör Googles nya system kryptering lättare att implementera i stor skala. Det erbjuder ett välkommet alternativ till komplexiteten i S/MIME, utan att kräva att användare hanterar certifikat manuellt eller utbyter nycklar i förväg.
Det sagt, detta är inte den typ av end-to-end-kryptering som integritetsförespråkare vanligtvis har i åtanke. I strikt mening innebär E2EE att endast avsändaren och mottagaren har åtkomst till meddelandet. I Googles version behåller organisationen fortfarande nycklarna, och administratörer behåller möjligheten att komma åt innehållet om det behövs. Den skillnaden är viktig.
Det är också värt att notera att kryptering som sker i en webbläsare fortfarande innebär risk. Moderna webbläsare är stora, komplexa plattformar som ofta kräver säkerhetsuppdateringar. Att dekryptera känsliga meddelanden inom en webbläsare är mer bekvämt, men det är inte samma sak som att kryptera data offline eller inom specialbyggda säkra klienter.
Kort sagt, detta är en pragmatisk lösning, inte en perfekt. Det erbjuder verkliga fördelar för reglerade företag som söker ett enklare sätt att anta kryptering, men det är inte utformat för användare som söker maximal integritet eller ensam kontroll över sina kommunikationer.
Om din organisation överväger att implementera Gmail CSE, är det värt att förstå både dess kapaciteter och dess begränsningar. Det är ett verktyg, inte en silverkula.
9. Apache Parquet drabbas av en CVSS 10.0 RCE-sårbarhet
En kritisk sårbarhet har upptäckts i Apache Parquet, ett mycket använt öppet kolumnlagringsformat för big data-analys. Spårad som CVE-2025-30065, har bristen fått den högsta möjliga CVSS-poängen på 10.0, vilket indikerar en maximal allvarlighetsgrad för fjärrkodexekvering (RCE).
Apache Parquet är en kärnkomponent i många moderna dataarkitekturer, som används över plattformar som Hadoop, AWS, Google Cloud, Microsoft Azure och nästan alla större ETL- och datalake-plattformar. Stora företag inklusive Netflix, Uber, Airbnb och LinkedIn förlitar sig på det för att lagra och bearbeta stora mängder strukturerad data.
Sårbarheten påverkar alla versioner av Apache Parquet upp till och med 1.15.0, och den offentliggjordes den 1 april 2025, ett datum som tyvärr kunde ha fått vissa att avfärda det som ett skämt. Men det finns inget humoristiskt med denna brist. I grund och botten handlar problemet om osäker deserialisering av opålitlig data. Angripare kan skapa skadliga Parquet-filer som, när de importeras, tillåter dem att köra godtycklig kod på målsystemet. Att utnyttja detta skulle kräva att övertyga någon att ladda den skadliga filen i ett system eller pipeline som stöder Parquet, en attackvektor som, även om den är indirekt, är mycket inom räckhåll i verkliga scenarier.
Sårbarheten har åtgärdats i Parquet version 1.15.1, och organisationer uppmanas att uppdatera omedelbart.
Varför det är viktigt
En CVSS 10.0 är sällsynt och bör aldrig tas lättvindigt. Denna sårbarhet understryker hur riskfyllda opålitliga dataimporter kan vara, särskilt i datadrivna miljöer där filbaserad automation är rutin och ofta saknar djup inspektion. Apache Parquets utbredda användning över kritiska analysplattformar innebär att många organisationer kan vara sårbara utan att ens inse det, särskilt om de förlitar sig på tredjepartsdataflöden eller tillåter externa filuppladdningar i analytiska system.
På Sidia Tech rekommenderar vi omedelbar granskning av alla system som hanterar Parquet-filer, särskilt pipelines som tar emot data från externa källor. Om uppgradering till version 1.15.1 inte är omedelbart möjligt, bör team:
- Undvika att importera några overifierade eller externt källade Parquet-filer
- Implementera strikt validering och sandboxing för alla Parquet-bearbetningsuppgifter
- Öka övervakning och loggning för system som hanterar Parquet-data
- Informera utvecklingsteam om riskerna med denna sårbarhet i test- och produktionsmiljöer
Även om det inte finns några rapporter om aktivt utnyttjande ännu, visar historien att sårbarheter med denna nivå av allvarlighet och denna nivå av antagande så småningom kommer att riktas in. Tiden att agera är nu, innan en opportunistisk angripare slår till.
