Common Weakness Enumeration

CWE-636

Allowed-with-Review

Not Failing Securely ('Failing Open')

Abstraction: Class · Status: Draft

When the product encounters an error condition or failure, its design requires it to fall back to a state that is less secure than other options that are available, such as selecting the weakest encryption algorithm or using the most permissive access control restrictions.

73 vulnerabilities reference this CWE, most recent first.

CVE-2024-2660 (GCVE-0-2024-2660)

Vulnerability from cvelistv5 – Published: 2024-04-04 17:55 – Updated: 2024-09-26 00:13
VLAI
Title
Vault TLS Cert Auth Method Did Not Correctly Validate OCSP Responses
Summary
Vault and Vault Enterprise TLS certificates auth method did not correctly validate OCSP responses when one or more OCSP sources were configured. This vulnerability, CVE-2024-2660, affects Vault and Vault Enterprise 1.14.0 and above, and is fixed in Vault 1.16.0 and Vault Enterprise 1.16.1, 1.15.7, and 1.14.11.
SSVC
Exploitation: none Automatable: no Technical Impact: partial
CISA Coordinator (v2.0.3)
CWE
  • CWE-636 - Not Failing Securely (Failing Open)
Assigner
Impacted products
Vendor Product Version
HashiCorp Vault Affected: 1.14.0 , < 1.16.0 (semver)
Create a notification for this product.
HashiCorp Vault Enterprise Affected: 1.14.0 , < 1.16.0 (semver)
Create a notification for this product.
Show details on NVD website

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2024-2660",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2024-04-09T16:05:40.204182Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2024-06-04T17:29:09.743Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      },
      {
        "providerMetadata": {
          "dateUpdated": "2024-08-01T19:18:48.125Z",
          "orgId": "af854a3a-2127-422b-91ae-364da2661108",
          "shortName": "CVE"
        },
        "references": [
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://discuss.hashicorp.com/t/hcsec-2024-07-vault-tls-cert-auth-method-did-not-correctly-validate-ocsp-responses/64573"
          },
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://security.netapp.com/advisory/ntap-20240524-0007/"
          }
        ],
        "title": "CVE Program Container"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "platforms": [
            "64 bit",
            "32 bit",
            "x86",
            "ARM",
            "MacOS",
            "Windows",
            "Linux"
          ],
          "product": "Vault",
          "repo": "https://github.com/hashicorp/vault",
          "vendor": "HashiCorp",
          "versions": [
            {
              "lessThan": "1.16.0",
              "status": "affected",
              "version": "1.14.0",
              "versionType": "semver"
            }
          ]
        },
        {
          "defaultStatus": "unaffected",
          "platforms": [
            "64 bit",
            "32 bit",
            "x86",
            "ARM",
            "MacOS",
            "Windows",
            "Linux"
          ],
          "product": "Vault Enterprise",
          "repo": "https://github.com/hashicorp/vault",
          "vendor": "HashiCorp",
          "versions": [
            {
              "changes": [
                {
                  "at": "1.14.11",
                  "status": "unaffected"
                },
                {
                  "at": "1.15.7",
                  "status": "unaffected"
                }
              ],
              "lessThan": "1.16.0",
              "status": "affected",
              "version": "1.14.0",
              "versionType": "semver"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cp\u003eVault and Vault Enterprise TLS certificates auth method did not correctly validate OCSP responses when one or more OCSP sources were configured. This vulnerability, CVE-2024-2660, affects Vault and Vault Enterprise 1.14.0 and above, and is fixed in Vault 1.16.0 and Vault Enterprise 1.16.1, 1.15.7, and 1.14.11.\u003c/p\u003e\u003cbr/\u003e"
            }
          ],
          "value": "Vault and Vault Enterprise TLS certificates auth method did not correctly validate OCSP responses when one or more OCSP sources were configured. This vulnerability, CVE-2024-2660, affects Vault and Vault Enterprise 1.14.0 and above, and is fixed in Vault 1.16.0 and Vault Enterprise 1.16.1, 1.15.7, and 1.14.11."
        }
      ],
      "impacts": [
        {
          "capecId": "CAPEC-26",
          "descriptions": [
            {
              "lang": "en",
              "value": "CAPEC-26: Leveraging Race Conditions"
            }
          ]
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "baseScore": 6.4,
            "baseSeverity": "MEDIUM",
            "vectorString": "CVSS:3.1/AV:A/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H",
            "version": "3.1"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-636",
              "description": "CWE-636: Not Failing Securely (Failing Open)",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2024-09-26T00:13:17.242Z",
        "orgId": "67fedba0-ff2e-4543-ba5b-aa93e87718cc",
        "shortName": "HashiCorp"
      },
      "references": [
        {
          "url": "https://discuss.hashicorp.com/t/hcsec-2024-07-vault-tls-cert-auth-method-did-not-correctly-validate-ocsp-responses/64573"
        }
      ],
      "source": {
        "advisory": "HCSEC-2024-07",
        "discovery": "INTERNAL"
      },
      "title": "Vault TLS Cert Auth Method Did Not Correctly Validate OCSP Responses"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "67fedba0-ff2e-4543-ba5b-aa93e87718cc",
    "assignerShortName": "HashiCorp",
    "cveId": "CVE-2024-2660",
    "datePublished": "2024-04-04T17:55:20.192Z",
    "dateReserved": "2024-03-19T17:34:27.401Z",
    "dateUpdated": "2024-09-26T00:13:17.242Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.1"
}

CVE-2023-28842 (GCVE-0-2023-28842)

Vulnerability from cvelistv5 – Published: 2023-04-04 21:07 – Updated: 2025-02-13 16:48
VLAI
Title
moby/moby's dockerd daemon encrypted overlay network with a single endpoint is unauthenticated
Summary
Moby) 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 is commonly referred to as *Docker*. Swarm 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 and supporting network code. The `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, which encapsulates link-layer (Ethernet) frames in UDP datagrams that tag the frame with the VXLAN metadata, including 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. Encrypted overlay networks function by encapsulating the VXLAN datagrams through the use of the IPsec Encapsulating Security Payload protocol in 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. When setting an endpoint up on an encrypted overlay network, Moby installs three iptables (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's VNI field, so that IPSec guarantees can be enforced on encrypted overlay networks without interfering with other overlay networks or other users of VXLAN. The `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. Encrypted 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 should be referenced for a deeper exploration. Patches are available in Moby releases 23.0.3, and 20.10.24. As Mirantis Container Runtime's 20.10 releases are numbered differently, users of that platform should update to 20.10.16. Some workarounds are available. In multi-node clusters, deploy a global ‘pause’ container for each encrypted overlay network, on every node. 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. The 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. If encrypted overlay networks are in exclusive use, block UDP port 4789 from traffic that has not been validated by IPSec.
SSVC
Exploitation: none Automatable: no Technical Impact: partial
CISA Coordinator (v2.0.3)
CWE
  • CWE-420 - Unprotected Alternate Channel
  • CWE-636 - Not Failing Securely ('Failing Open')
Assigner
Impacted products
Vendor Product Version
moby moby Affected: >= 1.12.0, < 20.10.24
Affected: >= 23.0.0, < 23.0.3
Create a notification for this product.
Show details on NVD website

{
  "containers": {
    "adp": [
      {
        "providerMetadata": {
          "dateUpdated": "2024-08-02T13:51:38.540Z",
          "orgId": "af854a3a-2127-422b-91ae-364da2661108",
          "shortName": "CVE"
        },
        "references": [
          {
            "name": "https://github.com/moby/moby/security/advisories/GHSA-6wrf-mxfj-pf5p",
            "tags": [
              "x_refsource_CONFIRM",
              "x_transferred"
            ],
            "url": "https://github.com/moby/moby/security/advisories/GHSA-6wrf-mxfj-pf5p"
          },
          {
            "name": "https://github.com/moby/libnetwork/security/advisories/GHSA-gvm4-2qqg-m333",
            "tags": [
              "x_refsource_MISC",
              "x_transferred"
            ],
            "url": "https://github.com/moby/libnetwork/security/advisories/GHSA-gvm4-2qqg-m333"
          },
          {
            "name": "https://github.com/moby/moby/security/advisories/GHSA-232p-vwff-86mp",
            "tags": [
              "x_refsource_MISC",
              "x_transferred"
            ],
            "url": "https://github.com/moby/moby/security/advisories/GHSA-232p-vwff-86mp"
          },
          {
            "name": "https://github.com/moby/moby/security/advisories/GHSA-33pg-m6jh-5237",
            "tags": [
              "x_refsource_MISC",
              "x_transferred"
            ],
            "url": "https://github.com/moby/moby/security/advisories/GHSA-33pg-m6jh-5237"
          },
          {
            "name": "https://github.com/moby/moby/security/advisories/GHSA-vwm3-crmr-xfxw",
            "tags": [
              "x_refsource_MISC",
              "x_transferred"
            ],
            "url": "https://github.com/moby/moby/security/advisories/GHSA-vwm3-crmr-xfxw"
          },
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/ZTE4ITXXPIWZEQ4HYQCB6N6GZIMWXDAI/"
          },
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/LYZOKMMVX4SIEHPJW3SJUQGMO5YZCPHC/"
          },
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/XNF4OLYZRQE75EB5TW5N42FSXHBXGWFE/"
          }
        ],
        "title": "CVE Program Container"
      },
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2023-28842",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2025-02-10T21:32:48.323374Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2025-02-10T21:32:59.329Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "moby",
          "vendor": "moby",
          "versions": [
            {
              "status": "affected",
              "version": "\u003e= 1.12.0, \u003c 20.10.24"
            },
            {
              "status": "affected",
              "version": "\u003e= 23.0.0, \u003c 23.0.3"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "Moby) 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 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 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, which encapsulates link-layer (Ethernet) frames in UDP datagrams that tag the frame with the VXLAN metadata, including 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 protocol in 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 (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\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 should be referenced for a deeper exploration.\n\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\nSome workarounds are available. In multi-node clusters, deploy a global \u2018pause\u2019 container for each encrypted overlay network, on every node. 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. The 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. If encrypted overlay networks are in exclusive use, block UDP port 4789 from traffic that has not been validated by IPSec."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "HIGH",
            "attackVector": "NETWORK",
            "availabilityImpact": "NONE",
            "baseScore": 6.8,
            "baseSeverity": "MEDIUM",
            "confidentialityImpact": "NONE",
            "integrityImpact": "HIGH",
            "privilegesRequired": "NONE",
            "scope": "CHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:N/I:H/A:N",
            "version": "3.1"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-420",
              "description": "CWE-420: Unprotected Alternate Channel",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-636",
              "description": "CWE-636: Not Failing Securely (\u0027Failing Open\u0027)",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2023-09-15T20:06:33.396Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/moby/moby/security/advisories/GHSA-6wrf-mxfj-pf5p",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/moby/moby/security/advisories/GHSA-6wrf-mxfj-pf5p"
        },
        {
          "name": "https://github.com/moby/libnetwork/security/advisories/GHSA-gvm4-2qqg-m333",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/moby/libnetwork/security/advisories/GHSA-gvm4-2qqg-m333"
        },
        {
          "name": "https://github.com/moby/moby/security/advisories/GHSA-232p-vwff-86mp",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/moby/moby/security/advisories/GHSA-232p-vwff-86mp"
        },
        {
          "name": "https://github.com/moby/moby/security/advisories/GHSA-33pg-m6jh-5237",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/moby/moby/security/advisories/GHSA-33pg-m6jh-5237"
        },
        {
          "name": "https://github.com/moby/moby/security/advisories/GHSA-vwm3-crmr-xfxw",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/moby/moby/security/advisories/GHSA-vwm3-crmr-xfxw"
        },
        {
          "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/ZTE4ITXXPIWZEQ4HYQCB6N6GZIMWXDAI/"
        },
        {
          "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/LYZOKMMVX4SIEHPJW3SJUQGMO5YZCPHC/"
        },
        {
          "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/XNF4OLYZRQE75EB5TW5N42FSXHBXGWFE/"
        }
      ],
      "source": {
        "advisory": "GHSA-6wrf-mxfj-pf5p",
        "discovery": "UNKNOWN"
      },
      "title": "moby/moby\u0027s dockerd daemon encrypted overlay network with a single endpoint is unauthenticated"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2023-28842",
    "datePublished": "2023-04-04T21:07:27.575Z",
    "dateReserved": "2023-03-24T16:25:34.466Z",
    "dateUpdated": "2025-02-13T16:48:55.735Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.1"
}

