We got a POST request to our server with the following in it:


Using url decode this translates to:

cgi-bin/php?-d allow_url_include=on -d safe_mode=off -d suhosin.simulation=on -d disable_functions="" -d open_basedir=none -d auto_prepend_file=php://input -d cgi.force_redirect=0 -d cgi.redirect_status_env file=php://input -n

It seems to be similar to Strange URL requests via Nginx on Ubuntu 14.04, what is the malicious user trying to do?. In what scenario would the request work? I see from the logs we sent a 404 but I want to make sure we don't have any other box that may be vulnerable to it.

  • I've always found that servers are least vulnerable to attack when turned off, removed from all networked systems, or otherwise isolated from the world.
    – MSC
    Aug 9, 2018 at 23:04
  • The question there offer some advise; serverfault.com/questions/453732/…
    – yagmoth555
    Aug 10, 2018 at 12:21

4 Answers 4


Many years ago people used to run PHP as a CGI script (not even FastCGI, it didn't exist yet!) in part so that they could switch Apache from its low-performance prefork MPM to the new and somewhat higher performing worker MPM. (And nginx was unknown yet, it was that long ago.) If a server was set up to run PHP as a CGI script, then you could call the PHP interpreter directly at /cgi-bin/php.

PHP technically still could be installed as CGI, but it turned out not to be as performant as people were hoping, thus FastCGI was invented. All current high performance PHP sites use FastCGI/FPM, generally with nginx or sometimes with Apache's event MPM. FastCGI/FPM are not vulnerable to this as they do not permit PHP to be called directly through /cgi-bin.

If your server isn't an ancient rotting pile of PHP run as CGI, then you need not worry about this request.

  • For some reason when you wrote 'Many years ago people ...' I had the thought of the old exploit in Apache 2.x. It's at the tip of my fingers but it was often used to cat /etc/passwd though of course it wouldn't work on all servers just like everything else. This was in the 1990s though maybe it went to the early 2000s? I don't remember. Right. I know why I thought of it - phf instead of php...
    – Pryftan
    Aug 9, 2018 at 21:15
  • @Pryftan There have been so many exploits over the years...but phf does sound vaguely familiar. I'm pretty sure that was long gone by the time this millennium rolled around though. Aug 9, 2018 at 21:17
  • All I know for certain is it was around in the mid 1990s. Even so assuming that a new tree of Apache was released it tends to take a long time for all the servers out there to update (then again it does for standard computers - a good example being Windows XP although I suppose it's not as bad as it was).
    – Pryftan
    Aug 9, 2018 at 21:33

The general problem is command injection. Made easier by old insecure CGI configurations allowing php execution direction, although a modern web server that sent a 404 isn't vulnerable to this specifically.

You prevent it by removing CGI where it is not needed, locking down the web server with file permissions and maybe SELinux, and securing your web apps. Open Web Application Security Project Testing Project has some general advice.


Mallicious attackers, or pentesters who want to get a part of your bug bounty will test your website for common errors made when writing web applications or configuring web servers. These attacks count on the fact that there is a chance are that you, your vendor, web application developers or your IT team made a small error or have forgotten to keep your software or configurations up to date for newly discovered security issues, so they are just trying to exploit a lot of known issues against every server on the internet. If you do not keep your systems up to date and stay informed of latest security issues in the platform or software stack you are using, eventually your security (or that of your visitors) will be compromised.

There are a few ways to harden your webapps against a successfull attack:

  • train your web developers in using good security practices, as always OWASP is a good starting point: https://www.owasp.org/index.php/OWASP_Guide_Project
  • put your applications behind a Web Application Firewall. (WAF) a WAF will scan all incomming requests and simply drop the ones that look like they're up to no good. An easy to use cloud solution is https://www.cloudflare.com/lp/waf-a/ but there are lots of others out there, be it cloud, appliances you can install at your datacenter of software you can run on your servers (think palo alto, fortigate, checkpoint, watchguard), or there are free options like https://modsecurity.org (at this moment it seems like the package managers for distro's need to pick up on the nginx plugin/module for this, but there is an apache module out there)
  • Let a pen tester investigate your infrastructure (regularly), if you give them documentation and information about your systems they will be able to perform these tests less blind than a random attacker on the internet, chances are they will find the issues faster then a random attacker and you can fix them. If you want to do this yourself, again, OWASP is a great resource: https://www.owasp.org/index.php/OWASP_Testing_Project
  • next to a WAF you can install software that blocks users that make to many invalid requests. e.g. brute force (ssh, basic auth, ftp, mysql...) logins, generate to much internal server errors, or even to much page not founds. my favorite software for this is to install fail2ban (https://www.fail2ban.org/) which will scan your log files and block offending ip's for a few minutes using firewall rules.

Neither of these options have a 100% guarantee, and I would recommend doing all of them.

For an exhaustive list of all security/hardening measures you can take on your centos7 system, you can follow this guide by RedHat: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/security_guide/index/index




The URL and form data needs to be sanitized for invalid characters. A “blacklist” of characters is an option but it may be difficult to think of all of the characters to validate against. Also there may be some that were not discovered as of yet. A “white list” containing only allowable characters or command list should be created to validate the user input. Characters that were missed, as well as undiscovered threats, should be eliminated by this list.

Genereal blacklist to be included for commannd injection can be | ; & $ > < ' \ ! >> #

Escape or filter special characters for windows, ( ) < > & * ‘ | = ? ; [ ] ^ ~ ! . ” % @ / \ : + ,

Escape or filter special characters for Linux, { } ( ) < > & * ‘ | = ? ; [ ] $ – # ~ ! . ” % / \ : + ,


The web application and its components should be running under strict permissions that do not allow operating system command execution. Try to verify all these informations to test from a Gray Box point of view.


Also install modsecurity in Nginx with the comodo rules.


  • 4
    Blanket blacklisting is never the correct answer to a security question. All the characters you mention could legitimately occur in an URL, never mind form data! How would you feel about not being able to use + or / or ' or () in SE posts?
    – marcelm
    Aug 9, 2018 at 14:52
  • Several of us have linked to OWASP, but I don't think narrowly focusing on sanitation is the right priority. Remove PHP if not in use, if in use use a modern web server. Prevent web server from executing arbitrary programs. Add a WAF to filter malicious stuff. Don't execute OS commands in web apps at all if possible. And so on. Aug 10, 2018 at 11:49

You must log in to answer this question.

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