KEDA PostgreSQL scaler: connection-string injection redirects the DB connection and leaks credentials

Impact

KEDA builds libpq connection strings from user-supplied host, port, userName, dbName, sslmode and password fields, but its escaping helper only quotes values that contain a literal space. Tabs, newlines, carriage returns, quotes and backslashes therefore terminate the current token and let an attacker append their own key-value pairs. Anyone who can create or edit a TriggerAuthentication or ScaledObject can inject a host parameter that points KEDA at a server they control, harvesting the database credentials KEDA presents, and inject sslmode to strip the TLS the operator intended. On a shared GPU cluster where KEDA drives autoscaling of inference deployments, namespace-scoped CRD write is a privilege tenants routinely hold, and the credentials KEDA carries are operator credentials, not tenant ones.

Who can reach it

Any authenticated principal with permission to create or modify KEDA ScaledObject or TriggerAuthentication resources, typically a tenant with write access in their own namespace. The attacker also needs a reachable network endpoint for the redirected connection.

What to do

Upgrade KEDA to 2.20.0, which fixes the escaping in pkg/scalers/postgresql_scaler.go. This is a control-plane component upgrade: roll the keda-operator deployment, no node drain or GPU workload disruption. Rotate any PostgreSQL credentials that were reachable through TriggerAuthentication objects a tenant could edit, since exposure leaves no trace in cluster state. Until the upgrade lands, restrict who can create ScaledObject and TriggerAuthentication resources via RBAC or admission policy.

References