Meta: hackers konden tienduizenden Instagram-accounts overnemen met Meta AI

Meta's eigen AI-chatbot heeft hackers geholpen bij het overnemen van meer dan 20.000 Instagram-accounts. De kwetsbaarheid werd eerder deze week bekend, maar nu zegt Meta hoeveel slachtoffers er waren. De chatbot laat hackers zeer eenvoudig het e-mailadres van een Instagram-account veranderen, waarna ze het account kunnen overnemen.

Bij de hack konden 20.225 accounts worden overgenomen, bevestigt Meta tegenover de Amerikaanse staat Maine. De hack kwam eerder deze week aan het licht, maar toen was nog niet bekend hoeveel slachtoffers er waren. Meta zegt dat dit aantal een 'bovenlimiet' is, omdat hier mogelijk ook accounts zijn geteld waarbij de gebruiker zelf inlogde en dus niet de hacker.

De aanval werkte met Meta's AI-chatbot die gebruikers helpt bij het oplossen van problemen, zoals het niet meer hebben van toegang tot het account. Die chatbot had niet veel controles om te verifiëren of de gebruiker daadwerkelijk toegang mocht hebben tot het account. Hackers hoefden alleen een vpn te gebruiken om de chatbot ervan te overtuigen dat ze in dezelfde regio waren als de gebruiker van het account.

Vervolgens vroegen ze de chatbot om hulp omdat ze zogenaamd het wachtwoord van een account waren vergeten. Hierbij vroegen ze Meta AI om het e-mailadres van het account te wijzigen. De chatbot paste hierop het mailadres aan, waarna ze via dat nieuwe adres het wachtwoord wijzigden. Accounts zonder 2fa konden zo eenvoudig worden overgenomen.

De hackers hadden het vooral voorzien op accounts met aantrekkelijke gebruikersnamen van maximaal vier karakters, die ze vervolgens konden verkopen. Ze hackten ook bekende en grote accounts, of probeerden daar toegang toe te krijgen, zoals het Witte Huis-account van Barack Obama, een hoge adviseur van de US Space Force en beveiligingsonderzoeker Jane Wong.

Meta ontdekte de fout op 31 mei en haalde de chatbot toen offline. Het bedrijf wil de chatbot aanpassen zodat gebruikers niet zomaar het e-mailadres kunnen wijzigen.

Reacties (57)

[qlum]

Tja een hack zou ik het nouwelijks noemen, de chatbot voert gewoon de opdracht uit. Erg verelend voor de slachtoffers hoop dat meta die dan ook weer toegang kan geven. Is meer via de achterdeur naar binnen lopen dan inbreken.

[Reactie gewijzigd door qlum op 7 juni 2026 10:36]

[njitter]

Social engineering toegepast op.een chatbot

[Blokker_1999]

En terwijl menselijke medewerkers een script moeten volgen en we hen gaan blokkeren in de software om dit soort acties te doen zonder de juiste verificatie van de gebruiker, wordt de chatbot gewoon toegang gegeven, en kan niemand zeggen hoe je een LLM gaat beperken om toch zeker te zijn dat de regels gevolgd worden, want we weten dat een LLM een zwarte doos is, en we weten dat een LLM te overtuigen is om alle regels te breken.

[Rhizix]

"en kan niemand zeggen hoe je een LLM gaat beperken om toch zeker te zijn dat de regels gevolgd worden" ?

Maar dat is dus letterlijk wat wel al makkelijk mogelijk is via hooks (zie bvb Codex of Claude Code)?

[drdelta]

Maar dat is dus letterlijk wat wel al makkelijk mogelijk is via hooks (zie bvb Codex of Claude Code)?

Hooks zijn suggesties, met geen enkele garantie dat je LLM ze zal volgen. Het internet staat vol met berichten van mensen die zich figuurlijk de haren uit het hoofd trekken omdat instructies genegeerd worden.

[lariekoek]

Je maakt "tools" zelf beschikbaar en bepaalt zelf wat ze wel en niet uitvoeren, waar ze toegang toe hebben etc.
Dat is gewoon deterministisch en volledig aan Meta toe te schrijven.

[drdelta]

Niets dat een LLM doet is deterministisch zover ik begrijp.

Maar inderdaad, ik zou ze geen toegang geven tot de mogelijkheid account gegevens in te zien, laat staan te wijzigen.