CVE-2023-28841 (GCVE-0-2023-28841)

Vulnerability from cvelistv5 – Published: 2023-04-04 21:12 – Updated: 2025-02-13 16:48
VLAI
Title
moby/moby's dockerd daemon encrypted overlay network traffic may be unencrypted
Summary
Moby 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 is commonly referred to as *Docker*. Swarm 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 and supporting network code. The `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, which encapsulates link-layer (Ethernet) frames in UDP datagrams that tag the frame with the VXLAN metadata, including 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. Encrypted overlay networks function by encapsulating the VXLAN datagrams through the use of the IPsec Encapsulating Security Payload protocol in 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. When setting an endpoint up on an encrypted overlay network, Moby installs three iptables (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's VNI field, so that IPSec guarantees can be enforced on encrypted overlay networks without interfering with other overlay networks or other users of VXLAN. An iptables rule designates outgoing VXLAN datagrams with a VNI that corresponds to an encrypted overlay network for IPsec encapsulation. Encrypted 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. It 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 use Swarm encrypted overlay networks to provide confidentiality, which due to this vulnerability this is no longer guaranteed. Patches are available in Moby releases 23.0.3, and 20.10.24. As Mirantis Container Runtime's 20.10 releases are numbered differently, users of that platform should update to 20.10.16. Some workarounds are available. Close the VXLAN port (by default, UDP port 4789) to outgoing traffic at the Internet boundary in order to prevent unintentionally leaking unencrypted traffic over the Internet, and/or ensure that the `xt_u32` kernel module is available on all nodes of the Swarm cluster.
SSVC
Exploitation: none Automatable: no Technical Impact: partial
CISA Coordinator (v2.0.3)
CWE
  • CWE-311 - Missing Encryption of Sensitive Data
  • CWE-636 - Not Failing Securely ('Failing Open')
Assigner
Impacted products
Vendor Product Version
moby moby Affected: >= 1.12.0, < 20.10.24
Affected: >= 23.0.0, < 23.0.3
Create a notification for this product.
Show details on NVD website

{
  "containers": {
    "adp": [
      {
        "providerMetadata": {
          "dateUpdated": "2024-08-02T13:51:38.268Z",
          "orgId": "af854a3a-2127-422b-91ae-364da2661108",
          "shortName": "CVE"
        },
        "references": [
          {
            "name": "https://github.com/moby/moby/security/advisories/GHSA-33pg-m6jh-5237",
            "tags": [
              "x_refsource_CONFIRM",
              "x_transferred"
            ],
            "url": "https://github.com/moby/moby/security/advisories/GHSA-33pg-m6jh-5237"
          },
          {
            "name": "https://github.com/moby/libnetwork/security/advisories/GHSA-gvm4-2qqg-m333",
            "tags": [
              "x_refsource_MISC",
              "x_transferred"
            ],
            "url": "https://github.com/moby/libnetwork/security/advisories/GHSA-gvm4-2qqg-m333"
          },
          {
            "name": "https://github.com/moby/moby/security/advisories/GHSA-232p-vwff-86mp",
            "tags": [
              "x_refsource_MISC",
              "x_transferred"
            ],
            "url": "https://github.com/moby/moby/security/advisories/GHSA-232p-vwff-86mp"
          },
          {
            "name": "https://github.com/moby/moby/security/advisories/GHSA-6wrf-mxfj-pf5p",
            "tags": [
              "x_refsource_MISC",
              "x_transferred"
            ],
            "url": "https://github.com/moby/moby/security/advisories/GHSA-6wrf-mxfj-pf5p"
          },
          {
            "name": "https://github.com/moby/moby/security/advisories/GHSA-vwm3-crmr-xfxw",
            "tags": [
              "x_refsource_MISC",
              "x_transferred"
            ],
            "url": "https://github.com/moby/moby/security/advisories/GHSA-vwm3-crmr-xfxw"
          },
          {
            "name": "https://github.com/moby/moby/issues/43382",
            "tags": [
              "x_refsource_MISC",
              "x_transferred"
            ],
            "url": "https://github.com/moby/moby/issues/43382"
          },
          {
            "name": "https://github.com/moby/moby/pull/45118",
            "tags": [
              "x_refsource_MISC",
              "x_transferred"
            ],
            "url": "https://github.com/moby/moby/pull/45118"
          },
          {
            "name": "https://github.com/moby/libnetwork/blob/d9fae4c73daf76c3b0f77e14b45b8bf612ba764d/drivers/overlay/encryption.go#L205-L207",
            "tags": [
              "x_refsource_MISC",
              "x_transferred"
            ],
            "url": "https://github.com/moby/libnetwork/blob/d9fae4c73daf76c3b0f77e14b45b8bf612ba764d/drivers/overlay/encryption.go#L205-L207"
          },
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/ZTE4ITXXPIWZEQ4HYQCB6N6GZIMWXDAI/"
          },
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/LYZOKMMVX4SIEHPJW3SJUQGMO5YZCPHC/"
          },
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/XNF4OLYZRQE75EB5TW5N42FSXHBXGWFE/"
          }
        ],
        "title": "CVE Program Container"
      },
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2023-28841",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2025-02-10T21:32:19.333443Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2025-02-10T21:32:23.447Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "moby",
          "vendor": "moby",
          "versions": [
            {
              "status": "affected",
              "version": "\u003e= 1.12.0, \u003c 20.10.24"
            },
            {
              "status": "affected",
              "version": "\u003e= 23.0.0, \u003c 23.0.3"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "Moby 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 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 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, which encapsulates link-layer (Ethernet) frames in UDP datagrams that tag the frame with the VXLAN metadata, including 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 protocol in 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 (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 designates outgoing VXLAN datagrams with a VNI that corresponds to an encrypted overlay network for IPsec encapsulation.\n\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 use Swarm encrypted overlay networks to provide confidentiality, which due to this vulnerability this is no longer guaranteed.\n\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\nSome workarounds are available. Close the VXLAN port (by default, UDP port 4789) to outgoing traffic at the Internet boundary in order to prevent unintentionally leaking unencrypted traffic over the Internet, and/or ensure that the `xt_u32` kernel module is available on all nodes of the Swarm cluster."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "HIGH",
            "attackVector": "NETWORK",
            "availabilityImpact": "NONE",
            "baseScore": 6.8,
            "baseSeverity": "MEDIUM",
            "confidentialityImpact": "HIGH",
            "integrityImpact": "NONE",
            "privilegesRequired": "NONE",
            "scope": "CHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:N/A:N",
            "version": "3.1"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-311",
              "description": "CWE-311: Missing Encryption of Sensitive Data",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-636",
              "description": "CWE-636: Not Failing Securely (\u0027Failing Open\u0027)",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2023-09-15T20:06:27.951Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/moby/moby/security/advisories/GHSA-33pg-m6jh-5237",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/moby/moby/security/advisories/GHSA-33pg-m6jh-5237"
        },
        {
          "name": "https://github.com/moby/libnetwork/security/advisories/GHSA-gvm4-2qqg-m333",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/moby/libnetwork/security/advisories/GHSA-gvm4-2qqg-m333"
        },
        {
          "name": "https://github.com/moby/moby/security/advisories/GHSA-232p-vwff-86mp",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/moby/moby/security/advisories/GHSA-232p-vwff-86mp"
        },
        {
          "name": "https://github.com/moby/moby/security/advisories/GHSA-6wrf-mxfj-pf5p",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/moby/moby/security/advisories/GHSA-6wrf-mxfj-pf5p"
        },
        {
          "name": "https://github.com/moby/moby/security/advisories/GHSA-vwm3-crmr-xfxw",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/moby/moby/security/advisories/GHSA-vwm3-crmr-xfxw"
        },
        {
          "name": "https://github.com/moby/moby/issues/43382",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/moby/moby/issues/43382"
        },
        {
          "name": "https://github.com/moby/moby/pull/45118",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/moby/moby/pull/45118"
        },
        {
          "name": "https://github.com/moby/libnetwork/blob/d9fae4c73daf76c3b0f77e14b45b8bf612ba764d/drivers/overlay/encryption.go#L205-L207",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/moby/libnetwork/blob/d9fae4c73daf76c3b0f77e14b45b8bf612ba764d/drivers/overlay/encryption.go#L205-L207"
        },
        {
          "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/ZTE4ITXXPIWZEQ4HYQCB6N6GZIMWXDAI/"
        },
        {
          "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/LYZOKMMVX4SIEHPJW3SJUQGMO5YZCPHC/"
        },
        {
          "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/XNF4OLYZRQE75EB5TW5N42FSXHBXGWFE/"
        }
      ],
      "source": {
        "advisory": "GHSA-33pg-m6jh-5237",
        "discovery": "UNKNOWN"
      },
      "title": "moby/moby\u0027s dockerd daemon encrypted overlay network traffic may be unencrypted"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2023-28841",
    "datePublished": "2023-04-04T21:12:17.406Z",
    "dateReserved": "2023-03-24T16:25:34.466Z",
    "dateUpdated": "2025-02-13T16:48:54.707Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.1"
}

CVE-2023-28840 (GCVE-0-2023-28840)

Vulnerability from cvelistv5 – Published: 2023-04-04 21:13 – Updated: 2025-02-13 16:48
VLAI
Title
moby/moby's dockerd daemon encrypted overlay network may be unauthenticated
Summary
Moby 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, is commonly referred to as *Docker*. Swarm 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 and supporting network code. The 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, 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. Encrypted overlay networks function by encapsulating the VXLAN datagrams through the use of the IPsec Encapsulating Security Payload protocol in 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. When setting an endpoint up on an encrypted overlay network, Moby installs three iptables (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's VNI field, so that IPSec guarantees can be enforced on encrypted overlay networks without interfering with other overlay networks or other users of VXLAN. Two iptables rules serve to filter incoming VXLAN datagrams with a VNI that corresponds to an encrypted network and discards unencrypted datagrams. The rules are appended to the end of the INPUT filter chain, following any rules that have been previously set by the system administrator. Administrator-set rules take precedence over the rules Moby sets to discard unencrypted VXLAN datagrams, which can potentially admit unencrypted datagrams that should have been discarded. The injection of arbitrary Ethernet frames can enable a Denial of Service attack. A sophisticated attacker may be able to establish a UDP or TCP connection by way of the container’s outbound gateway that would otherwise be blocked by a stateful firewall, or carry out other escalations beyond simple injection by smuggling packets into the overlay network. Patches are available in Moby releases 23.0.3 and 20.10.24. As Mirantis Container Runtime's 20.10 releases are numbered differently, users of that platform should update to 20.10.16. Some workarounds are available. Close the VXLAN port (by default, UDP port 4789) to incoming traffic at the Internet boundary to prevent all VXLAN packet injection, and/or ensure that the `xt_u32` kernel module is available on all nodes of the Swarm cluster.
SSVC
Exploitation: none Automatable: no Technical Impact: partial
CISA Coordinator (v2.0.3)
CWE
  • CWE-420 - Unprotected Alternate Channel
  • CWE-636 - Not Failing Securely ('Failing Open')
Assigner
Impacted products
Vendor Product Version
moby moby Affected: >= 1.12.0, < 20.10.24
Affected: >= 23.0.0, < 23.0.3
Create a notification for this product.
Show details on NVD website

{
  "containers": {
    "adp": [
      {
        "providerMetadata": {
          "dateUpdated": "2024-08-02T13:51:38.250Z",
          "orgId": "af854a3a-2127-422b-91ae-364da2661108",
          "shortName": "CVE"
        },
        "references": [
          {
            "name": "https://github.com/moby/moby/security/advisories/GHSA-232p-vwff-86mp",
            "tags": [
              "x_refsource_CONFIRM",
              "x_transferred"
            ],
            "url": "https://github.com/moby/moby/security/advisories/GHSA-232p-vwff-86mp"
          },
          {
            "name": "https://github.com/moby/libnetwork/security/advisories/GHSA-gvm4-2qqg-m333",
            "tags": [
              "x_refsource_MISC",
              "x_transferred"
            ],
            "url": "https://github.com/moby/libnetwork/security/advisories/GHSA-gvm4-2qqg-m333"
          },
          {
            "name": "https://github.com/moby/moby/security/advisories/GHSA-33pg-m6jh-5237",
            "tags": [
              "x_refsource_MISC",
              "x_transferred"
            ],
            "url": "https://github.com/moby/moby/security/advisories/GHSA-33pg-m6jh-5237"
          },
          {
            "name": "https://github.com/moby/moby/security/advisories/GHSA-6wrf-mxfj-pf5p",
            "tags": [
              "x_refsource_MISC",
              "x_transferred"
            ],
            "url": "https://github.com/moby/moby/security/advisories/GHSA-6wrf-mxfj-pf5p"
          },
          {
            "name": "https://github.com/moby/moby/security/advisories/GHSA-vwm3-crmr-xfxw",
            "tags": [
              "x_refsource_MISC",
              "x_transferred"
            ],
            "url": "https://github.com/moby/moby/security/advisories/GHSA-vwm3-crmr-xfxw"
          },
          {
            "name": "https://github.com/moby/moby/issues/43382",
            "tags": [
              "x_refsource_MISC",
              "x_transferred"
            ],
            "url": "https://github.com/moby/moby/issues/43382"
          },
          {
            "name": "https://github.com/moby/moby/pull/45118",
            "tags": [
              "x_refsource_MISC",
              "x_transferred"
            ],
            "url": "https://github.com/moby/moby/pull/45118"
          },
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/ZTE4ITXXPIWZEQ4HYQCB6N6GZIMWXDAI/"
          },
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/LYZOKMMVX4SIEHPJW3SJUQGMO5YZCPHC/"
          },
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/XNF4OLYZRQE75EB5TW5N42FSXHBXGWFE/"
          }
        ],
        "title": "CVE Program Container"
      },
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2023-28840",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2025-02-10T21:31:15.735065Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2025-02-10T21:31:41.188Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "moby",
          "vendor": "moby",
          "versions": [
            {
              "status": "affected",
              "version": "\u003e= 1.12.0, \u003c 20.10.24"
            },
            {
              "status": "affected",
              "version": "\u003e= 23.0.0, \u003c 23.0.3"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "Moby 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, 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 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, 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 protocol in 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 (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\nTwo iptables rules serve to filter incoming VXLAN datagrams with a VNI that corresponds to an encrypted network and discards unencrypted datagrams. The rules are appended to the end of the INPUT filter chain, following any rules that have been previously set by the system administrator. Administrator-set rules take precedence over the rules Moby sets to discard unencrypted VXLAN datagrams, which can potentially admit unencrypted datagrams that should have been discarded.\n\nThe injection of arbitrary Ethernet frames can enable a Denial of Service attack. A sophisticated attacker may be able to establish a UDP or TCP connection by way of the container\u2019s outbound gateway that would otherwise be blocked by a stateful firewall, or carry out other escalations beyond simple injection by smuggling packets into the overlay network.\n\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\nSome workarounds are available. Close the VXLAN port (by default, UDP port 4789) to incoming traffic at the Internet boundary to prevent all VXLAN packet injection, and/or ensure that the `xt_u32` kernel module is available on all nodes of the Swarm cluster."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "HIGH",
            "attackVector": "NETWORK",
            "availabilityImpact": "LOW",
            "baseScore": 7.5,
            "baseSeverity": "HIGH",
            "confidentialityImpact": "HIGH",
            "integrityImpact": "NONE",
            "privilegesRequired": "NONE",
            "scope": "CHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:N/A:L",
            "version": "3.1"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-420",
              "description": "CWE-420: Unprotected Alternate Channel",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-636",
              "description": "CWE-636: Not Failing Securely (\u0027Failing Open\u0027)",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2023-09-15T20:06:20.926Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/moby/moby/security/advisories/GHSA-232p-vwff-86mp",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/moby/moby/security/advisories/GHSA-232p-vwff-86mp"
        },
        {
          "name": "https://github.com/moby/libnetwork/security/advisories/GHSA-gvm4-2qqg-m333",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/moby/libnetwork/security/advisories/GHSA-gvm4-2qqg-m333"
        },
        {
          "name": "https://github.com/moby/moby/security/advisories/GHSA-33pg-m6jh-5237",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/moby/moby/security/advisories/GHSA-33pg-m6jh-5237"
        },
        {
          "name": "https://github.com/moby/moby/security/advisories/GHSA-6wrf-mxfj-pf5p",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/moby/moby/security/advisories/GHSA-6wrf-mxfj-pf5p"
        },
        {
          "name": "https://github.com/moby/moby/security/advisories/GHSA-vwm3-crmr-xfxw",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/moby/moby/security/advisories/GHSA-vwm3-crmr-xfxw"
        },
        {
          "name": "https://github.com/moby/moby/issues/43382",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/moby/moby/issues/43382"
        },
        {
          "name": "https://github.com/moby/moby/pull/45118",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/moby/moby/pull/45118"
        },
        {
          "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/ZTE4ITXXPIWZEQ4HYQCB6N6GZIMWXDAI/"
        },
        {
          "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/LYZOKMMVX4SIEHPJW3SJUQGMO5YZCPHC/"
        },
        {
          "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/XNF4OLYZRQE75EB5TW5N42FSXHBXGWFE/"
        }
      ],
      "source": {
        "advisory": "GHSA-232p-vwff-86mp",
        "discovery": "UNKNOWN"
      },
      "title": "moby/moby\u0027s dockerd daemon encrypted overlay network may be unauthenticated"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2023-28840",
    "datePublished": "2023-04-04T21:13:03.347Z",
    "dateReserved": "2023-03-24T16:25:34.466Z",
    "dateUpdated": "2025-02-13T16:48:53.710Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.1"
}

CVE-2023-22943 (GCVE-0-2023-22943)

Vulnerability from cvelistv5 – Published: 2023-02-14 17:22 – Updated: 2025-02-28 11:03
VLAI
Title
Modular Input REST API Requests Connect via HTTP after Certificate Validation Failure in Splunk Add-on Builder and Splunk CloudConnect SDK
Summary
In Splunk Add-on Builder (AoB) versions below 4.1.2 and the Splunk CloudConnect SDK versions below 3.1.3, requests to third-party APIs through the REST API Modular Input incorrectly revert to using HTTP to connect after a failure to connect over HTTPS occurs.
CWE
  • CWE-636 - When the product encounters an error condition or failure, its design requires it to fall back to a state that is less secure than other options that are available, such as selecting the weakest encryption algorithm or using the most permissive access control restrictions.
Assigner
Impacted products
Vendor Product Version
Splunk Splunk Add-on Builder Affected: 4.1 , < 4.1.2 (custom)
Create a notification for this product.
Splunk Splunk CloudConnect SDK Affected: 3.1 , < 3.1.3 (custom)
Create a notification for this product.
Date Public
2023-02-14 00:00
Credits
Chris Green
Show details on NVD website

{
  "containers": {
    "adp": [
      {
        "providerMetadata": {
          "dateUpdated": "2024-08-02T10:20:31.441Z",
          "orgId": "af854a3a-2127-422b-91ae-364da2661108",
          "shortName": "CVE"
        },
        "references": [
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://advisory.splunk.com/advisories/SVD-2023-0213"
          }
        ],
        "title": "CVE Program Container"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "Splunk Add-on Builder",
          "vendor": "Splunk",
          "versions": [
            {
              "lessThan": "4.1.2",
              "status": "affected",
              "version": "4.1",
              "versionType": "custom"
            }
          ]
        },
        {
          "product": "Splunk CloudConnect SDK",
          "vendor": "Splunk",
          "versions": [
            {
              "lessThan": "3.1.3",
              "status": "affected",
              "version": "3.1",
              "versionType": "custom"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "value": "Chris Green"
        }
      ],
      "datePublic": "2023-02-14T00:00:00.000Z",
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "In Splunk Add-on Builder (AoB) versions below 4.1.2 and the Splunk CloudConnect SDK versions below 3.1.3, requests to third-party APIs through the REST API Modular Input incorrectly revert to using HTTP to connect after a failure to connect over HTTPS occurs."
            }
          ],
          "value": "In Splunk Add-on Builder (AoB) versions below 4.1.2 and the Splunk CloudConnect SDK versions below 3.1.3, requests to third-party APIs through the REST API Modular Input incorrectly revert to using HTTP to connect after a failure to connect over HTTPS occurs."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "baseScore": 4.8,
            "baseSeverity": "MEDIUM",
            "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N",
            "version": "3.1"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-636",
              "description": "When the product encounters an error condition or failure, its design requires it to fall back to a state that is less secure than other options that are available, such as selecting the weakest encryption algorithm or using the most permissive access control restrictions.",
              "lang": "en",
              "type": "cwe"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2025-02-28T11:03:49.432Z",
        "orgId": "42b59230-ec95-491e-8425-5a5befa1a469",
        "shortName": "Splunk"
      },
      "references": [
        {
          "url": "https://advisory.splunk.com/advisories/SVD-2023-0213"
        }
      ],
      "source": {
        "advisory": "SVD-2023-0213"
      },
      "title": "Modular Input REST API Requests Connect via HTTP after Certificate Validation Failure in Splunk Add-on Builder and Splunk CloudConnect SDK"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "42b59230-ec95-491e-8425-5a5befa1a469",
    "assignerShortName": "Splunk",
    "cveId": "CVE-2023-22943",
    "datePublished": "2023-02-14T17:22:40.690Z",
    "dateReserved": "2023-01-10T21:39:55.584Z",
    "dateUpdated": "2025-02-28T11:03:49.432Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.1"
}

CVE-2023-4030 (GCVE-0-2023-4030)

Vulnerability from cvelistv5 – Published: 2023-08-17 16:48 – Updated: 2024-10-08 13:11
VLAI
Summary
A vulnerability was reported in BIOS for ThinkPad P14s Gen 2, P15s Gen 2, T14 Gen 2, and T15 Gen 2 that could cause the system to recover to insecure settings if the BIOS becomes corrupt.
SSVC
Exploitation: none Automatable: no Technical Impact: total
CISA Coordinator (v2.0.3)
CWE
  • CWE-636 - Not Failing Securely ('Failing Open')
Assigner
Impacted products
Vendor Product Version
Lenovo ThinkPad Affected: various
Create a notification for this product.
lenovo thinkpad Affected: p14_gen2
Affected: p15_gen2
Affected: t14_gen2
Affected: t15_gen2
    cpe:2.3:h:lenovo:thinkpad:-:*:*:*:*:*:*:*
Create a notification for this product.
Credits
Lenovo thanks Zichuan Li (@Ri7erLi) from Indiana University Bloomington for reporting this vulnerability.
Show details on NVD website

{
  "containers": {
    "adp": [
      {
        "providerMetadata": {
          "dateUpdated": "2024-08-02T07:17:11.606Z",
          "orgId": "af854a3a-2127-422b-91ae-364da2661108",
          "shortName": "CVE"
        },
        "references": [
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://support.lenovo.com/us/en/product_security/LEN-134879"
          }
        ],
        "title": "CVE Program Container"
      },
      {
        "affected": [
          {
            "cpes": [
              "cpe:2.3:h:lenovo:thinkpad:-:*:*:*:*:*:*:*"
            ],
            "defaultStatus": "unaffected",
            "product": "thinkpad",
            "vendor": "lenovo",
            "versions": [
              {
                "status": "affected",
                "version": "p14_gen2"
              },
              {
                "status": "affected",
                "version": "p15_gen2"
              },
              {
                "status": "affected",
                "version": "t14_gen2"
              },
              {
                "status": "affected",
                "version": "t15_gen2"
              }
            ]
          }
        ],
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2023-4030",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "total"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2024-10-08T13:08:56.146548Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2024-10-08T13:11:13.980Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "ThinkPad",
          "vendor": "Lenovo",
          "versions": [
            {
              "status": "affected",
              "version": "various"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "Lenovo thanks Zichuan Li (@Ri7erLi) from Indiana University Bloomington for reporting this vulnerability."
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "A vulnerability was reported in BIOS for ThinkPad P14s Gen 2, P15s Gen 2, T14 Gen 2, and T15 Gen 2 that could cause the system to recover to insecure settings if the BIOS becomes corrupt."
            }
          ],
          "value": "A vulnerability was reported in BIOS for ThinkPad P14s Gen 2, P15s Gen 2, T14 Gen 2, and T15 Gen 2 that could cause the system to recover to insecure settings if the BIOS becomes corrupt."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "LOCAL",
            "availabilityImpact": "HIGH",
            "baseScore": 8.4,
            "baseSeverity": "HIGH",
            "confidentialityImpact": "HIGH",
            "integrityImpact": "HIGH",
            "privilegesRequired": "NONE",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
            "version": "3.1"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-636",
              "description": "CWE-636: Not Failing Securely (\u0027Failing Open\u0027)",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2023-08-17T16:48:47.172Z",
        "orgId": "da227ddf-6e25-4b41-b023-0f976dcaca4b",
        "shortName": "lenovo"
      },
      "references": [
        {
          "url": "https://support.lenovo.com/us/en/product_security/LEN-134879"
        }
      ],
      "solutions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "Update system firmware to the version (or newer) indicated for your model in the Product Impact section in LEN-134879."
            }
          ],
          "value": "Update system firmware to the version (or newer) indicated for your model in the Product Impact section in LEN-134879."
        }
      ],
      "source": {
        "discovery": "UNKNOWN"
      },
      "x_generator": {
        "engine": "Vulnogram 0.1.0-dev"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "da227ddf-6e25-4b41-b023-0f976dcaca4b",
    "assignerShortName": "lenovo",
    "cveId": "CVE-2023-4030",
    "datePublished": "2023-08-17T16:48:47.172Z",
    "dateReserved": "2023-07-31T16:54:49.207Z",
    "dateUpdated": "2024-10-08T13:11:13.980Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.1"
}

CVE-2021-3614 (GCVE-0-2021-3614)

Vulnerability from cvelistv5 – Published: 2021-07-16 20:30 – Updated: 2024-08-03 17:01
VLAI
Summary
A vulnerability was reported on some Lenovo Notebook systems that could allow an attacker with physical access to elevate privileges under certain conditions during a BIOS update performed by Lenovo Vantage.
CWE
  • CWE-636 - Not Failing Securely ('Failing Open')
Assigner
References
Impacted products
Vendor Product Version
Lenovo Notebook BIOS Affected: various
Create a notification for this product.
Credits
Lenovo thanks Tim Boyd, NCC Group for reporting this issue.
Show details on NVD website

{
  "containers": {
    "adp": [
      {
        "providerMetadata": {
          "dateUpdated": "2024-08-03T17:01:07.203Z",
          "orgId": "af854a3a-2127-422b-91ae-364da2661108",
          "shortName": "CVE"
        },
        "references": [
          {
            "tags": [
              "x_refsource_MISC",
              "x_transferred"
            ],
            "url": "https://support.lenovo.com/us/en/product_security/LEN-65529"
          }
        ],
        "title": "CVE Program Container"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "Notebook BIOS",
          "vendor": "Lenovo",
          "versions": [
            {
              "status": "affected",
              "version": "various"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "value": "Lenovo thanks Tim Boyd, NCC Group for reporting this issue."
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "A vulnerability was reported on some Lenovo Notebook systems that could allow an attacker with physical access to elevate privileges under certain conditions during a BIOS update performed by Lenovo Vantage."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "PHYSICAL",
            "availabilityImpact": "HIGH",
            "baseScore": 6.4,
            "baseSeverity": "MEDIUM",
            "confidentialityImpact": "HIGH",
            "integrityImpact": "HIGH",
            "privilegesRequired": "LOW",
            "scope": "UNCHANGED",
            "userInteraction": "REQUIRED",
            "vectorString": "CVSS:3.1/AV:P/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H",
            "version": "3.1"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-636",
              "description": "CWE-636 Not Failing Securely (\u0027Failing Open\u0027)",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2021-07-16T20:30:20.000Z",
        "orgId": "da227ddf-6e25-4b41-b023-0f976dcaca4b",
        "shortName": "lenovo"
      },
      "references": [
        {
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://support.lenovo.com/us/en/product_security/LEN-65529"
        }
      ],
      "solutions": [
        {
          "lang": "en",
          "value": "Update system firmware to the version (or newer) indicated for your model in the Product Impact section of LEN-65529."
        }
      ],
      "source": {
        "advisory": "LEN-65529",
        "discovery": "UNKNOWN"
      },
      "x_generator": {
        "engine": "Vulnogram 0.0.9"
      },
      "x_legacyV4Record": {
        "CVE_data_meta": {
          "ASSIGNER": "psirt@lenovo.com",
          "ID": "CVE-2021-3614",
          "STATE": "PUBLIC"
        },
        "affects": {
          "vendor": {
            "vendor_data": [
              {
                "product": {
                  "product_data": [
                    {
                      "product_name": "Notebook BIOS",
                      "version": {
                        "version_data": [
                          {
                            "version_affected": "=",
                            "version_value": "various"
                          }
                        ]
                      }
                    }
                  ]
                },
                "vendor_name": "Lenovo"
              }
            ]
          }
        },
        "credit": [
          {
            "lang": "eng",
            "value": "Lenovo thanks Tim Boyd, NCC Group for reporting this issue."
          }
        ],
        "data_format": "MITRE",
        "data_type": "CVE",
        "data_version": "4.0",
        "description": {
          "description_data": [
            {
              "lang": "eng",
              "value": "A vulnerability was reported on some Lenovo Notebook systems that could allow an attacker with physical access to elevate privileges under certain conditions during a BIOS update performed by Lenovo Vantage."
            }
          ]
        },
        "generator": {
          "engine": "Vulnogram 0.0.9"
        },
        "impact": {
          "cvss": {
            "attackComplexity": "LOW",
            "attackVector": "PHYSICAL",
            "availabilityImpact": "HIGH",
            "baseScore": 6.4,
            "baseSeverity": "MEDIUM",
            "confidentialityImpact": "HIGH",
            "integrityImpact": "HIGH",
            "privilegesRequired": "LOW",
            "scope": "UNCHANGED",
            "userInteraction": "REQUIRED",
            "vectorString": "CVSS:3.1/AV:P/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H",
            "version": "3.1"
          }
        },
        "problemtype": {
          "problemtype_data": [
            {
              "description": [
                {
                  "lang": "eng",
                  "value": "CWE-636 Not Failing Securely (\u0027Failing Open\u0027)"
                }
              ]
            }
          ]
        },
        "references": {
          "reference_data": [
            {
              "name": "https://support.lenovo.com/us/en/product_security/LEN-65529",
              "refsource": "MISC",
              "url": "https://support.lenovo.com/us/en/product_security/LEN-65529"
            }
          ]
        },
        "solution": [
          {
            "lang": "en",
            "value": "Update system firmware to the version (or newer) indicated for your model in the Product Impact section of LEN-65529."
          }
        ],
        "source": {
          "advisory": "LEN-65529",
          "discovery": "UNKNOWN"
        }
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "da227ddf-6e25-4b41-b023-0f976dcaca4b",
    "assignerShortName": "lenovo",
    "cveId": "CVE-2021-3614",
    "datePublished": "2021-07-16T20:30:20.000Z",
    "dateReserved": "2021-06-23T00:00:00.000Z",
    "dateUpdated": "2024-08-03T17:01:07.203Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.1"
}

CVE-2021-1578 (GCVE-0-2021-1578)

Vulnerability from cvelistv5 – Published: 2021-08-25 19:10 – Updated: 2024-11-07 22:03
VLAI
Title
Cisco Application Policy Infrastructure Controller Privilege Escalation Vulnerability
Summary
A vulnerability in an API endpoint of Cisco Application Policy Infrastructure Controller (APIC) and Cisco Cloud Application Policy Infrastructure Controller (Cloud APIC) could allow an authenticated, remote attacker to elevate privileges to Administrator on an affected device. This vulnerability is due to an improper policy default setting. An attacker could exploit this vulnerability by using a non-privileged credential for Cisco ACI Multi-Site Orchestrator (MSO) to send a specific API request to a managed Cisco APIC or Cloud APIC device. A successful exploit could allow the attacker to obtain Administrator credentials on the affected device.
SSVC
Exploitation: none Automatable: no Technical Impact: total
CISA Coordinator (v2.0.3)
CWE
Assigner
References
URL Tags
https://tools.cisco.com/security/center/content/C… vendor-advisoryx_refsource_CISCO
Date Public
2021-08-25 00:00
Show details on NVD website

{
  "containers": {
    "adp": [
      {
        "providerMetadata": {
          "dateUpdated": "2024-08-03T16:18:10.274Z",
          "orgId": "af854a3a-2127-422b-91ae-364da2661108",
          "shortName": "CVE"
        },
        "references": [
          {
            "name": "20210825 Cisco Application Policy Infrastructure Controller Privilege Escalation Vulnerability",
            "tags": [
              "vendor-advisory",
              "x_refsource_CISCO",
              "x_transferred"
            ],
            "url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-capic-pesc-pkmGK4J"
          }
        ],
        "title": "CVE Program Container"
      },
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2021-1578",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "total"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2024-11-07T21:43:24.747573Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2024-11-07T22:03:16.741Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "Cisco Application Policy Infrastructure Controller (APIC)",
          "vendor": "Cisco",
          "versions": [
            {
              "status": "affected",
              "version": "n/a"
            }
          ]
        }
      ],
      "datePublic": "2021-08-25T00:00:00.000Z",
      "descriptions": [
        {
          "lang": "en",
          "value": "A vulnerability in an API endpoint of Cisco Application Policy Infrastructure Controller (APIC) and Cisco Cloud Application Policy Infrastructure Controller (Cloud APIC) could allow an authenticated, remote attacker to elevate privileges to Administrator on an affected device. This vulnerability is due to an improper policy default setting. An attacker could exploit this vulnerability by using a non-privileged credential for Cisco ACI Multi-Site Orchestrator (MSO) to send a specific API request to a managed Cisco APIC or Cloud APIC device. A successful exploit could allow the attacker to obtain Administrator credentials on the affected device."
        }
      ],
      "exploits": [
        {
          "lang": "en",
          "value": "The Cisco Product Security Incident Response Team (PSIRT) is not aware of any public announcements or malicious use of the vulnerability that is described in this advisory."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "NETWORK",
            "availabilityImpact": "HIGH",
            "baseScore": 8.8,
            "baseSeverity": "HIGH",
            "confidentialityImpact": "HIGH",
            "integrityImpact": "HIGH",
            "privilegesRequired": "LOW",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
            "version": "3.1"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-636",
              "description": "CWE-636",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2021-08-25T19:10:21.000Z",
        "orgId": "d1c1063e-7a18-46af-9102-31f8928bc633",
        "shortName": "cisco"
      },
      "references": [
        {
          "name": "20210825 Cisco Application Policy Infrastructure Controller Privilege Escalation Vulnerability",
          "tags": [
            "vendor-advisory",
            "x_refsource_CISCO"
          ],
          "url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-capic-pesc-pkmGK4J"
        }
      ],
      "source": {
        "advisory": "cisco-sa-capic-pesc-pkmGK4J",
        "defect": [
          [
            "CSCvw57550"
          ]
        ],
        "discovery": "INTERNAL"
      },
      "title": "Cisco Application Policy Infrastructure Controller Privilege Escalation Vulnerability",
      "x_legacyV4Record": {
        "CVE_data_meta": {
          "ASSIGNER": "psirt@cisco.com",
          "DATE_PUBLIC": "2021-08-25T16:00:00",
          "ID": "CVE-2021-1578",
          "STATE": "PUBLIC",
          "TITLE": "Cisco Application Policy Infrastructure Controller Privilege Escalation Vulnerability"
        },
        "affects": {
          "vendor": {
            "vendor_data": [
              {
                "product": {
                  "product_data": [
                    {
                      "product_name": "Cisco Application Policy Infrastructure Controller (APIC)",
                      "version": {
                        "version_data": [
                          {
                            "version_value": "n/a"
                          }
                        ]
                      }
                    }
                  ]
                },
                "vendor_name": "Cisco"
              }
            ]
          }
        },
        "data_format": "MITRE",
        "data_type": "CVE",
        "data_version": "4.0",
        "description": {
          "description_data": [
            {
              "lang": "eng",
              "value": "A vulnerability in an API endpoint of Cisco Application Policy Infrastructure Controller (APIC) and Cisco Cloud Application Policy Infrastructure Controller (Cloud APIC) could allow an authenticated, remote attacker to elevate privileges to Administrator on an affected device. This vulnerability is due to an improper policy default setting. An attacker could exploit this vulnerability by using a non-privileged credential for Cisco ACI Multi-Site Orchestrator (MSO) to send a specific API request to a managed Cisco APIC or Cloud APIC device. A successful exploit could allow the attacker to obtain Administrator credentials on the affected device."
            }
          ]
        },
        "exploit": [
          {
            "lang": "en",
            "value": "The Cisco Product Security Incident Response Team (PSIRT) is not aware of any public announcements or malicious use of the vulnerability that is described in this advisory."
          }
        ],
        "impact": {
          "cvss": {
            "baseScore": "8.8",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
            "version": "3.0"
          }
        },
        "problemtype": {
          "problemtype_data": [
            {
              "description": [
                {
                  "lang": "eng",
                  "value": "CWE-636"
                }
              ]
            }
          ]
        },
        "references": {
          "reference_data": [
            {
              "name": "20210825 Cisco Application Policy Infrastructure Controller Privilege Escalation Vulnerability",
              "refsource": "CISCO",
              "url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-capic-pesc-pkmGK4J"
            }
          ]
        },
        "source": {
          "advisory": "cisco-sa-capic-pesc-pkmGK4J",
          "defect": [
            [
              "CSCvw57550"
            ]
          ],
          "discovery": "INTERNAL"
        }
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "d1c1063e-7a18-46af-9102-31f8928bc633",
    "assignerShortName": "cisco",
    "cveId": "CVE-2021-1578",
    "datePublished": "2021-08-25T19:10:21.106Z",
    "dateReserved": "2020-11-13T00:00:00.000Z",
    "dateUpdated": "2024-11-07T22:03:16.741Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.1"
}

GHSA-232P-VWFF-86MP

Vulnerability from github – Published: 2023-04-04 21:13 – Updated: 2023-04-05 23:16
VLAI
Summary
Docker Swarm encrypted overlay network may be unauthenticated
Details

Moby 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 is commonly referred to as Docker.

Swarm 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 and supporting network code.

The 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, 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.

Encrypted overlay networks function by encapsulating the VXLAN datagrams through the use of the IPsec Encapsulating Security Payload protocol in 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.

When setting an endpoint up on an encrypted overlay network, Moby installs three iptables (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's VNI field, so that IPSec guarantees can be enforced on encrypted overlay networks without interfering with other overlay networks or other users of VXLAN.

Two iptables rules serve to filter incoming VXLAN datagrams with a VNI that corresponds to an encrypted network and discards unencrypted datagrams. The rules are appended to the end of the INPUT filter chain, following any rules that have been previously set by the system administrator. Administrator-set rules take precedence over the rules Moby sets to discard unencrypted VXLAN datagrams, which can potentially admit unencrypted datagrams that should have been discarded.

On Red Hat Enterprise Linux and derivatives such as CentOS and Rocky, the xt_u32 module has been: * moved to the kernel-modules-extra package and no longer installed by default in RHEL 8.3 * officially deprecated in RHEL 8.6 * removed completely in RHEL 9

These rules are not created when xt_u32 is unavailable, even though the container is still attached to the network.

Impact

Encrypted overlay networks on affected configurations 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 injection of arbitrary Ethernet frames can enable a Denial of Service attack. A sophisticated attacker may be able to establish a UDP or TCP connection by way of the container’s outbound gateway that would otherwise be blocked by a stateful firewall, or carry out other escalations beyond simple injection by smuggling packets into the overlay network.

Patches

Patches are available in Moby releases 23.0.3, and 20.10.24. As Mirantis Container Runtime's 20.10 releases are numbered differently, users of that platform should update to 20.10.16.

Workarounds

  • Close the VXLAN port (by default, UDP port 4789) to incoming traffic at the Internet boundary (see GHSA-vwm3-crmr-xfxw) to prevent all VXLAN packet injection.
  • Ensure that the xt_u32 kernel module is available on all nodes of the Swarm cluster.

Background

  • #43382 partially discussed this concern, but did not consider the security implications.
  • Mirantis FIELD-5788 essentially duplicates #43382, and was created six months earlier; it similarly overlooked the security implications.
  • #45118 is the ancestor of the final patches, and was where the security implications were discovered.

Related

Show details on source website

{
  "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-28840"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-420",
      "CWE-636"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-04-04T21:13:06Z",
    "nvd_published_at": "2023-04-04T22:15:00Z",
    "severity": "HIGH"
  },
  "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\n[Two iptables rules](https://github.com/moby/libnetwork/blob/d9fae4c73daf76c3b0f77e14b45b8bf612ba764d/drivers/overlay/encryption.go#L230-L234) serve to filter incoming VXLAN datagrams with a VNI that corresponds to an encrypted network and discards unencrypted datagrams. The rules are appended to the end of the `INPUT` filter chain, following any rules that have been previously set by the system administrator. Administrator-set rules take precedence over the rules Moby sets to discard unencrypted VXLAN datagrams, which can potentially admit unencrypted datagrams that should have been discarded.\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\nThese rules are 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 configurations 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.\n\nThe injection of arbitrary Ethernet frames can enable a Denial of Service attack. A sophisticated attacker may be able to establish a UDP or TCP connection by way of the container\u2019s outbound gateway that would otherwise be blocked by a stateful firewall, or carry out other escalations beyond simple injection by smuggling packets into the overlay network.\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 incoming traffic at the Internet boundary (see [GHSA-vwm3-crmr-xfxw](https://github.com/moby/moby/security/advisories/GHSA-vwm3-crmr-xfxw)) to prevent all VXLAN packet injection.\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-28841: Encrypted overlay network traffic may be unencrypted](https://github.com/moby/moby/security/advisories/GHSA-33pg-m6jh-5237)\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-232p-vwff-86mp",
  "modified": "2023-04-05T23:16:22Z",
  "published": "2023-04-04T21:13:06Z",
  "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-28840"
    },
    {
      "type": "WEB",
      "url": "https://github.com/moby/moby/issues/43382"
    },
    {
      "type": "WEB",
      "url": "https://github.com/moby/moby/pull/45118"
    },
    {
      "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:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Docker Swarm encrypted overlay network may be unauthenticated"
}

GHSA-2V5F-5R6W-P67R

Vulnerability from github – Published: 2026-05-19 15:39 – Updated: 2026-05-19 15:39
VLAI
Summary
MCP Registry: OCI validator skips ownership check on upstream rate limits
Details

OCI ownership validation fails open on upstream rate limits, allowing attacker to claim arbitrary public OCI images under their own namespace

Severity: Low (re-scored post-triage; see Maintainer triage note below) Affected: modelcontextprotocol/registry main branch at commit fe0cb3b (current HEAD as of 2026-05-09). Live deployment: https://registry.modelcontextprotocol.io (per repo README). Route: GitHub private security advisory (per repo SECURITY.md).


Title

OCI ownership validation skips label-match check when upstream OCI registry returns HTTP 429, letting any authenticated publisher bind their io.github.<user>/* namespace to OCI images they do not control.

Summary

internal/validators/registries/oci.go:104-119 fails open on http.StatusTooManyRequests: when the registry's anonymous fetch to the upstream OCI registry is rate-limited, ValidateOCI returns nil and the publish is accepted without ever running the io.modelcontextprotocol.server.name label-match check at lines 122-141. That label check is the only cross-system ownership proof the registry applies to OCI packages — every other registry type (NPM, PyPI, NuGet, MCPB) treats a non-200 upstream response as a hard error.

The fail-open trigger is attacker-controllable. The registry uses authn.Anonymous against Docker Hub, which is rate-limited to 100 manifest pulls per 6 hours per egress IP, and the production NGINX rate limit allows 180 publishes/minute (3 RPS, burst 540) per source IP. A single attacker from a single IP can exhaust the registry's shared anonymous quota in roughly 33 seconds, then submit a final publish that points packages[].identifier at a Docker Hub image they do not own. The validator hits the 429 fail-open branch, returns nil, and the registry stores a record under the attacker's namespace claiming the unrelated image as its package payload, with no label proof in evidence.

The fail-open is also reached without an attacker present. Docker Hub routinely 429s busy egress IPs during organic traffic, so publishes during those windows skip OCI ownership validation silently.

Vulnerable code

internal/validators/registries/oci.go:97-142:

img, err := remote.Image(ref, remote.WithAuth(authn.Anonymous), remote.WithContext(timeoutCtx))
if err != nil {
    if errors.Is(err, context.DeadlineExceeded) {
        return fmt.Errorf("OCI image validation timed out after 30 seconds for '%s'. The registry may be slow or unreachable", pkg.Identifier)
    }

    var transportErr *transport.Error
    if errors.As(err, &transportErr) {
        switch transportErr.StatusCode {
        case http.StatusTooManyRequests:
            // Rate limited - skip validation to avoid blocking publishers
            // This is intentional: we prioritize UX over strict validation during high traffic
            log.Printf("Skipping OCI validation for %s due to rate limiting", pkg.Identifier)
            return nil                                              // <-- FAIL-OPEN
        case http.StatusNotFound:
            return fmt.Errorf("OCI image '%s' does not exist in the registry", pkg.Identifier)
        case http.StatusUnauthorized, http.StatusForbidden:
            return fmt.Errorf("OCI image '%s' is private or requires authentication. Only public images are supported", pkg.Identifier)
        }
    }
    return fmt.Errorf("failed to fetch OCI image: %w", err)
}

// Get the image config which contains labels
configFile, err := img.ConfigFile()
if err != nil {
    return fmt.Errorf("failed to get image config: %w", err)
}

// Validate the MCP server name label
if configFile.Config.Labels == nil {
    return fmt.Errorf("OCI image '%s' is missing required annotation. Add this to your Dockerfile: LABEL io.modelcontextprotocol.server.name=\"%s\"", pkg.Identifier, serverName)
}

mcpName, exists := configFile.Config.Labels["io.modelcontextprotocol.server.name"]
if !exists {
    return fmt.Errorf("OCI image '%s' is missing required annotation. Add this to your Dockerfile: LABEL io.modelcontextprotocol.server.name=\"%s\"", pkg.Identifier, serverName)
}

if mcpName != serverName {
    return fmt.Errorf("OCI image ownership validation failed. Expected annotation 'io.modelcontextprotocol.server.name' = '%s', got '%s'", serverName, mcpName)
}

The fail-open returns before any of the three label-match guards run.

The validator is reached on every publish per internal/service/registry_service.go:151-158, gated by cfg.EnableRegistryValidation, which defaults to true in internal/config/config.go:18.

Reachability and authorization

POST /v0/publish (and /v0.1/publish) is registered with bearer-JWT auth in internal/api/handlers/v0/publish.go:30-50. JWTs are issued by /v0/auth/github-at (internal/api/handlers/v0/auth/github_at.go:46-67), which exchanges any GitHub OAuth access token for a 5-minute registry JWT carrying Permission{Action: Publish, ResourcePattern: "io.github.<login>/*"}. Any free GitHub account can mint such a JWT, so the publish path is reachable to anyone on the internet at the cost of a GitHub account.

Trigger conditions

  • internal/validators/registries/oci.go:97: anonymous Docker Hub auth, subject to the 100 manifest-pulls/6h/IP unauthenticated rate limit Docker Hub publishes.
  • deploy/pkg/k8s/registry.go:330-331: production NGINX limits incoming requests to 180/minute per source IP with a 3× burst multiplier (540).
  • A single source IP at 3 RPS exhausts the registry's anonymous Docker Hub quota in roughly 33 seconds. Each /publish against an allowlisted OCI identifier in internal/validators/registries/oci.go:29-42 (docker.io / registry-1.docker.io / index.docker.io / ghcr.io / quay.io / mcr.microsoft.com / *.pkg.dev / *.azurecr.io) consumes one slot, including publishes that go on to fail with the missing-annotation error after the manifest is fetched.
  • Once Docker Hub starts returning 429, every subsequent publish hits the fail-open branch until the quota replenishes.

Attacker chain

  1. Free GitHub account attackerPOST /v0/auth/github-at → registry JWT with Permission{Action: Publish, ResourcePattern: "io.github.attacker/*"}.
  2. From a single IP, send ~100 publishes whose packages[].identifier references real public Docker Hub images that lack the io.modelcontextprotocol.server.name label (e.g. docker.io/library/alpine:latest, docker.io/library/nginx:latest, …). Each publish fails with "OCI image is missing required annotation" but consumes one anonymous-quota slot from the registry's shared egress IP.
  3. While the egress IP is rate-limited by Docker Hub, submit the final publish: name = "io.github.attacker/<typo-squat-name>", packages[].registryType = "oci", packages[].identifier = "docker.io/<reputable-org>/<reputable-image>:<tag>".
  4. ValidateOCI calls remote.Image(ref, authn.Anonymous, …); Docker Hub returns 429; transportErr.StatusCode == http.StatusTooManyRequests matches the fail-open branch; ValidateOCI returns nil; ValidatePackage returns nil; validateRegistryOwnership returns nil; the publish proceeds and CreateServer writes the record. The registry now publishes a server record under io.github.attacker/<typo-squat-name> that asserts the reputable image as its package payload, without ever inspecting that image's labels.

Boundary delta

Starting capability After exploit
Identity Holder of a fresh io.github.<attacker> GitHub account Same
Publish scope io.github.<attacker>/* only io.github.<attacker>/* only (unchanged)
OCI claim scope OCI images the attacker controls and has labelled with io.modelcontextprotocol.server.name = io.github.<attacker>/<name> Any public OCI image at any allowlisted registry, regardless of label

The attacker's namespace stays bounded. What changes is that the registry's claim "this OCI image is the package payload of this MCP server" is no longer backed by any cross-system proof. The label check at oci.go:122-141 is the only ownership proof for OCI packages; bypassing it lets a publisher under io.github.attacker/* bind a server record to an unrelated image such as docker.io/microsoft/<some-tool>:latest without ever touching that image. Combined with how MCP clients render server-list entries — image identifier shown next to the namespace — the result is typo-squat / impersonation in registry search and discovery surfaces, with the actual image content delivered untouched from its real owner.

The same fail-open is reached without any attacker action whenever Docker Hub rate-limits the registry's egress IP for organic reasons. In that mode, the OCI ownership check is effectively non-functional for the duration of the limit window, even for legitimate publishers.

Cross-validator comparison (negative control)

The other registry-type validators do not fail-open on rate-limit responses:

  • internal/validators/registries/npm.go:72-74if resp.StatusCode != http.StatusOK { return error }.
  • internal/validators/registries/pypi.go:76-78 — same shape; 429 surfaces as "PyPI package '%s' not found (status: %d)".
  • internal/validators/registries/nuget.go:253 — non-OK response paths return "NuGet README request returned status %d", the publish fails closed.
  • internal/validators/registries/mcpb.go:84-91 — a HEAD that does not return 200 or a 3xx with Location is treated as inaccessible.

OCI is the only validator that converts an upstream rate-limit into a successful ownership attestation.

Suggested fix

Two options, either alone, or both for defence-in-depth:

  1. Remove the fail-open. Replace go case http.StatusTooManyRequests: log.Printf("Skipping OCI validation for %s due to rate limiting", pkg.Identifier) return nil with an error of the same shape the other validators use (return fmt.Errorf("OCI registry is currently rate-limiting validations for '%s'; please retry shortly", pkg.Identifier)). The handler call sites in validateRegistryOwnership already propagate the error to a 400 response.
  2. Replace authn.Anonymous at internal/validators/registries/oci.go:97 with an authenticated token whose quota is isolated from organic anonymous traffic to the registry's egress IP. Docker Hub authenticated pulls are 200/6h per token; ghcr.io / quay.io / *.pkg.dev / *.azurecr.io each have their own auth flows. This removes the easy attacker-side trigger and reduces organic fail-open windows.

If a fail-open path is retained for UX reasons, queue the publish for re-validation when the upstream registry recovers, instead of marking it accepted on first attempt.

Proof of concept

The refreshed PoC drives the publish path, not only the validator branch:

service.CreateServer
  -> validators.ValidatePublishRequest
  -> registries.ValidateOCI
  -> database.CreateServer

It runs inside the checked-out module, uses the real service and validator code, and substitutes only the database with a minimal in-memory implementation so the proof can run without a local Postgres stack. To keep the proof localhost-only, the runner temporarily adds the in-process mock OCI host to the unexported OCI allowlist. It does not contact Docker Hub, the production registry, or any external service.

To run:

bash outputs/poc-evidence/2026-05-12-mcp-registry-publish-path/run.sh

Captured transcript:

=== modelcontextprotocol/registry publish-path OCI 429 fail-open PoC ===
Path exercised: service.CreateServer -> validators.ValidatePublishRequest -> registries.ValidateOCI -> DB CreateServer

--- negative control: upstream 404 ---
[setup] temporarily allowlisted mock OCI host 127.0.0.1:39067 for localhost-only proof
[setup] publish identifier=127.0.0.1:39067/reputable-org/reputable-image:latest
[mock-oci] GET /v2/ -> 404
[publish] rejected: registry validation failed for package 0 (127.0.0.1:39067/reputable-org/reputable-image:latest): OCI image '127.0.0.1:39067/reputable-org/reputable-image:latest' does not exist in the registry

--- BUG: upstream 429 ---
[setup] temporarily allowlisted mock OCI host 127.0.0.1:40487 for localhost-only proof
[setup] publish identifier=127.0.0.1:40487/reputable-org/reputable-image:latest
[mock-oci] GET /v2/ -> 429
[memdb] AcquirePublishLock(io.github.attacker/typosquat-tool)
[memdb] CreateServer stored name=io.github.attacker/typosquat-tool version=1.0.1 package=127.0.0.1:40487/reputable-org/reputable-image:latest
[publish] accepted/stored packages=[{"registryType":"oci","identifier":"127.0.0.1:40487/reputable-org/reputable-image:latest","transport":{"type":"stdio"}}]
PUBLISH_PATH_RESULT: ACCEPTED_UNVERIFIED_OCI_PACKAGE_AFTER_429

Exit code 0. SHA-256 values:

acf7121111c19acaca1c99a3c08079213794ffc4feb63e545ec814bd6cd85984  transcript.txt
340e7a81740e9f14cadc144d4e640a1d497ce3e6696a3d9ea99d63e05c5edd71  publish_path_runner.go
c970f08d6b79852308ad931da85dd64a65fe373d3c988018de09a7e4c7c345a4  run.sh

The end-to-end attacker flow against production was not executed. No publish was sent against registry.modelcontextprotocol.io. No attacker namespace was registered on the live service. The local proof shows the critical property: when the actual publish validator sees an OCI 429, the service proceeds to create a server record containing the unverified OCI package identifier.

Severity rationale

Maintainer triage (2026-05-13): after review the maintainer settled on Low (3.5, CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:L/A:N). Impact stays within the attacker's own namespace and image bytes delivered to clients are unchanged. See the comment thread for reasoning. Reporter's original write-up preserved below.

Medium. Auth-bypass class — the attacker bypasses the only ownership proof for OCI packages, and the fail-open trigger is attacker-controllable from a single IP at modest cost. The blast radius is bounded to publication misrepresentation under the attacker's own namespace; the actual image content stays under its rightful owner. Combined with normal MCP-client search and discovery surfaces, this is sufficient for impersonation / typo-squat where the rendered image identifier implies authorship the registry could not actually attest.

The fail-open also activates under normal traffic when Docker Hub rate-limits the egress IP, so the OCI ownership check is in practice intermittent rather than absent — both modes are bug states.

Disclosure preferences

Report through the GitHub Security Advisory process per repo SECURITY.md. Happy to keep details private until a fix is in motion. If a public GHSA / CVE / release note is published, please credit the report to Ryan Vonbrubeck / @dodge1218.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/modelcontextprotocol/registry"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.7.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-45781"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-636"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-19T15:39:55Z",
    "nvd_published_at": "2026-05-14T21:16:48Z",
    "severity": "LOW"
  },
  "details": "# OCI ownership validation fails open on upstream rate limits, allowing attacker to claim arbitrary public OCI images under their own namespace\n\nSeverity: Low (re-scored post-triage; see Maintainer triage note below)\nAffected: `modelcontextprotocol/registry` main branch at commit `fe0cb3b` (current HEAD as of 2026-05-09).\nLive deployment: `https://registry.modelcontextprotocol.io` (per repo README).\nRoute: GitHub private security advisory (per repo SECURITY.md).\n\n---\n\n## Title\n\nOCI ownership validation skips label-match check when upstream OCI registry returns HTTP 429, letting any authenticated publisher bind their `io.github.\u003cuser\u003e/*` namespace to OCI images they do not control.\n\n## Summary\n\n`internal/validators/registries/oci.go:104-119` fails open on `http.StatusTooManyRequests`: when the\nregistry\u0027s anonymous fetch to the upstream OCI registry is rate-limited, `ValidateOCI` returns `nil`\nand the publish is accepted without ever running the\n`io.modelcontextprotocol.server.name` label-match check at lines 122-141. That label check is the\nonly cross-system ownership proof the registry applies to OCI packages \u2014 every other registry type\n(NPM, PyPI, NuGet, MCPB) treats a non-200 upstream response as a hard error.\n\nThe fail-open trigger is attacker-controllable. The registry uses `authn.Anonymous` against Docker\nHub, which is rate-limited to 100 manifest pulls per 6 hours per egress IP, and the production\nNGINX rate limit allows 180 publishes/minute (3 RPS, burst 540) per source IP. A single attacker\nfrom a single IP can exhaust the registry\u0027s shared anonymous quota in roughly 33 seconds, then\nsubmit a final publish that points `packages[].identifier` at a Docker Hub image they do not own.\nThe validator hits the 429 fail-open branch, returns `nil`, and the registry stores a record under\nthe attacker\u0027s namespace claiming the unrelated image as its package payload, with no label proof\nin evidence.\n\nThe fail-open is also reached without an attacker present. Docker Hub routinely 429s busy egress IPs\nduring organic traffic, so publishes during those windows skip OCI ownership validation silently.\n\n## Vulnerable code\n\n`internal/validators/registries/oci.go:97-142`:\n\n```go\nimg, err := remote.Image(ref, remote.WithAuth(authn.Anonymous), remote.WithContext(timeoutCtx))\nif err != nil {\n    if errors.Is(err, context.DeadlineExceeded) {\n        return fmt.Errorf(\"OCI image validation timed out after 30 seconds for \u0027%s\u0027. The registry may be slow or unreachable\", pkg.Identifier)\n    }\n\n    var transportErr *transport.Error\n    if errors.As(err, \u0026transportErr) {\n        switch transportErr.StatusCode {\n        case http.StatusTooManyRequests:\n            // Rate limited - skip validation to avoid blocking publishers\n            // This is intentional: we prioritize UX over strict validation during high traffic\n            log.Printf(\"Skipping OCI validation for %s due to rate limiting\", pkg.Identifier)\n            return nil                                              // \u003c-- FAIL-OPEN\n        case http.StatusNotFound:\n            return fmt.Errorf(\"OCI image \u0027%s\u0027 does not exist in the registry\", pkg.Identifier)\n        case http.StatusUnauthorized, http.StatusForbidden:\n            return fmt.Errorf(\"OCI image \u0027%s\u0027 is private or requires authentication. Only public images are supported\", pkg.Identifier)\n        }\n    }\n    return fmt.Errorf(\"failed to fetch OCI image: %w\", err)\n}\n\n// Get the image config which contains labels\nconfigFile, err := img.ConfigFile()\nif err != nil {\n    return fmt.Errorf(\"failed to get image config: %w\", err)\n}\n\n// Validate the MCP server name label\nif configFile.Config.Labels == nil {\n    return fmt.Errorf(\"OCI image \u0027%s\u0027 is missing required annotation. Add this to your Dockerfile: LABEL io.modelcontextprotocol.server.name=\\\"%s\\\"\", pkg.Identifier, serverName)\n}\n\nmcpName, exists := configFile.Config.Labels[\"io.modelcontextprotocol.server.name\"]\nif !exists {\n    return fmt.Errorf(\"OCI image \u0027%s\u0027 is missing required annotation. Add this to your Dockerfile: LABEL io.modelcontextprotocol.server.name=\\\"%s\\\"\", pkg.Identifier, serverName)\n}\n\nif mcpName != serverName {\n    return fmt.Errorf(\"OCI image ownership validation failed. Expected annotation \u0027io.modelcontextprotocol.server.name\u0027 = \u0027%s\u0027, got \u0027%s\u0027\", serverName, mcpName)\n}\n```\n\nThe fail-open returns before any of the three label-match guards run.\n\nThe validator is reached on every publish per `internal/service/registry_service.go:151-158`, gated by\n`cfg.EnableRegistryValidation`, which defaults to `true` in `internal/config/config.go:18`.\n\n## Reachability and authorization\n\n`POST /v0/publish` (and `/v0.1/publish`) is registered with bearer-JWT auth in\n`internal/api/handlers/v0/publish.go:30-50`. JWTs are issued by `/v0/auth/github-at`\n(`internal/api/handlers/v0/auth/github_at.go:46-67`), which exchanges any GitHub OAuth access token for\na 5-minute registry JWT carrying `Permission{Action: Publish, ResourcePattern: \"io.github.\u003clogin\u003e/*\"}`.\nAny free GitHub account can mint such a JWT, so the publish path is reachable to anyone on the\ninternet at the cost of a GitHub account.\n\n## Trigger conditions\n\n- `internal/validators/registries/oci.go:97`: anonymous Docker Hub auth, subject to the 100\n  manifest-pulls/6h/IP unauthenticated rate limit Docker Hub publishes.\n- `deploy/pkg/k8s/registry.go:330-331`: production NGINX limits incoming requests to 180/minute\n  per source IP with a 3\u00d7 burst multiplier (540).\n- A single source IP at 3 RPS exhausts the registry\u0027s anonymous Docker Hub quota in roughly 33\n  seconds. Each `/publish` against an allowlisted OCI identifier in\n  `internal/validators/registries/oci.go:29-42` (docker.io / registry-1.docker.io / index.docker.io\n  / ghcr.io / quay.io / mcr.microsoft.com / `*.pkg.dev` / `*.azurecr.io`) consumes one slot,\n  including publishes that go on to fail with the missing-annotation error after the manifest is\n  fetched.\n- Once Docker Hub starts returning 429, every subsequent publish hits the fail-open branch until\n  the quota replenishes.\n\n## Attacker chain\n\n1. Free GitHub account `attacker` \u2192 `POST /v0/auth/github-at` \u2192 registry JWT with\n   `Permission{Action: Publish, ResourcePattern: \"io.github.attacker/*\"}`.\n2. From a single IP, send ~100 publishes whose `packages[].identifier` references real public\n   Docker Hub images that lack the `io.modelcontextprotocol.server.name` label\n   (e.g. `docker.io/library/alpine:latest`, `docker.io/library/nginx:latest`, \u2026). Each publish\n   fails with \"OCI image is missing required annotation\" but consumes one anonymous-quota slot\n   from the registry\u0027s shared egress IP.\n3. While the egress IP is rate-limited by Docker Hub, submit the final publish:\n   `name = \"io.github.attacker/\u003ctypo-squat-name\u003e\"`,\n   `packages[].registryType = \"oci\"`,\n   `packages[].identifier = \"docker.io/\u003creputable-org\u003e/\u003creputable-image\u003e:\u003ctag\u003e\"`.\n4. `ValidateOCI` calls `remote.Image(ref, authn.Anonymous, \u2026)`; Docker Hub returns 429;\n   `transportErr.StatusCode == http.StatusTooManyRequests` matches the fail-open branch;\n   `ValidateOCI` returns `nil`; `ValidatePackage` returns `nil`;\n   `validateRegistryOwnership` returns `nil`; the publish proceeds and `CreateServer` writes the\n   record. The registry now publishes a server record under `io.github.attacker/\u003ctypo-squat-name\u003e`\n   that asserts the reputable image as its package payload, without ever inspecting that image\u0027s\n   labels.\n\n## Boundary delta\n\n| | Starting capability | After exploit |\n|---|---|---|\n| Identity | Holder of a fresh `io.github.\u003cattacker\u003e` GitHub account | Same |\n| Publish scope | `io.github.\u003cattacker\u003e/*` only | `io.github.\u003cattacker\u003e/*` only (unchanged) |\n| OCI claim scope | OCI images the attacker controls and has labelled with `io.modelcontextprotocol.server.name = io.github.\u003cattacker\u003e/\u003cname\u003e` | **Any public OCI image** at any allowlisted registry, regardless of label |\n\nThe attacker\u0027s namespace stays bounded. What changes is that the registry\u0027s claim \"this OCI image is\nthe package payload of this MCP server\" is no longer backed by any cross-system proof. The label\ncheck at `oci.go:122-141` is the only ownership proof for OCI packages; bypassing it lets a\npublisher under `io.github.attacker/*` bind a server record to an unrelated image such as\n`docker.io/microsoft/\u003csome-tool\u003e:latest` without ever touching that image. Combined with how MCP\nclients render server-list entries \u2014 image identifier shown next to the namespace \u2014 the result is\ntypo-squat / impersonation in registry search and discovery surfaces, with the actual image content\ndelivered untouched from its real owner.\n\nThe same fail-open is reached without any attacker action whenever Docker Hub rate-limits the\nregistry\u0027s egress IP for organic reasons. In that mode, the OCI ownership check is effectively\nnon-functional for the duration of the limit window, even for legitimate publishers.\n\n## Cross-validator comparison (negative control)\n\nThe other registry-type validators do not fail-open on rate-limit responses:\n\n- `internal/validators/registries/npm.go:72-74` \u2014 `if resp.StatusCode != http.StatusOK { return error }`.\n- `internal/validators/registries/pypi.go:76-78` \u2014 same shape; 429 surfaces as\n  `\"PyPI package \u0027%s\u0027 not found (status: %d)\"`.\n- `internal/validators/registries/nuget.go:253` \u2014 non-OK response paths return\n  `\"NuGet README request returned status %d\"`, the publish fails closed.\n- `internal/validators/registries/mcpb.go:84-91` \u2014 a HEAD that does not return 200 or a 3xx with\n  `Location` is treated as inaccessible.\n\nOCI is the only validator that converts an upstream rate-limit into a successful ownership\nattestation.\n\n## Suggested fix\n\nTwo options, either alone, or both for defence-in-depth:\n\n1. Remove the fail-open. Replace\n   ```go\n   case http.StatusTooManyRequests:\n       log.Printf(\"Skipping OCI validation for %s due to rate limiting\", pkg.Identifier)\n       return nil\n   ```\n   with an error of the same shape the other validators use (`return fmt.Errorf(\"OCI registry is\n   currently rate-limiting validations for \u0027%s\u0027; please retry shortly\", pkg.Identifier)`). The\n   handler call sites in `validateRegistryOwnership` already propagate the error to a 400 response.\n2. Replace `authn.Anonymous` at `internal/validators/registries/oci.go:97` with an authenticated\n   token whose quota is isolated from organic anonymous traffic to the registry\u0027s egress IP. Docker\n   Hub authenticated pulls are 200/6h per token; ghcr.io / quay.io / `*.pkg.dev` / `*.azurecr.io`\n   each have their own auth flows. This removes the easy attacker-side trigger and reduces organic\n   fail-open windows.\n\nIf a fail-open path is retained for UX reasons, queue the publish for re-validation when the\nupstream registry recovers, instead of marking it accepted on first attempt.\n\n## Proof of concept\n\nThe refreshed PoC drives the publish path, not only the validator branch:\n\n```text\nservice.CreateServer\n  -\u003e validators.ValidatePublishRequest\n  -\u003e registries.ValidateOCI\n  -\u003e database.CreateServer\n```\n\nIt runs inside the checked-out module, uses the real service and validator code, and substitutes only\nthe database with a minimal in-memory implementation so the proof can run without a local Postgres\nstack. To keep the proof localhost-only, the runner temporarily adds the in-process mock OCI host to\nthe unexported OCI allowlist. It does not contact Docker Hub, the production registry, or any\nexternal service.\n\nTo run:\n\n```bash\nbash outputs/poc-evidence/2026-05-12-mcp-registry-publish-path/run.sh\n```\n\nCaptured transcript:\n\n```text\n=== modelcontextprotocol/registry publish-path OCI 429 fail-open PoC ===\nPath exercised: service.CreateServer -\u003e validators.ValidatePublishRequest -\u003e registries.ValidateOCI -\u003e DB CreateServer\n\n--- negative control: upstream 404 ---\n[setup] temporarily allowlisted mock OCI host 127.0.0.1:39067 for localhost-only proof\n[setup] publish identifier=127.0.0.1:39067/reputable-org/reputable-image:latest\n[mock-oci] GET /v2/ -\u003e 404\n[publish] rejected: registry validation failed for package 0 (127.0.0.1:39067/reputable-org/reputable-image:latest): OCI image \u0027127.0.0.1:39067/reputable-org/reputable-image:latest\u0027 does not exist in the registry\n\n--- BUG: upstream 429 ---\n[setup] temporarily allowlisted mock OCI host 127.0.0.1:40487 for localhost-only proof\n[setup] publish identifier=127.0.0.1:40487/reputable-org/reputable-image:latest\n[mock-oci] GET /v2/ -\u003e 429\n[memdb] AcquirePublishLock(io.github.attacker/typosquat-tool)\n[memdb] CreateServer stored name=io.github.attacker/typosquat-tool version=1.0.1 package=127.0.0.1:40487/reputable-org/reputable-image:latest\n[publish] accepted/stored packages=[{\"registryType\":\"oci\",\"identifier\":\"127.0.0.1:40487/reputable-org/reputable-image:latest\",\"transport\":{\"type\":\"stdio\"}}]\nPUBLISH_PATH_RESULT: ACCEPTED_UNVERIFIED_OCI_PACKAGE_AFTER_429\n```\n\nExit code 0. SHA-256 values:\n\n```text\nacf7121111c19acaca1c99a3c08079213794ffc4feb63e545ec814bd6cd85984  transcript.txt\n340e7a81740e9f14cadc144d4e640a1d497ce3e6696a3d9ea99d63e05c5edd71  publish_path_runner.go\nc970f08d6b79852308ad931da85dd64a65fe373d3c988018de09a7e4c7c345a4  run.sh\n```\n\nThe end-to-end attacker flow against production was not executed. No publish was sent against\n`registry.modelcontextprotocol.io`. No attacker namespace was registered on the live service. The\nlocal proof shows the critical property: when the actual publish validator sees an OCI 429, the\nservice proceeds to create a server record containing the unverified OCI package identifier.\n\n## Severity rationale\n\n**Maintainer triage (2026-05-13):** after review the maintainer settled on Low (3.5, `CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:L/A:N`). Impact stays within the attacker\u0027s own namespace and image bytes delivered to clients are unchanged. See the comment thread for reasoning. Reporter\u0027s original write-up preserved below.\n\nMedium. Auth-bypass class \u2014 the attacker bypasses the only ownership proof for OCI packages, and the\nfail-open trigger is attacker-controllable from a single IP at modest cost. The blast radius is\nbounded to publication misrepresentation under the attacker\u0027s own namespace; the actual image\ncontent stays under its rightful owner. Combined with normal MCP-client search and discovery\nsurfaces, this is sufficient for impersonation / typo-squat where the rendered image identifier\nimplies authorship the registry could not actually attest.\n\nThe fail-open also activates under normal traffic when Docker Hub rate-limits the egress IP, so the\nOCI ownership check is in practice intermittent rather than absent \u2014 both modes are bug states.\n\n## Disclosure preferences\n\nReport through the GitHub Security Advisory process per repo SECURITY.md. Happy to keep details\nprivate until a fix is in motion. If a public GHSA / CVE / release note is published, please credit\nthe report to **Ryan Vonbrubeck / @dodge1218**.",
  "id": "GHSA-2v5f-5r6w-p67r",
  "modified": "2026-05-19T15:39:56Z",
  "published": "2026-05-19T15:39:55Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/modelcontextprotocol/registry/security/advisories/GHSA-2v5f-5r6w-p67r"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45781"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/modelcontextprotocol/registry"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "MCP Registry: OCI validator skips ownership check on upstream rate limits"
}

Mitigation
Architecture and Design

Subdivide and allocate resources and components so that a failure in one part does not affect the entire product.

No CAPEC attack patterns related to this CWE.