mcp-pinot, the Bridge Between AI and Your Database, Lets Anyone In: CVE-2026-49257, Update to v3.1.0

mcp-pinot, the component that connects AI assistants to an analytics database, turned out to let anyone reach in from the outside and operate the database when left at its default settings. The vulnerability is tracked as CVE-2026-49257, and it received the maximum possible rating of 10.0 out of 10.

mcp-pinot is connector software published by StarTree, the company behind the real-time analytics database Apache Pinot. According to the vendor's security advisory, a no-authentication configuration was the default, so anyone who could reach it over the network could read and write the database's contents. A fixed version, v3.1.0, has been released.

What is mcp-pinot, and why are components like this multiplying?

Modern AI assistants no longer just generate text; they can reach into internal databases, files, and external services on their own to look things up. The shared standard that connects an AI to those external systems is MCP (Model Context Protocol). The software that tells the AI "what tools are available" and acts as the gateway that actually invokes those tools is called an "MCP server," and mcp-pinot is one of them.

What mcp-pinot connects to is a database called Apache Pinot, which StarTree helps develop. Pinot is a "real-time analytics database" that excels at returning aggregates and searches instantly over large volumes of data, used for things like access dashboards and per-user recommendations where you don't want to wait. With mcp-pinot in the middle, you can just ask the AI assistant to "pull this number," and the AI queries Pinot behind the scenes and returns the answer.

These "components that connect AI to real systems" have exploded over the past year or two. On this site we have covered the takeover hole in LiteLLM, the Langflow case attacked within 20 hours of release, and the Langroid case where AI-written SQL hijacks a database. The more convenient connector parts there are, the more those "joints" become new entry points for attacks.

Who comes to the unlocked gateway, and what do they walk off with?

A perfect 10.0 severity is rare. It is assigned only when the conditions line up so that no prior privileges, no trickery against a user, and no advanced techniques are needed at all—just network reach is enough to operate the entire database. That is exactly why it is worth picturing, without the jargon, who reaches for that wide-open gateway.

Those who come are attackers who mechanically scan the whole internet for "servers you can hit without authentication," theft rings that steal and resell corporate data, ransomware operators who encrypt your data and demand payment, and intruders who, once inside a corporate network, try to spread sideways. What they get is the behavioral records and purchase histories stored in Pinot, service usage data, the personal data behind the analytics, and the operating power to rewrite or delete the database structure itself. If it is left open at the defaults, they aren't even asked for a passphrase: they can wield the whole toolkit prepared for the AI with their own hands.

Technically, mcp-pinot proxies the attacker's request using the server's strong privileges to Pinot and runs it as-is. This is a classic weakness called the "confused deputy," where an otherwise unprivileged party gets to do as they please by borrowing the server's privileges. Once the gateway is found, the attacker can not only read data but rewrite table structures, fire off heavy queries to slow the service, and enumerate cluster information to use as a foothold for the next attack.

The "10.0 severity" figure only marks the maximum of technical seriousness. For anyone entrusting business data to Pinot, what is truly lost is the pile of data handed over by customers, and the trust and compensation owed when it leaks. The frightening picture here is that what was meant to hand the AI a convenient tool instead handed out the keys to that toolbox to the whole world.

What actually happens with CVE-2026-49257

The core of the flaw is that a critical function has no authentication. Technically it is classified as missing authentication (CWE-306, the problem of an operation that should require login or a permission check being executable by anyone). The vendor advisory (GHSA-73cv-556c-w3g6) explains that three insecure defaults combined to cause it.

• The authentication mechanism (OAuth) is off by default (oauth_enabled = False)
• Tied to that off setting, the authentication handling itself is never wired in
• The listening address is open to all interfaces (0.0.0.0:8080), reachable from outside

When these three line up, anyone who can reach port 8080 over the network can invoke every tool mcp-pinot exposes. Those include powerful operations such as running SQL (commands to the database) and changing table designs. Because mcp-pinot proxies these calls using the server's Pinot credentials, an attacker gains full read/write to the configured Pinot cluster while remaining unauthenticated.

