CVE-2019-5736
published 2019-02-11CVE-2019-5736: runc through 1.0-rc6, as used in Docker before 18.09.2 and other products, allows attackers to overwrite the host runc binary (and consequently obtain host…
PriorityP185high8.6CVSS 3.1
AVLACLPRNUIRSCCHIHAH
ITWEXPLOITVulnCheck KEV
Exploited in the wild
EPSS
98.57%
99.9th percentile
runc through 1.0-rc6, as used in Docker before 18.09.2 and other products, allows attackers to overwrite the host runc binary (and consequently obtain host root access) by leveraging the ability to execute a command as root within one of these types of containers: (1) a new container with an attacker-controlled image, or (2) an existing container, to which the attacker previously had write access, that can be attached with docker exec. This occurs because of file-descriptor mishandling, related to /proc/self/exe.
Affected
58 ranges· showing 25
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| apache | mesos | >= 1.4.0 < 1.4.3 | 1.4.3 |
| apache | mesos | >= 1.5.0 < 1.5.3 | 1.5.3 |
| apache | mesos | >= 1.6.0 < 1.6.2 | 1.6.2 |
| apache | mesos | >= 1.7.0 < 1.7.2 | 1.7.2 |
| canonical | ubuntu_linux | — | — |
| canonical | ubuntu_linux | — | — |
| canonical | ubuntu_linux | — | — |
| canonical | ubuntu_linux | — | — |
| d2iq | dc_os | < 1.10.10 | 1.10.10 |
| d2iq | dc_os | >= 1.10.11 < 1.11.9 | 1.11.9 |
| d2iq | dc_os | >= 1.11.10 < 1.12.1 | 1.12.1 |
| d2iq | kubernetes_engine | < 2.2.0-1.13.3 | 2.2.0-1.13.3 |
| debian | docker.io | — | — |
| debian | firejail | < firejail 0.9.58.2-2 (bookworm) | firejail 0.9.58.2-2 (bookworm) |
| debian | lxc | < lxc 1:3.1.0+really3.0.3-4 (bookworm) | lxc 1:3.1.0+really3.0.3-4 (bookworm) |
| debian | runc | < lxc 1:3.1.0+really3.0.3-4 (bookworm) | lxc 1:3.1.0+really3.0.3-4 (bookworm) |
| docker | docker | < 18.09.2 | 18.09.2 |
| docker | docker | — | — |
| docker | docker | — | — |
| fedoraproject | fedora | — | — |
| fedoraproject | fedora | — | — |
| firejail_project | firejail | < 0.9.60 | 0.9.60 |
| firejail_project | firejail | >= 0 < 0.9.58.2-2 | 0.9.58.2-2 |
| firejail_project | firejail | >= 0 < 0.9.58.2-2 | 0.9.58.2-2 |
| firejail_project | firejail | >= 0 < 0.9.58.2-2 | 0.9.58.2-2 |
Detection & IOCsextracted from sources · hover to see the quote
commanddocker run -it --privileged --pid=host --net=host docker sh -c nsenter --mount=/proc/1/ns/mnt -- su -↗
- →Detect CVE-2019-5736 exploitation attempts via BOtB tool performing container breakout; monitor for BOtB process execution inside containers. ↗
- →Alert on containers launched with --privileged --pid=host --net=host flags combined with nsenter execution, which is a known host escape technique exploitable in the context of CVE-2019-5736. ↗
- ·Only docker version 1.13.1-108.git4ef4b30.el7 on RHEL 7 Extras is affected by the missing CVE-2019-5736 fix; earlier and later versions of the RHEL docker package are not affected. ↗
- ·Standard Kubernetes deployments allow anonymous kubelet access by default; most managed services (AKS, GKE, Kops) enforce authentication by default, reducing exposure. ↗
CVSS provenance
nvdv3.18.6HIGHCVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H
nvdv2.09.3CRITICALAV:N/AC:M/Au:N/C:C/I:C/A:C
osv8.6HIGH
vulncheck8.6HIGH
vendor_debian8.6LOW
vendor_msrc8.6HIGH
vendor_redhat8.6HIGH
CVEs like this are exactly what “Exploited This Week” covers.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
Kernel
fs: don't block i_writecount during exec
kernel_security·2024-05-31·CVSS 8.6
CVE-2019-5736 [HIGH] fs: don't block i_writecount during exec
fs: don't block i_writecount during exec
Back in 2021 we already discussed removing deny_write_access() for
executables. Back then I was hesistant because I thought that this might
cause issues in userspace. But even back then I had started taking some
notes on what could potentially depend on this and I didn't come up with
a lot so I've changed my mind and I would like to try this.
Here are some of the notes that I took:
(1) The deny_write_access() mechanism is causing really pointless issues
such as [1]. If a thread in a thread-group opens a file writable,
then writes some stuff, then closing the file descriptor and then
calling execve() they can fail the execve() with ETXTBUSY because
another thread in the thread-group could have concurrently called
fork(). Multi-threaded libraries s
GHSA
runc vulnerable to container breakout through process.cwd trickery and leaked fds
ghsa·2024-01-31
CVE-2024-21626 [HIGH] CWE-403 runc vulnerable to container breakout through process.cwd trickery and leaked fds
runc vulnerable to container breakout through process.cwd trickery and leaked fds
### Impact
In runc 1.1.11 and earlier, due to an internal file descriptor leak, an attacker could cause a newly-spawned container process (from `runc exec`) to have a working directory in the host filesystem namespace, allowing for a container escape by giving access to the host filesystem ("attack 2"). The same attack could be used by a malicious image to allow a container process to gain access to the host filesystem through `runc run` ("attack 1"). Variants of attacks 1 and 2 could be also be used to overwrite semi-arbitrary host binaries, allowing for complete container escapes ("attack 3a" and "attack 3b").
Strictly speaking, while attack 3a is the most severe from a CVSS perspective, attacks 2 and 3b
OSV
runc vulnerable to container breakout through process.cwd trickery and leaked fds
osv·2024-01-31
CVE-2024-21626 [HIGH] runc vulnerable to container breakout through process.cwd trickery and leaked fds
runc vulnerable to container breakout through process.cwd trickery and leaked fds
### Impact
In runc 1.1.11 and earlier, due to an internal file descriptor leak, an attacker could cause a newly-spawned container process (from `runc exec`) to have a working directory in the host filesystem namespace, allowing for a container escape by giving access to the host filesystem ("attack 2"). The same attack could be used by a malicious image to allow a container process to gain access to the host filesystem through `runc run` ("attack 1"). Variants of attacks 1 and 2 could be also be used to overwrite semi-arbitrary host binaries, allowing for complete container escapes ("attack 3a" and "attack 3b").
Strictly speaking, while attack 3a is the most severe from a CVSS perspective, attacks 2 and 3b
GHSA
GHSA-vqjv-866h-qv94: The version of docker as released for Red Hat Enterprise Linux 7 Extras via RHBA-2020:0053 advisory included an incorrect version of runc missing the
ghsa_unreviewed·2022-05-24·CVSS 8.6
CVE-2020-14298 [HIGH] CWE-273 GHSA-vqjv-866h-qv94: The version of docker as released for Red Hat Enterprise Linux 7 Extras via RHBA-2020:0053 advisory included an incorrect version of runc missing the
The version of docker as released for Red Hat Enterprise Linux 7 Extras via RHBA-2020:0053 advisory included an incorrect version of runc missing the fix for CVE-2019-5736, which was previously fixed via RHSA-2019:0304. This issue could allow a malicious or compromised container to compromise the container host and other containers running on the same host. This issue only affects docker version 1.13.1-108.git4ef4b30.el7, shipped in Red Hat Enterprise Linux 7 Extras. Both earlier and later versions are not affected.
GHSA
GHSA-933r-r67f-x632: Firejail before 0
ghsa_unreviewed·2022-05-24·CVSS 8.6
CVE-2019-12499 [HIGH] GHSA-933r-r67f-x632: Firejail before 0
Firejail before 0.9.60 allows truncation (resizing to length 0) of the firejail binary on the host by running exploit code inside a firejail sandbox and having the sandbox terminated. To succeed, certain conditions need to be fulfilled: The jail (with the exploit code inside) needs to be started as root, and it also needs to be terminated as root from the host (either by stopping it ungracefully (e.g., SIGKILL), or by using the --shutdown control command). This is similar to CVE-2019-5736.
GHSA
GHSA-gxmr-w5mj-v8hh: runc through 1
ghsa_unreviewed·2022-05-13
CVE-2019-5736 [HIGH] CWE-78 GHSA-gxmr-w5mj-v8hh: runc through 1
runc through 1.0-rc6, as used in Docker before 18.09.2 and other products, allows attackers to overwrite the host runc binary (and consequently obtain host root access) by leveraging the ability to execute a command as root within one of these types of containers: (1) a new container with an attacker-controlled image, or (2) an existing container, to which the attacker previously had write access, that can be attached with docker exec. This occurs because of file-descriptor mishandling, related to /proc/self/exe.
Kernel
Merge branch 'work.openat2' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs
kernel_security·2020-01-29
CVE-2017-1002101 Merge branch 'work.openat2' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs
Merge branch 'work.openat2' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs
Pull openat2 support from Al Viro:
"This is the openat2() series from Aleksa Sarai.
I'm afraid that the rest of namei stuff will have to wait - it got
zero review the last time I'd posted #work.namei, and there had been a
leak in the posted series I'd caught only last weekend. I was going to
repost it on Monday, but the window opened and the odds of getting any
review during that... Oh, well.
Anyway, openat2 part should be ready; that _did_ get sane amount of
review and public testing, so here it comes"
From Aleksa's description of the series:
"For a very long time, extending openat(2) with new features has been
incredibly frustrating. This stems from the fact that openat(2) is
possibly the most famou
OSV
CVE-2019-12499: Firejail before 0
osv·2019-05-31·CVSS 8.1
CVE-2019-12499 [HIGH] CVE-2019-12499: Firejail before 0
Firejail before 0.9.60 allows truncation (resizing to length 0) of the firejail binary on the host by running exploit code inside a firejail sandbox and having the sandbox terminated. To succeed, certain conditions need to be fulfilled: The jail (with the exploit code inside) needs to be started as root, and it also needs to be terminated as root from the host (either by stopping it ungracefully (e.g., SIGKILL), or by using the --shutdown control command). This is similar to CVE-2019-5736.
OSV
CVE-2019-5736: runc through 1
osv·2019-02-11·CVSS 8.6
CVE-2019-5736 [HIGH] CVE-2019-5736: runc through 1
runc through 1.0-rc6, as used in Docker before 18.09.2 and other products, allows attackers to overwrite the host runc binary (and consequently obtain host root access) by leveraging the ability to execute a command as root within one of these types of containers: (1) a new container with an attacker-controlled image, or (2) an existing container, to which the attacker previously had write access, that can be attached with docker exec. This occurs because of file-descriptor mishandling, related to /proc/self/exe.
VulnCheck
docker docker Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
vulncheck·2019·CVSS 8.6
CVE-2019-5736 [HIGH] docker docker Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
docker docker Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
runc through 1.0-rc6, as used in Docker before 18.09.2 and other products, allows attackers to overwrite the host runc binary (and consequently obtain host root access) by leveraging the ability to execute a command as root within one of these types of containers: (1) a new container with an attacker-controlled image, or (2) an existing container, to which the attacker previously had write access, that can be attached with docker exec. This occurs because of file-descriptor mishandling, related to /proc/self/exe.
Affected: docker docker
Required Action: Apply remediations or mitigations per vendor instructions or discontinue use of the product if remediation or mitigations are unavai
Palo Alto
PAN-SA-2020-0010 Informational: Cortex XSOAR: Impact of Linux and Docker vulnerabilities on Cortex XSOAR
vendor_paloalto·2020-10-14·CVSS 9.8
CVE-2019-5736 [CRITICAL] CWE-216 PAN-SA-2020-0010 Informational: Cortex XSOAR: Impact of Linux and Docker vulnerabilities on Cortex XSOAR
PAN-SA-2020-0010 Informational: Cortex XSOAR: Impact of Linux and Docker vulnerabilities on Cortex XSOAR
Cortex XSOAR provides analysts with the option to specify the Docker image to use for running custom scripts and integrations. An analyst who has write permission to scripts or integrations is able to exploit Docker vulnerabilities such as CVE-2019-5736, or Linux kernel vulnerability such as CVE-2020-14386 to obtain root access on the Cortex XSOAR server. Demisto Server does not use the docker exec command and does not expose a mechanism for an external attacker to manipulate or provide an attacker-controlled image for execution. Thus, CVE-2019-5736 does not increase exposure to an external attack. CVE-2019-5021 is a vulnerability in Alpine Linux Docker images where the root password m
Red Hat
docker: Security regression of CVE-2019-5736 due to inclusion of vulnerable runc
vendor_redhat·2020-06-23·CVSS 8.6
CVE-2020-14298 [HIGH] CWE-271 docker: Security regression of CVE-2019-5736 due to inclusion of vulnerable runc
docker: Security regression of CVE-2019-5736 due to inclusion of vulnerable runc
The version of docker as released for Red Hat Enterprise Linux 7 Extras via RHBA-2020:0053 advisory included an incorrect version of runc missing the fix for CVE-2019-5736, which was previously fixed via RHSA-2019:0304. This issue could allow a malicious or compromised container to compromise the container host and other containers running on the same host. This issue only affects docker version 1.13.1-108.git4ef4b30.el7, shipped in Red Hat Enterprise Linux 7 Extras. Both earlier and later versions are not affected.
The version of docker as released for Red Hat Enterprise Linux 7 Extras via RHBA-2020:0053 advisory included an incorrect version of runc missing the fix for CVE-2019-5736, which was previously f
Debian
CVE-2020-14298: docker.io - The version of docker as released for Red Hat Enterprise Linux 7 Extras via RHBA...
vendor_debian·2020·CVSS 8.6
CVE-2020-14298 [HIGH] CVE-2020-14298: docker.io - The version of docker as released for Red Hat Enterprise Linux 7 Extras via RHBA...
The version of docker as released for Red Hat Enterprise Linux 7 Extras via RHBA-2020:0053 advisory included an incorrect version of runc missing the fix for CVE-2019-5736, which was previously fixed via RHSA-2019:0304. This issue could allow a malicious or compromised container to compromise the container host and other containers running on the same host. This issue only affects docker version 1.13.1-108.git4ef4b30.el7, shipped in Red Hat Enterprise Linux 7 Extras. Both earlier and later versions are not affected.
Scope: local
bookworm: resolved
bullseye: resolved
forky: resolved
sid: resolved
trixie: resolved
Ubuntu
Docker vulnerabilities
vendor_ubuntu·2019-07-08
CVE-2018-15664 Docker vulnerabilities
Title: Docker vulnerabilities
Summary: Docker could be made to overwrite files as the administrator.
Aleksa Sarai discovered that Docker was vulnerable to a directory traversal
attack. An attacker could use this vulnerability to read and write arbitrary
files on the host filesystem as root.
Instructions: This update uses a new upstream release, which includes additional bug
fixes. In general, a standard system update will make all the necessary
changes.
VMware
VMware product updates resolve mishandled file descriptor vulnerability in runc container runtime.
vendor_vmware·2019-02-15·CVSS 8.6
CVE-2019-5736 [HIGH] VMware product updates resolve mishandled file descriptor vulnerability in runc container runtime.
VMSA-2019-0001: VMware product updates resolve mishandled file descriptor vulnerability in runc container runtime.
VMware product updates resolve mishandled file descriptor vulnerability in runc container runtime. Successful exploitation of this issue may allow a malicious container to overwrite the contents of a host's runc binary and execute arbitrary code. Exploitation of this vulnerability requires the attacker to have existing permission to deploy containers or run docker exec. Alternatively, an attacker could trick a user with these permissions into deploying a malicious container or running docker exec for them. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the identifier CVE-2019-5736 to this issue. Column 5 of the following table lists the action r
Cisco
Container Privilege Escalation Vulnerability Affecting Cisco Products: February 2019
vendor_cisco·2019-02-15
CVE-2019-5736 [HIGH] CWE-264 Container Privilege Escalation Vulnerability Affecting Cisco Products: February 2019
Container Privilege Escalation Vulnerability Affecting Cisco Products: February 2019
A vulnerability in the Open Container Initiative runc CLI tool used by multiple products could allow an unauthenticated, remote attacker to escalate privileges on a targeted system.
The vulnerability exists because the affected software improperly handles file descriptors related to /proc/self/exe. An attacker could exploit the vulnerability either by persuading a user to create a new container using an attacker-controlled image or by using the docker exec command to attach into an existing container that the attacker already has write access to. A successful exploit could allow the attacker to overwrite the host's runc binary file with a malicious file, escape the container, and execute arbitrary comman
Microsoft
runc through 1.0-rc6 as used in Docker before 18.09.2 and other products allows attackers to overwrite the host runc binary (and consequently obtain host root access) by leveraging the ability to exec
vendor_msrc·2019-02-12·CVSS 8.6
CVE-2019-5736 [HIGH] CWE-78 runc through 1.0-rc6 as used in Docker before 18.09.2 and other products allows attackers to overwrite the host runc binary (and consequently obtain host root access) by leveraging the ability to exec
runc through 1.0-rc6 as used in Docker before 18.09.2 and other products allows attackers to overwrite the host runc binary (and consequently obtain host root access) by leveraging the ability to execute a command as root within one of these types of containers: (1) a new container with an attacker-controlled image or (2) an existing container to which the attacker previously had write access that can be attached with docker exec. This occurs because of file-descriptor mishandling related to /proc/self/exe.
FAQ: Is Azure Linux the only Microsoft product that includes this open-source library and is therefore potentially affected by this vulnerability?
One of the main benefits to our customers who choose to use the Azure Linux distro is the commitment to keep it up to date with the most re
Red Hat
runc: Execution of malicious containers allows for container escape and access to host filesystem
vendor_redhat·2019-02-11·CVSS 8.6
CVE-2019-5736 [HIGH] CWE-672 runc: Execution of malicious containers allows for container escape and access to host filesystem
runc: Execution of malicious containers allows for container escape and access to host filesystem
runc through 1.0-rc6, as used in Docker before 18.09.2 and other products, allows attackers to overwrite the host runc binary (and consequently obtain host root access) by leveraging the ability to execute a command as root within one of these types of containers: (1) a new container with an attacker-controlled image, or (2) an existing container, to which the attacker previously had write access, that can be attached with docker exec. This occurs because of file-descriptor mishandling, related to /proc/self/exe.
A flaw was found in the way runc handled system file descriptors when running containers. A malicious container could use this flaw to overwrite contents of the runc binary and cons
Debian
CVE-2019-5736: lxc - runc through 1.0-rc6, as used in Docker before 18.09.2 and other products, allow...
vendor_debian·2019·CVSS 8.6
CVE-2019-5736 [HIGH] CVE-2019-5736: lxc - runc through 1.0-rc6, as used in Docker before 18.09.2 and other products, allow...
runc through 1.0-rc6, as used in Docker before 18.09.2 and other products, allows attackers to overwrite the host runc binary (and consequently obtain host root access) by leveraging the ability to execute a command as root within one of these types of containers: (1) a new container with an attacker-controlled image, or (2) an existing container, to which the attacker previously had write access, that can be attached with docker exec. This occurs because of file-descriptor mishandling, related to /proc/self/exe.
Scope: local
bookworm: resolved (fixed in 1:3.1.0+really3.0.3-4)
bullseye: resolved (fixed in 1:3.1.0+really3.0.3-4)
forky: resolved (fixed in 1:3.1.0+really3.0.3-4)
sid: resolved (fixed in 1:3.1.0+really3.0.3-4)
trixie: resolved (fixed in 1:3.1.0+really3.0.3-4)
Debian
CVE-2019-12499: firejail - Firejail before 0.9.60 allows truncation (resizing to length 0) of the firejail ...
vendor_debian·2019·CVSS 8.1
CVE-2019-12499 [HIGH] CVE-2019-12499: firejail - Firejail before 0.9.60 allows truncation (resizing to length 0) of the firejail ...
Firejail before 0.9.60 allows truncation (resizing to length 0) of the firejail binary on the host by running exploit code inside a firejail sandbox and having the sandbox terminated. To succeed, certain conditions need to be fulfilled: The jail (with the exploit code inside) needs to be started as root, and it also needs to be terminated as root from the host (either by stopping it ungracefully (e.g., SIGKILL), or by using the --shutdown control command). This is similar to CVE-2019-5736.
Scope: local
bookworm: resolved (fixed in 0.9.58.2-2)
bullseye: resolved (fixed in 0.9.58.2-2)
forky: resolved (fixed in 0.9.58.2-2)
sid: resolved (fixed in 0.9.58.2-2)
trixie: resolved (fixed in 0.9.58.2-2)
Cisco
Container Privilege Escalation Vulnerability Affecting Cisco Products: February 2019
vendor_cisco
CVE-2019-5736 Container Privilege Escalation Vulnerability Affecting Cisco Products: February 2019
CVE-2019-5736: Container Privilege Escalation Vulnerability Affecting Cisco Products: February 2019
A vulnerability in the Open Container Initiative runc CLI tool used by multiple products could allow an unauthenticated, remote attacker to escalate privileges on a targeted system. The vulnerability exists because the affected software improperly handles file descriptors related to /proc/self/exe . An attacker could exploit the vulnerability either by persuading a user to create a new container using an attacker-controlled image or by using the docker exec command to attach into an existing container that the attacker already has write access to. A successful exploit could allow the attacker to overwrite the host's runc binary file with a malicious file, escape the container, and execute ar
No detection rules found.
Exploit-DB
runc < 1.0-rc6 (Docker < 18.09.2) - Container Breakout (2)
exploitdb·2019-02-13·CVSS 8.6
CVE-2019-5736 [HIGH] runc < 1.0-rc6 (Docker < 18.09.2) - Container Breakout (2)
runc .
[+] constructed fdpath
[+] bad_init is ready -- see for logs.
[*] dying to allow /proc/self/exe to be unused...
% cat /usr/sbin/docker-runc
#!/bin/bash
touch /w00t_w00t ; cat /etc/shadow
```
And now if you try to use Docker normally, the malicious script will execute
with root privileges:
```
% docker exec -it pwnme /bin/good_bash
OCI runtime state failed: invalid character 'b' looking for beginning of value: unknown
% file /w00t_w00t
/w00t_w00t: empty
```
And obviously `make.sh` can be modified to make the evil path anything you
like. If you want to get access to the container, use `/bin/good_bash`.
### License ###
```
Copyright (C) 2019 Aleksa Sarai
Vulnerability discovered by Adam Iwaniuk and Borys Popławski.
Permission is hereby granted, free of charge, to any person obtai
Exploit-DB
runc < 1.0-rc6 (Docker < 18.09.2) - Container Breakout (1)
exploitdb·2019-02-12
CVE-2019-5736 runc < 1.0-rc6 (Docker < 18.09.2) - Container Breakout (1)
runc /bin/sh` is issued on the host.
More complete explanation [here](https://github.com/lxc/lxc/commit/6400238d08cdf1ca20d49bafb85f4e224348bf9d).
Download: https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/46359.zip
Metasploit
Docker Container Escape Via runC Overwrite
metasploit·CVSS 8.6
CVE-2019-5736 [HIGH] Docker Container Escape Via runC Overwrite
Docker Container Escape Via runC Overwrite
This module leverages a flaw in `runc` to escape a Docker container and get command execution on the host as root. This vulnerability is identified as CVE-2019-5736. It overwrites the `runc` binary with the payload and wait for someone to use `docker exec` to get into the container. This will trigger the payload execution. Note that executing this exploit carries important risks regarding the Docker installation integrity on the target and inside the container ('Side Effects' section in the documentation).
Hackernews
ThreatsDay Bulletin: AI Agents Gone Wrong, Sketchy C2 Tools, ClickFix Tricks, JS Backdoors & 20+ New Stories
blogs_hackernews·2026-06-04·CVSS 8.6
CVE-2026-20230 [HIGH] ThreatsDay Bulletin: AI Agents Gone Wrong, Sketchy C2 Tools, ClickFix Tricks, JS Backdoors & 20+ New Stories
Home
Threat Intelligence
Vulnerabilities
Cyber Attacks
Webinars
Expert Insights
Awards
Webinars
Awards
Free eBooks
About THN
Jobs
Advertise with us
## ThreatsDay Bulletin: AI Agents Gone Wrong, Sketchy C2 Tools, ClickFix Tricks, JS Backdoors & 20+ New Stories
It got stupid again.
The internet still feels held together with tape. Bad plugins, old bugs, fake tools, trusted apps doing shady things. Same mess, new wrapper. And now the weird stuff is normal. Forums go down and come back worse. Cheap hackers get better toys. AI starts breaking real systems. Great.
Read the whole thing before it ruins your week anyway.
Cisco has released fixes to address a high-severity security flaw in Unified Communications Manager (CVE-2026-20230, CVSS score: 8.6) that could allow an unauthe
Securelist
Containers on fire: from container escapes to supply chain attacks
blogs_securelist·2026-06-01
CVE-2019-5736 Containers on fire: from container escapes to supply chain attacks
Alexander Chudnov
Table of Contents
Introduction
Principles of containerization
Current attack vectors
Exploiting host system vulnerabilities
Malicious actions inside the container
Container escape
Privileged containers
CAP_SYS_ADMIN
CAP_SYS_MODULE
CAP_SYS_PTRACE
CAP_NET_ADMIN
Exploitation of orchestration APIs
Supply chain attacks
Takeaways
Authors
Alexander Chudnov
## Introduction
Modern infrastructures universally rely on containerization to deploy applications, scale services, and build cloud platforms. The use of Docker, Kubernetes, and similar technologies has become the corporate standard for efficient automation. However, as containers grow in popularity, so does the interest of malicious actors — a trend we actively track in our research into advanced cyberthrea
Wiz
What Is Arbitrary Code Execution? ACE Attacks Explained | Wiz
blogs_wiz·2025-11-30
What Is Arbitrary Code Execution? ACE Attacks Explained | Wiz
## What is arbitrary code execution?
Arbitrary code execution is when an attacker tricks your system into running their malicious code without permission. Think of it like someone breaking into your house and using your computer to do whatever they want.
When attackers achieve ACE, they can execute any commands they choose on your system. This lets attackers run code with the privileges of the compromised process—which could be a low-privilege web service account or a high-privilege system daemon. The actual control level depends on what permissions the exploited application already has. It's one of the worst types of security vulnerabilities because it hands over complete system access to the attacker.
Cloud environments change the blast radius calculus for ACE attacks. If network segm
Wiz
What Is Arbitrary Code Execution? ACE Attacks Explained | Wiz
blogs_wiz·2025-11-30
What Is Arbitrary Code Execution? ACE Attacks Explained | Wiz
## What is arbitrary code execution?
Arbitrary code execution is when an attacker tricks your system into running their malicious code without permission. Think of it like someone breaking into your house and using your computer to do whatever they want.
When attackers achieve ACE, they can execute any commands they choose on your system. This lets attackers run code with the privileges of the compromised process—which could be a low-privilege web service account or a high-privilege system daemon. The actual control level depends on what permissions the exploited application already has. It's one of the worst types of security vulnerabilities because it hands over complete system access to the attacker.
Cloud environments change the blast radius calculus for ACE attacks. If network segm
Wiz
What is Container Escape: Detection & Prevention | Wiz
blogs_wiz·2025-11-06
What is Container Escape: Detection & Prevention | Wiz
## What is container escape?
Container escape is when an attacker breaks out of a container's isolation boundaries to gain unauthorized access to the host operating system or other containers running on the same system. This happens because containers share the host kernel, unlike virtual machines that provide hardware-level isolation.
When isolation mechanisms like namespaces and cgroups get compromised through vulnerabilities or misconfigurations, attackers can escalate privileges and move laterally through your environment. A successful container escape is one of the most severe threats in containerized environments because it can compromise your entire infrastructure.
###### Container Security Best Practices Cheat Sheet
Understanding container escape is just the first step. Get pra
Wiz
What is Container Escape: Detection & Prevention | Wiz
blogs_wiz·2025-11-06
What is Container Escape: Detection & Prevention | Wiz
## What is container escape?
Container escape is when an attacker breaks out of a container's isolation boundaries to gain unauthorized access to the host operating system or other containers running on the same system. This happens because containers share the host kernel, unlike virtual machines that provide hardware-level isolation.
When isolation mechanisms like namespaces and cgroups get compromised through vulnerabilities or misconfigurations, attackers can escalate privileges and move laterally through your environment. A successful container escape is one of the most severe threats in containerized environments because it can compromise your entire infrastructure.
## Container Security Best Practices Cheat Sheet
Understanding container escape is just the first step. Get practic
Unit42
Container Breakouts: Escape Techniques in Cloud Environments
blogs_unit42·2024-07-18·CVSS 8.6
[HIGH] Container Breakouts: Escape Techniques in Cloud Environments
Threat Research Center
Threat Research
Cloud Cybersecurity Research
## Container Breakouts: Escape Techniques in Cloud Environments
Yosef Yaakov
Bar Ben-Michael
Published: July 18, 2024
Cloud Cybersecurity Research
Threat Research
Cloud infrastructure
Container
Container escape
Container security
Docker
Kubernetes
## Executive Summary
This article reviews container escape techniques, assesses their possible impact and reveals how to detect these escapes from the perspective of endpoint detection and response (EDR).
As cloud services rise in popularity, so does the use of containers, which have become an integrated part of cloud infrastructure. Although containers provide many advantages, they are also susceptible to attack techniques like container escapes.
Many conta
Unit42
Container Breakouts: Escape Techniques in Cloud Environments
blogs_unit42·2024-07-18·CVSS 8.6
[HIGH] Container Breakouts: Escape Techniques in Cloud Environments
## Executive Summary
This article reviews container escape techniques, assesses their possible impact and reveals how to detect these escapes from the perspective of endpoint detection and response (EDR).
As cloud services rise in popularity, so does the use of containers, which have become an integrated part of cloud infrastructure. Although containers provide many advantages, they are also susceptible to attack techniques like container escapes.
Many containers are internet-facing, which poses an even greater security risk. For example, an external attacker who has gained low-privilege access to a container will attempt to escape it through a variety of methods that include exploiting misconfigurations and vulnerabilities.
Container escapes are a notable security risk for organizatio
Trendmicro
Gaps in Azure Service Fabric’s Security Call for User Vigilance
blogs_trendmicro·2023-06-21
Gaps in Azure Service Fabric’s Security Call for User Vigilance
Cloud
## Gaps in Azure Service Fabric’s Security Call for User Vigilance
In this blog post, we discuss different configuration scenarios that may lead to security issues with Azure Service Fabric, a distributed platform for deploying, managing, and scaling microservices and container applications.
By: David Fiser Jun 21, 2023 Read time: ( words)
Save to Folio
Besides being known for deployment of containerized applications, many also know Kubernetes for container orchestration. However, it’s not the only platform that offers this service in the market. In this blog post, we will focus on Service Fabric, an orchestrator developed by Microsoft and available as a service inside the Azure cloud. As with our previous posts on Kubernetes , we will look into different configuration scenarios
Trendmicro
Gaps in Azure Service Fabric’s Security Call for User Vigilance
blogs_trendmicro·2023-06-21
Gaps in Azure Service Fabric’s Security Call for User Vigilance
Nube
## Gaps in Azure Service Fabric’s Security Call for User Vigilance
In this blog post, we discuss different configuration scenarios that may lead to security issues with Azure Service Fabric, a distributed platform for deploying, managing, and scaling microservices and container applications.
By: David Fiser Jun 21, 2023 Read time: ( words)
Save to Folio
Besides being known for deployment of containerized applications, many also know Kubernetes for container orchestration. However, it’s not the only platform that offers this service in the market. In this blog post, we will focus on Service Fabric, an orchestrator developed by Microsoft and available as a service inside the Azure cloud. As with our previous posts on Kubernetes , we will look into different configuration scenarios
Trendmicro
Gaps in Azure Service Fabric’s Security Call for User Vigilance
blogs_trendmicro·2023-06-21
Gaps in Azure Service Fabric’s Security Call for User Vigilance
Cloud
## Gaps in Azure Service Fabric’s Security Call for User Vigilance
In this blog post, we discuss different configuration scenarios that may lead to security issues with Azure Service Fabric, a distributed platform for deploying, managing, and scaling microservices and container applications.
By: David Fiser 2023/06/21 Read time: ( words)
Save to Folio
Besides being known for deployment of containerized applications, many also know Kubernetes for container orchestration. However, it’s not the only platform that offers this service in the market. In this blog post, we will focus on Service Fabric, an orchestrator developed by Microsoft and available as a service inside the Azure cloud. As with our previous posts on Kubernetes , we will look into different configuration scenarios t
Trendmicro
Gaps in Azure Service Fabric’s Security Call for User Vigilance
blogs_trendmicro·2023-06-21
Gaps in Azure Service Fabric’s Security Call for User Vigilance
Cloud
# Gaps in Azure Service Fabric’s Security Call for User Vigilance
In this blog post, we discuss different configuration scenarios that may lead to security issues with Azure Service Fabric, a distributed platform for deploying, managing, and scaling microservices and container applications.
By: David Fiser
2023/06/21
Read time: ( words)
Save to Folio
Besides being known for deployment of containerized applications, many also know Kubernetes for container orchestration. However, it’s not the only platform that offers this service in the market. In this blog post, we will focus on Service Fabric, an orchestrator developed by Microsoft and available as a service inside the Azure cloud. As with our previous posts on Kubernetes, we will look into different configuration scenarios th
Unit42
Finding Azurescape – Cross-Account Container Takeover in Azure Container Instances
blogs_unit42·2021-09-09
Finding Azurescape – Cross-Account Container Takeover in Azure Container Instances
## Executive Summary
Azure Container Instances (ACI) is Azure's Container-as-a-Service (CaaS) offering, enabling customers to run containers on Azure without managing the underlying servers. Unit 42 researchers recently identified and disclosed critical security issues in ACI to Microsoft. A malicious Azure user could have exploited these issues to execute code on other users' containers, steal customer secrets and images deployed to the platform, and possibly abuse ACI's infrastructure for cryptomining. Researchers named the vulnerability Azurescape – the first cross-account container takeover in the public cloud.
Azurescape allowed malicious users to compromise the multitenant Kubernetes clusters hosting ACI, establishing full control over other users' containers. This post covers the
Unit42
Finding Azurescape – Cross-Account Container Takeover in Azure Container Instances
blogs_unit42·2021-09-09·CVSS 2.6
CVE-2018-1002102 [LOW] Finding Azurescape – Cross-Account Container Takeover in Azure Container Instances
Threat Research Center
Threat Research
Cloud Cybersecurity Research
## Finding Azurescape – Cross-Account Container Takeover in Azure Container Instances
Yuval Avrahami
Published: September 9, 2021
Cloud Cybersecurity Research
Threat Research
Vulnerabilities
Azure
Azurescape
Cloud Security
Containers
CVE-2018-1002102
CVE-2019-5736
Kubernetes
RunC
## Executive Summary
Azure Container Instances (ACI) is Azure's Container-as-a-Service (CaaS) offering, enabling customers to run containers on Azure without managing the underlying servers. Unit 42 researchers recently identified and disclosed critical security issues in ACI to Microsoft. A malicious Azure user could have exploited these issues to execute code on other users' containers, steal customer secrets and images dep
Unit42
Unsecured Kubernetes Instances Could Be Vulnerable to Exploitation
blogs_unit42·2021-04-24
Unsecured Kubernetes Instances Could Be Vulnerable to Exploitation
Threat Research Center
Threat Research
Cloud Cybersecurity Research
## Unsecured Kubernetes Instances Could Be Vulnerable to Exploitation
Jay Chen
Aviv Sasson
Ariel Zelivansky
Published: April 23, 2021
Cloud Cybersecurity Research
Threat Research
Containers
Docker
Kubernetes
Public cloud
## Executive Summary
Between October 2020 and February 2021, Unit 42 researchers periodically scanned and analyzed unsecured Kubernetes (also known as k8s) clusters on the internet. Kubernetes clusters can and should be configured for greater security, but when left unsecured, these clusters can be accessed anonymously by anyone who knows their IPs, ports and APIs. Researchers identified 2,100 unsecured Kubernetes clusters that consist of 5,300 nodes, 31,340 CPUs and 75,270 pods. A wide
Unit42
Unsecured Kubernetes Instances Could Be Vulnerable to Exploitation
blogs_unit42·2021-04-24
Unsecured Kubernetes Instances Could Be Vulnerable to Exploitation
## Executive Summary
Between October 2020 and February 2021, Unit 42 researchers periodically scanned and analyzed unsecured Kubernetes (also known as k8s) clusters on the internet. Kubernetes clusters can and should be configured for greater security, but when left unsecured, these clusters can be accessed anonymously by anyone who knows their IPs, ports and APIs. Researchers identified 2,100 unsecured Kubernetes clusters that consist of 5,300 nodes, 31,340 CPUs and 75,270 pods. A wide range of applications were seen running in these unsecured clusters, operated by organizations in sectors including e-commerce, finance and healthcare. The abundant computational resources and large amount of sensitive data in the applications – such as API tokens, database credentials, source code and per
Unit42
Hildegard: New TeamTNT Cryptojacking Malware Targeting Kubernetes
blogs_unit42·2021-02-03
Hildegard: New TeamTNT Cryptojacking Malware Targeting Kubernetes
Threat Research Center
Threat Research
Cloud Cybersecurity Research
## Hildegard: New TeamTNT Cryptojacking Malware Targeting Kubernetes
Jay Chen
Aviv Sasson
Ariel Zelivansky
Published: February 3, 2021
Cloud Cybersecurity Research
Threat Research
Containers
Cryptojacking
Docker
Kubernetes
Public cloud
TeamTnT
## Executive Summary
In January 2021, Unit 42 researchers detected a new malware campaign targeting Kubernetes clusters. The attackers gained initial access via a misconfigured kubelet that allowed anonymous access. Once getting a foothold into a Kubernetes cluster, the malware attempted to spread over as many containers as possible and eventually launched cryptojacking operations. Based on the tactics, techniques and procedures (TTP) that the attackers used, we
Unit42
Hildegard: New TeamTNT Cryptojacking Malware Targeting Kubernetes
blogs_unit42·2021-02-03
Hildegard: New TeamTNT Cryptojacking Malware Targeting Kubernetes
## Executive Summary
In January 2021, Unit 42 researchers detected a new malware campaign targeting Kubernetes clusters. The attackers gained initial access via a misconfigured kubelet that allowed anonymous access. Once getting a foothold into a Kubernetes cluster, the malware attempted to spread over as many containers as possible and eventually launched cryptojacking operations. Based on the tactics, techniques and procedures (TTP) that the attackers used, we believe this is a new campaign from TeamTNT. We refer to this new malware as Hildegard, the username of the tmate account that the malware used.
TeamTNT is known for exploiting unsecured Docker daemons and deploying malicious container images, as documented in previous research (Cetus, Black-T and TeamTNT DDoS). However, this is
Unit42
The Challenge of Persistence in Containers and Serverless
blogs_unit42·2020-09-10
The Challenge of Persistence in Containers and Serverless
## Executive Summary
Seasoned attackers will tell you that persistence is an important part of any successful hacking campaign. Persistence allows attackers to maintain continuous control of their captured servers. Whether they are hijacking resources, exfiltrating data or using their target machines as proxies, attackers always face the risk of having their treasured vulnerabilities patched and sealed, eliminating their way in. The shift from traditional computing to technologies like containers and serverless has made persistence harder to obtain, thanks to the transient nature and strong isolation mechanisms of these technologies.
Palo Alto Networks customers are protected from these attacks by Prisma Cloud, which successfully detects and mitigates vulnerabilities as well as using Pri
Unit42
The Challenge of Persistence in Containers and Serverless
blogs_unit42·2020-09-10
The Challenge of Persistence in Containers and Serverless
Threat Research Center
Threat Research
Cloud Cybersecurity Research
## The Challenge of Persistence in Containers and Serverless
Ariel Zelivansky
Published: September 10, 2020
Cloud Cybersecurity Research
Threat Research
Containers
Docker
Kubernetes
Serverless
## Executive Summary
Seasoned attackers will tell you that persistence is an important part of any successful hacking campaign. Persistence allows attackers to maintain continuous control of their captured servers. Whether they are hijacking resources, exfiltrating data or using their target machines as proxies, attackers always face the risk of having their treasured vulnerabilities patched and sealed, eliminating their way in. The shift from traditional computing to technologies like containers and serverless has m
Unit42
Non-Root Containers, Kubernetes CVE-2019-11245 and Why You Should Care
blogs_unit42·2019-08-28·CVSS 4.9
CVE-2019-11245 [MEDIUM] Non-Root Containers, Kubernetes CVE-2019-11245 and Why You Should Care
Threat Research Center
Threat Research
Cloud Cybersecurity Research
## Non-Root Containers, Kubernetes CVE-2019-11245 and Why You Should Care
Ariel Zelivansky
Published: August 28, 2019
Cloud Cybersecurity Research
Threat Research
Vulnerabilities
Containers
CVE-2019-11245
Kubernetes
On May 31th, the Kubernetes Product Security Committee announced a security regression in Kubernetes for which they had assigned CVE-2019-11245. The problem caused containers that use images which are supposed to run with a non root user to run as root, on the second time they are used or upon restart of the container.
Before elaborating on this particular security issue, let’s first clarify why running a program as root in a container is even a concern at all.
## Non-root containers
When run
Unit42
Non-Root Containers, Kubernetes CVE-2019-11245 and Why You Should Care
blogs_unit42·2019-08-28·CVSS 4.9
CVE-2019-11245 [MEDIUM] Non-Root Containers, Kubernetes CVE-2019-11245 and Why You Should Care
On May 31th, the Kubernetes Product Security Committee announced a security regression in Kubernetes for which they had assigned CVE-2019-11245. The problem caused containers that use images which are supposed to run with a non root user to run as root, on the second time they are used or upon restart of the container.
Before elaborating on this particular security issue, let’s first clarify why running a program as root in a container is even a concern at all.
## Non-root containers
When running applications on a non-containerized Linux environment, e.g. on the host machine, it is commonly understood why isolation between the root user and non-privileged users is desired. If run as root, any breached or misbehaving application could easily wreak havoc on the system, by modifying system
Unit42
Making Containers More Isolated: An Overview of Sandboxed Container Technologies
blogs_unit42·2019-06-06
Making Containers More Isolated: An Overview of Sandboxed Container Technologies
Threat Research Center
Threat Research
Cloud Cybersecurity Research
## Making Containers More Isolated: An Overview of Sandboxed Container Technologies
Jay Chen
Published: June 6, 2019
Cloud Cybersecurity Research
Learning Hub
Threat Research
Containers
Docker
Kubernetes
LXC
Public cloud
Rkt
Executive Summary
While the majority of the IT industry is in the midst of adopting container-based infrastructure (cloud-native solution), it is imperative to understand the technology’s limitations. Traditional containers such as Docker, Linux Containers (LXC), and Rocket (rkt) are not truly sandboxed as they share the host OS kernel. They are resource-efficient, but the attack surface and the potential impact of a breach are still large, especially in a multi-tenant cloud environme
Unit42
Making Containers More Isolated: An Overview of Sandboxed Container Technologies
blogs_unit42·2019-06-06
Making Containers More Isolated: An Overview of Sandboxed Container Technologies
Executive Summary
While the majority of the IT industry is in the midst of adopting container-based infrastructure (cloud-native solution), it is imperative to understand the technology’s limitations. Traditional containers such as Docker, Linux Containers (LXC), and Rocket (rkt) are not truly sandboxed as they share the host OS kernel. They are resource-efficient, but the attack surface and the potential impact of a breach are still large, especially in a multi-tenant cloud environment that co-locate containers belonging to different customers. The root of the problem is the weak separation between containers when the host OS creates a virtualized userland for each container. There has been research and development focusing on designing truly sandboxed containers. Most of the solutions r
Unit42
Breaking Out of rkt – 3 New Unpatched CVEs
blogs_unit42·2019-05-30·CVSS 8.6
CVE-2019-5736 [HIGH] Breaking Out of rkt – 3 New Unpatched CVEs
# Executive Summary
Back in February, I wrote a piece on the major runC vulnerability, CVE-2019-5736. The fundamental flaw behind this vulnerability affected most container runtimes, such as LXC and Apache Mesos. One container runtime which seemed to be unfazed was CoreOS rkt, on which I heard a lot back when I first started to get into containers. So naturally, I was intrigued to check out rkt’s architecture and see what they did differently, and I recently had some time to do so.
I ended up finding 3 other, unrelated vulnerabilities in rkt. These vulnerabilities allow an attacker to compromise the host when a rkt user executes the ‘rkt enter’ command (the equivalent of ‘docker exec’) into an attacker-controlled pod. They are currently unpatched.
### rkt
rkt is an open source containe
Unit42
Breaking Out of rkt – 3 New Unpatched CVEs
blogs_unit42·2019-05-30·CVSS 7.7
CVE-2019-10147 [HIGH] Breaking Out of rkt – 3 New Unpatched CVEs
Threat Research Center
Threat Research
Cloud Cybersecurity Research
## Breaking Out of rkt – 3 New Unpatched CVEs
Yuval Avrahami
Published: May 30, 2019
Cloud Cybersecurity Research
Threat Research
Vulnerabilities
CVE-2019-10147
Docker. CVE-2019-10144. CVE-2019-10145
## Executive Summary
Back in February, I wrote a piece on the major runC vulnerability, CVE-2019-5736. The fundamental flaw behind this vulnerability affected most container runtimes, such as LXC and Apache Mesos. One container runtime which seemed to be unfazed was CoreOS rkt , on which I heard a lot back when I first started to get into containers. So naturally, I was intrigued to check out rkt’s architecture and see what they did differently, and I recently had some time to do so.
I ended up finding 3 other
Unit42
Breaking out of Docker via runC – Explaining CVE-2019-5736
blogs_unit42·2019-02-21·CVSS 8.6
CVE-2019-5736 [HIGH] Breaking out of Docker via runC – Explaining CVE-2019-5736
Last week (2019-02-11) a new vulnerability in runC was reported 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 and LXC 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 with all the relevant details and the mitigations offered by the Twistlock platform
Unit42
Breaking out of Docker via runC – Explaining CVE-2019-5736
blogs_unit42·2019-02-21·CVSS 8.6
CVE-2019-5736 [HIGH] Breaking out of Docker via runC – Explaining CVE-2019-5736
Threat Research Center
Threat Research
Cloud Cybersecurity Research
## Breaking out of Docker via runC – Explaining CVE-2019-5736
Yuval Avrahami
Published: February 21, 2019
Cloud Cybersecurity Research
Threat Research
Vulnerabilities
Container breakout
Container escape
Containers
CVE-2019-5736
Docker
Exploit
RunC
Last week (2019-02-11) a new vulnerability in runC was reported 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
Tenable
CVE-2019-5736 Exploits the Common runc Container Binary to Escape to Host
blogs_tenable·2019-02-13·CVSS 8.6
CVE-2019-5736 [HIGH] CVE-2019-5736 Exploits the Common runc Container Binary to Escape to Host
Blog / Cyber Exposure Alerts
Subscribe
# CVE-2019-5736 Exploits the Common runc Container Binary to Escape to Host
Ryan Seguin
February 13, 2019
2 Min Read
CVE-2019-5736 allows for an escape to host attack in specific container configurations.
### Background
A new vulnerability (CVE-2019-5736) was recently announced in runc, the runtime used by popular container platforms Docker and Kubernetes. The disclosure for this vulnerability details how a malicious container can escape its sandbox and execute arbitrary commands on the host. This attack does, however, come with some caveats, and isn’t exploitable in certain configurations that follow good security practices.
### Analysis
In order to properly exploit this vulnerability, a malicious or compromised container would need to be de
Tenable
CVE-2019-5736 Exploits the Common runc Container Binary to Escape to Host
blogs_tenable·2019-02-13·CVSS 8.6
[HIGH] CVE-2019-5736 Exploits the Common runc Container Binary to Escape to Host
## Cloud Exposure
Tenable Cloud Security (CNAPP) Request a demo
Tenable Cloud Vulnerability Management Request a demo
Tenable CIEM Request a demo
Secure your cloud
## Vulnerability Exposure
Tenable Vulnerability Management Try for free
Tenable Security Center Request a demo
Tenable Web App Scanning Try for free
Tenable Patch Management Request a demo
Tenable Enclave Security Request a demo
Tenable Attack Surface Management Request a demo
Tenable Nessus Try for free
## AI Exposure
Tenable AI Exposure Request a demo
## OT/IoT Exposure
Tenable OT Security Request a demo
## Identity Exposure
Tenable Identity Exposure Request a demo
## Business needs
Active Directory
AI Security Posture Management (AI-SPM)
AWS security
Azure security
Cloud Security Posture Man
Greynoiseio
Change in ENV Crawler Tags as Bots Continue to Target Environment Files
blogs_greynoiseio
Change in ENV Crawler Tags as Bots Continue to Target Environment Files
CVE Disclosure Early Warning Get an early warning when traffic spikes indicate a high likelihood of new disclosures
Compromised Asset Detection Find out immediately if an asset communicates with a malicious IP address
Vulnerability Prioritization Get real-time insight into active exploitation trends to better understand risk and severity
SOC Efficiency Filter out noisy, low priority and false-positive alerts from mass internet scanners
Incident Investigation Add context to incidents to speed the determinations of scope and timelines
Threat Hunting Quickly identify anomalous behavior and enrich your threat hunting campaigns
Why GreyNoise
CVE Disclosure Early Warning Get an early warning when traffic spikes indicate a high likelihood of new disclosures
Compromised Asset Detection Fin
arXiv
TPM-Based Continuous Remote Attestation and Integrity Verification for 5G VNFs on Kubernetes
arxiv_fulltext·2025-10-03
TPM-Based Continuous Remote Attestation and Integrity Verification for 5G VNFs on Kubernetes
TPM-Based Continuous Remote Attestation and Integrity Verification for 5G VNFs on Kubernetes
Al Nahian Bin Emran, Rajendra Upadhyay, Rajendra Paudyal, Lisa Donnan, Duminda Wijesekera
Mason Innovation Labs,
George Mason University, Arlington, VA, 22201, USA
\abinemra rupadhya rpaudyal ldonnan dwijesek@ .edu
## Abstract
In the rapidly evolving landscape of 5G technology, the adoption of cloud-based infrastructure for the deployment of 5G services has become increasingly common. Using a service-based architecture, critical 5G components, such as the Access and Mobility Management Function (AMF), Session Management Function (SMF), and User Plane Function (UPF), now run as containerized pods on Kubernetes clusters. Although this approach improves scalability, flexibility, and resilience, i
arXiv
A High-performance Real-time Container File Monitoring Approach Based on Virtual Machine Introspection
arxiv_fulltext·2025-09-19
A High-performance Real-time Container File Monitoring Approach Based on Virtual Machine Introspection
[Article Title]A High-performance Real-time Container File Monitoring Approach Based on Virtual Machine Introspection
[1]Kai [email protected]
*[1]Dongyang [email protected]
[1]Lin [email protected]
[1]Hongli [email protected]
[1]Binxing [email protected]
[2]Zhihong [email protected]
*[1]School of Cyberspace Science, Harbin Institute of Technology, Harbin, 150001, China
*[2]Guangzhou University, Guangzhou, 510000, China
As cloud computing continues to advance and become an integral part of modern IT infrastructure, container security has emerged as a critical factor in ensuring the smooth operation of cloud-native applications. An attacker can attack the service in the container or even perform the container escape attack by tampering with
arXiv
Cross-Service Token: Finding Attacks in 5G Core Networks
arxiv_fulltext·2025-09-10
Cross-Service Token: Finding Attacks in 5G Core Networks
Cross-Service Token: Finding Attacks in 5G Core Networks
Anqi Chen*
Northeastern University
[email protected]
Riccardo Preatoni*
University of Padova
[email protected]
Alessandro Brighente
University of Padova
[email protected]
Mauro Conti
University of Padua & Örebro University
[email protected]
Cristina Nita-Rotaru
Northeastern University
[email protected]
*Equal contribution.
\@IEEEpubidpullup6.5
Network and Distributed System Security (NDSS) Symposium 2026
23 - 27 February 2026 , San Diego, CA, USA
ISBN 979-8-9919276-8-0
https://dx.doi.org/10.14722/ndss.2026.[23|24]xxxx
www.ndss-symposium.org
[ ]
## Abstract
5G marks a major departure from previous cellular architectures, by transitioning from a monolithic design of th
arXiv
Analysis of Security in OS-Level Virtualization
arxiv_fulltext·2025-01-02
Analysis of Security in OS-Level Virtualization
Analysis of Security in OS-Level Virtualization
Krishna Sai Ketha1, Guanqun Song1, Ting Zhu1
1Department of Computer Science and Engineering, The Ohio State University, Columbus, USA
Email: [email protected], [email protected], [email protected]
## Abstract
Virtualization is a technique that allows multiple instances typically running different guest operating systems on top of single physical hardware. A hypervisor, a layer of software running on top of the host operating system, typically runs and manages these different guest operating systems. Rather than to run different services on different servers for reliability and security reasons, companies started to employ virtualization over their servers to run these services within a single server. This approach proves benefic
arXiv
Microservice Vulnerability Analysis: A Literature Review with Empirical Insights
arxiv_fulltext·2024-07-31
Microservice Vulnerability Analysis: A Literature Review with Empirical Insights
Microservice Vulnerability Analysis: A Literature Review with Empirical Insights
Raveen Kanishka Jayalath*
University of Adelaide, Australia
[email protected]
Hussain Ahmad* *Authors contributed equally to this work. Corresponding author.
University of Adelaide, Australia
[email protected]
Diksha Goel
CSIRO's Data61, Australia
[email protected]
3cmMuhammad Shuja Syed
3cmSLB, USA
[email protected]
Faheem Ullah
University of Adelaide, Australia
[email protected]
plain
## Abstract
Microservice architectures are revolutionizing both small businesses and large corporations, igniting a new era of innovation with their exceptional advantages in maintainability, reusability, and scalability. However, these benefits come w
arXiv
AI-Driven Container Security Approaches for 5G and Beyond: A Survey
arxiv_fulltext·2023-03-31
AI-Driven Container Security Approaches for 5G and Beyond: A Survey
[
@twocolumnfalse
## Abstract
The rising use of microservices based software deployment on the cloud leverages containerized software extensively.
The security of applications running inside containers as well as the container environment itself are critical infrastructure in the cloud setting and 5G.
To address the security concerns, research efforts have been focused on container security with subfields such as intrusion detection, malware detection and container placement strategies.
These security efforts are roughly divided into two categories: rule based approaches and machine learning that can respond to novel threats.
In this study, we have surveyed the container security literature focusing on approaches that leverage machine learning to address security challenges.
container,
arXiv
Threat Modeling and Security Analysis of Containers: A Survey
arxiv_fulltext·2021-11-22
Threat Modeling and Security Analysis of Containers: A Survey
Threat Modeling and Security Analysis of Containers: A Survey
Ann Yi Wong1 Eyasu Getahun Chekole1 Mart\'in Ochoa2 Jianying Zhou1
Singapore University of Technology and Design, Singapore 487372, Singapore
[email protected], \eyasu_chekole, jianying_zhou\@sutd.edu.sg
Department of Computer Science, ETH Zurich, 8092 Zurich, Switzerland
[email protected]
## Abstract
Traditionally, applications that are used in large and small enterprises were deployed on ``bare metal'' servers installed with operating systems. Recently, the use of multiple virtual machines (VMs) on the same physical server was adopted due to cost reduction and flexibility. Nowadays, containers have become popular for application deployment due to smaller footprints than the VMs, their ability to start
arXiv
Lic-Sec: an enhanced AppArmor Docker security profile generator
arxiv_fulltext·2020-09-24
Lic-Sec: an enhanced AppArmor Docker security profile generator
frontmatter
5pt
- 0ex
0cm
0em
Lic-Sec: an enhanced AppArmor Docker security profile generator
[1]Hui Zhu
[email protected]
[1]Christian Gehrmann
[email protected]
[1]Department of Electrical and Information Technology, Lund University, Lund, Sweden
## Abstract
Along with the rapid development of cloud computing technology, containerization technology has drawn much attention from both industry and academia. In this paper, we perform a comparative measurement analysis of Docker-sec, which is a Linux Security Module proposed in 2018, and a new AppArmor profile generator called Lic-Sec, which combines Docker-sec with a modified version of LiCShield, which is also a Linux Security Module proposed in 2015. Docker-sec and LiCShield can be used to enhance Docker container sec
CTF
TheNoteBook / README
ctf_writeups·CVSS 8.6
[HIGH] TheNoteBook / README
# TheNoteBook - HackTheBox
Linux, 30 Base Points, Medium
## Machine
## TL;DR;
To solve this machine, we begin by enumerating open services using namp – finding ports 80, 22, 10010.
***User:*** Find JWT token with ```"kid":"http://localhost:7070/privKey.key"``` value, Sign new JWT token with our private key and get access to ```/admin``` page as admin role, Uploading PHP web shell and got shell as ```www-data```, Found ```/var/backups/home.tar.gz``` with ```noah``` ssh private key.
***Root:*** By running sudo -l, we learn we are able to run ```/usr/bin/docker exec -it webapp-dev01*``` as root, Get exec to running container and use [CVE-2019-5736-PoC](https://github.com/Frichetten/CVE-2019-5736-PoC) to read the root flag.
## TheNoteBook Solution
### User
So let's start with ```nmap``
Bugzilla
CVE-2024-21626 runc: file descriptor leak
bugzilla·2024-01-17·CVSS 8.6
CVE-2024-21626 [HIGH] CVE-2024-21626 runc: file descriptor leak
CVE-2024-21626 runc: file descriptor leak
The core issue is a file descriptor leak, and while we do `O_CLOEXEC` all file descriptors before executing the container code, the file descriptor is open when doing `setcwd(2)` which means that the reference can be kept alive into the container by configuring the working directory to be a path resolved through the file descriptor (and the non-dumpable bit is unset after `execve` meaning that there are multiple ways to attack this other than bad configurations).
There is also an `execve`-based attack that makes simple verification unworkable was particularly hairy to fix (the patch involves doing `//go:linkname` to access Go runtime internals, because the only way to defend against it entirely is to close all unneeded file descriptors -- for the
Bugzilla
CVE-2020-14298 docker: Security regression of CVE-2019-5736 due to inclusion of vulnerable runc
bugzilla·2020-06-18·CVSS 8.6
CVE-2020-14298 [HIGH] CVE-2020-14298 docker: Security regression of CVE-2019-5736 due to inclusion of vulnerable runc
CVE-2020-14298 docker: Security regression of CVE-2019-5736 due to inclusion of vulnerable runc
The docker packages version docker-1.13.1-108.git4ef4b30.el7 as released for Red Hat Enterprise Linux 7 Extras via RHBA-2020:0053 (https://access.redhat.com/errata/RHBA-2020:0053) included an incorrect version of runc that was missing multiple bug and security fixes. One of the fixes regressed in that update was the fix for CVE-2019-5736, that was previously corrected in the docker packages in Red Hat Enterprise Linux 7 Extras via RHSA-2019:0304 (https://access.redhat.com/errata/RHSA-2019:0304). The CVE-2020-14298 was assigned to this security regression and it is specific to the docker packages produced by Red Hat.
The original issue - CVE-2019-5736 - could possibly allow a privileged process
HackerOne
CVE-2019-5736: Escape from Docker and Kubernetes containers to root on host
hackerone·2019-09-26·CVSS 8.6
CVE-2019-5736 [HIGH] CVE-2019-5736: Escape from Docker and Kubernetes containers to root on host
CVE-2019-5736: Escape from Docker and Kubernetes containers to root on host
description here:
https://blog.dragonsector.pl/2019/02/cve-2019-5736-escape-from-docker-and.html
PoC: https://github.com/q3k/cve-2019-5736-poc
Some more links:
https://seclists.org/oss-sec/2019/q1/119
https://access.redhat.com/security/cve/cve-2019-5736
## Impact
It allows to escape from container to root on host when unpatched version of Docker and Kubernetes are used.
This affects a pretty big part of internet, since a lot of services are using Docker and Kubernets these days.
It has also serious impact on cloud services
AWS https://aws.amazon.com/security/security-bulletins/AWS-2019-002/ and GCP https://cloud.google.com/kubernetes-engine/docs/security-bulletins#february-11-2019-runc
https://kubernetes.io/blo
Bugzilla
CVE-2019-12499 firejail: file descriptors command execution
bugzilla·2019-06-04·CVSS 8.1
CVE-2019-12499 [HIGH] CVE-2019-12499 firejail: file descriptors command execution
CVE-2019-12499 firejail: file descriptors command execution
Firejail before 0.9.60 allows truncation (resizing to length 0) of the firejail binary on the host by running exploit code inside a firejail sandbox and having the sandbox terminated. To succeed, certain conditions need to be fulfilled: The jail (with the exploit code inside) needs to be started as root, and it also needs to be terminated as root from the host (either by stopping it ungracefully (e.g., SIGKILL), or by using the --shutdown control command). This is similar to CVE-2019-5736.
Reference:
https://github.com/netblue30/firejail/issues/2401
Discussion:
Created firejail tracking bugs for this issue:
Affects: fedora-all [bug 1716910]
---
This CVE Bugzilla entry is for community support informational purposes only as
Bugzilla
CVE-2019-5736 docker-latest: runc: Execution of malicious containers allows for container escape and access to host filesystem [fedora-all]
bugzilla·2019-02-13·CVSS 8.6
CVE-2019-5736 [HIGH] CVE-2019-5736 docker-latest: runc: Execution of malicious containers allows for container escape and access to host filesystem [fedora-all]
CVE-2019-5736 docker-latest: runc: Execution of malicious containers allows for container escape and access to host filesystem [fedora-all]
This is an automatically created tracking bug! It was created to ensure
that one or more security vulnerabilities are fixed in affected versions
of fedora-all.
For comments that are specific to the vulnerability please use bugs filed
against the "Security Response" product referenced in the "Blocks" field.
For more information see:
http://fedoraproject.org/wiki/Security/TrackingBugs
When submitting as an update, use the fedpkg template provided in the next
comment(s). This will include the bug IDs of this tracking bug as well as
the relevant top-level CVE bugs.
Please also mention the CVE IDs being fixed in the RPM changelog and the
fedpkg commit
Bugzilla
CVE-2019-5736 container-tools:2018.0/runc: Execution of malicious containers allows for container escape and access to host filesystem [fedora-29]
bugzilla·2019-02-11·CVSS 8.6
CVE-2019-5736 [HIGH] CVE-2019-5736 container-tools:2018.0/runc: Execution of malicious containers allows for container escape and access to host filesystem [fedora-29]
CVE-2019-5736 container-tools:2018.0/runc: Execution of malicious containers allows for container escape and access to host filesystem [fedora-29]
This is an automatically created tracking bug! It was created to ensure
that one or more security vulnerabilities are fixed in affected versions
of fedora-29.
For comments that are specific to the vulnerability please use bugs filed
against the "Security Response" product referenced in the "Blocks" field.
For more information see:
http://fedoraproject.org/wiki/Security/TrackingBugs
When submitting as an update, use the fedpkg template provided in the next
comment(s). This will include the bug IDs of this tracking bug as well as
the relevant top-level CVE bugs.
Please also mention the CVE IDs being fixed in the RPM changelog and the
fedpkg c
Bugzilla
CVE-2019-5736 runc: Execution of malicious containers allows for container escape and access to host filesystem [fedora-all]
bugzilla·2019-02-11·CVSS 8.6
CVE-2019-5736 [HIGH] CVE-2019-5736 runc: Execution of malicious containers allows for container escape and access to host filesystem [fedora-all]
CVE-2019-5736 runc: Execution of malicious containers allows for container escape and access to host filesystem [fedora-all]
This is an automatically created tracking bug! It was created to ensure
that one or more security vulnerabilities are fixed in affected versions
of fedora-all.
For comments that are specific to the vulnerability please use bugs filed
against the "Security Response" product referenced in the "Blocks" field.
For more information see:
http://fedoraproject.org/wiki/Security/TrackingBugs
When submitting as an update, use the fedpkg template provided in the next
comment(s). This will include the bug IDs of this tracking bug as well as
the relevant top-level CVE bugs.
Please also mention the CVE IDs being fixed in the RPM changelog and the
fedpkg commit message.
NOTE:
Bugzilla
CVE-2019-5736 docker: runc: Execution of malicious containers allows for container escape and access to host filesystem [fedora-all]
bugzilla·2019-02-11·CVSS 8.6
CVE-2019-5736 [HIGH] CVE-2019-5736 docker: runc: Execution of malicious containers allows for container escape and access to host filesystem [fedora-all]
CVE-2019-5736 docker: runc: Execution of malicious containers allows for container escape and access to host filesystem [fedora-all]
This is an automatically created tracking bug! It was created to ensure
that one or more security vulnerabilities are fixed in affected versions
of fedora-all.
For comments that are specific to the vulnerability please use bugs filed
against the "Security Response" product referenced in the "Blocks" field.
For more information see:
http://fedoraproject.org/wiki/Security/TrackingBugs
When submitting as an update, use the fedpkg template provided in the next
comment(s). This will include the bug IDs of this tracking bug as well as
the relevant top-level CVE bugs.
Please also mention the CVE IDs being fixed in the RPM changelog and the
fedpkg commit message
Bugzilla
CVE-2019-5736 lxc: runc: Execution of malicious containers allows for container escape and access to host filesystem [epel-all]
bugzilla·2019-02-11·CVSS 8.6
CVE-2019-5736 [HIGH] CVE-2019-5736 lxc: runc: Execution of malicious containers allows for container escape and access to host filesystem [epel-all]
CVE-2019-5736 lxc: runc: Execution of malicious containers allows for container escape and access to host filesystem [epel-all]
This is an automatically created tracking bug! It was created to ensure
that one or more security vulnerabilities are fixed in affected versions
of epel-all.
For comments that are specific to the vulnerability please use bugs filed
against the "Security Response" product referenced in the "Blocks" field.
For more information see:
http://fedoraproject.org/wiki/Security/TrackingBugs
When submitting as an update, use the fedpkg template provided in the next
comment(s). This will include the bug IDs of this tracking bug as well as
the relevant top-level CVE bugs.
Please also mention the CVE IDs being fixed in the RPM changelog and the
fedpkg commit message.
NOTE
Bugzilla
CVE-2019-5736 container-tools:2018.0/runc: Execution of malicious containers allows for container escape and access to host filesystem [fedora-all]
bugzilla·2019-02-11·CVSS 8.6
CVE-2019-5736 [HIGH] CVE-2019-5736 container-tools:2018.0/runc: Execution of malicious containers allows for container escape and access to host filesystem [fedora-all]
CVE-2019-5736 container-tools:2018.0/runc: Execution of malicious containers allows for container escape and access to host filesystem [fedora-all]
This is an automatically created tracking bug! It was created to ensure
that one or more security vulnerabilities are fixed in affected versions
of fedora-all.
For comments that are specific to the vulnerability please use bugs filed
against the "Security Response" product referenced in the "Blocks" field.
For more information see:
http://fedoraproject.org/wiki/Security/TrackingBugs
When submitting as an update, use the fedpkg template provided in the next
comment(s). This will include the bug IDs of this tracking bug as well as
the relevant top-level CVE bugs.
Please also mention the CVE IDs being fixed in the RPM changelog and the
fedpkg
Bugzilla
CVE-2019-5736 lxc: runc: Execution of malicious containers allows for container escape and access to host filesystem [fedora-all]
bugzilla·2019-02-11·CVSS 8.6
CVE-2019-5736 [HIGH] CVE-2019-5736 lxc: runc: Execution of malicious containers allows for container escape and access to host filesystem [fedora-all]
CVE-2019-5736 lxc: runc: Execution of malicious containers allows for container escape and access to host filesystem [fedora-all]
This is an automatically created tracking bug! It was created to ensure
that one or more security vulnerabilities are fixed in affected versions
of fedora-all.
For comments that are specific to the vulnerability please use bugs filed
against the "Security Response" product referenced in the "Blocks" field.
For more information see:
http://fedoraproject.org/wiki/Security/TrackingBugs
When submitting as an update, use the fedpkg template provided in the next
comment(s). This will include the bug IDs of this tracking bug as well as
the relevant top-level CVE bugs.
Please also mention the CVE IDs being fixed in the RPM changelog and the
fedpkg commit message.
Bugzilla
CVE-2019-5736 runc: Execution of malicious containers allows for container escape and access to host filesystem
bugzilla·2019-01-10·CVSS 8.6
CVE-2019-5736 [HIGH] CVE-2019-5736 runc: Execution of malicious containers allows for container escape and access to host filesystem
CVE-2019-5736 runc: Execution of malicious containers allows for container escape and access to host filesystem
runc has a vulnerability in the usage of system file descriptors that allows for container escape and access to the host filesystem. An attacker can exploit this by convincing users to run malicious or modified containers on their systems.
Discussion:
Will write a nice blog on this when it goes public.
---
Created attachment 1520029
updates the vendored library needed for runc to access memfd_create
---
Created attachment 1520030
runc to use memfd_create
---
Acknowledgments:
Name: the Open Containers Security Team
Upstream: Adam Iwaniuk, Borys Popławski
---
Created container-tools:2017.0/runc tracking bugs for this issue:
Affects: fedora-all [bug 1674489]
Created c
http://lists.opensuse.org/opensuse-security-announce/2019-03/msg00044.htmlhttp://lists.opensuse.org/opensuse-security-announce/2019-04/msg00074.htmlhttp://lists.opensuse.org/opensuse-security-announce/2019-04/msg00091.htmlhttp://lists.opensuse.org/opensuse-security-announce/2019-05/msg00060.htmlhttp://lists.opensuse.org/opensuse-security-announce/2019-05/msg00073.htmlhttp://lists.opensuse.org/opensuse-security-announce/2019-06/msg00011.htmlhttp://lists.opensuse.org/opensuse-security-announce/2019-06/msg00015.htmlhttp://lists.opensuse.org/opensuse-security-announce/2019-08/msg00084.htmlhttp://lists.opensuse.org/opensuse-security-announce/2019-10/msg00007.htmlhttp://lists.opensuse.org/opensuse-security-announce/2019-10/msg00029.htmlhttp://packetstormsecurity.com/files/163339/Docker-Container-Escape.htmlhttp://packetstormsecurity.com/files/165197/Docker-runc-Command-Execution-Proof-Of-Concept.htmlhttp://www.openwall.com/lists/oss-security/2019/03/23/1http://www.openwall.com/lists/oss-security/2019/06/28/2http://www.openwall.com/lists/oss-security/2019/07/06/3http://www.openwall.com/lists/oss-security/2019/07/06/4http://www.openwall.com/lists/oss-security/2019/10/24/1http://www.openwall.com/lists/oss-security/2019/10/29/3http://www.openwall.com/lists/oss-security/2024/01/31/6http://www.openwall.com/lists/oss-security/2024/02/01/1http://www.openwall.com/lists/oss-security/2024/02/02/3http://www.securityfocus.com/bid/106976https://access.redhat.com/errata/RHSA-2019:0303https://access.redhat.com/errata/RHSA-2019:0304https://access.redhat.com/errata/RHSA-2019:0401https://access.redhat.com/errata/RHSA-2019:0408https://access.redhat.com/errata/RHSA-2019:0975https://access.redhat.com/security/cve/cve-2019-5736https://access.redhat.com/security/vulnerabilities/runcescapehttps://aws.amazon.com/security/security-bulletins/AWS-2019-002/https://azure.microsoft.com/en-us/updates/cve-2019-5736-and-runc-vulnerability/https://azure.microsoft.com/en-us/updates/iot-edge-fix-cve-2019-5736/https://blog.dragonsector.pl/2019/02/cve-2019-5736-escape-from-docker-and.htmlhttps://brauner.github.io/2019/02/12/privileged-containers.htmlhttps://bugzilla.suse.com/show_bug.cgi?id=1121967https://cloud.google.com/kubernetes-engine/docs/security-bulletins#february-11-2019-runchttps://github.com/Frichetten/CVE-2019-5736-PoChttps://github.com/docker/docker-ce/releases/tag/v18.09.2https://github.com/opencontainers/runc/commit/0a8e4117e7f715d5fbeef398405813ce8e88558bhttps://github.com/opencontainers/runc/commit/6635b4f0c6af3810594d2770f662f34ddc15b40dhttps://github.com/q3k/cve-2019-5736-pochttps://github.com/rancher/runc-cvehttps://kubernetes.io/blog/2019/02/11/runc-and-cve-2019-5736/https://lists.apache.org/thread.html/24e54e3c6b2259e3903b6b8fe26896ac649c481ea99c5739468c92a3%40%3Cdev.dlab.apache.org%3Ehttps://lists.apache.org/thread.html/a258757af84c5074dc7bf932622020fd4f60cef65a84290380386706%40%3Cuser.mesos.apache.org%3Ehttps://lists.apache.org/thread.html/a585f64d14c31ab393b90c5f17e41d9765a1a17eec63856ce750af46%40%3Cdev.dlab.apache.org%3Ehttps://lists.apache.org/thread.html/acacf018c12636e41667e94ac0a1e9244e887eef2debdd474640aa6e%40%3Cdev.dlab.apache.org%3Ehttps://lists.apache.org/thread.html/b162dd624dc088cd634292f0402282a1d1d0ce853baeae8205bc033c%40%3Cdev.mesos.apache.org%3Ehttps://lists.apache.org/thread.html/rc494623986d76593873ce5a40dd69cb3629400d10750d5d7e96b8587%40%3Cdev.dlab.apache.org%3Ehttps://lists.apache.org/thread.html/rf1bbc0ea4a9f014cf94df9a12a6477d24a27f52741dbc87f2fd52ff2%40%3Cissues.geode.apache.org%3Ehttps://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/DLC52IOJN6IQJWJ6CUI6AIUP6GVVG2QP/https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/EGZKRCKI3Y7FMADO2MENMT4TU24QGHFR/https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/SWFJGIPYAAAMVSWWI3QWYXGA3ZBU2H4W/https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/V6A4OSFM5GGOWW4ECELV5OHX2XRAUSPH/https://security.gentoo.org/glsa/202003-21https://security.netapp.com/advisory/ntap-20190307-0008/https://softwaresupport.softwaregrp.com/document/-/facetsearch/document/KM03410944https://support.hpe.com/hpsc/doc/public/display?docLocale=en_US&docId=emr_na-hpesbhf03913en_ushttps://support.mesosphere.com/s/article/Known-Issue-Container-Runtime-Vulnerability-MSPH-2019-0003https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20190215-runchttps://usn.ubuntu.com/4048-1/https://www.exploit-db.com/exploits/46359/https://www.exploit-db.com/exploits/46369/https://www.openwall.com/lists/oss-security/2019/02/11/2https://www.synology.com/security/advisory/Synology_SA_19_06https://www.twistlock.com/2019/02/11/how-to-mitigate-cve-2019-5736-in-runc-and-docker/http://lists.opensuse.org/opensuse-security-announce/2019-03/msg00044.htmlhttp://lists.opensuse.org/opensuse-security-announce/2019-04/msg00074.htmlhttp://lists.opensuse.org/opensuse-security-announce/2019-04/msg00091.htmlhttp://lists.opensuse.org/opensuse-security-announce/2019-05/msg00060.htmlhttp://lists.opensuse.org/opensuse-security-announce/2019-05/msg00073.htmlhttp://lists.opensuse.org/opensuse-security-announce/2019-06/msg00011.htmlhttp://lists.opensuse.org/opensuse-security-announce/2019-06/msg00015.htmlhttp://lists.opensuse.org/opensuse-security-announce/2019-08/msg00084.htmlhttp://lists.opensuse.org/opensuse-security-announce/2019-10/msg00007.htmlhttp://lists.opensuse.org/opensuse-security-announce/2019-10/msg00029.htmlhttp://packetstormsecurity.com/files/163339/Docker-Container-Escape.htmlhttp://packetstormsecurity.com/files/165197/Docker-runc-Command-Execution-Proof-Of-Concept.htmlhttp://www.openwall.com/lists/oss-security/2019/03/23/1http://www.openwall.com/lists/oss-security/2019/06/28/2http://www.openwall.com/lists/oss-security/2019/07/06/3http://www.openwall.com/lists/oss-security/2019/07/06/4http://www.openwall.com/lists/oss-security/2019/10/24/1http://www.openwall.com/lists/oss-security/2019/10/29/3http://www.openwall.com/lists/oss-security/2024/01/31/6http://www.openwall.com/lists/oss-security/2024/02/01/1http://www.openwall.com/lists/oss-security/2024/02/02/3http://www.securityfocus.com/bid/106976https://access.redhat.com/errata/RHSA-2019:0303https://access.redhat.com/errata/RHSA-2019:0304https://access.redhat.com/errata/RHSA-2019:0401https://access.redhat.com/errata/RHSA-2019:0408https://access.redhat.com/errata/RHSA-2019:0975https://access.redhat.com/security/cve/cve-2019-5736https://access.redhat.com/security/vulnerabilities/runcescapehttps://aws.amazon.com/security/security-bulletins/AWS-2019-002/https://azure.microsoft.com/en-us/updates/cve-2019-5736-and-runc-vulnerability/https://azure.microsoft.com/en-us/updates/iot-edge-fix-cve-2019-5736/https://blog.dragonsector.pl/2019/02/cve-2019-5736-escape-from-docker-and.htmlhttps://brauner.github.io/2019/02/12/privileged-containers.html
+ 32 more references
2019-02-11
Published
Exploited in the wild