Dat Meta dat wel gedaan heeft… tja, nu mag wel duidelijk zijn wat er allemaal mis kan gaan als je dat soort dingen doet.

[lariekoek]

Dat klopt deels maar de functies die je aanbiedt (daar kies je allereerst voor) zul je veilig moeten schrijven.
Zo geef je geen brede toegang tot SQL maar een functie ("tool") die expliciet dat doet wat het moet, en niet méér dan dat. Bijvoorbeeld enkel read-only toegang, de velden die functioneel relevant zijn, etc.
Ook zorg je dat je parameters/argumenten veilig zijn.
Ik ga er in de regel standaard van uit dat functies "gefuzzed" worden of aangeroepen outside of the box en met slechte intenties, zeker wanneer deze ver aan de voorkant zitten.

Op zich knap als je een LLM zover krijgt om tools juist te gebruiken.
Maar zoiets achterlijks als deze bug/feature is toch van de hoogste orde.

[Rhizix]

Hooks zijn geen suggesties... da's net het hele punt, het zijn hard blocks, commando's die defined zijn in je hooks worden gewoon niet uitgevoerd, simple as that.

[drdelta]

Maar die hooks zijn toch gewoon LLM instructies, die genegeerd kunnen worden als gevolg van bv de context window etc? Ik lees op het internet iig dat mensen allerlei problemen hebben omdat hun commando’s niet uitgevoerd worden, zelfs wanneer ze de Claude documentatie tot de letter volgen.

[Rhizix]

Hooks zijn geen instructies, het zijn in feite , well, "hooks" die tussen de LLM en de command line zelf zitten.
Dus als de LLM beslist van "git push --force" , dan zal als er hier een hook voor ingesteld staat, eerst (programatorisch) gekeken worden of dit dus al-dan-niet mag.

Mss niet de meest duidelijke uitleg, maar hopelijk is het alvast wat duidelijker

[drdelta]

Hooks zijn geen instructies, het zijn in feite , well, "hooks" die tussen de LLM en de command line zelf zitten.
Dus als de LLM beslist van "git push --force" , dan zal als er hier een hook voor ingesteld staat, eerst (programatorisch) gekeken worden of dit dus al-dan-niet mag.

Mss niet de meest duidelijke uitleg, maar hopelijk is het alvast wat duidelijker

Zover ik weet kan het reasoning model besluiten hooks te omzeilen, zie bv. Claude decided to use `git commit`, even though he was not allowed to, door verboden commandos/instructies gewoon indirect te draaien.

[2playgames]

Dat zou goed kunnen maar dat is geen zwakte van die hook, maar een ander lek dat de indirecte manier mogelijk maakt. Bijvoorbeeld het model permanent toe te staan een script te draaien waar het ook schrijfrechten voor heeft.

[bzuidgeest]

Dit soort onzin is niet uniek aan LLM's, een slecht "chatbot" kon dit jaren geleden al doen. Uiteindelijk is het meta die bepaald waar er toegang tot is. Dat met een simpele vraag een email adres gewijzigd kan worden zonder verdere authorisatie is natuurlijk vrij bizar. Dat zou gewoon nooit moeten mogen. Of het nou een LLM is of een gewone ouderwetse chatbot

[Nark0tiX]

Eerlijk gezegd snap ik niet waarom zoveel partijen hier mee worstelen. Wij hebben dit vanaf dag één dat openai uit kwam goed ingericht.

De truc is simpel: behandel de AI tool calling, als de ingelogde gebruiker...

Bij de 'SSE' call wordt gewoon de access_token van de gebruiker mee gestuurd, deze word gevalideerd en in scoped context worden alle claims / rollen gewoon zoals normaal geinject in de HttpContext.

De LLM kan dus letterlijk niet bij data of endpoints waar de user zelf ook niet bij kan, niet omdat we het de AI vragen, maar omdat de service het weigert. Prompt-based autorisatie ("geef alleen terug wat gebruiker X mag zien") is natuurlijk onzin, een LLM is geen security boundary.

Voor de audit trail dus RFC 8693 token exchange: de user token wordt ingewisseld voor een delegated token met een ai_agent scope en een act claim. Zo is elke AI-actie herleidbaar naar de user én zichtbaar als AI-call, en kun je daar aparte rate limits of restricties op zetten.

De LLM ziet nooit credentials, kan nooit meer dan de user zelf, alles is zichtbaar in auditlog... Gewoon je bestaande OIDC-infrastructuur goed gebruiken dus.

