Common Weakness Enumeration

CWE-306

Allowed

Missing Authentication for Critical Function

Abstraction: Base · Status: Draft

API response cwe.mitre.org

The product does not perform any authentication for functionality that requires a provable user identity or consumes a significant amount of resources.

5054 vulnerabilities reference this CWE, most recent first.

GHSA-436H-C7MW-9WGF

Vulnerability from github – Published: 2026-10-21 21:32 – Updated: 2026-10-22 00:31
VLAI
Details

Apache Pulsar Manager is a web console for administering Apache Pulsar clusters. It has its own user accounts and login, and it can be configured with an HTTP authentication credential, such as a token, that it uses to call the Pulsar admin API on behalf of its users. Pulsar Manager has the following security issues:

  • The operation for creating the initial administrator (superuser) account is available without authentication, and it remains available after the instance has been initialized. Anyone who can reach Pulsar Manager can create an additional administrator account at any time and log in with it. This issue affects versions 0.3.0 and later.
  • Requests to the Pulsar admin API that Pulsar Manager proxies to the configured Pulsar cluster are not subject to Pulsar Manager's authentication. Version 0.2.0 checks the caller's permissions for some of these requests, but not for all of them. An unauthenticated user can therefore use Pulsar Manager to send requests to the Pulsar admin API, which the cluster processes with the credential configured in Pulsar Manager.
  • The destination of a proxied request can be chosen by the requester, and Pulsar Manager attaches its configured Pulsar admin credential to the request. An unauthenticated user can make Pulsar Manager send this credential to a host of the user's choosing, and the credential can then be used directly against the Pulsar cluster.
  • In versions 0.3.0 and later, Pulsar Manager does not distinguish between privilege levels of its accounts. Every account, including one created through the first issue, effectively has full administrative privileges in Pulsar Manager.

The impact depends on the version and the deployment. In versions 0.3.0 and later, any user who can reach Pulsar Manager over the network can take full control of Pulsar Manager. In all versions, when Pulsar Manager is configured with an HTTP authentication credential for a Pulsar cluster, any user who can reach Pulsar Manager can perform the Pulsar admin operations that this credential permits and can obtain the credential itself. When Pulsar Manager is configured with the token signing key of a Pulsar cluster, an administrator of Pulsar Manager can create tokens for the cluster.

Apache Pulsar Manager is no longer maintained and is completely unsupported. The Apache Pulsar PMC has retired it. There are no supported versions, and no further releases, fixes or security updates will be made for any version. These issues will not be fixed.

