This vulnerability exposes a fundamental misdesign in how KEDA handles credential construction for the PostgreSQL scaler. User-supplied TriggerAuthentication and ScaledObject metadata gets concatenated directly into connection strings without comprehensive escaping — the code only escaped spaces, leaving backslashes, quotes, and other protocol-significant characters unhandled. This isn't a simple missing quote around a special character in a password; it's KEDA treating user-controlled metadata as raw construction material for a security-critical protocol string. Connection strings are not configuration key-values — they're parsed input with their own grammar, and the 'escape spaces' approach inverted the security model entirely.
The fix in version 2.20.0 presumably switches to proper libpq connection string construction, but verify this explicitly: the question isn't whether KEDA now uses quoting — it's whether the fix addresses the full injection vector (additional key-value tokens injected through unescaped delimiters) or merely beautifies the vulnerable construction. Pull the diff and confirm the new code uses parameterized connection builders rather than string concatenation with manual quoting.
The privilege boundary here is narrower than typical injection bugs — exploiting it requires the ability to create or modify TriggerAuthentication or ScaledObject objects. But that privilege is often granted broadly in platform engineering setups where app teams manage their own autoscaling, and CI/CD pipelines via GitOps tools like ArgoCD or Flux typically hold these permissions. The payoff, however, is severe: redirecting credentials bypasses TLS entirely and exposes plaintext secrets that may be reused across other systems. The blast radius extends horizontally across every workload the autoscaler manages and temporally through persisted scaling decisions made with poisoned credentials.
What should concern you more than this specific CVE: does this same pattern exist in other KEDA scalers? Redis, MongoDB, and custom HTTP scalers all construct connection strings or URLs from user input. Audit those for partial sanitization functions — look for anything named 'escapeConnection' or 'sanitizeParameter' that only handles a subset of special characters. The PostgreSQL scaler's partial fix created a function named escapePostgreConnectionParameter that passed security review for years precisely because it looked like the right solution. The vulnerable code may still exist in your deployment even after upgrading — verify it's genuinely excised, not just bypassed.
Prioritize: if you're running KEDA 2.14 through 2.19 with PostgreSQL autoscaling, treat this as a credential-exposure vulnerability despite the medium CVSS score. The asymmetric privilege-to-impact ratio and the potential for TLS bypass in a critical autoscaling path warrant faster remediation than the score alone suggests.