Common Weakness Enumeration

CWE-636

Allowed-with-Review

Not Failing Securely ('Failing Open')

Abstraction: Class · Status: Draft

API response cwe.mitre.org

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.

91 vulnerabilities reference this CWE, most recent first.

GHSA-RMHQ-3PJ8-86QJ

Vulnerability from github – Published: 2026-03-09 09:30 – Updated: 2026-03-09 09:30
VLAI
Details

An administrator may attempt to block all networks by specifying "*" or "all" as the network identifier. However, these values are not supported and do not trigger any validation error. Instead, they are silently interpreted as network 0 which results in no networks being blocked at all.

Severity
4.9 (Medium)
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-41759"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-636"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-09T09:15:59Z",
    "severity": "MODERATE"
  },
  "details": "An administrator may attempt to block all networks by specifying \"\\*\" or \"all\" as the network identifier. However, these values are not supported and do not trigger any validation error. Instead, they are silently interpreted as network 0 which results in no networks being blocked at all.",
  "id": "GHSA-rmhq-3pj8-86qj",
  "modified": "2026-03-09T09:30:30Z",
  "published": "2026-03-09T09:30:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-41759"
    },
    {
      "type": "WEB",
      "url": "https://www.mbs-solutions.de/mbs-2025-0001"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VCGP-9326-PQCP

Vulnerability from github – Published: 2026-05-04 22:01 – Updated: 2026-05-14 20:48
VLAI
Summary
net-imap vulnerable to STARTTLS stripping via invalid response timing
Details

Summary

A man-in-the-middle attacker can cause Net::IMAP#starttls to return "successfully", without starting TLS.

Details

When using Net::IMAP#starttls to upgrade a plaintext connection to use TLS, a man-in-the-middle attacker can inject a tagged OK response with an easily predictable tag. By sending the response before the client finishes sending the command, the command completes "successfully" before the response handler is registered. This allows #starttls to return without error, but the response handler is never invoked, the TLS connection is never established, and the socket remains unencrypted.

This allows man-in-the-middle attackers to perform a STARTTLS stripping attack, unless the client code explicitly checks Net::IMAP#tls_verified?.

Impact

TLS bypass, leading to cleartext transmission of sensitive information.

Mitigation

  • Upgrade to a patched version of net-imap that raises an exception whenever #starttls does not establish TLS.
  • Connect to an implicit TLS port, rather than use STARTTLS with a cleartext port. This is strongly recommended anyway:
  • RFC 8314: Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access
  • NO STARTTLS: Why TLS is better without STARTTLS, A Security Analysis of STARTTLS in the Email Context
  • Explicitly verify Net::IMAP#tls_verified? is true, before using the connection after #starttls.
Severity
7.6 (High)
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.6.3"
      },
      "package": {
        "ecosystem": "RubyGems",
        "name": "net-imap"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.6.0"
            },
            {
              "fixed": "0.6.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.5.13"
      },
      "package": {
        "ecosystem": "RubyGems",
        "name": "net-imap"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.5.0"
            },
            {
              "fixed": "0.5.14"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.4.23"
      },
      "package": {
        "ecosystem": "RubyGems",
        "name": "net-imap"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.4.0"
            },
            {
              "fixed": "0.4.24"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.3.9"
      },
      "package": {
        "ecosystem": "RubyGems",
        "name": "net-imap"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.3.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-42246"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-392",
      "CWE-393",
      "CWE-636",
      "CWE-754",
      "CWE-841"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-04T22:01:52Z",
    "nvd_published_at": "2026-05-09T20:16:28Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nA man-in-the-middle attacker can cause `Net::IMAP#starttls` to return \"successfully\", without starting TLS.\n\n### Details\n\nWhen using `Net::IMAP#starttls` to upgrade a plaintext connection to use TLS, a man-in-the-middle attacker can inject a tagged `OK` response with an easily predictable tag.  By sending the response before the client finishes sending the command, the command completes \"successfully\" before the response handler is registered.  This allows `#starttls` to return without error, but the response handler is never invoked, the TLS connection is never established, and the socket remains unencrypted.\n\nThis allows man-in-the-middle attackers to perform a STARTTLS stripping attack, unless the client code explicitly checks `Net::IMAP#tls_verified?`.\n\n### Impact\n\nTLS bypass, leading to cleartext transmission of sensitive information.\n\n### Mitigation\n\n* Upgrade to a patched version of net-imap that raises an exception whenever `#starttls` does not establish TLS.\n* Connect to an implicit TLS port, rather than use `STARTTLS` with a cleartext port.\n  This is strongly recommended anyway:\n  * [RFC 8314](https://www.rfc-editor.org/info/rfc8314): Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access\n  * [NO STARTTLS](https://nostarttls.secvuln.info/): Why TLS is better without STARTTLS, A Security Analysis of STARTTLS in the Email Context\n* Explicitly verify `Net::IMAP#tls_verified?` is `true`, before using the connection after `#starttls`.",
  "id": "GHSA-vcgp-9326-pqcp",
  "modified": "2026-05-14T20:48:01Z",
  "published": "2026-05-04T22:01:52Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/ruby/net-imap/security/advisories/GHSA-vcgp-9326-pqcp"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42246"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ruby/net-imap/commit/0ede4c40b1523dfeaf95777b2678e54cc0fd9618"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ruby/net-imap/commit/24a4e770b43230286a05aa2a9746cdbb3eb8485e"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ruby/net-imap/commit/97e2488fb5401a1783bddd959dde007d9fbce42c"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ruby/net-imap/commit/f79d35bf5833f186e81044c57c843eda30c873da"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/ruby/net-imap"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ruby/net-imap/releases/tag/v0.3.10"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ruby/net-imap/releases/tag/v0.4.24"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ruby/net-imap/releases/tag/v0.5.14"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ruby/net-imap/releases/tag/v0.6.4"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/net-imap/CVE-2026-42246.yml"
    },
    {
      "type": "WEB",
      "url": "https://nostarttls.secvuln.info"
    },
    {
      "type": "WEB",
      "url": "https://www.rfc-editor.org/info/rfc8314"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "net-imap vulnerable to STARTTLS stripping via invalid response timing"
}

