VTAdmin users that can create shards can deny access to other functions

Exploitation

No confirmed exploitation recorded. Patch Next marks exploitation only from CISA KEV.

CVSS

4.1 · CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:N/I:N/A:L

EPSS

• CVE-2023-29195: 0.98% estimated exploitation activity in the next 30 days; percentile 62.36 (FIRST EPSS, 2026-11-03). This is a model estimate, not proof of exploitation or customer exposure.

As published by the source; long descriptions are shortened.

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.

Published by the source

11 May 2023, 19:40 UTC

Last modified by the source

11 Nov 2023, 05:01 UTC

Source last checked

26 Oct 2026, 15:00 UTC

1. Revision 1 · created · 26 Oct 2026

   Published from ghsa record GHSA-pqj7-jx24-wj7w

Preview the exact text before you copy it. Commands are read-only suggestions; review them before running anything.

# Patch Next advisory brief: CVE-2023-29195

Advisory: VTAdmin users that can create shards can deny access to other functions
IDs: CVE-2023-29195, GHSA-pqj7-jx24-wj7w
Record: https://patchnext.com/advisories/cve-2023-29195 (revision 1, source checked 26 Oct 2026, 15:00 UTC)
Inventory: none attached. This brief comes from a public page and does not say whether any deployment is affected.
Severity: Medium (CVSS 4.1)
Exploitation: no confirmed exploitation recorded. Patch Next confirms exploitation only from CISA KEV.
Vendor response: Vendor fix available; fixed versions by package: vitess.io/vitess 0.16.2. A vendor fix does not mean a deployment is fixed.

## Affected components
- Go vitess.io/vitess: affected < 0.16.2; fixed in 0.16.2

## Suggested inspection (read-only)
- Go vitess.io/vitess: check the installed version with your package manager.

## Supported action
Upgrade each affected component to a fixed version on its release line. For a transitive dependency, upgrade the parent package or add an override or constraint, then regenerate the lockfile. Redeploy every environment that ran an affected version.

## Required regression checks
- Run the test suite and a production build.
- Exercise the features that depend on vitess.io/vitess.
- Repeat the inspection and confirm that only fixed versions remain installed.

## Rollback considerations
- Keep the previous lockfile and deployment artifact. Rolling back reinstates the vulnerable version, so apply any documented mitigation while you fix forward.

## Unresolved questions
- Which deployments run an affected version?
- Exploitation status can change. Check again before lowering the priority.
- Mark the work resolved only after the fixed version is verified in production.

## Sources
- Verified: https://github.com/advisories/GHSA-pqj7-jx24-wj7w (GitHub-reviewed advisory GHSA-pqj7-jx24-wj7w lists affected ranges: Go vitess.io/vitess >=0 <0.16.2)

Commands are suggestions: review each one before running it.