After building a custom docker image with the new version of nginx, the modsecurity page is turned on and it becomes messy!

Describe the bug

The latest version of nginx, I built my own docker image and used GitHub workflow to automatically execute it. Turning on modsecurity in the newly built nginx image will cause page loading errors. Turning off modsecurity will restore to normal.

As long as waf is turned on, the page will be messed up. I checked the waf warehouse and it has not been updated, but the nginx image has been updated. I hope it can be fixed. I did not have this problem when I built it in early January. Today, the page is messed up after turning on waf. This is how I build the image: https://github.com/kejilion/docker/blob/main/nginx/Dockerfile-waf

Logs and dumps

I just didn't see any relevant error logs. At first I thought it was WAF interception that caused the page display to be disordered, but there was no interception log, nor in the nginx log.

To Reproduce

https://github.com/kejilion/nginx/blob/main/nginx10.conf
https://github.com/kejilion/nginx/blob/main/wordpress.com.conf

Expected behavior

The version of nginx at the beginning of the month does not have page confusion when WAF is enabled, but the docker image built today will have problems. The build method is exactly the same as before. I hope it will return to normal and display the page content correctly.

Additional context

/ # nginx -V
nginx version: nginx/1.27.3
built by gcc 13.2.1 20240309 (Alpine 13.2.1_git20240309)
built with OpenSSL 3.3.0 9 Apr 2024 (running with OpenSSL 3.3.2 3 Sep 2024)
TLS SNI support enabled
configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib/nginx/modules --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --with-perl_modules_path=/usr/lib/perl5/vendor_perl --user=nginx --group=nginx --with-compat --with-file-aio --with-threads --with-http_addition_module --with-http_auth_request_module --with-http_dav_module --with-http_flv_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_mp4_module --with-http_random_index_module --with-http_realip_module --with-http_secure_link_module --with-http_slice_module --with-http_ssl_module --with-http_stub_status_module --with-http_sub_module --with-http_v2_module --with-http_v3_module --with-mail --with-mail_ssl_module --with-stream --with-stream_realip_module --with-stream_ssl_module --with-stream_ssl_preread_module --with-cc-opt='-Os -fstack-clash-protection -Wformat -Werror=format-security -g' --with-ld-opt=-Wl,--as-needed,-O1,--sort-common

Start by reproducing the rendering problem with the linked Dockerfile-waf, nginx10.conf, and wordpress.com.conf while comparing the earlier and current nginx builds. Inspect the WAF and nginx behavior with modsecurity enabled; done means the page renders correctly with WAF enabled and the relevant cause or diagnostic evidence is documented.