PHP versions 5.4.40, 5.5.24, and 5.6.8 provide a fix for use-after-free vulnerability in php_curl related to CURLOPT_FILE/_INFILE/_WRITEHEADER, which under certain circumstances might lead to arbitrary code execution.
Some details from the upstream bug:
"""
When using CURLOPT_WRITEHEADER, CURLOPT_INFILE or CURLOPT_FILE, in _php_curl_setopt, the provided stream is cast to a stdio FILE*:

if (FAILURE == php_stream_cast((php_stream *) what, PHP_STREAM_AS_STDIO, (void *) &fp, REPORT_ERRORS)) {
  return FAILURE;
}

This FILE* is then stored in the php_curl structure "ch", at the following locations, depending on which CURLOPT_ was used:
- ch->handlers->write->fp = fp;
- ch->handlers->write_header->fp = fp;
- ch->handlers->read->fp = fp;

Upon curl_exec(), _php_curl_verify_handlers() is called, which verifies if the user-set stream(s) are still open, and resets ->fp to 0 if they are not.

However, there are a number of curl callbacks we can use to close the stream after _php_curl_verify_handlers() has been called, resulting in the FILE* being free()'d. By allocating memory that ends up a the same address where the FILE structure was, its possible to achieve arbitrary code execution.

The following functions use *->fp without checking if the corresponding streams are still open (and thus if *->fp still points to a valid FILE structure or not):
- static size_t curl_write(char *data, size_t size, size_t nmemb, void *ctx)
- static size_t curl_read(char *data, size_t size, size_t nmemb, void *ctx)
- static size_t curl_write_header(char *data, size_t size, size_t nmemb, void *ctx)
- curl_exec (after curl processing is finished, there are 2 fflush() calls)

On Linux, with PHP linked against GLIBC, arbitrary code execution is trivial, since FILE structures conveniently have a "vtable" full of function pointers which we now control.
"""

Upstream fix: http://git.php.net/?p=php-src.git;a=commit;h=0ea75af9be8a40836951fc89f723dd5390b8b46f
Upstream bug: https://bugs.php.net/bug.php?id=69316