Van een Misgeconfigureerde Grafana naar 507 Private Meta Repositories: Een Bug van $157K

TL;DR

Een publieke Meta-IP met een open Grafana groeide uit tot een chain in vijf hops naar de broncode-omgeving van Meta.
Het pivot-punt was een wildcard SAN op het TLS-certificaat: *.llm-playground.aws.metafb.cloud, die een verborgen omgeving achter metafb.cloud blootlegde.
Door JavaScript-bundles in die omgeving te parsen vonden we referenties naar een tot dan onbekend domein: api.haloworld.xyz, dat het volgende pivot-punt werd.
Lichte fuzzing (AI-gebouwde wordlist op basis van JS-bundles, context, etc) tegen api.haloworld.xyz legde /_api/gcp-token bloot, een unauthenticated endpoint dat een geldige GCP OAuth2-token uitdeelde.
De chain liep van GCP-token, Secret Manager, Vercel-token, 85 environment variables, GitHub-tokens, 507 private repositories met read/write toegang.
We bewezen de impact zonder ook maar één bestand te clonen. Meta beloonde Preben $157K; gerapporteerd op 21 maart 2026, gemitigeerd op 23 maart 2026.

Een paar keer per jaar hacken we op Meta uit nieuwsgierigheid. Het is een van de zwaarste scopes in bug bounty en we zijn lang niet zo scherp als de fulltime Meta-hunters. Wat we wel hebben is een AI-framework bij Sectricity, dat het zware werk doet terwijl wij sturen. Diezelfde aanpak gebruiken we ook tijdens onze penetration testing en red teaming trajecten: menselijk oordeel bovenop agentic recon. Aan het einde van de chain keken we naar 507 private Meta repositories met read/write toegang.

Stap 1: ons AI-framework, gericht op anomalieën

Het afgelopen jaar hebben we onze eigen agentic frameworks en custom modellen gebouwd voor het recon-werk dat we echt doen. We richten ze niet op Meta met de vraag "vind bugs." We vragen om anomalieën: dingen die niet passen in het normaalbeeld.

Tijdens deze hunt deed het framework wat een menselijk team weken zou hebben gekost. Het werkte zich door de publieke infrastructuur van Meta, bouwde een baseline van wat normaal eruit ziet, en gaf ons een korte lijst van hosts die niet pasten. Een van die flags is waar de chain begint.

Stap 2: een saaie Grafana

Een van de gemarkeerde hosts was een IP met een open Grafana. Geen auth, gewoon open op het publieke internet.

Eerste reactie: nice. Tweede reactie, na wat rondkijken: saai. Dev metrics, niets gevoeligs. Het soort finding dat de meeste researchers afdoen als een low-severity misconfig en achter zich laten.

Het framework liet het niet los. Het had de host om een reden gemarkeerd en hield hem op de shortlist, hoe onspectaculair de oppervlakte ook leek. Wij waren klaar om verder te gaan; het framework niet. Dat is het stuk waar een mens het bijna altijd verkeerd doet.

De open Grafana-instance, op een van de hosts die onze pipeline als out of place had gemarkeerd. Dev metrics, niets gevoeligs, maar het bestaan van een publieke Meta-IP die dit draaide was het echte signaal.

Stap 3: het TLS-certificaat

De Grafana zelf was saai. Het bestaan van de Grafana, op een host die duidelijk van Meta was, was het vreemde stuk. Meta is netwerk-strikt; interne services lekken niet zomaar op het publieke internet zonder dat er iets onder zit. De echte vraag was niet "wat staat er in deze Grafana?" Het was "waarom staat deze IP überhaupt open?"

Het framework haalde het TLS-certificaat op van het IP en bracht de SANs naar boven. De CN: *.llm-playground.aws.metafb.cloud

Het TLS-certificaat opgehaald van het IP. De wildcard SAN *.llm-playground.aws.metafb.cloud was het pivot-punt, een domein dat bijna niemand kende.

metafb.cloud was een domein dat bijna niemand kende. llm-playground was een interne AI-experimenteeromgeving, blootgesteld genoeg om een publiek certificaat te hebben.

Een wildcard SAN vertelt je dat wie het certificaat heeft uitgegeven dacht aan een hele familie van hosts. We namen de fingerprint mee naar crt.sh en haalden er 20 tot 30 bereikbare subdomeinen vanaf dat ene certificaat uit.

