DBeaver Security Policy

Overview

This policy explains how to report security vulnerabilities and how the DBeaver team handles them. The policy covers DBeaver products, source code, third-party dependencies, and release artifacts.

Reporting a Vulnerability

Please report suspected security vulnerabilities privately. Do not create a public GitHub issue, discussion, pull request, or social media post for an unpatched vulnerability.

We use GitHub Security Advisories for tracking vulnerabilities in the open-source products:

• DBeaver Community
• CloudBeaver Community
• dbvr Community

All vulnerabilities for DBeaver commercial products can be reported via private emails to security@dbeaver.com.

Please include as much of the following information as possible:

• Affected product, repository, package, or service
• Affected version, commit, or release
• Description of the vulnerability
• Steps to reproduce
• Potential impact
• Proof of concept, logs, screenshots, or exploit details, if available
• Any known mitigation or workaround
• Your preferred contact details
• Whether you would like public credit after disclosure

Each report is reviewed by the maintainers. If a vulnerability is confirmed, we prioritize the fix based on its severity, practical exploitability, user impact, and any available workarounds or mitigations.

We will acknowledge receipt of valid reports within a reasonable timeframe and may contact you for additional information during triage.

After the vulnerability is confirmed and fixed, the DBeaver team will request an official CVE and provide GitHub credits for the open-source vulnerability reporter.

Triage and Severity

We evaluate reports based on practical security impact, exploitability, scope of impact, and whether the issue can be triggered remotely or without authentication.

Severity is generally classified as:

• Critical: Remote code execution, authentication bypass, compromise of sensitive data, or widespread impact.
• High: Significant privilege escalation, unauthorized access, or serious data exposure.
• Medium: Limited-impact vulnerabilities requiring specific conditions or user interaction.
• Low: Defense-in-depth issues, hardening gaps, or low-impact information disclosure.

Severity may be adjusted based on real-world exploitability, affected deployments, available mitigations, and product-specific context.

Remediation Targets

We target remediation within the following timeframes, starting from the moment of the vulnerability confirmation:

Severity	Target Remediation
Critical	Up to 10 business days
High	Up to 30 business days
Medium	Up to 120 business days
Low	Up to 250 business days

In exceptional cases, when remediation cannot be implemented within the target period, DBeaver will provide an official notification with information about the updated estimated delivery time and possible risk mitigation actions that can be applied before the official resolution.

For vulnerabilities in third-party dependencies, DBeaver will provide patched versions during the remediation period after the official patch for the third-party library is published. If no fix is available from the upstream vendor, DBeaver may apply compensating controls, disable affected functionality, document mitigations, or monitor until an upstream fix is released.

Disclosure Process

We follow coordinated vulnerability disclosure.

Before public disclosure, DBeaver asks reporters to follow the joint process and actively collaborate with the team during the investigation, remediation, testing, and release processes. When possible, we publish an official security advisory on GitHub containing:

• Affected products, components, or versions
• Severity and impact
• Version with fix
• Upgrade instructions
• Workarounds or mitigation steps
• Timeline of the issue
• Reporter credit, if requested

We aim to keep reporters informed during triage, remediation, and release, subject to operational and security constraints, and expect their participation in the process when needed. Information about all closed vulnerabilities and security patches will be available in the release notes on GitHub and the official website.

Supported Versions

Security fixes are generally provided for the latest stable release.

Old product versions may not receive security fixes. Users running unsupported versions must upgrade to a supported version to receive a fix.

Scope

This policy applies to security vulnerabilities affecting:

• Application source code
• Build, runtime, and development dependencies
• Packaging, distribution, and release artifacts
• Authentication, authorization, and access control logic
• Security-sensitive configuration

The following are generally out of scope unless they demonstrate a direct security impact:

• Missing security headers without a demonstrated exploit path
• Clickjacking on pages with no sensitive actions
• Reports from automated scanners without validation
• Social engineering or phishing
• Denial-of-service testing that may disrupt service
• Spam, brute force, credential stuffing, or rate-limit testing
• Vulnerabilities requiring compromised user devices, browsers, or accounts
• Issues in unsupported versions

Safe Harbor

We support good-faith security research conducted in accordance with this policy.

We will not pursue legal action against researchers who:

• Report vulnerabilities privately and promptly.
• Avoid accessing, modifying, deleting, or exfiltrating data that does not belong to them.
• Avoid privacy violations, service disruption, degradation, or destructive testing.
• Do not perform social engineering, phishing, physical attacks, or denial-of-service attacks.
• Use only the minimum testing necessary to demonstrate the issue.
• Give us a reasonable time to investigate and remediate the issue.
• Comply with applicable laws and regulations.

If you accidentally access sensitive data or affect service availability during research, stop testing immediately and report the incident to us.

This safe harbor does not apply to activity conducted in bad faith or activity that causes harm to users, systems, data, or services.

We appreciate your effort in helping us detect and remove security issues and potential vulnerabilities. We believe that together we can make open-source products safe for all users around the globe.