Op 17 oktober 2026 meldde een onderzoeker aan het Chrome Root Program dat een aantal tussenliggende certificaatautoriteiten van eMudhra hun keys aangemaakt had met te weinig willekeur. De private keys kan je afleiden uit de publieke certificaten. Wie dat doet, kan een certificaat maken voor eender welk domein, ook voor je API, en software zonder update aanvaardt dat als geldig.
Browsers waren snel gefixt. Chrome blokkeerde de certificaten dezelfde avond nog, en Android kreeg de blokkering twee dagen later via Google Play Services. Ook Apple blokkeerde ze op zijn platformen. Maar veel software vraagt niet aan de browser of het besturingssysteem of een certificaat te vertrouwen is. Die draagt een eigen lijst mee, en die lijst verandert pas als iemand ze bijwerkt of opnieuw bouwt.
Hieronder staat wat we gecheckt hebben voor de apps van onze klanten en voor onze eigen servers, zodat je hetzelfde kan doen.
Wat er echt kan gebeuren
Iemand die het netwerk tussen je app en je API controleert, kan een vervalst certificaat tonen voor het domein van je API. Een app die de gelekte certificaten nog vertrouwt, aanvaardt dat zonder enige waarschuwing. De aanvaller stuurt het verkeer door naar de echte server, dus de app blijft gewoon werken, terwijl logins, tokens en klantgegevens door zijn handen passeren.
Controle over het netwerk klinkt moeilijk, maar een valse hotspot op een beurs, in een station of in een magazijn is genoeg. Daarom is dit vooral belangrijk voor mobiele apps, en minder voor servers in een datacenter.
Wie is geraakt
| Software | Geraakt? | Wat te doen |
|---|---|---|
| Chrome, Firefox, Safari, Edge | Nee, binnen enkele dagen geblokkeerd | Niets |
| Native iOS- en macOS-apps | Nee, geblokkeerd door Apple | Niets |
| Native Android-apps | Nee, update van Play Services op 19 oktober | Niets |
| Flutter-apps op iOS, macOS en web | Nee | Niets |
| Flutter-apps op Android en Windows | Ja, tot ze opnieuw gebouwd zijn | Opnieuw bouwen op Flutter 3.47.8 / Dart 3.13.7 of later en releasen |
| Flutter op Linux | Hangt af van de certificaatlijst van het systeem | Het pakket ca-certificates updaten |
| Node.js | Oudere versies | 22.23.4, 24.22.1, 26.12.1 of later |
Python met certifi | Oudere versies | certifi 2026.10.19 of later |
| Docker-images en Linux-servers | Als ze gebouwd of geüpdatet zijn vóór ongeveer 20 oktober | Opnieuw bouwen met security-updates |
Voor containers telt de certificaatlijst in de image, en die ligt vast op het moment dat de image gebouwd werd. Alpine, Ubuntu en Debian 12 en 13 brachten tussen 20 en 21 oktober allemaal bijgewerkte ca-certificates-pakketten uit, dus een rebuild die security-updates installeert, pikt ze op.
Eén detail maakt dit lastiger dan gewoon een rootcertificaat verwijderen. De gelekte tussenliggende certificaten waren ook gecross-signed door een oudere root van Sectigo, AAA Certificate Services, die nog in veel certificaatbundels zit. Enkel de root van eMudhra verwijderen is niet genoeg: ofwel moet die oudere root ook weg, zoals in de update van Debian, ofwel worden de tussenliggende certificaten rechtstreeks geblokkeerd, zoals in de Flutter-fix.
Zo check je je app
Stel wie je app bouwt twee vragen:
- Op welke Flutter-versie is de laatste Android- en Windows-release gebouwd?
- Als die ouder is dan 3.47.8: wanneer gaat de nieuwe build uit?
Krijg je een versienummer en een datum als antwoord, dan zit je goed. Zodra de nieuwe build live staat, zorgt een hogere minimale appversie ervoor dat niemand de oude blijft gebruiken.
Er is ook een goed neveneffect. Op Android 14 en hoger laden apps die op de gefixte Flutter-versie gebouwd zijn hun vertrouwde rootcertificaten uit een deel van Android dat Google bijwerkt via Play-systeemupdates. Als er nog eens zoiets gebeurt, pikken die apps wijzigingen aan rootcertificaten op zonder nieuwe build.