| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| A regression error in the phpinfo function in PHP 4.4.3 to 4.4.6, and PHP 6.0 in CVS, allows remote attackers to conduct cross-site scripting (XSS) attacks via GET, POST, or COOKIE array values, which are not escaped in the phpinfo output, as originally fixed for CVE-2005-3388. |
| The imap_body function in PHP before 4.4.4 does not implement safemode or open_basedir checks, which allows local users to read arbitrary files or list arbitrary directory contents. |
| Off-by-one error in the str_ireplace function in PHP 5.2.1 might allow context-dependent attackers to cause a denial of service (crash). |
| The cpdf_open function in the ClibPDF (cpdf) extension in PHP 4.4.6 allows context-dependent attackers to obtain sensitive information (script source code) via a long string in the second argument. |
| The posix_mkfifo function in ext/posix/posix.c in PHP before 5.2.12 and 5.3.x before 5.3.1 allows context-dependent attackers to bypass open_basedir restrictions, and create FIFO files, via the pathname and mode arguments, as demonstrated by creating a .htaccess file. |
| The unserialize function in PHP 5.3.0 and earlier allows context-dependent attackers to cause a denial of service (resource consumption) via a deeply nested serialized variable, as demonstrated by a string beginning with a:1: followed by many {a:1: sequences. |
| Unspecified vulnerability in PHP before 5.2.11, and 5.3.x before 5.3.1, has unknown impact and attack vectors related to "missing sanity checks around exif processing." |
| sapi/cgi/cgi_main.c in PHP before 5.3.12 and 5.4.x before 5.4.2, when configured as a CGI script (aka php-cgi), does not properly handle query strings that lack an = (equals sign) character, which allows remote attackers to execute arbitrary code by placing command-line options in the query string, related to lack of skipping a certain php_getopt for the 'd' case. |
| FrankenPHP is a modern application server for PHP. Prior to 1.11.2, when running FrankenPHP in worker mode, the $_SESSION superglobal is not correctly reset between requests. This allows a subsequent request processed by the same worker to access the $_SESSION data of the previous request (potentially belonging to a different user) before session_start() is called. This vulnerability is fixed in 1.11.2. |
| FrankenPHP is a modern application server for PHP. Prior to 1.11.2, FrankenPHP’s CGI path splitting logic improperly handles Unicode characters during case conversion. The logic computes the split index (for finding .php) on a lowercased copy of the request path but applies that byte index to the original path. Because strings.ToLower() in Go can increase the byte length of certain UTF-8 characters (e.g., Ⱥ expands when lowercased), the computed index may not align with the correct position in the original string. This results in an incorrect SCRIPT_NAME and SCRIPT_FILENAME, potentially causing FrankenPHP to execute a file other than the one intended by the URI. This vulnerability is fixed in 1.11.2. |
| The Apache module for PHP 4.0.0 through PHP 4.0.4, when disabled with the 'engine = off' option for a virtual host, may disable PHP for other virtual hosts, which could cause Apache to serve the source code of PHP scripts. |
| Buffer overflows in (1) php_mime_split in PHP 4.1.0, 4.1.1, and 4.0.6 and earlier, and (2) php3_mime_split in PHP 3.0.x allows remote attackers to execute arbitrary code via a multipart/form-data HTTP POST request when file_uploads is enabled. |
| php_variables.c in PHP before 5.0.2 allows remote attackers to read sensitive memory contents via (1) GET, (2) POST, or (3) COOKIE GPC variables that end in an open bracket character, which causes PHP to calculate an incorrect string length. |
| The RFC1867 file upload feature in PHP 4.x up to 4.4.0 and 5.x up to 5.0.5, when register_globals is enabled, allows remote attackers to modify the GLOBALS array and bypass security protections of PHP applications via a multipart/form-data POST request with a "GLOBALS" fileupload field. |
| Buffer overflow in the imap_fetch_overview function in the IMAP functionality (php_imap.c) in PHP before 4.3.3 allows remote attackers to cause a denial of service (segmentation fault) and possibly execute arbitrary code via a long e-mail address in a (1) To or (2) From header. |
| Multiple vulnerabilities in PHP before 4.4.1 allow remote attackers to bypass safe_mode and open_basedir restrictions via unknown attack vectors in (1) ext/curl and (2) ext/gd. |
| Multiple integer handling errors in PHP before 4.3.10 allow attackers to bypass safe mode restrictions, cause a denial of service, or execute arbitrary code via (1) a negative offset value to the shmop_write function, (2) an "integer overflow/underflow" in the pack function, or (3) an "integer overflow/underflow" in the unpack function. NOTE: this issue was originally REJECTed by its CNA before publication, but that decision is in active dispute. This candidate may change significantly in the future as a result of further discussion. |
| The deserialization code in PHP before 4.3.10 and PHP 5.x up to 5.0.2 allows remote attackers to cause a denial of service and execute arbitrary code via untrusted data to the unserialize function that may trigger "information disclosure, double-free and negative reference index array underflow" results. |
| Stack-based buffer overflow in the create_named_pipe function in libmysql.c in PHP 4.3.10 and 4.4.x before 4.4.3 for Windows allows attackers to execute arbitrary code via a long (1) arg_host or (2) arg_unix_socket argument, as demonstrated by a long named pipe variable in the host argument to the mysql_connect function. |
| PHP treats unknown methods such as "PoSt" as a GET request, which could allow attackers to intended access restrictions if PHP is running on a server that passes on all methods, such as Apache httpd 2.0, as demonstrated using a Limit directive. NOTE: this issue has been disputed by the Apache security team, saying "It is by design that PHP allows scripts to process any request method. A script which does not explicitly verify the request method will hence be processed as normal for arbitrary methods. It is therefore expected behaviour that one cannot implement per-method access control using the Apache configuration alone, which is the assumption made in this report. |