GHSA-VJR8-6JJG-P3HJ

Vulnerability from github – Published: 2026-03-09 09:30 – Updated: 2026-03-09 09:30
VLAI
Details

An administrator may attempt to block all traffic by configuring a pass filter with an empty table. However, in UBR, an empty list does not enforce any restrictions and allows all network traffic to pass unfiltered.

Severity
4.9 (Medium)
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-41760"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-636"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-09T09:16:00Z",
    "severity": "MODERATE"
  },
  "details": "An administrator may attempt to block all traffic by configuring a pass filter with an empty table. However, in UBR, an empty list does not enforce any restrictions and allows all network traffic to pass unfiltered.",
  "id": "GHSA-vjr8-6jjg-p3hj",
  "modified": "2026-03-09T09:30:30Z",
  "published": "2026-03-09T09:30:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-41760"
    },
    {
      "type": "WEB",
      "url": "https://www.mbs-solutions.de/mbs-2025-0001"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VM29-7MQ3-9JRG

Vulnerability from github – Published: 2026-03-31 12:31 – Updated: 2026-04-07 18:10
VLAI
Summary
Duplicate Advisory: OpenClaw: Unavailable local auth SecretRefs could fall through to remote credentials in local mode
Details

Duplicate Advisory

This advisory has been withdrawn because it is a duplicate of GHSA-qvr7-g57c-mrc7. This link is maintained to preserve external references.

Original Description

OpenClaw before 2026.3.11 contains a credential fallback vulnerability where unavailable local gateway.auth.token and gateway.auth.password SecretRefs are treated as unset, allowing fallback to remote credentials in local mode. Attackers can exploit misconfigured local auth references to cause CLI and helper paths to select incorrect credential sources, potentially bypassing intended local authentication boundaries.

Severity
2.5 (Low)
CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N
2.0 (Low)
CVSS:4.0/AV:L/AC:H/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "OpenClaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.3.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-636"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-07T18:10:17Z",
    "nvd_published_at": "2026-03-31T12:16:29Z",
    "severity": "LOW"
  },
  "details": "### Duplicate Advisory\nThis advisory has been withdrawn because it is a duplicate of GHSA-qvr7-g57c-mrc7. This link is maintained to preserve external references.\n\n### Original Description\nOpenClaw before 2026.3.11 contains a credential fallback vulnerability where unavailable local gateway.auth.token and gateway.auth.password SecretRefs are treated as unset, allowing fallback to remote credentials in local mode. Attackers can exploit misconfigured local auth references to cause CLI and helper paths to select incorrect credential sources, potentially bypassing intended local authentication boundaries.",
  "id": "GHSA-vm29-7mq3-9jrg",
  "modified": "2026-04-07T18:10:17Z",
  "published": "2026-03-31T12:31:35Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-qvr7-g57c-mrc7"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32970"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-credential-fallback-logic-bypass-via-unavailable-local-auth-secretrefs"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:L/AC:H/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Duplicate Advisory: OpenClaw: Unavailable local auth SecretRefs could fall through to remote credentials in local mode",
  "withdrawn": "2026-04-07T18:10:17Z"
}

