Description
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.
Published: 2026-06-19
Score: 10 Critical
EPSS: n/a
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

ProxySQL, a database proxy for MySQL and its forks, incorrectly parses PROXY UNKNOWN frames in the PROXY protocol version 1. The proxy interprets the address fields that should be ignored as a legitimate client address, writing the spoofed source address into the session and then using that value in the query rule matcher. This flaw is an input validation weakness (CWE-348) that allows an attacker to assume any source IP address and has the proxy route their query as if it originated from that address, thereby bypassing all client‑address based access control and routing rules (CWE-863).

Affected Systems

The vulnerability affects Sysown ProxySQL versions 2.0.0 through 3.0.8. Version 3.0.9 and later includes the necessary fix.

Risk and Exploitability

The issue carries a CVSS score of 10, indicating a highly severe flaw. The EPSS score is not available, and the flaw is not listed in CISA KEV. The likely attack vector is any TCP peer that can reach the MySQL frontend port – an attacker can send a spoofed PROXY UNKNOWN frame and force the proxy to route traffic as if it came from a trusted IP.

Generated by OpenCVE AI on June 19, 2026 at 21:50 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Update ProxySQL to version 3.0.9 or later, which contains the fix for PROXY UNKNOWN parsing
  • Configure mysql-proxy_protocol_networks to a restricted subnet or specific IP addresses instead of the default '*' to limit which hosts can send PROXY protocol frames
  • Enable or enforce mysql_query_rules to use additional safeguards such as custom ACL rules or deny all unknown sources, and monitor proxy logs for unexpected PROXY protocol frames

Generated by OpenCVE AI on June 19, 2026 at 21:50 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Fri, 19 Jun 2026 20:00:00 +0000

Type Values Removed Values Added
Description 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.
Title ProxySQL: PROXY-Protocol-v1 UNKNOWN parses spoofed source IP, bypassing mysql_query_rules.client_addr ACL
Weaknesses CWE-348
CWE-863
References
Metrics cvssV3_1

{'score': 10, 'vector': 'CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N'}

Subscriptions

No data.

cve-icon MITRE

Status: PUBLISHED

Assigner: GitHub_M

Published:

Updated: 2026-06-19T19:28:46.248Z

Reserved: 2026-05-22T19:39:05.357Z

Link: CVE-2026-48772

cve-icon Vulnrichment

No data.

cve-icon NVD

No data.

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-06-19T22:00:07Z

Weaknesses