Er zijn weken waarin aanvallen lijken te “beginnen met magie”. Maar in de praktijk geldt bijna altijd hetzelfde patroon: aanvallers misbruiken iets dat al vertrouwd is, iets dat online staat, of een zwakke aanname die niemand serieus testte. In deze ThreatsDay-ronde springen vooral twee onderwerpen eruit: n8n en Gogs RCE via respectievelijk workflowlogica en Git hooks.
Concreet gaat het om een maximale-severity Remote Code Execution in Gogs (CVE-2026-52813) en een keten in n8n (CVE-2026-33696) die, na beperkte rechten, kan uitlopen op volledige code-uitvoering op je n8n-instantie. Hieronder lees je wat er precies misgaat, waarom het gevaarlijk is en welke acties je vandaag nog kunt uitvoeren.
Waarom n8n en Gogs RCE zo snel om zich heen grijpen
RCE-incidenten zijn berucht omdat ze aanvallers de deur geven naar de kern van je omgeving. Wat deze twee gevallen extra zorgwekkend maakt, is dat ze niet leunen op “superzeldzame” randvoorwaarden. Ze draaien juist om mechanismen die veel organisaties in hun dagelijkse workflow gebruiken: Git-repositories en geautomatiseerde taken.
Het kernpunt is telkens hetzelfde: systemen die bedoeld zijn om werk uit te voeren, kunnen met de juiste input worden gekanteld tot een uitvoeringsmachine. Daardoor verschuift de focus van “alleen patchen” naar “patchen plus controleren of je misbruik kunt voorkomen”.
Gogs RCE: remote code execution via Git hooks (CVE-2026-52813)
In Gogs is een maximum-severity kwetsbaarheid gemeld met als kern dat Git hooks kunnen worden overschreven via een pad-traversal scenario. De situatie werkt als volgt: organisatienamen die path traversal bevatten (zoals ../) worden door Gogs geaccepteerd. Vervolgens worden repositories onder die “verkeerde” paden weggeschreven naar locaties op de filesystem die niet bedoeld waren voor die repository.
Door slim te stapelen met een nested structuur van Git repositories kan een aanvaller elkaars configuratie beïnvloeden, met als eindresultaat dat de hooks configuratie wordt overschreven. Zodra hooks op de server worden verwerkt, kan dat uitlopen op Remote Code Execution.
Welke fixes zijn beschikbaar
Het probleem is verholpen in Gogs versie 0.14.3. Daarbij zijn ook gerelateerde issues gepatcht, waaronder:
- CVE-2026-52810: een logic bug waardoor er wordt geschreven op read-only repositories.
- GHSA-6vxv-wg6j-5qwp: een XSS in de verouderde “jsvine/notebookjs” component die gebruikt wordt om Jupyter notebook-bestanden te renderen.
De melding wordt toegeschreven aan Aikido Security.
n8n RCE-keten: prototype pollution in nodes (CVE-2026-33696)
Bij n8n draait het om een critical security flaw die kan leiden tot remote code execution. Het gaat om een scenario waarin een geauthentiseerde gebruiker, met rechten om workflows te maken of aan te passen, misbruik kan maken van een prototype pollution kwetsbaarheid in combinatie met de XML en de GSuiteAdmin nodes.
Volgens de beschrijving kan prototype pollution op zichzelf al problematisch zijn doordat het kan leiden tot het crashen van de volledige n8n-instantie. Maar de echte dreiging ontstaat wanneer de zwakte wordt geketend tot volledige code-uitvoering. De aanvallers kunnen dan hun commando uitvoeren als de n8n-procesgebruiker op de server.
Impact en voorwaarden
De voorwaarde “geauthentiseerd” maakt dit type aanval vaak lastiger om te onderscheppen met alleen perimetermaatregelen. Je hebt interne controle, roltoewijzing en workflowrechten nodig om te beperken wie kan bouwen aan workflows die later misbruikt worden.
Welke versies je moet gebruiken
Het lek is gerepareerd in:
- n8n 2.14.1
- n8n 2.13.3
- n8n 1.123.27
De ontdekker van de fout is Simon Koeck.
Wat je nu moet doen (praktische checklist)
Als je n8n en Gogs gebruikt, zijn de acties hieronder vooral bedoeld om snel risico te verlagen. Werk ze bij voorkeur af in deze volgorde.
1) Patch direct en verifieer de versie
- Upgraden naar Gogs 0.14.3 (om n8n en Gogs RCE—de Gogs-kant—te stoppen).
- Upgraden naar een n8n-versie waarin CVE-2026-33696 is opgelost (2.14.1 / 2.13.3 / 1.123.27).
Check daarna ook of er geen oude instantiaties draaien (bijvoorbeeld in testomgevingen of vergeten containers).
2) Beperk rechten rond workflows en Git-objecten
Bij n8n is “geauthentiseerd” een relevante drempel. Zorg dat alleen de juiste rollen workflowcreatie en -wijzigingen mogen doen. Bij Gogs is het scenario gebaseerd op repository- en padlogica, dus beperk ook daar onnodige rechten voor accounttypes die repositories mogen aanmaken.
3) Controleer op aanwijzingen van misbruik
Ook wanneer je gepatcht hebt, loont het om te controleren of er eerder al werk is misbruikt. Denk aan:
- Ongebruikelijke workflow-wijzigingen vlak voor de update.
- Onverwachte veranderingen in repository- of hook-gerelateerde configuratie.
- Verdachte systeemcalls/activiteiten die passen bij code execution vanuit de applicatiecontext.
Welke signalen je exact moet zoeken, hangt af van je logging en observability. Als je met CI/CD werkt, koppel dan vooral aan de plek waar credentials en secrets terechtkomen.
Supply chain risico’s: waarom “automation platforms” extra aandacht verdienen
Dit soort kwetsbaarheden vallen in de categorie die we binnen security vaak samenvatten als supply chain en operational automation risico. Niet omdat het om “software van derden” gaat, maar omdat je eigen processen en tooling de route vormen.
Daarom helpt het om het breder te bekijken: als je n8n workflows of Git-platforms gebruiken om scripts of buildstappen aan te sturen, dan is het effect van RCE direct gekoppeld aan je vermogen om secrets veilig te houden. Je wilt dus niet alleen patchen, maar ook voorkomen dat een compromis van de tool meteen productiesystemen kan raken.
Meer context over aanvallen die draaien om misbruik van vertrouwde tooling vind je ook in ons artikel over kwetsbaarheden die sandboxbelofte doorbreken. Hetzelfde gedachtegoed—“vertrouwen in een component wordt uitgebuit”—zie je in meerdere varianten terug.
AI en “agents” maken opsporing niet vanzelf makkelijker
Naast klassieke kwetsbaarheden beschrijft de ronde ook hoe AI-assisted exploit-onderzoek en geautomatiseerde ketens de drempel voor aanvallen kunnen verlagen. Dat betekent niet dat AI op zichzelf de oorzaak is van jouw incident. Het betekent wel dat aanvallers sneller van idee naar werkende stappen kunnen gaan.
Daarom is het extra belangrijk om je patchbeheer en je toegangs- en autorisatieregels strak te houden. Als de aanvaller niet door je tooling heen kan, blijft “onderzoek” hangen op papier.
Als je daarbij wilt inzoomen op het bredere governance- en beveiligingsvraagstuk rond AI-toepassingen, lees dan ook Shady AI: het nieuwe governance-risico voor security. Het is geen direct match met n8n of Gogs, maar het onderstreept wel waarom controles en grenzen cruciaal blijven.
Slot: maak van patchen een proces, niet een losse actie
n8n en Gogs RCE zijn geen incidenten die je alleen met een noodupdate afdoet. Natuurlijk: upgrade naar de vermelde vaste versies. Maar daarna wil je weten wie rechten had, welke wijzigingen zijn doorgevoerd en of je workflows en repository-inhoud nog “kloppen” met wat je verwacht.
De boodschap uit dit soort ThreatsDay-overzichten is duidelijk: de beste verdediging is niet één feature of één detectie, maar een combinatie van snelle patches, minimale privileges en continue controle op de “saaiste” randen van je systemen. Daar begint misbruik namelijk het vaakst.
Bron: https://thehackernews.com/2026/08/threatsday-gogs-100-rce-n8n-workflow-to.html