GHSA-VP96-HXJ8-P424

Vulnerability from github – Published: 2026-03-16 15:15 – Updated: 2026-03-19 18:28
VLAI
Summary
pyOpenSSL allows TLS connection bypass via unhandled callback exception in set_tlsext_servername_callback
Details

If a user provided callback to set_tlsext_servername_callback raised an unhandled exception, this would result in a connection being accepted. If a user was relying on this callback for any security-sensitive behavior, this could allow bypassing it.

Unhandled exceptions now result in rejecting the connection.

Credit to Leury Castillo for reporting this issue.

Severity
1.7 (Low)
CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:U
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "pyopenssl"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.14.0"
            },
            {
              "fixed": "26.0.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-27448"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-636"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-16T15:15:43Z",
    "nvd_published_at": "2026-03-18T00:16:19Z",
    "severity": "LOW"
  },
  "details": "If a user provided callback to `set_tlsext_servername_callback` raised an unhandled exception, this would result in a connection being accepted. If a user was relying on this callback for any security-sensitive behavior, this could allow bypassing it.\n\nUnhandled exceptions now result in rejecting the connection.\n\nCredit to **Leury Castillo** for reporting this issue.",
  "id": "GHSA-vp96-hxj8-p424",
  "modified": "2026-03-19T18:28:02Z",
  "published": "2026-03-16T15:15:43Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/pyca/pyopenssl/security/advisories/GHSA-vp96-hxj8-p424"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-27448"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pyca/pyopenssl/commit/d41a814759a9fb49584ca8ab3f7295de49a85aa0"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/pyca/pyopenssl"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pyca/pyopenssl/blob/358cbf29c4e364c59930e53a270116249581eaa3/CHANGELOG.rst#L27"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:U",
      "type": "CVSS_V4"
    }
  ],
  "summary": "pyOpenSSL allows TLS connection bypass via unhandled callback exception in set_tlsext_servername_callback"
}

GHSA-VPHW-2W3H-QJ8C

Vulnerability from github – Published: 2025-01-14 18:32 – Updated: 2025-01-14 18:32
VLAI
Details

Windows BitLocker Information Disclosure Vulnerability

Severity
4.2 (Medium)
CVSS:3.1/AV:P/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-21210"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-636"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-01-14T18:15:32Z",
    "severity": "MODERATE"
  },
  "details": "Windows BitLocker Information Disclosure Vulnerability",
  "id": "GHSA-vphw-2w3h-qj8c",
  "modified": "2025-01-14T18:32:02Z",
  "published": "2025-01-14T18:32:02Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21210"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-21210"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:P/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VQRQ-F9P4-XRM2

Vulnerability from github – Published: 2026-07-30 09:31 – Updated: 2026-07-30 09:31
VLAI
Details

An unauthenticated remote attacker can enforce the system to fall back to a firmware partition with an insecure configuration including default credentials. This could allow the attacker to gain SSH access to the system as an unprivileged user "user-app". Charging could be interrupted.

