There are weeks when attacks seem to “start with magic”. But in practice, almost always the same pattern applies: attackers exploit something that is already familiar, something that is online, or a weak assumption that nobody seriously tested. In this ThreatsDay roundup, two topics stand out in particular: n8n and Gogs RCE via workflow logic and Git hooks, respectively.
Concretely, this involves a maximum-severity Remote Code Execution flaw in Gogs (CVE-2026-52813) and a chain of issues in n8n (CVE-2026-33696) that—after limited permissions—can escalate to full code execution on your n8n instance. Below you’ll find what exactly goes wrong, why it’s dangerous, and which actions you can take today.
Why n8n and Gogs RCE spreads so quickly
RCE incidents are notorious because they give attackers a door straight into the core of your environment. What makes these two cases especially worrying is that they don’t rely on “extremely rare” conditions. They’re based on mechanisms that many organizations use in their day-to-day operations: Git repositories and automated tasks.
The key point is always the same: systems designed to do work can be turned into an execution engine with the right input. That shifts the focus from “just patching” to “patching plus verifying you can prevent misuse”.
Gogs RCE: remote code execution via Git hooks (CVE-2026-52813)
In Gogs, a maximum-severity vulnerability has been reported, with the core issue being that Git hooks can be overwritten via a path traversal scenario. The situation works like this: organization names that include path traversal sequences (such as ../) are accepted by Gogs. Then, repositories underneath those “wrong” paths get written out to filesystem locations that were not intended for that repository.
By carefully combining this with a nested structure of Git repositories, an attacker can influence each other’s configuration—ultimately resulting in the hooks configuration being overwritten. Once hooks are processed on the server, it can lead to Remote Code Execution.
What fixes are available
The problem has been fixed in Gogs version 0.14.3. Related issues were patched as well, including:
- CVE-2026-52810: a logic bug that causes writes to occur on read-only repositories.
- GHSA-6vxv-wg6j-5qwp: an XSS in the outdated “jsvine/notebookjs” component used to render Jupyter notebook files.
The report is attributed to Aikido Security.
n8n RCE chain: prototype pollution in nodes (CVE-2026-33696)
In n8n, the issue concerns a critical security flaw that can lead to remote code execution. It involves a scenario where a authenticated user, with permissions to create or modify workflows, can misuse a prototype pollution weakness in combination with the XML and the GSuiteAdmin nodes.
As described, prototype pollution on its own is already problematic because it can lead to crashing the entire n8n instance. But the real danger emerges when the weakness is chained to full code execution. Attackers can then run their commands as the n8n process user on the server.
Impact and conditions
The requirement of being “authenticated” makes this type of attack harder to detect with perimeter controls alone. You need internal oversight, role assignment, and workflow permissions to limit who can build workflows that later get misused.
Which versions you need
The vulnerability has been fixed in:
- n8n 2.14.1
- n8n 2.13.3
- n8n 1.123.27
The discoverer of the issue is Simon Koeck.
What you need to do now (practical checklist)
If you use n8n and Gogs, the steps below are primarily meant to reduce risk quickly. Prefer to finish them in this order.
1) Patch immediately and verify the version
- Upgrade to Gogs 0.14.3 (to stop n8n and Gogs RCE—the Gogs-side issue).
- Upgrade to an n8n version where CVE-2026-33696 is fixed (2.14.1 / 2.13.3 / 1.123.27).
After that, also check whether any older instances are still running (for example in test environments or forgotten containers).
2) Limit permissions around workflows and Git objects
In n8n, “authenticated” is a relevant threshold. Make sure only the right roles can create and modify workflows. In Gogs, the scenario is based on repository and path logic, so also restrict unnecessary rights for account types that are allowed to create repositories.
3) Check for signs of misuse
Even after you’ve patched, it’s worth checking whether misuse may have happened earlier. Look for:
- Unusual workflow changes shortly before the update.
- Unexpected changes in repository- or hook-related configuration.
- Suspicious system calls/activities that match code execution from the application context.
Exactly which signals you should search for depends on your logging and observability. If you use CI/CD, focus specifically on where credentials and secrets end up.
Supply chain risks: why “automation platforms” deserve extra attention
Vulnerabilities like this fall into the category that security teams often summarize as supply chain and operational automation risk. Not because it’s “third-party software”, but because your own processes and tooling form the route.
That’s why it helps to look at it more broadly: if you use n8n workflows or Git platforms to trigger scripts or build steps, then the impact of RCE is directly tied to your ability to keep secrets secure. So you don’t only want to patch—you also want to prevent a compromise of the tool from immediately reaching production systems.
More context on attacks that revolve around abusing trusted tooling can also be found in our article about vulnerabilities that break the sandbox promise. The same idea—“trust in a component gets exploited”—shows up in multiple variations.
AI and “agents” don’t automatically make detection easier
Alongside classic vulnerabilities, this roundup also describes how AI-assisted exploit research and automated chains can lower the bar for attackers. That doesn’t mean AI is the direct cause of your incident. It does mean attackers can move from idea to working steps faster.
That’s why it’s extra important to keep your patch management and your access and authorization rules tight. If the attacker can’t get past your tooling, “investigation” stays on paper.
If you want to zoom in on the broader governance and security question around AI applications, read Shady AI: the new governance risk for security as well. It’s not a direct match for n8n or Gogs, but it underlines why controls and boundaries remain crucial.
Final takeaway: turn patching into a process, not a one-off action
n8n and Gogs RCE aren’t incidents you solve with a single emergency update. Of course: upgrade to the fixed versions mentioned. But afterward, you also want to know who had permissions, what changes were made, and whether your workflows and repository content still “match” what you expect.
The message from ThreatsDay roundups like this is clear: the best defense isn’t one feature or one detection, but a combination of fast patches, minimal privileges, and continuous control over the “boring” edges of your systems. That’s where misuse often starts.
Source: https://thehackernews.com/2026/08/threatsday-gogs-100-rce-n8n-workflow-to.html