Het pivoten van het certificaat op crt.sh bracht 20 tot 30 bereikbare subdomeinen aan het licht die dezelfde wildcard deelden, waarmee de verborgen omgeving achter metafb.cloud in kaart kwam.

Stap 4a: AI bouwt de wordlist

De meeste subdomeinen van metafb.cloud waren saai. Om iets interessants te vinden hadden we een slimme wordlist nodig, geen generieke. En we hadden een doel nodig om hem op te richten.

Het framework had JavaScript-bundles van de bereikbare subdomeinen al doorlopen en daaruit elke URL en hostname gehaald. Een van die referenties wees naar een domein dat we nergens anders gezien hadden: api.haloworld.xyz. Niet op metafb.cloud, niet in het certificaat, niet ergens in Meta's publieke oppervlakte. Gewoon een stille referentie verstopt in JS.

Met een nieuw target in handen zetten we de orchestratie weer aan het werk. Bouw een context-aware wordlist voor deze host, gegrond in wat we al gezien hadden tijdens de recon: routes uit de JavaScript-bundles, woorden en tokens uit pagina's die we hadden gecrawled, naming patterns van zusje-subdomeinen. Het soort lijst dat een mens kan samenstellen, maar niet in een redelijke tijd.

Stap 4b: mensen (eigenlijk tools) fuzzen

We voerden de wordlist aan onze fuzzer en liepen de subdomeinen één voor één af. Er vielen een paar low en medium severity findings uit. Daarna raakten we er één die alles veranderde: GET https://api.haloworld.xyz/_api/gcp-token

Het unauthenticated endpoint dat een geldige GCP OAuth2-token uitdeelde aan iedereen die erom vroeg. Geen auth, geen rate limit.

Unauthenticated. Het endpoint gaf een geldige GCP OAuth2-access token terug aan iedereen die erom vroeg. Een GCP-access token is een sleutel, en wat hij ontsluit hangt volledig af van welke identity hij vertegenwoordigt. Deze vertegenwoordigde de verkeerde identity.

Stap 5: de chain

We controleerden wat de token kon doen, één read-only call per keer.

De chain in vijf hops. GCP-token, Secret Manager, Vercel-token, 85 env vars, GitHub-tokens, 507 private repos.

De token had read-toegang tot GCP Secret Manager. In Secret Manager: een Vercel API-token. De Vercel-token legde 85 environment variables bloot in de projecten van de organisatie. Tussen die env vars: meerdere GitHub personal access tokens. Eén van die GitHub-tokens had read/write toegang tot 507 private repositories.

Stap 6: stop

Toen de GitHub-token 507 private repos opsomde, draaiden we één voorzichtige query, bevestigden het aantal, en sloten het tabblad. We hebben niets gecloned, geen code doorzocht, geen enkele file tree bekeken.

De opdracht is om impact te bewijzen, niet om hem te extraheren. Op het moment dat je de blast radius kunt aantonen, schrijf je het op. We rapporteerden de chain; het security team van Meta heeft credentials geroteerd en onderzoek gedaan. Meta beloonde Preben Ver Eecke uiteindelijk met $157K.

507 private repositories opgesomd, nul benaderd. Het rapport was de win.

Wat we hieruit meenemen

Het moeilijke is niet het model of de bug zelf. Het is de scaffolding, de prompts, de feedback loops, het aaneenrijgen van kleinere bugs en het oordeel om te weten welke flags een nadere blik verdienen. Daar zitten we al een tijd in vast, en deze finding is daar een deel van het waarom van.

De human-led, AI-powered pipeline die deze chain naar boven bracht is beschikbaar voor bestaande én nieuwe Sectricity-klanten.

Reactie van Meta

After reviewing this issue, we have decided to award you a bounty of $150000. Below is an explanation of the bounty amount. Meta fulfills its bounty awards through Bugcrowd.

Your report demonstrated a chain of vulnerabilities that granted access to a set of secrets that enabled you to access services with privileged access.

Following a comprehensive investigation we have decided to award you a $150.000 bounty. We have mitigated the vulnerabilities and found no evidence of abuse. Thank you for your continued efforts in helping us secure our services and protect the people that use them, we look forward to collaborating with you again in the future.

