There’s now another reason an immediate patch is needed for organizations running Valkey clusters, according to Percona (and other database experts.)

In this article, I’ll detail four CVEs affecting your Valkey database. I’ll tell you what they are, why they’re dangerous, and detail, step-by-step, exactly what you should do for your users to avoid seeing a deface page the next time they visit your website.

But first, some background.

What is Valkey, and what’s it used for?

It’s safe to assume that most of you reading this article will know your way around database management systems. And, if so, you’ll also know that not all DBMS’ are built equal. A system considered ‘mainstream’ by one group of developers may not be seen that way by others – and that’s exactly the case with Valkey.

In a way, Valkey is like MySQL or SQL Server – and in other ways, it’s different. According to Valkey themselves, it’s an open-source, high-performance key-value datastore, able to support a wide variety of workloads. These workloads include (but are not limited to), caching, message queues, session storage, real-time analytics, AI and vector workloads, and more.

Valkey is considered a NoSQL database. As such, it solves issues for developers storing flexible structures, including geospatial data, vectors, and anything else that fits into the key-value database category. Valkey is used in industries like gaming, AI systems, and other high-traffic web applications.

Why is Valkey used in these industries?

Valkey is commonly used in these industries because it provides developers with quite a few advantages:

For example, running a query like SET session:ID session_data EX 3600 would:

In this case, if we run a query like SET user:1 “Bob“ on Valkey, it’ll update the key user:1 with the value of Bob. Should the key not already exist, Valkey will create it.

Why does Valkey follow this format?

The reason why Valkey follows such a format is because the “:“ here is a naming convention. It tells Valkey how to interact with the data – for example:

What is a CVE?

CVEs (Common Vulnerabilities and Exposures) are a way for security researchers (and hackers) to map a security flaw to a standardized and globally-recognized identifier, allowing for easier recognition and triage.

What does a CVE entry look like?

A CVE entry looks like CVE-YEAR-ID. CVE identifies the vulnerability, YEAR is the year the vulnerability was discovered, and ID is a four-digit serial number identifying the security bug.

For example, CVE-2026-6682 would refer to a vulnerability discovered in 2026 with the ID of 6682.

Knowing this is vital, because no one ID is the same. That’s sort of the entire point of having CVEs in the first place – each ID maps to one specific vulnerability.

What are the 4 CVEs affecting Valkey today?

Now for the specific CVEs affecting Valkey. These are:

CVE-2025-67733

CVE-2026-21863

CVE-2026-21864

CVE-2026-27623

In detail:

All CVEs except CVE-2026-21864 affect the Valkey server.

CVE-2026-21864, meanwhile, affects portions of pre-packaged Valkey images (Valkey-bloom and Valkey-bundle.) Valkey’s creators have already released new versions that include security patches for these vulnerabilities.

What to do right now

You should upgrade your Valkey installation to a version that isn’t vulnerable to these kinds of attacks.

Upgrade to one of the following:

If you’re not running Valkey at all, these flaws don’t apply to your infrastructure, and you’re safe.

What these 4 CVEs affecting Valkey mean for you

With the CVEs being vulnerable mostly to DoS attacks, any unpatched versions of Valkey could be exploited by hackers. If you’re not running Valkey, you don’t need to worry. If you are, check to see if your version of Valkey is vulnerable to these CVEs or not.

After doing so, keep in mind that database security doesn’t end there. Security for any database (or application) is an ongoing process that requires continuous monitoring, timely patching, and proper best practices. Take a look into the severity rating of one of these CVEs – even DoS-related vulnerabilities are classified as having HIGH severity. This is especially the case for services that depend on Valkey for caching, session storage, rate limiting, or queue management.

The consequences of a successful attack

A successful attack against an exposed or unpatched Valkey deployment, using one or more of the aforementioned CVEs, could lead to degraded application performance, customer unsatisfaction, and data vulnerabilities, among other issues.

In environments where high availability is critical, even a short disruption in service can translate into financial loss, reputation damage, and incident response overhead.

Next steps (and why security is not a ‘one-and-done’ situation)

That’s why you need to continuously educate yourself by attending workshops, conferences, reading books, following security researchers, participating in hands-on labs, and staying up to date with vulnerability disclosures affecting the technologies your organization depends on.

Database and application security is not a static field — attack techniques evolve, and defensive strategies need to evolve alongside them. Black Hat OSINT may be a good starting point for those of you that wonder how your own data is stolen, weaponized, and used against you. Likewise, keeping an eye out for some YouTube videos related to Valkey is a good idea, too.