Common Weakness Enumeration
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.
5659 vulnerabilities reference this CWE, most recent first.
GHSA-Q5XQ-RVPH-WWGR
Vulnerability from github – Published: 2026-04-03 00:31 – Updated: 2026-04-03 00:31
VLAI
Details
Improper authorization in Microsoft Azure Kubernetes Service allows an unauthorized attacker to elevate privileges over a network.
Severity
10.0 (Critical)
{
"affected": [],
"aliases": [
"CVE-2026-33105"
],
"database_specific": {
"cwe_ids": [
"CWE-285",
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-03T00:16:05Z",
"severity": "CRITICAL"
},
"details": "Improper authorization in Microsoft Azure Kubernetes Service allows an unauthorized attacker to elevate privileges over a network.",
"id": "GHSA-q5xq-rvph-wwgr",
"modified": "2026-04-03T00:31:09Z",
"published": "2026-04-03T00:31:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33105"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-33105"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-Q623-F4J4-P4XJ
Vulnerability from github – Published: 2026-05-28 21:32 – Updated: 2026-07-02 17:44
VLAI
Summary
OpenStack Keystone has an Incorrect Authorization issue
Details
An issue was discovered in OpenStack Keystone before 29.0.2. When combined with an application credential impersonation vulnerability, an attacker with the member role on a project can escalate to admin by chaining unrestricted application credentials with Keystone trusts. The impersonated token carries the victim's identity, which passes the trustor validation check. Keystone then validates the delegated roles against the victim's actual role assignments in the database, not the roles on the requesting token. This allows the attacker to create a trust delegating the victim's admin role to themselves. The trust persists independently, and additional trusts and application credentials can be created to maintain access. All actions are logged under the victim's identity.
Severity
6.0 (Medium)
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "keystone"
},
"ranges": [
{
"events": [
{
"introduced": "14.0.0"
},
{
"fixed": "27.0.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "keystone"
},
"ranges": [
{
"events": [
{
"introduced": "28.0.0"
},
{
"fixed": "28.0.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "keystone"
},
"ranges": [
{
"events": [
{
"introduced": "29.0.0"
},
{
"fixed": "29.0.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-43000"
],
"database_specific": {
"cwe_ids": [
"CWE-266",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-02T17:44:16Z",
"nvd_published_at": "2026-05-28T19:16:37Z",
"severity": "MODERATE"
},
"details": "An issue was discovered in OpenStack Keystone before 29.0.2. When combined with an application credential impersonation vulnerability, an attacker with the member role on a project can escalate to admin by chaining unrestricted application credentials with Keystone trusts. The impersonated token carries the victim\u0027s identity, which passes the trustor validation check. Keystone then validates the delegated roles against the victim\u0027s actual role assignments in the database, not the roles on the requesting token. This allows the attacker to create a trust delegating the victim\u0027s admin role to themselves. The trust persists independently, and additional trusts and application credentials can be created to maintain access. All actions are logged under the victim\u0027s identity.",
"id": "GHSA-q623-f4j4-p4xj",
"modified": "2026-07-02T17:44:16Z",
"published": "2026-05-28T21:32:02Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43000"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2026-43000"
},
{
"type": "WEB",
"url": "https://bugs.launchpad.net/keystone/+bug/2148477"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2482826"
},
{
"type": "PACKAGE",
"url": "https://github.com/openstack/keystone"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/keystone/PYSEC-2026-601.yaml"
},
{
"type": "WEB",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-43000.json"
},
{
"type": "WEB",
"url": "https://security.openstack.org/ossa/OSSA-2026-015.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:L/A:L",
"type": "CVSS_V3"
}
],
"summary": "OpenStack Keystone has an Incorrect Authorization issue"
}
GHSA-Q64V-P3VV-M993
Vulnerability from github – Published: 2022-05-24 16:51 – Updated: 2023-01-31 15:30
VLAI
Details
Application permissions give additional remote troubleshooting permission to the site input.mozilla.org, which has been retired and now redirects to another site. This additional permission is unnecessary and is a potential vector for malicious attacks. This vulnerability affects Firefox < 68.
Severity
6.1 (Medium)
{
"affected": [],
"aliases": [
"CVE-2019-11724"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-07-23T14:15:00Z",
"severity": "MODERATE"
},
"details": "Application permissions give additional remote troubleshooting permission to the site input.mozilla.org, which has been retired and now redirects to another site. This additional permission is unnecessary and is a potential vector for malicious attacks. This vulnerability affects Firefox \u003c 68.",
"id": "GHSA-q64v-p3vv-m993",
"modified": "2023-01-31T15:30:33Z",
"published": "2022-05-24T16:51:01Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-11724"
},
{
"type": "WEB",
"url": "https://bugzilla.mozilla.org/show_bug.cgi?id=1512511"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/201908-12"
},
{
"type": "WEB",
"url": "https://www.mozilla.org/security/advisories/mfsa2019-21"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2019-10/msg00009.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2019-10/msg00010.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2019-10/msg00011.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2019-10/msg00017.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-Q67Q-RG47-HFHR
Vulnerability from github – Published: 2024-10-01 03:30 – Updated: 2024-10-01 03:30
VLAI
Details
RevoWorks Cloud Client 3.0.91 and earlier contains an incorrect authorization vulnerability. If this vulnerability is exploited, unintended processes may be executed in the sandbox environment. Even if malware is executed in the sandbox environment, it does not compromise the client's local environment. However, information in the sandbox environment may be disclosed to outside or behaviors of the sandbox environment may be violated by tampering registry.
Severity
7.8 (High)
{
"affected": [],
"aliases": [
"CVE-2024-47560"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-10-01T02:15:10Z",
"severity": "HIGH"
},
"details": "RevoWorks Cloud Client 3.0.91 and earlier contains an incorrect authorization vulnerability. If this vulnerability is exploited, unintended processes may be executed in the sandbox environment. Even if malware is executed in the sandbox environment, it does not compromise the client\u0027s local environment. However, information in the sandbox environment may be disclosed to outside or behaviors of the sandbox environment may be violated by tampering registry.",
"id": "GHSA-q67q-rg47-hfhr",
"modified": "2024-10-01T03:30:33Z",
"published": "2024-10-01T03:30:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47560"
},
{
"type": "WEB",
"url": "https://jscom.jp/news-20240918"
},
{
"type": "WEB",
"url": "https://jvn.jp/en/jp/JVN39280069"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-Q6HG-6M9X-5G9C
Vulnerability from github – Published: 2024-07-10 14:19 – Updated: 2024-07-10 14:19
VLAI
Summary
Evmos vulnerable to exploit of smart contract account and vesting
Details
Summary
This advisory board aims to describe two vulnerabilities found in the Evmos codebase:
- Authorization check on the fundVestingAccount: unauthorized spend of funds.
Details
Authorization check on the fundVestingAccount
With the current implementation, a user can create a vesting account with a 3rd party account (EOA or contract) as funder. Then, this user can create an authorization for the contract.CallerAddress, this is the authorization checked in the code. But the funds are taken from the funder address provided in the message. Consequently, the user can fund a vesting account with a 3rd party account without its permission. The funder address can be any address, so this vulnerability can be used to drain all the accounts in the chain.
Severity
Based on ImmuneFi Severity Classification System the severity was evaluated to Critical since the attack could have lead to direct loss of funds.
Patches
The issue has been patched in versions >=V19.0.0
Severity
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 18.0.1"
},
"package": {
"ecosystem": "Go",
"name": "github.com/evmos/evmos/v18"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "19.0.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-39696"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2024-07-10T14:19:51Z",
"nvd_published_at": "2024-07-05T19:15:10Z",
"severity": "HIGH"
},
"details": "### Summary\n\nThis advisory board aims to describe two vulnerabilities found in the Evmos codebase:\n\n- _Authorization check on the fundVestingAccount_: unauthorized spend of funds.\n\n### Details\n\n#### Authorization check on the fundVestingAccount\n\nWith the current implementation, a user can create a vesting account with a 3rd party account (EOA or contract) as funder. Then, this user can create an authorization for the contract.CallerAddress, this is the authorization checked in the code. But the funds are taken from the funder address provided in the message. Consequently, the user can fund a vesting account with a 3rd party account without its permission. The funder address can be any address, so this vulnerability can be used to drain all the accounts in the chain.\n\n### Severity\nBased on [ImmuneFi Severity Classification System](https://immunefisupport.zendesk.com/hc/en-us/articles/13332717597585-Severity-Classification-System) the severity was evaluated to Critical since the attack could have lead to direct loss of funds.\n\n### Patches\nThe issue has been patched in versions \u003e=V19.0.0",
"id": "GHSA-q6hg-6m9x-5g9c",
"modified": "2024-07-10T14:19:51Z",
"published": "2024-07-10T14:19:51Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/evmos/evmos/security/advisories/GHSA-q6hg-6m9x-5g9c"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39696"
},
{
"type": "WEB",
"url": "https://github.com/evmos/evmos/commit/0a620e176617a835ac697eea494afea09185dfaf"
},
{
"type": "PACKAGE",
"url": "https://github.com/evmos/evmos"
}
],
"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"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Evmos vulnerable to exploit of smart contract account and vesting"
}
GHSA-Q6MV-M62H-7Q28
Vulnerability from github – Published: 2022-05-24 16:52 – Updated: 2024-04-04 01:35
VLAI
Details
A vulnerability in the web management interface of Cisco Small Business 220 Series Smart Switches could allow an unauthenticated, remote attacker to upload arbitrary files. The vulnerability is due to incomplete authorization checks in the web management interface. An attacker could exploit this vulnerability by sending a malicious request to certain parts of the web management interface. Depending on the configuration of the affected switch, the malicious request must be sent via HTTP or HTTPS. A successful exploit could allow the attacker to modify the configuration of an affected device or to inject a reverse shell. This vulnerability affects Cisco Small Business 220 Series Smart Switches running firmware versions prior to 1.1.4.4 with the web management interface enabled. The web management interface is enabled via both HTTP and HTTPS by default.
Severity
9.1 (Critical)
{
"affected": [],
"aliases": [
"CVE-2019-1912"
],
"database_specific": {
"cwe_ids": [
"CWE-285",
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-08-07T06:15:00Z",
"severity": "CRITICAL"
},
"details": "A vulnerability in the web management interface of Cisco Small Business 220 Series Smart Switches could allow an unauthenticated, remote attacker to upload arbitrary files. The vulnerability is due to incomplete authorization checks in the web management interface. An attacker could exploit this vulnerability by sending a malicious request to certain parts of the web management interface. Depending on the configuration of the affected switch, the malicious request must be sent via HTTP or HTTPS. A successful exploit could allow the attacker to modify the configuration of an affected device or to inject a reverse shell. This vulnerability affects Cisco Small Business 220 Series Smart Switches running firmware versions prior to 1.1.4.4 with the web management interface enabled. The web management interface is enabled via both HTTP and HTTPS by default.",
"id": "GHSA-q6mv-m62h-7q28",
"modified": "2024-04-04T01:35:09Z",
"published": "2022-05-24T16:52:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-1912"
},
{
"type": "WEB",
"url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20190806-sb220-auth_bypass"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/154667/Realtek-Managed-Switch-Controller-RTL83xx-Stack-Overflow.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-Q6P4-2Q7C-4VW7
Vulnerability from github – Published: 2022-05-24 19:07 – Updated: 2022-05-24 19:07
VLAI
Details
Improper authorization in handler for custom URL scheme vulnerability in GU App for Android versions from 4.8.0 to 5.0.2 allows a remote attacker to lead a user to access an arbitrary website via the vulnerable App.
Severity
4.3 (Medium)
{
"affected": [],
"aliases": [
"CVE-2021-20777"
],
"database_specific": {
"cwe_ids": [
"CWE-862",
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-07-07T08:15:00Z",
"severity": "MODERATE"
},
"details": "Improper authorization in handler for custom URL scheme vulnerability in GU App for Android versions from 4.8.0 to 5.0.2 allows a remote attacker to lead a user to access an arbitrary website via the vulnerable App.",
"id": "GHSA-q6p4-2q7c-4vw7",
"modified": "2022-05-24T19:07:09Z",
"published": "2022-05-24T19:07:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-20777"
},
{
"type": "WEB",
"url": "https://jvn.jp/en/jp/JVN25850723/index.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-Q6PH-8227-6M8X
Vulnerability from github – Published: 2026-03-16 21:34 – Updated: 2026-03-16 21:34
VLAI
Details
Mattermost versions 10.11.x <= 10.11.10 fail to properly validate permission requirements in the team member roles API endpoint which allows team administrators to demote members to guest role. Mattermost Advisory ID: MMSA-2025-00531
Severity
{
"affected": [],
"aliases": [
"CVE-2026-26230"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-16T21:16:33Z",
"severity": "LOW"
},
"details": "Mattermost versions 10.11.x \u003c= 10.11.10 fail to properly validate permission requirements in the team member roles API endpoint which allows team administrators to demote members to guest role. Mattermost Advisory ID: MMSA-2025-00531",
"id": "GHSA-q6ph-8227-6m8x",
"modified": "2026-03-16T21:34:33Z",
"published": "2026-03-16T21:34:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-26230"
},
{
"type": "WEB",
"url": "https://mattermost.com/security-updates"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-Q6W3-HPFV-RG36
Vulnerability from github – Published: 2026-05-29 22:05 – Updated: 2026-05-29 22:05
VLAI
Summary
Admidio: IDOR in documents-files.php allows cross-folder file rename and description changes by unauthorized uploaders
Details
Summary
modules/documents-files.php mode file_rename_save shares the same root-cause shape as the cross-folder move bug (05-documents-cross-folder-move-idor.md): the top-level rights check at lines 79-89 validates hasUploadRight() on the URL parameter folder_uuid, but the rename operation acts on file_uuid — a separate URL parameter — without re-checking the folder that actually contains the file. DocumentsService::renameFile() resolves the target file via getFileForDownload() (which permits view-readable files) but does not require upload right on the file's source folder. Result: a user with upload right on any folder A can rename a file in folder B as long as they can view it. They can also overwrite the file's description.
Details
Vulnerable Code
modules/documents-files.php:79-89 — top-level check binds to URL folder_uuid:
if ($getMode != 'list' && $getMode != 'download') {
$folder = new Folder($gDb);
$folder->getFolderForDownload($getFolderUUID);
if (!$folder->hasUploadRight()) {
$gMessage->show($gL10n->get('SYS_NO_RIGHTS'));
}
}
src/Documents/Service/DocumentsService.php:272-315 — renameFile() resolves the file via getFileForDownload() (view-only) and never re-verifies upload right on the file's parent:
public function renameFile(string $fileUUID, string $newName, string $newDescription): array
{
$file = new File($this->db);
$file->getFileForDownload($fileUUID); // <-- view rights, not upload
...
$oldFile = $file->getFullFilePath();
$newFile = $newName . '.' . pathinfo($oldFile, PATHINFO_EXTENSION);
$newPath = pathinfo($oldFile, PATHINFO_DIRNAME) . '/';
FileSystemUtils::moveFile($oldFile, $newPath . $newFile);
$file->setValue('fil_name', $newFile);
$file->setValue('fil_description', $newDescription);
$file->save();
...
}
getFileForDownload() enforces only the download (read) ACL on the file's folder. There is no hasUploadRight() check anywhere in the rename path. The actual file remains in its original folder; only its name and description change. This means the modified metadata is visible to every other user who legitimately has download rights on that folder, while the modification itself was performed by a user who has no edit right on it.
Exploitation Primitive
- Attacker user
lowuserholdsfolder_uploadonpublic_uploadable(UUIDc41a99c0-…). They have view (download) rights onview_only_public(UUID21b417e2-…,fol_public=1) but no upload/edit right there. The folder containsadmin_announcement.txt(UUIDaaae5edd-…). - Render the rename form with a
folder_uuidof a folder lowuser CAN upload to and afile_uuidof the target file:GET /modules/documents-files.php?mode=file_rename&folder_uuid=c41a99c0-…&file_uuid=aaae5edd-…The top-level rights check at line 85 sees the public-uploadable folder and passes. - Submit rename:
POST /modules/documents-files.php?mode=file_rename_save&folder_uuid=c41a99c0-…&file_uuid=aaae5edd-…withadm_csrf_token=<from step 2>,adm_new_name=hijacked_announcement,adm_new_description=Hijacked!. Server replies{"status":"success"}.adm_files:fil_fol_id=7(still the originalview_only_public),fil_name='hijacked_announcement.txt',fil_description='Hijacked!'. On disk:admin_announcement.txtis renamed tohijacked_announcement.txtin its original folder.
PoC
Captured live against HEAD c5cde53 (mariadb on 127.0.0.1:3399, php on 127.0.0.1:8085):
$ curl -sb $cookie \
"http://127.0.0.1:8085/modules/documents-files.php?mode=file_rename&folder_uuid=c41a99c0-…&file_uuid=aaae5edd-…"
# form rendered, CSRF token X added to session
$ curl -sb $cookie -X POST \
"http://127.0.0.1:8085/modules/documents-files.php?mode=file_rename_save&folder_uuid=c41a99c0-…&file_uuid=aaae5edd-…" \
-d "adm_csrf_token=X&adm_new_name=hijacked_announcement&adm_new_description=Hijacked%21"
{"status":"success", …}
$ mariadb -h 127.0.0.1 -P 3399 -u admidio -p… admidio \
-e "SELECT fil_fol_id, fil_name, fil_description FROM adm_files WHERE fil_uuid='aaae5edd-…';"
fil_fol_id fil_name fil_description
7 hijacked_announcement.txt Hijacked!
The folder ID fil_fol_id=7 is view_only_public — the folder that lowuser had no upload right on. The change was applied as if lowuser were authorised.
Impact
A user with the most basic Documents permission — upload to a single folder — can rename and overwrite descriptions of files in any other folder they can read. Confidentiality is unaffected (the actor already had download rights on the affected files), but integrity is broken across folder boundaries. Concretely:
- Defacement of public announcements / policies / circulars. A regular member can replace
admin_announcement.txtwithhijacked_announcement.txtand a description that misrepresents the content. Other readers see the malicious metadata. - Renaming-to-confuse. Files can be renamed to identifiers that imply different content (
board_minutes_2025-Q4.pdf→board_minutes_DRAFT-do-not-distribute.pdf). - Description-as-XSS-vector (downstream): if any view path treats
fil_descriptionas raw HTML, this becomes a stored XSS by a low-privilege user; absent that, it is plain content tampering.
The CVSS reflects: PR:L (uploader on any folder), S:U (stays inside Admidio's authorisation model), C:N because the actor already had read access, I:H because the file's identity is changed for every other reader, A:N because files are not deleted.
Recommended Fix
DocumentsService::renameFile() must check upload right on the file's source folder before mutating it:
// src/Documents/Service/DocumentsService.php
public function renameFile(string $fileUUID, string $newName, string $newDescription): array
{
$file = new File($this->db);
$file->getFileForDownload($fileUUID);
// verify the current user has upload (write) right on the file's parent folder,
// not just download right (which getFileForDownload enforces)
$sourceFolder = new Folder($this->db);
$sourceFolder->readData($file->getValue('fil_fol_id'));
if (!$sourceFolder->hasUploadRight()) {
throw new Exception('SYS_NO_RIGHTS');
}
...
}
Equivalently, in modules/documents-files.php case 'file_rename_save', resolve the file's parent folder and check hasUploadRight() against it before calling the service. The same fix should be applied to other documents-files modes that take a file_uuid independently of folder_uuid.
Related
This bug shares its root cause with 05-documents-cross-folder-move-idor.md — both flow from the top-level rights check at lines 79-89 binding to URL folder_uuid rather than the actual file's parent. A single fix to enforce source-folder upload right inside File::moveToFolder() and DocumentsService::renameFile() (and any other operations on file_uuid) closes both.
Severity
6.5 (Medium)
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 5.0.9"
},
"package": {
"ecosystem": "Packagist",
"name": "admidio/admidio"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.0.10"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-47230"
],
"database_specific": {
"cwe_ids": [
"CWE-639",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-29T22:05:47Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## Summary\n\n`modules/documents-files.php` mode `file_rename_save` shares the same root-cause shape as the cross-folder move bug (`05-documents-cross-folder-move-idor.md`): the top-level rights check at lines 79-89 validates `hasUploadRight()` on the URL parameter `folder_uuid`, but the rename operation acts on `file_uuid` \u2014 a separate URL parameter \u2014 without re-checking the folder that actually contains the file. `DocumentsService::renameFile()` resolves the target file via `getFileForDownload()` (which permits view-readable files) but does not require upload right on the file\u0027s source folder. Result: a user with upload right on any folder A can rename a file in folder B as long as they can view it. They can also overwrite the file\u0027s description.\n\n## Details\n\n### Vulnerable Code\n\n`modules/documents-files.php:79-89` \u2014 top-level check binds to URL `folder_uuid`:\n\n```php\nif ($getMode != \u0027list\u0027 \u0026\u0026 $getMode != \u0027download\u0027) {\n $folder = new Folder($gDb);\n $folder-\u003egetFolderForDownload($getFolderUUID);\n if (!$folder-\u003ehasUploadRight()) {\n $gMessage-\u003eshow($gL10n-\u003eget(\u0027SYS_NO_RIGHTS\u0027));\n }\n}\n```\n\n`src/Documents/Service/DocumentsService.php:272-315` \u2014 `renameFile()` resolves the file via `getFileForDownload()` (view-only) and never re-verifies upload right on the file\u0027s parent:\n\n```php\npublic function renameFile(string $fileUUID, string $newName, string $newDescription): array\n{\n $file = new File($this-\u003edb);\n $file-\u003egetFileForDownload($fileUUID); // \u003c-- view rights, not upload\n ...\n $oldFile = $file-\u003egetFullFilePath();\n $newFile = $newName . \u0027.\u0027 . pathinfo($oldFile, PATHINFO_EXTENSION);\n $newPath = pathinfo($oldFile, PATHINFO_DIRNAME) . \u0027/\u0027;\n FileSystemUtils::moveFile($oldFile, $newPath . $newFile);\n\n $file-\u003esetValue(\u0027fil_name\u0027, $newFile);\n $file-\u003esetValue(\u0027fil_description\u0027, $newDescription);\n $file-\u003esave();\n ...\n}\n```\n\n`getFileForDownload()` enforces only the *download* (read) ACL on the file\u0027s folder. There is no `hasUploadRight()` check anywhere in the rename path. The actual file remains in its original folder; only its name and description change. This means the modified metadata is visible to every other user who legitimately has download rights on that folder, while the modification itself was performed by a user who has no edit right on it.\n\n### Exploitation Primitive\n\n1. Attacker user `lowuser` holds `folder_upload` on `public_uploadable` (UUID `c41a99c0-\u2026`). They have *view* (download) rights on `view_only_public` (UUID `21b417e2-\u2026`, `fol_public=1`) but no upload/edit right there. The folder contains `admin_announcement.txt` (UUID `aaae5edd-\u2026`).\n2. Render the rename form with a `folder_uuid` of a folder lowuser CAN upload to and a `file_uuid` of the target file:\n `GET /modules/documents-files.php?mode=file_rename\u0026folder_uuid=c41a99c0-\u2026\u0026file_uuid=aaae5edd-\u2026`\n The top-level rights check at line 85 sees the public-uploadable folder and passes.\n3. Submit rename:\n `POST /modules/documents-files.php?mode=file_rename_save\u0026folder_uuid=c41a99c0-\u2026\u0026file_uuid=aaae5edd-\u2026` with `adm_csrf_token=\u003cfrom step 2\u003e`, `adm_new_name=hijacked_announcement`, `adm_new_description=Hijacked!`.\n Server replies `{\"status\":\"success\"}`. `adm_files`: `fil_fol_id=7` (still the original `view_only_public`), `fil_name=\u0027hijacked_announcement.txt\u0027`, `fil_description=\u0027Hijacked!\u0027`. On disk: `admin_announcement.txt` is renamed to `hijacked_announcement.txt` in its original folder.\n\n## PoC\n\nCaptured live against HEAD `c5cde53` (mariadb on `127.0.0.1:3399`, php on `127.0.0.1:8085`):\n\n```\n$ curl -sb $cookie \\\n \"http://127.0.0.1:8085/modules/documents-files.php?mode=file_rename\u0026folder_uuid=c41a99c0-\u2026\u0026file_uuid=aaae5edd-\u2026\"\n# form rendered, CSRF token X added to session\n\n$ curl -sb $cookie -X POST \\\n \"http://127.0.0.1:8085/modules/documents-files.php?mode=file_rename_save\u0026folder_uuid=c41a99c0-\u2026\u0026file_uuid=aaae5edd-\u2026\" \\\n -d \"adm_csrf_token=X\u0026adm_new_name=hijacked_announcement\u0026adm_new_description=Hijacked%21\"\n{\"status\":\"success\", \u2026}\n\n$ mariadb -h 127.0.0.1 -P 3399 -u admidio -p\u2026 admidio \\\n -e \"SELECT fil_fol_id, fil_name, fil_description FROM adm_files WHERE fil_uuid=\u0027aaae5edd-\u2026\u0027;\"\nfil_fol_id fil_name fil_description\n7 hijacked_announcement.txt Hijacked!\n```\n\nThe folder ID `fil_fol_id=7` is `view_only_public` \u2014 the folder that `lowuser` had no upload right on. The change was applied as if `lowuser` were authorised.\n\n## Impact\n\nA user with the most basic Documents permission \u2014 upload to a single folder \u2014 can rename and overwrite descriptions of files in any other folder they can read. Confidentiality is unaffected (the actor already had download rights on the affected files), but integrity is broken across folder boundaries. Concretely:\n\n* **Defacement of public announcements / policies / circulars.** A regular member can replace `admin_announcement.txt` with `hijacked_announcement.txt` and a description that misrepresents the content. Other readers see the malicious metadata.\n* **Renaming-to-confuse.** Files can be renamed to identifiers that imply different content (`board_minutes_2025-Q4.pdf` \u2192 `board_minutes_DRAFT-do-not-distribute.pdf`).\n* **Description-as-XSS-vector** (downstream): if any view path treats `fil_description` as raw HTML, this becomes a stored XSS by a low-privilege user; absent that, it is plain content tampering.\n\nThe CVSS reflects: `PR:L` (uploader on any folder), `S:U` (stays inside Admidio\u0027s authorisation model), `C:N` because the actor already had read access, `I:H` because the file\u0027s identity is changed for every other reader, `A:N` because files are not deleted.\n\n## Recommended Fix\n\n`DocumentsService::renameFile()` must check upload right on the file\u0027s source folder before mutating it:\n\n```php\n// src/Documents/Service/DocumentsService.php\npublic function renameFile(string $fileUUID, string $newName, string $newDescription): array\n{\n $file = new File($this-\u003edb);\n $file-\u003egetFileForDownload($fileUUID);\n\n // verify the current user has upload (write) right on the file\u0027s parent folder,\n // not just download right (which getFileForDownload enforces)\n $sourceFolder = new Folder($this-\u003edb);\n $sourceFolder-\u003ereadData($file-\u003egetValue(\u0027fil_fol_id\u0027));\n if (!$sourceFolder-\u003ehasUploadRight()) {\n throw new Exception(\u0027SYS_NO_RIGHTS\u0027);\n }\n ...\n}\n```\n\nEquivalently, in `modules/documents-files.php` `case \u0027file_rename_save\u0027`, resolve the file\u0027s parent folder and check `hasUploadRight()` against it before calling the service. The same fix should be applied to other documents-files modes that take a `file_uuid` independently of `folder_uuid`.\n\n## Related\n\nThis bug shares its root cause with `05-documents-cross-folder-move-idor.md` \u2014 both flow from the top-level rights check at lines 79-89 binding to URL `folder_uuid` rather than the actual file\u0027s parent. A single fix to enforce source-folder upload right inside `File::moveToFolder()` and `DocumentsService::renameFile()` (and any other operations on file_uuid) closes both.",
"id": "GHSA-q6w3-hpfv-rg36",
"modified": "2026-05-29T22:05:47Z",
"published": "2026-05-29T22:05:47Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/Admidio/admidio/security/advisories/GHSA-q6w3-hpfv-rg36"
},
{
"type": "PACKAGE",
"url": "https://github.com/Admidio/admidio"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Admidio: IDOR in documents-files.php allows cross-folder file rename and description changes by unauthorized uploaders"
}
GHSA-Q6X7-F33R-3WXX
Vulnerability from github – Published: 2022-05-13 01:02 – Updated: 2024-02-23 16:16
VLAI
Summary
Incorrect Authorization in Apache Tomcat
Details
The ResourceLinkFactory implementation in Apache Tomcat 9.0.0.M1 to 9.0.0.M9, 8.5.0 to 8.5.4, 8.0.0.RC1 to 8.0.36, 7.0.0 to 7.0.70 and 6.0.0 to 6.0.45 did not limit web application access to global JNDI resources to those resources explicitly linked to the web application. Therefore, it was possible for a web application to access any global JNDI resource whether an explicit ResourceLink had been configured or not.
Severity
7.5 (High)
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 9.0.0.M9"
},
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat:tomcat"
},
"ranges": [
{
"events": [
{
"introduced": "9.0.0.M1"
},
{
"fixed": "9.0.0.M10"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 8.5.4"
},
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat:tomcat"
},
"ranges": [
{
"events": [
{
"introduced": "8.5.0"
},
{
"fixed": "8.5.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 8.0.36"
},
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat:tomcat"
},
"ranges": [
{
"events": [
{
"introduced": "8.0.0"
},
{
"fixed": "8.0.37"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat:tomcat"
},
"ranges": [
{
"events": [
{
"introduced": "7.0.0"
},
{
"fixed": "7.0.72"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2016-6797"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2022-07-06T19:45:35Z",
"nvd_published_at": "2017-08-10T22:29:00Z",
"severity": "HIGH"
},
"details": "The ResourceLinkFactory implementation in Apache Tomcat 9.0.0.M1 to 9.0.0.M9, 8.5.0 to 8.5.4, 8.0.0.RC1 to 8.0.36, 7.0.0 to 7.0.70 and 6.0.0 to 6.0.45 did not limit web application access to global JNDI resources to those resources explicitly linked to the web application. Therefore, it was possible for a web application to access any global JNDI resource whether an explicit ResourceLink had been configured or not.",
"id": "GHSA-q6x7-f33r-3wxx",
"modified": "2024-02-23T16:16:51Z",
"published": "2022-05-13T01:02:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2016-6797"
},
{
"type": "WEB",
"url": "https://github.com/apache/tomcat/commit/2859ac3eae132383cb6f3f2042e25d7a4a281b0d"
},
{
"type": "WEB",
"url": "https://github.com/apache/tomcat/commit/b3406e6c318378cbf440f902f9fdbb8b440aef4e"
},
{
"type": "WEB",
"url": "https://github.com/apache/tomcat/commit/d6b5600afe75e1086dd564344e1d085966e4237d"
},
{
"type": "WEB",
"url": "https://github.com/apache/tomcat80/commit/824c7dc781056442046db0ae34bcf1497f23f44c"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/9325837eb00cba5752c092047433c7f0415134d16e7f391447ff4352%40%3Cannounce.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/9325837eb00cba5752c092047433c7f0415134d16e7f391447ff4352@%3Cannounce.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/b5e3f51d28cd5d9b1809f56594f2cf63dcd6a90429e16ea9f83bbedc%40%3Cdev.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/b5e3f51d28cd5d9b1809f56594f2cf63dcd6a90429e16ea9f83bbedc@%3Cdev.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/b84ad1258a89de5c9c853c7f2d3ad77e5b8b2930be9e132d5cef6b95%40%3Cdev.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/b84ad1258a89de5c9c853c7f2d3ad77e5b8b2930be9e132d5cef6b95@%3Cdev.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/b8a1bf18155b552dcf9a928ba808cbadad84c236d85eab3033662cfb%40%3Cdev.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/b8a1bf18155b552dcf9a928ba808cbadad84c236d85eab3033662cfb@%3Cdev.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r03c597a64de790ba42c167efacfa23300c3d6c9fe589ab87fe02859c%40%3Cdev.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r03c597a64de790ba42c167efacfa23300c3d6c9fe589ab87fe02859c@%3Cdev.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r587e50b86c1a96ee301f751d50294072d142fd6dc08a8987ae9f3a9b%40%3Cdev.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r587e50b86c1a96ee301f751d50294072d142fd6dc08a8987ae9f3a9b@%3Cdev.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r9136ff5b13e4f1941360b5a309efee2c114a14855578c3a2cbe5d19c%40%3Cdev.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r9136ff5b13e4f1941360b5a309efee2c114a14855578c3a2cbe5d19c@%3Cdev.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20180605-0001"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/4557-1"
},
{
"type": "WEB",
"url": "https://web.archive.org/web/20170320064509/http://www.securitytracker.com/id/1037145"
},
{
"type": "WEB",
"url": "https://web.archive.org/web/20170423095945/http://www.securityfocus.com/bid/93940"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpuoct2021.html"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2017:0455"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2017:0456"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2017:2247"
},
{
"type": "PACKAGE",
"url": "https://github.com/apache/tomcat"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/343558d982879bf88ec20dbf707f8c11255f8e219e81d45c4f8d0551%40%3Cdev.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/343558d982879bf88ec20dbf707f8c11255f8e219e81d45c4f8d0551@%3Cdev.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/37220405a377c0182d2afdbc36461c4783b2930fbeae3a17f1333113%40%3Cdev.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/37220405a377c0182d2afdbc36461c4783b2930fbeae3a17f1333113@%3Cdev.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/388a323769f1dff84c9ec905455aa73fbcb20338e3c7eb131457f708%40%3Cdev.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/388a323769f1dff84c9ec905455aa73fbcb20338e3c7eb131457f708@%3Cdev.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/39ae1f0bd5867c15755a6f959b271ade1aea04ccdc3b2e639dcd903b%40%3Cdev.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/39ae1f0bd5867c15755a6f959b271ade1aea04ccdc3b2e639dcd903b@%3Cdev.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/3d19773b4cf0377db62d1e9328bf9160bf1819f04f988315086931d7%40%3Cdev.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/3d19773b4cf0377db62d1e9328bf9160bf1819f04f988315086931d7@%3Cdev.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/6af47120905aa7d8fe12f42e8ff2284fb338ba141d3b77b8c7cb61b3%40%3Cdev.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/6af47120905aa7d8fe12f42e8ff2284fb338ba141d3b77b8c7cb61b3@%3Cdev.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/845312a10aabbe2c499fca94003881d2c79fc993d85f34c1f5c77424%40%3Cdev.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/845312a10aabbe2c499fca94003881d2c79fc993d85f34c1f5c77424@%3Cdev.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/88855876c33f2f9c532ffb75bfee570ccf0b17ffa77493745af9a17a%40%3Cdev.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/88855876c33f2f9c532ffb75bfee570ccf0b17ffa77493745af9a17a@%3Cdev.tomcat.apache.org%3E"
},
{
"type": "WEB",
"url": "http://rhn.redhat.com/errata/RHSA-2017-0457.html"
},
{
"type": "WEB",
"url": "http://www.debian.org/security/2016/dsa-3720"
}
],
"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": "Incorrect Authorization in Apache Tomcat"
}
Mitigation
Architecture and Design
- 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
Architecture and Design
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
Architecture and Design
Strategy: Libraries or Frameworks
- Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
- For example, consider using authorization frameworks such as the JAAS Authorization Framework [REF-233] and the OWASP ESAPI Access Control feature [REF-45].
Mitigation
Architecture and Design
- 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
System Configuration
Installation
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.