Severity
8.6 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:H
8.3 (High)
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:L/VA:H/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-44094"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-636"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-30T07:16:57Z",
    "severity": "HIGH"
  },
  "details": "An unauthenticated remote attacker can enforce the system to fall back to a firmware partition with an insecure configuration including default credentials. This could allow the attacker to gain SSH access to the system as an unprivileged user \"user-app\". Charging could be interrupted.",
  "id": "GHSA-vqrq-f9p4-xrm2",
  "modified": "2026-07-30T09:31:17Z",
  "published": "2026-07-30T09:31:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44094"
    },
    {
      "type": "WEB",
      "url": "https://www.certvde.com/en/advisories/VDE-2026-008"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:L/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-WHVH-WF3X-G77J

Vulnerability from github – Published: 2026-07-22 23:12 – Updated: 2026-07-22 23:12
VLAI
Summary
JupyterLab: Allowlist/blocklist check in `PyPIExtensionManager.install()` not enforced for direct callers (missing `await`)
Details

The extension allowlist/blocklist check inside PyPIExtensionManager.install() was not enforced due to a missing await. For purposes of JupyterLab this was a secondary defense-in-depth check: install() was intended to enforce the allowlist/blocklist itself for any future uses and users calling this method directly (in addition to the separate check handling requests arriving through the HTTP API). The only runtime symptom was a RuntimeWarning: coroutine 'is_install_allowed' was never awaited.

This has security implications only for deployments that combine all of the following: - a custom extension or downstream integration that imports PyPIExtensionManager and calls install() directly with a package name influenced by untrusted user input (the stock JupyterLab HTTP handler is not affected - it performs its own awaited allowlist check before calling install()); - an allowlist/blocklist configured with the intent of restricting which packages users can install; - the (default) PyPI Extension Manager enabled; and - kernels and terminals disabled or delegated to remote hosts, so that the custom extension's install() call is the only available package-install vector (otherwise a user with kernel access can install packages directly regardless of this check)

Impact

Low. No exposure for stock JupyterLab: the HTTP API and Extension Manager UI enforce the listing through a separate, correctly awaited check. The gap affected only custom extensions or downstream integrations that called the public install() method directly and relied on it to self-enforce.

Patches

JupyterLab v4.6.2 and v4.5.10 contain the patch.

Users of applications that depend on JupyterLab, such as Notebook v7+, should update jupyterlab package too.

Workarounds

No action is required for deployments that only expose extension management through the JupyterLab HTTP API / Extension Manager UI, as that path was already enforcing the listing via the handler's own check. Deployments wanting to disable programmatic extension installation entirely can switch to the read-only extension manager:

--LabApp.extension_manager=readonly

or the following traitlet:

c.LabApp.extension_manager = 'readonly'

You can confirm that the read-only manager is in use from GUI:

image

Severity
0.0 (None)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.6.1"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "jupyterlab"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.6.0"
            },
            {
              "fixed": "4.6.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.5.9"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "jupyterlab"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.5.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-284",
      "CWE-636"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-22T23:12:22Z",
    "nvd_published_at": null,
    "severity": "LOW"
  },
  "details": "The extension allowlist/blocklist check inside `PyPIExtensionManager.install()` was not enforced due to a missing await. For purposes of JupyterLab this was a secondary defense-in-depth check: `install()` was intended to enforce the allowlist/blocklist itself for any future uses and users calling this method directly (in addition to the separate check handling requests arriving through the HTTP API).  The only runtime symptom was a `RuntimeWarning: coroutine \u0027is_install_allowed\u0027 was never awaited.`\n\nThis has security implications only for deployments that combine all of the following:\n- a custom extension or downstream integration that imports `PyPIExtensionManager` and calls `install()` directly with a package name influenced by untrusted user input (the stock JupyterLab HTTP handler is not affected - it performs its own awaited allowlist check before calling `install()`);\n- an allowlist/blocklist configured with the intent of restricting which packages users can install;\n- the (default) PyPI Extension Manager enabled; and\n- kernels and terminals disabled or delegated to remote hosts, so that the custom extension\u0027s `install()` call is the only available package-install vector (otherwise a user with kernel access can install packages directly regardless of this check)\n\n### Impact\n\nLow. No exposure for stock JupyterLab: the HTTP API and Extension Manager UI enforce the listing through a separate, correctly awaited check. The gap affected only custom extensions or downstream integrations that called the public `install()` method directly and relied on it to self-enforce.\n\n### Patches\n\nJupyterLab [`v4.6.2`](https://github.com/jupyterlab/jupyterlab/releases/tag/v4.6.2) and [`v4.5.10`](https://github.com/jupyterlab/jupyterlab/releases/tag/v4.5.10) contain the patch.\n\nUsers of applications that depend on JupyterLab, such as Notebook v7+, should update `jupyterlab` package too.\n\n### Workarounds\n\nNo action is required for deployments that only expose extension management through the JupyterLab HTTP API / Extension Manager UI, as that path was already enforcing the listing via the handler\u0027s own check. Deployments wanting to disable programmatic extension installation entirely can switch to the read-only extension manager:\n\n```bash\n--LabApp.extension_manager=readonly\n```\n\nor the following traitlet:\n\n```python\nc.LabApp.extension_manager = \u0027readonly\u0027\n```\n\nYou can confirm that the read-only manager is in use from GUI:\n\n\u003cimg width=\"293\" height=\"293\" alt=\"image\" src=\"https://github.com/user-attachments/assets/8016c809-633e-4ed0-a5bc-6bc4793caa0f\" /\u003e",
  "id": "GHSA-whvh-wf3x-g77j",
  "modified": "2026-07-22T23:12:22Z",
  "published": "2026-07-22T23:12:22Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/jupyterlab/jupyterlab/security/advisories/GHSA-whvh-wf3x-g77j"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jupyterlab/jupyterlab/pull/19184"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jupyterlab/jupyterlab/pull/19185"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jupyterlab/jupyterlab/pull/19186"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jupyterlab/jupyterlab/commit/be9303f5bcd5308eaeae953c5a3c903046682c2c"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jupyterlab/jupyterlab/commit/f1beab4a2027af4719d6edc07d52d6cf5a39a432"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/jupyterlab/jupyterlab"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jupyterlab/jupyterlab/releases/tag/v4.5.10"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jupyterlab/jupyterlab/releases/tag/v4.6.2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "JupyterLab: Allowlist/blocklist check in `PyPIExtensionManager.install()` not enforced for direct callers (missing `await`)"
}

