Twee heel verschillende risico’s domineren het nieuws van de afgelopen dag. Apple bracht een noodpatch uit voor een zero-day in de CoreGraphics-component van iOS en macOS die al is ingezet in een uiterst geavanceerde aanval op specifieke individuen – het type aanval dat doorgaans met commerciële spyware wordt geassocieerd. Onderzoeksbureau UpGuard ontdekte tegelijk een veel breder probleem: meer dan 16.000 Supabase-databases blijken gevoelige gegevens vrij toegankelijk te hebben staan, vaak in apps die met behulp van AI-codeeragenten in elkaar zijn gezet zonder dat de basale toegangsbeveiliging goed werd ingesteld.
- Apple patcht CoreGraphics-zero-day die al is misbruikt in gerichte aanval op specifieke personen
- Meer dan 16.000 Supabase-databases blijken gevoelige data vrij toegankelijk te hebben staan
Apple patcht CoreGraphics-zero-day die al is misbruikt in gerichte aanval op specifieke personen
| Kwetsbaarheid | Out-of-bounds write in de CoreGraphics-component, waarmee verwerking van geprepareerde content tot willekeurige code-uitvoering kan leiden – iOS en iPadOS (iPhone 11 en later, diverse iPad-modellen), macOS Tahoe en macOS Sequoia |
| CVE-nummer | CVE-2026-86950 |
| CVSS-score | Niet door Apple bekendgemaakt |
| Actief misbruikt | Mogelijk, in een door Apple als “extreem geavanceerd” omschreven aanval tegen specifieke, individueel geselecteerde personen |
| Patch beschikbaar | Ja, sinds 28 september 2026 (iOS/iPadOS 26.7.1, macOS Tahoe 26.7.1, macOS Sequoia 15.8.1) |
Hoe wordt de kwetsbaarheid misbruikt?
CoreGraphics is het onderliggende raamwerk waarmee vrijwel elke iOS- en macOS-app afbeeldingen, PDF’s en andere visuele content verwerkt en weergeeft. Een fout in die verwerking laat, bij het openen van geprepareerde content, een schrijfactie buiten de bedoelde geheugengrenzen toe, wat kan uitlopen op willekeurige code-uitvoering. Apple meldt te weten van een rapport dat het lek al is misbruikt in een uiterst geavanceerde aanval tegen specifiek geselecteerde individuen, zonder verder detail te geven over het aantal getroffen personen of de exacte aanvalsmethode. Dat patroon – een technisch summiere melding gecombineerd met de term “specifiek geselecteerde individuen” – komt overeen met eerdere zero-days die zijn ingezet door leveranciers van commerciële spyware.
Wat kan het gevolg zijn?
Dit soort gerichte zero-days treft doorgaans een klein aantal, zorgvuldig geselecteerde slachtoffers zoals journalisten, mensenrechtenactivisten, bestuurders of medewerkers met een diplomatieke of politieke functie, en niet de bredere gebruikersgroep. Toch is de geschiedenis van dit soort lekken dat aanvalsdetails na verloop van tijd breder bekend raken, waarna ook minder gerichte actoren ze kunnen inzetten. Voor organisaties met bestuurders, juristen of andere functies met een verhoogd risicoprofiel in de iOS- of macOS-vloot is dit lek daarom relevanter dan voor de gemiddelde gebruiker.
Wat moeten IT-beheerders nu doen?
Update iPhones, iPad’s en Macs naar respectievelijk iOS/iPadOS 26.7.1, macOS Tahoe 26.7.1 of macOS Sequoia 15.8.1. Geef daarbij voorrang aan toestellen van bestuurders en andere functies met een verhoogd risicoprofiel, en wijs gebruikers in die groep erop dat ze extra alert moeten zijn op ongevraagd toegestuurde bestanden of links, ook al is over de exacte verspreidingsmethode niets bekendgemaakt.
Meer dan 16.000 Supabase-databases blijken gevoelige data vrij toegankelijk te hebben staan
| Kwetsbaarheid | Geen lek in het Supabase-platform zelf, maar op grote schaal ontbrekende of onvolledige Row Level Security-policies in combinatie met het gebruik van de publieke (“anon”) API-sleutel als enige toegangsbeveiliging, waardoor databasetabellen met gevoelige gegevens rechtstreeks vanaf het internet uitleesbaar zijn – apps gebouwd op het Supabase-platform, veelal met hulp van AI-codeeragenten |
| CVE-nummer | Niet toegekend – het betreft configuratiefouten per app, geen kwetsbaarheid in Supabase zelf |
| Actief misbruikt | Geen aanwijzingen voor gericht misbruik bekend, maar de data stond wel voor iedereen met de publieke sleutel direct opvraagbaar |
| Patch beschikbaar | Niet van toepassing; herstel ligt bij de bouwer van elke afzonderlijke app, door Row Level Security correct in te stellen |
Hoe kon dit zo mis gaan?
Supabase is een populair open source-platform waarmee ontwikkelaars snel een backend op basis van PostgreSQL kunnen opzetten, inclusief authenticatie en een direct vanuit de frontend aanroepbare database-API. Beveiliging van die API loopt via Row Level Security-policies, die precies moeten vastleggen welke gebruiker welke rijen in een tabel mag lezen of wijzigen. Onderzoeksbureau UpGuard onderzocht ongeveer 300.000 domeinen met Supabase-kenmerken en trof 16.326 databases aan waar dit niet goed was geregeld: tabellen zonder enige policy, tabellen met te losse policies, of ontwikkelaars die de publieke “anon”-sleutel behandelden als was die geheim, terwijl die sleutel juist bedoeld is om vrij in frontend-code te staan. Supabase’s eigen Table Editor schakelt Row Level Security standaard in, maar tabellen die via de API of migraties worden aangemaakt – zoals AI-codeeragenten dat vaak doen – krijgen die bescherming niet automatisch. Onder de gevonden voorbeelden: een Indiase dienstverlener met 65.000 personen aan rijbewijs- en paspoortnummers, financiële gegevens en ruim 100.000 privéberichten vrij toegankelijk, een Filipijnse OTP-dienst met ruim 100.000 sms-berichten inclusief privégesprekken van niet-betrokken chauffeurs, en een Afrikaans consulaat met adressen en noodhuisvestigingslocaties van 25.000 mensen.
Wat kan het gevolg zijn?
Meer dan de helft van de blootgestelde databases bevatte volgens UpGuard herkenbare persoonsgegevens, met in een deel van de gevallen ook financiële data. Het onderzoeksbureau trekt de vergelijking met eerdere golven van massale datalekken door verkeerd geconfigureerde Amazon S3-buckets en per ongeluk gepubliceerde GitHub-repository’s: telkens een populaire, laagdrempelige technologie waarvan de beveiligingsinstellingen niet vanzelfsprekend goed staan. De opkomst van AI-codeeragenten die snel werkende applicaties opleveren zonder dat de bouwer databasebeveiliging begrijpt, vergroot dit risico volgens UpGuard verder. Voor MSP’s die klanten met zelf- of AI-gebouwde webapplicaties ondersteunen of beheren, is dit een reëel risico dat niet in een klassieke CVE-scan naar boven komt.
Wat moeten IT-beheerders nu doen?
Ga voor elke klant of interne applicatie die op Supabase draait na of Row Level Security op alle tabellen actief staat, inclusief tabellen die buiten de Table Editor zijn aangemaakt. Controleer of de service-role-sleutel, die alle beveiliging omzeilt, nergens in frontend-code of publiek toegankelijke bestanden terechtkomt, en test of de publieke “anon”-sleutel daadwerkelijk alleen toegang geeft tot data die ook echt openbaar mag zijn. Behandel dit met dezelfde aandacht als een S3-bucketaudit, zeker bij applicaties die met AI-codeeragenten zijn gebouwd, en wijs klanten die zelf dit soort apps laten bouwen op het risico dat gemak bij het bouwen niet gelijk staat aan een veilige standaardconfiguratie.
