Imagine leaving your company's entire database of business intelligence — your sales figures, customer queries, internal reports — with the front door not just unlocked, but with the lock removed entirely.

Who's at Risk — and Why It Matters

Vanna AI is a widely-used open-source Python library that lets companies query their databases using plain English. Instead of writing complex database queries, employees just ask questions — "What were our top-selling products last quarter?" — and Vanna translates that into database language and fetches the answer. It's the kind of tool that data teams at startups, mid-size companies, and enterprises have quietly woven into their internal analytics stacks.

The library has thousands of GitHub stars and active community adoption. Developers often stand up Vanna's built-in web interface — powered by a component called the Flask API — for internal dashboards or demos. That's exactly where the problem lives. Any organization running Vanna version 2.0.2 or earlier with the Legacy Flask API exposed — even on an internal network — could be sitting on a vulnerability that lets an unauthenticated remote attacker issue commands as if they were a fully trusted user.

What an Attacker Can Actually Do

Think of a building's security desk. Normally, every visitor has to show ID, sign in, and get a badge before they can walk the halls. This vulnerability is the equivalent of a side door where the security desk doesn't exist at all — no ID check, no sign-in, no questions asked. Anyone who knows the door is there can walk straight through it.

In practice, an attacker who discovers a Vanna instance doesn't need a password, a stolen account, or even a sophisticated hacking tool. They can simply send requests directly to the API — the programming interface that Vanna uses to receive and respond to commands — and the system will treat them as a legitimate, authorized user. Depending on how Vanna is configured, that could mean reading the underlying database, extracting query history, or manipulating the AI model's behavior to produce malicious or misleading results.

The especially concerning part: Vanna is often connected to real business databases. If your team uses Vanna to query a customer database, a financial reporting system, or an internal data warehouse, an attacker who gets through that unlocked door isn't just playing with an AI toy — they may be standing directly in front of your most sensitive business data.

The Technical Detail Security Teams Need to Know

The vulnerability — tracked as CVE-2026-6977 — is classified as an Improper Authorization flaw (CWE-285) residing specifically in the Legacy Flask API component of the vanna-ai/vanna library. It carries a CVSS score of 7.3 (HIGH) under the Common Vulnerability Scoring System. The attack vector is network-based, requires no authentication, and demands no user interaction — a trifecta that pushes it firmly into "patch immediately" territory for any security team's priority queue. The vulnerability affects all releases up to and including version 2.0.2.

How Was This Found — and Has Anyone Been Hit?

The flaw was discovered and publicly disclosed by an external researcher. In a pattern that has become frustratingly common in the open-source security world, the Vanna AI vendor was contacted prior to public disclosure and did not respond. That silence meant the researcher had no choice but to release details publicly — which means the exploit information is now available to anyone, including malicious actors actively scanning for vulnerable instances.

As of publication, there is no confirmed evidence of active exploitation in the wild. However, the public availability of exploit details significantly compresses the window between "theoretical risk" and "active attacks." Security researchers have observed that authorization-bypass vulnerabilities in API-driven tools tend to attract automated scanners within days of public disclosure — particularly when the affected software is commonly deployed in cloud or containerized environments, as Vanna often is.

No specific threat actors or victim organizations have been publicly named in connection with this vulnerability at this time.

What You Should Do Right Now

1. Upgrade Vanna immediately. Update to the latest version of the vanna-ai library beyond 2.0.2. Run pip install --upgrade vanna in your Python environment and verify the installed version with pip show vanna. Do not continue running any instance at version 2.0.2 or below.
2. Audit and restrict access to your Legacy Flask API endpoint. Check whether your Vanna deployment is using the Legacy Flask API interface and whether it is reachable from outside your immediate application environment. If you do not need the Legacy Flask API, disable it. If you do need it, place it behind a firewall rule, a VPN requirement, or an authentication reverse proxy (such as Nginx with basic auth or an OAuth gateway) immediately — even before you can patch.
3. Review your logs for unexpected API requests. Look back through your web server or application logs for any unusual or unauthenticated requests to your Vanna API endpoints — particularly from unfamiliar IP addresses. Pay special attention to requests that executed database queries or accessed model configuration endpoints. If you find suspicious activity, treat it as a potential breach and follow your incident response procedures.