sysown proxysql up to 3.0.8 PROXY Protocol client_addr less trusted source

Summaryinfo

A vulnerability classified as critical has been found in sysown proxysql up to 3.0.8. Affected by this issue is some unknown functionality of the component PROXY Protocol. Performing a manipulation of the argument client_addr results in less trusted source. This vulnerability was named CVE-2026-48772. The attack may be initiated remotely. There is no available exploit. It is recommended to upgrade the affected component.

Detailsinfo

A vulnerability classified as critical has been found in sysown proxysql up to 3.0.8. This affects some unknown processing of the component PROXY Protocol. The manipulation of the argument client_addr with an unknown input leads to a less trusted source vulnerability. CWE is classifying the issue as CWE-348. The product has two different sources of the same data or information, but it uses the source that has less support for verification, is less trusted, or is less resistant to attack. This is going to have an impact on confidentiality, integrity, and availability. The summary by CVE is:

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 \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.

It is possible to read the advisory at github.com. This vulnerability is uniquely identified as CVE-2026-48772 since 05/22/2026. The exploitability is told to be easy. It is possible to initiate the attack remotely. No form of authentication is needed for exploitation. Technical details of the vulnerability are known, but there is no available exploit.

Upgrading to version 3.0.9 eliminates this vulnerability. The upgrade is hosted for download at github.com.

The vulnerability is also documented in the vulnerability database at EUVD (EUVD-2026-38074). Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Productinfo

Type

• Firewall Software

Vendor

• sysown

Name

• proxysql

Version

• 3.0.0
• 3.0.1
• 3.0.2
• 3.0.3
• 3.0.4
• 3.0.5
• 3.0.6
• 3.0.7
• 3.0.8

Website

• Product: https://github.com/sysown/proxysql/

CPE 2.3info

• 🔒
• 🔒
• 🔒

CPE 2.2info

• 🔒
• 🔒
• 🔒

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Discussion