CVE-2026-18677

Kong Mesh contains a vulnerability where the XDS authenticator derives SPIFFE identities from kuma.io/workload labels but only validates those labels when a dataplane token is bound to a specific workload. If you disable workload binding — a feature documented as optional and often disabled for operational simplicity — the validation check is silently bypassed. The SPIFFE identity is still derived and used for all downstream authorization decisions, but without any verification that the workload labels are legitimate. This is a secure-by-default violation disguised as configuration flexibility. The operator who disables workload binding isn't making an informed security tradeoff — they're unknowingly opting out of identity validation entirely, with no warning from the system. The XDS authenticator should either enforce label validation unconditionally or explicitly fail when workload binding is disabled if validation is required for identity derivation. What makes this worse than a typical CWE-285 is the blast radius. SPIFFE identity isn't a feature — it's the trust infrastructure every service in the mesh depends on for authorization. Compromising identity derivation doesn't give you access to one workload; it gives you a credential every service in the mesh is architecturally obligated to trust. The CVSS score captures exploitability but not this cascading infrastructure risk. Audit your Kong Mesh configuration immediately: check whether workload binding is enabled in your kuma-cp settings, and verify that the XDS authenticator is configured to validate kuma.io/workload labels regardless of binding state. Treat any security validation gated on an 'optional' feature flag as a design smell — this pattern has appeared across multiple generations of infrastructure tooling, and the word 'optional' in a security-critical path is often a signal that maintenance attention has already lapsed.

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