Two Critical Flaws in ProxySQL (CVE-2026-48772 / 48773): Source Spoofing and Pre-Login Memory Corruption, Upgrade to v3.0.9 Now

Two serious vulnerabilities have been found in ProxySQL, a widely used piece of software that distributes traffic to databases such as MySQL and PostgreSQL. One scores a maximum 10.0 out of 10 on the danger scale: it lets an attacker fake where their connection is coming from and slip past access controls. The other can corrupt the server's memory and bring it down before anyone even logs in.

What makes both nasty is that they require no authentication (no login) to exploit. The vendor, sysown, shipped a fixed release, ProxySQL 3.0.9, on June 4, 2026 and is urging users to upgrade immediately. The vulnerabilities are tracked as CVE-2026-48772 and CVE-2026-48773. This article explains which software is affected, what the risk is, and how to check whether your own setup is exposed.

What ProxySQL is: the "traffic controller" in front of your database

ProxySQL is a relay that sits between your application and your database. When a web service or app takes heavy traffic, the number of database queries spikes too. ProxySQL keeps the whole thing from grinding to a halt by spreading those queries across multiple databases and sorting them, for example sending writes to the primary server and read-only queries to replicas.

It is free open-source software, yet fast enough that it runs behind many high-traffic services. On top of MySQL and its relatives (MariaDB, Percona, AWS Aurora and so on), recent versions also support PostgreSQL. In other words, even if you have never heard the name, it is not unusual for ProxySQL to be sitting in front of the database of a service you use.

Because it guards the "front door" to the database, a hole here has an outsized impact: ProxySQL single-handedly decides how reads and writes are routed and who is allowed to connect. For more on protecting the database itself, see our deep dive on primary key design tested at 10 million rows.

Two critical flaws were disclosed

The disclosure covers two vulnerabilities of different natures. Here is the big picture in a table.

