该漏洞与php和nginx版本无关，是配置错误导致的问题 漏洞描述 通常在nginx.conf的配置文件或者include包含的其他配置文件下有以下信息 location ~ \.php$ { fastcgi_index index.php; include fastcgi_params; fastcgi_param REDIRECT_STATUS 200; fastcgi_param SCRIPT_FILENAME /var/www/html$fastcgi_script_name; fastcgi_param DOCUMENT_ROOT /var/www/html; fastcgi_pass php:9000; } 上述代码的可以简理解为:Nginx解析到.php的后缀名就会交给fastcgi处理，fastcgi可以简单的理解为python解释器一样的东西，负责php代码的执行渲染 但是现在还不会导致Nginx解析的漏洞，需要配合另外一个配置文件php.ini构成Nginx解析漏洞 在Nginx解析到后缀名为.php会交给php处理，php在处理文件的时候会受到php.ini配置文件的影响，在php.ini配置文件中含有一个默认配置cgi.fix_pathinfo=1，该配置项的作用是如果访问的.php文件不存在，则采用上层路径，例如访问/test.png/.php,一般情况下.php文件是不存在的就会将/test.png解析 最重要的配置就是php-fpm的配置文件中的security.limit_extensions配置项默认为空，该文件规定了什么后缀名当做php代码执行 所以通过这一连贯的默认配置，我们可以访问一个/test.png的文件，后方加入/.php或者是任意不存在的a.php,就会由于Nginx解析漏洞导致php代码执行 漏洞利用 使用vulhub复现靶机 cd /vulhub/nginx/nginx_parsing_vulnerability sudo docker-compose up -d 随便上传一个含有php代码的图片 访问该图片成功上传 在最后加入/.php或者任意一个不存在的文件名例如：/a.php 成功利用 漏洞修复 修改php-fpm配置文件项security.limit_extensions加入只有.php后缀名解析为php代码执行 [www] security.limit_extensions = .php 重启服务器再次漏洞利用失败 sudo docker-compose restart 实验结束。