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
6 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
From: xylove21 To: security@vitess.io Subject: [Security Report] Vitess vttablet /twopcz reflected XSS Date: Tue, 24 Jun 2026 14:30:00 +0800 Summary The twopczHandler in go/vt/vttablet/tabletserver/twopcz.go (line 185) reflects the Action and dtid form values directly into the HTML response body via fmt.Fprintln(w, msg) — without HTML escaping. The response is served as text/html; charset=utf-8, and Vitess's default acl policy is allow-all, so the endpoint is reachable by anyone who can hit the vttablet's HTTP port (default 15999, multiplexed with gRPC and MySQL wire-protocol ports). A crafted Action or dtid value yields a reflected XSS that executes in the operator's browser with same-origin access to the vttablet's debug endpoints. This includes /queryz (live query plans), /querylogz (recent queries with bound values), /txlogz (transactions), /debug/env (environment variables — may include MySQL/topology credentials), /debug/vars (expvar stats), and /debug/pprof/ if enabled. The…
Recommended action: Upgrade to 0.24.2 or 0.23.5 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go vitess.io/vitess >= 0.23.0-rc1, < 0.23.3; < 0.22.4
Fixed in
0.22.40.23.3· Vendor fix available
Issue
Impact Anyone with read/write access to the backup storage location (e.g. an S3 bucket) can manipulate backup manifest files so that files in the manifest — which may be files that they have also added to the manifest and backup contents — are written to any accessible location on restore. This is a common Path Traversal security issue. This can be used to provide that attacker with unintended/unauthorized access to the production deployment environment — allowing them to access information available in that environment as well as run any additional arbitrary commands there. Patches v23.0.3 and v22.0.4 Resources https://github.com/vitessio/vitess/pull/19470
Recommended action: Upgrade to 0.23.3 or 0.22.4 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The /debug/querylogz and /debug/env pages for vtgate and vttablet do not properly escape user input. The result is that queries executed by Vitess can write HTML into the monitoring page at will. Details These pages are rendered using text/template instead of rendering with a proper HTML templating engine. PoC Execute any query where part of it is HTML markup, for example as part of a string. To make it easier to observe you might want to make sure the query takes a few seconds to complete, giving you time to refresh the status page. Example query that can trigger the issue: Result: Impact Anyone looking at the Vitess status page is affected. This would normally be owners / administrators of the Vitess cluster. Anyone that can influence what text show up in queries can trigger it. This would normally be pretty much everybody interacting with a system that uses Vitess as a backend.
Recommended action: Upgrade to 0.21.1, 0.20.4 or 0.19.8 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When executing the following simple query, the vtgate will go into an endless loop that also keeps consuming memory and eventually will OOM. Details When running the following query, the evalengine will try evaluate it and runs forever. The source of the bug lies in the collation logic that we have. The bug applies to all utf16, utf32 and ucs2 encodings. In general, the bug is there for any encoding where the minimal byte length for a single character is more than 1 byte. The decoding functions for these collations all implement logic like the following to enforce the minimal character length: https://github.com/vitessio/vitess/blob/8f6cfaaa643a08dc111395a75a2d250ee746cfa8/go/mysql/collations/charset/unicode/utf16.go#L69-L71 The problem is that all the callers of DecodeRune expect progress by returning the number of bytes consumed. This means that if there's only 1 byte left in an input, it will here return still 0 and the caller(s) don't consume the character. One example of…
Recommended action: Upgrade to 0.19.4, 0.18.5 or 0.17.7 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Users can either intentionally or inadvertently create a shard containing / characters from VTAdmin such that from that point on, anyone who tries to create a new shard from VTAdmin will receive an error. Attempting to view the keyspace(s) will also no longer work. Creating a shard using vtctldclient does not have the same problem because the CLI validates the input correctly. Patches v16.0.2, corresponding to 0.16.2 on pkg.go.dev Workarounds - Always use vtctldclient to create shards, instead of using VTAdmin - Disable creating shards from VTAdmin using RBAC - Delete the topology record for the offending shard using the client for your topology server. For example, if you created a shard called a/b in keyspace commerce, and you are running etcd, it can be deleted by doing something like References https://github.com/vitessio/vitess/issues/12842 Found during a security audit sponsored by the CNCF and facilitated by OSTIF.
Recommended action: Upgrade to 0.16.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Users can either intentionally or inadvertently create a keyspace containing / characters such that from that point on, anyone who tries to view keyspaces from VTAdmin will receive an error. Trying to list all the keyspaces using vtctldclient GetKeyspaces will also return an error. Note that all other keyspaces can still be administered using the CLI (vtctldclient). Patches v16.0.1 (corresponding to 0.16.1 on pkg.go.dev) Workarounds Delete the offending keyspace using a CLI client (vtctldclient) Found during a security audit sponsored by the CNCF and facilitated by OSTIF.
Recommended action: Upgrade to 0.16.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.