Knowledge hub

CSV injection

Spreadsheet formulas hidden in exported data that run when someone opens the file.

What it means

CSV injection, also called formula injection, happens when your app exports data into a CSV or spreadsheet file and some of that data was typed by a user. A cell that starts with =, +, - or @ can be read by a spreadsheet program as a formula, not as plain text.

The person who typed it is rarely the victim. The harm lands on the employee who later opens the export, such as support staff or finance. Your own product is the delivery route for the payload. The risk comes from trusting text that was never meant to be trusted, much like injection in a web page.

Why it matters

A hostile name, comment or address typed into a form can sit harmlessly in your database, then act when someone downloads a report. Depending on the program and its settings, a formula can pull data from other cells, send it to an outside address, or try to run a command after a prompt the employee clicks through.

The result is a risk to your staff and customers that never shows up in the web app itself. Vendors sometimes call it expected behaviour, so it is your job to treat exports as an output where untrusted input must be neutralised.

How it shows up

You meet it in report downloads, admin exports, invoices, contact lists and anywhere a user-controlled field ends up in a column. Any text field that staff later export is in scope: names, notes, company, ticket subjects and product titles. Names, notes and ticket subjects all count.

The usual defence is to neutralise risky cells on export, for instance by putting a single quote or apostrophe in front of any value that begins with a formula character, and to quote fields properly. Test by saving harmless formula text such as =1+1 in each field and opening the export. Better still, tell staff to preview exports before trusting them.

Questions people ask

CSV injection, answered

Is CSV injection a real vulnerability?

It is a recognised weakness, listed by OWASP and MITRE. Some software vendors argue the spreadsheet program is responsible, so it is often not fixed upstream.

If your product produces the file, you can still neutralise it on your side.

Which characters are dangerous?

Cells starting with equals, plus, minus or at are the classic ones. OWASP also lists tab and carriage return as leading characters worth handling.

A safe approach is to treat any leading character of that kind as a reason to prefix the cell.

Does prefixing with an apostrophe fully fix it?

It is the common defence and it stops the formula being read as one. It can change how the value looks or round-trips in other tools.

Check the result in the programs your staff use.

Is this the same as XSS?

No. XSS runs script in a browser. CSV injection runs a formula in a spreadsheet program. They share a cause, which is untrusted input reaching a place that treats it as instructions.

The fix is the same idea: treat output with care.

How do we test for it?

Enter harmless formula text such as =1+1 in every field that appears in an export, run the export, and open it. If the cell shows 2 rather than the text, the field is unprotected.

Never test with real payloads on staff machines.

Sources