Using Pulsar Manager is not recommended. Users should stop using Pulsar Manager, remove existing deployments, and move to one of the alternatives described in the Administration UI documentation (https://pulsar.apache.org/docs/administration-ui). Users who have exposed Pulsar Manager configured with a Pulsar credential or token signing key should also consider replacing that credential or key.

Until a deployment is removed, users should not expose Pulsar Manager to untrusted networks, and should restrict network access to it to trusted administrators.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-105944"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-10-21T19:16:57Z",
    "severity": "CRITICAL"
  },
  "details": "Apache Pulsar Manager is a web console for administering Apache Pulsar clusters. It has its own user accounts and login, and it can be configured with an HTTP authentication credential, such as a token, that it uses to call the Pulsar admin API on behalf of its users. Pulsar Manager has the following security issues:\n\n- The operation for creating the initial administrator (superuser) account is available without authentication, and it remains available after the instance has been initialized. Anyone who can reach Pulsar Manager can create an additional administrator account at any time and log in with it. This issue affects versions 0.3.0 and later.\n- Requests to the Pulsar admin API that Pulsar Manager proxies to the configured Pulsar cluster are not subject to Pulsar Manager\u0027s authentication. Version 0.2.0 checks the caller\u0027s permissions for some of these requests, but not for all of them. An unauthenticated user can therefore use Pulsar Manager to send requests to the Pulsar admin API, which the cluster processes with the credential configured in Pulsar Manager.\n- The destination of a proxied request can be chosen by the requester, and Pulsar Manager attaches its configured Pulsar admin credential to the request. An unauthenticated user can make Pulsar Manager send this credential to a host of the user\u0027s choosing, and the credential can then be used directly against the Pulsar cluster.\n- In versions 0.3.0 and later, Pulsar Manager does not distinguish between privilege levels of its accounts. Every account, including one created through the first issue, effectively has full administrative privileges in Pulsar Manager.\n\nThe impact depends on the version and the deployment. In versions 0.3.0 and later, any user who can reach Pulsar Manager over the network can take full control of Pulsar Manager. In all versions, when Pulsar Manager is configured with an HTTP authentication credential for a Pulsar cluster, any user who can reach Pulsar Manager can perform the Pulsar admin operations that this credential permits and can obtain the credential itself. When Pulsar Manager is configured with the token signing key of a Pulsar cluster, an administrator of Pulsar Manager can create tokens for the cluster.\n\nApache Pulsar Manager is no longer maintained and is completely unsupported. The Apache Pulsar PMC has retired it. There are no supported versions, and no further releases, fixes or security updates will be made for any version. These issues will not be fixed.\n\nUsing Pulsar Manager is not recommended. Users should stop using Pulsar Manager, remove existing deployments, and move to one of the alternatives described in the Administration UI documentation (https://pulsar.apache.org/docs/administration-ui). Users who have exposed Pulsar Manager configured with a Pulsar credential or token signing key should also consider replacing that credential or key.\n\nUntil a deployment is removed, users should not expose Pulsar Manager to untrusted networks, and should restrict network access to it to trusted administrators.",
  "id": "GHSA-436h-c7mw-9wgf",
  "modified": "2026-10-22T00:31:58Z",
  "published": "2026-10-21T21:32:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-105944"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/hol3z7fzhjntwvrv8xqqwx4l4d2jx796"
    },
    {
      "type": "WEB",
      "url": "https://pulsar.apache.org/docs/administration-ui"
    },
    {
      "type": "WEB",
      "url": "https://pulsar.apache.org/security/CVE-2026-105944"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2026/10/21/26"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/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-4376-J46P-QQM7

Vulnerability from github – Published: 2026-10-21 18:33 – Updated: 2026-10-21 18:33
VLAI
Details

A vulnerability in the control channel socket implementation of Open Source Snort 3 could allow an authenticated, local attacker with low privileges to execute arbitrary commands as the Snort 3 process user.

This vulnerability is due to a lack of authentication when a local user connects to the Snort control channel socket. An attacker could exploit this vulnerability by connecting to the Snort 3 control channel socket as a local user. A successful exploit could allow the attacker to execute arbitrary commands as well as read and write Snort 3 process memory.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-76524"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-10-21T17:19:09Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability in the control channel socket implementation of\u0026nbsp;Open Source Snort 3 could allow an authenticated, local attacker with low privileges to execute arbitrary commands as the Snort 3 process user.\n\nThis vulnerability is due to a lack of authentication when a local user connects to the Snort control channel socket. An attacker could exploit this vulnerability by connecting to the Snort 3 control channel socket as a local user. A successful exploit could allow the attacker to execute arbitrary commands as well as read and write Snort 3 process memory.",
  "id": "GHSA-4376-j46p-qqm7",
  "modified": "2026-10-21T18:33:29Z",
  "published": "2026-10-21T18:33:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-76524"
    },
    {
      "type": "WEB",
      "url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-opensrc-snort3-2fXGJPfe"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-43FF-4WJR-J993

Vulnerability from github – Published: 2022-05-13 01:42 – Updated: 2022-05-13 01:42
VLAI
Details

An Improper Access Control issue was discovered in Smiths Medical Medfusion 4000 Wireless Syringe Infusion Pump, Version 1.1, 1.5, and 1.6. The FTP server on the pump does not require authentication if the pump is configured to allow FTP connections.

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

{
  "affected": [],
  "aliases": [
    "CVE-2017-12720"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-02-15T10:29:00Z",
    "severity": "HIGH"
  },
  "details": "An Improper Access Control issue was discovered in Smiths Medical Medfusion 4000 Wireless Syringe Infusion Pump, Version 1.1, 1.5, and 1.6. The FTP server on the pump does not require authentication if the pump is configured to allow FTP connections.",
  "id": "GHSA-43ff-4wjr-j993",
  "modified": "2022-05-13T01:42:44Z",
  "published": "2022-05-13T01:42:44Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-12720"
    },
    {
      "type": "WEB",
      "url": "https://ics-cert.us-cert.gov/advisories/ICSMA-17-250-02A"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/100665"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-43G3-JF9M-F6F5

Vulnerability from github – Published: 2022-05-24 19:17 – Updated: 2022-08-13 00:00
VLAI
Details

Tad Uploader edit book list function is vulnerable to authorization bypass, thus remote attackers can use the function to amend the folder names in the book list without logging in.

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

{
  "affected": [],
  "aliases": [
    "CVE-2021-41976"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-10-08T16:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Tad Uploader edit book list function is vulnerable to authorization bypass, thus remote attackers can use the function to amend the folder names in the book list without logging in.",
  "id": "GHSA-43g3-jf9m-f6f5",
  "modified": "2022-08-13T00:00:37Z",
  "published": "2022-05-24T19:17:02Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-41976"
    },
    {
      "type": "WEB",
      "url": "https://www.twcert.org.tw/tw/cp-132-5175-a2f8d-1.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-43HH-68V6-MF36

Vulnerability from github – Published: 2026-07-20 09:31 – Updated: 2026-08-26 18:30
VLAI
Details

A flaw was found in the Konnectivity proxy-server configuration for hosted control planes. The agent-facing listener was started without --cluster-ca-cert (and without token-based agent authentication), so client certificates were not validated. A remote attacker who can reach the Konnectivity cluster endpoint could connect as an unauthenticated agent, join the routing pool, and potentially proxy, inspect, modify, or drop control-plane-to-node traffic.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-16242"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-20T08:16:29Z",
    "severity": "CRITICAL"
  },
  "details": "A flaw was found in the Konnectivity proxy-server configuration for hosted control planes. The agent-facing listener was started without --cluster-ca-cert (and without token-based agent authentication), so client certificates were not validated. A remote attacker who can reach the Konnectivity cluster endpoint could connect as an unauthenticated agent, join the routing pool, and potentially proxy, inspect, modify, or drop control-plane-to-node traffic.",
  "id": "GHSA-43hh-68v6-mf36",
  "modified": "2026-08-26T18:30:35Z",
  "published": "2026-07-20T09:31:08Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-16242"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openshift/hypershift/pull/9031"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2502690"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2026-16242"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:56912"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:56789"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:50758"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:48699"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:48693"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:48676"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:48670"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:48657"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:48284"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:47974"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:47953"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:47949"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:47735"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:47728"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:47388"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:46885"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-43QC-C2GQ-5FQ2

Vulnerability from github – Published: 2026-08-13 21:36 – Updated: 2026-08-13 21:36
VLAI
Details

The Signify Philips Hue Bridge Pro firmware embeds a Mosquitto MQTT broker (v2.0.22) that listens on all network interfaces with anonymous access enabled and no firewall restriction. An attacker with access to the Bridge's network can read device data and control connected lights.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-73669"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-13T20:17:30Z",
    "severity": "MODERATE"
  },
  "details": "The Signify Philips Hue Bridge Pro firmware embeds a Mosquitto MQTT broker (v2.0.22) that listens on all network interfaces with anonymous access enabled and no firewall restriction. An attacker with access to the Bridge\u0027s network can read device data and control connected lights.",
  "id": "GHSA-43qc-c2gq-5fq2",
  "modified": "2026-08-13T21:36:12Z",
  "published": "2026-08-13T21:36:12Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-73669"
    },
    {
      "type": "WEB",
      "url": "https://raw.githubusercontent.com/cisagov/CSAF/develop/csaf_files/IT/white/2026/va-26-225-01.json"
    },
    {
      "type": "WEB",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-73669"
    },
    {
      "type": "WEB",
      "url": "https://www.philips-hue.com/en-us/support/release-notes/bridge-pro"
    },
    {
      "type": "WEB",
      "url": "https://www.philips-hue.com/en-us/support/security-advisory"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:A/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:L/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-449W-C77C-VMF6

Vulnerability from github – Published: 2022-07-28 00:00 – Updated: 2022-12-09 20:56
VLAI
Summary
Lack of authentication mechanism in Jenkins Git Plugin webhook
Details

Git Plugin provides a webhook endpoint at /git/notifyCommit that can be used to notify Jenkins of changes to an SCM repository. For its most basic functionality, this endpoint receives a repository URL, and Jenkins will schedule polling for all jobs configured with the specified repository. In Git Plugin 4.11.3 and earlier, this endpoint can be accessed with GET requests and without authentication. In addition to this basic functionality, the endpoint also accept a sha1 parameter specifying a commit ID. If this parameter is specified, jobs configured with the specified repo will be triggered immediately, and the build will check out the specified commit. Additionally, the output of the webhook endpoint will provide information about which jobs were triggered or scheduled for polling, including jobs the user has no permission to access. This allows attackers with knowledge of Git repository URLs to trigger builds of jobs using a specified Git repository and to cause them to check out an attacker-specified commit, and to obtain information about the existence of jobs configured with this Git repository. Additionally, this webhook endpoint does not require POST requests, resulting in a cross-site request forgery (CSRF) vulnerability. Git Plugin 4.11.4 requires a token parameter which will act as an authentication for the webhook endpoint. While GET requests remain allowed, attackers would need to be able to provide a webhook token. For more information see the plugin documentation.

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.11.3"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.jenkins-ci.plugins:git"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.11.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-36884"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-306"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-08-10T18:28:37Z",
    "nvd_published_at": "2022-07-27T15:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Git Plugin provides a webhook endpoint at `/git/notifyCommit` that can be used to notify Jenkins of changes to an SCM repository. For its most basic functionality, this endpoint receives a repository URL, and Jenkins will schedule polling for all jobs configured with the specified repository. In Git Plugin 4.11.3 and earlier, this endpoint can be accessed with GET requests and without authentication. In addition to this basic functionality, the endpoint also accept a `sha1` parameter specifying a commit ID. If this parameter is specified, jobs configured with the specified repo will be triggered immediately, and the build will check out the specified commit. Additionally, the output of the webhook endpoint will provide information about which jobs were triggered or scheduled for polling, including jobs the user has no permission to access. This allows attackers with knowledge of Git repository URLs to trigger builds of jobs using a specified Git repository and to cause them to check out an attacker-specified commit, and to obtain information about the existence of jobs configured with this Git repository. Additionally, this webhook endpoint does not require POST requests, resulting in a cross-site request forgery (CSRF) vulnerability. Git Plugin 4.11.4 requires a `token` parameter which will act as an authentication for the webhook endpoint. While GET requests remain allowed, attackers would need to be able to provide a webhook token. For more information see [the plugin documentation](https://github.com/jenkinsci/git-plugin/#push-notification-from-repository).",
  "id": "GHSA-449w-c77c-vmf6",
  "modified": "2022-12-09T20:56:53Z",
  "published": "2022-07-28T00:00:43Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-36884"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jenkinsci/git-plugin/commit/b46165c74a0bf15e08763de2e506005624d5d238"
    },
    {
      "type": "WEB",
      "url": "https://www.jenkins.io/security/advisory/2022-07-27/#SECURITY-284"
    },
    {
      "type": "PACKAGE",
      "url": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2022/07/27/1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Lack of authentication mechanism in Jenkins Git Plugin webhook"
}

GHSA-44F9-R7RV-2634

Vulnerability from github – Published: 2022-05-24 17:36 – Updated: 2022-05-24 17:36
VLAI
Details

The official composer docker images before 1.8.3 contain a blank password for a root user. System using the composer docker container deployed by affected versions of the docker image may allow a remote attacker to achieve root access with a blank password.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2020-35184"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-12-17T02:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "The official composer docker images before 1.8.3 contain a blank password for a root user. System using the composer docker container deployed by affected versions of the docker image may allow a remote attacker to achieve root access with a blank password.",
  "id": "GHSA-44f9-r7rv-2634",
  "modified": "2022-05-24T17:36:45Z",
  "published": "2022-05-24T17:36:45Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-35184"
    },
    {
      "type": "WEB",
      "url": "https://github.com/koharin/koharin2/blob/main/CVE-2020-35184"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-44QJ-CGHF-9P97

Vulnerability from github – Published: 2026-05-08 22:47 – Updated: 2026-06-08 23:47
VLAI
Summary
free5GC's SMF UPI POST /upi/v1/upNodesLinks exits the SMF process on overlapping UE pools (unauthenticated, reachable Fatalf)
Details

Summary

free5GC's SMF mounts the UPI management route group without inbound OAuth2 middleware (same root cause as free5gc/free5gc#887). The POST /upi/v1/upNodesLinks create-or-update handler accepts attacker-controlled JSON and passes it directly into UpNodesFromConfiguration(), which calls logger.InitLog.Fatalf(...) on several validation failures. One confirmed path is the UE-IP-pool overlap check: a single unauthenticated POST that adds a new UPF whose pool overlaps an existing UPF terminates the entire SMF process (docker ps shows Exited (1)), not just the goroutine. This is a stronger sink than free5gc/free5gc#905: that one panics inside the request goroutine and Gin recovers; this one calls Fatalf which is os.Exit(1)-equivalent and kills the whole SMF process, dropping all of SMF's SBI surface (PDU-session establishment, UE policy lookups, etc.) until the process is restarted.

Details

Validated against the SMF container in the official Docker compose lab. - Source repo tag: v4.2.1 - Running Docker image: free5gc/smf:v4.2.1 - Runtime SMF commit: 8385c00a - Docker validation date: 2026-03-22 local (container log timestamp 2026-03-21T23:47:07Z) - SMF endpoint: http://10.100.200.6:8000

The broader UPI auth gap (#887) lets the unauthenticated POST reach the create/update handler. From there:

Vulnerable handler dispatches into topology parsing:

POST /upi/v1/upNodesLinks
 -> UpNodesFromConfiguration()
   -> isOverlap(allUEIPPools)
     -> logger.InitLog.Fatalf("overlap cidr value between UPFs")

Code evidence (paths in free5gc/smf): - UPI group mounted WITHOUT auth middleware (preconditions for unauthenticated reachability): - NFs/smf/internal/sbi/server.go:76 - NFs/smf/internal/sbi/server.go:78 - Create-or-update handler accepts attacker JSON and forwards it to UpNodesFromConfiguration(): - NFs/smf/internal/sbi/api_upi.go:60 - NFs/smf/internal/sbi/api_upi.go:72 - Pool parsing (input from attacker JSON): - NFs/smf/internal/context/user_plane_information.go:413 - Overlap check that calls Fatalf: - NFs/smf/internal/context/user_plane_information.go:479

The same unauthenticated POST path also reaches sibling Fatalf calls for invalid-pool and static-pool-exclusion failures, so this is not a one-off code smell -- it is a class of attacker-reachable Fatalf call sites on a single unauthenticated handler: - NFs/smf/internal/context/user_plane_information.go:416 - NFs/smf/internal/context/user_plane_information.go:424 - NFs/smf/internal/context/user_plane_information.go:430

PoC

Reproduced end-to-end against the running SMF at http://10.100.200.6:8000.

  1. Trigger: unauthenticated POST that adds a UPF with a UE pool overlapping the default UPF (10.60.0.0/16):
curl -i -X POST http://10.100.200.6:8000/upi/v1/upNodesLinks \
  -H 'Content-Type: application/json' \
  --data '{"links":[{"A":"gNB1","B":"UPF-OVERLAP-20260322"}],"upNodes":{"UPF-OVERLAP-20260322":{"type":"UPF","nodeID":"198.51.100.20","addr":"198.51.100.20","sNssaiUpfInfos":[{"sNssai":{"sst":1,"sd":"010203"},"dnnUpfInfoList":[{"dnn":"internet","pools":[{"cidr":"10.60.0.0/16"}]}]}]}}}'

Client-side observation (server died mid-request, no HTTP response written):

curl: (52) Empty reply from server
  1. Confirm the SMF container exited:
docker ps -a --filter name=smf --format '{{.Names}}\t{{.Status}}'

smf    Exited (1) 9 seconds ago
  1. SMF container logs (docker logs --tail 80 smf) show the FATA line that terminated the process:
[FATA][SMF][Init] overlap cidr value between UPFs

Impact

Unauthenticated process-kill DoS on the SMF management plane.

  1. Missing inbound authentication (CWE-306) and authorization (CWE-862) on the UPI route group makes the trigger reachable to any off-path network attacker who can reach SMF on the SBI -- no token, no UE state needed. The same-instance nsmf-oam returning 401 (see free5gc/free5gc#887) proves OAuth middleware is wired in for other SMF route groups and only missing on UPI.
  2. Reachable assertion / fail-fast (CWE-617): topology parsing calls logger.InitLog.Fatalf(...) on attacker-influenced validation failures. Fatalf is os.Exit(1)-equivalent -- it skips Gin's recovery, the deferred handlers, and kills the whole SMF process. This is materially worse than the related panic-DoS in free5gc/free5gc#905, which Gin recovers from at the goroutine level.

Any party that can reach SMF on the SBI can: - Send one unauthenticated POST with an overlapping UE pool and immediately terminate the SMF process, dropping all of SMF's SBI surface (PDU-session establishment, UE policy interactions) until SMF is restarted. - Repeat the trigger after every restart to sustain the outage. - Use sibling Fatalf paths (invalid-pool, static-pool exclusion) to sustain the same DoS even if the overlap check is hardened in isolation, because the underlying defect is using Fatalf for request-time validation on an unauthenticated handler.

No Confidentiality impact (the crash returns no data to the attacker). No persistent Integrity impact (the topology updates are in-memory and are lost when SMF dies). The whole impact concentrates in Availability: complete loss of SMF service via a single unauthenticated request.

Affected: free5gc v4.2.1.

Upstream issue: https://github.com/free5gc/free5gc/issues/906 Upstream fix: https://github.com/free5gc/smf/pull/203

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/free5gc/smf"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "1.4.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-44321"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306",
      "CWE-617",
      "CWE-862"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-08T22:47:24Z",
    "nvd_published_at": "2026-05-27T17:16:37Z",
    "severity": "HIGH"
  },
  "details": "### Summary\nfree5GC\u0027s SMF mounts the `UPI` management route group without inbound OAuth2 middleware (same root cause as free5gc/free5gc#887). The `POST /upi/v1/upNodesLinks` create-or-update handler accepts attacker-controlled JSON and passes it directly into `UpNodesFromConfiguration()`, which calls `logger.InitLog.Fatalf(...)` on several validation failures. One confirmed path is the UE-IP-pool overlap check: a single unauthenticated POST that adds a new UPF whose pool overlaps an existing UPF terminates the entire SMF process (`docker ps` shows `Exited (1)`), not just the goroutine. This is a stronger sink than free5gc/free5gc#905: that one panics inside the request goroutine and Gin recovers; this one calls `Fatalf` which is `os.Exit(1)`-equivalent and kills the whole SMF process, dropping all of SMF\u0027s SBI surface (PDU-session establishment, UE policy lookups, etc.) until the process is restarted.\n\n### Details\nValidated against the SMF container in the official Docker compose lab.\n- Source repo tag: `v4.2.1`\n- Running Docker image: `free5gc/smf:v4.2.1`\n- Runtime SMF commit: `8385c00a`\n- Docker validation date: 2026-03-22 local (container log timestamp `2026-03-21T23:47:07Z`)\n- SMF endpoint: `http://10.100.200.6:8000`\n\nThe broader `UPI` auth gap (#887) lets the unauthenticated POST reach the create/update handler. From there:\n\nVulnerable handler dispatches into topology parsing:\n```\nPOST /upi/v1/upNodesLinks\n -\u003e UpNodesFromConfiguration()\n   -\u003e isOverlap(allUEIPPools)\n     -\u003e logger.InitLog.Fatalf(\"overlap cidr value between UPFs\")\n```\n\nCode evidence (paths in `free5gc/smf`):\n- UPI group mounted WITHOUT auth middleware (preconditions for unauthenticated reachability):\n  - `NFs/smf/internal/sbi/server.go:76`\n  - `NFs/smf/internal/sbi/server.go:78`\n- Create-or-update handler accepts attacker JSON and forwards it to `UpNodesFromConfiguration()`:\n  - `NFs/smf/internal/sbi/api_upi.go:60`\n  - `NFs/smf/internal/sbi/api_upi.go:72`\n- Pool parsing (input from attacker JSON):\n  - `NFs/smf/internal/context/user_plane_information.go:413`\n- Overlap check that calls `Fatalf`:\n  - `NFs/smf/internal/context/user_plane_information.go:479`\n\nThe same unauthenticated POST path also reaches sibling `Fatalf` calls for invalid-pool and static-pool-exclusion failures, so this is not a one-off code smell -- it is a class of attacker-reachable `Fatalf` call sites on a single unauthenticated handler:\n- `NFs/smf/internal/context/user_plane_information.go:416`\n- `NFs/smf/internal/context/user_plane_information.go:424`\n- `NFs/smf/internal/context/user_plane_information.go:430`\n\n### PoC\nReproduced end-to-end against the running SMF at `http://10.100.200.6:8000`.\n\n1. Trigger: unauthenticated POST that adds a UPF with a UE pool overlapping the default UPF (`10.60.0.0/16`):\n```\ncurl -i -X POST http://10.100.200.6:8000/upi/v1/upNodesLinks \\\n  -H \u0027Content-Type: application/json\u0027 \\\n  --data \u0027{\"links\":[{\"A\":\"gNB1\",\"B\":\"UPF-OVERLAP-20260322\"}],\"upNodes\":{\"UPF-OVERLAP-20260322\":{\"type\":\"UPF\",\"nodeID\":\"198.51.100.20\",\"addr\":\"198.51.100.20\",\"sNssaiUpfInfos\":[{\"sNssai\":{\"sst\":1,\"sd\":\"010203\"},\"dnnUpfInfoList\":[{\"dnn\":\"internet\",\"pools\":[{\"cidr\":\"10.60.0.0/16\"}]}]}]}}}\u0027\n```\n\nClient-side observation (server died mid-request, no HTTP response written):\n```\ncurl: (52) Empty reply from server\n```\n\n2. Confirm the SMF container exited:\n```\ndocker ps -a --filter name=smf --format \u0027{{.Names}}\\t{{.Status}}\u0027\n```\n```\nsmf    Exited (1) 9 seconds ago\n```\n\n3. SMF container logs (`docker logs --tail 80 smf`) show the `FATA` line that terminated the process:\n```\n[FATA][SMF][Init] overlap cidr value between UPFs\n```\n\n### Impact\nUnauthenticated process-kill DoS on the SMF management plane.\n\n1. Missing inbound authentication (CWE-306) and authorization (CWE-862) on the `UPI` route group makes the trigger reachable to any off-path network attacker who can reach SMF on the SBI -- no token, no UE state needed. The same-instance `nsmf-oam` returning `401` (see free5gc/free5gc#887) proves OAuth middleware is wired in for other SMF route groups and only missing on UPI.\n2. Reachable assertion / fail-fast (CWE-617): topology parsing calls `logger.InitLog.Fatalf(...)` on attacker-influenced validation failures. `Fatalf` is `os.Exit(1)`-equivalent -- it skips Gin\u0027s recovery, the deferred handlers, and kills the whole SMF process. This is materially worse than the related panic-DoS in free5gc/free5gc#905, which Gin recovers from at the goroutine level.\n\nAny party that can reach SMF on the SBI can:\n- Send one unauthenticated POST with an overlapping UE pool and immediately terminate the SMF process, dropping all of SMF\u0027s SBI surface (PDU-session establishment, UE policy interactions) until SMF is restarted.\n- Repeat the trigger after every restart to sustain the outage.\n- Use sibling `Fatalf` paths (invalid-pool, static-pool exclusion) to sustain the same DoS even if the overlap check is hardened in isolation, because the underlying defect is using `Fatalf` for request-time validation on an unauthenticated handler.\n\nNo Confidentiality impact (the crash returns no data to the attacker). No persistent Integrity impact (the topology updates are in-memory and are lost when SMF dies). The whole impact concentrates in Availability: complete loss of SMF service via a single unauthenticated request.\n\nAffected: free5gc v4.2.1.\n\nUpstream issue: https://github.com/free5gc/free5gc/issues/906\nUpstream fix: https://github.com/free5gc/smf/pull/203",
  "id": "GHSA-44qj-cghf-9p97",
  "modified": "2026-06-08T23:47:19Z",
  "published": "2026-05-08T22:47:24Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/free5gc/free5gc/security/advisories/GHSA-44qj-cghf-9p97"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44321"
    },
    {
      "type": "WEB",
      "url": "https://github.com/free5gc/free5gc/issues/906"
    },
    {
      "type": "WEB",
      "url": "https://github.com/free5gc/smf/pull/203"
    },
    {
      "type": "WEB",
      "url": "https://github.com/free5gc/smf/commit/e0974e07ddab44a67d36a563cca383b2449e33e5"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/free5gc/free5gc"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "free5GC\u0027s SMF UPI POST /upi/v1/upNodesLinks exits the SMF process on overlapping UE pools (unauthenticated, reachable Fatalf)"
}

GHSA-44WQ-7FM8-J2J2

Vulnerability from github – Published: 2022-05-24 16:49 – Updated: 2024-04-04 01:13
VLAI
Details

Lack of authentication in file-viewing components in DDRT Dashcom Live 2019-05-09 allows anyone to remotely access all claim details by visiting easily guessable dashboard/uploads/claim_files/claim_id_ URLs.

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

{
  "affected": [],
  "aliases": [
    "CVE-2019-11020"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-07-09T17:15:00Z",
    "severity": "HIGH"
  },
  "details": "Lack of authentication in file-viewing components in DDRT Dashcom Live 2019-05-09 allows anyone to remotely access all claim details by visiting easily guessable dashboard/uploads/claim_files/claim_id_ URLs.",
  "id": "GHSA-44wq-7fm8-j2j2",
  "modified": "2024-04-04T01:13:10Z",
  "published": "2022-05-24T16:49:47Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-11020"
    },
    {
      "type": "WEB",
      "url": "https://domdomegg.github.io/CVE-2019-11020.pdf"
    },
    {
      "type": "WEB",
      "url": "http://ddrt.co.uk/complaint-handling-software"
    }
  ],
  "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"
    }
  ]
}
Mitigation
Architecture and Design
  • Divide the software into anonymous, normal, privileged, and administrative areas. Identify which of these areas require a proven user identity, and use a centralized authentication capability.
  • Identify all potential communication channels, or other means of interaction with the software, to ensure that all channels are appropriately protected, including those channels that are assumed to be accessible only by authorized parties. Developers sometimes perform authentication at the primary channel, but open up a secondary channel that is assumed to be private. For example, a login mechanism may be listening on one network port, but after successful authentication, it may open up a second port where it waits for the connection, but avoids authentication because it assumes that only the authenticated party will connect to the port.
  • In general, if the software or protocol allows a single session or user state to persist across multiple connections or channels, authentication and appropriate credential management need to be used throughout.
