Overview

This section describes Payara’s official policy for managing Payara Platform’s security vulnerabilities.

The CVE Program

Payara, a leading provider of Jakarta EE and MicroProfile runtimes, is authorized by the Common Vulnerabilities and Exposures (CVE) Program as a CVE Numbering Authority (CNA).

Payara will publish authoritative cybersecurity vulnerability information about its products via the CVE Program. Vulnerabilities will be given a unique, alphanumeric identifier, building the CVE List that feeds into the U.S. National Vulnerability Database (NVD), and playing a role in the CVE Program’s mission to identify, define and catalogue cybersecurity vulnerabilities.

The CVE Program is sponsored by the Cybersecurity and Infrastructure Security Agency (CISA) of the U.S. Department of Homeland Security (DHS).

Developers using Payara Platform products will benefit from the collaboration, as vulnerabilities will be part of the standardized and publicly disclosed CVE List. This will result in time and cost savings for those using Payara products, as security issues can be discussed, dealt with and prevented through the use of a trusted, standardized catalogue.

In general, Payara follows the CVE Program’s CNA Operational rules to make decisions on reported vulnerabilities and CVE record management.

General Guidelines

  • Payara is committed to fixing any vulnerabilities and exploits identified in any Payara Platform products and distributions.

  • Any reported vulnerabilities will be fixed with celerity as soon as they are reported and confirmed.

  • Security vulnerabilities will have to be verified to affect a Payara Platform product before getting a CVE ID assigned.

  • Vulnerabilities reported on product versions that are no longer supported due to having reached their End-of-Support will be disclosed but will NOT be fixed.

  • Vulnerabilities not related to the Payara Platform will be ignored and not disclosed as CVE records. These include:

    • Operating system vulnerabilities

    • JVM-specific vulnerabilities

    • Conditions or behaviors that do not lead to a security impact.

      • These include an increase in access for an attacker, a decrease in availability of a target, or a violation of an implemented security policy.

    • Physical attacks unless there is a specific security feature, supported claim, or policy that defends against the physical attack.

    • Well-documented or commonly understood non-default configuration or runtime changes made by an authorized user

    • Brute-force denial-of-service (DoS) and brute-force resource exhaustion attacks, for example, high-rate or high-bandwidth denial-of-service attacks.

      • Failure to implement common defenses against such attacks will also be determined NOT to be valid vulnerabilities.

  • Payara Enterprise customers can request security fixes to be back-ported to any supported releases (if allowed by their corresponding Enterprise support lifecycle) used on their environments.

Vulnerabilities on Third-party Components

As the Payara Platform depends on third-party components of other software packages like Apache Guava, Jackson, Smack, etc. Vulnerabilities on specific versions of these components may be reported as well. Payara is committed to analysing any reported vulnerabilities and upgrading them to a patched version whether applicable.

In these cases, reports SHOULD if possible reference an existing CVE record that details the vulnerability in question.

Reporting Security Vulnerabilities

To report a vulnerability, make an official request through the Customer Support Portal. Please make sure to describe the vulnerability encountered in great detail, along with detailed steps on how to reproduce or exploit the vulnerability and environmental details like:

  • Payara Platform distribution (i.e, Server, Micro, Embedded, Docker Image) and version

  • Operating System

  • JDK Version

If the report is related to a Vulnerabilities on Third-party Components, please include the CVE ID of the vulnerability that affects the third-party component if you have access to it.

CVE ID Assignment

Once a report it’s received, we’ll determine if it exposes a valid vulnerability that needs to be disclosed and assign a CVE ID to it as established by the CNA Program rules. We’ll assign a CVE ID when:

  1. Payara reasonable evidence to determine the existence of a vulnerability on the report.

  2. The vulnerability has been or is expected to be publicly disclosed.

  3. The vulnerability has the potential to cause significant harm.

If these conditions are not met, Payara will not address the vulnerability and will NOT assign a CVE ID.

If a report includes evidence of multiple independently fixable vulnerabilities, Payara will assign separate CVE IDs for each confirmed vulnerability in the report.

CVE Record Disclosure

Once a security vulnerability is fixed and published in an official release of Payara Platform Enterprise, the following will occur:

  • The details of the vulnerability will be published in the release notes in this documentation site.

  • The CVE record will be officially published.

  • Customers will be notified of any necessary mitigation measures to be considered if they are affected by the vulnerability.

CVE Record Rejection

In some cases, the investigation of a vulnerability that has a CVE ID assigned may yield a result where the vulnerability in question does not warrant a fix (it cannot be reproduced, it doesn’t affect the Payara Platform, is not considered as harmful as originally reported).

In cases like this, the CVE record will be rejected along with a reason explaining why the vulnerability didn’t require disclosure.

CVE Disputes

If as a reporter, you do not agree with the assessment that Payara has made on a reported vulnerability when a CVE has not been assigned or an assigned CVE has been rejected, you may let us know through the corresponding customer portal ticket. We’ll follow the CVE Program Policy and Procedure for Disputing a CVE Record to handle the resolution of this dispute within our scope as a CNA.

Payara will be open to negotiating any disputes and reconsider our position on previous assessments if enough evidence and information is provided by the reported.

Security Advisories

All security reports, that correspond to either fixes to vulnerabilities that affect the Payara Platform directly or vulnerabilities to its third-party dependencies are catalogued under the Security Advisories page.

Each vulnerability entry will contain:

  • Its CVE ID

  • The CVE record’s CVSS Score

  • The status of the vulnerability (FIXED, REJECTED, N/A)

  • The summary of the exploit

  • The release where a fix was published (if applicable)

  • Additional observations on the resolution of the vulnerability.

Credits

If you are interested in being credited as the finder and/or reporter of the vulnerability, please let us know explicitly on your report and provide the following details:

  • Your name or an alias.

  • (Optional) The name of an organisation you belong to and wants to be credited.

See Also