Submit a Vulnerability to the Critical Defense Program

1. Sign in to the Critical Defense Program portal.
2. Click Submit New Vulnerability.

   A five-step progress indicator at the top of the panel tracks your position in the submission process. You can navigate back to any completed step using the Back button.
3. Provide information about the Patch Status to identify the affected product and its current remediation state.

   This section establishes which product the vulnerability affects and where it stands in the patch and disclosure lifecycle, so Palo Alto Networks can scope coverage to the correct versions and align deployment with your disclosure timeline.

   1. Enter the Vendor Name of the organization responsible for the affected product.

      Pre-filled with your organization. Change it when you report a vulnerability in a third-party or open source component owned by a different vendor, so that Palo Alto Networks links it to the correct product owner.
   2. Enter the official Product Name that contains the vulnerability.

      Use the same product name that appears in your security advisory or CVE record. This links the vulnerability to the correct signature scope for Frontier Virtual Patching.
   3. Enter the earliest and latest Affected Version Range in which the vulnerability exists.

      An accurate range ensures signatures target only the affected codebase. Too broad increases false positives; too narrow leaves vulnerable versions unprotected.
   4. (Optional) Enter the Product Package URL (PURL) identifier for the affected software component.

      A standardized identifier in the format pkg:type/namespace/name@version (for example, pkg:maven/org.apache/log4j@2.14.1). Separate multiple PURLs with commas. A PURL lets Palo Alto Networks link your submission to existing CVE records.
   5. (Optional) Enable OSS Component when the vulnerability is in an open source component embedded in the product, then provide the component details.

      Links an open source CVE to the commercial product that embeds it, so coverage protects the component wherever it is reachable. This matters most for operational technology (OT) and commercial software.

      • Enter the OSS Component Name, for example, log4j or OpenSSL.
      • Enter the OSS Version that contains the vulnerability.
      • (Optional) Enter the OSS CVE in the format CVE-YYYY-NNNNN to reference the existing open source CVE record.
      • (Optional) Enter the OSS Package URL (PURL) for the component. Separate multiple PURLs with commas.
   6. Choose the Patch Status that describes the current state of your patch development.

      • Not yet patched
        A fix is not yet available. Virtual patch deployment is the primary protection during this period.
      • Patch available
        A fix exists but has not been broadly distributed or communicated to customers.
      • Patch deployed and customers notified
        The fix is available and customers have been informed. Choose this option when you are preparing for public disclosure.
   7. (Optional) Enter the Fixed Version(s) where you resolved the vulnerability.

      Lets Palo Alto Networks scope the virtual patch to the affected range and retire protection automatically once customers upgrade. You can update this after submission.
   8. Choose the Public Disclosure Status that describes the current state of public awareness about the vulnerability.

      • Not yet disclosed
        No public information exists. The vulnerability is known only to your organization and Palo Alto Networks.
      • Partially disclosed
        Limited public information exists, such as a vendor advisory without full technical details.
      • Publicly disclosed
        The vulnerability is documented in a public CVE record or security advisory. Choose this option if you are providing additional technical detail to improve existing coverage.
   9. Click Next.
4. Provide CVE Information to notify Palo Alto Networks about the CVE assignment status and your organization's role in the CVE process.

   This section captures where the vulnerability stands in the CVE assignment process, so Palo Alto Networks can link the virtual patch to the correct CVE record and coordinate CVE minting on your behalf if requested.

   1. (Optional) Enter the CVE ID (CVE identifier) assigned to this vulnerability.

      Enter the CVE ID in the format CVE-YYYY-NNNNN. If you do not yet have one, leave it blank and update it after submission. Palo Alto Networks uses it to link the virtual patch to the public record at the Active stage.
   2. (Optional) Enter your Partner Internal ID to cross-reference this submission with your own tracking system.

      Your organization's internal tracking identifier, such as a bug or case number. Up to 64 characters, using letters, numbers, hyphens, and underscores. Palo Alto Networks stores it so you can correlate the submission with your own records.
   3. Choose the CVE Assignment Status that reflects the current state of your CVE request.

      • Not yet required
        A CVE is not yet needed for this vulnerability.
      • Pending
        A CVE has been requested but not yet assigned.
      • Assigned
        A CVE ID has been issued for this vulnerability.
   4. Choose your organization's CNA Role in the CVE Numbering Authority process.

      • Self-minting (Submitter is CNA)
        Your organization is an authorized CVE Numbering Authority (CNA) and will assign the CVE ID directly.
      • Request PAN to mint
        Your organization does not have CNA authority. Palo Alto Networks will coordinate CVE assignment on your behalf through its CNA role.
      • No CVE required
        The vulnerability does not require a CVE ID, for example, proprietary protocols or internal vulnerabilities not subject to public disclosure.
   5. Click Next.
