---
title: "Vulnerability Reporting"
publish_date: 2020-09-28
updated_date: 2026-01-27
---

# Vulnerability Reporting

## Reporting a Security Concern

### Customers

Current MariaDB customers may report a security concern by creating a support case in the [Customer Support Portal](https://support.weglot.kinsta.cloud/).

### Non-Customers

Non-customers may report a security concern by emailing security@mariadb.com

### MariaDB Foundation

For the MariaDB Foundation’s policy on reporting security concerns, please see [MariaDB Foundation Reporting Procedures](https://hackerone.com/mariadb?type=team).

## Reporting Details

MariaDB asks that reports provide full details of the security concern so our security team can validate and reproduce the issue.

### Scope

- In-Scope: MariaDB plc Developed Software Products and Services including (API’s, binaries, MariaDB Cloud)
- Out-of-Scope: Third-party services, partner products, physical security, DoS attacks, social engineering

To help us address your report efficiently, please include the following information:

- The environment (operating system, hardware, and MariaDB version, including plugins and storage engines).
- Code affected, along with your explanation of the faulty behavior.
- Configuration details, including SQL tables, queries, and network actions required to reproduce the behavior.
- Core dumps, stack-traces, error logs, data dumps, failed test cases or network packets required to diagnose or reproduce the attack.
- Proof of Concept (PoC) code that successfully triggers/exploits the vulnerability in at least one given scenario.
- Technical reproduction details, such as: 
    - The specific URL or endpoint affected
    - The parameters or payloads to be sent
    - The type of request (e.g., GET, POST, PUT, DELETE, etc.)
    - Any headers or authentication context required to reproduce the issue
    - Binary/Package command line parameters
    - Software or service affected
    - Module name or parameter
    - Video demonstrating the vulnerability
- Exclusions List 
    - Automated scanner findings without PoC
    - DoS/DDoS attacks
    - Social engineering
    - Missing security headers without exploitability
    - Self-XSS
    - Known vulnerabilities

Vulnerability reports need to be documented in a way that they can be reproduced, easily understood, and classified. The more details you provide, including screenshots, sample code, or short videos; the faster our team can understand and address the issue.

## Safe Harbor Clause

MariaDB considers security research conducted consistent with this policy to be “authorized” conduct and will not pursue legal action against security researchers who:

- Act in good faith and in accordance with this policy;
- Perform security research within the scope defined in this policy;
- Do not access, modify, or exfiltrate data beyond what is strictly necessary to demonstrate a vulnerability. If user data is encountered, the security researcher must stop immediately and report it;
- Comply with all applicable laws;
- Do not cause harm or disruption to MariaDB services or users (e.g., DoS attacks); and
- Report vulnerabilities responsibly and maintain confidentiality until the issue is resolved.

**Third Parties:** please understand that MariaDB cannot authorize research on third-party infrastructure (e.g., hosting providers) and cannot limit their legal rights.

## Our Security Commitment

To all customer and security researchers who follow this MariaDB Vulnerability Reporting Policy, our security team commits to:

- Respond in a timely manner, acknowledging receipt of your report
- Provide an estimated time frame for addressing the vulnerability
- Notify the reporting individual when the vulnerability has been fixed

We take security issues seriously and will endeavor to respond swiftly to fix verifiable security issues.

## Compensation

While we appreciate the work done by independent security researchers, we do not offer compensation for reporting a security vulnerability.