[gekkegerrit101]

Die vlieger zal hier niet op gaan. Het misbruik hier heeft plaatsgevonden in het account herstel gedeelte. Dus de gebruikers die hier normaal gesproken mee chatten, zijn niet aangemeld want ze kunnen niet meer in hun account.

[2playgames]

Met andere woorden, Meta heeft een LLM dat er nog niet klaar voor was een bepaalde beslissingsbevoegdheid gegeven, en plukt daar nu de vruchten van.

[Nark0tiX]

Dan gaat het zelfde principe op toch. LLM hoort daar dan niet bij te kunnen

[gekkegerrit101]

100%, zeg alleen dat de oplossing die jij beschrijft (wat exact is wat wij ook doen) hier alleen niet inzetbaar is helaas.

[2playgames]

Zo zou ik het ook inrichten inderdaad. De chatbot is er dan als alternatief (ernaast of vervangend) voor het zelfbedieningsinstellingenmenu (lingo!). Eventueel met wat meer escalatiemogelijkheden en obscure procedures maar altijd met harde grenzen en externe goedkeuring.

[supersnathan94]

Sorry, maar wat een ontzettend achterlijke manier om dit te doen zeg.

Nul verificatie whatsoever.

Account reset waarbij je alle “known verifiable information” ook direct wijzigt.

Wat knullig. Ik dacht dat we al wel voorbij dit stadium van security waren?

[Blokker_1999]

Wat ik persoonlijk het ergste vind is dat iemand het een goed idee vond om die LLM zelfs maar de mogelijkheid te geven om aanpassingen te maken aan de accounts van een gebruiker. LLMs als vervanger van je helpsysteem is 1 ding. Het helpen van mensen met het vinden van de juiste infromatie, daar kan ik inkomen. Maar dat meerdere diensten hebben toegestaan dat deze chatbot ook gewoon letterlijk accounts mag aanpassen, dat er schrijftoegang is naar die backend, dat doet me echt grote vraagtekens plaatsen bij hoe heel dat ding is kunnen gebeuren want het is net een scenario dat al zo lang bekend is en waar zoveel voor gewaarschuwd wordt.

[fenrirs]

Simpel: een combinatie van junior developers met AI tooling en een pushende manager met het verstand van een aardbei.

Ik vrees dat we dit veel meer gaan zien

[renecl]

Heel veel, denk zelfs alles wat door vibecoders wordt utigespuugd. Als het ineens werkt, stop je met "ontwikkelen"

[CAPSLOCK2000]

Maar dat meerdere diensten hebben toegestaan dat deze chatbot ook gewoon letterlijk accounts mag aanpassen, dat er schrijftoegang is naar die backend, dat doet me echt grote vraagtekens plaatsen bij hoe heel dat ding is kunnen gebeuren want het is net een scenario dat al zo lang bekend is en waar zoveel voor gewaarschuwd wordt.

De basis is natuurlijk heel simpel: dit is goedkoper en de overlast die het geeft komt terecht bij de gebruikers, niet de aandeelhouders.

Meer verklaringen zijn er niet nodig, maar ik kan er nog wel een paar bedenken. Laat ik eens advocaat van de duivel spelen:
1. Eat-you-own-dogfoot. Als voorloper en promotor van AI is het niet gek dat Meta het zelf te pas én te onpas inzet. Om nieuwe grenzen te leren zal je er af en toe overheen moeten gaan (dit is geen excuus).
2. Privacy. Liever een neutrale bot die bij privé-gegevens gaat dan nieuwschierige menjes.
3. Nauwkeurigheid. Persoonsnamen uit andere talen/culteren kunnen erg lastig zijn om te spellen als je dat niet gewend bent. Mensen maken daar voortdurend fouten in en dat vinden onbeleefd overkomen. Een computer zal braaf het stringetje exact overnomen en geen tikfouten maken.
4. Groupthink. Als iedereen om je heen de hele dag enthousiast is over AI dan is het moeilijk om je kritisch blik te bewaren.
5. Luiheid en gemakzucht. Geen uitleg, we zijn allemaal mensen.
6. AI druk. I hoor dat sommige grote bedrijven hun personeel bijna dwingen om "iets" met AI te doen en AI-first te werken. Het hoort een beetje bij punt 1 (EYODF). Het gevolg is dat het ook gebruikt wordt door mensen die niet echt weten wat ze doen.
7. AI bluf + IT-schaamte.
Een van de gevaren van AI is dat alles makkelijk lijkt als iemand anders het werk doet en wij alleen maar mee hoeven te kijken ter controle. Het gevaar is dat je veel te lang mee gaat in iets dat je eigenlijk niet echt meer begrijpt omdat je het niet zelf hebt hoeven uitzoeken. Dat maakt mensen overmoedig.
Dat is een heel andere situatie dan voorheen waarin de meeste mensen eigenlijk een beetje bang waren voor IT en computers omdat ze niet echt konden overzien hoe het werkt. Nu snappen ze het nog steeds niet maar door gebruik van LLMs overschatten ze hun eigen inzicht flink.
8. Niet mijn probleem
In een grote organisatie wordt verantwoordelijk vaak erg versnipperd. Het kan best zijn dat er 10 teams bedacht hebben dat het riskant is, maar het niet als hun taak hebben gezien om er voor te gaan liggen. De persoon die het idee had kan heel ver afstaan van de mensen die het uiteindelijk hebben uitgevoerd. Iedereen in de keten gaat er vanuit dat de mensen voor of na hen wel hebben nagedacht over de risico's en verantwoordelijkheden.

