When FIRST — the Forum of Incident Response and Security Teams — published its midyear vulnerability forecast on June 15, the headline was 66,000 projected CVEs for 2026. That's a 46% overshoot from what they predicted in February.
The number getting less attention is this one: a 449% year-over-year surge in GitHub Security Advisories.
GitHub Security Advisories aren't about Windows Update or router firmware. They're for open-source software — the stuff that lives in package managers, runs in Docker containers, and gets installed by small teams specifically because it's free, auditable, and not dependent on a single vendor. They cover tools like n8n, Langflow, Flowise, Dify, and LibreChat — the same open-source AI workflow builders that got popular exactly because the pitch was "host it yourself, own your data."
If your team went down that path, the June 15 data is worth understanding.
Why GHSA volume is a different problem than Patch Tuesday
Most small org IT conversations around vulnerabilities focus on Windows patches and firmware updates. Those matter. But GitHub Security Advisories cover a completely separate ecosystem — the open-source packages your developers install, your operations team deploys, and your infrastructure runs on.
The 449% surge isn't happening because open-source software suddenly got worse. It's happening because AI-powered vulnerability scanners are now continuously auditing open-source codebases and finding issues that years of manual code review missed. FIRST identifies this specifically as one of three structural drivers behind the broader CVE surge — alongside a 3,119% increase in VulnCheck CNA-of-Last-Resort activity absorbing a previously ignored backlog.
The category of open-source software attracting the most attention right now is AI tools. They're relatively new, built fast during intense competition, and they interact with sensitive systems in ways that make vulnerabilities especially high-value for attackers.
What's actually happening to n8n and Langflow
These aren't theoretical concerns. Here's what 2026 has looked like for two of the most widely deployed open-source AI workflow tools:
n8n has two critical CVEs this year. CVE-2026-21858 is a content-type confusion flaw rated CVSS 10.0 — the maximum possible severity — that allows an unauthenticated attacker to bypass automation controls entirely. CVE-2026-25049 lets authenticated users execute arbitrary system commands through crafted workflow expressions. On a typical deployment, that second vulnerability gives an attacker who gets a valid session — through phishing, credential stuffing, or just the first CVE — the ability to run shell commands on the server n8n is running on.
Langflow has been hit three times this year. CVE-2026-5027, the most recent, is a path traversal vulnerability in the file upload endpoint that allows writing files to arbitrary locations on the filesystem. The reason it's particularly dangerous: Langflow ships with auto-login enabled by default. That means a single unauthenticated HTTP request is enough to get a valid session token. From there, the attacker can write files anywhere. Censys scanning identified roughly 7,000 publicly exposed Langflow instances. Most of them are likely unpatched.
The pace of exploitation is the part that changes the calculus. When Langflow's CVE-2026-33017 was published in March, attackers were observed actively exploiting it within 20 hours of the advisory going public. Not 20 days. 20 hours. There's a category of threat actor — increasingly automated — that monitors vulnerability databases specifically for high-severity CVEs in popular open-source tools and immediately scans the internet for exposed instances. If you haven't patched within that window, you're in the attack window.
Why these tools are a higher-value target than they look
A compromised n8n instance isn't just "someone got on a server." These tools are designed to connect to things. A typical deployment might hold:
- LLM API keys for OpenAI, Mistral, or whoever you're using
- OAuth tokens for your Google Workspace, Microsoft 365, or Slack
- Database credentials for your CRM or operations systems
- Credentials to internal APIs or cloud storage buckets
- Webhook secrets that let an attacker impersonate your automation triggers
This is why the open-source AI tool layer is the attack surface getting weaponized right now. High privilege, relatively new, and usually deployed with less hardening than a customer-facing application would get. When a small org deploys Langflow to "control their own data," the self-hosted deployment often has more access to sensitive systems than their main website does — and it may have received significantly less security review.
The pitch for self-hosting AI tools is legitimate. Keeping data in-house, avoiding vendor lock-in, controlling your infrastructure — these are real benefits. But self-hosting only delivers on that promise if you're also managing the security of what you're running.
What to do
Subscribe to GitHub Security Advisories for every tool you self-host. Go to the GitHub repository for each open-source tool you're running. Click "Watch," then "Custom," and enable "Security alerts." GitHub will notify you directly when a new advisory is published for that project. For tools managed through a package manager, Dependabot can do this automatically. This costs nothing and takes ten minutes per tool.
Check your current version against known CVEs right now. For each tool you run, search "CVE 2026 [tool name]" and confirm you're not running a version with an unpatched critical vulnerability. n8n, Langflow, and Flowise all have patches available for their critical 2026 CVEs. If you're on an older version, this is the week to update.
Stop exposing these tools directly to the internet. The 7,000 Langflow instances identified in Censys scans are accessible without authentication from anywhere on the internet. That's the entire attack surface problem in one configuration choice. If your AI workflow tools need to be accessed remotely, put them behind a VPN or an IP allowlist. A public endpoint is not the right answer.
Audit your default settings. Multiple open-source AI tools ship with auto-login enabled for ease of setup. That's reasonable during local development. It's a critical risk in any deployed environment. Check the default settings of every tool you run and disable anything that removes the authentication step. Look specifically at: auto-login, anonymous access, open API endpoints, and default admin credentials.
Know what access these tools actually have. List out what API keys, OAuth tokens, and credentials are stored in or accessible to each tool you're running. If a tool were compromised today, what could an attacker reach? For many teams, that list is longer than expected. Scope that access to the minimum required and rotate credentials that don't need to persist.
The 449% surge in GitHub Security Advisories is not a Windows patch problem. It's a problem for every team that has deployed open-source AI tools and treated "install and configure" as the end of the security conversation.
The tools are worth running. The workflow capabilities they offer are real, and the self-hosting model genuinely does give small orgs more control — when done right. "Done right" includes treating these deployments as production software: monitored, kept current, and configured with the assumption that someone will try to exploit them.
Every AI deployment sprint we run includes a review of what's self-hosted, what access it has, and whether the configuration matches the risk. If you've deployed open-source AI tools in the last twelve months and haven't done that review, it's a reasonable thing to do this month.