Some checks on a request URI were not executed on a character following an unescaped space character (which is invalid per HTTP protocol, but allowed for compatibility reasons since nginx 0.8.41). One of the results is that it was possible to bypass security restrictions like location /protected/ { deny all; } by requesting a file as "/foo /../protected/file" (in case of static files, only if there is a "foo " directory with a trailing space), or to trigger processing of a file with a trailing space in a configuration like location ~ \.php$ { fastcgi_pass ... } by requesting a file as "/file \0.php".
nginx-1.4.4 and 1.5.7 are in the tree. Please continue with stabilization of 1.4.4 since it is the stable branch.
Arches, please test and mark stable: =www-servers/nginx-1.4.4 Target keywords : "amd64 x86"
amd64 stable
x86 stable. Maintainer(s), please cleanup. Security, please vote.
(In reply to Agostino Sarubbo from comment #4) > x86 stable. > > Maintainer(s), please cleanup. done.
CVE-2013-4547 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2013-4547): nginx 0.8.41 through 1.4.3 and 1.5.x before 1.5.7 allows remote attackers to bypass intended restrictions via an unescaped space character in a URI.
GLSA vote: no.
GLSA vote: no Closing as noglsa