Uit persoonlijke ervaring: voor mij zijn LLMs een enorm krachtig hulpmiddel die me veel productiever maken, ik wil niet meer zonder. Ik merk dat ik voortdurend mijn eigen grenzen opschuif omdat de resultaten zo goed zijn. Nu ben ik redelijk gekwaliceerd om de risico's en gevolgen de overzien maar ook voor mij blijft het een valkuil.
Nogmaals, ik wil geen excuses maken voor Meta, maar ik kan het wel proberen te verklaren.

PS. Mijn advies is om LLMs te behandelen als gereedschap om taken sneller te maken, niet makkelijker. Doe er niks mee dat je niet zelf met de hand kan. Vraag alleen dingen die je zelf makkelijk kan controleren. Geef duidelijke opdrachten, geen vage suggesties of vragen. LLMs werken op of onder het niveau van de vraagsteller, niet er boven. Een LLM gebruiken om je eigen gebrek aan inzicht op te vangen is vragen problemen.

[PuzzleSolver]

Sluit me hier helemaal bij aan, als programmeur gebruik ik ook LLM's en ook voor mijn electronica hobby en huis verbouwingen is het makkelijk om snel dingen uit te zoeken of te vinden. Maar het probleem is dat de LLM je met hetzelfde vertrouwen verkeerde code, verkeerde antwoorden zal geven. Als je er wat van zegt dan krijg je een compliment van scherp opgemerkt oid en gaan we op dezelfde voet verder.

Nog steeds komen LLM's vast te zitten als het buiten de kennis van het internet komt of als het antwoord moet komen door verschillende domeinen te combineren electronica en programmeren gaat steeds beter shadercode doen ze inmiddels ook vrij goed en vooruitgang is er wel, maar het is nog geen AGI aangezien ze uiteindelijk in een loop van vereerde antwoorden blijven zitten als ze het niet weten ipv te zeggen dat ze het niet weten.

Maar toegang geven tot het resetten van een wachtwoord en e-mail zonder verificatie is natuurlijk gestoord. Dit had eigenlijk in de API af moeten worden gevangen, maar inderdaad is reden 8 die je hierboven noemt vaak het probleem in grote organisaties, plus dat mensen in zo'n organisatie het vaak niet willen horen omdat ze dan verantwoordelijk zijn voor de oplossing.

[2playgames]

Ik kan me inderdaad niet voorstellen dat niemand daar aan dit probleem heeft gedacht, dus het moet wel een bewuste keuze zijn geweest. Kan alsnog een domme keuze zijn natuurlijk.

Trouwens, ik denk dat je LLMs heel goed kan gebruiken om je eigen inzicht aan te vullen, maar je moet ze dan wel zelf die kant op motiveren. In mijn ervaring kunnen ze goed onduidelijkheden en problemen in mijn opdracht aankaarten maar zullen ze dit niet snel proactief doen.

[Reactie gewijzigd door 2playgames op 8 juni 2026 19:55]

[JustRob]

Tja. Dat krijg je als je van die CEO’s hebt die roepen dat alles AI moet worden zonder na te denken of het wel écht verstandig is.

[Barsonax]

Ja maar 10x productiever en nog steeds geen tijd om de kwaliteit checken

[supersnathan94]

Nouja. AI is hier niet zozeer het probleem. Dit kan opzich best.

