We process a large number of submissions every day, some of which have a high impact on the WordPress ecosystem, and others less so. In order to ensure that our work effectively helps make the web a safer place, we have to prioritize the submissions we receive. As part of that, we’d like to clarify how we’ll handle CSV Injection submissions going forward.
Who Should Mitigate CSV Injection Vulnerabilities?
Many bug bounty programs specifically reject CSV Formula Injection vulnerabilities for various reasons, Google being one of the most popular companies to have done so. They even wrote a blog post describing the rationale behind that decision, which states the following:
it is important to remember that CSV files are simply text files (the format is defined in RFC 4180) and that only a subset of the applications which open CSV files actually evaluate formulas – it’s more of a side effect of the CSV format and not a vulnerability in Google products which can export user-created CSVs. In consequence, this issue should be mitigated by applications which import/interpret data from external sources such as CSV files, as e.g. Microsoft Excel does by displaying a warning. In other words, the proper fix should be applied when opening CSV files, not when creating them.
In that same line of thought, other spreadsheet software vendors have already implemented countermeasures to deter formula injection attacks when opening/importing CSV files.
One example of that is the latest version of LibreOffice, which will not evaluate formulas when importing CSV files by default, leaving it to the user to enable the option to do so.
What Will WPScan Do About Them?
We intend to follow a similar line of thought from now on. We will no longer accept CSV Injection submissions where the only security risk is other applications interpreting formulas injected by ill-intentioned visitors.
This however does not mean we’ll reject 100% of reports that involve injecting something in a CSV file. We may, in some specific circumstances, elect to accept CSV Injection submissions that actively affect the very functioning of the plugin at stake, and lead to tangible security risks.
Some examples of submissions we may still accept include the following:
- CSV Injection in a user migration plugin where one could inject extra new lines, and create new administrator users on the site where the CSV is imported.
- Cases where adding new columns (by injecting commas) may allow attackers to change sensitive fields.
Obviously, this is not an exhaustive list, and it will most likely be updated in the future as we receive more submissions.
“Are You Saying CSV Injection Isn’t A Security Issue?”
To be clear, this is not about whether CSV Injection attacks constitute a security risk or not. They clearly do.
This is about defining what the problem is, and figuring out who should be responsible for fixing what. We’re of the opinion that formula injection is only a problem because spreadsheet software vendors made it so by interpreting text data as formulas. Logically, they should be the ones to fix that behavior.
However, preventing the injection of new columns or rows definitely lands in the hands of plugin owners. This is especially the case if the resulting malformed CSV file may lead to security issues.
Having a clear distinction between those two is fundamental for us. It lets us communicate our expectations better when sharing your findings with plugin authors.
Can I Still Request CVEs For Rejected CSV Injection Issues?
While we may decide not to process your submission based on that reasoning, if you choose to report your finding to the plugin author directly, and they fix the problem, we will be more than glad to add it to the database and issue a CVE for it.
Simply let us know how or where it’s been fixed when submitting it to us.
