exploit the possibilities
Home Files News &[SERVICES_TAB]About Contact Add New

BugCrowd CSV Injection

BugCrowd CSV Injection
Posted Apr 4, 2016
Authored by Hack Ex

BugCrowd's file upload allows for CSVs that may have malicious formulas in them.

tags | exploit, file upload
SHA-256 | b22bc45847766c3e4f34e0f66a6aeb563bc845db10f668c4635c00ee0bc764a1

BugCrowd CSV Injection

Change Mirror Download

A vulnerability in the file upload feature allows attackers to send
malicious csv files. By using the Microsoft Excel DDE function an
attacker can launch arbritary commands on the victims system.

Many companies don't allow xslx or docx files to be uploaded by
security testers, because they can contain malicious macros. What they
don't realize, however, is that csv files can contain malicious macros
as well.

The csv contains a field like this:
=cmd|' /C calc'!A0

Which in this case launches the calc application as a proof of
concept. While excel does give a warning before a user opens the file
saying it should only be used if it comes from trusted sources,
bugcrowd could be seen as a trusted source and the file could be

This is just as bad or even worse than an XSS vulnerability. Imagine
if a security researcher made a submission. This submission got
rejected and the researcher is very angry. To have his revenge, he
sends a malicious csv file containing a payload to launch an
application and steal the credentials of the analysts account. Now the
researcher has access to all the vulnerabilities that have been
reported in the application. He can now publish them or cause havoc.

Extra info:

Description of the vulnerability
The same vulnerability has been discovered in HackerOne.

The researcher recommends BugCrowd to always stay on the lookout for
new kinds of vulnerabilities. Most of my submissions were
vulnerabilities in the Bug/Other categories, because they weren't the
most obvious vulnerabilities. This vulnerability was found in just a
few minutes after reading through some public HackerOne articles and
discovering an article about CSV formula injection.

Do not allow formulas in csv files.



Certain 'risky' file types like EXE files are also accepted on upload.
A better approach would probably be to limit the allowed file types to
a certain degree.


We agree with Google, who made an announcement about this issue:
As such, this is a P5 or Won't Fix issue based on Bugcrowd's
Vulnerability Rating Taxonomy. Please do read our VRT in order to know
what bugs are eligible for rewards.

changed state to wont fix
This submission was reproducible but will not be fixed. This may be a
best practice recommendation, an issue with low risk, an issue that
has existing mitigations in place, or is an accepted business risk for
the customer.


Thank you for bringing this to the researchers attention. He will
refrain from reporting these kind of vulnerabilities from now on. The
researcher did read the VRT, but didn't realize that CSV injection
vulnerabilities were a part of it. He will make sure to always test
that document before writing his reports.

Researcher (again)

The researcher doesn't want to be stubborn, but just to make sure you
understand the full impact of the vulnerability consider the fact that
Bugcrowd has 54 different companies that have their own bug bounty
programs. If an attacker send a malicious file like this to all these
companies the chanches of at least one analyst making a mistake and
opening the file are definitely high.
This could be an attractive vector for an attacker to take into
account. Excel already displays several warnings upon opening a csv
file, but these warnings imply that if the file is from a 'trusted
location' it should be ok to continue. If an attacker submits a
legitimate low level issue the analysts might place more trust in
them, because they already reported a vulnerability in their products.
Of course, Bugcrowd cannot account for every single malicious file. If
an analyst decides to open an EXE file and it contains malware then
that is something Bugcrowd doesn't have any responsibility for.
However while many people know about the risks of XLSX files and
malicious macros, not everybody knows about the fact that CSV files
can be malicious as well.
The researcher agrees with the stance of Nikhit Kumar
This issue is not essentially a vulnerability in Excel, but in every
website that places active content from untrusted sources into
spreadsheets. A website must validate its user input properly.
There is not a lot Microsoft can do to 'fix' this issue in Excel,
since it is partly an intended functionality of their product. This
isn't just limited to Excel, but it also affects products like
Openoffice and others. Older versions don't even show a warning at all
(although at this point, there are so many prerequisites that this can
hardly be seen as a valid argument).
While the researcher understands the opinion of a high profile
organisation like Google is quite convincing the researcher doesn't
believe it to be a business accepted risk. Please take a moment to
reconsider my arguments. The researcher accepts the decisions made by
Bugcrowd. If this submission will not be fixed, however, the
researcher would like permission to publish a video demonstrating this
issue so that company analysts are aware of this issue. This is not
meant as a threat towards Bugcrowd, since it is more of a way to teach
the users of Bugcrowd about the risks involved with opening these
kinds of CSV files.
Thank you for your response and the researcher awaits your response.