Mitigation MIT-15
Architecture and Design

For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.

Mitigation
Architecture and Design
  • Where possible, avoid implementing custom, "grow-your-own" authentication routines and consider using authentication capabilities as provided by the surrounding framework, operating system, or environment. These capabilities may avoid common weaknesses that are unique to authentication; support automatic auditing and tracking; and make it easier to provide a clear separation between authentication tasks and authorization tasks.
  • In environments such as the World Wide Web, the line between authentication and authorization is sometimes blurred. If custom authentication routines are required instead of those provided by the server, then these routines must be applied to every single page, since these pages could be requested directly.
Mitigation MIT-4.5
Architecture and Design

Strategy: Libraries or Frameworks

  • Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
  • For example, consider using libraries with authentication capabilities such as OpenSSL or the ESAPI Authenticator [REF-45].
Mitigation
Implementation System Configuration Operation

When storing data in the cloud (e.g., S3 buckets, Azure blobs, Google Cloud Storage, etc.), use the provider's controls to require strong authentication for users who should be allowed to access the data [REF-1297] [REF-1298] [REF-1302].

CAPEC-12: Choosing Message Identifier

This pattern of attack is defined by the selection of messages distributed via multicast or public information channels that are intended for another client by determining the parameter value assigned to that client. This attack allows the adversary to gain access to potentially privileged information, and to possibly perpetrate other attacks through the distribution means by impersonation. If the channel/message being manipulated is an input rather than output mechanism for the system, (such as a command bus), this style of attack could be used to change the adversary's identifier to more a privileged one.

