CWE-285
DiscouragedImproper Authorization
Abstraction: Class · Status: Draft
The product does not perform or incorrectly performs an authorization check when an actor attempts to access a resource or perform an action.
2321 vulnerabilities reference this CWE, most recent first.
GHSA-4M3W-PP93-QQGM
Vulnerability from github – Published: 2025-05-07 12:30 – Updated: 2025-05-07 12:30The Frontend Dashboard plugin for WordPress is vulnerable to Privilege Escalation due to a missing capability check on the fed_wp_ajax_fed_login_form_post() function in versions 1.0 to 2.2.6. This makes it possible for unauthenticated attackers to reset the administrator’s email and password, and elevate their privileges to that of an administrator.
{
"affected": [],
"aliases": [
"CVE-2025-4104"
],
"database_specific": {
"cwe_ids": [
"CWE-285"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-07T10:15:15Z",
"severity": "CRITICAL"
},
"details": "The Frontend Dashboard plugin for WordPress is vulnerable to Privilege Escalation due to a missing capability check on the fed_wp_ajax_fed_login_form_post() function in versions 1.0 to 2.2.6. This makes it possible for unauthenticated attackers to reset the administrator\u2019s email and password, and elevate their privileges to that of an administrator.",
"id": "GHSA-4m3w-pp93-qqgm",
"modified": "2025-05-07T12:30:34Z",
"published": "2025-05-07T12:30:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-4104"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/frontend-dashboard/tags/2.2.6/includes/frontend/request/login/index.php#L21"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/frontend-dashboard/tags/2.2.6/includes/frontend/request/login/register.php#L16"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/frontend-dashboard/tags/2.2.7/includes/frontend/request/login/validation.php"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset/3288562"
},
{
"type": "WEB",
"url": "https://wordpress.org/plugins/frontend-dashboard/#developers"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/31e518a9-316b-40a4-ada7-317fb2c16766?source=cve"
}
],
"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"
}
]
}
GHSA-4MF8-X363-F56C
Vulnerability from github – Published: 2026-03-18 18:31 – Updated: 2026-03-23 18:30The WiFi Extender WDR201A (HW V2.1, FW LFMZX28040922V1.02) implements a broken authentication mechanism in its web management interface. The login page does not properly enforce session validation, allowing attackers to bypass authentication by directly accessing restricted web application endpoints through forced browsing
{
"affected": [],
"aliases": [
"CVE-2026-30702"
],
"database_specific": {
"cwe_ids": [
"CWE-285"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-18T18:16:27Z",
"severity": "CRITICAL"
},
"details": "The WiFi Extender WDR201A (HW V2.1, FW LFMZX28040922V1.02) implements a broken authentication mechanism in its web management interface. The login page does not properly enforce session validation, allowing attackers to bypass authentication by directly accessing restricted web application endpoints through forced browsing",
"id": "GHSA-4mf8-x363-f56c",
"modified": "2026-03-23T18:30:26Z",
"published": "2026-03-18T18:31:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-30702"
},
{
"type": "WEB",
"url": "https://mstreet97.github.io/security-research/iot/vulnerability-disclosure/cybersecurity/cve/2026/02/18/From-Blackbox-to-Whitebox-Multiple-CVEs-in-a-Consumer-WiFi-Extender.html"
},
{
"type": "WEB",
"url": "https://www.made-in-china.com/showroom/yeapook/#:~:text=Established%20in%202015.%2CDistrict%2C%20Shenzhen%2C%20Guangdong%2C%20China"
}
],
"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"
}
]
}
GHSA-4Q92-RFM6-2CQX
Vulnerability from github – Published: 2026-02-06 19:08 – Updated: 2026-03-30 19:59Claude Code failed to strictly enforce deny rules configured in settings.json when accessing files through symbolic links. If a user explicitly denied Claude Code access to a file (such as /etc/passwd) and Claude Code had access to a symbolic link pointing to that file, it was possible for Claude Code to read the restricted file through the symlink without triggering deny rule enforcement.
Users on standard Claude Code auto-update received this fix automatically. Users performing manual updates are advised to update to the latest version.
Claude Code thanks https://hackerone.com/ofirh for reporting this issue.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "@anthropic-ai/claude-code"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.1.7"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-25724"
],
"database_specific": {
"cwe_ids": [
"CWE-285",
"CWE-61"
],
"github_reviewed": true,
"github_reviewed_at": "2026-02-06T19:08:04Z",
"nvd_published_at": "2026-02-06T18:16:00Z",
"severity": "LOW"
},
"details": "Claude Code failed to strictly enforce deny rules configured in settings.json when accessing files through symbolic links. If a user explicitly denied Claude Code access to a file (such as /etc/passwd) and Claude Code had access to a symbolic link pointing to that file, it was possible for Claude Code to read the restricted file through the symlink without triggering deny rule enforcement. \n\nUsers on standard Claude Code auto-update received this fix automatically. Users performing manual updates are advised to update to the latest version.\n\nClaude Code thanks https://hackerone.com/ofirh for reporting this issue.",
"id": "GHSA-4q92-rfm6-2cqx",
"modified": "2026-03-30T19:59:02Z",
"published": "2026-02-06T19:08:04Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/anthropics/claude-code/security/advisories/GHSA-4q92-rfm6-2cqx"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-25724"
},
{
"type": "PACKAGE",
"url": "https://github.com/anthropics/claude-code"
},
{
"type": "WEB",
"url": "https://www.terra.security/blog/when-ai-becomes-the-attack-surface-lessons-from-discovering-cve-2026-25724"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Claude Code has Permission Deny Bypass Through Symbolic Links"
}
GHSA-4QCW-4458-7MV8
Vulnerability from github – Published: 2025-09-05 18:31 – Updated: 2025-09-05 21:32In getDestinationForApp of SpaAppBridgeActivity, there is a possible cross-user file reveal due to a logic error in the code. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.
{
"affected": [],
"aliases": [
"CVE-2025-26430"
],
"database_specific": {
"cwe_ids": [
"CWE-285"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-04T18:15:41Z",
"severity": "HIGH"
},
"details": "In getDestinationForApp of SpaAppBridgeActivity, there is a possible cross-user file reveal due to a logic error in the code. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.",
"id": "GHSA-4qcw-4458-7mv8",
"modified": "2025-09-05T21:32:36Z",
"published": "2025-09-05T18:31:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-26430"
},
{
"type": "WEB",
"url": "https://android.googlesource.com/platform/packages/apps/Settings/+/484b4be8f3634fa0d0fed53729490b9135c644b5"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/2025-05-01"
}
],
"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-4QGW-8RWW-MW2H
Vulnerability from github – Published: 2024-03-02 03:31 – Updated: 2024-03-02 03:31Due to insufficient server-side validation, a successful exploit of this vulnerability could allow an attacker to gain access to certain URLs that the attacker should not have access to.
{
"affected": [],
"aliases": [
"CVE-2024-25063"
],
"database_specific": {
"cwe_ids": [
"CWE-285"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-03-02T03:15:06Z",
"severity": "HIGH"
},
"details": "Due to insufficient server-side validation, a successful exploit of this vulnerability could allow an attacker to gain access to certain URLs that the attacker should not have access to.",
"id": "GHSA-4qgw-8rww-mw2h",
"modified": "2024-03-02T03:31:19Z",
"published": "2024-03-02T03:31:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-25063"
},
{
"type": "WEB",
"url": "https://www.hikvision.com/en/support/cybersecurity/security-advisory/security-vulnerabilities-in-hikcentral-professional"
}
],
"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-4QJ7-J8H7-R8G6
Vulnerability from github – Published: 2022-05-24 16:49 – Updated: 2022-05-24 16:49An issue was discovered on D-Link DCS-1130 devices. The device requires that a user logging to the device to provide a username and password. However, the device does not enforce the same restriction on a specific URL thereby allowing any attacker in possession of that to view the live video feed. The severity of this attack is enlarged by the fact that there more than 100,000 D-Link devices out there.
{
"affected": [],
"aliases": [
"CVE-2017-8409"
],
"database_specific": {
"cwe_ids": [
"CWE-285"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-07-02T20:15:00Z",
"severity": "HIGH"
},
"details": "An issue was discovered on D-Link DCS-1130 devices. The device requires that a user logging to the device to provide a username and password. However, the device does not enforce the same restriction on a specific URL thereby allowing any attacker in possession of that to view the live video feed. The severity of this attack is enlarged by the fact that there more than 100,000 D-Link devices out there.",
"id": "GHSA-4qj7-j8h7-r8g6",
"modified": "2022-05-24T16:49:13Z",
"published": "2022-05-24T16:49:13Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-8409"
},
{
"type": "WEB",
"url": "https://github.com/ethanhunnt/IoT_vulnerabilities/blob/master/Dlink_DCS_1130_security.pdf"
},
{
"type": "WEB",
"url": "https://seclists.org/bugtraq/2019/Jun/8"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/153226/Dlink-DCS-1130-Command-Injection-CSRF-Stack-Overflow.html"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-4R39-F4RH-J6Q8
Vulnerability from github – Published: 2022-05-24 17:03 – Updated: 2022-11-01 22:48A missing permission check in Jenkins Gerrit Trigger Plugin 2.30.1 and earlier allows attackers with Overall/Read permission to connect to an attacker-specified HTTP URL or SSH server using attacker-specified credentials, or determine the existence of a file with a given path on the Jenkins master.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "com.sonyericsson.hudson.plugins.gerrit:gerrit-trigger"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.30.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2019-16552"
],
"database_specific": {
"cwe_ids": [
"CWE-276",
"CWE-285"
],
"github_reviewed": true,
"github_reviewed_at": "2022-11-01T22:48:07Z",
"nvd_published_at": "2019-12-17T15:15:00Z",
"severity": "MODERATE"
},
"details": "A missing permission check in Jenkins Gerrit Trigger Plugin 2.30.1 and earlier allows attackers with Overall/Read permission to connect to an attacker-specified HTTP URL or SSH server using attacker-specified credentials, or determine the existence of a file with a given path on the Jenkins master.",
"id": "GHSA-4r39-f4rh-j6q8",
"modified": "2022-11-01T22:48:07Z",
"published": "2022-05-24T17:03:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-16552"
},
{
"type": "WEB",
"url": "https://github.com/jenkinsci/gerrit-trigger-plugin/commit/bdc94d3e23df0ad6a64565c732498f89ff743b51"
},
{
"type": "WEB",
"url": "https://jenkins.io/security/advisory/2019-12-17/#SECURITY-1527"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2019/12/17/1"
}
],
"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:N",
"type": "CVSS_V3"
}
],
"summary": "Missing permission check in Jenkins Gerrit Trigger Plugin"
}
GHSA-4V2W-2WQP-MC85
Vulnerability from github – Published: 2026-06-29 17:46 – Updated: 2026-06-29 17:46Summary
Description
An Improper Authorization (CWE-285) issue in OpenAM's OAuth2 authorization-code grant allows a PKCE-protected authorization code to be redeemed without the required code_verifier. This affects OpenAM Community Edition through version 16.0.6 and was patched in version 16.1.1.
The authorize endpoint stores a code_challenge on the issued code, but the token endpoint only requires a code_verifier when the realm-wide codeVerifierEnforced setting is enabled, which ships disabled by default. With that setting off, the stored challenge is checked only if the caller supplies a verifier, so omitting the parameter skips PKCE verification entirely.
Impact
OpenAM Community Edition deployments through version 16.0.6 using the default OAuth2 provider configuration are potentially affected. For public clients, an attacker who intercepts an authorization code can exchange it for tokens without knowing the verifier. For confidential clients, the attacker additionally needs client authentication material or an execution context that can redeem the code. A token request supplying an incorrect verifier is still rejected. The bypass is specifically the missing-parameter path.
Patch
This has been patched in OpenAM Community Edition version 16.1.1. Users are encouraged to update to the latest release.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 16.0.6"
},
"package": {
"ecosystem": "Maven",
"name": "org.openidentityplatform.openam:openam-oauth2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "16.1.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-48717"
],
"database_specific": {
"cwe_ids": [
"CWE-285"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-29T17:46:06Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## Summary\n\n**Description**\n\nAn Improper Authorization (CWE-285) issue in OpenAM\u0027s OAuth2 authorization-code grant allows a PKCE-protected authorization code to be redeemed without the required code_verifier. This affects OpenAM Community Edition through version 16.0.6 and was patched in version 16.1.1.\n\nThe authorize endpoint stores a code_challenge on the issued code, but the token endpoint only requires a code_verifier when the realm-wide codeVerifierEnforced setting is enabled, which ships disabled by default. With that setting off, the stored challenge is checked only if the caller supplies a verifier, so omitting the parameter skips PKCE verification entirely.\n\n## Impact\nOpenAM Community Edition deployments through version 16.0.6 using the default OAuth2 provider configuration are potentially affected. For public clients, an attacker who intercepts an authorization code can exchange it for tokens without knowing the verifier. For confidential clients, the attacker additionally needs client authentication material or an execution context that can redeem the code. A token request supplying an incorrect verifier is still rejected. The bypass is specifically the missing-parameter path.\n\n## Patch\nThis has been patched in OpenAM Community Edition version 16.1.1. Users are encouraged to update to the latest release.",
"id": "GHSA-4v2w-2wqp-mc85",
"modified": "2026-06-29T17:46:06Z",
"published": "2026-06-29T17:46:06Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/OpenIdentityPlatform/OpenAM/security/advisories/GHSA-4v2w-2wqp-mc85"
},
{
"type": "PACKAGE",
"url": "https://github.com/OpenIdentityPlatform/OpenAM"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:U",
"type": "CVSS_V4"
}
],
"summary": "OpenAM OAuth Authorization Bypass via PKCE Challenge"
}
GHSA-4V9X-J7PR-8WXQ
Vulnerability from github – Published: 2022-05-24 19:02 – Updated: 2025-10-22 00:32An improper authorization vulnerability has been reported to affect QNAP NAS running HBS 3 (Hybrid Backup Sync. ) If exploited, the vulnerability allows remote attackers to log in to a device. This issue affects: QNAP Systems Inc. HBS 3 versions prior to v16.0.0415 on QTS 4.5.2; versions prior to v3.0.210412 on QTS 4.3.6; versions prior to v3.0.210411 on QTS 4.3.4; versions prior to v3.0.210411 on QTS 4.3.3; versions prior to v16.0.0419 on QuTS hero h4.5.1; versions prior to v16.0.0419 on QuTScloud c4.5.1~c4.5.4. This issue does not affect: QNAP Systems Inc. HBS 2 . QNAP Systems Inc. HBS 1.3 .
{
"affected": [],
"aliases": [
"CVE-2021-28799"
],
"database_specific": {
"cwe_ids": [
"CWE-285",
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-05-13T03:15:00Z",
"severity": "CRITICAL"
},
"details": "An improper authorization vulnerability has been reported to affect QNAP NAS running HBS 3 (Hybrid Backup Sync. ) If exploited, the vulnerability allows remote attackers to log in to a device. This issue affects: QNAP Systems Inc. HBS 3 versions prior to v16.0.0415 on QTS 4.5.2; versions prior to v3.0.210412 on QTS 4.3.6; versions prior to v3.0.210411 on QTS 4.3.4; versions prior to v3.0.210411 on QTS 4.3.3; versions prior to v16.0.0419 on QuTS hero h4.5.1; versions prior to v16.0.0419 on QuTScloud c4.5.1~c4.5.4. This issue does not affect: QNAP Systems Inc. HBS 2 . QNAP Systems Inc. HBS 1.3 .",
"id": "GHSA-4v9x-j7pr-8wxq",
"modified": "2025-10-22T00:32:13Z",
"published": "2022-05-24T19:02:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-28799"
},
{
"type": "WEB",
"url": "https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2021-28799"
},
{
"type": "WEB",
"url": "https://www.qnap.com/en/security-advisory/QSA-21-13"
}
],
"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"
}
]
}
GHSA-4VC8-WVHW-M5GV
Vulnerability from github – Published: 2025-07-09 15:33 – Updated: 2025-08-26 20:21Summary
You can affect the agent binaries used in a Juju controller and the code that is run in the binaries by simply having a user account on a controller. You aren't required to have a model or any permissions. This just requires a user account in the controller database.
Details
Because of the way Juju upload tools code works in the controller it only checks that the user uploading agent binaries is authenticated and is a user tag. No more checks are performed and it allows that user to upload binaries to any model they like (as long as they know the model uuid) or upload binaries to the controller (attacker doesn't need to know any uuid's for controller or controller model).
Once the poison binaries have been uploaded any new machine that is started in the affected model or controller will get started with the poison binaries. Alternatively administrator's of the controller running either juju upgrade-controller or juju upgrade-model will force distribution of the poisoned binaries to all machines in either the model or poison the controllers themselves.
On top of this the exploit can be done with the Juju client tooling itself and no real knowledge on constructing raw API requests is required.
The tools handler is the main piece of code that is used in the APIServer for handling upload requests and persisting the data uploaded: The following code references is how Juju uses and defines this: - The tools upload handler is defined here (https://github.com/juju/juju/blob/3.6/apiserver/apiserver.go#L972) - The tools upload handler is created in the api server here (https://github.com/juju/juju/blob/4bcbd094097016b2fde926afd8c9e590eabb3f0c/apiserver/apiserver.go#L766C2-L766C25). - The main authoriser that is used for the upload handler is created here (https://github.com/juju/juju/blob/4bcbd094097016b2fde926afd8c9e590eabb3f0c/apiserver/apiserver.go#L770C2-L770C28) - The upload handler is registered for the model here (https://github.com/juju/juju/blob/4bcbd094097016b2fde926afd8c9e590eabb3f0c/apiserver/apiserver.go#L902) - The upload handler is registered for the controller here (https://github.com/juju/juju/blob/4bcbd094097016b2fde926afd8c9e590eabb3f0c/apiserver/apiserver.go#L972)
The authoriser that is used (https://github.com/juju/juju/blame/4bcbd094097016b2fde926afd8c9e590eabb3f0c/apiserver/httpcontext.go#L209) only confirms that the logged in user is authenticated and authenticated as a user tag. No other checks are performed.
The toolsUploaderHandler also uses another server func for getting the Mongo state. This also confirms a logged in user but the state that is returned to the caller is scoped to whatever model the requester has asked for. No checks are performed to make sure that the user in question actually has access to this model or the controller. See code here (https://github.com/juju/juju/blob/4e50a28cdde17832aa31634915fbe7442dca6ab3/apiserver/httpcontext.go#L38). We end up here through a few layers of indirection of https://github.com/juju/juju/blob/4bcbd094097016b2fde926afd8c9e590eabb3f0c/apiserver/apiserver.go#L768
We can also see that when handlers are registered with no model uuid scope in the handler like the controller registration of the tools upload handler, the model uuid gets defaulted to that of the controller model. See (https://github.com/juju/juju/blob/4bcbd094097016b2fde926afd8c9e590eabb3f0c/apiserver/apiserver.go#L690).
PoC
This proof of concept was done with the latest tip of the juju/juju 3.6 branch (https://github.com/juju/juju/commit/cd12b4951d657a980e113564bf2ea82f167589fd). Pull this code and work from inside of the root of the code base. It is expected that this security issue applies to 2.9 onwards as well.
Repo steps:
-
Bootstrap a new controller to lxd. This was done with a compiled client from the branch but there is no reason performing this action from latest snap won't produce the same result.
juju bootstrap localhost sec-demo -
Add a new user to the controller. This is the user with no permissions or models that we will prove the problem with.
juju add-user poisoner poisoner -
From step 2 save the registration string that the
jujuclient prints out. -
We are going to remove the local
jujuadmin credentials and information that was made during bootstrap. We will use this later on for confirming the attack.mv ~/.local/share/juju /tmp/juju-bak -
Run the
jujucli registration command for the new user that was saved from step 3. Set the new password to whatever you wish and then re-enter to login into the controller. After this step we are now logged in as an unprivileged user to the controller. -
Apply the following patch to the currently checked out
jujucode base:
cat <<EOF | git apply -
diff --git a/cmd/jujud/main.go b/cmd/jujud/main.go
index f268509a52..1b01a74b66 100644
--- a/cmd/jujud/main.go
+++ b/cmd/jujud/main.go
@@ -315,6 +315,16 @@ func Main(args []string) int {
os.Exit(exit_err)
}
+ logger.Criticalf("----------------------")
+ logger.Criticalf("----------------------")
+ logger.Criticalf("----------------------")
+ logger.Criticalf("----------------------")
+ logger.Criticalf("Got access to the binary")
+ logger.Criticalf("----------------------")
+ logger.Criticalf("----------------------")
+ logger.Criticalf("----------------------")
+ logger.Criticalf("----------------------")
+
var code int
commandName := filepath.Base(args[0])
switch commandName {
diff --git a/version/version.go b/version/version.go
index 2bbc8968c8..40af52f337 100644
--- a/version/version.go
+++ b/version/version.go
@@ -18,7 +18,7 @@ import (
// The presence and format of this constant is very important.
// The debian/rules build recipe uses this value for the version
// number of the release package.
-const version = "3.6.6"
+const version = "3.6.7"
// UserAgentVersion defines a user agent version used for communication for
// outside resources.
EOF
- Set bogus model information. To make the
sync-agent-binarycommand work below we need to set a bogus model that is in use by the client. This is done through the localmodels.yamlfile. Theuuidfeatured here does not matter at and can be set to anything that parses as a uuid injuju. This is just to trick the client tooling, the attacker could just manually construct the http request their self to bypass this.
cat <<EOF > ~/.local/share/juju/models.yaml
controllers:
sec-demo:
models:
admin/controller:
uuid: 4dde46dd-a514-491e-8a5f-b908b5310c02
type: iaas
branch: ""
current-model: admin/controller
EOF
- Next build the changes with
make simplestreams. - The output of step 9 will provide an export command to run. Please execute this command to point the
jujuclient at your local simple streams cache. - Next sync the compiled agent binaries from step 9 to the controller with
juju sync-agent-binary --debug --agent-version 3.6.7.
At this stage the controllers agent binary cache has been poisoned and the security issue has been proven.
- We can now swap back to the administrator user to start forcing binary circulation.
mv ~/.local/share/juju /tmp/juju-poisonand thenmv /tmp/juju-bak ~/.local/share/juju
At this stage the issue can be demonstrated with just a simple juju upgrade-controller and a controller upgrade will kick off. You can also upgrade a model. When I was testing this my upgrade-controller failed to shut down the controller for reasons unrelated to this security issue. I was able to log into the controller and confirm with sha256sum that the controller had downloaded the new binaries and the checksums matched. They were also symlink as the new binaries to run for machine-0. This was under /var/lib/juju/tools on the controller machine.
It would also be possible to affect new machines coming up in a model by repeating the steps above but changing the version to that of the model that you want to be poisoned.
Impact
This is a bad vulnerability in my opinion. It allows a user with no permissions to eventually consume an entire juju controller with poisoned binaries and gain access to all of the infrastructure and secrets on that controller. Through model migration it would also be possible to poison other controllers that the user doesn't have access to.
This also requires that an administrator upgrade or migrate aspects of the controller. But a bad actor could affect brand new machines coming up in the system straight away.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/juju/juju"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.0.0-20250619215741-4034aa13c7cf"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-0928"
],
"database_specific": {
"cwe_ids": [
"CWE-285",
"CWE-434"
],
"github_reviewed": true,
"github_reviewed_at": "2025-07-09T15:33:56Z",
"nvd_published_at": "2025-07-08T18:15:26Z",
"severity": "HIGH"
},
"details": "### Summary\nYou can affect the agent binaries used in a Juju controller and the code that is run in the binaries by simply having a user account on a controller. You aren\u0027t required to have a model or any permissions. This just requires a user account in the controller database.\n\n### Details\nBecause of the way Juju upload tools code works in the controller it only checks that the user uploading agent binaries is authenticated and is a user tag. No more checks are performed and it allows that user to upload binaries to any model they like (as long as they know the model uuid) or upload binaries to the controller (attacker doesn\u0027t need to know any uuid\u0027s for controller or controller model).\n\nOnce the poison binaries have been uploaded any new machine that is started in the affected model or controller will get started with the poison binaries. Alternatively administrator\u0027s of the controller running either `juju upgrade-controller` or `juju upgrade-model` will force distribution of the poisoned binaries to all machines in either the model or poison the controllers themselves.\n\nOn top of this the exploit can be done with the Juju client tooling itself and no real knowledge on constructing raw API requests is required.\n\nThe tools handler is the main piece of code that is used in the APIServer for handling upload requests and persisting the data uploaded: The following code references is how Juju uses and defines this:\n- The tools upload handler is defined here (https://github.com/juju/juju/blob/3.6/apiserver/apiserver.go#L972)\n- The tools upload handler is created in the api server here (https://github.com/juju/juju/blob/4bcbd094097016b2fde926afd8c9e590eabb3f0c/apiserver/apiserver.go#L766C2-L766C25).\n- The main authoriser that is used for the upload handler is created here (https://github.com/juju/juju/blob/4bcbd094097016b2fde926afd8c9e590eabb3f0c/apiserver/apiserver.go#L770C2-L770C28)\n- The upload handler is registered for the model here (https://github.com/juju/juju/blob/4bcbd094097016b2fde926afd8c9e590eabb3f0c/apiserver/apiserver.go#L902)\n- The upload handler is registered for the controller here (https://github.com/juju/juju/blob/4bcbd094097016b2fde926afd8c9e590eabb3f0c/apiserver/apiserver.go#L972)\n\nThe authoriser that is used (https://github.com/juju/juju/blame/4bcbd094097016b2fde926afd8c9e590eabb3f0c/apiserver/httpcontext.go#L209) only confirms that the logged in user is authenticated and authenticated as a user tag. No other checks are performed.\n\nThe `toolsUploaderHandler` also uses another server func for getting the Mongo state. This also confirms a logged in user but the state that is returned to the caller is scoped to whatever model the requester has asked for. No checks are performed to make sure that the user in question actually has access to this model or the controller. See code here (https://github.com/juju/juju/blob/4e50a28cdde17832aa31634915fbe7442dca6ab3/apiserver/httpcontext.go#L38). We end up here through a few layers of indirection of https://github.com/juju/juju/blob/4bcbd094097016b2fde926afd8c9e590eabb3f0c/apiserver/apiserver.go#L768\n\nWe can also see that when handlers are registered with no model uuid scope in the handler like the controller registration of the tools upload handler, the model uuid gets defaulted to that of the controller model. See (https://github.com/juju/juju/blob/4bcbd094097016b2fde926afd8c9e590eabb3f0c/apiserver/apiserver.go#L690).\n\n### PoC\nThis proof of concept was done with the latest tip of the `juju/juju` 3.6 branch (https://github.com/juju/juju/commit/cd12b4951d657a980e113564bf2ea82f167589fd). Pull this code and work from inside of the root of the code base. It is expected that this security issue applies to 2.9 onwards as well.\n\nRepo steps:\n\n1. Bootstrap a new controller to lxd. This was done with a compiled client from the branch but there is no reason performing this action from latest snap won\u0027t produce the same result.\n` juju bootstrap localhost sec-demo`\n\n2. Add a new user to the controller. This is the user with no permissions or models that we will prove the problem with.\n`juju add-user poisoner poisoner`\n\n3. From step 2 save the registration string that the `juju` client prints out.\n\n4. We are going to remove the local `juju` admin credentials and information that was made during bootstrap. We will use this later on for confirming the attack.\n`mv ~/.local/share/juju /tmp/juju-bak`\n\n5. Run the `juju` cli registration command for the new user that was saved from step 3. Set the new password to whatever you wish and then re-enter to login into the controller. After this step we are now logged in as an unprivileged user to the controller.\n\n6. Apply the following patch to the currently checked out `juju` code base:\n```\ncat \u003c\u003cEOF | git apply -\ndiff --git a/cmd/jujud/main.go b/cmd/jujud/main.go\nindex f268509a52..1b01a74b66 100644\n--- a/cmd/jujud/main.go\n+++ b/cmd/jujud/main.go\n@@ -315,6 +315,16 @@ func Main(args []string) int {\n \t\tos.Exit(exit_err)\n \t}\n\n+\tlogger.Criticalf(\"----------------------\")\n+\tlogger.Criticalf(\"----------------------\")\n+\tlogger.Criticalf(\"----------------------\")\n+\tlogger.Criticalf(\"----------------------\")\n+\tlogger.Criticalf(\"Got access to the binary\")\n+\tlogger.Criticalf(\"----------------------\")\n+\tlogger.Criticalf(\"----------------------\")\n+\tlogger.Criticalf(\"----------------------\")\n+\tlogger.Criticalf(\"----------------------\")\n+\n \tvar code int\n \tcommandName := filepath.Base(args[0])\n \tswitch commandName {\ndiff --git a/version/version.go b/version/version.go\nindex 2bbc8968c8..40af52f337 100644\n--- a/version/version.go\n+++ b/version/version.go\n@@ -18,7 +18,7 @@ import (\n // The presence and format of this constant is very important.\n // The debian/rules build recipe uses this value for the version\n // number of the release package.\n-const version = \"3.6.6\"\n+const version = \"3.6.7\"\n\n // UserAgentVersion defines a user agent version used for communication for\n // outside resources.\nEOF\n```\n\n7. Set bogus model information. To make the `sync-agent-binary` command work below we need to set a bogus model that is in use by the client. This is done through the local `models.yaml` file. The `uuid` featured here does not matter at and can be set to anything that parses as a uuid in `juju`. This is just to trick the client tooling, the attacker could just manually construct the http request their self to bypass this.\n```\ncat \u003c\u003cEOF \u003e ~/.local/share/juju/models.yaml\ncontrollers:\n sec-demo:\n models:\n admin/controller:\n uuid: 4dde46dd-a514-491e-8a5f-b908b5310c02\n type: iaas\n branch: \"\"\n current-model: admin/controller\nEOF\n```\n\n8. Next build the changes with `make simplestreams`.\n9. The output of step 9 will provide an export command to run. Please execute this command to point the `juju` client at your local simple streams cache.\n10. Next sync the compiled agent binaries from step 9 to the controller with `juju sync-agent-binary --debug --agent-version 3.6.7`.\n\n**At this stage the controllers agent binary cache has been poisoned and the security issue has been proven.**\n\n11. We can now swap back to the administrator user to start forcing binary circulation. `mv ~/.local/share/juju /tmp/juju-poison` and then `mv /tmp/juju-bak ~/.local/share/juju`\n\nAt this stage the issue can be demonstrated with just a simple `juju upgrade-controller` and a controller upgrade will kick off. You can also upgrade a model. When I was testing this my `upgrade-controller` failed to shut down the controller for reasons unrelated to this security issue. I was able to log into the controller and confirm with sha256sum that the controller had downloaded the new binaries and the checksums matched. They were also symlink as the new binaries to run for `machine-0`. This was under `/var/lib/juju/tools` on the controller machine.\n\nIt would also be possible to affect new machines coming up in a model by repeating the steps above but changing the version to that of the model that you want to be poisoned.\n\n### Impact\nThis is a bad vulnerability in my opinion. It allows a user with no permissions to eventually consume an entire `juju` controller with poisoned binaries and gain access to all of the infrastructure and secrets on that controller. Through model migration it would also be possible to poison other controllers that the user doesn\u0027t have access to.\n\nThis also requires that an administrator upgrade or migrate aspects of the controller. But a bad actor could affect brand new machines coming up in the system straight away.",
"id": "GHSA-4vc8-wvhw-m5gv",
"modified": "2025-08-26T20:21:38Z",
"published": "2025-07-09T15:33:56Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/juju/juju/security/advisories/GHSA-4vc8-wvhw-m5gv"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-0928"
},
{
"type": "WEB",
"url": "https://github.com/juju/juju/commit/22cdcf6b54c2f371822e1c203d4f341be6c9589e"
},
{
"type": "WEB",
"url": "https://github.com/juju/juju/commit/311e374cb8d2431032c51fb3fb5c4b0aaaa7196c"
},
{
"type": "WEB",
"url": "https://github.com/juju/juju/commit/4034aa13c7cf5a37427fcd032925d5d21955b096"
},
{
"type": "WEB",
"url": "https://github.com/juju/juju/commit/b4176e6e45c2c3c817ab60b39e2d52f9a11a5ddf"
},
{
"type": "PACKAGE",
"url": "https://github.com/juju/juju"
},
{
"type": "WEB",
"url": "https://pkg.go.dev/vuln/GO-2025-3805"
}
],
"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"
}
],
"summary": "Juju allows arbitrary executable uploads via authenticated endpoint without authorization"
}
Mitigation
- Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) to enforce the roles at the appropriate boundaries.
- Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
Mitigation
Ensure that you perform access control checks related to your business logic. These checks may be different than the access control checks that you apply to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor.
Mitigation MIT-4.4
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 authorization frameworks such as the JAAS Authorization Framework [REF-233] and the OWASP ESAPI Access Control feature [REF-45].
Mitigation
- For web applications, make sure that the access control mechanism is enforced correctly at the server side on every page. Users should not be able to access any unauthorized functionality or information by simply requesting direct access to that page.
- One way to do this is to ensure that all pages containing sensitive information are not cached, and that all such pages restrict access to requests that are accompanied by an active and authenticated session token associated with a user who has the required permissions to access that page.
Mitigation
Use the access control capabilities of your operating system and server environment and define your access control lists accordingly. Use a "default deny" policy when defining these ACLs.
CAPEC-1: Accessing Functionality Not Properly Constrained by ACLs
In applications, particularly web applications, access to functionality is mitigated by an authorization framework. This framework maps Access Control Lists (ACLs) to elements of the application's functionality; particularly URL's for web apps. In the case that the administrator failed to specify an ACL for a particular element, an attacker may be able to access it with impunity. An attacker with the ability to access functionality not properly constrained by ACLs can obtain sensitive information and possibly compromise the entire application. Such an attacker can access resources that must be available only to users at a higher privilege level, can access management sections of the application, or can run queries for data that they otherwise not supposed to.
CAPEC-104: Cross Zone Scripting
An attacker is able to cause a victim to load content into their web-browser that bypasses security zone controls and gain access to increased privileges to execute scripting code or other web objects such as unsigned ActiveX controls or applets. This is a privilege elevation attack targeted at zone-based web-browser security.
CAPEC-127: Directory Indexing
An adversary crafts a request to a target that results in the target listing/indexing the content of a directory as output. One common method of triggering directory contents as output is to construct a request containing a path that terminates in a directory name rather than a file name since many applications are configured to provide a list of the directory's contents when such a request is received. An adversary can use this to explore the directory tree on a target as well as learn the names of files. This can often end up revealing test files, backup files, temporary files, hidden files, configuration files, user accounts, script contents, as well as naming conventions, all of which can be used by an attacker to mount additional attacks.
CAPEC-13: Subverting Environment Variable Values
The adversary directly or indirectly modifies environment variables used by or controlling the target software. The adversary's goal is to cause the target software to deviate from its expected operation in a manner that benefits the adversary.
CAPEC-17: Using Malicious Files
An attack of this type exploits a system's configuration that allows an adversary to either directly access an executable file, for example through shell access; or in a possible worst case allows an adversary to upload a file and then execute it. Web servers, ftp servers, and message oriented middleware systems which have many integration points are particularly vulnerable, because both the programmers and the administrators must be in synch regarding the interfaces and the correct privileges for each interface.
CAPEC-39: Manipulating Opaque Client-based Data Tokens
In circumstances where an application holds important data client-side in tokens (cookies, URLs, data files, and so forth) that data can be manipulated. If client or server-side application components reinterpret that data as authentication tokens or data (such as store item pricing or wallet information) then even opaquely manipulating that data may bear fruit for an Attacker. In this pattern an attacker undermines the assumption that client side tokens have been adequately protected from tampering through use of encryption or obfuscation.
CAPEC-402: Bypassing ATA Password Security
An adversary exploits a weakness in ATA security on a drive to gain access to the information the drive contains without supplying the proper credentials. ATA Security is often employed to protect hard disk information from unauthorized access. The mechanism requires the user to type in a password before the BIOS is allowed access to drive contents. Some implementations of ATA security will accept the ATA command to update the password without the user having authenticated with the BIOS. This occurs because the security mechanism assumes the user has first authenticated via the BIOS prior to sending commands to the drive. Various methods exist for exploiting this flaw, the most common being installing the ATA protected drive into a system lacking ATA security features (a.k.a. hot swapping). Once the drive is installed into the new system the BIOS can be used to reset the drive password.
CAPEC-45: Buffer Overflow via Symbolic Links
This type of attack leverages the use of symbolic links to cause buffer overflows. An adversary can try to create or manipulate a symbolic link file such that its contents result in out of bounds data. When the target software processes the symbolic link file, it could potentially overflow internal buffers with insufficient bounds checking.
CAPEC-5: Blue Boxing
This type of attack against older telephone switches and trunks has been around for decades. A tone is sent by an adversary to impersonate a supervisor signal which has the effect of rerouting or usurping command of the line. While the US infrastructure proper may not contain widespread vulnerabilities to this type of attack, many companies are connected globally through call centers and business process outsourcing. These international systems may be operated in countries which have not upgraded Telco infrastructure and so are vulnerable to Blue boxing. Blue boxing is a result of failure on the part of the system to enforce strong authorization for administrative functions. While the infrastructure is different than standard current applications like web applications, there are historical lessons to be learned to upgrade the access control for administrative functions.
{'xhtml:b': 'This attack pattern is included in CAPEC for historical purposes.'}
CAPEC-51: Poison Web Service Registry
SOA and Web Services often use a registry to perform look up, get schema information, and metadata about services. A poisoned registry can redirect (think phishing for servers) the service requester to a malicious service provider, provide incorrect information in schema or metadata, and delete information about service provider interfaces.
CAPEC-59: Session Credential Falsification through Prediction
This attack targets predictable session ID in order to gain privileges. The attacker can predict the session ID used during a transaction to perform spoofing and session hijacking.
CAPEC-60: Reusing Session IDs (aka Session Replay)
This attack targets the reuse of valid session ID to spoof the target system in order to gain privileges. The attacker tries to reuse a stolen session ID used previously during a transaction to perform spoofing and session hijacking. Another name for this type of attack is Session Replay.
CAPEC-647: Collect Data from Registries
An adversary exploits a weakness in authorization to gather system-specific data and sensitive information within a registry (e.g., Windows Registry, Mac plist). These contain information about the system configuration, software, operating system, and security. The adversary can leverage information gathered in order to carry out further attacks.
CAPEC-668: Key Negotiation of Bluetooth Attack (KNOB)
An adversary can exploit a flaw in Bluetooth key negotiation allowing them to decrypt information sent between two devices communicating via Bluetooth. The adversary uses an Adversary in the Middle setup to modify packets sent between the two devices during the authentication process, specifically the entropy bits. Knowledge of the number of entropy bits will allow the attacker to easily decrypt information passing over the line of communication.
CAPEC-76: Manipulating Web Input to File System Calls
An attacker manipulates inputs to the target software which the target software passes to file system calls in the OS. The goal is to gain access to, and perhaps modify, areas of the file system that the target software did not intend to be accessible.
CAPEC-77: Manipulating User-Controlled Variables
This attack targets user controlled variables (DEBUG=1, PHP Globals, and So Forth). An adversary can override variables leveraging user-supplied, untrusted query variables directly used on the application server without any data sanitization. In extreme cases, the adversary can change variables controlling the business logic of the application. For instance, in languages like PHP, a number of poorly set default configurations may allow the user to override variables.
CAPEC-87: Forceful Browsing
An attacker employs forceful browsing (direct URL entry) to access portions of a website that are otherwise unreachable. Usually, a front controller or similar design pattern is employed to protect access to portions of a web application. Forceful browsing enables an attacker to access information, perform privileged operations and otherwise reach sections of the web application that have been improperly protected.