Vulnerability Reporting & Disclosure Policy
The DHIS2 security team participates in responsible disclosure and welcomes collaboration with the wider community on security issues. On this page we describe how to contact the DHIS2 security team, what you can expect when you contact us, and what we expect from you
Jump to a section on this page
You may report issues by sending an email to the DHIS2 security team firstname.lastname@example.org. We aim to respond within 10 working days.
We ask that you:
- Include only a brief summary of the issue and provide us with your contact details so that we can discuss the issue further on a secure channel.
Vulnerability reports must include clear written instructions for reproducing the vulnerability. Every report should contain the following:
- DHIS2 version
- DHIS2 build number
- Description of the issue
- Why do you consider it a security vulnerability
- Steps to reproduce
- Do you want to be accredited (YES/NO)
Please do NOT report the issue on the public mailing lists and do NOT report the issue through the Jira system as these methods are available to members outside the security team.
Investigating and fixing the reported issue may take time, as will the deployment of updated releases by our users. We therefore ask that you refrain from sharing vulnerabilities publicly until we believe that it is safe to do so.
We do not currently offer monetary rewards for bug reports, but we are happy to give credit to reporters in our hall of fame and change logs.
The following targets are in scope:
- Your own private instances of the DHIS2 software
- Our open source software
- The current Android App and the Android SDK
Out of scope
- Any public or private hosted instances of the DHIS2 server not listed above.
- Unsupported versions of DHIS2
- We only support and provide security fixes for the last 3 versions of DHIS2
- Social engineering, phishing, or physical attacks against our employees, users, or infrastructure
- Third party apps built on the DHIS2 platform
- By “third party” we mean apps which have not been published or developed by the University of Oslo
- Vulnerabilities in upstream dependencies
- Lack of rate limiting
- Reports concerning volumetric DoS attacks are out of scope.
- Vulnerabilities due to outdated browser versions
- Vulnerabilities affecting outdated modern browser versions are out of scope, as are those caused by browser extensions.
- MITM attacks
- We cannot protect our users from using vulnerable networks, hence man-in-the-middle attacks are out of scope.
- Missing best practices in SSL/TLS configuration without proof of concept/demonstrating a vulnerability.
- Content spoofing and text injection issues without showing an attack vector/without being able to modify HTML/CSS
- Missing HttpOnly or Secure flags on cookies not related to authentication or sessions
- Misconfiguration of databases or reverse proxies
- DMARC, SPF and DKIM email policy
- We believe our DMARC, SPF and DKIM settings appropriately balance security against email deliverability concerns.
The security team is committed to making a public disclosure of security issues in a responsible manner. This implies that an issue may be embargoed for some time while a fix or workaround is created.
DHIS2 asks participating security researchers to:
- Provide DHIS2 reasonable time to fix the reported issue before disclosing issues to outside parties
- Not publicly disclose vulnerabilities or related details without explicit written authorization from DHIS2
- Not include sensitive or identifying data in any public disclosures