[![Logo](https://www.paloaltonetworks.com/wp-content/uploads/2021/07/PANW_Parent.png)](https://www.paloaltonetworks.com/) [![Unit42 Logo](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/unit42-logo-white.svg)](https://unit42.paloaltonetworks.com/) Menu * [Tools](https://unit42.paloaltonetworks.com/tools/) * [ATOMs](https://unit42.paloaltonetworks.com/atoms/) * [Security Consulting](https://www.paloaltonetworks.com/unit42) * [About Us](https://unit42.paloaltonetworks.com/about-unit-42/) * [**Under Attack?**](https://start.paloaltonetworks.com/contact-unit42.html) English * [English](https://unit42.paloaltonetworks.com/breaking-docker-via-runc-explaining-cve-2019-5736/) * [Japanese](https://unit42.paloaltonetworks.com/ja/breaking-docker-via-runc-explaining-cve-2019-5736/) * [Threat Research Center](https://unit42.paloaltonetworks.com "Threat Research") * [Threat Research](https://unit42.paloaltonetworks.com/category/threat-research/ "Threat Research") * [Cloud Cybersecurity Research](https://unit42.paloaltonetworks.com/category/cloud-cybersecurity-research/ "Cloud Cybersecurity Research") [Cloud Cybersecurity Research](https://unit42.paloaltonetworks.com/category/cloud-cybersecurity-research/) # Breaking out of Docker via runC -- Explaining CVE-2019-5736 ![Clock Icon](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-clock.svg) 11 min read * ![Profile Icon](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-profile-grey.svg) By: * [Yuval Avrahami](https://unit42.paloaltonetworks.com/author/yuval-avrahami/) * ![Published Icon](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-calendar-grey.svg) Published:February 21, 2019 * ![Tags Icon](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-category.svg) Categories: * [Cloud Cybersecurity Research](https://unit42.paloaltonetworks.com/category/cloud-cybersecurity-research/) * [Threat Research](https://unit42.paloaltonetworks.com/category/threat-research/) * [Vulnerabilities](https://unit42.paloaltonetworks.com/category/vulnerabilities/) * ![Tags Icon](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-tags-grey.svg) Tags: * [Container breakout](https://unit42.paloaltonetworks.com/tag/container-breakout/) * [Container escape](https://unit42.paloaltonetworks.com/tag/container-escape/) * [Containers](https://unit42.paloaltonetworks.com/tag/containers/) * [CVE-2019-5736](https://unit42.paloaltonetworks.com/tag/cve-2019-5736/) * [Docker](https://unit42.paloaltonetworks.com/tag/docker/) * [Exploit](https://unit42.paloaltonetworks.com/tag/exploit/) * [RunC](https://unit42.paloaltonetworks.com/tag/runc/) * [![Download Icon](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-download.svg)](https://unit42.paloaltonetworks.com/breaking-docker-via-runc-explaining-cve-2019-5736/?pdf=download&lg=en&_wpnonce=7052973960 "Click here to download") * [![Print Icon](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-print.svg)](https://unit42.paloaltonetworks.com/breaking-docker-via-runc-explaining-cve-2019-5736/?pdf=print&lg=en&_wpnonce=7052973960 "Click here to print") Share![Down arrow](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/down-arrow.svg) * ![Link Icon](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-share-link.svg) * [![Link Email](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-sms.svg)](mailto:?subject=Breaking%20out%20of%20Docker%20via%20runC%20–%20Explaining%20CVE-2019-5736&body=Check%20out%20this%20article%20https%3A%2F%2Funit42.paloaltonetworks.com%2Fbreaking-docker-via-runc-explaining-cve-2019-5736%2F "Share in email") * [![Facebook Icon](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-fb-share.svg)](https://www.facebook.com/sharer/sharer.php?u=https%3A%2F%2Funit42.paloaltonetworks.com%2Fbreaking-docker-via-runc-explaining-cve-2019-5736%2F "Share in Facebook") * [![LinkedIn Icon](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-linkedin-share.svg)](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Funit42.paloaltonetworks.com%2Fbreaking-docker-via-runc-explaining-cve-2019-5736%2F&title=Breaking%20out%20of%20Docker%20via%20runC%20–%20Explaining%20CVE-2019-5736 "Share in LinkedIn") * [![Twitter Icon](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-twitter-share.svg)](https://twitter.com/intent/tweet?url=https%3A%2F%2Funit42.paloaltonetworks.com%2Fbreaking-docker-via-runc-explaining-cve-2019-5736%2F&text=Breaking%20out%20of%20Docker%20via%20runC%20–%20Explaining%20CVE-2019-5736 "Share in Twitter") * [![Reddit Icon](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-reddit-share.svg)](https://www.paloaltonetworks.com//www.reddit.com/submit?url=https%3A%2F%2Funit42.paloaltonetworks.com%2Fbreaking-docker-via-runc-explaining-cve-2019-5736%2F&ts=markdown "Share in Reddit") * [![Mastodon Icon](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-mastodon-share.svg)](https://mastodon.social/share?text=Breaking%20out%20of%20Docker%20via%20runC%20–%20Explaining%20CVE-2019-5736%20https%3A%2F%2Funit42.paloaltonetworks.com%2Fbreaking-docker-via-runc-explaining-cve-2019-5736%2F "Share in Mastodon") Last week (2019-02-11) a new vulnerability in runC was [reported](https://www.openwall.com/lists/oss-security/2019/02/11/2) by its maintainers, originally found by Adam Iwaniuk and Borys Poplawski. Dubbed CVE-2019-5736, it affects Docker containers running in default settings and can be used by an attacker to gain root-level access on the host. Aleksa Sarai, one of runC's maintainers, found that the same fundamental flaw exists in LXC. As opposed to Docker though, only privileged LXC containers are vulnerable. Both [runC](https://github.com/opencontainers/runc/commit/6635b4f0c6af3810594d2770f662f34ddc15b40d) and [LXC](https://github.com/lxc/lxc/commit/6400238d08cdf1ca20d49bafb85f4e224348bf9d) were patched and new versions were released. The vulnerability gained a lot of traction and numerous technology sites and commercial companies addressed it in dedicated posts. Here at Twistlock, our CTO John Morello wrote an [excellent piece](https://www.twistlock.com/2019/02/11/how-to-mitigate-cve-2019-5736-in-runc-and-docker/) with all the relevant details and the mitigations offered by the Twistlock platform. Initially, the official exploit code wasn't to be released publicly until 2019-02-18, in order to prevent malicious parties from weaponizing it before users have had some time to update. In the following days though, several people decided to release their own exploit code. That led the runC team to eventually [release their exploit code](https://www.openwall.com/lists/oss-security/2019/02/13/3) earlier (2019-02-13) since -- as they put it -- "the cat was out of the bag". This post aims to be a comprehensive technical deep dive into the vulnerability and it's various exploitation methods. #### So What Is runC? RunC is a container runtime originally developed as part of Docker and later extracted out as a separate open source tool and library. As a "low level" container runtime, runC is mainly used by "high level" container runtimes (e.g. Docker) to spawn and run containers, although it can be used as a stand-alone tool. "High level" container runtimes like Docker will normally implement functionalities such as image creation and management and will use runC to handle tasks related to running containers -- creating a container, attaching a process to an existing container (docker exec) and so on. #### Procfs To understand the vulnerability, we need to go over some procfs basics. The proc filesystem is a virtual filesystem in Linux that presents information primarily about processes, typically mounted to /proc. It is virtual in a sense that it does not exist on disk. Instead, the kernel creates it in memory. It can be thought of as an interface to system data that the kernel exposes as a filesystem. Each process has its own directory in procfs, at /proc/\[pid\]: ![](https://unit42.paloaltonetworks.com/wp-content/uploads/2019/10/procfs1-1.jpg) As shown in the image above, /proc/self is a symbolic link to the directory of the currently running process (in this case pid 177). Each process's directory contains several files and directories with information on the process. For the vulnerability, the relevant ones are: * /proc/self/exe -- a symbolic link to the executable file the process is running, and ; * /proc/self/fd -- a directory containing the file descriptors open by the process. For example, by listing the files under /proc/self using ls /proc/self one can see that /proc/self/exe points to the 'ls' executable. ![](https://unit42.paloaltonetworks.com/wp-content/uploads/2019/10/procfs2.jpg) That makes sense as the one accessing /proc/self is the 'ls' process that our shell spawned. ## The Vulnerability Let's go over the vulnerability overview given by the runC team: The vulnerability allows a malicious container to (with minimal user interaction) overwrite the host runc binary and thus gain root-level code execution on the host. The level of user interaction is being able to run any command ... as root within a container in either of these contexts: * Creating a new container using an attacker-controlled image. * Attaching (docker exec) into an existing container which the attacker had previous write access to. Those two scenarios might seem different, but both require runC to spin up a new process in a container and are implemented similarly. In both cases, runC is tasked with running a user-defined binary in the container. In Docker, this binary is either the image's entry point when starting a new container, or docker exec's argument when attaching to an existing container. When this user binary is run, it must already be confined and restricted inside the container, or it can jeopardize the host. In order to accomplish that, runC creates a 'runC init' subprocess which places all needed restrictions on itself (such as entering or setting up namespaces) and effectively places itself in the container. Then, the runC init process, now in the container, [calls](https://github.com/opencontainers/runc/blob/751f18de2af90495e9c5665b95bfc7adf66ddd57/libcontainer/standard_init_linux.go#L206) the execve syscall to overwrite itself with the user requested binary. ![](https://unit42.paloaltonetworks.com/wp-content/uploads/2019/02/word-image-1.jpeg) This is the method used by runC both for creating new containers and for attaching a process to an existing container. ![](https://unit42.paloaltonetworks.com/wp-content/uploads/2019/10/runc_init1.jpg) The researchers who revealed the vulnerability discovered that an attacker can trick runC into executing itself by asking it to run /proc/self/exe, which is a symbolic link to the runC binary on the host. ![](https://unit42.paloaltonetworks.com/wp-content/uploads/2019/10/runc_init2.jpg) An attacker with root access in the container can then use /proc/\[runc-pid\]/exe as a reference to the runC binary on **the host** and overwrite it. Root access in the container is required to perform this attack as the runC binary is owned by root. The next time runC is executed, the attacker will achieve code execution on the host. Since runC is normally run as root (e.g. by the Docker daemon), the attacker will gain root access on the host. #### Why not runC init? The image above might mislead some to believe the vulnerability (i.e. tricking runC into executing itself) is redundant. That is, why can't an attacker simply overwrite /proc/\[**runc-init-pid** \]/exe instead? A patch for a similar runC vulnerability, [CVE-2016-9962](https://bugzilla.suse.com/show_bug.cgi?id=1012568), mitigates this kind of attack. CVE-2016-9962 revealed that the runC init process possessed open file descriptors from the host which could be used by an attacker in the container to traverse the host's filesystem and thus break out of the container. Part of the patch for this flaw was setting the runc init process as 'non-dumpable' before it entering the container. In the context of CVE-2019-5736, the 'non-dumpable' flag denies other processes from dereferencing /proc/\[pid\]/exe, and therefore mitigates overwriting the runC binary through /proc/\[runc-init-pid\]/exe [\[1\]](#footnote1). Calling execve drops this flag though, and hence the new runC process' /proc/\[runc-pid\]/exe is accessible. #### The Symlink Problem The vulnerability may appear to contradict the way symbolic links are implemented in Linux. Symbolic links simply hold the path to their target. For a runC process, /proc/self/exe should contain something like /usr/sbin/runc. When a symlink is accessed by a process, the kernel uses the path present in the link to find the target under the root of the accessing process. That begs the question -- **when a process in the container opens the symbolic link to the runC binary, why doesn't the kernel searches for the runC path inside the container root?** The answer is that /proc/\[pid\]/exe does not follow the normal semantics for symbolic links. Technically this might count as a violation of [POSIX](https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_381), but as I mentioned earlier procfs is a special filesystem. When a process opens /proc/\[pid\]/exe, there is none of the normal procedure of reading and following the contents of a symlink. Instead, the kernel just gives you access to the open file entry directly. ## Exploitation Soon after the vulnerability was reported, when no POCs were publicly released yet, I attempted to develop my own POC based on the detailed description of the vulnerability given in the [LXC patch](https://github.com/lxc/lxc/commit/6400238d08cdf1ca20d49bafb85f4e224348bf9d) addressing it. You can find the complete POC code [here](https://github.com/twistlock/RunC-CVE-2019-5736/tree/master/exec_POC). Let's break down LXC's description of the vulnerability: when runC attaches to a container the attacker can trick it into executing itself. This could be done by replacing the target binary inside the container with a custom binary pointing back at the runC binary itself. As an example, if the target binary was /bin/bash, this could be replaced with an executable script specifying the interpreter path #!/proc/self/exe The '#!' syntax is called shebang and is used in scripts to specify an interpreter. When the Linux loader encounters the shebang, it runs the interpreter instead of the executable. As seen in the [video](https://asciinema.org/a/228389), the program finally executed by the loader is: interpreter \[optional-arg\] executable-path When the user runs something like docker exec container-name /bin/bash, the loader will recognize the shebang in the modified bash and execute the interpreter we specified -- /proc/self/exe, which is a symlink to the runC binary. We can proceed to overwrite the runC binary from a separate process in the container through /proc/\[runc-pid\]/exe. ![](https://unit42.paloaltonetworks.com/wp-content/uploads/2019/10/replace-sh-new.jpg) The attacker can then proceed to write to the target of /proc/self/exe to try and overwrite the runC binary on the host. However in general, this will not succeed as the kernel will not permit it to be overwritten whilst runC is executing. Basically, we cannot overwrite the runC binary while a process is running it. On the other hand, if the runC process exits, /proc/\[runc-pid\]/exe will vanish and we will lose the reference to the runC binary. To overcome this, we open /proc/\[runc-pid\]/exe for reading in our process, which creates a file descriptor at /proc/\[our-pid\]/fd/3. We then wait for the runC process to exit, and proceed to open /proc/\[our-pid\]/fd/3 for writing, and overwrite runC. Here is the code for overwrite\_runc, shortened for brevity: ![](https://unit42.paloaltonetworks.com/wp-content/uploads/2019/10/overwrite_runc-c-new.jpg) Let's see some action! The exploit output shows the steps taken to overwrite runC. You can see that the runC process is running as pid 20054. The video can also be seen [here](https://asciinema.org/a/228632). This method has one setback though -- it requires an additional process to run the attacker code. Since containers are started with only one process (i.e. the Docker's image entry point), this approach couldn't be used to create a malicious image that will compromise the host when run. Some other POCs you might have seen that implement a similar approach are [Frichetten's](https://github.com/Frichetten/CVE-2019-5736-PoC/blob/master/main.go) and [feexd's](https://github.com/feexd/pocs/tree/master/CVE-2019-5736). ## Shared Libraries Approach A different exploitation method is used in the official POC released by runC's maintainers and is superior to POCs similar to mine since it can be implemented to compromise the host through two separate methods: 1. When a user execs a command into an existing attacker controlled container 2. When a user runs a malicious image We'll now look into building a malicious image since the previous POC already demonstrated the first scenario. The POC I wrote for this method is heavily based on [q3k's POC](https://github.com/q3k/cve-2019-5736-poc), which, to the best of my knowledge, was the first published malicious image POC. You can view the full POC code [here](https://github.com/twistlock/RunC-CVE-2019-5736/tree/master/malicious_image_POC). Let's go over the Dockerfile used to build the malicious image. First, the entry point of the image is set to /proc/self/exe in order to trick runC into executing itself when the image is run. # Create a symbolic link to /proc/self/exe and set it as the image entrypoint RUN set -e -x ;\\ ln -s /proc/self/exe /entrypoint ENTRYPOINT \[ "/entrypoint" \] |---------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------| | 1 2 3 4 | # Create a symbolic link to /proc/self/exe and set it as the image entrypoint RUN set -e -x ;\\ ln -s /proc/self/exe /entrypoint ENTRYPOINT \[ "/entrypoint" \] | RunC is [dynamically linked](https://www.ibm.com/developerworks/library/l-dynamic-libraries/index.html) to several shared libraries at run time, which can be listed using the ldd command. ![](https://unit42.paloaltonetworks.com/wp-content/uploads/2019/10/runc-shared-libraries.jpg) When the runC process is executed in the container, those libraries are loaded into the runC process by the dynamic linker. It is possible to substitute one of those libraries with a malicious version, that will overwrite the runC binary upon being loaded into the runC process. Our Dockerfile builds a malicious version of the libseccomp library: # Append the run\_at\_link function to the libseccomp-2.3.1/src/api.c file and build libseccomp ADD run\_at\_link.c /root/run\_at\_link.c RUN set -e -x ;\\ cd /root/libseccomp-2.3.1 ;\\ cat /root/run\_at\_link.c \>\> src/api.c ;\\ DEB\_BUILD\_OPTIONS=nocheck dpkg-buildpackage -b -uc -us ;\\ dpkg -i /root/\*.deb |-------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | 1 2 3 4 5 6 7 8 9 | # Append the run\_at\_link function to the libseccomp-2.3.1/src/api.c file and build libseccomp ADD run\_at\_link.c /root/run\_at\_link.c RUN set -e -x ;\\ cd /root/libseccomp-2.3.1 ;\\ cat /root/run\_at\_link.c \>\> src/api.c ;\\ DEB\_BUILD\_OPTIONS=nocheck dpkg-buildpackage -b -uc -us ;\\ dpkg -i /root/\*.deb | The Dockerfile appends the content of run\_at\_link.c to one of libsecomp's source files. Subsequently, the malicious libsecomp is built. ![](https://www.twistlock.com/wp-content/uploads/2019/02/run_at_linc-c-new.png) The constructor attribute (a GCC-specific syntax) indicates that the run\_at\_link function is to be executed as an initialization function [\[2\]](#footnote2) for libseccomp after the dynamic linker loads the library into the runC process. Since run\_at\_link will be executed by the runC process, it can access the runC binary at /proc/self/exe. The runC process must exit for the runC binary to be writable though. To enforce the exit, run\_at\_link calls the execve syscall to execute overwrite\_runc. Since execve doesn't affect the file descriptors open by the process, the same file descriptor trick from the previous POC can be used: 1. The runC process loads the libseccomp library and transfers execution to the run\_at\_link function. 2. run\_at\_link opens the runC binary for reading through /proc/self/exe. This creates a file descriptor at /proc/self/fd/${runc\_fd\_read}. 3. run\_at\_link calls execve to execute overwrite\_runc. 4. The process is no longer running the runC binary, overwrite\_runc opens /proc/self/fd/runc\_fd\_read for writing and overwrites the runC binary. For the following [video](https://asciinema.org/a/228625), I built a malicious image that overwrites the runC binary with a simple script that spawns a reverse shell at port 2345. The docker run command executes runC twice. Once to create and run the container, which executes the POC to overwrite runC, and then again to stop the container using runc delete [\[3\]](#footnote3). The second time runC is executed, it is already overwritten, and hence the reverse shell script is executed instead. ## The Fix RunC and LXC were both patched using the same approach, which is described clearly in the LXC patch commit: To prevent this attack, LXC has been patched to create a temporary copy of the calling binary itself when it starts or attaches to containers. To do this LXC creates an anonymous, in-memory file using the memfd\_create() system call and copies itself into the temporary in-memory file, which is then sealed to prevent further modifications. LXC then executes this sealed, in-memory file instead of the original on-disk binary. Any compromising write operations from a privileged container to the host LXC binary will then write to the temporary in-memory binary and not to the host binary on-disk, preserving the integrity of the host LXC binary. Also as the temporary, in-memory LXC binary is sealed, writes to this will also fail. RunC has been patched using the same method. It re-executes from a temporary copy of itself when it starts or attaches to containers. Consequently, /proc/\[runc-pid\]/exe now points to the temporary file, and the runC binary can't be reached from within the container. The temporary file is also [sealed](https://manpages.courier-mta.org/htmlman2/memfd_create.2.html) to block writing to it, although overwriting it shouldn't compromise the host. This patch introduced some issues though. The temporary runC copy is created in-memory after the runc init process has already applied the container's cgroup [memory constraints](https://docs.docker.com/config/containers/resource_constraints/) on itself. For containers running with a relatively low memory limit (e.g 10Mb), this can cause processes in the container to be oom-killed (Out Of Memory killed) by the kernel when the runC init process attaches to the container. If you are interested, an [issue](https://github.com/opencontainers/runc/issues/1980) regarding this complication was created and contains a discussion about alternative fixes that might not introduce the same problem. ## CVE-2019-5736 and Privileged Containers As a general rule of thumb, privileged containers (of a given container runtime) are less secure then unprivileged containers (of the same runtime). Earlier I stated that the vulnerability affects all Docker containers but only LXC's privileged containers. So why are Docker unprivileged containers vulnerable while LXC unprivileged containers aren't? Well, it's because LXC and Docker define privileged containers differently. In fact, Docker unprivileged containers are considered privileged according to [LXC philosophy](https://linuxcontainers.org/lxc/security/#privileged-containers). Privileged containers are defined as any container where the container uid 0 is mapped to the host's uid 0. The main difference is that LXC runs unprivileged containers in a separate user namespace by default, while Docker doesn't. User namespaces are a feature of Linux that can be used to separate the container root from the host root. The root inside the container, as well as all other users, are mapped to unprivileged users on the host. In other words, a process can have root access for operations inside the container but is unprivileged for operations outside it. If you would like a more in-depth explanation, I recommend LWN's [namespace series](https://lwn.net/Articles/531114/) ![](https://unit42.paloaltonetworks.com/wp-content/uploads/2019/10/unprivileged-builds-userns1.svg) Image from [*kinvolk*](https://kinvolk.io/blog/2018/04/towards-unprivileged-container-builds/#uid-mappings). So how does running the container in a user namespace mitigate this vulnerability? The attacker is root inside the container but is mapped to an unprivileged user on the host. Therefore, when the attacker tries to open the host's runC binary for writing, he is denied by the kernel. You might wonder why Docker doesn't run containers in a separate user namespace by default. It's because user namespaces do have some drawbacks in the context of containers, which are a bit out of the scope of this post. If you are interested, [Docker](https://docs.docker.com/engine/security/userns-remap/#user-namespace-known-limitations) and [rkt](https://coreos.com/rkt/docs/latest/devel/user-namespaces.html) (another container runtime) both list the limitations of running containers in user namespaces. ## Ending Note I hope this post gave you a bit of insight into the different aspects of this vulnerability. If you are using either runC, Docker, or LXC, don't forget to update to the patched version. Feel free to reach out with any questions you may have through email or [@TwistlockLabs](https://twitter.com/TwistlockLabs). *** ** * ** *** [\[1\]](#back1) As a side note, privileged Docker containers (before the new patch) could use the /proc/pid/exe of the runc init process to overwrite the runC binary. To be exact, the specific privileges required are SYS\_CAP\_PTRACE and disabling AppArmor. [\[2\]](#back2) For those familiar with Windows DLLs, it resembles DllMain. [\[3\]](#back3) The container is stopped after overwrite\_runc exits, since overwrite\_runc was executed as the init process (PID 1) of the container. Back to top ### Tags * [Container breakout](https://unit42.paloaltonetworks.com/tag/container-breakout/ "container breakout") * [Container escape](https://unit42.paloaltonetworks.com/tag/container-escape/ "container escape") * [Containers](https://unit42.paloaltonetworks.com/tag/containers/ "Containers") * [CVE-2019-5736](https://unit42.paloaltonetworks.com/tag/cve-2019-5736/ "CVE-2019-5736") * [Docker](https://unit42.paloaltonetworks.com/tag/docker/ "Docker") * [Exploit](https://unit42.paloaltonetworks.com/tag/exploit/ "exploit") * [RunC](https://unit42.paloaltonetworks.com/tag/runc/ "runC") [Threat Research Center](https://unit42.paloaltonetworks.com "Threat Research") [Next: Shifting in the Wind: WINDSHIFT Attacks Target Middle Eastern Governments](https://unit42.paloaltonetworks.com/shifting-in-the-wind-windshift-attacks-target-middle-eastern-governments/ "Shifting in the Wind: WINDSHIFT Attacks Target Middle Eastern Governments") ### Table of Contents * ### Related Articles * [Copy Fail: What You Need to Know About the Most Severe Linux Threat in Years](https://unit42.paloaltonetworks.com/cve-2026-31431-copy-fail/ "article - table of contents") * [Understanding Current Threats to Kubernetes Environments](https://unit42.paloaltonetworks.com/modern-kubernetes-threats/ "article - table of contents") * [Cloud Threats on the Rise: Alert Trends Show Intensified Attacker Focus on IAM, Exfiltration](https://unit42.paloaltonetworks.com/2025-cloud-security-alert-trends/ "article - table of contents") ## Related Resources ![Pictorial representation of a group of people interacting with a dynamic 3D holographic display of colorful, undulating data waves on a table.](https://unit42.paloaltonetworks.com/wp-content/uploads/2025/09/11_Myth-Busting_Overview_1920x900-786x368.jpg) [![category icon](https://unit42.paloaltonetworks.com/wp-content/uploads/2025/08/Insights-icon-white.svg)Insights](https://unit42.paloaltonetworks.com/category/insights/) August 4, 2026 [#### The Frontier AI Vulnerability Burst: Industrializing Autonomous Zero-Day Discovery in Open-Source Software](https://unit42.paloaltonetworks.com/frontier-ai-vulnerability-burst/) * [AI](https://unit42.paloaltonetworks.com/tag/ai/ "AI") * [Frontier AI](https://unit42.paloaltonetworks.com/tag/frontier-ai/ "Frontier AI") * [Vulnerability Exploitation](https://unit42.paloaltonetworks.com/tag/vulnerability-exploitation/ "Vulnerability Exploitation") [Read now ![Right arrow](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-right-arrow-withtail.svg)](https://unit42.paloaltonetworks.com/frontier-ai-vulnerability-burst/ "The Frontier AI Vulnerability Burst: Industrializing Autonomous Zero-Day Discovery in Open-Source Software") ![Pictorial representation of AI-enabled autonomous cyberattacks. A digital illustration depicting abstract, interconnected data streams in vibrant colors on a dark blue background](https://unit42.paloaltonetworks.com/wp-content/uploads/2026/07/AdobeStock_992950050-3-782x440.jpeg) [![category icon](https://unit42.paloaltonetworks.com/wp-content/uploads/2024/06/icon-threat-research.svg)Threat Research](https://unit42.paloaltonetworks.com/category/threat-research/) July 30, 2026 [#### Chinese-Speaking Threat Actor Harnesses AI Models for Autonomous Cyberattacks](https://unit42.paloaltonetworks.com/autonomous-ai-cyber-attack-campaign/) * [ChatGPT](https://unit42.paloaltonetworks.com/tag/chatgpt/ "ChatGPT") * [Claude code](https://unit42.paloaltonetworks.com/tag/claude-code/ "Claude code") * [CVEs](https://unit42.paloaltonetworks.com/tag/cves/ "CVEs") [Read now ![Right arrow](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-right-arrow-withtail.svg)](https://unit42.paloaltonetworks.com/autonomous-ai-cyber-attack-campaign/ "Chinese-Speaking Threat Actor Harnesses AI Models for Autonomous Cyberattacks") ![Pictorial representation of three zero-day vulnerabilities in Siemens ROX II OT switches. Digital illustration of a global network featuring interconnected lines and nodes over a map of the world, highlighted with neon lights and digital elements.](https://unit42.paloaltonetworks.com/wp-content/uploads/2026/07/03_Vulnerabilities_1920x900-786x368.jpg) [![category icon](https://unit42.paloaltonetworks.com/wp-content/uploads/2024/06/icon-threat-research.svg)Threat Research](https://unit42.paloaltonetworks.com/category/threat-research/) July 17, 2026 [#### Three Steps to the Terminal: A Siemens ROX II Zero-Day Trilogy](https://unit42.paloaltonetworks.com/siemens-rox-ii-zero-day-vulnerabilities/) * [Command injection](https://unit42.paloaltonetworks.com/tag/command-injection/ "Command injection") * [CVE-2025-40947](https://unit42.paloaltonetworks.com/tag/cve-2025-40947/ "CVE-2025-40947") * [CVE-2025-40948](https://unit42.paloaltonetworks.com/tag/cve-2025-40948/ "CVE-2025-40948") [Read now ![Right arrow](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-right-arrow-withtail.svg)](https://unit42.paloaltonetworks.com/siemens-rox-ii-zero-day-vulnerabilities/ "Three Steps to the Terminal: A Siemens ROX II Zero-Day Trilogy") ![Pictorial representation of bucket hijacking technique for cloud data exfiltration. Digital illustration of Europe map highlighting network connections and nodes, depicted as glowing points and lines on a dark blue background, emphasizing major cities and connectivity across the continent.](https://unit42.paloaltonetworks.com/wp-content/uploads/2026/06/09_Cloud_cybersecurity_research_Overview_1920x900-786x368.jpg) [![category icon](https://unit42.paloaltonetworks.com/wp-content/uploads/2024/06/icon-threat-research.svg)Threat Research](https://unit42.paloaltonetworks.com/category/threat-research/) June 22, 2026 [#### The Global Namespace Risk: Universal Bucket Hijacking Technique for Cloud Data Exfiltration](https://unit42.paloaltonetworks.com/cloud-bucket-hijacking-risks/) * [AWS](https://unit42.paloaltonetworks.com/tag/aws/ "AWS") * [Bucket hijacking](https://unit42.paloaltonetworks.com/tag/bucket-hijacking/ "bucket hijacking") * [Cloud data exfiltration](https://unit42.paloaltonetworks.com/tag/cloud-data-exfiltration/ "cloud data exfiltration") [Read now ![Right arrow](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-right-arrow-withtail.svg)](https://unit42.paloaltonetworks.com/cloud-bucket-hijacking-risks/ "The Global Namespace Risk: Universal Bucket Hijacking Technique for Cloud Data Exfiltration") ![Pictorial representation of Vertex AI model uploads. Close-up view of a digital wall displaying various glowing icons, representing a high-tech network interface.](https://unit42.paloaltonetworks.com/wp-content/uploads/2026/06/AdobeStock_1270203474-1-786x354.png) [![category icon](https://unit42.paloaltonetworks.com/wp-content/uploads/2024/06/icon-threat-research.svg)Threat Research](https://unit42.paloaltonetworks.com/category/threat-research/) June 16, 2026 [#### Pickle in the Middle -- Hijacking Vertex AI Model Uploads for Cross-Tenant RCE](https://unit42.paloaltonetworks.com/hijacking-vertex-ai-model/) * [Bucket squatting](https://unit42.paloaltonetworks.com/tag/bucket-squatting/ "bucket squatting") * [Google Cloud](https://unit42.paloaltonetworks.com/tag/google-cloud/ "Google Cloud") * [Joblib](https://unit42.paloaltonetworks.com/tag/joblib/ "joblib") [Read now ![Right arrow](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-right-arrow-withtail.svg)](https://unit42.paloaltonetworks.com/hijacking-vertex-ai-model/ "Pickle in the Middle – Hijacking Vertex AI Model Uploads for Cross-Tenant RCE") ![Pictorial representation of Cloud Logging services for defense evasion. A vibrant digital illustration depicting a glowing, neon blue cloud symbol positioned over a circuit board landscape. The cloud symbolizes cloud computing technology, and the landscape features intricate electronic circuits with glowing lines and nodes, suggesting high-tech data transfer and connectivity.](https://unit42.paloaltonetworks.com/wp-content/uploads/2026/06/11_Cloud_cybersecurity_research_Overview_1920x900-786x368.jpg) [![category icon](https://unit42.paloaltonetworks.com/wp-content/uploads/2024/06/icon-threat-research.svg)Threat Research](https://unit42.paloaltonetworks.com/category/threat-research/) June 9, 2026 [#### Blinding the Watchmen: Abusing Cloud Logging Services for Defense Evasion and Visibility](https://unit42.paloaltonetworks.com/cloud-logging-defense-evasion/) * [AWS CloudTrail](https://unit42.paloaltonetworks.com/tag/aws-cloudtrail/ "AWS CloudTrail") * [Cloud logging](https://unit42.paloaltonetworks.com/tag/cloud-logging/ "cloud logging") * [Defense evasion](https://unit42.paloaltonetworks.com/tag/defense-evasion/ "defense evasion") [Read now ![Right arrow](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-right-arrow-withtail.svg)](https://unit42.paloaltonetworks.com/cloud-logging-defense-evasion/ "Blinding the Watchmen: Abusing Cloud Logging Services for Defense Evasion and Visibility") ![Pictorial representation of PAN-OS CVE-2026-0257. A vibrant city skyline at night, with tall skyscrapers and glowing digital beams extending into the sky, suggesting advanced technology and connectivity.](https://unit42.paloaltonetworks.com/wp-content/uploads/2026/06/07_Vulnerabilities_1920x900-786x368.jpg) [![category icon](https://unit42.paloaltonetworks.com/wp-content/uploads/2024/07/top-threats.svg)High Profile Threats](https://unit42.paloaltonetworks.com/category/top-cyberthreats/) June 9, 2026 [#### Threat Brief: Active Exploitation of PAN-OS CVE-2026-0257](https://unit42.paloaltonetworks.com/active-exploitation-of-pan-os-cve-2026-0257/) * [CVE-2026-0257](https://unit42.paloaltonetworks.com/tag/cve-2026-0257/ "CVE-2026-0257") * [Vulnerability](https://unit42.paloaltonetworks.com/tag/vulnerability/ "vulnerability") [Read now ![Right arrow](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-right-arrow-withtail.svg)](https://unit42.paloaltonetworks.com/active-exploitation-of-pan-os-cve-2026-0257/ "Threat Brief: Active Exploitation of PAN-OS CVE-2026-0257") ![Pictorial representation of ROADtools framework in the cloud. An Asian man wearing glasses sits in front of a computer screen. Reflecting in the glasses are lines indicating analysis. Bright blue city lights illuminate the rest of the image.](https://unit42.paloaltonetworks.com/wp-content/uploads/2026/05/10_Cloud_cybersecurity_research_Overview_1920x900-1-786x368.jpg) [![category icon](https://unit42.paloaltonetworks.com/wp-content/uploads/2024/06/icon-threat-research.svg)Threat Research](https://unit42.paloaltonetworks.com/category/threat-research/) May 22, 2026 [#### Paved With Intent: ROADtools and Nation-State Tactics in the Cloud](https://unit42.paloaltonetworks.com/roadtools-cloud-attacks/) * [Curious Serpens](https://unit42.paloaltonetworks.com/tag/curious-serpens/ "Curious Serpens") * [Entra ID](https://unit42.paloaltonetworks.com/tag/entra-id/ "Entra ID") * [Microsoft Azure](https://unit42.paloaltonetworks.com/tag/microsoft-azure/ "Microsoft Azure") [Read now ![Right arrow](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-right-arrow-withtail.svg)](https://unit42.paloaltonetworks.com/roadtools-cloud-attacks/ "Paved With Intent: ROADtools and Nation-State Tactics in the Cloud") ![Pictorial representation of CVE-2026-30300. Digital illustration of a map of North America with interconnected glowing lines and dots symbolizing network connections across the continent.](https://unit42.paloaltonetworks.com/wp-content/uploads/2026/05/06_Vulnerabilities_1920x900-3-1-786x368.jpg) [![category icon](https://unit42.paloaltonetworks.com/wp-content/uploads/2024/07/top-threats.svg)High Profile Threats](https://unit42.paloaltonetworks.com/category/top-cyberthreats/) May 6, 2026 [#### Threat Brief: Exploitation of PAN-OS Captive Portal Zero-Day for Unauthenticated Remote Code Execution](https://unit42.paloaltonetworks.com/captive-portal-zero-day/) * [CVE-2026-0300](https://unit42.paloaltonetworks.com/tag/cve-2026-0300/ "CVE-2026-0300") * [EarthWorm](https://unit42.paloaltonetworks.com/tag/earthworm/ "EarthWorm") * [PAN-OS](https://unit42.paloaltonetworks.com/tag/pan-os/ "PAN-OS") [Read now ![Right arrow](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-right-arrow-withtail.svg)](https://unit42.paloaltonetworks.com/captive-portal-zero-day/ "Threat Brief: Exploitation of PAN-OS Captive Portal Zero-Day for Unauthenticated Remote Code Execution") ![Pictorial representation of a severe Linux vulnerability. Close-up of a woman wearing glasses and focusing intently on a computer screen.](https://unit42.paloaltonetworks.com/wp-content/uploads/2026/05/05_Vulnerabilities_1920x900-2-1-786x368.jpg) [![category icon](https://unit42.paloaltonetworks.com/wp-content/uploads/2024/07/top-threats.svg)High Profile Threats](https://unit42.paloaltonetworks.com/category/top-cyberthreats/) May 5, 2026 [#### Copy Fail: What You Need to Know About the Most Severe Linux Threat in Years](https://unit42.paloaltonetworks.com/cve-2026-31431-copy-fail/) * [Containers](https://unit42.paloaltonetworks.com/tag/containers/ "Containers") * [CVE-2026-31431](https://unit42.paloaltonetworks.com/tag/cve-2026-31431/ "CVE-2026-31431") * [Kubernetes](https://unit42.paloaltonetworks.com/tag/kubernetes/ "Kubernetes") [Read now ![Right arrow](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-right-arrow-withtail.svg)](https://unit42.paloaltonetworks.com/cve-2026-31431-copy-fail/ "Copy Fail: What You Need to Know About the Most Severe Linux Threat in Years") * ![Slider arrow](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/slider-arrow-left.svg) * ![Slider arrow](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/slider-arrow-left.svg) ![Close button](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/close-modal.svg) ![Enlarged Image]() ![Newsletter](https://unit42.paloaltonetworks.com/wp-content/uploads/2026/03/unit42-footer-subscribe-desktop.png) ![UNIT 42 Small Logo](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/palo-alto-logo-small.svg) Get updates from Unit 42 ## Peace of mind comes from staying ahead of threats. Subscribe today. Your Email Subscribe for email updates to all Unit 42 threat research. By submitting this form, you agree to our [Terms of Use](https://www.paloaltonetworks.com/legal-notices/terms-of-use "Terms of Use") and acknowledge our [Privacy Statement.](https://www.paloaltonetworks.com/legal-notices/privacy "Privacy Statement") 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. Invalid captcha! Subscribe ![Right Arrow](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/right-arrow.svg) ![loader](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-loader.svg) {#footer} Products and Services * [AI-Powered Network Security Platform](https://www.paloaltonetworks.com/network-security) * [Secure AI by Design](https://www.paloaltonetworks.com/ai-security) * [Prisma AIRS](https://www.paloaltonetworks.com/ai-security/prisma-airs) * [AI Access Security](https://www.paloaltonetworks.com/sase/ai-access-security) * [Cloud Delivered Security Services](https://www.paloaltonetworks.com/network-security/security-subscriptions) * [Advanced Threat Prevention](https://www.paloaltonetworks.com/network-security/advanced-threat-prevention) * [Advanced URL Filtering](https://www.paloaltonetworks.com/network-security/advanced-url-filtering) * [Advanced WildFire](https://www.paloaltonetworks.com/network-security/advanced-wildfire) * [Advanced DNS Security](https://www.paloaltonetworks.com/network-security/advanced-dns-security) * [Enterprise Data Loss Prevention](https://www.paloaltonetworks.com/sase/enterprise-data-loss-prevention) * [Enterprise IoT Security](https://www.paloaltonetworks.com/network-security/enterprise-device-security) * [Medical IoT Security](https://www.paloaltonetworks.com/network-security/medical-device-security) * [Industrial OT Security](https://www.paloaltonetworks.com/network-security/ot-security-solution) * [SaaS Security](https://www.paloaltonetworks.com/sase/saas-security) * [Next-Generation Firewalls](https://www.paloaltonetworks.com/network-security/next-generation-firewall) * [Hardware Firewalls](https://www.paloaltonetworks.com/network-security/hardware-firewall-innovations) * [Software Firewalls](https://www.paloaltonetworks.com/network-security/software-firewalls) * [Strata Cloud Manager](https://www.paloaltonetworks.com/network-security/strata-cloud-manager) * [SD-WAN for NGFW](https://www.paloaltonetworks.com/network-security/sd-wan-subscription) * [PAN-OS](https://www.paloaltonetworks.com/network-security/pan-os) * [Panorama](https://www.paloaltonetworks.com/network-security/panorama) * [Secure Access Service Edge](https://www.paloaltonetworks.com/sase) * [Prisma SASE](https://www.paloaltonetworks.com/sase) * [Application Acceleration](https://www.paloaltonetworks.com/sase/app-acceleration) * [Autonomous Digital Experience Management](https://www.paloaltonetworks.com/sase/adem) * [Enterprise DLP](https://www.paloaltonetworks.com/sase/enterprise-data-loss-prevention) * [Prisma Access](https://www.paloaltonetworks.com/sase/access) * [Prisma Browser](https://www.paloaltonetworks.com/sase/prisma-browser) * [Prisma SD-WAN](https://www.paloaltonetworks.com/sase/sd-wan) * [Remote Browser Isolation](https://www.paloaltonetworks.com/sase/remote-browser-isolation) * [SaaS Security](https://www.paloaltonetworks.com/sase/saas-security) * [AI-Driven Security Operations Platform](https://www.paloaltonetworks.com/cortex) * [Cloud Security](https://www.paloaltonetworks.com/cortex/cloud) * [Cortex Cloud](https://www.paloaltonetworks.com/cortex/cloud) * [Application Security](https://www.paloaltonetworks.com/cortex/cloud/application-security) * [Cloud Posture Security](https://www.paloaltonetworks.com/cortex/cloud/cloud-posture-security) * [Cloud Runtime Security](https://www.paloaltonetworks.com/cortex/cloud/runtime-security) * [Prisma Cloud](https://www.paloaltonetworks.com/prisma/cloud) * [AI-Driven SOC](https://www.paloaltonetworks.com/cortex) * [Cortex XSIAM](https://www.paloaltonetworks.com/cortex/cortex-xsiam) * [Cortex XDR](https://www.paloaltonetworks.com/cortex/cortex-xdr) * [Cortex XSOAR](https://www.paloaltonetworks.com/cortex/cortex-xsoar) * [Cortex Xpanse](https://www.paloaltonetworks.com/cortex/cortex-xpanse) * [Unit 42 Managed Detection \& Response](https://www.paloaltonetworks.com/cortex/managed-detection-and-response) * [Managed XSIAM](https://www.paloaltonetworks.com/cortex/managed-xsiam) * [Next-Generation Identity Security](https://www.paloaltonetworks.com/idira) * [Privileged Access Management](https://www.paloaltonetworks.com/idira/human/privileged-access-management) * [Identity and Access Management](https://www.paloaltonetworks.com/idira/human/identity-and-access-management) * [Endpoint Privilege Manager](https://www.paloaltonetworks.com/idira/human/endpoint-privilege-manager) * [Identity Governance](https://www.paloaltonetworks.com/idira/human/identity-governance) * [Workforce Password Management](https://www.paloaltonetworks.com/idira/human/workforce-password-management) * [Agentic Identities](https://www.paloaltonetworks.com/idira/agentic) * [Secrets Management](https://www.paloaltonetworks.com/idira/machine/secrets-management) * [Unified Secrets Governance](https://www.paloaltonetworks.com/idira/machine/unified-secrets-governance) * [Application Credentials Delivery](https://www.paloaltonetworks.com/idira/machine/application-credentials-delivery) * [Vendor Privileged Access](https://www.paloaltonetworks.com/idira/human/vendor-privileged-access) * [Threat Intel and Incident Response Services](https://www.paloaltonetworks.com/unit42) * [Proactive Assessments](https://www.paloaltonetworks.com/unit42/assess) * [Incident Response](https://www.paloaltonetworks.com/unit42/respond) * [Transform Your Security Strategy](https://www.paloaltonetworks.com/unit42/transform) * [Discover Threat Intelligence](https://www.paloaltonetworks.com/unit42/threat-intelligence-partners) Company * [About Us](https://www.paloaltonetworks.com/about-us) * [Careers](https://jobs.paloaltonetworks.com/en/) * [Contact Us](https://www.paloaltonetworks.com/company/contact-sales) * [Corporate Responsibility](https://www.paloaltonetworks.com/about-us/corporate-responsibility) * [Customers](https://www.paloaltonetworks.com/customers) * [Investor Relations](https://investors.paloaltonetworks.com/) * [Location](https://www.paloaltonetworks.com/about-us/locations) * [Newsroom](https://www.paloaltonetworks.com/company/newsroom) Popular Links * [Blog](https://www.paloaltonetworks.com/blog/) * [Communities](https://www.paloaltonetworks.com/communities) * [Content Library](https://www.paloaltonetworks.com/resources) * [Cyberpedia](https://www.paloaltonetworks.com/cyberpedia) * [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) * [Product Certifications](https://www.paloaltonetworks.com/legal-notices/trust-center/certifications) * [Report a Vulnerability](https://www.paloaltonetworks.com/security-disclosure) * [Sitemap](https://www.paloaltonetworks.com/sitemap) * [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) ![Palo Alto Networks Logo](https://www.paloaltonetworks.com/etc/clientlibs/clean/imgs/pan-logo-dark.svg) * [Privacy](https://www.paloaltonetworks.com/legal-notices/privacy) * [Trust Center](https://www.paloaltonetworks.com/legal-notices/trust-center) * [Terms of Use](https://www.paloaltonetworks.com/legal-notices/terms-of-use) * [Documents](https://www.paloaltonetworks.com/legal) 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) * [![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 ![Play](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/player-play-icon.svg) ![Pause](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/player-pause-icon1.svg) ![Minimize](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-minimize.svg) ![Close button](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/close-modal.svg) ### Default Heading Read the article ![Right Arrow](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/right-arrow.svg) Seekbar ![Play](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/player-play-icon.svg) ![Pause](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/player-pause-icon1.svg) ![Volume](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-volume.svg) Volume ![Minimize](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-minimize.svg)