Intro
Safety and data security is our top priority at Deltablot. If you are a security researcher and have discovered a security vulnerability in our code base, we would appreciate your help in disclosing it to us in a responsible manner.
Scope
You can report vulnerabilities present in the software. The source code is hosted in these repositories:
- https://github.com/elabftw/elabftw
- https://github.com/elabftw/elabdoc
- https://github.com/elabftw/elabctl
- https://github.com/elabftw/elabimg
- https://github.com/deltablot/malle
For eLabFTW/elabimg: vulnerabilities that cannot be reproduced in the official Docker image deployment are not eligible. This includes instances where the Content-Security-Policy header has not been set correctly, or where another webserver software/configuration is being used.
You are not allowed to search for vulnerabilities on any instance of Deltablot products found in the wild, nor on the official Demo instance of eLabFTW located at demo.elabftw.net. It is recommended that you do your research on a local installation.
If you want to perform testing that might break things, please contact us to arrange access to a private staging server.
Where to report
Please report any security vulnerabilities that you find through the GitHub Private Vulnerability reporting interface on the elabftw/elabftw repository.
IMPORTANT: make sure that the vulnerability is actually exploitable and that you reproduced it yourself manually on the latest commit from master branch.
Policy
If your report is reproducible as an exploit and results in a change to the code base or documentation of a Deltablot product, we will (at your discretion) publicly acknowledge your responsible disclosure and publish a Security Advisory (attached to a CVE and/or GHSA).
After a fix is made, we ask security researchers to wait 30 days after a release before announcing the specific details of a vulnerability, and to provide Deltablot with a link to any such announcements.
Bug Bounty
We believe that it is important to reward responsible security researchers and to stimulate security research. Depending on the severity of the vulnerability, a reward of up to $500 may be awarded, at our discretion. Please note that the widespread use of LLMs changed the value of such reports, because the actual work of searching for vulns is now done by an agent. This is expressed in that blog post: Vulnerability Reports Are Not Special Anymore.
What we are looking for in reports
We’ve have many reports where the attacker would need to have an active account on the instance. Given the context of eLabFTW where all users are known and validated, the impact is pretty minimal. What would be very interesting and highly rewarded would be something where an attacker without an account could extract data from a system. That would be interesting.
Note about AI
LLMs are now pretty good at finding vulns. But as a popular open source project, we are now flooded with reports. Some of these reports are good, but others are very much far-fetched or don’t apply at all.
We are asking you to set a filter on your reports: report only the things that you manually verified and that have an interest. Also, don’t let your LLM write a long text about all the different aspects of the issue. Keep it short, please. Thank you.