CAPEC-166: Force the System to Reset Values

An attacker forces the target into a previous state in order to leverage potential weaknesses in the target dependent upon a prior configuration or state-dependent factors. Even in cases where an attacker may not be able to directly control the configuration of the targeted application, they may be able to reset the configuration to a prior state since many applications implement reset functions.

CAPEC-216: Communication Channel Manipulation

An adversary manipulates a setting or parameter on communications channel in order to compromise its security. This can result in information exposure, insertion/removal of information from the communications stream, and/or potentially system compromise.

CAPEC-36: Using Unpublished Interfaces or Functionality

An adversary searches for and invokes interfaces or functionality that the target system designers did not intend to be publicly available. If interfaces fail to authenticate requests, the attacker may be able to invoke functionality they are not authorized for.

CAPEC-62: Cross Site Request Forgery

An attacker crafts malicious web links and distributes them (via web pages, email, etc.), typically in a targeted manner, hoping to induce users to click on the link and execute the malicious action against some third-party application. If successful, the action embedded in the malicious link will be processed and accepted by the targeted application with the users' privilege level. This type of attack leverages the persistence and implicit trust placed in user session cookies by many web applications today. In such an architecture, once the user authenticates to an application and a session cookie is created on the user's system, all following transactions for that session are authenticated using that cookie including potential actions initiated by an attacker and simply "riding" the existing session cookie.

← Back to the CWE list