This year has seen a mass influx of reportson remote file-include vulnerabilities. On the same note, it has alsoseen a mass number of invalid vulnerability reports. Thetrend, it seems, is for reporters to grep as much source code aspossible, looking for that special phrase: include($variable). However,the reporters either neglect to read the entire source prior to thatline, or perhaps choose to ignore it. As is often the case for falsereports, within five lines of the include() call is a declaration forthe very variable assumed to be vulnerable.
This naturally makes my job all the more complicated. Our teamprides itself on having the most comprehensive vulnerability databaseavailable. We also want to make sure it’s accurate and doesn’t containinvalid entries. We try to verify all the issues reported to us,usually by inspecting the source code, but it is frustrating to spendtime scrutinizing reports on “issues” that are clearly not vulnerable.This, in turn, means that we must now maintain a list of reports ofinvalid issues. We must then check that list every time an issue isreported to weed out the obvious invalid reports, and then repeat thecycle with another source inspection.
The real question remains: Are those that report these issues insuch a hurry that they neglect to ensure their validity? Or, are thereporters in such a rush to have their five minutes of fame, eventuallyrisking the loss of a lot of their credibility (and even facingridicule from their peers) when the false report is discovered?
Our customers can rest assured that the issues we report have gonethrough the scrutiny required. They can also know that if we don’treport on an Issue—even if our competitors may provide a report onit—then it’s likely not a valid issue because it’s based on an invalidreport.