Paid Advertising
web application security lab

phpinfo() Recon

Today I was doing a little research and I happened across a site that displayed it’s phpinfo() function. I wasn’t even sure what I was looking at at first because it was just such an insane wealth of reconnaissance information on the server in question that I just couldn’t believe my eyes. It’s my new favorite amusing Google Dork: intitle:phpinfo() inurl:com

Let’s take an example, like What can we derive out of looking at their phpinfo? Where should we start?

  • Compile time configuration information. So if I wanted to know configuration options for PHP, I’ve pretty much got that at my disposal, not to mention path information. Bummer.
  • Register_globals is apparently turned on - lucky for us.
  • libcurl/7.15.1 OpenSSL 0.9.8a 11 Oct 2005 zlib/1.2.2 libidn/0.5.18 - lots of outdated software.
  • Hashing engines - at least we don’t have to muddle around and guess how data is hashed too much once we do break in
  • ImageMagick 5.5.7 - another outdated version, love it.
  • pfpro.defaulthost - could be interesting if we can compromise the DNS, but it’s only a test. This could be more interesting on a production machine.
  • libTidy Release 1 September 2005 - more outdated software.
  • Apache/1.3.34 Ben-SSL/1.57 (Unix) mod_gzip/ mod_fastcgi/2.4.2 mod_throttle/3.1.2 Chili!Soft-ASP/3.6.2 FrontPage/ mod_perl/1.29 PHP/4.4.2 - hmmm… vulnerable to the expect XSS issue among other issues.

Why would you ever put something like this on your server, and more importantly why would you ever allow a search engine to spider it? These sorts of information disclosure issues can really hurt companies, and unfortunately it’s trivial to find them (less so on targeted servers, but for un-targeted worms this is great recon). Scary.

15 Responses to “phpinfo() Recon”

  1. dusoft Says:

    I am surprised that you have found this so late ;-)

    Some of the nameservers display phpinfo() functions, some of the well configured servers have phpinfo() on the special page…

    Otherwise I have to agree with you, phpinfo is great source of information on the server, you don’t even have to use nmap ;-)

  2. RSnake Says:

    I am too… where was I sleeping?

  3. DanielG Says:

    You could even use the phpinfo() page to execute XSS for PHP version 5.1.2 and prior or PHP version 4.4.2 and prior.

    Example using the google dork [”PHP 4.4.1″ intitle:phpinfo() inurl:com]:[][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][]=%3Cscript%3Ealert(String.fromCharCode(88,83,83));%3C/script%3E

  4. Andrew Says:

    DanielG, I’ve found that the above exploit actually works on some 4.4.4 servers also.


  5. Kyran Says:

    Haha RSnake. Even I knew this! But it is really useful and as DanielG and Andrew pointed out, has more uses than just recon.

  6. dusoft Says:

    RSnake: XSS bug found by me ath website of the largest daily newspaper in Slovakia:

    Attacker could gain access to logged users’ data in the discussions - it was possible to inject HTML/JS code into the discussion comment easily (no checking for or encoding it whatsoever). Attacker could gain access to the username, user’s email, IP address of user, session ID and of course full access to any property of document object model.

    More reading in Slovak language only ;-):

  7. Stefan Esser Says:


    this is indeed quite old news. However the Suhosin extension (since 0.9.15) transparently adds META tags into the phpinfo() output that tells search engines to NOT index them.

    Similiar stuff is also in the PHP CVS, and will be part of default PHP as soon new versions are released.

  8. John @ Says:

    It was very easy to find several .gov sites with remotely exploitable vulnerabilities in just a few minutes time that allow remote code execution (of course they may be relying on an IPS crutch to stop some of it). Seems like this would have been used more effectively. Of course it would also be real easy to seed Google with fake PHPInfo pages on a honeypot. Great for meeting a monthly bust a script kiddie quota.

    Not knowing a lot about this but I would think having PHPInfo open would not be the default installation. If that is true wouldn’t it be likely that these sites would other permissions set incorrectly?

    btw Rsnake, I think someone from Slovakia is trying hard to get your attention.

  9. Jungsonn Says:

    Yeah it’s something I was barking to fellow developers for many years, but they just don’t see the risk, for them it’s handy.

    But there is something far more dangerous, sometmies a developer needs to know the globals stored in PHP, this can be accessed with: var_dump($GLOBALS)

    Now, the cool thing about it is, that it also dumps the database login unto the screen if that file is present before the place where you call the globals.

  10. dusoft Says:

    John @ NIST: please, read discussion under older articles - I was referring to the larges Czech e-zine XSS vulnerability which I have mentioned under the older article.

  11. dexcs Says:

    Hey folks,
    try that google dork, much less spam ;-)

    “intitle:phpinfo() inurl:com System Build Date”

    Greetings dexcs

  12. dexcs Says:

    Sry, Mod for another Post, but check this one out:

  13. kmoney Says:

    Andrew Says:
    January 30th, 2007 at 8:10 pm

    DanielG, I’ve found that the above exploit actually works on some 4.4.4 servers also.

    So….Andrew, RSnake, what kind of info can be gained thru an XSS vulnerability in phpinfo() just for my information? -trying to build my security knowledge as a junior developer

  14. phpinfo() больше не индексируется — Webсайт Титова Антона Says:

    […] О том, чем может помочь злоумышленику страница созданная функцией phpinfo() можно почитать например в записи phpinfo() Recon. […]

  15. sencaw Says:

    who wrote this originally, anyone recognize it - trying to give cred but having hard time finding orig?