Direct naar de inhoud
Beveiligingsnieuws

Grok-built apps blootgesteld: 35.578 open apps

Grok-built apps blootgesteld

Grok-built apps blootgesteld aan het internet: dat is de kern van een recente ontdekking door Claroc. Van de 37.571 Grok-built applicaties die de onderzoekers online vonden, waren er 35.578 toegankelijk voor iedereen zonder in te loggen. Daarbij ging het niet alleen om spelletjes en rekenhulpen, maar ook om apps met interne bedrijfs- en persoonlijke informatie.

In sommige gevallen zat die informatie zó vergaand dat de onderzoekers expliciet spreken over serieus risico. Ze rapporteerden bovendien dat er zelfs scenario’s waren waarin wachtwoorden in platte tekst in app-data konden voorkomen.

35.578 Grok-built apps zonder inlog

Claroc telde 37.571 Grok-built apps die online terug te vinden waren. Van dat totaal waren 35.578 apps benaderbaar zonder sign-in. Het merendeel betrof relatief onschuldige toepassingen, zoals games, landing pages en calculators.

Toch zat in ongeveer 1 op de 10 open apps interne data of persoonlijke informatie. Dat maakte de impact groter dan alleen ‘privacy-issues’ op het oppervlak.

Welke gevoelige data werd gevonden?

Volgens de onderzoekers zat er bij een deel van de open apps materiaal dat volgens hun inschatting als high of critical te classificeren is. Grofweg gaat het om ongeveer 2% van de open apps, maar juist die groep is het meest zorgwekkend.

De onderzoekers noemen voorbeelden zoals:

  • Een doorzoekbare lijst met meer dan 3.500 medewerkers van een ziekenhuisgroep.
  • Een intensive care-briefing over één specifieke patiënt.
  • Een live shift board van een brandweerorganisatie.
  • Een contractorsysteem waarvan de code elke medewerkerwachtwoord in platte tekst bevatte.

Apps van medewerkers: deels direct al verwijderd

Een deel van de blootgestelde apps werd gemaakt door medewerkers. De onderzoekers noemen daarbij 24 apps die door personeel zijn gebouwd bij het sociale netwerk X en bij SpaceXSI, het bedrijf dat de Grok AI-assistent ontwikkelt.

SpaceXSI zou inmiddels alle 24 medewerker-apps hebben verwijderd. Dat neemt het bredere probleem niet weg: de onderzoekers stellen dat andere gebruikers-apps niet automatisch werden teruggetrokken.

Daarnaast identificeren de onderzoekers dat de open apps interne data konden bevatten van 30 andere organisaties. Ze noemen sectoren variërend van bouw en energie tot zorg en defensie. Binnen die groep waren er meerdere organisaties met grote personeelsomvang, waaronder Fortune 500-bedrijven.

Hoe kan een app toch openbaar lijken?

Grok kan, volgens de bron, een werkende app bouwen op basis van een beschrijving in chat. Die functie werd geopend voor alle Grok-plannen rond 19 augustus. Elke gepubliceerde app krijgt een eigen subdomain op grok.me, en de maker kiest vervolgens wie de app kan openen.

Belangrijk detail: een app wordt niet ‘publiek’ totdat de maker op Publish klikt. In de betaalde account die de onderzoekers gebruikten, kregen ze bij publicatie drie toegangsopties:

  • Anyone with the link
  • Invited users
  • Only you

De onderzoekers stellen dat de setting ertoe doet, omdat het adres niet echt geheim blijft. Als iemand een app opent, doet de browser een DNS-lookup van het subdomain. Leveranciers van passive DNS slaan dit soort lookup-gegevens op. Met een account kun je die records doorzoeken op patronen.

Daar komt bij dat Grok suggesties geeft voor namen met random woorden. Dat maakt gokken soms lastiger, maar het voorkomt niet dat subdomains toch worden gevonden via ontdekkingstechnieken en DNS-gegevens.

Testen met toegangsinstellingen: toegang bleek soms mogelijk

Om te begrijpen hoe Grok zelf de toegang afbakent, bouwden de onderzoekers twee testapps met nepdata. Ze publiceerden die apps met de setting die in hun context al geselecteerd stond: Anyone with the link. Daarna testten ze wat er gebeurde zonder in te loggen.

In de eerste test, een contactlijst, bleek dat er wel data in de app beschikbaar was zonder sign-in. In het scenario erna konden de onderzoekers vanuit een private browser een extra rij toevoegen vanuit een privévenster, waarna een volgende bezoeker die informatie alsnog zag.

