www.verl.de

Bugsink: https://bugsink.cytrus.de/issues/issue/220edff8-5038-490c-9f01-281a76e01958/event/last/

Typ: NEW issue

Projekt: www-verl-de

Bugsink Alert

ErrorException: Warning: filesize(): stat failed for /srv/www/www.verl.de/pages/public/uploads/tx_powermail/1qarbpm3a__or_614__select_614_from_pg_sle…

Automatisch erstellt durch n8n

KI-Analyse:

1. Ursache identifizieren (Root Cause Analysis)¶

Primäre Ursache: SQL Injection Attempt / Malicious Payload im Dateinamen.
Der Dateiname 1qarbpm3a__or_614__select_614_from_pg_sleep_15__-- ist ein klassischer SQLi-Test-Payload (PostgreSQL basiert: pg_sleep(15), Comment --).

• or 614=614 -> Always True Condition.
• select 614 from pg_sleep(15) -> Time-based Blind SQLi (Verzögerung 15 Sek.).
• -- -> SQL Comment zum Auskommentieren des Rest der Query.

Technischer Fehler (PHP Warning):
filesize(): stat failed tritt auf, weil TYPO3 (bzw. die Extension powermail) versucht, die Dateigröße via filesize() zu ermitteln, die Datei physisch aber nicht auf dem Dateisystem existiert.
Der Angreifer hat vermutlich einen Datensatz in tx_powermail_domain_model_file (oder sys_file_reference) erstellt, der auf diesen Dateinamen verweist, ohne dass die Datei tatsächlich hochgeladen wurde (z.B. via Manipulation der Formulardaten / Hidden Fields / API).

Warum crashed es hier (Middleware Stack)?
Der Stacktrace zeigt nur den Request Entry Point (AbstractApplication::run -> Middlewares). Der eigentliche Fehler passiert später im Controller/Service Layer (z.B. beim Rendern der Mail, im Backend Modul oder im Frontend Plugin), wird aber als ErrorException (durch TYPO3 Error Handler gewandeltes Warning) global geworfen und landet im Log. Der Stacktrace ist abgeschnitten ("WICHTIGE FRAMES" zeigen nur den Bootstrap).

Betroffene Extension: powermail (Pfad: /uploads/tx_powermail/...).

2. Fix beschreiben (Konkret & Priorisiert)¶

A. Sofortmaßnahme: Bereinigung & Monitoring (Produktion)¶

1. DB bereinigen: Suche in tx_powermail_domain_model_file (und sys_file / sys_file_reference) nach Datensätzen mit diesem Dateinamen (%pg_sleep%, %select%from%, %--%) und lösche sie.
2. Dateisystem prüfen: Stelle sicher, dass im Ordner public/uploads/tx_powermail/ keine suspekten Dateien liegen.
3. WAF/Shield: Blockiere Requests, die SQLi-Patterns in Parameter-Namen oder Werten enthalten (ModSecurity / NaXSI / Cloudflare WAF Rules).

B. Code-Fix: Robustheit in powermail / Custom Code (Mittel)¶

Das Problem: Code ruft filesize($path) auf, ohne zu prüfen, ob die Datei existiert (is_file() / file_exists()). PHP wirft E_WARNING -> TYPO3 wandelt in ErrorException -> 500er / Log Flood.

Fix in der Extension (oder eigener Signal/Slot / XClass):
Suche im Code von powermail (oder deinem Custom Code, der Files verarbeitet) nach filesize(.

Beispiel Fix (Defensive Programming):

// SCHLECHT (Verursacht Warning/Exception)
$size = filesize($filePath);

// GUT (Robust)
$size = 0;
if (is_file($filePath) && is_readable($filePath)) {
    $size = filesize($filePath);
} else {
    // Logging: "Missing file referenced in DB: " . $filePath
    // Optional: DB Record bereinigen (Soft Delete / Orphan Removal)
}

Wo genau patchen? (powermail typische Stellen):

• Classes/Utility/FileUtility.php (falls existent)
• Classes/Controller/ExportController.php (CSV Export prüft oft Dateigrößen)
• Classes/Service/MailService.php (beim Anhängen von Dateien an Mails)
• Classes/Domain/Repository/FileRepository.php (beim Lesen der Records)
• Wahrscheinlichster Ort: Frontend Rendering der Mails (Backend Modul "Powermail" -> "Mails anzeigen" oder Frontend "Meine Anträge").

C. Architektur-Fix: FAL (File Abstraction Layer) nutzen¶

Stelle sicher, dass powermail (Version >= 7.x nutzt FAL) nicht mehr native Pfade (uploads/tx_powermail/...) manuell verarbeitet, sondern \TYPO3\CMS\Core\Resource\FileInterface / FileReference Objekte nutzt.

• $file->getSize() wirft keine Warning, sondern liefert 0 oder wirft saubere \TYPO3\CMS\Core\Resource\Exception\FileDoesNotExistException.

3. Betroffene TYPO3 Extension¶

powermail (Ingo Schmitt / Powermail Team)

• Pfadbeweis: /uploads/tx_powermail/
• Tabelle: tx_powermail_domain_model_file / tx_powermail_domain_model_mail / tx_powermail_domain_model_field

4. Confidence (0-100%)¶

95%

Begründung:

• 100% dass der Dateiname ein SQLi-Payload ist (PostgreSQL Time-based).
• 100% dass filesize() auf fehlender Datei scheitert (stat failed).
• 100% dass der Upload-Pfad tx_powermail zur Extension powermail gehört.
• -5% Restunsicherheit: Der exakte PHP-Code-Zeile im Stacktrace fehlt (der Trace bricht im Middleware-Dispatcher ab). Es könnte theoretisch ein eigener Signal/Slot/EventListener im Projektcode sein, der auf Powermail-Events reagiert und filesize() aufruft. Die Verantwortung für den fehlenden is_file()-Check liegt aber meist im Core der Extension powermail (ältere Versionen oder Legacy Code Pfade im Export/Backend).

Zusammenfassung für das Ticket (Copy-Paste)¶

Title: powermail: PHP Warning filesize(): stat failed durch SQLi-Payload im Dateinamen führt zu ErrorException

Severity: High (Security/DoS potential via Log Flood / Error Handling Overhead)

Root Cause: Angreifer injizierte SQLi-Payload (pg_sleep) als Dateinamen in Powermail-DB-Records. Datei existiert nicht auf FS. Code ruft filesize($path) ohne is_file() Check auf.

Fix:

1. DB Records bereinigen (tx_powermail_domain_model_file WHERE name LIKE %pg_sleep%).
2. Patchen der aufrufenden Stelle (ExportController / MailService / FileUtility): if (is_file($path)) { filesize($path) }.
3. Update powermail auf neueste Version (FAL Migration prüfen).
4. WAF Rule für SQLi in Upload-Parametern deployen.