I have noticed over the couple last weeks that the amount of vulnerabilities being discovered in PHP related products have soared. This might have been a good thing if these vulnerabilities weren’t sometimes fictitious.

Take this example:
Smarty-2.6.1 Remote File Include Vulnerabilities

The poster of the vulnerability mentions these lines of code as being vulnerable:
require_once ‘./config.php’;
require_once SMARTY_DIR . ‘Smarty.class.php’;
require_once ‘PHPUnit.php’;

And further says that by passing:
/unit_test/test_cases.php?SMARTY_DIR=Sh3ll?

He is able to cause the PHP code to include arbitrary code. The vulnerability is simply not there, credit is due to J. Carlos Nieto for noting it first.

Is this a single incident? No, another example is a vulnerability titled:
gcards (languagefile) Remote File Include

Where the author of the advisory doesn’t specifically state where the vulnerable code is located at, but only provides a proof of concept:
gcards/admin/addnews.php?languagefile=shell code

Looking into addnews.php you can notice the following line:
include_once(“../inc/”.$languageFile);

Does this mean that languagefile value affects languageFile parameter being used in the include_once? if the PoC is no typo, then no it doesn’t affect that parameter.

If the PoC is a typo and the PoC should have contained langaugeFile as the name of the parameter, still no, if you look into the code closer you will notice that, the following files precede the call to languageFile:
include_once(‘../inc/adodb300/adodb.inc.php’); # load code common to ADOdb
include_once(‘../config.php’);
include_once(‘../inc/UIfunctions.php’);
include_once(‘loginfunction.php’);
include_once(‘../inc/smileyClass.php’);

and the config.php file specifies:
$languageFile = ‘language_en.php’;

Meaning the product isn’t open to attack through this parameter, credit is due here for str0ke for noting it first.

Last but probably not really the last one:
PhpBB 2.0.10 (groupcp.php) Remote File Include Vulnerability

The author of the advisory mentions:
include($phpbb_root_path . ‘includes/page_header.’.$phpEx);

As the code being vulnerable, and /groupcp.php?phpbb_root_path=shell.txt? as being the attack vector, beside the fact that version 2.0.10 is more than 2 years old a check through the code reveals that a call to (at the very beginning of the file):
$phpbb_root_path = ‘./’

Stops any such attack from occurring, credit is due to NeoThermic for noting it first.

Does it mean that all vulnerabilities are fake? no, some are true, but there is an increasing sense – at least by me – that people are releasing without testing, or maybe they are even using Google’s codesearch to discover these vulnerabilities and never bother to test them thoroughly.