Hey HackEx,
You can email support@bugcrowd.com for the request of your report to
be made public. Make sure to include the Reference Number of this


The researcher has sent an email to support@bugcrowd.com asking for
full disclosure.
The researcher doesn't really like the idea of going full disclosure,
since it would increase the chances of attackers actually exploiting
this vulnerability and it could damage the reputation of Bugcrowd.
The researcher highly values the Bugcrowd community and everything it
stands for and doesn't want to create a public discussion about this
Could the analyst please explain in his/her own words why this
vulnerability will not be fixed? Relying on the opinion of another
company isn't really applicable in all cases.
An employee of Mozilla describes it nicely in response to
a bug in bugzilla.
Why is this bug tagged as a security bug? It's an issue in Excel/LibO/OO
IMO, not a Bugzilla bug.
It doesn't matter whose bug it is, bugzilla is used by folks in
environments with those very common programs and the combination can
result in harm. That makes it a security bug
Bugcrowd is also used in environments with these programs.
Now, you could also make an exception for this submission and fix it
while not rewarding the researcher. Because this is not about being
rewarded for this vulnerability, the researcher simply wants this
issue fixed and be absolutely sure it isn't abused to attack the very
companies he has fought to protect during the last 11 months since he
joined Bugcrowd.
Besides Google has actually fixed the same kind of vulnerability in Google docs.
Just look at https://erpscan.com/press-center/excel-formula-injection-in-google-docs/.
This means that the argument "Google doesn't think it is an issue and
neither do we." doesn't hold up anymore, since Google actually does
think this is an issue.
Please give it some thought. The researcher send a very long comment
the last time and none of the points he made were adressed other than
the researcher potentially wanting to go full disclosure.
With all due respect, it would probably be a lot easier to fix the
vulnerability now and get it over with than it would be to go full
disclosure and fixing it after public embarrassment (which is quite
likely to happen considering that the people who care about this issue
are probably both the security researchers and the companies who
joined Bugcrowd).
The researcher reads mailing lists like Bugtraq and other resources
like security researcher blogs daily and so do many other people.
So please, again, reconsider this issue. The researcher will probably
not be able to come up with much more than he has done so far to
convince you to fix it except for public disclosure, but this is
against the researchers philosophy of responsible disclosure and the
researcher would hate to do that.


Hi HackEx,
This has been given okay for full disclosure.


Login or Register to add favorites

File Archive:

April 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Apr 1st
    10 Files
  • 2
    Apr 2nd
    26 Files
  • 3
    Apr 3rd
    40 Files
  • 4
    Apr 4th
    6 Files
  • 5
    Apr 5th
    26 Files
  • 6
    Apr 6th
    0 Files
  • 7
    Apr 7th
    0 Files
  • 8
    Apr 8th
    22 Files
  • 9
    Apr 9th
    14 Files
  • 10
    Apr 10th
    10 Files
  • 11
    Apr 11th
    13 Files
  • 12
    Apr 12th
    14 Files
  • 13
    Apr 13th
    0 Files
  • 14
    Apr 14th
    0 Files
  • 15
    Apr 15th
    30 Files
  • 16
    Apr 16th
    10 Files
  • 17
    Apr 17th
    22 Files
  • 18
    Apr 18th
    45 Files
  • 19
    Apr 19th
    0 Files
  • 20
    Apr 20th
    0 Files
  • 21
    Apr 21st
    0 Files
  • 22
    Apr 22nd
    0 Files
  • 23
    Apr 23rd
    0 Files
  • 24
    Apr 24th
    0 Files
  • 25
    Apr 25th
    0 Files
  • 26
    Apr 26th
    0 Files
  • 27
    Apr 27th
    0 Files
  • 28
    Apr 28th
    0 Files
  • 29
    Apr 29th
    0 Files
  • 30
    Apr 30th
    0 Files

Top Authors In Last 30 Days

File Tags


packet storm

© 2022 Packet Storm. All rights reserved.

Security Services
Hosting By