{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/docker/docker"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.12.0"
            },
            {
              "fixed": "20.10.24"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/docker/docker"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "23.0.0"
            },
            {
              "fixed": "23.0.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-28841"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-311",
      "CWE-636"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-04-04T21:12:20Z",
    "nvd_published_at": "2023-04-04T22:15:00Z",
    "severity": "MODERATE"
  },
  "details": "[Moby](https://mobyproject.org/) is an open source container framework developed by Docker Inc. that is distributed as Docker, Mirantis Container Runtime, and various other downstream projects/products. The Moby daemon component (`dockerd`), which is developed as [moby/moby](https://github.com/moby/moby) is commonly referred to as *Docker*.\n\nSwarm Mode, which is compiled in and delivered by default in `dockerd` and is thus present in most major Moby downstreams, is a simple, built-in container orchestrator that is implemented through a combination of [SwarmKit](https://github.com/moby/swarmkit) and supporting network code.\n\nThe `overlay` network driver is a core feature of Swarm Mode, providing isolated virtual LANs that allow communication between containers and services across the cluster. This driver is an implementation/user of [VXLAN](https://en.wikipedia.org/wiki/Virtual_Extensible_LAN), which encapsulates link-layer (Ethernet) frames in UDP datagrams that tag the frame with a VXLAN Network ID (VNI) that identifies the originating overlay network. In addition, the overlay network driver supports an optional, off-by-default encrypted mode, which is especially useful when VXLAN packets traverses an untrusted network between nodes.\n\nEncrypted overlay networks function by encapsulating the VXLAN datagrams through the use of the [IPsec Encapsulating Security Payload](https://en.wikipedia.org/wiki/IPsec#Encapsulating_Security_Payload) protocol in [Transport mode](https://en.wikipedia.org/wiki/IPsec#Transport_mode). By deploying IPSec encapsulation, encrypted overlay networks gain the additional properties of source authentication through cryptographic proof, data integrity through check-summing, and confidentiality through encryption.\n\nWhen setting an endpoint up on an encrypted overlay network, Moby installs three [iptables](https://www.netfilter.org/projects/iptables/index.html) (Linux kernel firewall) rules that enforce both incoming and outgoing IPSec. These rules rely on the `u32` iptables extension provided by the `xt_u32` kernel module to directly filter on a VXLAN packet\u0027s VNI field, so that IPSec guarantees can be enforced on encrypted overlay networks without interfering with other overlay networks or other users of VXLAN.\n\nAn [iptables rule](https://github.com/moby/libnetwork/blob/d9fae4c73daf76c3b0f77e14b45b8bf612ba764d/drivers/overlay/encryption.go#L205-L207) designates outgoing VXLAN datagrams with a VNI that corresponds to an encrypted overlay network for IPsec encapsulation.\n\nOn Red Hat Enterprise Linux and derivatives such as CentOS and Rocky, the `xt_u32` module has been:\n* [moved to the kernel-modules-extra package and no longer installed by default in RHEL 8.3](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/8.3_release_notes/rhel-8-3-0-release#technology-preview_networking)\n* [officially deprecated in RHEL 8.6](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/8.6_release_notes/deprecated_functionality#deprecated-functionality_networking)\n* [removed completely in RHEL 9](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/considerations_in_adopting_rhel_9/assembly_networking_considerations-in-adopting-rhel-9#ref_firewall-networking_assembly_networking)\n\nThis rule is not created when `xt_u32` is unavailable, even though the container is still attached to the network.\n\n## Impact\nEncrypted overlay networks on affected platforms silently transmit unencrypted data. As a result, `overlay` networks may appear to be functional, passing traffic as expected, but without any of the expected confidentiality or data integrity guarantees.\n\nIt is possible for an attacker sitting in a trusted position on the network to read all of the application traffic that is moving across the overlay network, resulting in unexpected secrets or user data disclosure. Thus, because many database protocols, internal APIs, etc. are not protected by a second layer of encryption, a user may rely on Swarm encrypted overlay networks to provide confidentiality, which due to this vulnerability is no longer guaranteed.\n\n## Patches\nPatches are available in Moby releases 23.0.3, and 20.10.24. As Mirantis Container Runtime\u0027s 20.10 releases are numbered differently, users of that platform should update to 20.10.16.\n\n## Workarounds\n* Close the VXLAN port (by default, UDP port 4789) to outgoing traffic at the Internet boundary (see [GHSA-vwm3-crmr-xfxw](https://github.com/moby/moby/security/advisories/GHSA-vwm3-crmr-xfxw)) in order to prevent unintentionally leaking unencrypted traffic over the Internet.\n* Ensure that the `xt_u32` kernel module is available on all nodes of the Swarm cluster.\n\n## Background\n* [#43382 ](https://github.com/moby/moby/issues/43382)partially discussed this concern, but did not consider the security implications.\n* Mirantis FIELD-5788 essentially duplicates [#43382](https://github.com/moby/moby/issues/43382), and was created six months earlier; it similarly overlooked the security implications.\n* [#45118](https://github.com/moby/moby/pull/45118) is the ancestor of the final patches, and was where the security implications were discovered.\n\n## Related\n* [CVE-2023-28840: Encrypted overlay network may be unauthenticated](https://github.com/moby/moby/security/advisories/GHSA-232p-vwff-86mp)\n* [CVE-2023-28842: Encrypted overlay network with a single endpoint is unauthenticated](https://github.com/moby/moby/security/advisories/GHSA-6wrf-mxfj-pf5p)\n* [GHSA-vwm3-crmr-xfxw: The Swarm VXLAN port may be exposed to attack due to ambiguous documentation](https://github.com/moby/moby/security/advisories/GHSA-vwm3-crmr-xfxw)\n* [GHSA-gvm4-2qqg-m333: Security issues in encrypted overlay networks](https://github.com/moby/libnetwork/security/advisories/GHSA-gvm4-2qqg-m333) (libnetwork)",
  "id": "GHSA-33pg-m6jh-5237",
  "modified": "2023-04-05T23:16:54Z",
  "published": "2023-04-04T21:12:20Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/moby/libnetwork/security/advisories/GHSA-gvm4-2qqg-m333"
    },
    {
      "type": "WEB",
      "url": "https://github.com/moby/moby/security/advisories/GHSA-232p-vwff-86mp"
    },
    {
      "type": "WEB",
      "url": "https://github.com/moby/moby/security/advisories/GHSA-33pg-m6jh-5237"
    },
    {
      "type": "WEB",
      "url": "https://github.com/moby/moby/security/advisories/GHSA-6wrf-mxfj-pf5p"
    },
    {
      "type": "WEB",
      "url": "https://github.com/moby/moby/security/advisories/GHSA-vwm3-crmr-xfxw"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-28841"
    },
    {
      "type": "WEB",
      "url": "https://github.com/moby/moby/issues/43382"
    },
    {
      "type": "WEB",
      "url": "https://github.com/moby/moby/pull/45118"
    },
    {
      "type": "WEB",
      "url": "https://github.com/moby/libnetwork/blob/d9fae4c73daf76c3b0f77e14b45b8bf612ba764d/drivers/overlay/encryption.go#L205-L207"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/moby/moby"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Docker Swarm encrypted overlay network traffic may be unencrypted"
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/sirupsen/logrus"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.8.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/sirupsen/logrus"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.9.0"
            },
            {
              "fixed": "1.9.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "1.9.0"
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/sirupsen/logrus"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.9.2"
            },
            {
              "fixed": "1.9.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "1.9.2"
      ]
    }
  ],
  "aliases": [
    "CVE-2025-65637"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-12-05T02:27:47Z",
    "nvd_published_at": "2025-12-04T19:16:05Z",
    "severity": "HIGH"
  },
  "details": "A denial-of-service vulnerability exists in github.com/sirupsen/logrus when using Entry.Writer() to log a single-line payload larger than 64KB without newline characters. Due to limitations in the internal bufio.Scanner, the read fails with \"token too long\" and the writer pipe is closed, leaving Writer() unusable and causing application unavailability (DoS). This affects versions \u003c 1.8.3, 1.9.0, and 1.9.2. The issue is fixed in 1.8.3, 1.9.1, and 1.9.3+, where the input is chunked and the writer continues to function even if an error is logged.",
  "id": "GHSA-4f99-4q7p-p3gh",
  "modified": "2026-01-21T16:20:52Z",
  "published": "2025-12-04T21:31:04Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-65637"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sirupsen/logrus/issues/1370"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sirupsen/logrus/pull/1376"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sirupsen/logrus/commit/6acd903758687c4a3db3c11701e6c414fcf1c1f7"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mjuanxd/logrus-dos-poc"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mjuanxd/logrus-dos-poc/blob/main/README.md"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/sirupsen/logrus"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sirupsen/logrus/releases/tag/v1.8.3"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sirupsen/logrus/releases/tag/v1.9.1"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sirupsen/logrus/releases/tag/v1.9.3"
    },
    {
      "type": "WEB",
      "url": "https://security.snyk.io/vuln/SNYK-GOLANG-GITHUBCOMSIRUPSENLOGRUS-5564391"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Logrus is vulnerable to DoS when using Entry.Writer()"
}

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 25.0.12"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/docker/docker"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "25.0.13"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/docker/docker"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "26.0.0-rc1"
            },
            {
              "fixed": "28.0.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-54410"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-909"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-07-29T19:56:25Z",
    "nvd_published_at": "2025-07-30T14:15:28Z",
    "severity": "LOW"
  },
  "details": "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. The Moby daemon component (dockerd), which is developed as [moby/moby](https://github.com/moby/moby) is commonly referred to as Docker, or Docker Engine.\n\nFirewalld is a daemon used by some Linux distributions to provide a dynamically managed firewall. When Firewalld is running, Docker uses its iptables backend to create rules, including rules to isolate containers in one bridge network from containers in other bridge networks.\n\n### Impact\n\nThe iptables rules created by Docker are removed when firewalld is reloaded using, for example \"firewall-cmd --reload\", \"killall -HUP firewalld\", or \"systemctl reload firewalld\".\n\nWhen that happens, Docker must re-create the rules. However, in affected versions of Docker, the iptables rules that isolate containers in different bridge networks from each other are not re-created.\n\nOnce these rules have been removed, containers have access to any port, on any container, in any non-internal bridge network, running on the Docker host.\n\nContainers running in networks created with `--internal` or equivalent have no access to other networks. Containers that are only connected to these networks remain isolated after a firewalld reload.\n\nWhere Docker Engine is not running in the host\u0027s network namespace, it is unaffected. Including, for example, Rootless Mode, and Docker Desktop.\n\n### Patches\n\nMoby releases 28.0.0 and newer are not affected. A fix is available in moby release 25.0.13.\n\n### Workarounds\nAfter reloading firewalld, either:\n- Restart the docker daemon,\n- Re-create bridge networks, or\n- Use rootless mode.\n\n### References\nhttps://firewalld.org/\nhttps://firewalld.org/documentation/howto/reload-firewalld.html",
  "id": "GHSA-4vq8-7jfc-9cvp",
  "modified": "2026-03-27T17:37:52Z",
  "published": "2025-07-29T19:56:25Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/moby/moby/security/advisories/GHSA-4vq8-7jfc-9cvp"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-54410"
    },
    {
      "type": "WEB",
      "url": "https://github.com/moby/moby/pull/49443"
    },
    {
      "type": "WEB",
      "url": "https://github.com/moby/moby/pull/49728"
    },
    {
      "type": "WEB",
      "url": "https://firewalld.org/documentation/howto/reload-firewalld.html"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/moby/moby"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Moby firewalld reload removes bridge network isolation"
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/docker/docker"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.12.0"
            },
            {
              "fixed": "20.10.24"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/docker/docker"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "23.0.0"
            },
            {
              "fixed": "23.0.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-28842"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-420",
      "CWE-636"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-04-04T21:11:24Z",
    "nvd_published_at": "2023-04-04T22:15:00Z",
    "severity": "MODERATE"
  },
  "details": "[Moby](https://mobyproject.org/) is an open source container framework developed by Docker Inc. that is distributed as Docker, Mirantis Container Runtime, and various other downstream projects/products. The Moby daemon component (`dockerd`), which is developed as [moby/moby](https://github.com/moby/moby) is commonly referred to as *Docker*.\n\nSwarm Mode, which is compiled in and delivered by default in `dockerd` and is thus present in most major Moby downstreams, is a simple, built-in container orchestrator that is implemented through a combination of [SwarmKit](https://github.com/moby/swarmkit) and supporting network code.\n\nThe `overlay` network driver is a core feature of Swarm Mode, providing isolated virtual LANs that allow communication between containers and services across the cluster. This driver is an implementation/user of [VXLAN](https://en.wikipedia.org/wiki/Virtual_Extensible_LAN), which encapsulates link-layer (Ethernet) frames in UDP datagrams that tag the frame with a VXLAN Network ID (VNI) that identifies the originating overlay network. In addition, the overlay network driver supports an optional, off-by-default encrypted mode, which is especially useful when VXLAN packets traverses an untrusted network between nodes.\n\nEncrypted overlay networks function by encapsulating the VXLAN datagrams through the use of the [IPsec Encapsulating Security Payload](https://en.wikipedia.org/wiki/IPsec#Encapsulating_Security_Payload) protocol in [Transport mode](https://en.wikipedia.org/wiki/IPsec#Transport_mode). By deploying IPSec encapsulation, encrypted overlay networks gain the additional properties of source authentication through cryptographic proof, data integrity through check-summing, and confidentiality through encryption.\n\nWhen setting an endpoint up on an encrypted overlay network, Moby installs three [iptables](https://www.netfilter.org/projects/iptables/index.html) (Linux kernel firewall) rules that enforce both incoming and outgoing IPSec. These rules rely on the `u32` iptables extension provided by the `xt_u32` kernel module to directly filter on a VXLAN packet\u0027s VNI field, so that IPSec guarantees can be enforced on encrypted overlay networks without interfering with other overlay networks or other users of VXLAN.\n\nThe `overlay` driver dynamically and lazily defines the kernel configuration for the VXLAN network on each node as containers are attached and detached. Routes and encryption parameters are only defined for destination nodes that participate in the network. The iptables rules that prevent encrypted overlay networks from accepting unencrypted packets are not created until a peer is available with which to communicate.\n\n## Impact\nEncrypted overlay networks silently accept cleartext VXLAN datagrams that are tagged with the VNI of an encrypted overlay network. As a result, it is possible to inject arbitrary Ethernet frames into the encrypted overlay network by encapsulating them in VXLAN datagrams. The implications of this can be quite dire, and [GHSA-vwm3-crmr-xfxw](https://github.com/moby/moby/security/advisories/GHSA-vwm3-crmr-xfxw) should be referenced for a deeper exploration.\n\n## Patches\nPatches are available in Moby releases 23.0.3, and 20.10.24. As Mirantis Container Runtime\u0027s 20.10 releases are numbered differently, users of that platform should update to 20.10.16.\n\n## Workarounds\n* In multi-node clusters, deploy a global \u2018pause\u2019 container for each encrypted overlay network, on every node. For example, use the `registry.k8s.io/pause` image and a `--mode global` service.\n* For a single-node cluster, do not use overlay networks of any sort. Bridge networks provide the same connectivity on a single node and have no multi-node features.\nThe Swarm ingress feature is implemented using an overlay network, but can be disabled by publishing ports in `host` mode instead of `ingress` mode (allowing the use of an external load balancer), and removing the `ingress` network.\n* If encrypted overlay networks are in exclusive use, block UDP port 4789 from traffic that has not been validated by IPSec. For example, `iptables -A INPUT -m udp \u2014-dport 4789 -m policy --dir in --pol none -j DROP`.\n\n## Background\n* This issue was discovered while characterizing and mitigating [CVE-2023-28840](https://github.com/moby/moby/security/advisories/GHSA-232p-vwff-86mp) and [CVE-2023-28841](https://github.com/moby/moby/security/advisories/GHSA-33pg-m6jh-5237).\n\n## Related\n* [CVE-2023-28841: Encrypted overlay network traffic may be unencrypted](https://github.com/moby/moby/security/advisories/GHSA-33pg-m6jh-5237)\n* [CVE-2023-28840: Encrypted overlay network may be unauthenticated](https://github.com/moby/moby/security/advisories/GHSA-232p-vwff-86mp)\n* [GHSA-vwm3-crmr-xfxw: The Swarm VXLAN port may be exposed to attack due to ambiguous documentation](https://github.com/moby/moby/security/advisories/GHSA-vwm3-crmr-xfxw)\n* [GHSA-gvm4-2qqg-m333: Security issues in encrypted overlay networks](https://github.com/moby/libnetwork/security/advisories/GHSA-gvm4-2qqg-m333) (libnetwork)",
  "id": "GHSA-6wrf-mxfj-pf5p",
  "modified": "2023-04-05T23:15:38Z",
  "published": "2023-04-04T21:11:24Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/moby/libnetwork/security/advisories/GHSA-gvm4-2qqg-m333"
    },
    {
      "type": "WEB",
      "url": "https://github.com/moby/moby/security/advisories/GHSA-232p-vwff-86mp"
    },
    {
      "type": "WEB",
      "url": "https://github.com/moby/moby/security/advisories/GHSA-33pg-m6jh-5237"
    },
    {
      "type": "WEB",
      "url": "https://github.com/moby/moby/security/advisories/GHSA-6wrf-mxfj-pf5p"
    },
    {
      "type": "WEB",
      "url": "https://github.com/moby/moby/security/advisories/GHSA-vwm3-crmr-xfxw"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-28842"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/moby/moby"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Docker Swarm encrypted overlay network with a single endpoint is unauthenticated"
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/docker/distribution"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.8.2-beta.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-2253"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-475",
      "CWE-770"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-05-11T20:37:54Z",
    "nvd_published_at": "2023-06-06T20:15:12Z",
    "severity": "HIGH"
  },
  "details": "### Impact\n\nSystems that run `distribution` built after a specific commit running on memory-restricted environments can suffer from denial of service by a crafted malicious `/v2/_catalog` API endpoint request. \n\n### Patches\n\nUpgrade to at least 2.8.2-beta.1 if you are running `v2.8.x` release. If you use the code from the main branch, update at least to the commit after [f55a6552b006a381d9167e328808565dd2bf77dc](https://github.com/distribution/distribution/commit/f55a6552b006a381d9167e328808565dd2bf77dc).\n\n### Workarounds\n\nThere is no way to work around this issue without patching. Restrict access to the affected API endpoint: see the recommendations section.\n\n### References\n\n`/v2/_catalog` endpoint accepts a parameter to control the maximum amount of records returned (query string: `n`).\n\nWhen not given the default `n=100` is used.  The server trusts that `n` has an acceptable value, however when using a \nmaliciously large value, it allocates an array/slice of `n` of strings before filling the slice with data.\n\nThis behaviour was introduced ~7yrs ago [1].\n\n### Recommendation\n\nThe `/v2/_catalog` endpoint was designed specifically to do registry syncs with search or other API systems. Such an endpoint would create a lot of load on the backend system, due to overfetch required to serve a request in certain implementations.\n\nBecause of this, we strongly recommend keeping this API endpoint behind heightened privilege and avoiding leaving it exposed to the internet.\n\n###  For more information\n\nIf you have any questions or comments about this advisory:\n* Open an issue in [distribution repository](https://github.com/distribution/distribution)\n* Email us at [cncf-distribution-security@lists.cncf.io](mailto:cncf-distribution-security@lists.cncf.io)\n\n[1] [faulty commit](https://github.com/distribution/distribution/blob/b7e26bac741c76cb792f8e14c41a2163b5dae8df/registry/handlers/catalog.go#L45)",
  "id": "GHSA-hqxw-f8mx-cpmw",
  "modified": "2023-05-11T20:37:54Z",
  "published": "2023-05-11T20:37:54Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/distribution/distribution/security/advisories/GHSA-hqxw-f8mx-cpmw"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-2253"
    },
    {
      "type": "WEB",
      "url": "https://github.com/distribution/distribution/commit/f55a6552b006a381d9167e328808565dd2bf77dc"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2189886"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/distribution/distribution"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2023/06/msg00035.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "distribution catalog API endpoint can lead to OOM via malicious user input"
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/docker/docker"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "24.0.0"
            },
            {
              "fixed": "24.0.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/docker/docker"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "21.0.0"
            },
            {
              "fixed": "23.0.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/docker/docker"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "20.10.27"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": true,
    "github_reviewed_at": "2023-10-30T15:25:44Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "Intel\u0027s RAPL (Running Average Power Limit) feature, introduced by the Sandy Bridge microarchitecture, provides software insights into hardware energy consumption. To facilitate this, Intel introduced the powercap framework in Linux kernel 3.13, which reads values via relevant MSRs (model specific registers) and provides unprivileged userspace access via `sysfs`. As RAPL is an interface to access a hardware feature, it is only available when running on bare metal with the module compiled into the kernel.\n\nBy 2019, it was realized that in some cases unprivileged access to RAPL readings could be exploited as a power-based side-channel against security features including AES-NI (potentially inside a SGX enclave) and KASLR (kernel address space layout randomization). Also known as the [PLATYPUS attack](https://platypusattack.com/), Intel assigned [CVE-2020-8694](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-8694) and [CVE-2020-8695](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-8695), and AMD assigned [CVE-2020-12912](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-12912).\n\nSeveral mitigations were applied; Intel reduced the sampling resolution via a microcode update, and the Linux kernel [prevents access by non-root users](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=949dd0104c496fa7c14991a23c03c62e44637e71) since 5.10. However, this kernel-based mitigation does not apply to many container-based scenarios:\n* Unless using user namespaces, root inside a container has the same level of privilege as root outside the container, but with a slightly more narrow view of the system\n* `sysfs` is mounted inside containers read-only; however only read access is needed to carry out this attack on an unpatched CPU\n\nWhile this is not a direct vulnerability in container runtimes, defense in depth and safe defaults are valuable and preferred, especially as this poses a risk to multi-tenant container environments running directly on affected hardware. This is provided by masking `/sys/devices/virtual/powercap` in the default mount configuration, and adding an additional set of rules to deny it in the default AppArmor profile.\n\nWhile `sysfs` is not the only way to read from the RAPL subsystem, other ways of accessing it require additional capabilities such as `CAP_SYS_RAWIO` which is not available to containers by default, or `perf` paranoia level less than 1, which is a non-default kernel tunable.\n\n## References\n\n* https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-8694\n* https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-8695\n* https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-12912\n* https://platypusattack.com/\n* https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=949dd0104c496fa7c14991a23c03c62e44637e71\n* https://web.eece.maine.edu/~vweaver/projects/rapl/",
  "id": "GHSA-jq35-85cj-fj4p",
  "modified": "2023-10-30T15:25:44Z",
  "published": "2023-10-30T15:25:44Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/moby/moby/security/advisories/GHSA-jq35-85cj-fj4p"
    },
    {
      "type": "WEB",
      "url": "https://github.com/moby/moby/commit/48ebe353e49a9def5e6679f6e386b0efb1c95f0e"
    },
    {
      "type": "WEB",
      "url": "https://github.com/moby/moby/commit/81ebe71275768629689a23bc3bca34b3b374a6a6"
    },
    {
      "type": "WEB",
      "url": "https://github.com/moby/moby/commit/c9ccbfad11a60e703e91b6cca4f48927828c7e35"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/moby/moby"
    },
    {
      "type": "WEB",
      "url": "https://github.com/moby/moby/releases/tag/v20.10.27"
    },
    {
      "type": "WEB",
      "url": "https://github.com/moby/moby/releases/tag/v23.0.8"
    },
    {
      "type": "WEB",
      "url": "https://github.com/moby/moby/releases/tag/v24.0.7"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [],
  "summary": "/sys/devices/virtual/powercap accessible by default to containers"
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/docker/docker"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "26.0.0-rc1"
            },
            {
              "fixed": "26.0.0-rc3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/docker/docker"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "25.0.0"
            },
            {
              "fixed": "25.0.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/docker/docker"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "23.0.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-29018"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-669"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-03-20T17:59:52Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "Moby is an open source container framework originally developed by Docker Inc. as Docker. It is a key component of Docker Engine, Docker Desktop, and other distributions of container tooling or runtimes. As a batteries-included container runtime, Moby comes with a built-in networking implementation that enables communication between containers, and between containers and external resources.\n\nMoby\u0027s networking implementation allows for creating and using many networks, each with their own subnet and gateway. This feature is frequently referred to as custom networks, as each network can have a different driver, set of parameters, and thus behaviors. When creating a network, the `--internal` flag is used to designate a network as _internal_. The `internal` attribute in a docker-compose.yml file may also be used to mark a network _internal_, and other API clients may specify the `internal` parameter as well.\n\nWhen containers with networking are created, they are assigned unique network interfaces and IP addresses (typically from a non-routable [RFC 1918](https://datatracker.ietf.org/doc/html/rfc1918) subnet). The root network namespace (hereafter referred to as the \u0027host\u0027) serves as a router for non-internal networks, with a gateway IP that provides SNAT/DNAT to/from container IPs.\n\nContainers on an _internal_ network may communicate between each other, but are precluded from communicating with any networks the host has access to (LAN or WAN) as no default route is configured, and firewall rules are set up to drop all outgoing traffic. Communication with the gateway IP address (and thus appropriately configured host services) is possible, and the host may communicate with any container IP directly.\n\nIn addition to configuring the Linux kernel\u0027s various networking features to enable container networking, `dockerd` directly provides some services to container networks. Principal among these is serving as a resolver, enabling service discovery (looking up other containers on the network by name), and resolution of names from an upstream resolver.\n\nWhen a DNS request for a name that does not correspond to a container is received, the request is forwarded to the configured upstream resolver (by default, the host\u0027s configured resolver). This request is made from the container network namespace: the level of access and routing of traffic is the same as if the request was made by the container itself.\n\nAs a consequence of this design, containers solely attached to _internal_ network(s) will be unable to resolve names using the upstream resolver, as the container itself is unable to communicate with that nameserver. Only the names of containers also attached to the internal network are able to be resolved.\n\nMany systems will run a local forwarding DNS resolver, typically present on a loopback address (`127.0.0.0/8`), such as systemd-resolved or dnsmasq. Common loopback address examples include `127.0.0.1` or `127.0.0.53`. As the host and any containers have separate loopback devices, a consequence of the design described above is that containers are unable to resolve names from the host\u0027s configured resolver, as they cannot reach these addresses on the host loopback device.\n\nTo bridge this gap, and to allow containers to properly resolve names even when a local forwarding resolver is used on a loopback address, `dockerd` will detect this scenario and instead forward DNS requests from the host/root network namespace. The loopback resolver will then forward the requests to its configured upstream resolvers, as expected.\n\n## Impact\n\nBecause `dockerd` will forward DNS requests to the host loopback device, bypassing the container network namespace\u0027s normal routing semantics entirely, _internal_ networks can unexpectedly forward DNS requests to an external nameserver.\n\nBy registering a domain for which they control the authoritative nameservers, an attacker could arrange for a compromised container to exfiltrate data by encoding it in DNS queries that will eventually be answered by their nameservers. For example, if the domain `evil.example` was registered, the authoritative nameserver(s) for that domain could (eventually and indirectly) receive a request for `this-is-a-secret.evil.example`.\n\nDocker Desktop is not affected, as Docker Desktop always runs an internal resolver on a RFC 1918 address.\n\n## Patches\n\nMoby releases 26.0.0-rc3, 25.0.5 (released) and 23.0.11 (to be released) are patched to prevent forwarding DNS requests from internal networks.\n\n## Workarounds\n\n-   Run containers intended to be solely attached to _internal_ networks with a custom upstream address (`--dns` argument to `docker run`, or API equivalent), which will force all upstream DNS queries to be resolved from the container network namespace.\n\n## Background\n\n- yair zak originally reported this issue to the Docker security team.\n-  PR \u003chttps://github.com/moby/moby/pull/46609\u003e was opened in public to fix this issue, as it was not originally considered to have a security implication.\n- [The official documentation](https://docs.docker.com/network/drivers/ipvlan/#:~:text=If%20the%20parent,the%20network%20completely) claims that \"the `--internal` flag that will completely isolate containers on a network from any communications external to that network,\" which necessitated this advisory and CVE.",
  "id": "GHSA-mq39-4gv4-mvpx",
  "modified": "2024-03-20T17:59:52Z",
  "published": "2024-03-20T17:59:52Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/moby/moby/security/advisories/GHSA-mq39-4gv4-mvpx"
    },
    {
      "type": "WEB",
      "url": "https://github.com/moby/moby/pull/46609"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/moby/moby"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Moby\u0027s external DNS requests from \u0027internal\u0027 networks could lead to data exfiltration"
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/docker/cli"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "19.03.0"
            },
            {
              "fixed": "29.2.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-15558"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-427"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-05T00:10:40Z",
    "nvd_published_at": "2026-03-04T17:16:14Z",
    "severity": "HIGH"
  },
  "details": "This issue affects Docker CLI through 29.1.5\n\n### Impact\n\nDocker CLI for Windows searches for plugin binaries in `C:\\ProgramData\\Docker\\cli-plugins`, a directory that does not exist by default. A low-privileged attacker can create this directory and place malicious CLI plugin binaries (docker-compose.exe, docker-buildx.exe, etc.) that are executed when a victim user opens Docker Desktop or invokes Docker CLI plugin features, and allow privilege-escalation if the `docker` CLI is executed as a privileged user.\n\nThis issue affects Docker CLI through v29.1.5 (fixed in v29.2.0). It impacts Windows binaries acting as a CLI plugin manager via the [`github.com/docker/cli/cli-plugins/manager`](https://pkg.go.dev/github.com/docker/cli@v29.1.5+incompatible/cli-plugins/manager) package, which is consumed by downstream projects such as Docker Compose.\n\nDocker Compose became affected starting in v2.31.0, when it incorporated the relevant CLI plugin manager code (see https://github.com/docker/compose/pull/12300), and is fixed in v5.1.0.\n\nThis issue does not impact non-Windows binaries or projects that do not use the plugin manager code.\n\n### Patches\n\nFixed version starts with 29.2.0\n\nThis issue was fixed in https://github.com/docker/cli/commit/13759330b1f7e7cb0d67047ea42c5482548ba7fa (https://github.com/docker/cli/pull/6713), which removed `%PROGRAMDATA%\\Docker\\cli-plugins` from the list of paths used for plugin-discovery on Windows.\n\n### Workarounds\n\nNone\n\n### Resources\n\n- Pull request: \"cli-plugins/manager: remove legacy system-wide cli-plugin path\" (https://github.com/docker/cli/pull/6713)\n- Patch: https://github.com/docker/cli/commit/13759330b1f7e7cb0d67047ea42c5482548ba7fa.patch\n\n### Credits\n\nNitesh Surana (niteshsurana.com) of Trend Research of TrendAI",
  "id": "GHSA-p436-gjf2-799p",
  "modified": "2026-03-31T14:21:14Z",
  "published": "2026-03-05T00:10:40Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/docker/cli/security/advisories/GHSA-p436-gjf2-799p"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-15558"
    },
    {
      "type": "WEB",
      "url": "https://github.com/docker/cli/pull/6713"
    },
    {
      "type": "WEB",
      "url": "https://github.com/docker/compose/pull/12300"
    },
    {
      "type": "WEB",
      "url": "https://github.com/docker/cli/commit/13759330b1f7e7cb0d67047ea42c5482548ba7fa"
    },
    {
      "type": "WEB",
      "url": "https://docs.docker.com/desktop/release-notes"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/docker/cli"
    },
    {
      "type": "WEB",
      "url": "https://www.zerodayinitiative.com/advisories/ZDI-CAN-28304"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Docker CLI Plugins: Uncontrolled Search Path Element Leads to Local Privilege Escalation on Windows"
}

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c 29.3.1"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/docker/docker"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/moby/moby/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.0.0-beta.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c 29.3.1"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/moby/moby"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-33997"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-193"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-27T17:38:09Z",
    "nvd_published_at": "2026-03-31T03:15:57Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nA security vulnerability has been detected that allows [plugins](https://docs.docker.com/engine/extend/legacy_plugins/) privilege validation to be bypassed during `docker plugin install`. Due to an error in the daemon\u0027s privilege comparison logic, the daemon may incorrectly accept a privilege set that differs from the one approved by the user.\n\nPlugins that request exactly one privilege are also affected, because no comparison is performed at all.\n\n## Impact\n\n**If plugins are not in use, there is no impact.**\n\nWhen a plugin is installed, the daemon computes the privileges required by the plugin\u0027s configuration and compares them with the privileges approved during installation. A malicious plugin can exploit this bug so that the daemon accepts privileges that differ from what was intended to be approved.\n\nAnyone who depends on the plugin installation approval flow as a meaningful security boundary is potentially impacted.\n\nDepending on the privilege set involved, this may include highly sensitive plugin permissions such as broad device access.\n\n**For consideration: exploitation still requires a plugin to be installed from a malicious source, and Docker plugins are relatively uncommon. Docker Desktop also does not support plugins.**\n\n## Workarounds\n\nIf unable to update immediately:\n- Do not install plugins from untrusted sources\n- Carefully review all privileges requested during `docker plugin install`\n- Restrict access to the Docker daemon to trusted parties, following the principle of least privilege\n- Avoid relying on plugin privilege approval as the only control boundary for sensitive environments\n\n## Credits\n\n- Reported by Cody (c@wormhole.guru, PGP 0x9FA5B73E)",
  "id": "GHSA-pxq6-2prw-chj9",
  "modified": "2026-03-31T18:40:21Z",
  "published": "2026-03-27T17:38:09Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/moby/moby/security/advisories/GHSA-pxq6-2prw-chj9"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33997"
    },
    {
      "type": "WEB",
      "url": "https://github.com/moby/moby/commit/f4d6f25bf0c3fa12d4968320a45685947756a22a"
    },
    {
      "type": "WEB",
      "url": "https://docs.docker.com/engine/extend/legacy_plugins"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/moby/moby"
    },
    {
      "type": "WEB",
      "url": "https://github.com/moby/moby/releases/tag/docker-v29.3.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Moby has an Off-by-one error in its plugin privilege validation"
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/docker/docker"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "19.03.0"
            },
            {
              "fixed": "23.0.15"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/docker/docker"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "26.0.0"
            },
            {
              "fixed": "26.1.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/docker/docker"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "27.0.0"
            },
            {
              "fixed": "27.1.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/docker/docker"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "24.0.0"
            },
            {
              "fixed": "25.0.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-41110"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-187"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-07-30T10:18:57Z",
    "nvd_published_at": "2024-07-24T17:15:11Z",
    "severity": "CRITICAL"
  },
  "details": "A security vulnerability has been detected in certain versions of Docker Engine, which could allow an attacker to bypass [authorization plugins (AuthZ)](https://docs.docker.com/engine/extend/plugins_authorization/) under specific circumstances. The base likelihood of this being exploited is low. This advisory outlines the issue, identifies the affected versions, and provides remediation steps for impacted users.\n\n### Impact\n\nUsing a specially-crafted API request, an Engine API client could make the daemon forward the request or response to an [authorization plugin](https://docs.docker.com/engine/extend/plugins_authorization/) without the body. In certain circumstances, the authorization plugin may allow a request which it would have otherwise denied if the body had been forwarded to it.\n\n\nA security issue was discovered In 2018,  where an attacker could bypass AuthZ plugins using a specially crafted API request. This could lead to unauthorized actions, including privilege escalation. Although this issue was fixed in Docker Engine [v18.09.1](https://docs.docker.com/engine/release-notes/18.09/#security-fixes-1) in January 2019, the fix was not carried forward to later major versions, resulting in a regression. Anyone who depends on authorization plugins that introspect the request and/or response body to make access control decisions is potentially impacted.\n\nDocker EE v19.03.x and all versions of Mirantis Container Runtime **are not vulnerable.**\n\n### Vulnerability details\n\n- **AuthZ bypass and privilege escalation:** An attacker could exploit a bypass using an API request with Content-Length set to 0, causing the Docker daemon to forward the request without the body to the AuthZ plugin, which might approve the request incorrectly.\n- **Initial fix:** The issue was fixed in Docker Engine [v18.09.1](https://docs.docker.com/engine/release-notes/18.09/#security-fixes-1) January 2019..\n- **Regression:** The fix was not included in Docker Engine v19.03 or newer versions. This was identified in April 2024 and patches were released for the affected versions on July 23, 2024. The issue was assigned [CVE-2024-41110](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-41110).\n\n### Patches\n\n- docker-ce v27.1.1 containes patches to fix the vulnerability.\n- Patches have also been merged into the master, 19.0, 20.0, 23.0, 24.0, 25.0, 26.0, and 26.1 release branches.\n\n### Remediation steps\n\n- If you are running an affected version, update to the most recent patched version.\n- Mitigation if unable to update immediately:\n    - Avoid using AuthZ plugins.\n    - Restrict access to the Docker API to trusted parties, following the principle of least privilege.\n\n\n### References\n\n- https://github.com/moby/moby/commit/fc274cd2ff4cf3b48c91697fb327dd1fb95588fb\n- https://github.com/moby/moby/commit/a79fabbfe84117696a19671f4aa88b82d0f64fc1\n- https://www.docker.com/blog/docker-security-advisory-docker-engine-authz-plugin/",
  "id": "GHSA-v23v-6jw2-98fq",
  "modified": "2024-08-09T19:07:47Z",
  "published": "2024-07-30T10:18:57Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/moby/moby/security/advisories/GHSA-v23v-6jw2-98fq"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41110"
    },
    {
      "type": "WEB",
      "url": "https://github.com/moby/moby/commit/411e817ddf710ff8e08fa193da80cb78af708191"
    },
    {
      "type": "WEB",
      "url": "https://github.com/moby/moby/commit/42f40b1d6dd7562342f832b9cd2adf9e668eeb76"
    },
    {
      "type": "WEB",
      "url": "https://github.com/moby/moby/commit/65cc597cea28cdc25bea3b8a86384b4251872919"
    },
    {
      "type": "WEB",
      "url": "https://github.com/moby/moby/commit/852759a7df454cbf88db4e954c919becd48faa9b"
    },
    {
      "type": "WEB",
      "url": "https://github.com/moby/moby/commit/a31260625655cff9ae226b51757915e275e304b0"
    },
    {
      "type": "WEB",
      "url": "https://github.com/moby/moby/commit/a79fabbfe84117696a19671f4aa88b82d0f64fc1"
    },
    {
      "type": "WEB",
      "url": "https://github.com/moby/moby/commit/ae160b4edddb72ef4bd71f66b975a1a1cc434f00"
    },
    {
      "type": "WEB",
      "url": "https://github.com/moby/moby/commit/ae2b3666c517c96cbc2adf1af5591a6b00d4ec0f"
    },
    {
      "type": "WEB",
      "url": "https://github.com/moby/moby/commit/cc13f952511154a2866bddbb7dddebfe9e83b801"
    },
    {
      "type": "WEB",
      "url": "https://github.com/moby/moby/commit/fc274cd2ff4cf3b48c91697fb327dd1fb95588fb"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/moby/moby"
    },
    {
      "type": "WEB",
      "url": "https://www.docker.com/blog/docker-security-advisory-docker-engine-authz-plugin"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Authz zero length regression"
}