CVE-2026-102664: The ProxySQL Memory Disclosure That Can Expose Other Users' Queries

When a MySQL client uses compression, each packet states how long its contents will be after decompression. ProxySQL's zlib path checked that decompression succeeded, but not that the output actually matched the claimed length. A client could overstate that length, leaving the rest of a heap buffer uninitialized, and ProxySQL would then parse the leftover bytes as if they were real packets.

Those leftover bytes can be whatever was in memory before, including fragments of other sessions. They get forwarded to the backend, and error messages that reflect them can come back to the client. Malformed lengths can also trigger excessive memory allocation. The advisory notes that compression is on by default through mysql-have_compress, and that the zstd path already performed the check correctly.

Because the attacker needs a working database login, the realistic question is who has one. The risk is modest if a single application with one credential talks to ProxySQL. It rises considerably if multiple tenants, teams, or services with different permissions share a proxy, because a low-privilege account could then see fragments of far more sensitive traffic.

Application compromises are the other route. If an attacker steals your app's database credentials, perhaps from a leaked environment file, and can reach the proxy, this flaw could let them see more than those credentials allow. Customer-facing SQL consoles, BI tools, and internal admin tools that share the proxy all deserve a look, as does any AI feature that connects to your database.

Upgrade to at least 3.0.10, 3.1.10, or 4.0.10, on your branch. In practice, aim for the latest release. ProxySQL has published a steady run of advisories in 2026, including a critical pre-authentication heap overflow, CVE-2026-48773, in May, and October advisories covering pre-authentication memory exhaustion in the PostgreSQL packet path and out-of-bounds reads. Some of those list versions later than these minimums, so read the advisory list and do not stop at this CVE's fix.

If an upgrade needs planning, the advisory's reference to mysql-have_compress suggests disabling compression as a possible interim measure. The advisory does not present it as an official workaround, and clients that rely on compression may behave differently, so test it first. Either way, restrict who can connect.

Database proxies, connection poolers, and load balancers are easy to forget. Your team may watch database versions closely while a proxy installed during a scaling scramble runs untouched for years. It holds credentials, sees queries, and rarely causes visible problems, which is exactly why it drifts out of date.

The same thing can happen with AI-built products. An assistant recommends a proxy to fix too many connections errors, it works immediately, and nobody thinks about it again. The fix was reasonable. What is missing is an inventory entry, an upgrade routine, and a person who notices advisories for it.

If your product has reached the point of needing connection proxies, it has probably outgrown informal operations. An experienced engineer can map your data path, tighten network access and credentials, and put upgrades on a schedule. We do this kind of work when hardening AI-built products for production, and through retainers for teams that want ongoing ownership.