Cybersecurity-onderzoekers waarschuwen voor een campagne die draait om Vite mass-scanning. Daarbij scannen aanvallers het internet op Vite development servers die bereikbaar zijn, om vervolgens via een specifieke kwetsbaarheid gevoelige gegevens uit de app-omgeving te trekken. In waargenomen aanvallen uit augustus 2026 ging het onder meer om configuraties en cloudcredentials voor omgevingen bij AWS en Microsoft Azure.
De kern van het probleem is CVE-2026-39364, een fout met hoge ernst (CVSS 8.2). Met de exploit kan een onbevoegde aanvaller beveiligingschecks omzeilen door queryparameters te manipuleren, met als resultaat dat bestanden die normaal zijn geblokkeerd toch worden teruggegeven in de response.
Wat is de Vite mass-scanning aanval precies?
De campagne is volgens F5 Labs gericht op internet-bereikbare Vite development servers. Zulke servers zijn bedoeld voor ontwikkeling en troubleshooting, maar worden vaak ten onrechte (tijdelijk) opengezet. Zodra dat gebeurt, kunnen geautomatiseerde partijen gericht aanvragen doen op het eindpunt dat bedoeld is voor het serveren van bestanden: /@fs/.
Waar het bij de Vite mass-scanning om draait: aanvallers proberen gevoelige bestanden op te halen door een pad mee te geven en tegelijk bypass-queryparameters toe te voegen. Daardoor wordt een beveiligingscontrole ondermijnd en kunnen de inhoud en metadata van het gevraagde bestand zichtbaar worden.
Welke kwetsbaarheid wordt misbruikt (CVE-2026-39364)?
Vite bevestigde de kwetsbaarheid in een advisory (april 2026). Het gaat om een situatie waarin bestanden die niet bedoeld zijn om via de dev server te worden benaderd, tóch kunnen worden opgehaald. F5 Labs beschrijft dat wanneer bepaalde queryparameters worden toegevoegd, bestanden als antwoord terugkomen met HTTP 200, terwijl blokkades normaal zouden verhinderen dat ze worden geserveerd.
De advisory van Vite geeft voorbeelden van queryvarianten waarmee dit kan gebeuren, zoals het toevoegen van ?raw of combinaties zoals ?import&raw en ?import&url&inline. Vervolgens kan een aanvaller bijvoorbeeld bestanden benaderen die normaal zijn geblokkeerd via instellingen zoals server.fs.deny.
Wanneer is een app daadwerkelijk kwetsbaar?
Niet elke Vite setup is automatisch gevoelig. Volgens de beschrijving van de exploit zijn er drie voorwaarden nodig voordat een app als getroffen kan worden aangemerkt:
- De Vite dev server moet expliciet bereikbaar zijn voor het netwerk, bijvoorbeeld door –host of via de configuratie server.host.
- Het gevoelige bestand moet bestaan binnen de mappen die zijn toegestaan via server.fs.allow.
- Het betreffende bestand moet daarnaast vallen onder een patroon dat juist wordt geblokkeerd met server.fs.deny.
In standaardconfiguraties bindt Vite de dev server aan localhost. De risico’s ontstaan vooral wanneer ontwikkelaars de service openzetten met –host, server.host aanpassen, of wanneer containerpoorten verkeerd worden gemapt waardoor de dev server extern bereikbaar wordt.
Welke data kunnen aanvallers buitmaken?
De impact gaat verder dan “een bestand lezen”. In de waargenomen aanvallen werden requests gebruikt om te verkennen en vervolgens gevoelige configuratie- en statusbestanden op te halen. F5 Labs noemt onder andere de volgende datacategorieën:
- Environment-configuraties (vaak gekoppeld aan omgevingsvariabelen)
- AWS-credentials
- AWS-configuraties en backups
- Infrastructure state files, zoals terraform.tfstate en serverless.yml
- Azure-profielen
- Systeem- en omgevingsdetails, inclusief bestanden als /etc/passwd en omgevingsinformatie uit /proc en een actief .env-bestand
Een opvallend detail is dat aanvallers requests stuurden die blijk geven van kennis van de deploymentstack: door bijvoorbeeld /proc/self/cwd/.env te benaderen, kunnen ze het actieve .env-bestand lezen zonder het absolute webapp-pad te hoeven raden.
Hoe passen de requests omzeiling toe?
Het aanvalsmechanisme gebruikt het /@fs/-pad om naar een bestandlocatie te verwijzen en voegt daarbij queryparameters toe om de normale server.fs.deny-afhandeling te omzeilen. Daardoor lijkt de server toch het gevraagde bestand te verwerken, en wordt de inhoud teruggeleverd in plaintext in de body van de HTTP-response.
Omdat dit soort requests vaak geautomatiseerd is, zijn er ook sporen in de netwerk- en headerlaag. F5 Labs rapporteert dat de aanvallers User-Agent-headers verzonnen om bekende webcrawlers of AI-bots na te bootsen, zoals onder meer Googlebot-achtige en GPT/Claude/Perplexity-achtige varianten.
Daarnaast werden waarden voor X-Forwarded-For en X-Real-IP vervalst, wat het lastiger maakt om IP-gebaseerde toegangsregels en loganalyse op een rechtlijnige manier uit te voeren.
Waar komt het verkeer vandaan en hoe proberen ze detectie te omzeilen?
Een belangrijk deel van de activiteit kwam voort uit landen zoals de Verenigde Staten, België, Nederland, Singapore en Taiwan. Daarbij werden onder andere Google Cloud Platform-netwerkbereiken ingezet (bijvoorbeeld 34.x en 35.x).
Het patroon past bij “mass scanning”: niet per target maatwerk, maar breed zoeken naar dezelfde blootstelling en daarna gericht proberen te extraheren wat beschikbaar is.
Wat betekent dit voor jouw Vite development servers?
De praktische les is helder: development servers horen in principe niet publiek bereikbaar te zijn. Als je werkt met Vite, controleer dan specifiek of je ooit –host hebt gebruikt, of server.host is ingesteld op een waarde die meer biedt dan localhost, of dat containerpoortmappings je dev server onverwacht naar buiten hebben gebracht.
Verder is het verstandig om te toetsen of je configuratie klopt met de intentie van server.fs.allow en server.fs.deny. Ook al zijn die instellingen aanwezig, de kwetsbaarheid maakt duidelijk dat je niet alleen op “blokkeren” moet vertrouwen wanneer de dev server op een risicovolle manier is ontsloten.
Snel stappenplan: beperken, detecteren en herstellen
Onderstaand stappenplan helpt om risico’s rond Vite mass-scanning te verkleinen en mogelijke blootstelling te beperken:
- Sluit de dev server extern af: verwijder publieke bereikbaarheid en beperk toegang tot alleen de noodzakelijke netwerken.
- Beoordeel de Vite configuratie: check server.host, –host, en of Docker/hostingpoorten correct zijn gemapt.
- Herzie wat er in je environment files staat: ga ervan uit dat secrets (zoals API-sleutels) niet in bestanden moeten staan die per ongeluk benaderbaar kunnen zijn.
- Zoek in logs naar /@fs/ requests: let op patronen met queryparameters die lijken op raw/import varianten.
- Rotteer credentials indien nodig: als je verdachte requests hebt gezien of gevoelige bestanden hebt blootgesteld, ga uit van compromise en vernieuw secrets.
Door dit te combineren met een bredere kijk op je software supply chain en runtime-opzet, voorkom je dat een “kleine” dev-only fout verandert in een datalek met cloud-toegang.
Gerelateerd: waarom losse checks soms niet genoeg zijn
Deze casus laat opnieuw zien dat standaard “preventie-instellingen” in de praktijk onder druk komen te staan. Het concept van aanvallen draait regelmatig om het vinden van precies de zwakke stap in een keten. Als je wilt begrijpen waarom losse beveiligingschecks niet altijd werken, is deze uitleg relevant: Attack chains testen: waarom losse checks niet werken.
Ook bij andere exploitaties van omgevingen zien we dat het verschil tussen “intern” en “publiek” vaak het omslagpunt vormt. Dat maakt het extra belangrijk om niet alleen naar de code te kijken, maar ook naar bereikbaarheid en configuratiekeuzes.
Conclusie
Vite mass-scanning is geen hypothetisch risico: onderzoekers zagen geautomatiseerde aanvallen op internet-bereikbare Vite development servers, met CVE-2026-39364 als sleutel. Door queryparameters te misbruiken kan een aanvaller beveiligingsregels omzeilen en gevoelige bestanden—waaronder configuraties en cloudcredentials—terugkrijgen.
De beste verdediging is daarom preventief: houd dev services niet publiek bereikbaar, controleer je Vite host- en filesystem-instellingen en monitort actief op verdachte /@fs/-verzoeken. Heb je aanwijzingen dat je setup is blootgesteld, neem dan snel maatregelen zoals het intrekken en roteren van secrets.
Bron: https://thehackernews.com/2026/09/mass-scanning-campaign-exploits-vite.html