In de tweede test, een klantlijst voor een team van vier personen, voegde Grok volgens de onderzoekers juist wél een sign-in flow toe met knoppen zoals Continue with Google en Continue with X. Alleen: de check op wie toegang hoort te krijgen werkte volgens hun test niet goed. Daardoor kon een niet-gerechtigde Google-account binnenkomen, de volledige lijst bekijken en records aanpassen en verwijderen.

Let op: de onderzoekers geven aan dat ze dit alleen op eigen testapps hebben gedaan. Ze hebben niet vastgesteld of de open apps die ze in de echte wereld vonden zich precies op dezelfde manier gedroegen.

Wat kun je als organisatie nu doen?

Claroc, dat tools verkoopt om AI-apps te vinden en te beveiligen, adviseert organisaties om gestructureerd te checken welke AI app builders medewerkers gebruiken. Volgens de aanpak zijn er een paar praktische stappen:

  • Inventariseer welke AI-app builders je team gebruikt. Er worden voorbeelden genoemd zoals Grok, Lovable, Replit, v0, Bolt, Base44 en Google AI Studio.
  • Beschik je over passive DNS-data? Zoek dan op de domeinen van de betreffende builders en open de resultaten in een private browser.
  • Controleer of een Grok-app met interne data staat op Invited users of Only you. In een veilig scenario ziet een onbekende bezoeker een foutmelding/geen toegang.
  • Test buiten je eigen domein: probeer in te loggen met een account van buiten de organisatie. Als de app toegang verleent, moet je autorisatielogica (wie mag wat) kloppen.
  • Bekijk geladen scripts: let op of apps namen, e-mailadressen en wachtwoorden ophalen. Is er geen duidelijke eigenaar, dan adviseren de onderzoekers om de app unpublish te maken.

Snelle signalen: instelling “Only you” en unpublish

In hun test beschreven de onderzoekers dat een app op Only you voor een onbekende bezoeker terugvalt naar een 401-achtige afwijzing voor zowel pagina als data. Ook gaven ze aan dat unpublish de app binnen seconden offline kon halen.

Dat maakt het extra belangrijk om niet alleen te vertrouwen op een intuïtieve ‘privacy’-instelling, maar om het effect daadwerkelijk te verifiëren.

Waarom dit ook breder dan Grok speelt

Dit voorval laat zien hoe AI-app builders de drempel voor publicatie verlagen. Tegelijk ontstaat er een nieuw type risico: een app kan technische distributie krijgen (via subdomains en DNS-registraties) terwijl de maker denkt dat de content “gedeeld maar afgeschermd” is.

De onderzoekers plaatsen het probleem bovendien in dezelfde lijn als bevindingen rond app builders bij andere platforms. Ze verwijzen naar een eerdere ontdekking waarbij gedeelde pagina’s via passive DNS te vinden waren, waarna een platform een fix uitbracht.

Voor security teams betekent dit vooral één ding: controleer instelbare toegang én controleer dat wat publiek zichtbaar wordt ook werkelijk niet uitlekt.

Gerichte next steps voor je security- en IT-team

Als je wilt starten met een aanpak die aansluit op de gevonden risico’s, kies dan voor korte, haalbare acties:

  • Maak een lijst van alle Grok-built apps (en andere AI-app builders) die medewerkers hebben gepubliceerd.
  • Markeer apps met interne data als prioriteit en zet ze op Invited users of Only you.
  • Voer een test uit met een account van buiten de organisatie om te verifiëren dat autorisatie echt werkt.
  • Als je scripts verdachte gedrag zien (of als je geen eigenaar kunt vinden): unpublish.
  • Integreer dit in je bredere proces voor software supply chain en app discovery, zodat dit niet een eenmalige oefening blijft.

Wil je daarnaast begrijpen hoe je modernere zichtbaarheid en rapportage rond software beter opzet, dan is dit ook relevant: Software transparency: SBOM, AI BOMs en VEX uitgelegd.

En als je vooral kijkt naar het tempo van kwetsbaarheden en updates binnen de securitypraktijk, helpt ook dit overzicht: Dreiging en patchvertraging: waarom rijke data wint.

Conclusie

Grok-built apps blootgesteld: het onderzoek van Claroc laat zien dat tienduizenden Grok-apps zonder inlog toegankelijk konden zijn. Een deel van die apps bevatte interne bedrijfs- of persoonlijke data, en in sommige gevallen kwam zelfs extreem gevoelige informatie naar voren.

De technische kern van het risico zit in toegangsinstellingen die niet volledig voorkomen dat adressen en subdomains via DNS-artefacten vindbaar worden. Daarom is de beste remedie praktisch en snel: ontdek gepubliceerde apps, controleer de daadwerkelijke toegang van buitenstaanders en haal apps met interne data terug wanneer autorisatie niet klopt.

Bron: https://thehackernews.com/2026/11/over-35000-grok-built-apps-exposed.html