Google: Pixel-eigenaren zijn aangevallen via lek in modem

Eigenaren van Google Pixel-telefoons zijn de afgelopen tijd aangevallen via een lek in het modem van de soc. Dat zegt Google. Volgens het bedrijf troffen de aanvallen een beperkt aantal klanten. De update van deze maand dicht het lek.

Google zegt dat het gaat om aanvallen die gebruikmaken van de kwetsbaarheid CVE-2026-58.704. Voor deze exploit hoeven gebruikers van Pixel-telefoons niet op een link te klikken of een bestand te openen. Door een 'logic error' in de code kan een aanvaller toegang krijgen tot het modem en later tot bestanden op de telefoon.

De Amerikaanse Cybersecurity and Infrastructure Security Agency (CISA) waarschuwt bedrijven dat dit lek ook hen kan treffen. Het agentschap adviseert om de update van september zo snel mogelijk op alle apparaten door te voeren.

Het is onbekend welke Pixel-apparaten kwetsbaar zijn voor dit lek. Het modem in elke soc verschilt, maar de modems kwamen de afgelopen jaren wel telkens uit dezelfde productlijn van dezelfde fabrikant, namelijk Samsung. De Pixel 11-toestellen kregen een MediaTek-modem.

Reacties (65)

[ndonkersloot]

Voor mensen het vragen, dit is ook relevant voor GrapheneOS.

It's included in the Pixel Update Bulletin for September 2026 released on 2026-09-15 and will be included in the upcoming release of GrapheneOS.

It's taking longer than usual due to the Pixel OS release being Android 17 QPR1. QPR1 and QPR3 releases currently aren't pushed to AOSP so we need to backport the firmware, drivers and HALs to Android 17 from Android 17 QPR1. Only the yearly and QPR2 releases are currently pushed to AOSP.

We completed a port to Android 17 QPR1 in advance but we lack permission to release it unless they push it to AOSP. Instead of releasing an already completed port to Android 17 QPR1, we have to do backports instead which can be quite problematic.

[Reactie gewijzigd door ndonkersloot op 17 september 2026 14:19]

[De Vliegmieren]

typisch - bij iedere post die ik plaats over het probleem van vendor driver blobs voor de radios (5g/4g/3g, wifi, bluetooth) en dat GrapheneOS daar niet immuun voor is, wordt de post of naar beneden gemod en/of wordt er geclaimt dat GrapheneOS daar wel immuun voor is.

[Aftansert]

Dat komt omdat je comment in het andere topic van het type "just asking questions" is: saai en met lage informatiedichtheid, wat terecht geïrriteerde reacties oproept. Net zoals je post nu (en mijn alinea hier) alleen maar op meta-niveau klaagt en weinig toevoegt aan de discussie. Probeer je iets nieuwsgieriger op te stellen.

Security is niet zo zwart-wit. Graphene OS is zeker afhankelijk van de veiligheid van modem firmware, maar zet deze wel in een sandbox en voegt allerlei andere features toe die het over het algemeen veel moeilijker maken om een volledige exploit chain te realiseren. Het zou dus goed zo kunnen zijn dat deze CVE niet (op dezelfde manier) te exploiteren is op Graphene OS, ondanks dat de vulnerability er wel in zit en je deze alsnog zo snel mogelijk wil patchen. Aangezien Google geen details vrijgeeft omdat deze nog niet overal is gepatched, valt daar nu nog weinig over te zeggen.

[Reactie gewijzigd door Aftansert op 17 september 2026 15:16]

[De Vliegmieren]

alleen de firmware zit in een sandbox, niet de rest van de driver.

Niet iedereen vindt bescherming tegen bugs in 3rd party driver blobs saai - dat is enkel jouw interpetatie imo

[Reactie gewijzigd door De Vliegmieren op 17 september 2026 16:31]

[danieldk]

In dit geval gaat het om firmware: https://grapheneos.social/@GrapheneOS/117280746681197709

Zoals gezegd, het is nog helemaal niet duidelijk of deze kwetsbaarheid in GrapheneOS omgezet kan worden in een export chain.

