$4,800 for an Equals Sign: CSV Formula Injection That Turns an Export Feature Into a Payload…

This is the bug I've had the hardest time convincing people outside security actually matters. "You typed a formula into a text field, and a spreadsheet program did spreadsheet things with it" sounds, on first hearing, like a non-issue — almost a feature working as intended. It took building the full chain, from a single character typed into an ordinary form field through to arbitrary command execution on an internal employee's laptop, to understand why this is a real, repeatedly-exploited vulnerability class rather than a curiosity.

The target, which I'll call Fieldmark Analytics here per their program's anonymization terms, is a survey and feedback-collection platform. Respondents fill out forms; the companies running those surveys download the collected responses as CSV exports to analyze in Excel or Google Sheets.

Why a Text Field and a Spreadsheet Don't Agree on What Text Means

A CSV file is, structurally, just plain text — values separated by commas, nothing more sophisticated than that by specification. The danger exists entirely because spreadsheet applications layer additional meaning on top of that plain format for convenience: if a cell's content begins with specific characters — an equals sign, a plus sign, a minus sign, or an at-sign — Excel, Google Sheets, and most other spreadsheet software interpret that cell not as literal text, but as the start of a formula to be evaluated.

An application generating a CSV export has no way of knowing this in advance, because CSV itself carries no such concept — the formula-triggering behavior lives entirely in the spreadsheet application that later opens the file, not in the format or the exporting application. If a platform takes free-text user input and writes it directly into a CSV cell without checking whether that input happens to start with one of those four characters, it's effectively handing attacker-controlled formula syntax straight to whoever opens the resulting file, with the exporting application never doing anything wrong by any definition CSV itself provides.

The Field That Mattered

Fieldmark's survey forms included open-ended, free-text response fields — exactly the kind of input most applications correctly treat as inert, since there's no SQL query or HTML rendering context for a plain-text survey answer to inject into. I submitted a response deliberately starting with an equals sign:

=1+1

=1+1

Then, as any legitimate survey administrator would, I exported the responses as a CSV and opened the file in a spreadsheet application. The cell containing my response didn't show the literal text =1+1 — it showed 2, evaluated as a formula exactly as Excel's default behavior dictates for any cell beginning with that character. Confirmed: Fieldmark's export wrote my input directly into the CSV without any sanitization for formula-triggering characters, and whoever opened that export in a spreadsheet application would have it evaluated as a live formula rather than displayed as the plain text it actually was.

From a Calculator Trick to Something Genuinely Dangerous

Evaluating 1+1 is harmless, obviously, and not remotely what makes this bug worth a serious report. Spreadsheet formula languages are considerably more powerful than basic arithmetic, and several well-documented formula functions can be abused specifically to reach outside the spreadsheet itself — the most consequential being functions that can invoke external commands or fetch external resources when a workbook is configured (or an older, more permissive default is in effect) to allow it.

I crafted a survey response using a formula pattern documented across numerous public write-ups of this exact vulnerability class, designed to launch a command through a spreadsheet application's dynamic data exchange functionality:

=cmd|'/c calc.exe'!A1

=cmd|'/c calc.exe'!A1

This specific payload, submitted as a survey response and later opened in a vulnerable or permissively-configured spreadsheet application, triggers a prompt (in modern, patched versions) or, depending on the application's security settings and version, silently executes the embedded command — in this proof-of-concept case, launching the Windows calculator, chosen specifically because it's inert, instantly visually obvious, and does nothing beyond confirm execution occurred.

Building a Safe, Self-Contained Demonstration

Testing this chain responsibly meant being deliberate about where the "victim" step actually happened. I submitted the crafted survey response through my own test account, acting as a respondent, and then separately, acting as the survey administrator — also my own test account, since Fieldmark allowed self-service account creation for both roles — exported the response and opened the resulting CSV file myself, in a spreadsheet application on a virtual machine specifically set up for this test and isolated from anything sensitive. I captured a screenshot of the calculator launching as direct evidence of successful execution, then closed and discarded that virtual machine entirely.

I did not submit this payload to any real, active survey belonging to an actual Fieldmark customer, and did not attempt to reach any real survey administrator at all — the entire chain, from crafted submission through confirmed execution, happened within infrastructure and accounts I fully controlled.

Why This Deserves a Real Severity Rating, Not a Shrug

