* [Blog](https://origin-researchcenter.paloaltonetworks.com/blog)
* [Cloud Security](https://origin-researchcenter.paloaltonetworks.com/blog/cloud-security/)
* [Application Security](https://origin-researchcenter.paloaltonetworks.com/blog/category/application-security/)
* All the Small Things: Azu...

# All the Small Things: Azure CLI Leakage and Problematic Usage Patterns

[](https://www.facebook.com/sharer/sharer.php?u=https%3A%2F%2Forigin-researchcenter.paloaltonetworks.com%2Fblog%2Fcloud-security%2Fsecrets-leakage-user-error-azure-cli%2F)  
[](https://twitter.com/share?text=All+the+Small+Things%3A+Azure+CLI+Leakage+and+Problematic+Usage+Patterns&url=https%3A%2F%2Forigin-researchcenter.paloaltonetworks.com%2Fblog%2Fcloud-security%2Fsecrets-leakage-user-error-azure-cli%2F)  
[](https://www.linkedin.com/shareArticle?mini=true&url=https%3A%2F%2Forigin-researchcenter.paloaltonetworks.com%2Fblog%2Fcloud-security%2Fsecrets-leakage-user-error-azure-cli%2F&title=All+the+Small+Things%3A+Azure+CLI+Leakage+and+Problematic+Usage+Patterns&summary=&source=)  
[](https://www.paloaltonetworks.com//www.reddit.com/submit?url=https://origin-researchcenter.paloaltonetworks.com/blog/cloud-security/secrets-leakage-user-error-azure-cli/&ts=markdown)  
\[\](mailto:?subject=All the Small Things: Azure CLI Leakage and Problematic Usage Patterns)  
Link copied  
By [Aviad Hahami](https://www.paloaltonetworks.com/blog/author/aviad-hahami/?ts=markdown "Posts by Aviad Hahami")  
Nov 14, 2023  
11 minutes  
[Application Security](https://www.paloaltonetworks.com/blog/category/application-security/?ts=markdown)  
[CI/CD](https://www.paloaltonetworks.com/blog/cloud-security/category/ci-cd/?ts=markdown)  
[AppSec](https://www.paloaltonetworks.com/blog/tag/appsec/?ts=markdown)  
[Azure](https://www.paloaltonetworks.com/blog/tag/azure/?ts=markdown)  
[Cloud Research](https://www.paloaltonetworks.com/blog/tag/cloud-research/?ts=markdown)  
[DevOps](https://www.paloaltonetworks.com/blog/tag/devops/?ts=markdown)  
[GitHub Actions](https://www.paloaltonetworks.com/blog/tag/github-actions/?ts=markdown)

At the beginning of July 2023, I took a stroll around the [azure/login](https://github.com/Azure/login) GitHub Action repository. Looked through the repository's issues section, I immediately noticed [issue number 315](https://github.com/azure/login/issues/315). The issue was titled "*SECURITY: Azure/login in some cases leaks Azure Application Variables to the GitHub build log* ". And don't you just love when things leak stuff? I had to click! Let's see what's up.  
![](https://www.paloaltonetworks.com/blog/wp-content/uploads/2023/10/word-image-305943-1.png)

## Excuse Me? You Dropped Your Environment Variables

The issue reported by [@NoCopy](https://github.com/NoCopy) stated that "azure/login in some cases leaks Azure Application Variables to the GitHub build log." The user included an example workflow, a relevant az command use case and an example output that contains alleged credentials.
![Security issue reported in the Azure/login project](https://www.paloaltonetworks.com/blog/wp-content/uploads/2023/10/word-image-305943-2.png)
Figure 1: Security issue reported in the Azure/login project

Well this is pretty straight forward, I thought. You tell me that the Azure CLI simply outputs environment variables to [CI/CD](https://www.paloaltonetworks.com/cyberpedia/what-is-the-ci-cd-pipeline-and-ci-cd-security) logs without anyone (or at least without many people) knowing? And I can simply try to find these occurrences in the wild? (Remember -- "some cases"). That doesn't sound hard. I decided to give it a shot.

A search for the string shown in the report, "az webapp config appsettings", using GitHub's code search, yielded the following result in a [Microsoft-owned repository](https://github.com/Azure-Samples/copilot-nodejs-todo/blob/d927453bb92a0521bd3de416af33c73b90a40a2c/.github/workflows/deploy.yml#L49). See line 49 in figure 2.
![GitHub Actions workflow running an az CLI command](https://www.paloaltonetworks.com/blog/wp-content/uploads/2023/10/word-image-305943-3.png)
Figure 2: GitHub Actions workflow running an az CLI command

Ok, I thought, let's see if it's really that easy.

I clicked the View Runs button at the top to see the GitHub Actions workflow logs, scrolled to the relevant step of the workflow run, and then saw these two lurking around:
![Microsoft’s workflow logs exposing sensitive information](https://www.paloaltonetworks.com/blog/wp-content/uploads/2023/10/word-image-305943-4.png)
Figure 3: Microsoft's workflow logs exposing sensitive information

Well, that was easy. I smiled.

![](https://www.paloaltonetworks.com/blog/wp-content/uploads/2023/10/basketball.gif)

Seeing that the issue is indeed true, I did an initial lookup while also trying to see if I can find other commands.

The initial lookup yielded five vulnerability reports, four to Microsoft and one to GitHub. Throughout the research, I was able to disclose more findings to some other groups that I can't disclose, per their requests. I reported the findings to the relevant vulnerability disclosure programs, and all were all accepted and fixed. The findings' severities ranged from informative to critical.

## The Azure CLI: Bug or Feature?

In fact, many az functions (which are being run using the Azure CLI) echo back the accessed/created/updated/deleted resource alongside their environment variables, secrets, etc.

Down the line, I also found the following issues:

1. [https://github.com/Azure/login/issues/27](https://github.com/Azure/login/issues/27) - \[Security: Potential leak of az secrets on cmdline\]
2. [https://github.com/Azure/k8s-create-secret/issues/3](https://github.com/Azure/k8s-create-secret/issues/3) - \[Security: Pass secrets with --from-file instead of over the command line\]

Both of these issues showed environment variables echoing back to the log. That said, I didn't find a bug here. The Azure CLI actually echoes back this information as intended, so there's nothing buggy regarding the tool or its output.

What's actually problematic is the combination of *where* this tool is running and *who*can access the run logs.

So while the Azure CLI doesn't perform anything buggy, when executed in a pipeline with the echoed credentials stored in the pipeline's log, we suddenly find ourselves in a "who should be able to read the logs" kind of problem.

For public repositories and pipelines, this problem is easy to see and understand --- random internet stalkers (*comme moi!*) shouldn't access your production database keys.

For private repositories you may get a false sense of security due to the "private" title. But given one compromised account/token with the lowest "READ" permissions --- suddenly an actor can access raw production credentials and possibly escalate their privileges. Whoops.

Moving on, I wanted to find more variants and occurrences. To do so, I cloned the Azure CLI repo and looked through the various modules ( == about 64 options for different CMDs when running az CMD, e.g., "az webapp"), searching for existing leaks in CI logs using command variants.
![az commands list](https://www.paloaltonetworks.com/blog/wp-content/uploads/2023/10/word-image-305943-6.png)
Figure 5: az commands list

## Observing Usage Patterns of the Azure CLI in the Wild, Wild GitHub Actions

When I looked at the Azure CLI usages, I noted that even for cases where the tool was "supposed" to leak credentials, the developers' use differentiated between a full leak or the mitigation of it.

Where some developers didn't know about the tool's tendency to emit sensitive data, others did know (or at-least played it safe) and proactively mitigate the problem.

Classifying the usages, I found three main variations of usage patterns when using Azure CLI in GitHub actions.

### Pattern 1: Folks Who Didn't Know

Use cases among people who didn't anticipate the issue are especially problematic and an easy target for attackers. The developers weren't aware that the tool is spewing their credentials, so they didn't put any mitigations in place. This implies, then, that their logs contain raw sensitive information.

In some implementations, though, I saw developers getting "saved by the bell". This is when the developers defined the about-to-be-echoed credentials as secrets in the workflow --- but mainly for the input phase. GitHub Actions later masked, or partially masked, the output of the tool, protecting the tool users. Whether they knew about the nature of the output of the tool, I can't tell.

In the majority of the "saved by the bell" cases, I wasn't able to find full raw credentials. For the remaining cases, I encountered partial or insufficient maskings that still left secrets and sensitive data exposed. So no bell today.
![Workflow logs with masking and credentials leakage](https://www.paloaltonetworks.com/blog/wp-content/uploads/2023/10/word-image-305943-7.png)
Figure 6: Workflow logs with masking and credentials leakage

### Pattern 2: Folks Who Had It Right

Some developers knew, or assumed, that the Azure CLI would leak sensitive data. In these workflows, the developers either manually masked the entirety of the returned values or stored the responses in variables rather than letting them echo to the log. This usage pattern yielded zero credentials. Kudos!

### Pattern 3: The Folks Who Almost Had It Right

Incidents where folks who almost escaped without mishap but didn't make it in the end were unfortunate to witness and yet fun to find. These incidents happened where developers set up separate pipelines for create and delete actions (or equivalent).

To explain, let's look at an example. Let's assume there's a resource definition in a pipeline called Pipeline A that consumes a secret called "MY\_SECRET". When Pipeline A runs and executes the az command, it prints the echoed secret from the Azure CLI response --- but masked. This is because GitHub Actions identifies the string as sensitive information, as it should, and masks the string for us (similar to pattern 2; see figure 7).
![Pipeline A, defining a secret](https://www.paloaltonetworks.com/blog/wp-content/uploads/2023/10/word-image-305943-8.png)
Figure 7: Pipeline A, defining a secret

Meanwhile, its sibling pipeline, Pipeline B, performs other actions on the same resource, like delete. This time the secret "MY\_SECRET" isn't needed to execute the delete command and is not defined or used in Pipeline B.

So, when Pipeline B executes the delete command, the Azure CLI echoes the resource data securely created by Pipeline A back to Pipeline B! And since Pipeline B never defined "MY\_SECRET" as a secret, GitHub Actions doesn't mask the returned credentials. Eventually, we find ourselves with a pipeline emitting raw credentials to its log, similar to pattern 1.
![Pipeline B log leaking the secret](https://www.paloaltonetworks.com/blog/wp-content/uploads/2023/10/word-image-305943-9.png)
Figure 8: Pipeline B log leaking the secret

## How to Safely Use Azure CLI in Pipelines

So how can you sleep at night without knowing if your Azure CLI usage will emit sensitive information?

If you're working solely with private repositories and CI instances, you're "saved" by the authentication and authorization mechanisms you have. The problem remains bad, just not as bad as it would be for public repositories. Make no mistake, though. Relying on the privacy of your repositories and CIs is an incident waiting to happen, so don't do it.

To mitigate the issue, you have a few options, depending on your needs.

Prior to trying to handle the output in the log, you should consider replacing the static values in the applications with a more robust mechanism. Azure has a [solution using its Key Vault feature](https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/key-vault-parameter?tabs=azure-cli), and by utilizing [Bicep](https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/overview?tabs=bicep), for example, you could replace the static sensitive values in your applications settings with references to secrets stored in the vault. Doing so will make all the 'leakages' in the tool harmless, as the settings will now reference secrets instead of containing their values.

If you need to use the output of the az command, you could do either of the following:

1. Store the output in a variable so it doesn't get echoed to the log and use it later in your workflow. This holds up, for example, when testing the return code of an "az" invocation or grepping specific parts of the output.
2. Use JMESPath queries when fetching information with the tool using the built-in "--query" feature.

JMESPath (JSON Matching Expression paths) is a query language for searching JSON documents that allows you to declaratively extract elements from a JSON document.

By [using JMESPath you could directly access the desired property](https://learn.microsoft.com/en-us/cli/azure/query-azure-cli?tabs=concepts%2Cbash) in the tool's response and output only the relevant section/value.

If you don't need the output of the az command, you could:

1. Redirect the output to `/dev/null` --- This is a basic redirection option you could use to mute the output. Apply it like: "az webapp config ... \&\> /dev/null". Note that it's best to pipe both streams (stdout + stderr) to the location-of-no-return, as Azure CLI sometimes emits the credentials as a part of its error messages. In other words, a simple "az ... \> /dev/null" may not suffice.
2. Use the Azure CLI "output" option --- Although I've seen a low number of usages of this option, Azure allows setting the desired output format using the "--output/-o" option. This [option supports various values](https://learn.microsoft.com/en-us/cli/azure/format-output-azure-cli), and for our purposes we could use the "--output none" option.
3. Selective masking \[Not recommended\] --- You could go and start masking every returned value in your pipeline, but this will generate a headache and require attention and maintenance, as the usage will change with time. And the tool will change. And GitHub Actions will change. And TL;DR ... I do not recommend this approach.

## Famous Last Words

This lookup was fun and a cool thing to accidentally pick up from a random GitHub issues pile. As I stated in the beginning of this post, the bug isn't sophisticated or actually a bug at all. The usage patterns of Azure CLI, though, are "bugged" and should be reported.

So while we love the relative new ease of cloud-services usage in 202x, we need to remain mindful of what's printing into those logs, where the logs reside and who can read them.

Happy coding!

## Update: Collaborating with Microsoft on CVE-2023-36052

In addition to solving the issues reported on their open-source projects, Microsoft validated the issues with the Azure CLI and assigned [CVE-2023-36052](https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-36052) with a CVSS score of 8.6. [Microsoft then made changes to the Azure CLI](https://msrc.microsoft.com/blog/2023/11/microsoft-guidance-regarding-credentials-leaked-to-github-actions-logs-through-azure-cli/), Azure Pipelines and GitHub Actions. They published a new release of Azure CLI as part of their November 2023 Patch Tuesday. By avoiding echoing secrets, the new release prevents leakage in CI pipeline logs, developers' machines, and log aggregators.

We recommend updating the Azure CLI versions used in CI runners and developers' machines to 2.54, to make sure no secrets are printed to the logs.

## Learn More

Because of the data they store and the workloads they run, CI/CD systems are among the most critical and sensitive assets in your organization. Discover how to apply policy-as-code, implement an effective secrets scanning strategy, adopt least-privileged access, and establish robust logging and monitoring with our [CI/CD Security Checklist](https://www.paloaltonetworks.com/resources/datasheets/cicd-security-checklist).

If you haven't tried Prisma Cloud and would like to, we'd love for you to experience a free[30-day Prisma Cloud trial](https://www.paloaltonetworks.com/prisma/request-a-prisma-cloud-trial).

*** ** * ** ***

## Related Blogs

### [CI/CD](https://www.paloaltonetworks.com/blog/cloud-security/category/ci-cd/?ts=markdown), [DevOps](https://www.paloaltonetworks.com/blog/cloud-security/category/devops/?ts=markdown)

[#### Unpinnable Actions: How Malicious Code Can Sneak into Your GitHub Actions Workflows](https://origin-researchcenter.paloaltonetworks.com/blog/cloud-security/unpinnable-actions-github-security/)

### [Application Security](https://www.paloaltonetworks.com/blog/category/application-security/?ts=markdown), [CI/CD](https://www.paloaltonetworks.com/blog/cloud-security/category/ci-cd/?ts=markdown)

[#### AppSec for the Modern Engineering Ecosystem](https://origin-researchcenter.paloaltonetworks.com/blog/cloud-security/appsec-engineering-ecosystem/)

### [AppSec](https://www.paloaltonetworks.com/blog/cloud-security/category/appsec/?ts=markdown), [CI/CD](https://www.paloaltonetworks.com/blog/cloud-security/category/ci-cd/?ts=markdown), [Research](https://www.paloaltonetworks.com/blog/category/research/?ts=markdown)

[#### ArtiPACKED: Hacking Giants Through a Race Condition in Github Actions Artifacts](https://origin-researchcenter.paloaltonetworks.com/blog/cloud-security/github-repo-artifacts-leak-tokens/)

### [Data Security](https://www.paloaltonetworks.com/blog/category/data-security/?ts=markdown), [Data Security Posture Management](https://www.paloaltonetworks.com/blog/cloud-security/category/data-security-posture-management/?ts=markdown)

[#### Are Cloud Serverless Functions Exposing Your Data?](https://origin-researchcenter.paloaltonetworks.com/blog/cloud-security/secure-access-cloud-serverless-functions/)

### [AppSec](https://www.paloaltonetworks.com/blog/cloud-security/category/appsec/?ts=markdown), [CI/CD](https://www.paloaltonetworks.com/blog/cloud-security/category/ci-cd/?ts=markdown), [Cloud Native Application Protection Platform](https://www.paloaltonetworks.com/blog/category/cloud-native-application-protection-platforms/?ts=markdown)

[#### Drive Towards Preventing Breaches and Pipeline Attacks with Prisma Cloud](https://origin-researchcenter.paloaltonetworks.com/blog/cloud-security/cicd-security-cnapp-risk-prevention/)

### [AppSec](https://www.paloaltonetworks.com/blog/cloud-security/category/appsec/?ts=markdown), [CI/CD](https://www.paloaltonetworks.com/blog/cloud-security/category/ci-cd/?ts=markdown), [DevOps](https://www.paloaltonetworks.com/blog/cloud-security/category/devops/?ts=markdown), [Research](https://www.paloaltonetworks.com/blog/category/research/?ts=markdown)

[#### The GitHub Actions Worm: Compromising GitHub Repositories Through the Actions Dependency Tree](https://origin-researchcenter.paloaltonetworks.com/blog/cloud-security/github-actions-worm-dependencies/)

### Subscribe to Cloud Security Blogs!

Sign up to receive must-read articles, Playbooks of the Week, new feature announcements, and more.
![spinner](https://origin-researchcenter.paloaltonetworks.com/blog/wp-content/themes/panwblog2023/dist/images/ajax-loader.gif) Sign up  
Please enter a valid email.  
By submitting this form, you agree to our [Terms of Use](https://www.paloaltonetworks.com/legal-notices/terms-of-use?ts=markdown) and acknowledge our [Privacy Statement](https://www.paloaltonetworks.com/legal-notices/privacy?ts=markdown). Please look for a confirmation email from us. If you don't receive it in the next 10 minutes, please check your spam folder.  
This site is protected by reCAPTCHA and the Google [Privacy Policy](https://policies.google.com/privacy) and [Terms of Service](https://policies.google.com/terms) apply.  
{#footer} {#footer}

## Products and Services

* [AI-Powered Network Security Platform](https://www.paloaltonetworks.com/network-security?ts=markdown)

* [Secure AI by Design](https://www.paloaltonetworks.com/precision-ai-security/secure-ai-by-design?ts=markdown)

* [Prisma AIRS](https://www.paloaltonetworks.com/prisma/prisma-ai-runtime-security?ts=markdown)

* [AI Access Security](https://www.paloaltonetworks.com/sase/ai-access-security?ts=markdown)

* [Cloud Delivered Security Services](https://www.paloaltonetworks.com/network-security/security-subscriptions?ts=markdown)

* [Advanced Threat Prevention](https://www.paloaltonetworks.com/network-security/advanced-threat-prevention?ts=markdown)

* [Advanced URL Filtering](https://www.paloaltonetworks.com/network-security/advanced-url-filtering?ts=markdown)

* [Advanced WildFire](https://www.paloaltonetworks.com/network-security/advanced-wildfire?ts=markdown)

* [Advanced DNS Security](https://www.paloaltonetworks.com/network-security/advanced-dns-security?ts=markdown)

* [Enterprise Data Loss Prevention](https://www.paloaltonetworks.com/sase/enterprise-data-loss-prevention?ts=markdown)

* [Enterprise IoT Security](https://www.paloaltonetworks.com/network-security/enterprise-device-security?ts=markdown)

* [Medical IoT Security](https://www.paloaltonetworks.com/network-security/medical-device-security?ts=markdown)

* [Industrial OT Security](https://www.paloaltonetworks.com/network-security/medical-device-security?ts=markdown)

* [SaaS Security](https://www.paloaltonetworks.com/sase/saas-security?ts=markdown)

* [Next-Generation Firewalls](https://www.paloaltonetworks.com/network-security/next-generation-firewall?ts=markdown)

* [Hardware Firewalls](https://www.paloaltonetworks.com/network-security/hardware-firewall-innovations?ts=markdown)

* [Software Firewalls](https://www.paloaltonetworks.com/network-security/software-firewalls?ts=markdown)

* [Strata Cloud Manager](https://www.paloaltonetworks.com/network-security/strata-cloud-manager?ts=markdown)

* [SD-WAN for NGFW](https://www.paloaltonetworks.com/network-security/sd-wan-subscription?ts=markdown)

* [PAN-OS](https://www.paloaltonetworks.com/network-security/pan-os?ts=markdown)

* [Panorama](https://www.paloaltonetworks.com/network-security/panorama?ts=markdown)

* [Secure Access Service Edge](https://www.paloaltonetworks.com/sase?ts=markdown)

* [Prisma SASE](https://www.paloaltonetworks.com/sase?ts=markdown)

* [Application Acceleration](https://www.paloaltonetworks.com/sase/app-acceleration?ts=markdown)

* [Autonomous Digital Experience Management](https://www.paloaltonetworks.com/sase/adem?ts=markdown)

* [Enterprise DLP](https://www.paloaltonetworks.com/sase/enterprise-data-loss-prevention?ts=markdown)

* [Prisma Access](https://www.paloaltonetworks.com/sase/access?ts=markdown)

* [Prisma Browser](https://www.paloaltonetworks.com/sase/prisma-browser?ts=markdown)

* [Prisma SD-WAN](https://www.paloaltonetworks.com/sase/sd-wan?ts=markdown)

* [Remote Browser Isolation](https://www.paloaltonetworks.com/sase/remote-browser-isolation?ts=markdown)

* [SaaS Security](https://www.paloaltonetworks.com/sase/saas-security?ts=markdown)

* [AI-Driven Security Operations Platform](https://www.paloaltonetworks.com/cortex?ts=markdown)

* [Cloud Security](https://www.paloaltonetworks.com/cortex/cloud?ts=markdown)

* [Cortex Cloud](https://www.paloaltonetworks.com/cortex/cloud?ts=markdown)

* [Application Security](https://www.paloaltonetworks.com/cortex/cloud/application-security?ts=markdown)

* [Cloud Posture Security](https://www.paloaltonetworks.com/cortex/cloud/cloud-posture-security?ts=markdown)

* [Cloud Runtime Security](https://www.paloaltonetworks.com/cortex/cloud/runtime-security?ts=markdown)

* [Prisma Cloud](https://www.paloaltonetworks.com/prisma/cloud?ts=markdown)

* [AI-Driven SOC](https://www.paloaltonetworks.com/cortex?ts=markdown)

* [Cortex XSIAM](https://www.paloaltonetworks.com/cortex/cortex-xsiam?ts=markdown)

* [Cortex XDR](https://www.paloaltonetworks.com/cortex/cortex-xdr?ts=markdown)

* [Cortex XSOAR](https://www.paloaltonetworks.com/cortex/cortex-xsoar?ts=markdown)

* [Cortex Xpanse](https://www.paloaltonetworks.com/cortex/cortex-xpanse?ts=markdown)

* [Unit 42 Managed Detection \& Response](https://www.paloaltonetworks.com/cortex/managed-detection-and-response?ts=markdown)

* [Managed XSIAM](https://www.paloaltonetworks.com/cortex/managed-xsiam?ts=markdown)

* [Threat Intel and Incident Response Services](https://www.paloaltonetworks.com/unit42?ts=markdown)

* [Proactive Assessments](https://www.paloaltonetworks.com/unit42/assess?ts=markdown)

* [Incident Response](https://www.paloaltonetworks.com/unit42/respond?ts=markdown)

* [Transform Your Security Strategy](https://www.paloaltonetworks.com/unit42/transform?ts=markdown)

* [Discover Threat Intelligence](https://www.paloaltonetworks.com/unit42/threat-intelligence-partners?ts=markdown)

## Company

* [About Us](https://www.paloaltonetworks.com/about-us?ts=markdown)
* [Careers](https://jobs.paloaltonetworks.com/en/)
* [Contact Us](https://www.paloaltonetworks.com/company/contact-sales?ts=markdown)
* [Corporate Responsibility](https://www.paloaltonetworks.com/about-us/corporate-responsibility?ts=markdown)
* [Customers](https://www.paloaltonetworks.com/customers?ts=markdown)
* [Investor Relations](https://investors.paloaltonetworks.com/)
* [Location](https://www.paloaltonetworks.com/about-us/locations?ts=markdown)
* [Newsroom](https://www.paloaltonetworks.com/company/newsroom?ts=markdown)

## Popular Links

* [Blog](https://www.paloaltonetworks.com/blog/?ts=markdown)
* [Communities](https://www.paloaltonetworks.com/communities?ts=markdown)
* [Content Library](https://www.paloaltonetworks.com/resources?ts=markdown)
* [Cyberpedia](https://www.paloaltonetworks.com/cyberpedia?ts=markdown)
* [Event Center](https://events.paloaltonetworks.com/)
* [Manage Email Preferences](https://start.paloaltonetworks.com/preference-center)
* [Products A-Z](https://www.paloaltonetworks.com/products/products-a-z?ts=markdown)
* [Product Certifications](https://www.paloaltonetworks.com/legal-notices/trust-center/compliance?ts=markdown)
* [Report a Vulnerability](https://www.paloaltonetworks.com/security-disclosure?ts=markdown)
* [Sitemap](https://www.paloaltonetworks.com/sitemap?ts=markdown)
* [Tech Docs](https://docs.paloaltonetworks.com/)
* [Unit 42](https://unit42.paloaltonetworks.com/)
* [Do Not Sell or Share My Personal Information](https://panwedd.exterro.net/portal/dsar.htm?target=panwedd)
  ![PAN logo](https://www.paloaltonetworks.com/etc/clientlibs/clean/imgs/pan-logo-dark.svg)
* [Privacy](https://www.paloaltonetworks.com/legal-notices/privacy?ts=markdown)
* [Trust Center](https://www.paloaltonetworks.com/legal-notices/trust-center?ts=markdown)
* [Terms of Use](https://www.paloaltonetworks.com/legal-notices/terms-of-use?ts=markdown)
* [Documents](https://www.paloaltonetworks.com/legal?ts=markdown)

Copyright © 2026 Palo Alto Networks. All Rights Reserved

* [![Youtube](https://www.paloaltonetworks.com/etc/clientlibs/clean/imgs/social/youtube-black.svg)](https://www.youtube.com/user/paloaltonetworks)
* [![Podcast](https://www.paloaltonetworks.com/content/dam/pan/en_US/images/icons/podcast.svg)](https://www.paloaltonetworks.com/podcasts/threat-vector?ts=markdown)
* [![Facebook](https://www.paloaltonetworks.com/etc/clientlibs/clean/imgs/social/facebook-black.svg)](https://www.facebook.com/PaloAltoNetworks/)
* [![LinkedIn](https://www.paloaltonetworks.com/etc/clientlibs/clean/imgs/social/linkedin-black.svg)](https://www.linkedin.com/company/palo-alto-networks)
* [![Twitter](https://www.paloaltonetworks.com/etc/clientlibs/clean/imgs/social/twitter-x-black.svg)](https://twitter.com/PaloAltoNtwks)
* EN  
  Select your language