CVSS is an international scale that rates how serious a vulnerability is from 0 to 10, where higher is worse. The U.S. National Vulnerability Database (NVD) rated CVE-2026-48772 a perfect 10.0 (the vendor's own GitHub Advisory lists it as 9.1, so scoring bodies differ slightly). The other, CVE-2026-48773, sits at 9.8 — both high enough to be classed as "critical."

Who would target this, and why

The CVSS number alone doesn't tell you whether this matters to you, so let's break it down. The people who would actually exploit these holes are attackers scanning the internet for exposed database front doors. Out of the box, ProxySQL will trust the "self-reported source" of any connection, no matter where it comes from. For an attacker, that is an inviting target you can reach without even stealing a password.

What they do splits into two paths. With the first flaw, they forge their source so it looks like "I'm coming from a trusted spot inside the corporate network," slipping past access rules that should have blocked them. Rules like "only allow writes from this location" or "only let this address range reach the primary database" get sidestepped with a fake address. With the second flaw, they send a deliberately malformed first message and corrupt ProxySQL's memory before they ever reach the login step.

For ordinary users of a service, the damage shows up as a site or app that suddenly gets slow or stops responding. For the companies running the system it is more serious: once access controls stop working, reads and writes that should never have been allowed can go through. And when the source is spoofed, a fake address ends up in the access logs too, making it harder to trace who did what afterward. This kind of attack against databases echoes cases like Spring AI being manipulated without a login and a database hijacked through AI-written SQL.

A closer look at the two flaws

Now for the technical details — why each hole works.

CVE-2026-48772: spoofing the source address to bypass access controls

This one centers on the "PROXY protocol." It is a convention by which a relay device — a load balancer, say — tells the server "the real source of this connection is this IP address," and it was originally defined by HAProxy. ProxySQL takes that information and uses it for access-control decisions.

The trouble is that the protocol has an "UNKNOWN" mode for when the source is unknown. The spec is explicit: if it says UNKNOWN, the receiver "MUST ignore any address fields" that follow. But ProxySQL read those address fields anyway, even when marked UNKNOWN, and accepted the value as the genuine source. According to the vendor's security advisory (GHSA-gw94-85m2-x8v2), an attacker exploits this misreading to declare any IP address as their own source.

The default configuration makes it worse. The setting mysql-proxy_protocol_networks defaults to '*' (allow everything), meaning "accept the PROXY protocol self-report from any connection." So a default install exposed to the outside lets anyone use this spoofing trick. Any rule based on source IP — read/write routing, restricting schema changes to a specific range — can be nullified.

CVE-2026-48773: memory corruption that crashes the server before login

The second flaw hides in the very first exchange of a database connection. When a client connects to ProxySQL, it first declares "I'm about to send data of roughly this size" (the packet length). ProxySQL trusts that number and sets aside a receive buffer — but if an attacker declares a length far larger than reality, the write overruns the 32 KB input buffer and spills into memory. This is the classic memory-corruption class known as CWE-787 (out-of-bounds write).

Because this runs before authentication, the attack works without any valid username or password at all. It is reported to affect the entry point on the PostgreSQL side as well as MySQL, so the exposure is broad. Memory corruption first leads to a server crash (a service outage), and depending on conditions it can escalate to deeper abuse. ProxySQL 3.0.9 also fixes a separate large-packet bug (a double-free) at the same time.

Is your setup at risk? A version cheat sheet

You can check your ProxySQL version with proxysql --version. Find the matching row below.

If you are on 2.0.0–3.0.8, you are affected by at least one and usually both. The fix landed in 3.0.9, and the vendor has backported the same fix to 3.1.9 and 4.0.9 for those on other branches. Pick the latest release that matches your branch.

What to do: mitigation and upgrade steps

The surest fix is to upgrade to 3.0.9 or later. If you installed via a package manager, refresh the repository, replace the ProxySQL package, and restart the service. If you run the Docker image, switch the tag to 3.0.9 or later and rebuild the container.

If you genuinely cannot upgrade right away, three stopgaps help limit the damage. First, don't leave mysql-proxy_protocol_networks at '*' — restrict it to the IP range of trusted devices such as your load balancer. Second, don't expose the port ProxySQL listens on directly to the internet; keep it behind a firewall or inside the internal network. Third, audit any access rules that rely on source IP and confirm your design doesn't lean on that alone. These only buy time, though; the real fix is still the version upgrade.

For the record, as of June 19, 2026 neither flaw is listed in the U.S. CISA "Known Exploited Vulnerabilities" (KEV) catalog, and there is no public confirmation that they have been used in real attacks. Even so, with no login required and an unguarded default configuration, they are the kind of bug that gets hunted soon after disclosure. It is safer to act early rather than wait and see.

How we got here

Here is the timeline from the fixed release to the formal CVE registration.

The PROXY protocol spoofing flaw (CVE-2026-48772) was fixed after a report from a researcher going by "addcontent." No public release of proof-of-concept exploit code from a prominent researcher has been confirmed so far.

Summary

ProxySQL guards the front door to the database, and two holes were found there that can be reached without a login: an access-control bypass (CVE-2026-48772) and memory corruption (CVE-2026-48773). The former in particular carries the maximum 10.0 severity and leaves a default, internet-exposed install wide open.

The affected range — 2.0.0 through 3.0.8 — is wide, and the longer an install has been running, the more likely it qualifies. Start by checking your version with proxysql --version; if affected, upgrade to 3.0.9 or later. If you can't upgrade yet, narrow the allowed source range and keep it off the open internet. It comes down to those two moves. The layer in front of the database rarely gets attention, which is exactly why this one is worth not overlooking.

References

• ▸ NVD - CVE-2026-48772 Detail
• ▸ NVD - CVE-2026-48773 Detail
• ▸ ProxySQL Security Advisory - GHSA-gw94-85m2-x8v2 (PROXY protocol spoofing)
• ▸ ProxySQL v3.0.9 Release Notes (June 4, 2026)
• ▸ HAProxy - The PROXY protocol specification
• ▸ ProxySQL official site