5. Provide the Vulnerability Details to describe technical characteristics of the vulnerability.

   The Agentic IPS pipeline uses these details to generate proof-of-concept exploits, build multivariate protections, and validate signatures against evasion techniques. The more technical detail you provide, the faster and more accurate signature generation is.

   1. Choose one or more Vulnerability Type categories that describe the vulnerability.

      You can select multiple types and change your selection after submission. Options are Remote Code Execution, Authentication Bypass, Privilege Escalation, Denial of Service, Information Disclosure, SQL Injection, Buffer Overflow, and Other. The vulnerability type informs the signature generation strategy and coverage approach the Agentic IPS pipeline uses.
   2. Enter the CVSS Score for this vulnerability.

      The Common Vulnerability Scoring System (CVSS) score sets the severity and populates the severity badge on the dashboard and in telemetry reports. The read-only Severity Level field is calculated from the score and cannot be edited. Enter the score from your advisory or CVE record.
   3. For CVSS Vector String, enter the full CVSS vector string for this vulnerability.

      Encodes the full set of CVSS base metrics, such as attack vector, privileges required, and impact scope, in a compact format (for example, CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H). It gives Palo Alto Networks a complete picture of exploitability and impact.
   4. Enter the technical Vulnerability Description. This can include the root cause, attack vector, and conditions required for exploitation.

      Write a description detailed enough for Palo Alto Networks researchers to reproduce the vulnerability independently: the affected component or module, the input or network request that triggers the issue, and any preconditions such as authentication state or configuration. This is the primary input the Agentic IPS pipeline uses to generate candidate exploits.
   5. (Optional) Enter the Detection Guidance to describe the observable differences between malicious exploit traffic and normal application behavior.

      The Agentic IPS pipeline uses detection guidance directly to distinguish exploit traffic from legitimate traffic, which improves accuracy and reduces false positives. Examples include HTTP headers or parameter values that appear only in exploit attempts, protocol anomalies, or payload characteristics unique to exploitation.
   6. (Optional) Enter the Exploit Behavior to describe what occurs on the target system when the vulnerability is successfully exploited.

      Describing post-exploitation behavior helps Palo Alto Networks cover the full exploit chain, not only the initial trigger: for example, which processes launch, which files the exploit creates, or which network connections open. Include any indicators of compromise (IOCs) if known.
   7. Click Next.
6. Set the Embargo Policy to authorize each coverage type and control when Palo Alto Networks may release it.

   The embargo policy authorizes each coverage type independently and sets when Palo Alto Networks may release it. You enable the coverage types you want, and for each one you set the date Palo Alto Networks is authorized to publicly disclose the vulnerability. Palo Alto Networks offers two coverage types: Vaulted (Frontier Virtual Patching) and Standard (Advanced Threat Prevention).

   1. For Vaulted (Frontier Virtual Patching) coverage, choose when Palo Alto Networks is Authorized to Release the protection.

      Vaulted coverage is isolated, cloud-based protection that detects and mitigates exploits targeting zero-day and pre-disclosure vulnerabilities. The vulnerability details and underlying protection mechanisms remain confidential to prevent adversary reconnaissance.

      • Choose As of today for no embargo, or choose On a specific date and enter the date on which Palo Alto Networks is authorized to publicly disclose the vulnerability.
      • Under Metadata Disclosure, review which submission metadata Palo Alto Networks may disclose with this coverage. Vendor Name is required and Severity Level is included if provided. Select Authorize to allow Palo Alto Networks to disclose the Product Name.
   2. For Standard (Advanced Threat Prevention) coverage, choose when Palo Alto Networks is Authorized to Release the protection.

      Standard coverage is comprehensive Advanced Threat Prevention delivered through routine content updates to NGFW. These signatures draw on both pre- and post-disclosure intelligence and are published upon public disclosure of the vulnerability. Choose As of today for no embargo, or choose On a specific date and enter the date on which Palo Alto Networks is authorized to publicly disclose the vulnerability.
   3. Click Next.
