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.