Alleen hebben ze fouten gemaakt in wat tegelijkertijd kan en wat de API aan de achterkant allemaal goedkeurt of niet.


Je kunt dit opzich redelijk doen door de checks and balances in code vast te leggen waarbij de chatbot een frontend is. Maar dit lijkt gewoon amateuristisch “hier zijn schrijfAPIs in een MCP. Succes!”

[JustRob]

Een password reset process werkt al prima op de bestaande manier. Het is totaal niet nodig hier een LLM voor in te zetten. Uiteindelijk is het die LLM die gevoelig is voor een prompt injectie en een reset uitvoert naar een verkeerd e-mail adres.

dus het is wel AI hier dat het probleem is.

[supersnathan94]

Uiteindelijk is het die LLM die gevoelig is voor een prompt injectie en een reset uitvoert naar een verkeerd e-mail adres.

Is helemaal geen injectie, is gewoon by design. Kijk naar de screenshots. Dit is gewoon onderdeel van een proces, waar kennelijk geen correcte validatie plaatsvind.

Aan de achterkant worden er gewoon geen dingen gevalideerd. Dit kun je dus ook verkeerd doen zonder LLM.

dus het is wel AI hier dat het probleem is.

Nou denk het niet. Dit is gewoon niet goed ontworpen. Kan AI ook weinig aan doen.

[Sandor_Clegane]

Hahaha te mooi ook.

En dan te bedenken dat we nog niet zo lang geleden tegen dit soort bedrijven opkeken: 'move fast and break things'.

Dat laatste komt wel goed.

[armageddon_2k1]

Wie keek daar naar op dan?

[Aphelion]

Een hele groep mensen. Ik ken het vanuit software dev omgevingen.

[Sandor_Clegane]

Oh zowat de gehele software de wereld, net als met Uber enzo.

[Meros]

Dit is dus de kwaliteit van de "poortwachters" die de controle en het beheer vezorgen over de A.I. ontwikkeling.

"What can go wrong" /sarcasm off

[beerse]

Het gaat om instgram en het gaat om meta. Dan is 20.000 accounts niet zo heel veel. Op 1 of andere manier heb ik het idee dat er 20.000 accounts via deze route overgenomen zijn. En dat het in potentie een veelvoud (als in meer cijfers) van dit aantal accounts betreft.

Het gaat naar mijn idee om een 'in huis' achterdeurtje, zeg maar een tussendeur die eigenlijk dicht zou moeten zijn en voor de buitenwereld helemaal niet herkenbaar en officiëel niet aanwezig.

Waarom verbaast mij dit niet.

[dasiro]

In de VS of minstens in de EU zou er hier een groot en diepgaand onderzoek naar moeten gedaan worden met eindelijk eens echt zware straffen voor zowel het bedrijf als de personen die ervoor verantwoordelijk waren, want dit loopt al een tijdje de spuigaten uit: oeps foutje is opgemerkt, snel ff quick&dirty fixen en hopen dat de wind gaat liggen

[OlivierH]

"Hackers"

Ha, natuurlijk joh Meta, vooral niet toegeven dat je AI gewoon zo slecht (in je platform in-)gebouwd is dat het een extreem simpele vorm van social engineering niet eens kan afwenden.

Als Meta ook maar half wist waar ze mee bezig waren hadden ze nu alle AI zooi uitgezet, maar ze hebben geen flauw idee joh.. 😂 Nou is het wachten op de volgende paar die dit soort dingen gaan proberen, als je het super lief vraagt in de juiste context kun je dan waarschijnlijk ook dingen doen als alle persoonlijke (privé) gegevens van een profiel opvragen?

Dit krijgt nog een staartje, misschien word dit zelfs waar de bubbel barst.

[Bux666]

[...] het Witte Huis-account van Barack Obama [...]

Deze man is al ruim 5 jaar geen president meer. Hoe kan hij nog een account van het Witte Huis hebben?

[ZpAz]

Ach ja, nu je die engineers niet meer nodig hebt omdat AI het allemaal wel kan.

[0b1]

"Meta zegt dat dit aantal een 'bovenlimiet' is, omdat hier mogelijk ook accounts zijn geteld waarbij de gebruiker zelf inlogde en dus niet de hacker." Dit is toch om te huiveren zo een antwoord. Afdoen alsof het maar beperkt was. Voldoende bevestiging om niets maar ook niets met META te doen.