When Redis Labs shifted its flagship product away from open-source licensing in March 2024, a coalition of contributors forked the project and created Valkey under the stewardship of the Linux Foundation. The move was celebrated as a triumph for open-source principles. But a recent cluster of Common Vulnerabilities and Exposures (CVEs) affecting Valkey has thrown a spotlight on the security challenges that come with maintaining a widely deployed, community-driven data store—and the operational risks enterprises face when critical infrastructure depends on rapidly evolving open-source software.
On June 10, 2025, database performance and consulting firm Percona published a detailed security advisory outlining a series of CVEs that affect multiple versions of Valkey. The advisory, authored by Percona’s security team, identifies vulnerabilities ranging from denial-of-service vectors to potential remote code execution risks, and urges all Valkey users to patch immediately. The disclosure underscores a broader truth about open-source database management: community governance does not automatically translate into bulletproof security.
What the CVEs Reveal About Valkey’s Attack Surface
According to Percona’s advisory, the vulnerabilities span several categories. Some involve improper handling of specially crafted commands that can crash the Valkey server process, leading to denial of service. Others relate to authentication bypass scenarios and memory corruption bugs that, under specific conditions, could allow an attacker with network access to the Valkey instance to execute arbitrary code or extract sensitive data from memory.
The CVEs affect Valkey versions prior to the latest patched releases, and Percona notes that organizations running older, unpatched versions are at heightened risk. The firm specifically calls out CVE-2025-30156, which involves an authenticated user triggering a server crash through a malformed command, and CVE-2025-30157, which relates to a heap buffer overflow that could be exploited for code execution. Additional CVEs in the series address issues with ACL (Access Control List) enforcement and improper input validation across multiple subsystems.
Why In-Memory Data Stores Are High-Value Targets
Valkey, like its predecessor Redis, is designed to operate as an in-memory data structure store, frequently used for caching, session management, real-time analytics, and message brokering. Because these systems often sit between application layers and persistent databases, they handle a high volume of sensitive, transient data. A compromised Valkey instance can expose session tokens, user credentials, API keys, and other ephemeral secrets that applications store in memory for rapid access.
The security implications are amplified by common deployment patterns. Many organizations expose their Valkey or Redis instances on internal networks with minimal authentication, relying on network-level controls rather than application-level security. In cloud environments, misconfigurations can inadvertently expose these services to the public internet. The Percona advisory emphasizes that even authenticated vulnerabilities are dangerous in environments where internal network access is broadly shared among microservices and development teams.
Percona’s Recommendations and the Patch Timeline
Percona’s advisory recommends that all Valkey users upgrade to the latest stable releases immediately. The firm notes that the Valkey maintainers, coordinating through the Linux Foundation’s governance structure, released patches addressing all identified CVEs. Percona also advises organizations to audit their Valkey configurations, ensure that ACLs are properly enforced, disable unnecessary commands using the rename-command directive, and restrict network access to Valkey ports using firewalls and security groups.
Beyond patching, Percona recommends enabling TLS encryption for all Valkey connections, particularly in environments where data traverses untrusted network segments. The firm also suggests implementing monitoring for unusual command patterns that could indicate exploitation attempts. “Organizations should treat their Valkey instances with the same security rigor they apply to their primary databases,” the Percona advisory states, noting that in-memory stores are too often treated as disposable infrastructure rather than critical data assets.
The Fork Factor: Security Governance After the Redis Split
The Valkey project emerged in early 2024 after Redis Ltd. re-licensed Redis under a dual-license model that restricted cloud providers from offering Redis as a managed service without a commercial agreement. Amazon Web Services, Google Cloud, Oracle, and a broad coalition of contributors rallied behind the fork, which was placed under the Linux Foundation to ensure long-term open-source governance. The project quickly gained traction, with AWS offering Valkey as the backend for its ElastiCache and MemoryDB services.
But forking a major open-source project is not without consequences. When a codebase splits, the security review burden effectively doubles. Vulnerabilities discovered in one branch may or may not exist in the other, and patches developed by one team may not be directly applicable to the forked codebase. The Valkey maintainers have established their own security reporting and disclosure processes, but the project is still maturing its security infrastructure. The current batch of CVEs represents one of the first major security tests for the Valkey project’s governance model.
Industry Context: Open-Source Security Under Scrutiny
The Valkey vulnerabilities arrive at a moment when open-source security is receiving unprecedented attention from regulators, enterprise buyers, and the security research community. The 2024 XZ Utils backdoor incident—in which a sophisticated supply chain attack was narrowly averted in a widely used Linux compression library—demonstrated how thinly stretched open-source maintainers can become vectors for compromise. The U.S. Cybersecurity and Infrastructure Security Agency (CISA) has been pushing for software bills of materials (SBOMs) and improved vulnerability disclosure practices across the open-source supply chain.
For Valkey, the stakes are particularly high because of its adoption by major cloud providers. AWS’s decision to build ElastiCache on Valkey means that millions of workloads depend on the project’s security posture. A critical vulnerability in Valkey could cascade across cloud infrastructure at scale, affecting applications from e-commerce platforms to financial trading systems. The cloud providers themselves maintain their own patching and hardening layers, but the underlying open-source code remains the foundation.
What Enterprises Should Do Now
For organizations running Valkey in production, the immediate action items are straightforward but urgent. First, identify all Valkey instances across your infrastructure, including those running in containers, Kubernetes clusters, and managed cloud services. Second, verify the version numbers against the patched releases listed in the Valkey project’s security advisories and Percona’s guidance. Third, apply patches during the next available maintenance window—or sooner, if instances are exposed to untrusted networks.
Beyond the immediate response, this series of CVEs should prompt a broader review of how organizations manage their in-memory data store security. Configuration audits should verify that default passwords have been changed, that ACLs restrict command access to authorized clients, and that network exposure is minimized. Organizations using managed Valkey services from cloud providers should confirm with their providers that patches have been applied and review any provider-specific security advisories.
The Bigger Picture for Valkey’s Future
The disclosure of multiple CVEs is not, by itself, a sign of a failing project. Mature open-source projects regularly discover and patch vulnerabilities as their codebases are scrutinized by an expanding community of users and security researchers. What matters is how the project responds—the speed of patches, the clarity of communication, and the rigor of the review process that follows. By those measures, the Valkey project and its supporting organizations like Percona have handled this round of disclosures competently, with patches available before public exploitation was reported.
Still, the incident serves as a reminder that the transition from Redis to Valkey is not merely a licensing story. It is also a security story. Every organization that migrated to Valkey—whether by choice or because their cloud provider made the switch—has inherited both the benefits and the risks of a young fork of a complex, performance-critical system. The CVEs disclosed by Percona are a call to treat Valkey with the operational seriousness it demands: as infrastructure that, when compromised, can undermine the security of everything built on top of it.
As the Valkey project matures, the security community will be watching closely. The next year will determine whether the project can build the kind of security culture that enterprises require—one defined not by the absence of vulnerabilities, but by the speed and transparency with which they are addressed.
WebProNews is an iEntry Publication