Uiteindelijk gaat veiligheid om defense in depth. Uiteraard kan een firmware een kwetsbaarheid hebben, maar als de firmware vervolgens gesandboxed is, moet je ook een kwetsbaarheid in de sandbox hebben. Als je het persistent tegen reboots wil maken, moet je ook bijv. een kwetsbaarheid in secure boot hebben. Het punt van GrapheneOS is niet zozeer dat code nooit een kwetsbaarheid heeft. Maar als er een kans is van P(bekende kwetsbaarheid in modem firmware)=0.1 en P(bekende kwetsbaarheid in modem firmware sandbox)=0.1, dan heeft die hardening de kans dat je door kan escaleren via een modem verkleint van 0.1 naar 0.01. Dat is een principe achter veel technieken in GrapheneOS. Zoveel mogelijk MTE uitrollen maken veel geheugenkwetbaarheden een crash, idem ditto voor een secure allocator en zo kunnen we nog wel even doorgaan.

Het volgende plaatje uit Apple's documentatie over MIE legt het perfect uit:

https://security.apple.com/assets/image/generated/xlarge_advanced-memory-integrity-light.png

Dit is ook de reden waarom GrapeneOS een lijst van toestel-eisen heeft en ze ondanks het vele aandringen van mensen, ze bijv. geen Fairphone gaan ondersteunen. Defense in depth vereist dat je alles doet: up-to-date firmware, up-to-date OS, memory tagging, secure processor, firmware die sandboxing ondersteunt, etc. Fairphone e.a. kunnen dit niet bieden. Toestellen worden vaak gecomprommiteerd met exploit chains en hoe meer mitigaties je hebt, hoe groter de kans dat de exploit chain ergens geblokkeerd wordt.

alleen de firmware zit in een sandbox, niet de rest van de driver.

Nog even een opmerking hierover: dit is één van de redenen waarom het GrapheneOS vaak kritisch is op de Linux kernel. Met de huidige stroom van LLM exploits zal er wel meer motivate zijn drivers in Rust te schrijven en hopelijk meer isolatie toe te gaan passen. In principe kun je dit ook in betaalde mate doen met virtualisatie, bijv. door een aparte kernel te draaien met device drivers. Leden van het GrapheneOS project hebben hier ook wel over gespeculeerd, maar het staat of valt met mankracht. Een goede reden om to doneren zodat ze meer medewerkers in dienst kunnen nemen.

[Reactie gewijzigd door danieldk op 17 september 2026 20:47]

[astro_volt]

Perfecte uitleg, ik had het zelf niet beter kunnen verwoorden.
Het leunen op meerdere scala van exploit protection leveren met elkaar een sterke bescherming, zodat als 1 ding omvalt niet meteen de rest van de OS is overgeleverd aan de exploiter.

Natuurlijk betekent dit dat een belangrijk onderdeel is omgevallen, en daarom ook dat GrapheneOS dit zo snel mogelijk wil patchen om weer de volledige bescherming van die laag te herstellen.

[Aftansert]

offtopic:
Dat is niet wat ik zei. Niet het onderwerp / de bescherming is saai: je manier van communiceren is saai. Je doet geen enkele moeite en draagt wederom niet bij aan de discussie of een goede weergave van kennis (die heel interessant kan zijn), en laat het bij een zeer kort hoofdletterloos zinnetje bovenin.

Ik heb in m'n vorige comment iets bij proberen te dragen. Ik laat het nu zelf even bij een saaie comment.

[Reactie gewijzigd door Aftansert op 17 september 2026 18:21]

[flaskk]

Het agentschap adviseert om de update van september zo snel mogelijk op alle apparaten door te voeren.

Wanneer komt die update uit in Nederland? Want mijn 9xl heeft nog augustus en staat niks klaar..

Edit: na paar keer op de knop drukken "controleren op updates" heeft ie m

[Reactie gewijzigd door flaskk op 17 september 2026 14:09]

[RalphM.]

Ik heb op mijn 8 pro hem gisteren geïnstalleerd. Maar soms moet je eerst alle apps (iig device policy) en de Google services updaten voor je hem te zien krijgt na een reboot.

[Reactie gewijzigd door RalphM. op 17 september 2026 14:02]

[IJsbeer]

Voor de 8a is hij er al wel, zal dus wel eerdaags zijn.

Wat ik mis: Mooi dat het lek wordt gedicht, maar hoe kom ik erachter of er al wat op mijn telefoon draait wat daar niet hoort (cq ik dus al getroffen ben door dit lek)? En wordt dat ook weggehaald (zal wel niet, want natuurlijk niet bepalen door Google)

[Fly-guy]

Blijkbaar vandaag want ik heb 'm net geïnstalleerd.

[unilizer]