It's worth directly addressing the skepticism this bug class often receives, because "the user has to open the file in a vulnerable configuration" sounds like it requires an unreasonable number of coincidences to actually matter. In practice, the realistic attack scenario here isn't abstract: any platform that lets arbitrary, often unauthenticated users submit free-text input that later gets exported as CSV for a legitimate business user to open is handing anonymous internet users a direct, repeatable channel to deliver formula payloads onto an internal employee's machine, with the only real barrier being whichever security settings that employee's spreadsheet application happens to have configured. Given how many organizations still run older application versions or have legacy macro and external-data settings enabled for business reasons, that barrier is considerably less reliable than it should be, and the submission side of this attack requires no authentication, no social engineering beyond a normal-looking survey response, and no interaction with the platform's own security controls at all.

The Report

Title: CSV formula injection in survey response export allows arbitrary command execution on administrator machines opening exported files

Root cause: Free-text survey response fields are written directly into CSV export files without sanitizing or escaping leading characters (=, +, -, @) that spreadsheet applications interpret as formula triggers, allowing a malicious respondent to embed formula payloads, including ones capable of external command execution, that execute when a survey administrator opens the exported file in a vulnerable or permissively-configured spreadsheet application.

Reproduction: The basic formula-evaluation confirmation, followed by the command-execution payload and a screenshot demonstrating successful execution, performed entirely within a self-controlled survey submission, a self-controlled administrator export, and an isolated test virtual machine.

Impact: Any respondent — including fully unauthenticated, anonymous users on publicly-accessible surveys — can embed a payload capable of command execution on any administrator's machine that later opens the exported CSV file in a vulnerable spreadsheet configuration, without any interaction with Fieldmark's own authentication or authorization controls.

Fix recommendations:

• Sanitize every exported cell value by prefixing any content beginning with =, +, -, or @ with a single quote or equivalent neutralizing character, which causes spreadsheet applications to treat the content as literal text rather than a formula, while preserving the original data's readability
• Apply this sanitization at the point of export generation specifically, rather than at submission time, since any future export feature or format needs the same protection and submission-time filtering alone wouldn't cover it
• Consider adding an explicit warning in the export UI itself, noting that response data originates from untrusted external submitters and should be reviewed with spreadsheet macro and external-data security settings enabled

What Happened After

Fieldmark added export-time sanitization within a week, prefixing any formula-triggering leading character across every export format the platform offered, not just CSV. Their resolution notes mentioned this had apparently never been considered during the export feature's original design, since the development team's mental model had treated survey responses purely as data to be stored and displayed, never considering what a different application opening that same data might do with it. The report closed at $4,800, rated medium severity — lower than many of the other findings in this series, reflecting that successful exploitation depends on a downstream user's own application configuration rather than anything fully within Fieldmark's control, but still a clear, real, and relatively cheap-to-fix vulnerability worth taking seriously.

Why CSV Injection Deserves a Spot in Your Testing Routine

Any platform letting users submit free-text content that later gets exported to CSV, Excel, or any other spreadsheet-compatible format is worth testing with a leading formula character, regardless of how unrelated to "security" the feature seems — a survey tool, a contact form, a support ticket system, anything collecting user-submitted text destined for a business user's spreadsheet. A few habits worth carrying forward:

Test all four formula-triggering characters, not just the equals sign. +, -, and @ can each trigger formula evaluation in different spreadsheet applications and configurations, and a sanitization fix that only handles = leaves the other three open.

Build your command-execution proof of concept against something instantly, visually obvious and completely inert, like launching a calculator application — this proves the chain works without requiring anything resembling real payload delivery or persistence.

Keep the entire chain self-contained, submitting through your own account and opening the export yourself in an isolated environment, specifically so the demonstration never risks affecting a real respondent or real administrator.

Don't let dismissive first reactions talk you out of reporting this class. It's genuinely underestimated by people unfamiliar with it, but the realistic attack surface — anonymous, unauthenticated submission reaching a trusted internal user's machine — is a legitimate and recurring security concern.

What stayed with me about this one is how completely correct every individual piece of Fieldmark's code was, by its own local logic. The survey form correctly accepted free text. The export feature correctly wrote that text into a CSV file. Nothing malformed, nothing injected into any query or rendered unsafely into any page. The entire vulnerability lived in the fact that CSV, as a format, means something different depending on which application eventually opens it — and nobody at Fieldmark had ever had reason to think about that gap until a respondent's answer started with a single, unremarkable-looking character.