Security Disclosure

Our team of dedicated security professionals works vigilantly to keep customer information secure. We recognize the important role that security researchers and our community play in keeping Palo Alto Networks and our customers secure. If you discover a product or website vulnerability, please notify us using the guidelines below.

Report a vulnerability specific to a Palo Alto Networks product

or email us at PSIRT@PaloAltoNetworks.com . For additional security, you can find our PGP key here .
Learn more about our Product Security Assurance and Vulnerability Disclosure Policy .

Report any other (non-product) vulnerability involving Palo Alto Networks

i.e. vulnerabilities affecting paloaltonetworks.com

View our Security Researcher Acknowledgements . Product Security Researcher Acknowledgements are currently located within the specific security advisory.

Guidelines for Responsible Disclosure Program

Palo Alto Networks follows the principle of Coordinated Vulnerability Disclosure . When Palo Alto Networks receives a security vulnerability report, we work as quickly as possible to develop an update and release it to our customers, so they can be protected.

We ask the security community to give us an opportunity to fix vulnerabilities before releasing information publicly and to follow the guidelines below:

Please do

Share the security issue with us before making it public on social media, message boards, mailing lists, conference talks, and other forums.
Provide full details of the security issue including steps to reproduce and the details of the system where the tests were conducted.
Wait until notified that the vulnerability has been resolved before disclosing it to others. We take the security of our customers very seriously, however some vulnerabilities take longer than others to resolve. There are several teams involved in working on these vulnerabilities depending on the vulnerability and the function being exploited.
If you are planning to present at a conference, let us know the date as soon as possible.

Please do not

Cause potential or actual damage to Palo Alto Networks users, systems or applications.
Use an exploit to view unauthorized data or corrupt data.
Request compensation for the reporting of security issues either to Palo Alto Networks, or through any external marketplace for vulnerabilities, whether black-market or otherwise.
Engage in disruptive testing like DoS or any action that could impact the confidentiality, integrity or availability of information and systems
Engage in social engineering or phishing of customers or employees
Request for compensation for time and materials or vulnerabilities discovered

Responsible Disclosure Policy

(applies to Non-Product Vulnerability Disclosures)

Accepted Web Vulnerabilities:

OWASP Top 10 vulnerability categories
Other vulnerabilities with demonstrated impact

Out of Scope Web Vulnerabilities:

Theoretical vulnerabilities
Informational disclosure of non-sensitive data
Low impact and/or Low Likelihood of occurrence session management issues
Self XSS (user defined payload)

Rules of Engagement

No Denial of Service testing
No Physical or Social Engineering
No testing of Third-party Services
No uploading of any vulnerability or client-related content to third-party utilities (e.g. Github, DropBox, YouTube)
All attack payload data must use professional language
If able to gain access to a system, accounts, users, or user data, stop at the point of recognition and report. Do attempt to determine how much more is accessible.
Low Impact Vulnerabilities are out of scope (see details below)

Responsible Disclosure Details for Web Vulnerabilities

The following vulnerabilities are considered a very low impact and hence are out of scope for our Responsible Disclosure program.

Account/e-mail enumeration using brute-force attacks
- Valid user account/email enumeration not requiring brute-force will be considered
Any low impact issues related to session management (i.e. concurrent sessions, session expiration, password reset/change log out, etc.)
Bypassing content restrictions in uploading a file without proving the file was received
Clickjacking/UI redressing
Client-side application/browser autocomplete or saved password/credentials
Descriptive or verbose error pages without proof of exploitability or obtaining sensitive information
Directory structure enumeration (unless the fact reveals exceptionally useful information)
Incomplete or missing SPF/DMARC/DKIM records
Issues related to password/credential strength, length, lockouts, or lack of brute-force/rate limiting protections
- Account compromises (especially admin) as a result of these issues will likely be considered VALID
Lack of SSL or Mixed content
- Leaking Session Cookies, User Credentials, or other sensitive data will be reviewed on a case by case basis
- If leaking of sensitive data requires MiTM positioning to exploit, it will be considered out of scope
Login/Logout/Unauthenticated/Low-impact CSRF
- CSRF Vulnerabilities may be acceptable if they are of higher impact. Examples of low impact CSRF include: Add/Delete from Cart, Add/remove wishlist/favorites, Nonsevere preference options, etc.
Low impact Information disclosures (including Software version disclosure)
Missing Cookie flags
Missing/Enabled HTTP Headers/Methods which do not lead directly to a security vulnerability
Reflected file download attacks (RFD)
Self-exploitation (i.e. password reset links or cookie reuse)
SSL/TLS best practices that do not contain a fully functional proof of concept
URL/Open Redirection
Use of a known-vulnerable library which leads to a low-impact vulnerability (i.e. jQuery outdated version leads to low impact XSS)
Valid bugs or best practice issues that are not directly related to the security posture of the client
Vulnerabilities affecting users of outdated browsers, plugins or platforms
Vulnerabilities that allow for the injection of arbitrary text without allowing for hyperlinks, HTML, or JavaScript code to be injected
Vulnerabilities that require the user/victim to perform extremely unlikely actions (i.e. Self-XSS)
- Self-XSS for a Persistent/Stored XSS will be considered. Please review the Self-XSS article for more information.
- Any type of XSS that requires a victim to press an unlikely key combination is NOT in scope (i.e. alt+shift+x for payload execution)