Er zijn veel verschillende types security updates in Android:
- Android Security Bulletins: dit is voor kwetsbaarheden in Android zelf, maar alleen voor kwetsbaarheden die als high en critical gemarkeerd zijn. Dus ASBs alleen zijn niet genoeg om alle Android security updates te krijgen. Binnen ASBs zijn er nog twee groepen op te delen:
- Projecten/leveranciers die ook fixes uitbrengen die drie maanden onder embargo zijn: GrapheneOS rolt alle embargoed fixes uit. Samsung een deel, Google Pixel een deel of alles (is me nooit helemaal duidelijk).
- Projecten/leveranciers die geen fixes uitbrengen die onder embargo vallen. Deze toestellen zijn dus in zekere mate al 3 maanden kwetsbaar omdat de kwetsbaarheden al lekken, bijv. door reverse engineering van GrapheneOS/Samsung/Pixels updates of door informatie die van OEMs lekt. Alle organisaties die niet in het vorige punt genoemd zijn vallen hier onder.
- Android security fixes voor kwetsbaarheden die niet high/critical gemarkeerd zijn. In deze categorie zitten geen RCEs, maar ze worden wel gebruikt in exploit chains. Deze fixes krijg je alleen met major releases en QPRs. Daarom is het ook vrij kwalijk dat de meeste Android-leveranciers zo laat zijn met major releases. Het gaat niet zozeer om features, maar om de security fixes. Hier ziet het er ongeveer als volgt uit: Pixel rolt alle QPRs en majors uit, GrapheneOS rolt majors en QPR2 meestal enkele dagen na Google/Pixel uit (QPR1/3 kan niet omdat Google die niet meer open sourced), Samsung rolt major en QPR2 uit, maar vaak met enkele weken tot maanden vertraging. Bij de rest mag je blij zijn zelfs majors niet maanden te laat zijn, laat staan dat ze QPRs uit zouden rollen.
- Project Mainline (Google Play System Updates). De OEM-update situatie is in zo'n deplorabele staat dat Google op een gegeven moment het heft in eigen wou nemen. Dit doen ze door bepaalde delen van het systeem als modules te verpakken, waarbij ze dan als een soort van overlay bestaande functionaliteit kunnen updaten. Hier zitten zowel functionele nieuwe features in als heel erg acute kwetsbaarheden in componenten die mainline kan updaten (bijvoorbeeld Bluetooth, UWB). Helaas missen degoogled projecten als /e/OS en GrapheneOS deze updates volledig. Of dat een probleem is ligt eraan hoe snel je ASBs en majors/QPRs uitrolt.
- Driver firmware. Dit is de software waarop belangrijke onderdelen van de telefoon draait, zoals het modem, WiFi, Bluetooth, cameras, noem het maar op. Sommige blobs zijn praktisch een OS op zichzelf (zoals cellular broadband firmware die op een eigen processor een RTOS draait). Omdat het hier vaak gaat om hardware die data verwerken die niet te vertrouwen is, is veiligheid erg belangrijk. In welke mate dit belangrijk is, hangt er vanaf in welke mate de firmware geïsoleerd is (kan ook bij geheugen van het main OS, etc.). Pixel/GrapheneOS en iPhone hebben altijd sterk ingezet op isolatie. Deze firmware wordt geleverd door de maker van de hardware (bijv Qualcomm, Mediatek, Sony/Samsung for camera's, etc.), maar verspreid door de OEM. Dus als Volla de firmware nooit update, dan krijgt /e/OS de security updates ook niet, het leveren van de firmware is op basis van een contract dat Volla's ODM heeft met bijv. Mediatek. En ze zijn wel degelijk belangrijk, want bijv. Qualcomm/Mediatek/Samsung firmware heeft maandelijks kritische kwetsbaarheden. Eigenlijk alleen Google Pixel, GrapheneOS en Samsung zitten hier bovenop en rollen maandelijks updates uit. Fairphone doet dit bijv. veel minder vaak (bijv. met major releases). Volle vrijwel nooit.
- De Linux kernel + drivers. Dit is de kern van het systeem + drivers voor verschillende devices. Hier is het huilen met de pet op. Volgens mij doen alleen Google Pixel en GrapheneOS regelmatig kernel updates, zelfs Samsung zit vaak op oude versies. Maar een kernel-kwetsbaarheid kan genoeg zijn voor een app om uit de SELinux sandbox te krijgen. Vergelijkbaar met driver firmware geldt: dit moet over het algemeen van de OEM komen. Ze vallen niet onder ASBs, dus Ubuntu Touch, /e/OS e.d. zullen dezelfde oude kernel trees gebruiken.
Conclusie: nee, de maandelijkse updates zijn bij lange na niet genoeg. De maandelijkse updates dekken alleen de eerste categorie af en major updates de tweede categorie.
Is dit belangrijk? Daar moet iedereen zijn eigen inschatting maken. Android botnets zijn een ding. Android malware bestaat. Het zal het komende jaar allemaal erger worden door LLMs, de laatste ASB had meer dan 100 fixes voor kwetsbaarheden. De vermoedelijk honderden kwetsbaarheden die niet critical/high gemarkeerd of de honderden kwetsbaarheden in firmware en Linux zijn hierin nog niet meegenomen.
Als je je telefoon alleen gebruikt om een beetje te bellen en wat spelletjes te doen, kan ik me voorstellen dat je denkt 'soit'. Als je voor een waardevol bedrijf werkt, waar een aanvaller met laterale aanvallen op een privételefoon door kan lopen op bedrijfsnetwerken, neem een telefoon met GrapheneOS, iOS, Pixel of heel misschien een Samsung flagship (in die volgorde). De rest is gewoon niet veilig genoeg, zowel door het gebrek aan veiligheidsupdates, alsook het ontbreken van een aparte secure processor om geheim materiaal op te slaan.
Om een voorbeeld te geven waarom ASBs alleen niet genoeg zijn: veel Android toestellen waren onlangs zero click te hacken tot root aan toe door een combinatie van een kwetsbaarheid in WeChat (simpelweg bellen was genoeg, de gebruiker hoefde het belletje niet op te nemen) en kwetsbaarheden in de OEM drivers.
https://calif.io/research/weworm
https://calif.io/research/oempocalypse
Ander voorbeeld, veel apparaten met een MediaTek SoC waren voor de eerste unlock binnen 60 seconden uit te lezen met een USB kabeltje, ondanks encryptie (voorbeeld waarom zowel firmware updates als een aparte secure processor belangrijk zijn):
https://www.malwarebytes.com/blog/news/2026/03/this-android-vulnerability-can-break-your-lock-screen-in-under-60-seconds
Excuses voor het lange antwoord. Hier zijn geen LLMs aan te pas gekomen

, ik heb een hekel aan LLM-geschreven teksten.
[
Voor 7% gewijzigd door
nonagoninf op 12-09-2026 14:42
]