Redis VDP

Our Priorities for the Research Community

We are particularly interested in reports involving our cloud DBaaS product (Redis Cloud) that are:

• Remote Code Execution (RCE) vulnerabilities
• Weaknesses in user access and permission management
• API flaws that could result in unauthorized data exposure in api.redislabs.com
• Cross-tenant data access

Program Rules

• You pledge not to discuss potential vulnerabilities either publicly or privately prior to your findings being resolved without express written consent from Redis.
• Please follow HackerOne's disclosure guidelines.

• Please provide detailed reports with clear, reproducible steps. Reports that lack sufficient detail to reproduce the issue may not be triaged. If you are aware of potential mitigations or remediations, please include them.
• Submit one vulnerability per report unless chaining vulnerabilities is necessary to demonstrate impact.
• In the case of duplicate submissions, we will triage only the first fully reproducible report received.
• Multiple vulnerabilities stemming from a single underlying issue will be treated as a single valid report.
• Social engineering (e.g., phishing, vishing, smishing) is prohibited.
• Flooding or denial-of-service (DoS) testing against Redis owned infrastructure is prohibited.
• Do not violate user privacy, modify or destroy data, or interrupt/degrade our services.
• Only interact with accounts you own or have explicit permission to test.

Disqualifiers

The following actions will result in disqualification from the program:

• Modification or destruction of user data
• Intentional violations of user privacy
• Public actions that harm the company’s reputation (e.g., website defacement, typo-squatting domains or accounts)
• Social engineering of users or employees
• Denial-of-service attacks and high-volume automated scanning targeting Redis infrastructure or user accounts

Redis Security Baseline & CVSS Scoring

Base Configuration

The following defines the security configuration assumptions under which Redis evaluates and scores vulnerabilities. Researchers may test outside these assumptions; however, CVSS base scoring will be evaluated against this hardened security posture. When testing, enable the following security controls where supported.
See the documentation references below for full details of controls and recommendations.

• Enforce strong authentication for all users and clients.
• Enable Multi-Factor Authentication (MFA).
• Use Role-Based Access Control (RBAC) and Access Control Lists (ACLs) to enforce the principle of least privilege.
• Enable TLS encryption for clients and connections.
• Use trusted certificates issued by recognized Certificate Authorities.
• Restrict access to trusted network environments using private networking and CIDR allowlists.

CVSS Scoring

Redis uses the CVSS 4.0 standard to determine vulnerability scores and may adjust them based on context and evolving threat models. Customers are expected to evaluate published vulnerabilities within the context of their own environments and are encouraged to apply CVSS Temporal Metrics and Environmental Metrics based on their specific usage.

Examples

The following example is hypothetical and is not based on any previously disclosed or existing vulnerability. It is provided solely to illustrate CVSS scoring under the guidelines above.

Vulnerability Description

Product: Redis OSS (Redis Community Edition)
Summary: A malformed database CLIENT UNBLOCK command causes the database process to crash. CVSS 4.0 Score: 6.8

CVSS Metrics Breakdown

• AV: A — Requires access to a trusted network.
• AC: L — No special conditions (e.g., ASLR or DEP bypass) are required for the crash to occur.
• AT: N — Does not require specific load conditions or OS-specific scenarios.
• PR: H — The CLIENT UNBLOCK command is classified as high privilege under the @admin ACL category.
• UI: N — No user interaction is required.
• VC: N — No impact on confidentiality.
• VI: N — No impact on integrity.
• VA: H — The process crash impacts availability for all users of the affected database instance.

Note regarding Subsequent System impact. Redis considers the full Redis deployment, including databases, clusters, nodes, shards, and Redis-managed services, to be a single Vulnerable System for CVSS scoring. Impacts confined to that deployment are scored using Vulnerable System impact metrics. Subsequent System impact is reserved for effects outside that Redis boundary, such as compromise of the underlying host operating system. For example, an RCE that executes as root rather than the expected redislabs service user may justify Subsequent System impact because exploitation has crossed from the Redis service context into the host operating system security domain.

References

• Redis Cloud Security Documentation
• Redis Enterprise Software Recommended Security Practices
• Redis Enterprise for Kubernetes Security Documentation
• Redis Open Source Security Documentation

Policy Updates

We may update this policy from time to time. If we make material changes, we will post a notice on this page.

Thank you for helping secure Redis and our community of technologists, enthusiasts, and innovators