Security is of the utmost importance to LabKey. We take a proactive approach to improving the platform and creating secure software, testing new and existing features for potential vulnerabilities, and scanning our dependencies. We also acknowledge that security issues will be identified after the software has been developed and deployed. As such, we have instituted the following policies.
We welcome reports of any issues that the community may identify. Please use our Contact Us form to securely send us information about potential vulnerabilities.
Whether we discover an issue ourselves or it is reported to us, the LabKey team will promptly assess the issue, confirm if it is a true vulnerability, and determine a timeline for resolution based on the severity of the risk. We use the Common Vulnerability Scoring System (CVSS) to score the issue and guide our follow-up steps, completing the Base Score Metrics assessment under the following assumptions. Note that not all of these conditions will apply to all user servers.
If the vulnerability is in code that is solely deployed in mitigating conditions (for example, in a module that is only used by one production installation which is behind a firewall and not on the public Internet), we will adjust the scoring accordingly.
We then compare the CVSS (version 3.1) score to the following industry ranges, and take the following actions. Note that depending on the specific circumstances, we may take a more aggressive approach than what is described here.
|None, Low||0.0 - 3.9||Fix in the next major LabKey Server release.|
|Medium||4.0 - 6.9||Hotfix the current LabKey Server major release, post for customers, and communicate that it contains a security fix.|
|High, Critical||7.0 - 10.0||Hotfix the current major release, backport to the previous major release, repost Community Edition installers, broadly communicate that there is an important security fix.|
Please contact your Account Manager if you have questions or concerns.
LabKey has patched the following Common Vulnerabilities and Exposures (CVE). We thank Tenable and Rhino Security Labs for their issue reports.
|CVE||Vulnerability Type||Versions Patched|
|CVE-2019-3911||Reflected cross-site scripting (XSS)||18.2-60915, All official 18.3 and later releases|
|CVE-2019-3912||Open redirects||All official 18.3 and later releases|
|CVE-2019-3913||Site admins can unmount drive through invalid input||All official 18.3 and later releases|
|CVE-2019-9758||Stored cross-site scripting (XSS)||19.1.1, all later releases, backported to 17.2, 18.2, and 18.3 releases|
|CVE-2019-9926||Cross-site request forgery (CSRF) for R script reports||19.1.1, all later releases, backported to 17.2, 18.2, and 18.3 releases|
|CVE-2019-9757||XML External Entity (XXE) in PDF and SVG generation||19.1.1, all later releases, backported to 17.2, 18.2, and 18.3 releases|
Note that this table covers vulnerabilities in LabKey Server itself. LabKey also proactively reacts to and provides hotfixes for vulnerabilities reported in related software as described in the next section.
Monitoring third-party libraries that we depend on directly or indirectly is important for keeping our own software free of vulnerabilities. We have enabled automation to routinely scan all of our Java libraries and match them against public CVE databases.
Any reported CVEs in our dependencies are treated as any other test failure in our software and promptly investigated. We keep this list clear, either by updating the version of the library we use, by changing how we use it, or in special cases, by suppressing individual CVE reports when we can conclusively determine that they are either false positive reports, or do not apply to our usage.
Please contact us if you have questions or concerns.