Edit report at https://bugs.php.net/bug.php?id=80385&edit=1
ID: 80385
Comment by: en3py at hotmail dot com
Reported by: 306503207 at qq dot com
Summary: Response data preceded by post data
Status: Re-Opened
Type: Bug
Package: FPM related
Operating System: CentOS 7.4
PHP Version: 7.2.34
Block user comment: N
Private report: N
New Comment:
Having the same issue on two different deployments:
CentOS 7.9
CentOS 8.3
The problem does not appear on a CentOS 7.3
PHP compiled from source (7.2.34) with the following string:
./configure --prefix=/opt/php/7.2 \
--exec-prefix=/opt/php/7.2 \
--bindir=/opt/php/7.2/bin \
--sbindir=/opt/php/7.2/sbin \
--datadir=/opt/php/7.2/share \
--includedir=/opt/php/7.2/include \
--libdir=/opt/php/7.2/lib64 \
--localstatedir=/var \
--sharedstatedir=/var/lib \
--sysconfdir=/etc/php/7.2 \
--mandir=/usr/share/man \
--infodir=/usr/share/info \
--with-config-file-path=/etc/php/7.2 \
--with-config-file-scan-dir=/etc/php/7.2/conf.d \
--with-openssl-dir=/opt/openssl \
--disable-cgi --enable-ftp --enable-mbstring --enable-mysqlnd --with-curl --with-zlib \
--enable-fpm --with-fpm-user=apache --with-fpm-group=nobody --with-pdo-mysql \
--enable-zip --with-mysqli --enable-embedded-mysqli \
--with-openssl --with-ldap
FPM configuration for this context:
[xxx]
user = xxx
group = nobody
listen = 0.0.0.0:17202
pm = dynamic
pm.max_children = 5
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 3
pm.process_idle_timeout = 10s;
pm.status_path = /status
access.log = /var/log/fpm-7.2-$pool.access.log
access.format = "%R %{HTTP_HOST}e - %u %t \"%m %r%Q%q\" %s %f %{mili}d %{kilo}M
%C%%"
slowlog = /var/log/php-7.2.$pool.slow.log
request_slowlog_timeout = 10s
request_slowlog_trace_depth = 20
php_admin_value[include_path] = ".:/opt/xxx/lib:/opt/php-7.2/lib64/php"
php_admin_flag[display_errors] = false
php_admin_value[session.name] = "xxx-staging"
php_admin_value[session.save_path] = "/opt/xxx/sessions"
php_admin_flag[session.auto_start] = true
From our experience this is what happens:
- the worker starts
- POST any form: everything seems right
- avoid making any call for 5-10 seconds
- POST THE SAME Form: response data is prepended to any output
The problem persists even if the target of the POST form is empty.
[19/Mar/2021:10:10:25 +0000] "POST /it/about/op-flag.php HTTP/1.1" 200 86 [omissis]
[19/Mar/2021:10:10:26 +0000] "POST /it/about/op-flag.php HTTP/1.1" 200 201 [omissis]
The first row (Apache HTTPD 2.4.46) has the correct output, while the second shows the prepended
results, so it really comes out from FPM.
We are still investigating the isse, whereas we have about 10 servers created last year with the
identical configuration and the problem seems not occurring...
Previous Comments:
------------------------------------------------------------------------
[2021-03-01 07:52:47] camalolo at gmail dot com
Having the same exact issue. Php 7.3.27 / Ubuntu 20.04
------------------------------------------------------------------------
[2021-02-27 05:16:56] wjh08081329 at gmail dot com
when i run use docker php:8.0.1 ,i encounter this issue, but when i start a container with a self
defined php.ini locate in /usr/local/etc/php/ which with auto_prepend_file is no value ,the issue
is gone
------------------------------------------------------------------------
[2021-02-09 14:28:44] benedikt dot schaller at simovative dot com
Same problem here with Ubuntu 16.04 and PHP7.3 over apache fast-cgi module and php-fpm. The problem
apears if the fpm service runs for some time and is gone after a php-fpm restart.
I think that is a big security issue, because you could execute php code.
We have a log of similiar systems and it only happens on one of them. There themes to be no
difference.
------------------------------------------------------------------------
[2021-01-10 04:22:09] php-bugs at lists dot php dot net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Re-Opened". Thank you.
------------------------------------------------------------------------
[2020-12-28 19:22:59] bukka@php.net
So this is specifically documented in https://www.php.net/manual/en/install.fpm.configuration.php
. See the "Example #2 set PHP settings in nginx.conf" and the warning below that
"php-fpm should not be bound to a worldwide accessible address". So if the FPM is publicly
available, it should at least have listen.allowed_clients set so only the server can connect to it.
This looks like the reason why this got reported (setting PHP_VALUE and PHP_ADMIN_VALUE) from the OP
comments. Does anyone see this behaviour when having fpm protected?
Also it's not the first time I'm seeing a report like this so I'm thinking to
introduce some options that would disallow this.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=80385
--
Edit this bug report at https://bugs.php.net/bug.php?id=80385&edit=1