GHSA-WPWQ-4J6V-78M3

Vulnerability from github – Published: 2026-06-19 14:17 – Updated: 2026-06-19 14:17
VLAI
Summary
guzzlehttp/guzzle: Silent HTTPS-Proxy Downgrade to Cleartext
Details

Impact

The built-in cURL handlers (GuzzleHttp\Handler\CurlHandler and GuzzleHttp\Handler\CurlMultiHandler, used by default whenever the PHP cURL extension is available) accept an https:// proxy — a proxy reached over a TLS-encrypted connection — through the proxy request option, client-level proxy defaults, or proxy environment variables such as http_proxy, https_proxy, HTTPS_PROXY, all_proxy, and ALL_PROXY.

When the installed libcurl does not support HTTPS proxies, behavior depends on the libcurl version/build:

  • libcurl older than 7.50.2 silently treats an https:// proxy as a plaintext http:// proxy. The TLS connection to the proxy is never established, and the proxy leg is cleartext with no error or warning.
  • libcurl 7.50.2 through 7.51.x rejects the unsupported proxy scheme at connect time, so no cleartext exposure occurs, but the failure is late and opaque.
  • libcurl 7.52.0 or newer builds without HTTPS-proxy support also fail at connect time rather than downgrading.

The security-relevant case is the silent downgrade on libcurl older than 7.50.2. An application is affected when it sends requests through one of the built-in cURL handlers, configures an https:// proxy expecting the proxy connection itself to be encrypted, and runs with libcurl older than 7.50.2.

In that configuration, traffic expected to be protected by TLS on the hop to the proxy is transmitted in cleartext. Proxy authentication credentials (the Proxy-Authorization header, proxy userinfo in the proxy URL, or CURLOPT_PROXYUSERPWD) are sent without encryption, and the CONNECT target host and port for tunneled HTTPS requests are exposed. For plain HTTP requests, request headers and bodies are also exposed on the proxy leg. End-to-end HTTPS requests tunneled through the proxy remain protected by their inner TLS session; the exposure is limited to the proxy negotiation and proxy credentials.

Applications that do not configure an https:// proxy are not affected. Installations running libcurl 7.52.0 or newer built with HTTPS-proxy support are not affected because HTTPS proxies work as intended. Installations running libcurl 7.50.2 through 7.51.x, or libcurl 7.52.0 or newer built without HTTPS-proxy support, are not exposed to the silent cleartext downgrade, but Guzzle now rejects those unsupported configurations up front as well. The built-in stream handler is not affected; the issue is specific to the cURL handlers' proxy handling. Low-level cURL options under the curl request option, such as CURLOPT_PROXY or CURLOPT_PROXYTYPE, are advanced custom configuration and remain the caller's responsibility.

Patches

The issue is patched in 7.12.1 and later. Starting in that release, the built-in cURL handlers detect whether the installed libcurl supports HTTPS proxies — requiring both libcurl 7.52.0 or newer and the CURL_VERSION_HTTPS_PROXY feature bit — and reject a request configured through Guzzle's first-class proxy handling with an https:// proxy up front by throwing a GuzzleHttp\Exception\RequestException. No request bytes reach the network when the proxy cannot be used securely. Versions before 7.12.1 are affected by the silent downgrade when run against libcurl older than 7.50.2.

Workarounds

If you cannot upgrade immediately, do not configure an https:// proxy on an installation whose libcurl lacks HTTPS-proxy support, and verify the capability in application code before using one. Remember to check proxy environment variables as well as any explicit proxy option:

$curl = \curl_version();
$httpsProxyBit = \defined('CURL_VERSION_HTTPS_PROXY') ? \CURL_VERSION_HTTPS_PROXY : (1 << 21);

if (\version_compare($curl['version'], '7.52.0', '<') || 0 === ($curl['features'] & $httpsProxyBit)) {
    throw new \RuntimeException('Installed libcurl does not support HTTPS proxies.');
}

Upgrading the system libcurl to 7.52.0 or newer built with HTTPS-proxy support also resolves the underlying unsupported-proxy behavior.

