CVE-2025-61679: Anyquery Information Disclosure Flaw

CVE-2025-61679 Overview

Anyquery is an SQL query engine built on top of SQLite that exposes a Model Context Protocol (MCP) HTTP server for AI integrations. Versions 0.4.3 and below ship the local HTTP server without an authorization mechanism. Any process or user on localhost, including low-privilege accounts, can reach the MCP endpoint and query private integration data such as emails. The provider issues no foreign-login warning when this access occurs. The maintainers fixed the issue in version 0.4.4 by introducing a default bearer-token authorization layer. The vulnerability is tracked under CWE-200: Exposure of Sensitive Information to an Unauthorized Actor.

Critical Impact
Local low-privilege users can read private integration data (emails, connected services) through the unauthenticated MCP HTTP server on the loopback interface.

Affected Products

Anyquery versions 0.4.3 and earlier
Anyquery MCP HTTP server component (cmd/llm.go, controller/llm.go)
Local integrations exposed through the MCP server (email and other connected data sources)

Discovery Timeline

2025-10-03 - CVE-2025-61679 published to the National Vulnerability Database
2026-06-17 - Last updated in the NVD database

Technical Details for CVE-2025-61679

Vulnerability Analysis

Anyquery starts an MCP HTTP server on 127.0.0.1:8070 to serve AI clients such as language model agents. In versions 0.4.3 and below, the server accepts all requests on the loopback interface without verifying any credential. Any local process can call MCP tools like listTables and read data from integrations the user has configured, including email content.

The vulnerability falls under information exposure to an unauthorized actor. Exploitation requires only local access at low privilege. The attacker does not need to be the user that started the Anyquery process. Shared workstations, terminal services, and multi-tenant developer machines are exposed when one user runs Anyquery while another can reach the loopback port.

Integration providers receive no notice of the access because the MCP server itself queries the upstream service with the legitimate user's tokens. Victims see no foreign-login alert.

Root Cause

The MCP server was bound to localhost but treated network reachability as an implicit trust boundary. No bearer token, OAuth flow, or per-request authentication check existed in the request handlers. Local trust assumptions break on shared hosts where multiple users or unprivileged processes share the loopback interface.

Attack Vector

A local attacker sends HTTP requests to http://127.0.0.1:8070/ and invokes MCP tool calls such as listTables to enumerate accessible data sources. Subsequent tool calls return rows from integration tables, including stored email metadata and content. The attack runs without user interaction and requires no elevation.

// Source: https://github.com/julien040/anyquery/commit/43cd8bd3354b9725b245a2354b08e1c9be1cc1d3
// Patch in cmd/llm.go - registers the new --no-auth flag and keeps auth on by default.
addFlag_commandModifiesConfiguration(mcpCmd)
mcpCmd.Flags().String("host", "127.0.0.1", "Host to bind to")
mcpCmd.Flags().String("domain", "", "Domain to use for the HTTP tunnel (empty to use the host)")
mcpCmd.Flags().Bool("no-auth", false, "Disable the authorization mechanism for locally bound HTTP servers")
mcpCmd.Flags().Int("port", 8070, "Port to bind to")
mcpCmd.Flags().Bool("stdio", false, "Use standard input/output for communication")
mcpCmd.Flags().Bool("tunnel", false, "Use an HTTP tunnel, and expose the server to the internet")

// Source: https://github.com/julien040/anyquery/commit/43cd8bd3354b9725b245a2354b08e1c9be1cc1d3
// Patch in controller/llm.go - enables bearer token auth for HTTP mode by default.
useStdio, _ := cmd.Flags().GetBool("stdio")
tunnelEnabled, _ := cmd.Flags().GetBool("tunnel")

authEnabled := false
noAuthHTTPFlag, _ := cmd.Flags().GetBool("no-auth")
if !noAuthHTTPFlag && !tunnelEnabled && !useStdio {
    authEnabled = true
}

bearerToken := generateBearerToken()
if envBearerToken := os.Getenv("ANYQUERY_AI_SERVER_BEARER_TOKEN"); envBearerToken != "" {
    bearerToken = envBearerToken
}

s.AddTool(tool, func(ctx context.Context, request mcp.CallToolRequest) (*mcp.CallToolResult, error) {
    if authEnabled {
        suppliedToken := request.Header.Get("Authorization")
        if suppliedToken == "" {
            return mcp.NewToolResultError("Missing authorization token"), nil
        }
        suppliedToken = strings.TrimPrefix(suppliedToken, "Bearer ")
        // ... token comparison continues
    }
})

Detection Methods for CVE-2025-61679

Indicators of Compromise

Unexpected HTTP requests to 127.0.0.1:8070 originating from processes other than the user's authorized AI client.
MCP tool invocations such as listTables, describeTable, or executeQuery in Anyquery logs without an accompanying Authorization: Bearer header.
Outbound API traffic to integration providers (mail, cloud storage) initiated by the Anyquery process at times the user was not actively prompting their AI client.

Detection Strategies

Inventory hosts running anyquery binaries and capture the installed version through software asset queries.
Audit listening sockets on developer and shared workstations for the anyquery mcp process bound to TCP port 8070.
Inspect process command lines for the --no-auth flag on version 0.4.4 and later, since it disables the new default authentication.

Monitoring Recommendations

Log connections to loopback port 8070 using ss, lsof, or endpoint telemetry, and alert on connections from processes that are not the expected MCP client.
Forward Anyquery server logs to a central log store and alert on responses containing integration table names when no bearer header is present.
Correlate Anyquery activity with integration provider audit logs to identify reads not initiated by user activity.

How to Mitigate CVE-2025-61679

Immediate Actions Required

Upgrade Anyquery to version 0.4.4 or later on every host, including developer laptops and shared servers.
Stop any running anyquery mcp HTTP servers on unpatched hosts until the upgrade completes.
Rotate credentials and OAuth tokens stored in Anyquery integrations if multi-user systems ran a vulnerable version.
Audit recent integration provider access logs for unexpected reads that match Anyquery query patterns.

Patch Information

The fix is published in the Anyquery 0.4.4 release. Code changes are tracked in the security patch commit 43cd8bd and described in GitHub Security Advisory GHSA-5f7p-rhmq-hvc7. After upgrading, the MCP HTTP server generates a random bearer token on startup and requires it in the Authorization header. Operators can override the token by setting the ANYQUERY_AI_SERVER_BEARER_TOKEN environment variable.

Workarounds

Run Anyquery in stdio mode (--stdio) so the MCP server does not bind a network socket.
Restrict loopback access on multi-user hosts using host firewall rules or Linux namespaces so only the owning user can reach port 8070.
Avoid passing --no-auth on version 0.4.4 and later; keep the default authentication enabled for HTTP mode.
Stop running Anyquery on shared workstations and terminal servers until version 0.4.4 is deployed.

bash

# Configuration example: upgrade and launch with default authentication
go install github.com/julien040/anyquery@v0.4.4

# Set a stable bearer token for trusted MCP clients
export ANYQUERY_AI_SERVER_BEARER_TOKEN="$(openssl rand -hex 32)"

# Start the MCP HTTP server (auth is enabled by default in 0.4.4+)
anyquery mcp --host 127.0.0.1 --port 8070

# Clients must now send: Authorization: Bearer <token>
curl -H "Authorization: Bearer ${ANYQUERY_AI_SERVER_BEARER_TOKEN}" \
     http://127.0.0.1:8070/