Listen to this Post
How the CVE Works – Missing Authorization in Tag Deletion Endpoint
1. The vulnerable endpoint is `DELETE /admin/api/content/tags/{tagId}` within the `TagController::delete()` method.
2. The method calls `$this->userIsAuthenticated()` to verify the user is logged in.
3. It does not call any permission‑checking method, such as $this->userHasPermission(PermissionType::FAQ_EDIT).
4. In contrast, the `update()` and `search()` endpoints of the same controller do require the `FAQ_EDIT` permission.
5. `userIsAuthenticated()` only examines whether `$this->currentUser->isLoggedIn()` is true.
- The application’s kernel lacks admin‑specific middleware; it registers only generic listeners.
- The admin API entry point (
admin/api/index.php) shares the same session handling as the frontend. - Consequently, a session cookie obtained from the frontend works seamlessly for the admin API.
- An attacker who registers as a regular frontend user can reuse their authenticated session.
- By sending a simple `DELETE` request with the session cookie, they can delete any tag by its numeric ID.
- The endpoint does not validate a CSRF token, simplifying exploitation.
- Lack of permission checks allows even a non‑administrator user to delete tags.
- Since the method only checks authentication, any logged‑in user automatically passes.
- The vulnerable code appears in `TagController.php` at lines 121‑133.
- The `userIsAuthenticated()` implementation can be found in `AbstractController` lines 258‑263.
- Attackers can enumerate tag IDs and delete all tags in a single loop.
- The response returns a `200 OK` with a success message, confirming the deletion.
- No additional privileges or special permissions are required.
- The root cause is an inconsistent application of authorization logic across the controller.
- A proper fix must add a permission check, as shown in the comparator `update()` method.
DailyCVE Form
Platform: `phpMyFAQ`
Version: `4.0.16` and below
Vulnerability: `Privilege escalation`
Severity: `Medium`
Date: `2026-05-06`
Prediction: `Patch within 14 days`
What Undercode Say:
Analytics:
- Attack surface: `DELETE /admin/api/content/tags/{tagId}`
– Authorization gap: Missing `userHasPermission` vs. `update()` endpoint - Attack vector: Authenticated frontend user
- Risk: Unauthenticated tag deletion across the entire installation
Bash Commands / Codes:
Enumerate and delete tags 1–100 for i in $(seq 1 100); do curl -X DELETE "https://target.com/admin/api/content/tags/$i" \ -H 'Cookie: PHPSESSID=frontend_session_cookie' done
Exploit:
- Register a new user on the frontend (or use any existing non‑admin account).
- Obtain the session cookie from the authenticated frontend session.
- Send a `DELETE` request to `https://target.com/admin/api/content/tags/1` using that cookie.
4. Observe the `200 OKresponse with{“success”: “Tag deleted”}`. - Repeat the request for other tag IDs to delete all tags.
Protection from this CVE:
– Upgrade to phpMyFAQ version 4.0.17 or later when available.
– Apply the fix by adding `$this->userHasPermission(PermissionType::FAQ_EDIT);` to TagController::delete().
– Prevent frontend sessions from accessing admin API routes (use different session namespaces if feasible).
– Validate CSRF tokens for all state‑changing admin API endpoints.
– Monitor logs for unexpected `DELETE` requests to `/admin/api/content/tags/` from non‑admin IPs.
Impact:
- Data integrity loss – Tags are permanently deleted from the database.
- Disrupted FAQ organization – Tag‑based navigation, filtering, and tag clouds become empty or broken.
- No recovery without a database backup – Deleted tags and associations cannot be restored automatically.
- In large installations with rich tag taxonomies, this can significantly degrade usability and search functionality.
- The damage is limited to tags (FAQ content itself remains intact), but the overall information architecture may be severely harmed.
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
