CVE-2026-47230

The CVE-2026-47230 IDOR in Admidio's documents module exposes a fundamental architectural mismatch between how authorization is checked and how the service layer actually operates. The vulnerable code path — `DocumentsService::renameFile()` accepting a file UUID without validating that the caller has upload rights to that file's parent folder — isn't a simple missing permission check. It's a structural failure where the wrapper layer (`file_rename_save`) gates access using a folder UUID from the URL, but the service method acts on a separate file UUID resolved independently. These are different authorization decisions, and the service doesn't inherit context from the caller. The critical question for defenders: does version 5.0.10 close this hole at the right abstraction level? If the patch only adds a folder-permission check inside the specific `file_rename_save` handler, you're looking at a surgical fix that leaves every other `DocumentsService` method vulnerable — `copyFile()`, `deleteFile()`, `moveFile()`, and any future methods that accept file UUIDs as input. The service layer accepts entity IDs without requiring the caller to prove relationship-to-context, making every method a potential vector as long as that design persists. Audit your `DocumentsService` method signatures: any method that takes a file UUID and resolves the file independently is a dormant IDOR vector until proven otherwise. The two reported CVEs share the same root-cause shape — same service class, same authorization model failure — which suggests the first patch addressed a code path rather than the abstraction layer producing the bug. Consider whether your remediation should include a service-layer authorization decorator that enforces folder-level rights on every entity ID the service touches, rather than patching individual call paths. That's the only fix that doesn't guarantee a third CVE.

Reviewed through automated stages and approved by a human before publication.