2026-08-19 · CVE-2026-33696: From a Schema Name to RCE in n8n

Transcript

Transcript. Paraphrased; sources in notes.md.

HostIt is August 19th, 2026. Welcome back. I am Daniel, and sitting across from me is our resident skeptic, Alex. Today we are looking at a classic prototype pollution vulnerability in n8n, the philosophical friction between hobbyist coders and LLMs, and finally, why someone would choose to write Lisp in the age of AI. Alex, I saw you staring at your coffee machine when I walked in. Are you already running a threat model on the brew cycle?

GuestDaniel, it is not a coffee machine, it is a networked liability with a sensor package. If it is talking to an API, it is talking to a recruiter for a botnet. Honestly, I saw the writeup about n8n today and I felt a strange sense of relief. It is exactly the kind of mess I expect.

HostYou mean the prototype pollution in the GSuiteAdmin node. For our listeners, n8n is a workflow automation tool that lets you connect various apps together. The author of this writeup found that you could pass a custom schema name that gets treated as a property key, allowing an attacker to inject into the Object prototype.

GuestExactly. It is a textbook failure. The developer assumes the input is just a string, but the language allows that string to be a pointer to the entire environment's base object. The author explains that by polluting that object with an environment variable like GIT_SSH_COMMAND, they could force the Git node to execute arbitrary code. It is beautiful, in a horrifying way. It is a reminder that if you are not explicitly sanitizing every key, every field, and every single configuration parameter, you are essentially leaving the keys to the kingdom under the doormat.

HostIt is a stark reminder, definitely. I checked the Lobsters thread for this, and interestingly, there was not much discussion. It seems like a clean kill. People just read it and moved on, probably because it is so straightforward.

GuestOr maybe they are all busy fixing their own GSuiteAdmin nodes. I wouldn't bet against that.

HostMoving on to something a bit more existential. There is a great piece up on the blog of a developer named Fogus about why hobbyist communities, like those building emulators or operating systems, are so hostile toward AI. Fogus argues that for these people, the process is the point. The struggle is the product.

GuestI have a lot of time for this take. The "AI boosters," as a Lobsters user called mattgreenrocks puts it, want to skip to the end. They want the result without the misery of learning how a CPU actually executes an instruction. But in these niches, the misery is where the mastery comes from. If you automate the struggle, you aren't doing the hobby anymore, you are just running a prompt-engineering script.

HostRight, but there is pushback. In the same thread, a user named davepagurek makes the point that the "gatekeeping" and slow pace aren't necessarily about elitism. He argues that in complex software design, the bottleneck is reaching a consensus on architecture, not writing the code. An AI can type out functions faster, but it doesn't help you with the shared imagination required to keep a project from collapsing under its own weight.

GuestDave is onto something. You can have a thousand lines of code generated in seconds, but if you don't know why those lines were written, you are just accumulating technical debt at the speed of light. I have a small static analysis tool I use to audit dependencies, and honestly, the amount of garbage I see coming into repositories under the guise of "AI-assisted development" is staggering. It is just faster ways to build unmaintainable, insecure software.

HostThat brings us to our final topic, which is a bit of a counter-argument. A blog post titled Why vibe code in Lisp suggests that Lisp is actually the perfect language for this AI era. Lisp, for the uninitiated, is a family of programming languages characterized by its use of prefix notation and powerful macro systems. The author argues that because Lisp is homoiconic, meaning the code is structured as data, an AI can parse and manipulate the abstract syntax tree directly.

GuestI am skeptical of the "vibe coding" label, but I get the Lisp argument. If you want a machine to rewrite your code, you want a language that doesn't hide its structure behind layers of syntax sugar. Lisp is just lists. It is easier to program a machine to manipulate lists than it is to teach it to navigate the mess of modern mainstream languages.

HostA Lobsters user named puhsu shared a talk about how Lisp allows for what they call M-x all the way down, referencing the command interface in Emacs, meaning you can manipulate abstraction levels dynamically. But a user named zem pushed back, pointing out that even with AI, the code is an artifact. You are still sculpting something, and using an AI doesn't change the fact that you need to own the final result.

GuestThat is the core of it, Daniel. If you don't own the code, you can't secure it. And if you can't secure it, I don't care how elegant your macros are or how fast your AI can generate your REPL sessions. You are building on sand.

HostA sobering thought to end on. I think I will stick to my plain text files for now.

GuestGood plan. Although, make sure you audit your editor plugins first. Those things are just Trojan horses with better fonts. I saw a report the other day about an IDE extension that was doing things I wouldn't dream of.

HostI am going to choose to remain blissfully ignorant of that one for the weekend. Thanks for coming on, Alex. All these stories and more are available over on Lobsters. We will be back tomorrow, so see you then.