CWE-863
Allowed-with-ReviewIncorrect Authorization
Abstraction: Class · Status: Incomplete
The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check.
5513 vulnerabilities reference this CWE, most recent first.
GHSA-J6CV-3W8P-VRG8
Vulnerability from github – Published: 2026-04-15 21:30 – Updated: 2026-04-16 21:40A flaw was found in KubeVirt's Role-Based Access Control (RBAC) evaluation logic. The authorization mechanism improperly truncates subresource names, leading to incorrect permission evaluations. This allows authenticated users with specific custom roles to gain unauthorized access to subresources, potentially disclosing sensitive information or performing actions they are not permitted to do. Additionally, legitimate users may be denied access to resources.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "kubevirt.io/kubevirt"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "1.8.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-6383"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-16T21:40:08Z",
"nvd_published_at": "2026-04-15T19:16:38Z",
"severity": "MODERATE"
},
"details": "A flaw was found in KubeVirt\u0027s Role-Based Access Control (RBAC) evaluation logic. The authorization mechanism improperly truncates subresource names, leading to incorrect permission evaluations. This allows authenticated users with specific custom roles to gain unauthorized access to subresources, potentially disclosing sensitive information or performing actions they are not permitted to do. Additionally, legitimate users may be denied access to resources.",
"id": "GHSA-j6cv-3w8p-vrg8",
"modified": "2026-04-16T21:40:08Z",
"published": "2026-04-15T21:30:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-6383"
},
{
"type": "WEB",
"url": "https://github.com/kubevirt/kubevirt/issues/17337"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2026-6383"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2458741"
},
{
"type": "PACKAGE",
"url": "https://github.com/kubevirt/kubevirt"
}
],
"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": "KubeVirt\u0027s authorization mechanism improperly truncates subresource names"
}
GHSA-J6F6-JP3P-53MW
Vulnerability from github – Published: 2026-04-03 18:18 – Updated: 2026-04-27 16:43Summary
It is possible that a compromised workload machine under a Juju controller can read any log file for any entity in any model at any level.
There is a debug log endpoint in the API server that allows streaming of logs off of the controller. To access this endpoint you must be authentication and either be a machine agent, controller agent, controller admin or have model read permission.
The problematic is the machine agent story. The rest of the other checks have a high enough degree of safety that an attacker can not move side ways in the controller when obtaining log files.
Details
A compromised workload machine is capable of obtaining logs for both the controller and any model under the controller at any log level they wish. A bad actor can use this information as signal for further attacks or possible gain secret information leaked out in debug and trace logs. On top of this they would also be able to receive the logs from the charm itself for which we have no control over.
- here is where the authorizer is defined for the endpoint.
- here is where the authorizer is checked.
- here and onwards is the amount of information the attacker can gain access to.
PoC
If an attacker compromises a workload machine, they will have access to the agent.conf file containing the credentials. This can then be used to obtain debug logs for any part of the controller.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/juju/juju"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.0.0-20250623030540-c91a1f404695"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-68152"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-03T18:18:38Z",
"nvd_published_at": "2026-04-03T16:16:23Z",
"severity": "MODERATE"
},
"details": "### Summary\nIt is possible that a compromised workload machine under a Juju controller can read any log file for any entity in any model at any level.\n\nThere is a debug log endpoint in the API server that allows streaming of logs off of the controller. To access this endpoint you must be authentication and either be a machine agent, controller agent, controller admin or have model read permission.\n\nThe problematic is the machine agent story. The rest of the other checks have a high enough degree of safety that an attacker can not move side ways in the controller when obtaining log files.\n\n### Details\nA compromised workload machine is capable of obtaining logs for both the controller and any model under the controller at any log level they wish. A bad actor can use this information as signal for further attacks or possible gain secret information leaked out in debug and trace logs. On top of this they would also be able to receive the logs from the charm itself for which we have no control over.\n\n- [here](https://github.com/juju/juju/blob/1a8d84ec114c2e4f9921e30081e5a5549f7cbfc4/apiserver/apiserver.go#L767) is where the authorizer is defined for the endpoint.\n- [here](https://github.com/juju/juju/blob/1a8d84ec114c2e4f9921e30081e5a5549f7cbfc4/apiserver/debuglog.go#L110) is where the authorizer is checked.\n- [here](https://github.com/juju/juju/blob/1a8d84ec114c2e4f9921e30081e5a5549f7cbfc4/apiserver/debuglog.go#L115) and onwards is the amount of information the attacker can gain access to.\n\n### PoC\n\nIf an attacker compromises a workload machine, they will have access to the agent.conf file containing the credentials. This can then be used to obtain debug logs for any part of the controller.",
"id": "GHSA-j6f6-jp3p-53mw",
"modified": "2026-04-27T16:43:44Z",
"published": "2026-04-03T18:18:38Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/juju/juju/security/advisories/GHSA-j6f6-jp3p-53mw"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68152"
},
{
"type": "WEB",
"url": "https://github.com/juju/juju/commit/22cdcf6b54c2f371822e1c203d4f341be6c9589e"
},
{
"type": "WEB",
"url": "https://github.com/juju/juju/commit/c91a1f4046956874ba77c8b398aecee3d61a2dc3"
},
{
"type": "PACKAGE",
"url": "https://github.com/juju/juju"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Juju: Read All Controller Logs From Compromised Workload"
}
GHSA-J6GG-R5JC-47CM
Vulnerability from github – Published: 2025-11-14 09:30 – Updated: 2025-11-14 22:08Mattermost versions < 11 fail to properly restrict access to archived channel search API which allows guest users to discover archived public channels via the /api/v4/teams/{team_id}/channels/search_archived endpoint
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/mattermost/mattermost/server/v8"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "8.0.0-20250815165020-c8d66301415d"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/mattermost/mattermost"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.3.2-0.20250815165020-c8d66301415d"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/mattermost/mattermost-server"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.3.2-0.20250815165020-c8d66301415d"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/mattermost/mattermost-server/v5"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.3.2-0.20250815165020-c8d66301415d"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/mattermost/mattermost-server/v6"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.3.2-0.20250815165020-c8d66301415d"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-11776"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2025-11-14T22:08:04Z",
"nvd_published_at": "2025-11-14T08:15:43Z",
"severity": "MODERATE"
},
"details": "Mattermost versions \u003c 11 fail to properly restrict access to archived channel search API which allows guest users to discover archived public channels via the `/api/v4/teams/{team_id}/channels/search_archived` endpoint",
"id": "GHSA-j6gg-r5jc-47cm",
"modified": "2025-11-14T22:08:04Z",
"published": "2025-11-14T09:30:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-11776"
},
{
"type": "WEB",
"url": "https://github.com/mattermost/mattermost/commit/c8d66301415d5b447df0e829bdbaa92e8a83ecf8"
},
{
"type": "WEB",
"url": "https://mattermost.com/security-updates"
},
{
"type": "PACKAGE",
"url": "github.com/mattermost/mattermost"
}
],
"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"
}
],
"summary": "Mattermost fails to properly restrict access to archived channel search API"
}
GHSA-J6GW-77PG-859Q
Vulnerability from github – Published: 2025-04-21 18:32 – Updated: 2025-04-21 18:32The FileWave Windows client before 16.0.0, in some non-default configurations, allows an unprivileged local user to escalate privileges to SYSTEM.
{
"affected": [],
"aliases": [
"CVE-2025-43922"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-04-21T16:15:55Z",
"severity": "HIGH"
},
"details": "The FileWave Windows client before 16.0.0, in some non-default configurations, allows an unprivileged local user to escalate privileges to SYSTEM.",
"id": "GHSA-j6gw-77pg-859q",
"modified": "2025-04-21T18:32:09Z",
"published": "2025-04-21T18:32:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-43922"
},
{
"type": "WEB",
"url": "https://kb.filewave.com/books/downloads/page/filewave-version-1603"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-J6H7-3PC4-2M8J
Vulnerability from github – Published: 2022-05-13 01:50 – Updated: 2022-05-13 01:50Incorrect enforcement of authorization checks in eDirectory prior to 9.1 SP2
{
"affected": [],
"aliases": [
"CVE-2018-17950"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-12-12T14:29:00Z",
"severity": "HIGH"
},
"details": "Incorrect enforcement of authorization checks in eDirectory prior to 9.1 SP2",
"id": "GHSA-j6h7-3pc4-2m8j",
"modified": "2022-05-13T01:50:35Z",
"published": "2022-05-13T01:50:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-17950"
},
{
"type": "WEB",
"url": "https://www.netiq.com/documentation/edirectory-91/edirectory912_releasenotes/data/edirectory912_releasenotes.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-J6JP-78W8-34X6
Vulnerability from github – Published: 2026-03-13 18:56 – Updated: 2026-03-24 21:01Summary
An insufficient authorization check in the file replace API allows a user with only list visibility permission (UserPermListOtherUploads) to delete another user's file by abusing the deleteNewFile flag, bypassing the requirement for UserPermDeleteOtherUploads.
Impact
Any authenticated user with PERM_REPLACE (replace own files) and PERM_LIST (view other users' uploads) can delete any other user's file without needing PERM_DELETE.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.2.3"
},
"package": {
"ecosystem": "Go",
"name": "github.com/forceu/gokapi"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.2.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-30943"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-13T18:56:32Z",
"nvd_published_at": "2026-03-13T19:54:35Z",
"severity": "MODERATE"
},
"details": "## Summary\n\nAn insufficient authorization check in the file replace API allows a user with only list visibility permission (`UserPermListOtherUploads`) to delete another user\u0027s file by abusing the `deleteNewFile` flag, bypassing the requirement for `UserPermDeleteOtherUploads`.\n\n### Impact\n\nAny authenticated user with `PERM_REPLACE` (replace own files) and `PERM_LIST` (view other users\u0027 uploads) can delete any other user\u0027s file without needing `PERM_DELETE`.",
"id": "GHSA-j6jp-78w8-34x6",
"modified": "2026-03-24T21:01:40Z",
"published": "2026-03-13T18:56:32Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/Forceu/Gokapi/security/advisories/GHSA-j6jp-78w8-34x6"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-30943"
},
{
"type": "PACKAGE",
"url": "https://github.com/Forceu/Gokapi"
},
{
"type": "WEB",
"url": "https://github.com/Forceu/Gokapi/releases/tag/v2.2.4"
},
{
"type": "WEB",
"url": "https://pkg.go.dev/vuln/GO-2026-4696"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:N/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Gokapi vulnerable to Privilege Escalation in File Replace"
}
GHSA-J6RQ-W94J-R7M5
Vulnerability from github – Published: 2022-05-24 17:20 – Updated: 2022-05-24 17:20A vulnerability in the Web Access feature of Cisco IP Phones Series 7800 and Series 8800 could allow an unauthenticated, remote attacker to view sensitive information on an affected device. The vulnerability is due to improper access controls on the web-based management interface of an affected device. An attacker could exploit this vulnerability by sending malicious requests to the device, which could allow the attacker to bypass access restrictions. A successful attack could allow the attacker to view sensitive information, including device call logs that contain names, usernames, and phone numbers of users of the device.
{
"affected": [],
"aliases": [
"CVE-2020-3360"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-06-18T03:15:00Z",
"severity": "MODERATE"
},
"details": "A vulnerability in the Web Access feature of Cisco IP Phones Series 7800 and Series 8800 could allow an unauthenticated, remote attacker to view sensitive information on an affected device. The vulnerability is due to improper access controls on the web-based management interface of an affected device. An attacker could exploit this vulnerability by sending malicious requests to the device, which could allow the attacker to bypass access restrictions. A successful attack could allow the attacker to view sensitive information, including device call logs that contain names, usernames, and phone numbers of users of the device.",
"id": "GHSA-j6rq-w94j-r7m5",
"modified": "2022-05-24T17:20:59Z",
"published": "2022-05-24T17:20:59Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-3360"
},
{
"type": "WEB",
"url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-phone-logs-2O7f7ExM"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-J6WP-3859-VXFG
Vulnerability from github – Published: 2021-11-10 16:52 – Updated: 2021-11-08 21:37Impact
Changes to the OIDC claims of a user after initial login are not reflected in policy evaluation when using allowed_idp_claims as part of policy. If using allowed_idp_claims and a user's claims are changed, Pomerium can make incorrect authorization decisions.
Patches
v0.15.6
Workarounds
- Clear data on
databrokerservice by clearing redis or restarting the in-memory databroker to force claims to be updated
References
https://github.com/pomerium/pomerium/pull/2724
For more information
If you have any questions or comments about this advisory: * Open an issue in Pomerium * Email us at security@pomerium.com
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/pomerium/pomerium"
},
"ranges": [
{
"events": [
{
"introduced": "0.14.0"
},
{
"fixed": "0.15.6"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2021-41230"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2021-11-08T21:37:07Z",
"nvd_published_at": "2021-11-05T23:15:00Z",
"severity": "MODERATE"
},
"details": "### Impact\nChanges to the OIDC claims of a user after initial login are not reflected in policy evaluation when using [`allowed_idp_claims`](https://www.pomerium.com/reference/#allowed-idp-claims) as part of policy. If using `allowed_idp_claims` and a user\u0027s claims are changed, Pomerium can make incorrect authorization decisions.\n\n### Patches\nv0.15.6\n\n### Workarounds\n- Clear data on `databroker` service by clearing redis or restarting the in-memory databroker to force claims to be updated\n\n### References\nhttps://github.com/pomerium/pomerium/pull/2724\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Open an issue in [Pomerium](https://github.com/pomerium/pomerium)\n* Email us at [security@pomerium.com](mailto:security@pomerium.com)\n",
"id": "GHSA-j6wp-3859-vxfg",
"modified": "2021-11-08T21:37:07Z",
"published": "2021-11-10T16:52:24Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/pomerium/pomerium/security/advisories/GHSA-j6wp-3859-vxfg"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-41230"
},
{
"type": "WEB",
"url": "https://github.com/pomerium/pomerium/pull/2724"
},
{
"type": "WEB",
"url": "https://github.com/pomerium/pomerium/commit/f20542c4bf2cc691e4c324f7ec79e02e46d95511"
},
{
"type": "PACKAGE",
"url": "https://github.com/pomerium/pomerium"
},
{
"type": "WEB",
"url": "https://pkg.go.dev/vuln/GO-2021-0258"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "OIDC claims not updated from Identity Provider in Pomerium"
}
GHSA-J732-2X82-535H
Vulnerability from github – Published: 2024-06-11 06:31 – Updated: 2024-08-23 03:30Incorrect authorization vulnerability in Cybozu Garoon 5.0.0 to 5.15.2 allows a remote authenticated attacker to delete the data of Shared To-Dos.
{
"affected": [],
"aliases": [
"CVE-2024-31402"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-06-11T06:15:10Z",
"severity": "MODERATE"
},
"details": "Incorrect authorization vulnerability in Cybozu Garoon 5.0.0 to 5.15.2 allows a remote authenticated attacker to delete the data of Shared To-Dos.",
"id": "GHSA-j732-2x82-535h",
"modified": "2024-08-23T03:30:58Z",
"published": "2024-06-11T06:31:47Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-31402"
},
{
"type": "WEB",
"url": "https://cs.cybozu.co.jp/2024/007901.html"
},
{
"type": "WEB",
"url": "https://jvn.jp/en/jp/JVN28869536"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-J748-H363-WQJ8
Vulnerability from github – Published: 2026-06-26 22:32 – Updated: 2026-06-26 22:32Impact
CVSSv4 Baseline Score: Low 2.4
CVSSv4 Weighted Score: Low 1.3
The full CVSSv4 Vector for this vulnerability is:
CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:L/VI:N/VA:N/SC:L/SI:N/SA:N/E:P/CR:H/IR:L/AR:L/MAV:N/MAC:H/MAT:P/MPR:L/MVC:L/MVI:N/MVA:N/MSC:L/MSI:N/MSA:N/S:N/AU:Y/R:U/V:D/RE:L/U:Amber
CVSSv3.1 Baseline Score: Low 3.1
CVSSv3.1 Overall Score: Low 3.4
The full CVSSv3.1 Vector equivalent for this vulnerability is:
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N/E:P/RL:O/RC:C/CR:H/IR:L/AR:L/MAV:N/MAC:H/MPR:L/MUI:X/MS:U/MC:L/MI:N/MA:N
The weighted severity rating is a result of no indication this is currently being exploited being available at the time of the publish date, in addition to the fact it's unlikely that it is being exploited currently. The vectors have been picked based on the scenario most likely to exist in real configurations.
In addition to the weighting our assessment considers the fact the configuration scenario required for this vulnerability to be exploited is highly unlikely and an attacker is unlikely in most scenarios to be able to determine if the exploit is available and if it was successful except in rare situations. Though the visibility to the attacker was not reflected in our assessment.
Summary
Due to lack of canonicalization of domains in very specific edge cases an access control rule may be skipped when it should match a request.
Details
This attack vector must be executed in a highly specific scenario which we do not believe any user would find themselves in. In an abundance of caution we are issuing this advisory and would appreciate any users who find this configuration report it to us with both the access control section, and sessions section so that we can best advise the community of the actual impact.
The specific conditions that could lead to a security issue for vulnerability are as follows:
- The specific target resource of the attack must be using the forwarded authorization integration.
- The requested domain must have two additional segments compared to a session domain i.e.
a.b.example.comis requested, but the session domain isexample.com. - There access control rules must specify two separate rules which both contain inexact domain matches such as
*.b.example.comand*.example.comi.e. wildcards, username matches, group matches. - The rules must be in order of most specific domain to least specific domain.
- The second rule must be more permissive than the first rule.
- The second rule must also match all criteria of the given request.
- The attacker must specifically request a URL for the more specific domain, with the second part containing one or more capitalized letters i.e.
https://a.B.example.comand no other segment with capitalized letters. - The integration used must not be the Envoy ExtAuthz integration.
- The proxy must not canonicalize the requested host name in the relevant header before sending it to the relevant authorization endpoint.
The kind of configuration used to produce this issue and result in a bypass rule being matched has long been highly discouraged. Essentially hosts which should be bypassed entirely should not be secured by having the proxy check them with the authorization handlers.
It should also be noted this has been heavily mitigated due to another bug where the session domain would not match if any part of the configured session domain was capitalized (fixed in https://github.com/authelia/authelia/commit/368631ecc5a9c6bcf2ff5f892ad443b890dd945e, it should be expressly noted this commit does not contain a fix for a CVE). This bug would prevent the request from succeeding in any way. This bug will also be fixed after this vulnerability is fixed, and the bug where session domains would not match has no security impact other than heavily mitigating the access control vulnerability.
Patches
Upgrade to 4.39.20.
Commit: https://github.com/authelia/authelia/commit/b6d1d60baa02f216fdb19f5dfeaf2e805829508a
Workarounds
See the below examples for configurations to avoid.
Examples
1FA Downgrade
The following example could result in a 1FA downgrade.
Request URL: https://a.B.example.com
Configuration:
session:
cookies:
- domain: 'example.com'
authelia_url: 'https://example.com'
access_control:
rules:
- domain: '*.b.example.com'
policy: 'two_factor'
- domain: '*.example.com'
policy: 'one_factor'
Bypass Downgrade
The following example could result in a bypass downgrade. It should be noted that configurations like this have long been discouraged. The domains matching the pattern *.example.com should not be configured to forward authorization requests to Authelia in most situations.
Request URL: https://a.B.example.com
Configuration:
session:
cookies:
- domain: 'example.com'
authelia_url: 'https://example.com'
access_control:
rules:
- domain: '*.b.example.com'
policy: 'two_factor'
- domain: '*.example.com'
policy: 'bypass'
Unaffected Scenario
The following configuration is unaffected regardless of the request.
session:
cookies:
- domain: 'example.com'
authelia_url: 'https://example.com'
access_control:
rules:
- domain: 'b.example.com'
policy: 'two_factor'
- domain: '*.example.com'
policy: 'one_factor'
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.39.19"
},
"package": {
"ecosystem": "Go",
"name": "github.com/authelia/authelia/v4"
},
"ranges": [
{
"events": [
{
"introduced": "4.36.0"
},
{
"fixed": "4.39.20"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-48794"
],
"database_specific": {
"cwe_ids": [
"CWE-178",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-26T22:32:21Z",
"nvd_published_at": "2026-06-19T21:17:01Z",
"severity": "LOW"
},
"details": "### Impact\n\n**CVSSv4 Baseline Score:** Low 2.4\n\n**CVSSv4 Weighted Score:** Low 1.3\n\nThe full CVSSv4 Vector for this vulnerability is:\n\n\u003e CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:L/VI:N/VA:N/SC:L/SI:N/SA:N/E:P/CR:H/IR:L/AR:L/MAV:N/MAC:H/MAT:P/MPR:L/MVC:L/MVI:N/MVA:N/MSC:L/MSI:N/MSA:N/S:N/AU:Y/R:U/V:D/RE:L/U:Amber\n\n**CVSSv3.1 Baseline Score:** Low 3.1\n\n**CVSSv3.1 Overall Score:** Low 3.4\n\nThe full CVSSv3.1 Vector equivalent for this vulnerability is:\n\n\u003e CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N/E:P/RL:O/RC:C/CR:H/IR:L/AR:L/MAV:N/MAC:H/MPR:L/MUI:X/MS:U/MC:L/MI:N/MA:N\n\nThe weighted severity rating is a result of no indication this is currently being exploited being available at the time of the publish date, in addition to the fact it\u0027s unlikely that it is being exploited currently. The vectors have been picked based on the scenario most likely to exist in real configurations.\n\nIn addition to the weighting our assessment considers the fact the configuration scenario required for this vulnerability to be exploited is highly unlikely and an attacker is unlikely in most scenarios to be able to determine if the exploit is available and if it was successful except in rare situations. Though the visibility to the attacker was not reflected in our assessment.\n\n### Summary\n\nDue to lack of canonicalization of domains in very specific edge cases an access control rule may be skipped when it should match a request.\n\n### Details\n\nThis attack vector must be executed in a highly specific scenario which we do not believe any user would find themselves in. In an abundance of caution we are issuing this advisory and would appreciate any users who find this configuration report it to us with both the access control section, and sessions section so that we can best advise the community of the actual impact.\n\nThe specific conditions that could lead to a security issue for vulnerability are as follows:\n\n1. The specific target resource of the attack must be using the forwarded authorization integration.\n2. The requested domain must have two additional segments compared to a session domain i.e. `a.b.example.com` is requested, but the session domain is `example.com`.\n3. There access control rules must specify two separate rules which both contain inexact domain matches such as `*.b.example.com` and `*.example.com` i.e. wildcards, username matches, group matches.\n4. The rules must be in order of most specific domain to least specific domain.\n5. The second rule must be **more permissive** than the first rule.\n6. The second rule must also **match all criteria** of the given request.\n7. The attacker must specifically request a URL for the more specific domain, with the second part containing one or more capitalized letters i.e. `https://a.B.example.com` and no other segment with capitalized letters.\n8. The integration used must not be the Envoy ExtAuthz integration.\n9. The proxy must not canonicalize the requested host name in the relevant header before sending it to the relevant authorization endpoint.\n\nThe kind of configuration used to produce this issue and result in a `bypass` rule being matched has long been highly discouraged. Essentially hosts which should be bypassed entirely should not be secured by having the proxy check them with the authorization handlers.\n\nIt should also be noted this has been heavily mitigated due to another bug where the session domain would not match if any part of the configured session domain was capitalized (fixed in https://github.com/authelia/authelia/commit/368631ecc5a9c6bcf2ff5f892ad443b890dd945e, it should be expressly noted this commit does not contain a fix for a CVE). This bug would prevent the request from succeeding in any way. This bug will also be fixed after this vulnerability is fixed, and the bug where session domains would not match has no security impact other than heavily mitigating the access control vulnerability.\n\n### Patches\n\nUpgrade to 4.39.20.\n\nCommit: https://github.com/authelia/authelia/commit/b6d1d60baa02f216fdb19f5dfeaf2e805829508a\n\n### Workarounds\n\nSee the below examples for configurations to avoid.\n\n#### Examples\n\n##### 1FA Downgrade\n\nThe following example could result in a 1FA downgrade.\n\n**Request URL:** `https://a.B.example.com`\n\n**Configuration:**\n\n```yaml\nsession:\n cookies:\n - domain: \u0027example.com\u0027\n authelia_url: \u0027https://example.com\u0027\naccess_control:\n rules:\n - domain: \u0027*.b.example.com\u0027\n policy: \u0027two_factor\u0027\n - domain: \u0027*.example.com\u0027\n policy: \u0027one_factor\u0027\n```\n\n##### Bypass Downgrade\n\nThe following example could result in a bypass downgrade. It should be noted that configurations like this have long been discouraged. The domains matching the pattern `*.example.com` should not be configured to forward authorization requests to Authelia in most situations.\n\n**Request URL:** `https://a.B.example.com`\n\n**Configuration:**\n\n```yaml\nsession:\n cookies:\n - domain: \u0027example.com\u0027\n authelia_url: \u0027https://example.com\u0027\naccess_control:\n rules:\n - domain: \u0027*.b.example.com\u0027\n policy: \u0027two_factor\u0027\n - domain: \u0027*.example.com\u0027\n policy: \u0027bypass\u0027\n```\n\n##### Unaffected Scenario\n\nThe following configuration is unaffected regardless of the request.\n\n```yaml\nsession:\n cookies:\n - domain: \u0027example.com\u0027\n authelia_url: \u0027https://example.com\u0027\naccess_control:\n rules:\n - domain: \u0027b.example.com\u0027\n policy: \u0027two_factor\u0027\n - domain: \u0027*.example.com\u0027\n policy: \u0027one_factor\u0027\n```",
"id": "GHSA-j748-h363-wqj8",
"modified": "2026-06-26T22:32:21Z",
"published": "2026-06-26T22:32:21Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/authelia/authelia/security/advisories/GHSA-j748-h363-wqj8"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-48794"
},
{
"type": "WEB",
"url": "https://github.com/authelia/authelia/commit/b6d1d60baa02f216fdb19f5dfeaf2e805829508a"
},
{
"type": "PACKAGE",
"url": "https://github.com/authelia/authelia"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:L/VI:N/VA:N/SC:L/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Authelia has an Edge Case Access Control Rule Mismatch"
}
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) [REF-229] 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 access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied 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 [REF-7].
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.
No CAPEC attack patterns related to this CWE.