Older versions of nginx suffer from a flaw where a NULL byte in a URI was handled improperly in some modules, such as with the FastCGI server. If an attacker were able to upload a file to the PHP-FCGI server with a crafted filename such as file.jpg%00.php, the NULL byte could cause all data after the NULL byte to be discarded. In this case, uploading file.jpg%00.php would cause PHP-FCGI, for instance, to parse the file as a PHP file, which could lead to artbitrary code execution on sites where files could be uploaded.
This was previously reported to the Ubuntu bug tracker  and has been fixed in nginx r3528. This would affect nginx versions 0.5, 0.6, 0.7 < 0.7.66, and 0.8 < 0.8.38.
Created nginx tracking bugs for this issue
Affects: epel-4 [bug 717080]
[I'm the original reporter]
Just to clarify, this issue does not involve uploading files containing NULL bytes in their name. Instead, it has to do with how NULL bytes in URLs are handled by nginx.
The default configuration for PHP-FCGI involves a location block that looks for requests with URLs ending in .php and passes those requests onto the PHP-FCGI handler. In vulnerable versions of nginx, an attacker can cause any file accessible on the server to be executed as PHP by making a request with a URL ending in %00.php. Behind the scenes, nginx notices the .php extension at the end of the request and passes it along to the PHP-FCGI handler. However, the %00.php suffix is ignored by PHP-FCGI due to the NULL byte, which allows the real file to be loaded and parsed. That leads to arbitrary code execution on sites where an attacker can upload a publicly accessible file to the server.
Blog post about this flaw from the original reporter:
This was pushed to stable back in September, should it be closed now?
It looks like this should have been closed by Bodhi but wasn't.
(In reply to comment #5)
> It looks like this should have been closed by Bodhi but wasn't.
I can confirm, the latest available version of nginx package for Fedora EPEL 4 is nginx-0.8.55-2.el4, which contains patch for this issue. Thus this can truly should be closed.
Thanks for doing that, Jeremy.
Jan iankko Lieskovsky / Red Hat Security Response Team