7. Set the Classification to apply a Traffic Light Protocol (TLP) designation and upload technical artifacts.

   The classification controls how broadly Palo Alto Networks shares your submission data internally, and the artifacts you upload are the highest-value inputs for signature generation.

   1. Choose the Submission-Level TLP Classification that controls how Palo Alto Networks handles your submission data.

      All artifacts in the submission inherit this classification by default.

      • TLP:AMBER (default)
        Palo Alto Networks restricts submission data to its internal teams. TLP:AMBER is the recommended default for pre-disclosure vulnerability data.
      • TLP:RED
        Palo Alto Networks restricts submission data to named researchers explicitly assigned to your submission. Choose this classification for highly sensitive vulnerabilities where you need to limit internal access further.
      • TLP:GREEN
        Palo Alto Networks may share submission data within its community. Choose this classification when broader internal sharing is acceptable.
      • TLP:CLEAR
        Submission data carries no distribution restrictions. Choose this classification only for vulnerabilities that are already publicly known or where unrestricted sharing is appropriate.
   2. (Optional) To add partner-specific metadata, click Add field under Custom Metadata Fields, then define each field.

      Custom metadata fields are structured key-value pairs that capture partner-specific information that does not fit the standard form fields, such as an on-behalf-of tracking reference. You can add multiple fields. Each key must be unique within the submission. A key can be up to 64 characters and a value up to 1024 characters. You can edit custom fields after submission.

      • Choose the field type: String, Number, or Boolean.
      • Enter the Key and its value.
      • To add another field, click Add field again. To remove a field, click the delete icon next to it.
   3. (Optional) Upload technical artifacts by dragging files into the upload zone or clicking Browse files.

      Accepted artifact types include proof-of-concept (PoC) exploit code, PCAP files, binary samples, SBOM files, detection notes, and any other file type. Each file must be no larger than 1 GB, and a submission can include up to 100 files. Palo Alto Networks stores artifacts in the Vulnerability Database (VDB), encrypts them at rest, and restricts access to assigned researchers; you can add files after submission while it is being processed. Uploading PCAP files and PoC exploit code significantly accelerates signature generation, because the pipeline uses them directly to validate candidate protections.
8. Click Submit.

   The portal assigns a unique submission ID in the format PANSUB-YYMMDD-NNNNN and sends an acknowledgment email to your registered address. The submission status on the dashboard changes to Intake. Submissions that include PCAP data typically complete signature generation within eight hours. Submissions without PCAP data may require additional processing time.

   After submission, Palo Alto Networks routes your submission through an automated pipeline. You can track the current stage in the portal dashboard at any time.

   • Intake
     The portal receives and logs your submission.
   • Analysis
     Palo Alto Networks security researchers validate the vulnerability details and assess exploitability and severity.
   • Queued
     The submission enters the signature generation queue and the Agentic IPS pipeline begins building candidate protections.
   • Sig Dev
     The pipeline generates multivariate protections, validates them against evasion techniques, and prepares them for cloud deployment.
   • Shadow
     Palo Alto Networks deploys the virtual patch in monitoring mode to validate signature accuracy against real-world traffic before enforcement begins.
   • Vaulted
     The signature moves to enforcement mode. Customers with an ATP+ subscription receive active protection. Signature details remain cryptographically sealed under embargo.
   • Active
     After public disclosure and a patch are available, the signature graduates to a standard Advanced Threat Prevention content update and Palo Alto Networks distributes it through normal content update channels.