HashiCorp

HashiCorp Consul Enterprise before 1.8.17, 1.9.x before 1.9.11, and 1.10.x before 1.10.4 has Incorrect Access Control.

HashiCorp Consul and Consul Enterprise up to 1.9.16, 1.10.9, and 1.11.4 may allow server side request forgery when the Consul client agent follows redirects returned by HTTP health check endpoints.

An issue was discovered in GoGo Protobuf before 1.3.2.

A vulnerability was identified in Consul and Consul Enterprise (“Consul”) such that using Headers in L7 traffic intentions could bypass HTTP header based access rules.

Consul and Consul Enterprise allowed any user with service:write permissions to use Envoy extensions configured via service-defaults to patch remote proxy instances that target the configured service, regardless of wheth…

HashiCorp Consul and Consul Enterprise 1.13.0 up to 1.13.3 do not filter cluster filtering's imported nodes and services for HTTP or RPC endpoints used by the UI.

HashiCorp Consul and Consul Enterprise 1.10.1 Raft RPC layer allows non-server agents with a valid certificate signed by the same CA to access server-only functionality, enabling privilege escalation.

A vulnerability was identified in Consul and Consul Enterprise (“Consul”) such that using URL paths in L7 traffic intentions could bypass HTTP request path-based access rules.

HashiCorp Consul Enterprise version 1.7.0 up to 1.8.4 includes a namespace replication bug which can be triggered to cause denial of service via infinite Raft writes.

HashiCorp Consul and Consul Enterprise include an HTTP API (introduced in 1.2.0) and DNS (introduced in 1.4.3) caching feature that was vulnerable to denial of service.

HashiCorp Consul (and Consul Enterprise) 1.4.x before 1.4.3 allows a client to bypass intended access restrictions and obtain the privileges of one other arbitrary token within secondary datacenters, because a token with…

Patch in third party library Consul requires 'enable-script-checks' to be set to False.

HashiCorp Consul Enterprise version 1.8.0 up to 1.9.4 audit log can be bypassed by specifically crafted HTTP events.

HashiCorp Consul and Consul Enterprise up to 1.6.2 HTTP/RPC services allowed unbounded resource usage, and were susceptible to unauthenticated denial of service.

HashiCorp Consul and Consul Enterprise 1.9.0 through 1.10.0 default deny policy with a single L7 application-aware intention deny action cancels out, causing the intention to incorrectly fail open, allowing L4 traffic.

HashiCorp Consul and Consul Enterprise 1.3.0 through 1.10.0 Envoy proxy TLS configuration does not validate destination service identity in the encoded subject alternative name.

HashiCorp Consul and Consul Enterprise up to version 1.9.4 key-value (KV) raw mode was vulnerable to cross-site scripting.

HashiCorp Consul and Consul Enterprise did not appropriately enforce scope for local tokens issued by a primary data center, where replication to a secondary data center was not enabled.

HashiCorp Consul and Consul Enterprise could crash when configured with an abnormally-formed service-router entry.

HashiCorp Consul 1.4.0 through 1.5.0 has Incorrect Access Control.

Consul and Consul Enterprise's cluster peering implementation contained a flaw whereby a peer cluster with service of the same name as a local service could corrupt Consul state, resulting in denial of service.

HashiCorp Consul and Consul Enterprise 1.16.0 when using JWT Auth for service mesh incorrectly allows/denies access regardless of service identities.

HashiCorp Consul 1.8.1 up to 1.11.8, 1.12.4, and 1.13.1 do not properly validate the node or segment names prior to interpolation and usage in JWT claim assertions with the auto config RPC.

HashiCorp Consul 1.4.3 lacks server hostname verification for agent-to-agent TLS communication.

HashiCorp Consul and Consul Enterprise 1.9.0 through 1.9.14, 1.10.7, and 1.11.2 clusters with at least one Ingress Gateway allow a user with service:write to register a specifically-defined service that can cause Consul…