Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Clone this wiki locally
A web application like phpMyAdmin can be vulnerable to a number of attacks. Even though the team does it's best to code securely things happen...we're human.
Please see our documentation for more details on security policy and usual types of vulnerabilities:
On this page we try to differentiate between the different threats. And explain how phpMyAdmin sees these.
Think you have found an issue, please contact the security team via email@example.com
When are security updates released?
When notified of a problem the security team does it's best to quickly come up with a patch.
TODO: specify the levels we also use in advisories
For critical issues it can be necessary to immediately make a release.
These releases usually contain only security fixes and use four digit version number (such as 220.127.116.11).
When an issue is deemed minor no special release is made, the fix will be included in the next stable release. The Changelog would describe the fix and should include the [security] prefix.
The security coordinator
- is the official voice of communication for security issues
- acknowledges issues with the reporters
- requests CVE ids
- communicates the outcome to the reporters when fixes are released
- ensures that all issues have been answered
The security team
- communicates on the private security mailing list only
- verifies issues
- prepares and test fixes
- discusses the target version for fixes
- every security member has access to shared PGP key
- reporters can encrypt reports to make them secret
- the PGP key is sent to every member encrypted
- every member of security team is expected to sign this key and publish the signature on keyservers
Tracking of security issues happens in the phpmyadmin-security repository:
- Every issue is created once the report is received
- Anybody working on that can assign it to himself
- The issue is assigned labels according to release which need fixes (eg.
- Once it is clear we need PMASA for this issue, it gets
- Once the issue is fixed in the security repos (all branches), it gets
- Once PMASA is written, it's number is written at the end of summary, linked from the issue comment and label
pmasa neededis removed
- Once the security release is out, the issue is closed
The tracker is here: https://github.com/phpmyadmin/phpmyadmin-security/issues
Preparation takes place in the Git_Security repository, and is internally communicated via the security mailinglist.
If a security team member wishes to submit a pull request before merging the changes, the process is to create and push a new branch to the security repository, then create the pull request inside the repository from that private branch. This way, the changes aren't revealed before the security issue is made public.
- Add separate commit to every affected (and supported) branch (usually bunch of older
- Merge the latest
QA_*-securitybranch with fix to
master-security(this is especially needed with intrusive fixes or things which have meanwhile changed in master to ensure we have master branch ready with all the fixes at time of release).
Preparing a PMASA
See the template guide in PMASA for details. The PMASA should be drafted and reviewed by several security team members for accuracy, then published when a new phpMyAdmin release occurs.
Obtaining CVE ID
If the issue has not yet assigned CVE ID, the security coordinator will ask for one by submitting through the MITRE CVE web form at https://cve.mitre.org/cve/request_id.html
The web form has several questions that we should attempt to answer consistently.
- Contact email address: the security submission email list
- Product name: phpMyAdmin
- Vendor name: phpMyAdmin
- Version affected: example: "18.104.22.168 and older, 22.214.171.124 and older, 4.6.4 and older"
- Version fixed: example: 126.96.36.199, 188.8.131.52, 4.6.5
Preparing for release
If the issue is not yet disclosed, the release date and possible references should be checked with reporter.
Reporter might want to include his or company name together with link in PMASA, whould should be honored.
Releasing and disclosing
Once all changes are ready, they are pushed to public repository together with PMASA announcements and standard release process follows, see Releasing for more details.