How is CVE-2026-48772 exploited?

Network reachability (required): The attacker must reach the ProxySQL frontend port over the network; with the default wildcard `mysql-proxy_protocol_networks` setting any TCP peer on the network qualifies. Authentication (not-required): No credentials are needed; the PP1 frame is processed before any MySQL authentication handshake occurs. Victim interaction (not-required): Exploitation is fully attacker-driven and requires no action from an operator, DBA, or end user. Attack complexity (info): The exploit is reliable and condition-free: crafting a valid PP1 UNKNOWN frame with an arbitrary source address requires only basic TCP socket access and knowledge of the target IP to impersonate.

What is the impact of CVE-2026-48772?

The attacker routes their MySQL queries through ACL rules intended only for trusted internal addresses, gaining access to query paths (such as primary write endpoints or privileged schema routes) that should be unavailable to them. ACL rows that restrict DDL statements or dangerous query patterns to specific admin CIDRs are bypassed, allowing the attacker to issue otherwise-blocked commands. Read/write splitting policies are subverted: an attacker can direct queries to the primary (write) instance by forging an address in the internal-app CIDR, potentially modifying persisted database rows. The Confidentiality and Integrity impact tokens are both High (scope changed), meaning a successful attacker reads data and modifies data across any route reachable via forged client_addr rules.

Back to search

CRITICALCVE-2026-48772Published 2026-06-19Modified 2026-06-19CNA GitHub_M

CVE-2026-48772: ProxySQL: PROXY-Protocol-v1 UNKNOWN parses spoofed source IP, bypassing mysql_query_rules.client_addr ACL

ProxySQL is a proxy for MySQL and its forks, as well as PostgreSQL. In versions 2.0.0 through 3.0.8, the ProxySQL MySQL frontend accepts the `PROXY UNKNOWN <addr> <addr> <port> <port>\r\n` PP1 frame as a well-formed PROXY protocol header. The HAProxy PROXY protocol v1 specification says that when the protocol token is `UNKNOWN`, the receiver MUST ignore any address fields that follow it, because the proxy has declared it cannot determine the client identity. ProxySQL parses those address fields anyway via `sscanf` and writes the spoofed source address into the session's `addr.addr` field. From there it flows directly into the query-rule matcher, where the `client_addr` predicate decides routing and ACL. When `mysql-proxy_protocol_networks = '*'` (the default), any TCP peer can send a PP1 frame and choose any source IP claim. With that, any `mysql_query_rules` row pinned to a `client_addr` value is forgeable: the attacker writes the address they want to match into the PP1 line, and ProxySQL routes their query as if it came from that address. In practice this is a routing and ACL bypass. Real deployments use `client_addr` for read-write splitting (internal apps go to the primary, public traffic to read replicas), per-app schema pinning, and query-filter rules (DDL allowed only from admin CIDR, public queries blocked from dangerous patterns). An attacker that can reach the frontend port can forge their way into any of those routes. Version 3.0.9 patches this issue.

CVSS v3.1: 10.0
Severity: CRITICAL
Fixed in: —
Affected Products: 1

HarborGuard Analysis

Synopsis

An ACL bypass vulnerability affects ProxySQL versions 2.0.0 through 3.0.8, where the MySQL frontend incorrectly parses address fields from PROXY protocol v1 UNKNOWN frames instead of ignoring them as the specification requires. The flaw is reachable over the network with no authentication or user interaction needed, because the default configuration (`mysql-proxy_protocol_networks = '*'`) accepts PP1 frames from any TCP peer. A remote attacker can forge any source IP claim in the PP1 header, causing ProxySQL to route their queries as if they originated from a trusted address, bypassing `client_addr`-based ACL rules and read/write routing policies. No fix version has been published yet; HarborGuard tracks the upstream advisory for patch availability.

HarborGuard Coverage

Detection

Detection for CVE-2026-48772 is available across every HarborGuard environment: the CVE is ingested from upstream advisory feeds within minutes of publication and matched against all customer images, including custom-built images that bundle ProxySQL binaries.

Available

Triage

HarborGuard scores this finding at CVSS 10.0 (Critical) using the published v3.1 vector and weights it further against each environment's compliance policy. Triage findings are routed to the appropriate team inbox within each customer organization based on image ownership and policy configuration.

Available

Patch

Because no upstream fix version has been published, HarborGuard re-checks the ProxySQL advisory on every ingest cycle and will make a patched-image rebuild available the moment version 3.0.9 or a later fix is released. For customers with auto-remediation enabled, the rebuild, regression test run, and PR against affected workloads will trigger automatically once a fix version becomes available.

Pending upstream

Exploit Conditions

Network reachabilityRequired
The attacker must reach the ProxySQL frontend port over the network; with the default wildcard `mysql-proxy_protocol_networks` setting any TCP peer on the network qualifies.
AuthenticationNot required
No credentials are needed; the PP1 frame is processed before any MySQL authentication handshake occurs.
Victim interactionNot required
Exploitation is fully attacker-driven and requires no action from an operator, DBA, or end user.
Attack complexityDetail
The exploit is reliable and condition-free: crafting a valid PP1 UNKNOWN frame with an arbitrary source address requires only basic TCP socket access and knowledge of the target IP to impersonate.

Blast Radius

The attacker routes their MySQL queries through ACL rules intended only for trusted internal addresses, gaining access to query paths (such as primary write endpoints or privileged schema routes) that should be unavailable to them.
ACL rows that restrict DDL statements or dangerous query patterns to specific admin CIDRs are bypassed, allowing the attacker to issue otherwise-blocked commands.
Read/write splitting policies are subverted: an attacker can direct queries to the primary (write) instance by forging an address in the internal-app CIDR, potentially modifying persisted database rows.
The Confidentiality and Integrity impact tokens are both High (scope changed), meaning a successful attacker reads data and modifies data across any route reachable via forged client_addr rules.

How HarborGuard Handles This

Available on HarborGuard: detection for CVE-2026-48772 is active now, with affected ProxySQL image layers flagged at Critical severity as soon as the advisory was ingested. Because no upstream fix has been published, HarborGuard monitors the ProxySQL advisory on every ingest cycle and will generate a patched-image rebuild and, for customers with auto-remediation enabled, open a PR against affected workloads the moment a fix version appears. In the interim, compensating controls worth considering include: restricting `mysql-proxy_protocol_networks` to a specific trusted CIDR rather than the wildcard default via a runtime configuration change; applying network policy or firewall rules that limit which hosts can reach the ProxySQL frontend port; and auditing existing `mysql_query_rules` rows that rely on `client_addr` for security-critical routing to determine whether alternative rule predicates (such as username or schema) can substitute until a patch is available. Where compliance policy permits, HarborGuard can enforce a network-isolation policy recommendation as an automated compensating control pending the upstream fix.

See how HarborGuard automates this

Affected packages

sysown / proxysql
>= 2.0.0, < 3.0.9

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N

References

Metrics

Get notified