Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
3 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Go github.com/projectcontour/contour >= 1.23.0, < 1.33.5
Fixed in
1.33.5· Vendor fix available
Issue
Impact When an HTTPProxy is configured with incompatible combination of both .spec.virtualhost.tls.enableFallbackCertificate: true and .spec.virtualhost.jwtProviders, Contour does not reject the configuration. Consequently, requests from clients that do not send TLS SNI or send an unrecognized SNI (one that does not match any HTTPProxy FQDN) bypass configured JWT verification and are proxied to upstream services without a valid token. To list all HTTPProxies with this invalid configuration, run Patches This issue is fixed in Contour v1.33.5. Contour now rejects and marks invalid any HTTPProxy resources that combine .spec.virtualhost.tls.enableFallbackCertificate: true with .spec.virtualhost.jwtProviders. Affected resources will receive a status condition with the error reason TLSIncompatibleFeatures. Workarounds Do not enable .spec.virtualhost.tls.enableFallbackCertificate on HTTPProxy resources that also define .spec.virtualhost.jwtProviders. Remove one of the two settings to avoid…
Recommended action: Upgrade to 1.33.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Contour's Cookie Rewriting feature is vulnerable to Lua code injection. An attacker with RBAC permissions to create or modify HTTPProxy resources can craft a malicious value in the following fields that results in arbitrary code execution in the Envoy proxy: - spec.routes[].cookieRewritePolicies[].pathRewrite.value - spec.routes[].services[].cookieRewritePolicies[].pathRewrite.value The cookie rewriting feature is internally implemented using Envoy's HTTP Lua filter. User-controlled values are interpolated into Lua source code using Go text/template without sufficient sanitization. The injected code only executes when processing traffic on the attacker's own route, which they already control. However, since Envoy runs as shared infrastructure, the injected code can also: - Read Envoy's xDS client credentials from the filesystem, which could be used to read all Contour xDS configuration, including TLS certificates and private keys of other tenants. - Cause denial of service for…
Recommended action: Upgrade to 1.33.4, 1.32.5 or 1.31.6 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Josh Ferrell (@josh-ferrell) from VMware has reported that a specially crafted ExternalName type Service may be used to access Envoy's admin interface, which Contour normally prevents from access outside the Envoy container. This can be used to shut down Envoy remotely (a denial of service), or to expose the existence of any Secret that Envoy is using for its configuration, including most notably TLS Keypairs. However, it cannot be used to get the content of those secrets. Since this attack allows access to the administration interface, a variety of administration options are available, such as shutting down the Envoy or draining traffic. In general, the Envoy admin interface cannot easily be used for making changes to the cluster, in-flight requests, or backend services, but it could be used to shut down or drain Envoy, change traffic routing, or to retrieve secret metadata, as mentioned above. Patches The issue will be addressed in the forthcoming Contour v1.18.0 and a patch…
Recommended action: Upgrade to 1.17.1, 1.16.1, 1.15.2 or 1.14.2 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.