CVE-2026-50236

The CVSS 7.4 score fundamentally mischaracterizes this vulnerability. Standard SSRF severity models assume the attacker is pivoting from an application server toward external targets. This case inverts that model: the console pod operates inside the cluster with likely access to the Kubernetes API server, internal service registries, and cloud metadata endpoints (169.254.169.254). The full response reflection capability is the critical detail—unlike blind SSRF, this enables direct exfiltration of data from internal services the pod can reach. The path neutralization bypass means attackers aren't constrained to simple GET requests; they can target arbitrary internal endpoints with crafted paths and methods. The authentication requirement creates a dangerous false sense of containment. Organizations seeing "authenticated SSRF" will deprioritize this relative to unauthenticated flaws, leaving it unpatched longer than it should be. The real attack chain is more severe than the CVSS vector captures: compromised developer account (common, lower-privilege) → console pod SSRF → service account token exfiltration → cluster admin. This isn't linear—it's a cascade with multiple detonation points, and the CVSS model stops measuring at the console pod's network edge. The authentication gate isn't a wall; it's a gate in a fence that has been rotting for years. Developer credentials leak into CI/CD pipelines, bash histories, encrypted secrets in repos, and service accounts created for temporary debugging that graduated to permanence. Every cluster upgrade that adjusts RBAC, every new internal service granted access because 'it already has cluster-network access,' silently expands what an attacker with any developer credential can reach. The deeper pattern: webhook handlers forwarding user-supplied URLs through privileged service account contexts have a documented lineage—AWS metadata SSRF in 2018, GCP service account token exposure via webhook handlers in 2020, and now this. Each time, post-mortems add URL validation layers. Each time, the underlying assumption—that authenticated user input routed through high-privilege context is acceptable if properly sanitized—remains intact. Previous CVEs in this lineage recommended URL allowlisting and input validation. Those fixes failed. The architectural assumption must be severed, not sanitized. Prioritize: enumerate what the console pod's service account can actually reach (API server endpoints, kubelet APIs, cloud metadata), assess whether SSRF enables credential theft beyond the cluster boundary, and treat any compromised developer account as a potential cluster admin pivot—not a low-severity auth-gated issue. The remediation should question whether this URL-handling endpoint in a privileged context should exist at all, not just add another validation layer.

Reviewed through automated stages and approved by a human before publication.