The NVD (the U.S. government's vulnerability database) rated it a perfect 10.0, accounting for the fact that it needs no prior privileges and no user interaction and that the impact can spread beyond the original software (a scope change). It was reported by raysabee and PeledTomer1, and there are no reports of actual exploitation as of disclosure. Still, "servers you can hit without authentication" are easily found by mechanical scanning, so anything exposed externally needs prompt action.

Am I affected, and which versions are at risk?

You are affected if you use mcp-pinot and run an old version at its defaults in a place reachable from outside. Check the table below.

What to watch is that the defaults faced outward (0.0.0.0:8080, auth off). Even if you believe you only use it on an internal network, if you have not revisited the settings there is room to be targeted by an attacker who got inside or by a server accidentally exposed to the outside. First confirm "from where my mcp-pinot is reachable."

How should I respond?

The basic response is to update mcp-pinot to v3.1.0 or later. According to the advisory, the fixed version revises the dangerous defaults: the default listening address changed from the outward-facing 0.0.0.0 to local-only 127.0.0.1, and it now refuses to expose itself externally unless authentication is enabled. Update steps are in the official repository.

If you cannot update right away, the advisory lists three stopgaps. First, enable authentication (OAUTH_ENABLED=true). Second, restrict the listening address to local only (MCP_HOST=127.0.0.1). Third, block outside access to port 8080 with a firewall. All are temporary; the real fix is updating.

If you cannot fully track which AI connector parts you run and with what settings, a tool like an open-source vulnerability scanner that automatically flags risky versions from a list of the parts you use helps prevent oversights. MCP servers in particular sell themselves on "connect the moment you run it," so it is easy to leave the outward-facing defaults untouched.

Why do "AI connector gateways" keep having no-auth holes?

This mcp-pinot case is not an isolated accident. Throughout 2026, MCP servers that connect AI to external systems have repeatedly been found running with no authentication as the default. Security firm Akamai's research reports the same type of weakness recurring in the back-end of MCP servers. Prioritizing convenience with "connect right away" defaults has pushed the basic defense of authentication to the back burner.

Attackers are also using AI to speed up their hunt for weaknesses. On this site we covered the structure in which AI accelerates attacks while AI also creates more holes. When you hand an AI assistant the tools to reach internal systems, it matters more than ever to inspect not just the AI's intelligence but "whether that connector gateway is properly guarded with authentication" and "whether it is open to the outside."

Frequently asked questions

Q. Am I safe if I only use it on an internal network?

A. Don't let your guard down. Because the defaults face outward (0.0.0.0) with auth off, there is room to be targeted by an attacker who got into your network or by a server exposed externally through a misconfiguration. It is safest to restrict the listen address to 127.0.0.1, enable authentication, or block it with a firewall, and then update.

Q. Is the hole in Apache Pinot itself?

A. No. This vulnerability is a default-settings problem in mcp-pinot, the connector between AI and Pinot. However, mcp-pinot runs with strong privileges to Pinot, so if it is abused, the data on the Pinot side is put entirely at risk.

Q. Does updating really fix it?

A. Yes. In v3.1.0 the listen address changed to local only (127.0.0.1), and it now refuses external exposure unless authentication is on. Updating to the latest version is the reliable response.

Summary

CVE-2026-49257 is a flaw in mcp-pinot, the connector between AI assistants and the analytics database Apache Pinot, that lets anyone reach in from outside and operate the database at default settings. Rated the maximum 10.0, three combined defaults—auth off and an outward-facing listen address—left an unauthenticated attacker with full read/write to the database.

It affects v3.0.1 and earlier and is fixed in v3.1.0. If you cannot update right away, enabling authentication, restricting the listen address, and blocking with a firewall are stopgaps. MCP servers, which hand AI real tools, tend to turn their "joints" into new entry points behind the convenience. The more you adopt connector parts, the more a habit of inspecting authentication and exposure becomes your best defense.

References

• ▸ NVD - CVE-2026-49257 Detail
• ▸ mcp-pinot Security Advisory - GHSA-73cv-556c-w3g6
• ▸ CVE.org - CVE-2026-49257 Record
• ▸ mcp-pinot - GitHub repository
• ▸ Akamai - Research on MCP back-end vulnerabilities