Severity
5.9 (Medium)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "guzzlehttp/guzzle"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "7.12.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-55568"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-311",
      "CWE-319",
      "CWE-636"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-19T14:17:59Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Impact\n\nThe built-in cURL handlers (`GuzzleHttp\\Handler\\CurlHandler` and `GuzzleHttp\\Handler\\CurlMultiHandler`, used by default whenever the PHP cURL extension is available) accept an `https://` proxy \u2014 a proxy reached over a TLS-encrypted connection \u2014 through the `proxy` request option, client-level `proxy` defaults, or proxy environment variables such as `http_proxy`, `https_proxy`, `HTTPS_PROXY`, `all_proxy`, and `ALL_PROXY`.\n\nWhen the installed libcurl does not support HTTPS proxies, behavior depends on the libcurl version/build:\n\n- libcurl older than 7.50.2 silently treats an `https://` proxy as a plaintext `http://` proxy. The TLS connection to the proxy is never established, and the proxy leg is cleartext with no error or warning.\n- libcurl 7.50.2 through 7.51.x rejects the unsupported proxy scheme at connect time, so no cleartext exposure occurs, but the failure is late and opaque.\n- libcurl 7.52.0 or newer builds without HTTPS-proxy support also fail at connect time rather than downgrading.\n\nThe security-relevant case is the silent downgrade on libcurl older than 7.50.2. An application is affected when it sends requests through one of the built-in cURL handlers, configures an `https://` proxy expecting the proxy connection itself to be encrypted, and runs with libcurl older than 7.50.2.\n\nIn that configuration, traffic expected to be protected by TLS on the hop to the proxy is transmitted in cleartext. Proxy authentication credentials (the `Proxy-Authorization` header, proxy userinfo in the proxy URL, or `CURLOPT_PROXYUSERPWD`) are sent without encryption, and the `CONNECT` target host and port for tunneled HTTPS requests are exposed. For plain HTTP requests, request headers and bodies are also exposed on the proxy leg. End-to-end HTTPS requests tunneled through the proxy remain protected by their inner TLS session; the exposure is limited to the proxy negotiation and proxy credentials.\n\nApplications that do not configure an `https://` proxy are not affected. Installations running libcurl 7.52.0 or newer built with HTTPS-proxy support are not affected because HTTPS proxies work as intended. Installations running libcurl 7.50.2 through 7.51.x, or libcurl 7.52.0 or newer built without HTTPS-proxy support, are not exposed to the silent cleartext downgrade, but Guzzle now rejects those unsupported configurations up front as well. The built-in stream handler is not affected; the issue is specific to the cURL handlers\u0027 proxy handling. Low-level cURL options under the `curl` request option, such as `CURLOPT_PROXY` or `CURLOPT_PROXYTYPE`, are advanced custom configuration and remain the caller\u0027s responsibility.\n\n### Patches\n\nThe issue is patched in `7.12.1` and later. Starting in that release, the built-in cURL handlers detect whether the installed libcurl supports HTTPS proxies \u2014 requiring both libcurl 7.52.0 or newer and the `CURL_VERSION_HTTPS_PROXY` feature bit \u2014 and reject a request configured through Guzzle\u0027s first-class proxy handling with an `https://` proxy up front by throwing a `GuzzleHttp\\Exception\\RequestException`. No request bytes reach the network when the proxy cannot be used securely. Versions before `7.12.1` are affected by the silent downgrade when run against libcurl older than 7.50.2.\n\n### Workarounds\n\nIf you cannot upgrade immediately, do not configure an `https://` proxy on an installation whose libcurl lacks HTTPS-proxy support, and verify the capability in application code before using one. Remember to check proxy environment variables as well as any explicit `proxy` option:\n\n```php\n$curl = \\curl_version();\n$httpsProxyBit = \\defined(\u0027CURL_VERSION_HTTPS_PROXY\u0027) ? \\CURL_VERSION_HTTPS_PROXY : (1 \u003c\u003c 21);\n\nif (\\version_compare($curl[\u0027version\u0027], \u00277.52.0\u0027, \u0027\u003c\u0027) || 0 === ($curl[\u0027features\u0027] \u0026 $httpsProxyBit)) {\n    throw new \\RuntimeException(\u0027Installed libcurl does not support HTTPS proxies.\u0027);\n}\n```\n\nUpgrading the system libcurl to 7.52.0 or newer built with HTTPS-proxy support also resolves the underlying unsupported-proxy behavior.",
  "id": "GHSA-wpwq-4j6v-78m3",
  "modified": "2026-06-19T14:17:59Z",
  "published": "2026-06-19T14:17:59Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/guzzle/guzzle/security/advisories/GHSA-wpwq-4j6v-78m3"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/guzzle/guzzle"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "guzzlehttp/guzzle: Silent HTTPS-Proxy Downgrade to Cleartext"
}

