Placeholder-domeinen worden al jaren gebruikt om documentatie, tests en voorbeelden begrijpelijk te maken. Denk aan varianten zoals example[.]com of andere ‘voorbeelddomeinen’ die teams hard-coded opnemen in skills, agent-werkstromen en codevoorbeelden. Maar juist die ogenschijnlijk onschuldige verwijzingen kunnen omslaan in een gevaarlijke ingang—zoals blijkt uit een casus rond placeholder-domeinen ClickFix.
Onderzoekers zagen dat het domein third-party[.]com, doorgaans gebruikt als documentatie-placeholder, actief een ClickFix-lure serveerde aan Windows-browsers. Tegelijkertijd kregen andere gebruikers een decoy te zien. Het resultaat: een keten waarin vertrouwen in ‘een voorbeeldlink’ verandert in een poging om commando’s te laten uitvoeren via de Windows Run dialoog.
Wat is er mis met ‘placeholder-domeinen’?
Het probleem zit niet in het idee van een placeholder, maar in welk type domein je kiest en wie het kan registreren. Het onderzochte domein third-party[.]com is niet IANA-reserved. Daardoor kan iedereen het domein vastleggen en content leveren die afwijkt van wat teams verwachten.
In de praktijk betekent dit dat code, skills en documentatie die jaren geleden een placeholder-url gebruikten, nu een live verwijzing kunnen vormen naar infrastructuur die door aanvallers wordt beheerd. Wat in een repo als ‘stand-in’ bedoeld was, kan bij een echte klik uitmonden in een aanvalspad.
ClickFix in actie: van decoy naar clipboard hijack
ClickFix is een social engineering techniek waarbij pagina’s foutmeldingen, browseralerts of CAPTCHA-achtige prompts tonen. Het doel is gebruikers te laten geloven dat er iets ‘gerepareerd’ moet worden, waarna ze een commando moeten kopiëren en plakken om het probleem op te lossen.
In deze casus werd het lokaas zichtbaar gemaakt bij Windows-gebruikers. De pagina stuurde een Cloudflare check die de clipboard zou vergiftigen, waarna het slachtoffer werd aangemoedigd om het commando via Windows Run te plakken en uit te voeren. Het geplakte commando was bedoeld om een remote PowerShell-payload te extraheren en te starten.
Voor macOS-gebruikers lag de focus anders: dezelfde verwijzing liet een melding zien dat macOS niet ondersteund zou zijn, met de instructie om het op een Windows-device opnieuw te proberen. Daarmee blijft het ‘echte’ Windows-pad buiten beeld voor veel niet-Windows testers en beoordelaars.
Waarom statische checks dit niet altijd vinden
Veel teams draaien securitycontroles op bestanden voordat ze code publiceren. Dat is nuttig, maar het onderschept niet altijd wat er gebeurt tijdens een live verzoek.
De kern van het punt van de onderzoekers: een bestandsanalyse of scan kan niet zien wat een website precies terugstuurt op het moment dat een gebruiker (of een agent) de URL bezoekt. De ‘echtheid’ van de dreiging verschijnt dus bij request time, afhankelijk van browser, OS of andere context.
Dat maakt placeholder-domeinen ClickFix-achtig lastig: het staat misschien netjes als voorbeeld in een repo, maar het gedrag van de domeinserver kan intussen volledig zijn gedraaid.
Een domein in 1.700+ repos: hoe verspreidt het zich?
De onderzochte domeinverwijzing third-party[.]com werd gevonden in meer dan 1.700 publieke GitHub-repositories. Daarbij ging het niet alleen om ‘gewone’ code, maar ook om materiaal rond AI agent skills en MCP-server docs waarin een placeholder-URL werd gebruikt als voorbeeldendpoint.
Wat hierbij extra zorgwekkend is: in alle gevonden plaatsen zag de verwijzing eruit als wat het was—een logische placeholder. Juist daardoor kan het misbruik zich onopgemerkt verspreiden. Teams nemen het voorbeeld over, testen ermee, en vergeten dat de placeholder-url zelf niet onder hun controle valt.
Risico’s voor prompt engineering en agentgedrag
Naast de directe ClickFix-route kunnen misbruikte placeholder-domeinen ook indirecte problemen veroorzaken. De onderzoekers wijzen erop dat een ‘blind vertrouwde’ domeinverwijzing deuren kan openen richting prompt injection en andere onverwachte gedragingen.
Het is niet alleen een kwestie van “er wordt iets kwaads uitgevoerd”, maar ook van “de content die de agent binnenhaalt” kan onbedoeld instructies, scripts of data bevatten die het systeem beïnvloeden op manieren die niet in je statische analyse zitten.
Ook andere placeholder-domeinen bleken te misbruiken
Na de eerste vondst identificeerden de onderzoekers 13 extra placeholder-domeinen die niet IANA-reserved zijn. Een deel daarvan bleek ondertussen op verschillende manieren misbruikt te worden.
Voor sommige domeinen ging het om scams en scareware richting macOS-bezoekers. In andere gevallen zagen onderzoekers bijvoorbeeld een normale parkingpagina—wat meteen duidelijk maakt dat de server per context kan variëren. Bovendien werden de twee scam/scareware-gevallen aangetroffen in honderdduizenden GitHub-bestanden en ook in honderden agent skills.
Zo verklein je het risico: audit, vervang en kies het juiste placeholderdomein
De aanpak begint met bewustwording: als je een domein als placeholder gebruikt, moet je controleren of het domein onder jouw controle valt of dat het in elk geval niet ‘squattable’ is.
1) Audit je skills, documentatie en testcases
Zoek in je repos en pipelines naar verwijzingen naar placeholder-domeinen die niet IANA-reserved zijn. De onderzoekers benadrukken dat het gedrag van een website pas echt duidelijk wordt bij het daadwerkelijk opvragen van de URL. Daarom is het verstandig om niet alleen te zoeken op tekst, maar ook te beoordelen waar en hoe die links gebruikt worden door agents en gebruikers.
2) Gebruik alleen reserved placeholders
Een praktische regel: kies reserved voorbeeldniveaus zoals example[.]com (of example[.]org en example[.]net) voor voorbeelden. Daarmee vermijd je dat iemand anders het domein kan registreren en vullen met schadelijke content.
3) Behandel plausible ‘stand-in’ domeinen als misbruikbaar
Als je teams “logisch klinkende” domeinen gebruiken zoals yourcompany[.]com, mycompany[.]com, your-api[.]com of varianten daarop, beschouw die dan als domeinen die door aanvallers kunnen worden vastgelegd en misbruikt. De vormgeving is dan geen bescherming; alleen de reservering (of controle) telt.
4) Test met context, niet alleen met scans
Omdat de server per OS of browser kan reageren, kun je niet volstaan met een statische controle. Richt je tests op het gedrag dat agents en eindgebruikers ervaren bij een echte HTTP(s)-aanvraag. Zo ontdek je tijdig of een ‘placeholder’ in de praktijk iets anders serveert.
Waarom dit extra relevant is voor AI-agent omgevingen
AI-agent skills en agent-werkstromen nemen sneller dan traditionele applicaties externe content over: documentatie, endpoints, voorbeeldcalls en skills die doorverwijzen naar “een testserver”. Als die verwijzingen naar onbeheerde placeholder-domeinen leiden, kan dat betekenen dat een agent onverwachte instructies ontvangt of dat uitvoerroutes worden beïnvloed.
Als je met agenten werkt, is het verstandig om ook te kijken naar eerdere patronen rond agent- en social engineering risico’s. Zie bijvoorbeeld hoe aanvallers proberen agentgedrag te sturen via websequenties: AI-agents bij aanvallen op webshops: wat speelt er?. En voor de bredere component van herstel en controle in agentic flows: Agentic remediation: sluit de CTEM-cyclus met AI.
Conclusie: vertrouw op reserved placeholders, niet op ‘waarschijnlijk onschuldige’ urls
De casus rond placeholder-domeinen ClickFix laat zien hoe snel een ‘voorbeeld’ kan veranderen in een aanval. Omdat domeinen niet IANA-reserved zijn, kunnen kwaadwillenden ze registreren en content sturen die afwijkt per platform—van Windows-clipboard malware tot macOS scareware of decoys.
Wil je dit soort risico’s dempen, vervang dan niet-reserved placeholder-domeinen door reserved voorbeelden, voer gerichte audits uit op skills en documentatie, en test gedrag bij echte requests in plaats van alleen op statische bestanden. Zo voorkom je dat “redelijk ogende” links je ecosystemen verbinden met attacker infrastructure.
Bron: https://thehackernews.com/2026/09/placeholder-third-partycom-referenced.html
