OpenVAS found a vulnerability where it points to PHP versions 5.4.3 and 5.3.13. But both the two hosts I checked with OpenVAS are running PHP 7.2.x. Would this vulnerability be a false positive?

High (CVSS: 7.5)
NVT: PHP-CGI-based setups vulnerability when parsing query string parameters from ph... (OID:
PHP is prone to an information-disclosure vulnerability.

Vulnerability Detection Result
Vulnerable URL: http://domain:port/

Solution type: VendorFix

PHP has released version 5.4.3 and 5.3.13 to address this vulnerability. PHP is recommending that users upgrade to the latest version of PHP.

Vulnerability Insight
When PHP is used in a CGI-based setup (such as Apache's mod_cgid), the php-cgi receives a processed query string parameter as command line arguments which allows command-line switches, such as -s, -d or -c to be passed to the php-cgi binary, which can be exploited to disclose source code and obtain arbitrary code execution.

An example of the -s command, allowing an attacker to view the source code of index.php is below:


Vulnerability Detection Method
Details: PHP-CGI-based setups vulnerability when parsing query string parameters from ph... (OID:

Version used: 2019-11-08T10:10:55+0000

CVE: CVE-2012-1823, CVE-2012-2311, CVE-2012-2336, CVE-2012-2335
BID: 53388

  • 2
    Welcome! Are you able to reproduce this by manually sending the same HTTP request as OpenVas?
    – phbits
    May 4, 2020 at 17:53
  • Its 2020, are you really using PHP via CGI?
    – symcbean
    May 4, 2020 at 23:29
  • Thank you for the welcome @phbits. We do not use PHP and CGI. How do I reproduce this by manually sending the same HTTP request as OpenVas? I do not know how to do. Thank you
    – Ricardo
    May 6, 2020 at 16:28
  • 1
    Use something like apirequest.io or nc. Even browser developer tools can send HTTP requests. Since you're not even using PHP/CGI this would be for the sake of learning as it isn't necessary. Very likely a false positive.
    – phbits
    May 6, 2020 at 20:43

1 Answer 1


This VT is doing an "active" HTTP POST request to the mentioned URL http://domain:port/ with the following data:

POST body: <?php phpinfo();?>

to the following two URLs (one after another):

URL1: http://domain:port/?-dallow_url_include%3don+-dauto_prepend_file%3dphp://input
URL2: http://domain:port/?%2D%64+%61%6C%6C%6F%77%5F%75%72%6C%5F%69%6E%63%6C%75%64%65%3D%6F%6E+%2D%64%73%61%66%65%5F%6D%6F%64%65%3D%6F%66%66+%2D%64+%73%75%68%6F%73%69%6E%2E%73%69%6D%75%6C%61%74%69%6F%6E%3D%6F%6E+%2D%64+%64%69%73%61%62%6C%65%5F%66%75%6E%63%74%69%6F%6E%73%3D%22%22+%2D%64+%6F%70%65%6E%5F%62%61%73%65%64%69%72%3D%6E%6F%6E%65+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%70%75%74+%2D%64+%63%67%69%2E%66%6F%72%63%65%5F%72%65%64%69%72%65%63%74%3D%30+%2D%64+%63%67%69%2E%72%65%64%69%72%65%63%74%5F%73%74%61%74%75%73%5F%65%6E%76%3D%30+%2D%6E

and is checking if the remote host is answering with a <title>phpinfo() to this request. To avoid that any false positives are happening it checks if any of the URL tested are previously detected to respond with such a <title>phpinfo() string.

If you're getting a vulnerability report this could mean a few things:

  1. The web server / application itself is vulnerable against such kind of attacks even if not running PHP via CGI.
  2. Newer versions of PHP are again vulnerable against such kind of attacks.
  3. The URL http://domain:port/ is always returning <title>phpinfo() and the previous detection of this to avoid false positives failed.

The VT will be improved in the next few days to give out a little bit more info about the check done but the info above should be enough to verify the vulnerability on that specific host.

Disclaimer: VT Dev @ Greenbone (Maintainer of GVM, former OpenVAS)

  • So with one of the next feed updates you should get something like e.g. the following: ` By doing the following HTTP POST request: "HTTP POST" body : <?php phpinfo();?> URL : localhost:8080/… it was possible to execute the "<?php phpinfo();?>" command. Result: <title>phpinfo()</title><meta name="ROBOTS" content="NOINDEX,NOFOLLOW,NOARCHIVE" /></head> `
    – cfischer
    May 11, 2020 at 14:16
  • Thank you @cfischer The information you provided was great. The scan target actually had a so-called "echo php info" within the main redirect. When removing this call echo php info, I ran the scan again, and OpenVas did not present this vulnerability. Thank you for your help!
    – Ricardo
    May 16, 2020 at 14:24
  • Thanks cfischer, your tip was valuable. The host actually had a php info call within a redirect. By removing the call and scanning again with OpenVas, the problem is gone. Thank you for your help.
    – Ricardo
    May 19, 2020 at 11:11

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .