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.

Reporting Security Issues

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.

Assessment and Remediation

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.

  • The LabKey Server installation is on the public Internet
  • Guest users have some access, i.e. can read the /Home project or similar
  • Self-registration is enabled, and logged in users are at least Submitters in one folder
  • The server is configured and maintained following industry best practices

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.

Severity Score Action
None, Low 0.0 - 3.9 Fix in the next LabKey Server extended support release (ESR).
Medium 4.0 - 6.9 Hotfix the current LabKey Server ESR, post for customers, and communicate that it contains a security fix.
High, Critical 7.0 - 10.0 Hotfix the current ESR, backport to the previous ESR, repost Community Edition installers, broadly communicate that there is an important security fix.

Premium Edition Support

  • For Enterprise Edition clients, LabKey will consider backporting hotfixes to the three most recent ESRs, i.e. the current and two previous ESR releases, covering roughly a calendar year.
  • For Professional and Starter Edition clients, LabKey will only backport to the most recent ESR. However, LabKey provides a six-week grace period after each release is delivered to give clients a reasonable opportunity to upgrade.

Please contact your Account Manager if you have questions or concerns.

LabKey Server CVEs

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.

Dependency CVE Monitoring

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.

Related Topics

Was this content helpful?

Log in or register an account to provide feedback

expand allcollapse all