Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

According to this post, it was said that if I am using PHP/Nginx, for better security, I should either

cgi.fix_pathinfo = 0


if ( $fastcgi_script_name ~ \..*\/.*php ) {
  return 403;

In other tutorial it recommend the style of

fastcgi_split_path_info ^((?U).+\.php)(/?.+)$;

Are they contradictive to each others? Any security recommendation?


share|improve this question
up vote 4 down vote accepted

You're referring to an issue where an attacker can upload arbitrary code to an nginx web server and then trick the server into executing it as PHP. (No CVE exists for this issue as it is technically a misconfiguration rather than a vulnerability.)

Any of the methods you listed can be used to remediate the issue.

Another, simpler way of remediating this issue is to add the following into your PHP location:

try_files $uri =404;

Though this only works if nginx and PHP are running on the same server, which is almost always true.

The recommendation, of course, is that you clearly document what you're doing and why.

share|improve this answer

In recent versions of php, this is no longer an issue:

From the file /etc/php-fpm.d/www.conf:

; Limits the extensions of the main script FPM will allow to parse. This can
; prevent configuration mistakes on the web server side. You should only limit
; FPM to .php extensions to prevent malicious users to use other extensions to
; exectute php code.
; Note: set an empty value to allow all extensions.
; Default Value: .php
;security.limit_extensions = .php .php3 .php4 .php5
share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.