GHSA-X5R2-R74C-3W28

Vulnerability from github – Published: 2026-04-14 20:00 – Updated: 2026-04-24 20:36
VLAI
Summary
free5gc UDR improper path validation allows unauthenticated access to Traffic Influence Subscriptions
Details

Summary

An improper path validation vulnerability in the UDR service allows any unauthenticated attacker with access to the 5G Service Based Interface (SBI) to read Traffic Influence Subscriptions by supplying an arbitrary value in place of the expected subs-to-notify path segment.

Details

The endpoint GET /nudr-dr/v2/application-data/influenceData/{influenceId}/{subscriptionId} is intended to only operate on Traffic Influence Subscription resources when influenceId is exactly subs-to-notify.

In the free5GC UDR implementation, the path validation is present but ineffective because the handler does not return after sending the HTTP 404 response. The request handling flow is:

  1. The function HandleApplicationDataInfluenceDataSubsToNotifySubscriptionIdGet in ./free5gc_4-2-1/free5gc/NFs/udr/internal/sbi/api_datarepository.go checks whether influenceId != "subs-to-notify".
  2. If the value is different, it calls c.String(http.StatusNotFound, "404 page not found"), but it does not return afterwards.
  3. Execution continues and the handler still calls s.Processor().ApplicationDataInfluenceDataSubsToNotifySubscriptionIdGetProcedure(c, subscriptionId).
  4. The processor retrieves and returns the subscription identified by subscriptionId even though the path is invalid and the request should have been rejected.

As a result, an attacker can send a request to an invalid path, receive an apparent 404 page not found response, and still obtain the full subscription object in the same HTTP response body.

The missing return after sending the 404 response in api_datarepository.go is the root cause of this vulnerability.

PoC

No authentication is required. Only a valid subscriptionId is needed.

# Create a subscription to obtain a valid subscriptionId
curl -v -X POST "http://<udr-host>/nudr-dr/v2/application-data/influenceData/subs-to-notify" \
  -H "Content-Type: application/json" \
  -d '{
    "notificationUri":"http://evil.com/notify",
    "dnns":["internet"],
    "snssais":[{"sst":1,"sd":"000001"}],
    "supis":["imsi-222777483957498"]
  }'

Example response:

HTTP/1.1 201 Created

Then read it through an invalid path:

curl -v "http://<udr-host>/nudr-dr/v2/application-data/influenceData/WRONGID/87615e16"

Response:

HTTP/1.1 404 Not Found
404 page not found{"dnns":["internet"],"snssais":[{"sst":1,"sd":"000001"}],"supis":["imsi-222777483957498"],"notificationUri":"http://evil.com/notify"}

For comparison, the valid request is:

curl -v "http://<udr-host>/nudr-dr/v2/application-data/influenceData/subs-to-notify/87615e16"

Response:

{"dnns":["internet"],"snssais":[{"sst":1,"sd":"000001"}],"supis":["imsi-222777483957498"],"notificationUri":"http://evil.com/notify"}

Impact

This is an unauthenticated information disclosure vulnerability. Any attacker with network access to the SBI can retrieve Traffic Influence Subscription objects by knowing or guessing a valid subscriptionId, even when using an invalid path that should have been rejected.

The returned objects may contain sensitive subscriber-related information, including SUPIs/IMSIs, DNNs, S-NSSAIs, and callback notificationUri values.

Impacted deployments: any free5GC instance where the SBI is reachable by untrusted parties (e.g., misconfigured network segmentation, rogue NF, or compromised internal host).

Patch

The vulnerability has been confirmed patched by adding the missing return statement in NFs/udr/internal/sbi/api_datarepository.go, function HandleApplicationDataInfluenceDataSubsToNotifySubscriptionIdGet:

go
if influenceId != "subs-to-notify" {
    c.String(http.StatusNotFound, "404 page not found")
    return
}

