Critical n8n + Supabase Flaw: Check Your Workflows Today

Your website can be fully updated and still be compromised, and today’s first story shows exactly how. A flaw involving n8n and Supabase can turn your own automation against your database. We’ve also got WordPress malware that comes back after you delete it, a critical JavaScript sandbox flaw that matters if you’re building with AI, and new Apache security fixes for the server underneath your website.

I’ve spent 25 years building production software, and here are the five security stories you need to know today.

Let’s start with n8n, because this one’s important. If you’re building with AI, there’s a critical vulnerability in the n8n Supabase integration. The problem involves the table ID: an attacker can control that value, and they may be able to change where n8n sends the request.

That creates a much bigger problem, because n8n may be connecting with the Supabase service role key. That’s a powerful credential, and it’s designed to bypass row-level security. So here’s the interesting part: your Supabase security could be configured correctly, and your row-level security could be working correctly, but the attacker isn’t necessarily attacking Supabase.

They’re tricking n8n into using its own privileges against the wrong endpoint. That’s called a confused deputy problem, and it’s becoming increasingly important with AI agents and automation. So update n8n to a patched release.

Then check your Supabase workflows, especially anything receiving values from forms, webhooks, APIs or AI agents. Your database may not be the weak point; the automation in front of it might be.

Next up, there’s some interesting WordPress malware, because deleting it may not actually remove it. Researchers have documented malware designed to rebuild itself. Different parts can exist in different places: some in WordPress files, some in the database, and some outside WordPress entirely.

That creates a nasty situation. You find the malicious PHP file, you delete it, you scan the website, and everything looks clean. Then another component recreates the infection.

That’s why patching and incident response are two different things. Updating the vulnerable plugin closes the original door, but it doesn’t automatically remove someone already inside. So after a compromise, don’t just scan the plugins folder.

Check the database, check scheduled tasks, check must-use plugins, check uploads and check recently modified files. If you control the server, check outside WordPress as well. Sometimes the safest recovery isn’t cleaning the website; it’s rebuilding it from a known clean environment.

Next, this one’s for anyone building applications with AI. New vulnerabilities have been found in vm2. vm2 is a JavaScript sandbox, designed to let applications run untrusted JavaScript without giving that code access to anything else.

One of the new vulnerabilities has been rated critical, and under affected configurations, the restrictions around Node modules can potentially be bypassed. That’s particularly interesting because of AI. We’re increasingly letting AI write code, and then we’re letting systems execute that code.

One common assumption is that it’s inside a sandbox, so we’re safe. But the sandbox is software too, and software can have vulnerabilities. So if you’re building AI agents, code runners, automation platforms or development tools, check whether you’re using vm2 and update affected versions.

Don’t make an application-level sandbox your only security boundary. If the sandbox fails, you need another boundary behind it.

Next up, Apache has released version 2.4.69, and it fixes multiple security vulnerabilities. The issues cover several different attack types, including information disclosure, security control bypasses, denial of service and potentially code execution. The important part isn’t that every Apache server is suddenly exploitable; the actual risk depends on your configuration and which modules you’re running.

But this highlights something website managers often forget: your application isn’t the only layer. WordPress can be updated, your plugins can be updated and your application code can be secure, but underneath all that, there’s still a web server. If nobody’s maintaining it, that’s another attack surface.

So check your infrastructure and find out which version of Apache you’re actually running. Then check whether the vulnerabilities fixed in 2.4.69 apply to your configuration, because website security doesn't stop at the CMS.

And finally today, a WordPress backup plugin called BackupSheep has a critical vulnerability. This one is a great example of why security tools need security too. The vulnerability involves how the plugin validates its integration key, and under the vulnerable condition, an empty key can potentially be treated as valid.

That could allow an unauthenticated attacker to generate and download a complete website backup. That can include your WordPress files and your database configuration information. The plugin has now been closed on WordPress.org.

So if you’re running BackupSheep, don’t just deactivate it. Check whether backups were generated unexpectedly, and check whether files were accessed or removed. If you can’t establish whether the credentials were exposed, rotate them.

Think about what a backup plugin can access: basically everything. We install backup software to protect the website, but that also makes it one of the most privileged components on the entire system.

And that’s the pattern in today’s briefing. The vulnerable component isn’t always your website. It might be your automation platform, your JavaScript sandbox, your web server, your backup system, or something you thought you’d already removed.

This matters even more when you’re vibe coding, because AI makes it incredibly easy to connect systems together. But every connection creates another trust boundary. Understanding those boundaries is what turns working software into production-ready software. That’s today’s security briefing.