Skip to content
vitessGHSA-649x-hxfx-57j2

Vitess vulnerable to infinite memory consumption and vtgate crash

Medium4.9CVE-2024-32886 · Published May 8, 2024 · updated Sep 10, 2026

GitHub advisory

Affected versions

PackageAffectedFixed in
github.com/vitessio/vitess
Go
>= 19.0.0, < 19.0.419.0.4
>= 18.0.0, < 18.0.518.0.5
< 17.0.717.0.7
vitess.io/vitess
Go
< 0.17.70.17.7
>= 0.18.0, < 0.18.50.18.5
>= 0.19.0, < 0.19.40.19.4
Details and references

### Summary 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. ``` select _utf16 0xFF ``` 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 such a caller is the following: https://github.com/vitessio/vitess/blob/8f6cfaaa643a08dc111395a75a2d250ee746cfa8/go/mysql/collations/charset/convert.go#L73-L79 The logic here moves forward the pointer in the input `[]byte` but if `DecodeRune` returns `0` in case of error, it will keep running forever. The OOM happens since it keeps adding the `?` as the invalid character to the destination buffer infinitely, growing forever until it runs out of memory. The fix here would be to always return forward progress also on invalid strings. There's also a separate bug here that even if progress is guaranteed, `select _utf16 0xFF` will return the wrong result currently. MySQL will pad here the input when the `_utf16` introducer is used with leading `0x00` bytes and then decode to UTF-16, resulting in the output of `ÿ` here. ### PoC ``` select _utf16 0xFF ``` ### Impact Denial of service attack by triggering unbounded memory usage.

CVSS 3.1
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H
Severity from
GitHub (reviewed advisory)
Weakness
CWE-835
Also known as
CVE-2024-32886, GO-2024-2826

More vitess advisories

All
DateAdvisory
Dec 32024Vitess allows HTML injection in /debug/querylogz & /debug/env
CVE-2024-53257Medium4.9fixed in 0.19.8, 0.20.4, 0.21.1
May 112023VTAdmin users that can create shards can deny access to other functions
CVE-2023-29195Medium4.1fixed in 0.16.2
Apr 112023vitess allows users to create keyspaces that can deny access to already existing keyspaces
CVE-2023-29194Medium4.1fixed in 0.16.1
Feb 26Vitess users with backup storage access can gain unauthorized access to production deployment environments
CVE-2026-27965Highno fix yet
Feb 27Vitess users with backup storage access can write to arbitrary file paths on restore
CVE-2026-27969Criticalfixed in 0.22.4, 0.23.3
Aug 18Vitess: Missing authorization on vttablet /debug/vrlog exposes live VReplication SQL data
CVE-2026-65959Medium5.3no fix yet

Critical advisories by email

Wednesdays: the week’s critical and high advisories in the AI and data stack, with the fixed versions. Only in weeks that have some.

Double opt-in. Unsubscribe any time.