Thank you again for your report. We look forward to receiving more reports from you in the future!

en een 5% patience bonus

Thank you for your patience while we investigated this report. As the payment is being issued 37 days from your message with the last details required for us to reproduce the bug, we are awarding you with 5% bonus of the original payout amount.

Tijdlijn

21 maart 2026: gerapporteerd
23 maart 2026: getriaged en gemitigeerd
29 april 2026: beloning uitbetaald

Het is bijna exact tien jaar geleden dat onze eerste Meta-finding plaatsvond, een saaie IDOR die op het Belgische nationale nieuws belandde. Een decennium later op een podium staan in Taipei en praten over een chain die begon met een open Grafana en eindigde bij 507 private repos, voelt als een nette manier om die verjaardag te markeren.

De IDOR uit 2016 die op het Belgische nationale nieuws belandde. De originele Meta (toen nog Facebook) finding, bijna exact tien jaar voor deze chain.

Veelgestelde vragen

Waarom begon de chain met een open Grafana?

De Grafana zelf was niet de kwetsbaarheid. Het was een signaal. Een netwerk-strikt bedrijf als Meta laat normaal geen interne services lekken naar het publieke internet. Een open Grafana op een publieke Meta-IP was een anomalie die het waard was om verder te onderzoeken, zelfs al was de inhoud van het dashboard gewoon saaie dev metrics.

Wat is een wildcard SAN en waarom was die hier het pivot-punt?

Een wildcard SAN is een Subject Alternative Name op een TLS-certificaat dat een hele familie van hostnames dekt, zoals *.example.com. In deze chain liet de wildcard *.llm-playground.aws.metafb.cloud zien dat er een hele verborgen omgeving bestond achter een domein dat bijna niemand kende, en met de fingerprint van het certificaat konden we via de publieke Certificate Transparency logs 20 tot 30 bereikbare subdomeinen ophalen.

Hoe kan een unauthenticated GCP-token private broncode blootleggen?

Een GCP OAuth2-access token vertegenwoordigt een identity binnen Google Cloud. Als die identity read-toegang heeft tot Secret Manager, kan iedereen die de token in handen heeft elk secret lezen dat de identity mag zien. In dit geval bevatten die secrets een Vercel API-token, die op zijn beurt 85 environment variables blootlegde, die op hun beurt GitHub personal access tokens bevatten met read/write toegang tot 507 private repositories. De les is dat secrets in cloud storage alleen zo goed beschermd zijn als de zwakste identity die ze kan lezen. Dit is een van de kernfaalmodi die we tijdens een pentest onderzoeken.

Heeft Sectricity een van de 507 private repositories benaderd?

Nee. We hebben het aantal opgesomd met één read-only query en daarna gestopt. We hebben niets gecloned, doorbladerd of doorzocht. Het doel van responsible disclosure is impact bewijzen, geen data extraheren.

Hoe lang deed Meta erover om de chain te fixen?

Twee dagen. De chain werd gerapporteerd op 21 maart 2026 en op 23 maart 2026 getriaged en gemitigeerd.

Is deze aanpak iets dat bedrijven kunnen gebruiken tijdens pentests?

Ja. Dezelfde agentic reasoning die deze chain naar boven bracht is toepasbaar op elk extern aanvalsoppervlak: shadow domains, vergeten certificaten, blootgestelde dev environments en gelekte credentials. Sectricity gebruikt deze aanpak in externe pentests voor zowel bestaande als nieuwe klanten.

Gerelateerde services en bronnen

Als jouw organisatie cloud workloads draait op GCP, AWS of Vercel, dan is de faalmodus uit dit verhaal niet exotisch; het is een chain van kleine misconfiguraties die los van elkaar onschuldig lijken. Sectricity test op precies dit soort chains tijdens een pentest en gaat dieper tijdens een red team traject, waar we externe recon combineren met doelgerichte aanvallen op je echte omgeving. Voor organisaties die AI-experimenteeromgevingen en LLM-playgrounds aan het internet blootstellen dekt onze AI security testing het specifieke aanvalsoppervlak dat LLM-aangrenzende infrastructuur introduceert. Verder lezen: OWASP over veelvoorkomende web-aanvalsoppervlakken en het MITRE ATT&CK-framework voor het in kaart brengen van post-exploitation gedrag.