www.verl.de

Bugsink: https://bugsink.cytrus.de/issues/issue/3d346365-3a6c-4425-9f12-4f66ad9f9fce/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/1-1__or_10__select_10_from_pg_sleep_15__--

---

Automatisch erstellt durch n8n

KI-Analyse:

1. Ursache identifizieren¶

Der Fehler entsteht hier:

filesize(): stat failed for /srv/www/www.verl.de/pages/public/uploads/tx_powermail/1-1__or_10__select_10_from_pg_sleep_15__--

Das bedeutet: PHP versucht, die Dateigröße einer Datei zu ermitteln, die nicht existiert oder nicht zugreifbar ist.

Der Pfad liegt in:

public/uploads/tx_powermail/

Das ist der typische Upload-Ordner der TYPO3-Extension Powermail.

Der Dateiname ist auffällig:

1-1__or_10__select_10_from_pg_sleep_15__--

Das ist keine normale Datei, sondern eine SQL-Injection-/Scanner-Payload, vermutlich von einem Bot oder Security-Scan. Powermail oder benutzerdefinierter Code versucht offenbar, diesen Wert wie eine hochgeladene Datei zu behandeln und ruft dafür filesize() auf.

Die TYPO3-Core-Frames sind hier nur der HTTP-Request-Stack. Die eigentliche Ursache liegt sehr wahrscheinlich nicht im Core, sondern in der Verarbeitung eines Powermail-Uploadfeldes.

---

2. Fix konkret¶

Kurzfristiger Fix¶

Stelle sicher, dass vor filesize() geprüft wird, ob die Datei wirklich existiert.

Beispiel:

$path = '/srv/www/www.verl.de/pages/public/uploads/tx_powermail/' . $fileName;

if (is_file($path)) {
    $size = filesize($path);
} else {
    $size = 0;

    // optional loggen
    error_log('Powermail upload file missing: ' . $path);
}

Noch besser mit TYPO3-API:

use TYPO3\CMS\Core\Utility\GeneralUtility;

$path = GeneralUtility::getFileAbsFileName('uploads/tx_powermail/' . $fileName);

if (is_file($path)) {
    $size = filesize($path);
} else {
    // keine echte Upload-Datei: ignorieren oder als fehlerhaften Datensatz behandeln
    $size = 0;
}

Wichtig: Keine Request-Werte direkt als Dateipfad verwenden.

---

TYPO3 / Powermail-seitig prüfen¶

In EXT:powermail bzw. im betroffenen Powermail-Formular:

1. Powermail auf die neueste kompatible Version aktualisieren.

2. Upload-Felder im Formular prüfen:

   • Nur echte Upload-Felder verwenden.
   • Keine freien Textfelder als Upload interpretieren.
   • allowedExtensions restriktiv setzen, z. B.:

   jpg,jpeg,png,pdf,doc,docx,xls,xlsx,zip
   

3. Maximale Dateigröße begrenzen.

4. Powermail-Datensätze bereinigen, die auf diese Payload verweisen.

Datenbank prüfen, z. B.:

SELECT uid, pid, field, value
FROM tx_powermail_domain_model_answer
WHERE value LIKE '%pg_sleep%';

Auch suchen nach:

SELECT uid, pid, field, value
FROM tx_powermail_domain_model_answer
WHERE value LIKE '%select%from%';

Vor Löschungen Backup machen. Danach fehlerhafte Powermail-Einträge über Backend oder kontrolliert per SQL bereinigen.

---

Security-Maßnahme¶

Die Anfrage sollte zusätzlich auf Webserver-/WAF-Ebene blockiert werden, weil sie eindeutig nach SQL-Injection-Scanning aussieht.

Blockieren bzw. alarmieren bei Payloads wie:

pg_sleep
select ... from
or 1=1
or 10
--

Zugriffslogs zum Fehlerzeitpunkt prüfen:

grep -R "pg_sleep" /srv/www/www.verl.de/pages/var/log/
grep -R "select" /srv/www/www.verl.de/pages/var/log/

sowie Webserver-Accesslogs nach dem entsprechenden Timestamp durchsuchen.

---

3. Betroffene TYPO3 Extension¶

Sehr wahrscheinlich:

EXT:powermail

Package typischerweise:

typo3-ter/powermail

bzw. FriendsOfTYPO3 Powermail.

Nicht betroffen im engeren Sinne: typo3/cms-core. Der Core erscheint nur im Stack, weil der Fehler während der HTTP-Verarbeitung geworfen wurde.

---

4. Confidence¶

95 %

Begründung: Der Pfad uploads/tx_powermail/ und der manipulierte Dateiname deuten sehr stark auf eine fehlerhafte Verarbeitung eines Powermail-Uploadfeldes hin. Die genaue aufrufende Codezeile ist im gelieferten Stack nicht sichtbar, daher nicht 100 %.