CSV injection, also called formula injection, happens when text a user supplied is written into an exported CSV file and a spreadsheet application then treats it as a formula rather than as data. The file itself is structurally valid. The harm occurs on the machine of whoever opens it.
How an export becomes an attack
Most applications that hold data eventually grow a download button. Export the customer list, export this month's submissions, export the support tickets. The application takes fields that users typed, writes them into a CSV and hands the file over.
The gap opens because CSV is not really a data format in the strict sense. It is text with commas in it, and the meaning is decided entirely by whatever opens it. Spreadsheet applications decide that a cell beginning with certain characters is a formula to evaluate rather than a string to display, so a value that was inert in your database becomes an instruction the moment it lands in a spreadsheet.
OWASP lists the characters that begin a formula as equals, plus, minus and at, along with tab, carriage return and line feed. The full-width Unicode versions of those symbols count as well, since spreadsheet software normalises them, which quietly defeats a filter that only checks the ASCII forms.
Nothing in this requires the attacker to breach anything. They fill in a form field on your site with a value that starts with one of those characters, wait for somebody on your side to export the data, and the formula runs on that person's machine.
What it can lead to
OWASP sets out three routes, and they escalate in how quietly they work.
Exploiting the spreadsheet software. Formula evaluators are large, old and complicated pieces of software with a long history of parsing vulnerabilities. A formula is a way to reach that surface with attacker-chosen input.
Exploiting the warning dialogue. Spreadsheet applications do warn before running anything that reaches outside the file. They also warn frequently, in the middle of ordinary work, to people who have learned that clicking through is usually fine. The warning is a real control and it is a weak one.
Exfiltrating the contents. This is the one that tends to surprise people. A formula can read cells from the sheet it is in, or from other sheets the user has open, assemble them into a string and append that string to an outbound request. Nothing visibly happens. The file opens, the numbers look right, and data has left the building.
The person harmed is usually a colleague rather than the attacker's original target, which is why this is usually found late. Your application is working perfectly. The damage is happening somewhere you are not looking.
How to stop it
The fix belongs in the code that writes the file, and it is small. OWASP's mitigations are to wrap cell values in double quotes, to escape any double quotes inside them by doubling, and to prefix a value with a single quote where its first character could begin a formula. Some guidance recommends a leading tab inside a quoted field for Excel specifically.
Three practical points make the difference between a fix that holds and one that does not:
- Check the full character set, not just the equals sign. Plus, minus and at all begin formulas, and the full-width variants normalise to the same thing
- Sanitise at the point of export, every time. Escaping is documented as not always surviving a save and reopen in Excel, so treat each export as the place the defence is applied rather than assuming a file stays safe once handled
- Cover every export path. Applications accumulate these: a report download, an admin export, a scheduled email attachment, an API endpoint that returns CSV. They usually do not share the writing code
Storing the raw value and escaping only on the way out is the right order. The value is not dangerous in your database, and stripping characters on input tends to corrupt legitimate data. Plenty of real names, part numbers and accounting figures begin with a minus or a plus.
Why scanning and sanitisation do not help here
This is worth stating plainly, because CSV injection often gets filed alongside malicious file uploads and treated as though the same controls apply. They do not.
A malware scanner has nothing to match on. There is no malicious code in the file, no embedded executable and no exploit. It is text. Nor does type validation help: CSV is a text format with no binary signature, so checking magic bytes has nothing to check.
Content disarm and reconstruction does not help either, and for an instructive reason. Sanitisation works by rebuilding a document from the components that are safe and discarding the ones that carry risk, which is effective when the danger is structural: a macro, an embedded object, an unexpected script. A CSV containing a formula has no unsafe structure to remove. Every character in it is legitimate CSV. Rebuild it faithfully and you get the same formula back.
OWASP tests for it under the name spreadsheet injection, and it is an output encoding problem in the same family as cross-site scripting, and it is fixed the same way: by encoding data correctly for the context it is about to enter. The context here happens to be a spreadsheet rather than a browser.
This one is yours to fix. The files arriving the other way are a different problem. Escaping your exports handles data leaving your application. For documents coming in, where the risk genuinely is structural, the Red Eagle Tech CDR API rebuilds each file from its safe components and returns something your users can still open. Published per-document pricing, and you can be running in minutes.