Ik heb een pixel 6 Pro en heb gisteren al de update gekregen. Het kan wel zijn dat je manueel eens moet controleren op updates, waarschijnlijk fased roll-out. De update is pas recent released: September 2026 Pixel Drop

[desalniettemin]

Ik kreeg hem dinsdag op mijn Pixel 6.

[erikieperikie]

Inderdaad: handmatig controleren op updates geeft de check een hogere prioriteit ofzo, dus daarmee kun je de wachtlijst o.i.d. overslaan.

[Wouterie]

Gisteravond bij de telefoon van mijn vrouw.

[chris_0611]

Pijnlijk. Ik dacht dat Pixels juist extra veilig waren door extra security hardware enzo. Weet iemand of grapheneOS hier ook door getroffen is? Dit lek zit dan vast in de proprietary/binary blob firmware van het modem...

[tweak_dude]

Of het lek in een binary blob zit weet ik niet maar GrapheneOS is nog niet gepatched, zie dit bericht.

[danieldk]

Pijnlijk. Ik dacht dat Pixels juist extra veilig waren door extra security hardware enzo.

Pixels zijn nog steeds extra veilig. Dankzij Titan M zal het zelfs met deze kwetsbaarheid (vrijwel) onmogelijk zijn om private key material uit de Titan M te halen. Als het een telefoon zonder secure processor was geweest, was dat veel makkelijker geweest via side-channel attacks.

Ook is het lastiger malware persistent te maken, want wijzigingen aan het systeem worden gedetecteerd omdat Pixel een correcte, volledige secure boot chain heeft.

Desalniettemin blijven dit soort kwetsbaarheden pijnlijk.

[Yngwie-]

Geen automatisch updatebericht op mijn 11 Pro, handmatig controleren levert wel een update op, maar daar wordt niet gesproken over een modem of security aanpassen. Wel: "Pas je Pixel direct aan met Harry Potter-audioboekpakketten"

[anne1407]

11 hier. Welke update kreeg jij net? Die van 1 september?

[Yngwie-]

5 september, CP3A.260905.009

[anne1407]

Weet je zeker dat je een Pixel 11 Pro hebt? Google vermeldt CP3A.260905.009 alleen voor Pixel 6 t/m 10a. Mijn Pixel 11 zit op CD1A.260905.001.B1, wat voor zover ik kan vinden de actuele 11-serie-build is. Dus ik ben echt heel benieuwd hoe dat dan kan.

Link naar Google

[Yngwie-]

Waah, je hebt gelijk, typefout. Gaat om een 10 Pro

[anne1407]

Ah dan weet ik dat ik niks gemist heb.

[anne1407]

Hier nog steeds niks, ook niet handmatig.

[dnat]

Gaan ze deze security update/bugfix dan ook nog op de 6 pro en none pro duwen, want laat deze nu net uit support gegaan zijn...

ook niet handig dat ze niet vermelden welk type, kwestie van gewisse-ongewisse

[desalniettemin]

Pixel 6 oktober de laatste keer. Ik heb deze update dinsdag geinstalleerd. Net ook googleplay systeemupdate geinstalleerd. Even herstarten.

[Reactie gewijzigd door desalniettemin op 17 september 2026 14:14]

[Cartman!]

Wel erg karig bericht van Google, ik zou op zn minst een lijst van toestellen verwachten waar dit op van toepassing is en idealiter ook iets van een methode om te checken of je bij die gebruikers zit die getroffen zijn.

[William_H]

Precies. Hier ben ik ook wel benieuwd naar.
@arnoudwokke Is hierover nog iets bekend? Staat die vraag uit bij Google NL?

[John Doos]

Pixel 10 had gisteren avond rond 22.30 een update klaar staan hiervoor.


Werd niks hierover genoemd, enkel pixel VIP goodies etc.

[Insomnia1988]

Hopelijk komt deze fix ook snel voor GrapheneOS uit

[phpnuker]

Update van 1.5 gb op mijn pixel8 . Het is groot bestand vergeleken met de patches van 50 mb.

[anne1407]

Pixel 11 maar ik heb nog niks. Het is me niet helemaal duidelijk of de 11 erbuiten valt of dat ik ook ergens een update moet krijgen nog.

[William_H]

De 11 serie heeft een ander type modem, en is dus niet gevoelig voor dit lek.

[anne1407]

Is bevestigd dat die er inderdaad buiten vallen? Dat kan ik (nog) nergens vinden.