Filtered by vendor Mirantis
Subscriptions
Total
7 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2025-54388 | 3 Docker, Mirantis, Mobyproject | 4 Engine, Moby, Mirantis Container Runtime and 1 more | 2025-07-31 | 5.2 Medium |
| Moby is an open source container framework developed by Docker Inc. that is distributed as Docker Engine, Mirantis Container Runtime, and various other downstream projects/products. In versions 28.2.0 through 28.3.2, when the firewalld service is reloaded it removes all iptables rules including those created by Docker. While Docker should automatically recreate these rules, versions before 28.3.3 fail to recreate the specific rules that block external access to containers. This means that after a firewalld reload, containers with ports published to localhost (like 127.0.0.1:8080) become accessible from remote machines that have network routing to the Docker bridge, even though they should only be accessible from the host itself. The vulnerability only affects explicitly published ports - unpublished ports remain protected. This issue is fixed in version 28.3.3. | ||||
| CVE-2025-54410 | 3 Docker, Mirantis, Mobyproject | 4 Engine, Moby, Mirantis Container Runtime and 1 more | 2025-07-31 | 3.3 Low |
| Moby is an open source container framework developed by Docker Inc. that is distributed as Docker Engine, Mirantis Container Runtime, and various other downstream projects/products. A firewalld vulnerability affects Moby releases before 28.0.0. When firewalld reloads, Docker fails to re-create iptables rules that isolate bridge networks, allowing any container to access all ports on any other container across different bridge networks on the same host. This breaks network segmentation between containers that should be isolated, creating significant risk in multi-tenant environments. Only containers in --internal networks remain protected. Workarounds include reloading firewalld and either restarting the docker daemon, re-creating bridge networks, or using rootless mode. Maintainers anticipate a fix for this issue in version 25.0.13. | ||||
| CVE-2022-0484 | 1 Mirantis | 1 Container Cloud Lens Extension | 2024-11-21 | 8.8 High |
| Lack of validation of URLs causes Mirantis Container Cloud Lens Extension before v3.1.1 to open external programs other than the default browser to perform sign on to a new cluster. An attacker could host a webserver which serves a malicious Mirantis Container Cloud configuration file and induce the victim to add a new cluster via its URL. This issue affects: Mirantis Mirantis Container Cloud Lens Extension v3 versions prior to v3.1.1. | ||||
| CVE-2022-0270 | 1 Mirantis | 1 Bored-agent | 2024-11-21 | 8.8 High |
| Prior to v0.6.1, bored-agent failed to sanitize incoming kubernetes impersonation headers allowing a user to override assigned user name and groups. | ||||
| CVE-2021-44458 | 2 Linux, Mirantis | 2 Linux Kernel, Lens | 2024-11-21 | 8.3 High |
| Linux users running Lens 5.2.6 and earlier could be compromised by visiting a malicious website. The malicious website could make websocket connections from the victim's browser to Lens and so operate the local terminal feature. This would allow the attacker to execute arbitrary commands as the Lens user. | ||||
| CVE-2021-23218 | 1 Mirantis | 1 Mirantis Container Runtime | 2024-11-21 | 5.3 Medium |
| When running with FIPS mode enabled, Mirantis Container Runtime 20.10.8 leaks memory during TLS Handshakes which could be abused to cause a denial of service. | ||||
| CVE-2021-23154 | 1 Mirantis | 1 Lens | 2024-11-21 | 6.3 Medium |
| In Lens prior to 5.3.4, custom helm chart configuration creates helm commands from string concatenation of provided arguments which are then executed in the user's shell. Arguments can be provided which cause arbitrary shell commands to run on the system. | ||||
Page 1 of 1.