Description

Admidio is an open-source user management solution. Prior to version 5.0.10, `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. Version 5.0.10 contains a fix.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.5",
  "pubDate": "2026-08-12T14:17:54.057Z",
  "pubdate": "2026-08-12T14:17:54.057Z",
  "executiveSummary": "An Insecure Direct Object Reference (IDOR) vulnerability exists in Admidio prior to version 5.0.10 within the file management module. The flaw resides in the modules/documents-files.php script under the file_rename_save mode. This security deficiency allows an authenticated user who possesses upload rights on a single accessible folder to arbitrarily rename files and overwrite file descriptions located within entirely separate, unauthorized folders, provided they possess read access to the target files. The risk implication includes unauthorized modification and potential metadata corruption of restricted organizational documents across distinct directories. Exploitation requires authenticated access, valid view permissions for the targeted file, and legitimate upload privileges on any arbitrary folder within the system to satisfy the initial top-level rights check.",
  "technicalDetails": "The vulnerability stems from a broken access control pattern and improper parameter validation within the document management service architecture. Specifically, in modules/documents-files.php during the file_rename_save mode execution, the application performs a top-level authorization check between lines 79 and 89. This check exclusively validates the hasUploadRight() permission against a URL-supplied folder_uuid parameter, asserting that the user can upload to that specific folder context.\nHowever, the subsequent rename operation acts directly upon a separate URL parameter, file_uuid, which designates the specific file targeted for modification without verifying whether the source folder containing that file matches the authorized folder context. The underlying method DocumentsService::renameFile() resolves the target file utilizing getFileForDownload(), an access function that only mandates view-readable permissions rather than enforcing strict administrative or upload rights on the file's actual parent folder.\nThe step-by-step attack flow proceeds as follows: First, an authenticated attacker identifies a file located in a restricted folder B that they have permissions to view, obtaining its corresponding file_uuid. Second, the attacker locates or utilizes any arbitrary folder A where they hold legitimate upload rights, obtaining its folder_uuid. Third, the attacker crafts an HTTP request to modules/documents-files.php with mode set to file_rename_save, supplying the folder_uuid of folder A to successfully bypass the initial permission gate at lines 79-89. Finally, the attacker supplies the file_uuid of the target file in folder B alongside the new filename or description parameters. The application processes the request, resulting in unauthorized file renaming and description overwriting within folder B."
}