MariaDB
External Program
Submit bugs directly to this organization
MariaDB
MariaDB Server is one of the most popular open source database servers in the world. It is developed and maintained by the original developers of MySQL and guaranteed to stay open source.
The MariaDB Foundation supports continuity and open collaboration in the MariaDB ecosystem. The Foundation guarantees that there is a global contact point for collaboration and that the community can always rely upon MariaDB Server.
The Foundation is committed to working with security experts to stay up to date with the latest security techniques and towards the security of your database deployments. Feel free to inspect, analyze and fuzz our source code as you wish. If you discovered a security issue in either research or production that you believe we should know about, please let us know via responsible disclosure and we'll make every effort to quickly correct the issue following a vulnerability handling process that is respectful and considerate to you, all users, partners, companies and forks of MariaDB. If you'd like to bring additional attention to a report or feel we can improve with our report handling please let us know at [email protected].
A note on upstream MySQL and third party storage engines,
MySQL, which is the base of MariaDB, is a product and trademark of Oracle Corporation, Inc. MariaDB is a fork of MySQL and the Foundation is committed to keeping MariaDB on par and go beyond feature, security, performance and reliability wise, as well as keep drop-in compatibility to the best of our efforts for certain branches. This implies that some security issues could originate in the upstream source code before the initial fork, or be introduced later via a subsequent merge, in which case our biggest priority is to resolve the issue for MariaDB users as quickly and responsibly as possible and at the same time report upstream if applicable. We can report the vulnerability to Oracle on your behalf, unless you prefer to do it yourself. However, if you report it only to Oracle, we will never know about it and might never fix it.
Also, MariaDB, in the default source offering, incorporates various third party open source modules, for example, Storage Engines that provide different backend store facilities with focus on performance, efficiency, or scaling. Examples include TokuDB, XtraDB from Percona, and MyRocks originally from Facebook. If your report specifically targets one of those third party modules that is part of the original MariaDB source offering, we encourage you to report it to us, in which case, our biggest priority is to resolve the issue for MariaDB users quickly and responsibly and at the same time notify and collaborate with the original upstream source to mitigate risk and develop a resolution that has the widest outreach possible.
If you are unsure of the scope of your vulnerability report, don't worry too much about it, just make sure you are following the responsible disclosure guidelines and we will get in touch with you about the classification and scope specifics upon verification and validation of the report. In either case, you will be kept in the loop for the entire life-time of the disclosure and handling process.
MariaDB is a server product used in both public and private environments, with a wide reach ranging from being the default database system on Debian flavored distributions and availability in most other Linux and BSD package repositories, to corporate, enterprise and governmental deployments, to supplying database needs for many internet sites and services, and ultimately to being the go-to choice for many personal individuals all around the globe. To that end we strongly encourage you to follow the responsible disclosure philosophy and guidelines when stumbling across vulnerabilities in critical infrastructure software, MariaDB included.
A quick summary of the rules defining responsible disclosure:
A good vulnerability bug report should include at least the following information:
In gist, vulnerability reports need to be documented in a way that they can be reproduced, easily understood and classified by our developers without duplicating everything you did already from scratch. The more details you send in, the easier it is for our developers to rely on the effort already put in by you and act faster. Send screen-shots, code, video; whatever helps to understand the flaw as quickly as possible.
For details on how to submit a comprehensive bug report that's specifically tailored to MariaDB see Bug Reporting in our Knowledge Base.
Due to the nature of our client-server protocol, replication technologies, plugin system, and overall architecture of MariaDB sever and deployment specifics, there are a variety of forms that a security vulnerability can take, so in order to simplify our classification of reports for eligibility, we try and base our evaluations on a combination of risk, impact, exposure and common sense to evaluate severity for a particular vulnerability report and the threat posed to users. It is considered a good practice to assess any particular vulnerability using the Common Vulnerability Scoring System CVSS3 standard in order to easily come up with a metric that can be easily understood and shared by many in the industry.
Unless otherwise stated by the MariaDB security team, pending completion of report evaluation and analysis, we currently consider this classification for qualifying vulnerabilities:
Security vulnerabilities in active development branches and released versions that are still in the supported timeline, such as:
Vulnerabilities that don't lead to a severe compromise of the server, data and information leakage or privilege escalation, but do affect normal operation, up-time and service reliability are considered of limited scope:
In addition to the main product offerings of MariaDB, we are also considering critical security issues in our website, support, development, testing and release infrastructure that could potentially affect end users of MariaDB server as part of this policy and in limited scope. Examples could be server side attacks that lead to binary release distribution integrity corruption or web attacks that could lead to serious compromise of our infrastructure, such as:
Please, note, MariaDB Foundation is a non-profit organization with limited resources and while we do our best to keep everything up to date and secure, there's still the chance that some underused service, daemon or forgotten installation might gradually slide down the path of irrelevance and obsoleteness and thus, potentially expose us to attacks. If you happen to find such problems in our infrastructure, please notify us first. We will be grateful and acknowledge you with thanks on HackerOne at least.
Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service. Only interact with accounts you own or with explicit permission of the account holder or the Foundation. Engaging in a full-blown penetration test of our infrastructure and live systems without a prior agreement from the Foundation is especially prohibited. If you're planning to look for vulnerabilities in our infrastructure, we'd like to ask you to refrain from:
If you're in doubt, feel free to report it anyway or e-mail us at [email protected].
The MariaDB Server developers classify all security vulnerabilities according to their threat level and thus handle them with the appropriate consideration. The threat level can be one of:
We promise to fix any CRITICAL security vulnerability immediately, usually within hours, and release fixed MariaDB binaries as soon as possible, usually the next day.
We will fix MEDIUM security vulnerability as soon as possible, but we will not change our planned release schedule to get the fix out earlier.
The MariaDB Foundation security policy at https://mariadb.org/about/security-policy/
####Thank you for helping keep MariaDB and our users safe!