Projekt

Allgemein

Profil

Aktionen

Bug #221

offen

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

Von Bug Sink vor etwa 1 Monat hinzugefügt.

Status:
Neu
Priorität:
wichtig
Zugewiesen an:
-
Beginn:
12.09.2026
Abgabedatum:
% erledigt:

0%

Geschätzter Aufwand:

Beschreibung

Bugsink: https://bugsink.cytrus.de/issues/issue/b88d97ad-1326-4cc0-b36f-2ad73657325e/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/1nsourdou____or_483__select_483_from_pg_s…


Automatisch erstellt durch n8n

KI-Analyse:

1. Ursache identifizieren

Der Fehler entsteht durch diesen PHP-Call:

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

Das bedeutet: PHP versucht die Größe einer Datei zu ermitteln, die Datei existiert aber nicht oder ist nicht lesbar.

Der relevante Pfad ist:

/srv/www/www.verl.de/pages/public/uploads/tx_powermail/

Das ist der Upload-Ordner der TYPO3-Extension powermail.

Der Dateiname:

1nsourdou____or_483__select_483_from_pg_sleep_15__--

sieht nicht nach einem legitimen Upload aus, sondern nach einem typischen SQL-Injection-/Scanner-Payload:

... OR 483 SELECT 483 FROM pg_sleep(15) --

Wahrscheinlich wurde eine direkte Anfrage auf eine nicht existierende Datei im Powermail-Upload-Ordner gestellt, z. B.:

/uploads/tx_powermail/1nsourdou____or_483__select_483_from_pg_sleep_15__--

TYPO3/PHP versucht daraufhin, die Datei für einen Download oder eine Ausgabe vorzubereiten und ruft filesize() auf. Da die Datei nicht existiert, entsteht die Warning. In TYPO3 wird diese Warning als ErrorException behandelt und im Log sichtbar.

Root Cause:
Eine fehlerhafte bzw. manipulative HTTP-Anfrage versucht auf eine nicht vorhandene Datei im Powermail-Upload-Verzeichnis zuzugreifen. Dadurch schlägt filesize() fehl.


2. Fix beschreiben – konkret

Kurzfristig

Es muss keine Code-Änderung an TYPO3 Core oder Powermail vorgenommen werden, wenn es sich nur um einzelne Scans/Attack-Versuche handelt.

Empfohlene Maßnahmen:

  1. Request loggen und beobachten

    • Prüfen, ob viele ähnliche Requests auf /uploads/tx_powermail/... kommen.
    • User-Agent, IP und Request-URI auswerten.
  2. Fehlende Upload-Dateien nicht als TYPO3-Frontend-Request durchlaufen lassen

    • Webserver so konfigurieren, dass nicht-existierende Dateien unter /uploads/ direkt mit 404 beantwortet werden.
    • Kein Fallback auf /public/index.php.

    Beispiel nginx:

    location ^~ /uploads/ {
        try_files $uri =404;
    }
    

    Beispiel Apache:

    RewriteCond %{REQUEST_URI} ^/uploads/
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteRule ^ - [R=404,L]
    
  3. WAF/ModSecurity/CDN-Regeln prüfen

    • Requests mit Mustern wie pg_sleep, select, union, --, ' OR blockieren oder zumindest challengen.
    • Gerade dieser Dateiname enthält eindeutige SQLi-Indikatoren.
  4. TYPO3 Error Handling prüfen
    Falls die Warning nicht als Exception behandelt werden soll, kann in Production das Error Handling angepasst werden, z. B. in config/system/settings.php bzw. LocalConfiguration:

    'SYS' => [
        'displayErrors' => 0,
        'productionExceptionHandler' => \TYPO3\CMS\Core\Error\Http\HttpExceptionHandler::class,
    ],
    

    Das behebt aber nicht die Ursache, sondern reduziert nur die Sichtbarkeit.


Nachhaltiger Fix

Der eigentliche Fix liegt auf Webserver-/Routing-Ebene:

Nicht-existierende Dateien unter /public/uploads/ dürfen nicht an TYPO3 geroutet werden.

Aktuell scheint der Request:

/uploads/tx_powermail/1nsourdou____or_483__select_483_from_pg_sleep_15__--

nicht direkt vom Webserver mit 404 beantwortet zu werden, sondern läuft durch public/index.php. Dadurch wird TYPO3 Bootstrap gestartet und im weiteren Verlauf filesize() auf den nicht existierenden Pfad ausgeführt.


3. Betroffene TYPO3 Extension

Betroffen ist sehr wahrscheinlich:

powermail

bzw. Vendor-Paket typischerweise:

in2code/powermail

Begründung:

  • Der Pfad enthält uploads/tx_powermail/
  • tx_powermail ist der typische Upload-/Speicherbereich von Powermail
  • Der Dateiname wirkt wie ein manipulativer Request auf Powermail-Uploads

Der TYPO3 Core erscheint nur im Stacktrace, weil der Request durch den normalen TYPO3 HTTP-Bootstrap läuft. Die fachliche Ursache liegt aber im Powermail-Upload-Kontext bzw. im direkten Zugriff auf dessen Upload-Ordner.


4. Confidence

Confidence: 90%

Sehr hohe Wahrscheinlichkeit, dass es sich um einen fehlgeschlagenen Zugriff auf eine nicht existierende Powermail-Upload-Datei handelt, ausgelöst durch einen Scanner-/SQLi-Versuch.

Restunsicherheit:
Ohne den vollständigen Stacktrace unterhalb der TYPO3-Core-Frames ist nicht zu 100% sichtbar, welche konkrete Methode filesize() aufruft. Der Pfad uploads/tx_powermail/ macht Powermail aber zur klar wahrscheinlichsten betroffenen Extension.

Nichts anzuzeigen

Aktionen

Auch abrufbar als: Atom PDF