With the patch applied, requests using an invalid influenceId now correctly return HTTP 404 and do not disclose the targeted subscription data.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
8.7 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/free5gc/udr"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "1.4.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-40247"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-285",
      "CWE-636"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-14T20:00:35Z",
    "nvd_published_at": "2026-04-16T22:16:38Z",
    "severity": "HIGH"
  },
  "details": "### Summary\nAn improper path validation vulnerability in the UDR service allows any unauthenticated attacker with access to the 5G Service Based Interface (SBI) to read Traffic Influence Subscriptions by supplying an arbitrary value in place of the expected `subs-to-notify` path segment.\n\n### Details\nThe endpoint `GET /nudr-dr/v2/application-data/influenceData/{influenceId}/{subscriptionId}` is intended to only operate on Traffic Influence Subscription resources when `influenceId` is exactly `subs-to-notify`.\n\nIn the free5GC UDR implementation, the path validation is present but ineffective because the handler does not return after sending the HTTP 404 response. The request handling flow is:\n\n1. The function `HandleApplicationDataInfluenceDataSubsToNotifySubscriptionIdGet` in `./free5gc_4-2-1/free5gc/NFs/udr/internal/sbi/api_datarepository.go` checks whether `influenceId != \"subs-to-notify\"`.\n2. If the value is different, it calls `c.String(http.StatusNotFound, \"404 page not found\")`, **but it does not return afterwards**.\n3. Execution continues and the handler still calls `s.Processor().ApplicationDataInfluenceDataSubsToNotifySubscriptionIdGetProcedure(c, subscriptionId)`.\n4. The processor retrieves and returns the subscription identified by `subscriptionId` even though the path is invalid and the request should have been rejected.\n\nAs a result, an attacker can send a request to an invalid path, receive an apparent `404 page not found` response, and still obtain the full subscription object in the same HTTP response body.\n\nThe missing `return` after sending the 404 response in `api_datarepository.go` is the root cause of this vulnerability.\n\n### PoC\nNo authentication is required. Only a valid `subscriptionId` is needed.\n\n```bash\n# Create a subscription to obtain a valid subscriptionId\ncurl -v -X POST \"http://\u003cudr-host\u003e/nudr-dr/v2/application-data/influenceData/subs-to-notify\" \\\n  -H \"Content-Type: application/json\" \\\n  -d \u0027{\n    \"notificationUri\":\"http://evil.com/notify\",\n    \"dnns\":[\"internet\"],\n    \"snssais\":[{\"sst\":1,\"sd\":\"000001\"}],\n    \"supis\":[\"imsi-222777483957498\"]\n  }\u0027\n```\nExample response:\n```\nHTTP/1.1 201 Created\n```\n\nThen read it through an invalid path:\n```bash\ncurl -v \"http://\u003cudr-host\u003e/nudr-dr/v2/application-data/influenceData/WRONGID/87615e16\"\n```\nResponse:\n```\nHTTP/1.1 404 Not Found\n404 page not found{\"dnns\":[\"internet\"],\"snssais\":[{\"sst\":1,\"sd\":\"000001\"}],\"supis\":[\"imsi-222777483957498\"],\"notificationUri\":\"http://evil.com/notify\"}\n```\nFor comparison, the valid request is:\n```bash\ncurl -v \"http://\u003cudr-host\u003e/nudr-dr/v2/application-data/influenceData/subs-to-notify/87615e16\"\n```\nResponse:\n```json\n{\"dnns\":[\"internet\"],\"snssais\":[{\"sst\":1,\"sd\":\"000001\"}],\"supis\":[\"imsi-222777483957498\"],\"notificationUri\":\"http://evil.com/notify\"}\n```\n### Impact\nThis is an unauthenticated information disclosure vulnerability. Any attacker with network access to the SBI can retrieve Traffic Influence Subscription objects by knowing or guessing a valid subscriptionId, even when using an invalid path that should have been rejected.\n\nThe returned objects may contain sensitive subscriber-related information, including SUPIs/IMSIs, DNNs, S-NSSAIs, and callback notificationUri values.\n\nImpacted deployments: any free5GC instance where the SBI is reachable by untrusted parties (e.g., misconfigured network segmentation, rogue NF, or compromised internal host).\n\n### Patch\nThe vulnerability has been confirmed patched by adding the missing return statement in NFs/udr/internal/sbi/api_datarepository.go,\nfunction HandleApplicationDataInfluenceDataSubsToNotifySubscriptionIdGet:\n```\ngo\nif influenceId != \"subs-to-notify\" {\n    c.String(http.StatusNotFound, \"404 page not found\")\n    return\n}\n```\nWith the patch applied, requests using an invalid influenceId now correctly return HTTP 404 and do not disclose the targeted subscription data.",
  "id": "GHSA-x5r2-r74c-3w28",
  "modified": "2026-04-24T20:36:20Z",
  "published": "2026-04-14T20:00:35Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/free5gc/free5gc/security/advisories/GHSA-x5r2-r74c-3w28"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-40247"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/free5gc/udr"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "free5gc UDR improper path validation allows unauthenticated access to Traffic Influence Subscriptions"
}
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.

← Back to the CWE list