REQBODY_ERROR "Extra content at the end of the document" after 3.0.15 update

[ssigwart]

Describe the bug

I updated from version 3.0.14 to 3.0.15 today. Unfortunately, I don't have a ton of helpful info, but I've noticed a few errors that I haven't seen before with REQBODY_ERROR tripping.

Logs and dumps

Here's an example nginx error log (with IP and domain changed).

body.xml:1: parser error : Extra content at the end of the document
2026/05/12 20:51:59 [error] 22751#22751: *430298 [client 123.123.123.123] ModSecurity: Access denied with code 400 (phase 2). Matched "Operator `Eq' with parameter `0' against variable `REQBODY_ERROR' (Value: `1' ) [file "/etc/nginx/modsec/modsecurity.conf"] [line "53"] [id "200002"] [rev ""] [msg "Failed to parse request body."] [data "XML parsing error: XML: Failed to parse document."] [severity "2"] [ver ""] [maturity "0"] [accuracy "0"] [hostname "example.com"] [uri "/"] [unique_id "177863351988.105338"] [ref "v269,1"], client: 123.123.123.123, server: example.com, request: "GET / HTTP/1.1", host: "example.com"

To Reproduce

Sorry, I don't know how to reproduce this. I've seen this a handful of times in millions of requests.

Server (please complete the following information):

• ModSecurity version (and connector): ModSecurity v3.0.15 with nginx-connector v1.0.4
• WebServer: nginx 1.26
• OS (and distro): Amazon Linux 2

Rule Set (please complete the following information):

• Running any public or commercial rule set? CRS
• What is the version number? 4.26.0

[airween]

Hi @ssigwart,

thanks for reporting this.

Based on the message in the attached log this can happened at two places:

• here
• and here

The mentioned blocks have changed since 3.0.14, but the last condition is the same (in both cases):

    if (m_data.well_formed != 1) {

Sorry, I don't know how to reproduce this. I've seen this a handful of times in millions of requests.

Don't you have any audit.log with body part content? Without that, I'm afraid we can't investigate this issue. If you have a tons of this, probably that would be enough to allow audit.log (with body parts) for a short time.

[ssigwart]

Hi @airween,

I do have some audit logs, but I thought it was basically the same info as the error log. I posted it here anyway. We don't include the request or response headers or body for security reasons and PCI compliance. It can make debugging harder though.

---4AxOFwLw---A--
[12/May/2026:20:51:59 -0400] 177863351988.105338 123.123.123.123 43936 192.168.100.100 443
---4AxOFwLw---D--

---4AxOFwLw---F--
HTTP/1.1 400
Server: nginx
Date: Wed, 13 May 2026 00:51:59 GMT
Content-Length: 552
Content-Type: text/html
Connection: close

---4AxOFwLw---H--
ModSecurity: Access denied with code 400 (phase 2). Matched "Operator `Eq' with parameter `0' against variable `REQBODY_ERROR' (Value: `1' ) [file "/etc/nginx/modsec/modsecurity.conf"] [line "53"] [id "200002"] [rev ""] [msg "Failed to parse request body."] [data "XML parsing error: XML: Failed to parse document."] [severity "2"] [ver ""] [maturity "0"] [accuracy "0"] [hostname "example.com"] [uri "/"] [unique_id "177863351988.105338"] [ref "v269,1"]

---4AxOFwLw---I--

---4AxOFwLw---J--

---4AxOFwLw---Z--

Thanks for pointing out the updated code. I looked at some requests before and after upgrading. We did have some things triggering rule 200002 before and after, so I don't think it's an issue that the rule is triggering. That's probably appropriately flagging malicious requests. However, the difference is the body.xml:1: parser error : Extra content at the end of the document line in the nginx error logs. Notice that it doesn't output with the normal Nginx error log line prefix (e.g. 2026/05/12 20:51:59 [error] 22751#22751: *430298 [client 123.123.123.123] ). That is what brought this to my attention. We have code that parses timestamps from the logs, but these didn't have one.

I wonder if this needs an update similar to b9dc9cc.

[airween]

I do have some audit logs, but I thought it was basically the same info as the error log. I posted it here anyway. We don't include the request or response headers or body for security reasons and PCI compliance. It can make debugging harder though.

I see and I agree.

But - I don't know how frequent is this issue, for a short period would it be possible to add the body parts (C) to SecAuditLogParts? Indeed, you might remove/change sensitive data.

That's probably appropriately flagging malicious requests.

So probably this is a normal behavior?

Notice that it doesn't output with the normal Nginx error log line prefix (... ). That is what brought this to my attention. We have code that parses timestamps from the logs, but these didn't have one.

Ah, I see.

I wonder if this needs an update similar to b9dc9cc.

Thanks, I'll take a look at that.

[ssigwart]

I do have some audit logs, but I thought it was basically the same info as the error log. I posted it here anyway. We don't include the request or response headers or body for security reasons and PCI compliance. It can make debugging harder though.

I see and I agree.

But - I don't know how frequent is this issue, for a short period would it be possible to add the body parts (C) to SecAuditLogParts? Indeed, you might remove/change sensitive data.

It's so infrequent. In millions of requests yesterday, there were probably no more than 1 - 2 dozen. I can't enable the logging because PCI compliance requires log retention and deletion protection. Even if that wasn't a concern, I'm pretty sure the sheer volume of ModSecurity blocks I deal with would fill up our disk.

That's probably appropriately flagging malicious requests.

So probably this is a normal behavior?

I think so. It's just the error log entry without the date prefix that's problematic.

Notice that it doesn't output with the normal Nginx error log line prefix (... ). That is what brought this to my attention. We have code that parses timestamps from the logs, but these didn't have one.

Ah, I see.

I wonder if this needs an update similar to b9dc9cc.

Thanks, I'll take a look at that.

Thank you.

[ssigwart]

@airween, I found a really easy way to duplicate it. I ran the following against my server and saw it in the logs. I tried to use the CRS sandbox so it was a server you'd be able to see, but the command below results in a 500 server error.

curl -H "x-format-output: txt-matched-rules" https://sandbox.coreruleset.org/ -H "Content-Type: application/xml" -i -X POST --data '<xml></xml> Testing modsec'

[airween]

@ssigwart,

thanks, I was able to reproduce that.

But I got only this in my error.log:

2026/05/13 18:12:58 [info] 132588#132588: *1 ModSecurity: Warning. Matched "Operator `Eq' with parameter `0' against variable `REQBODY_ERROR' (Value: `1' ) [file "/etc/nginx/modsecurity.conf"] [line "75"] [id "200002"] [rev ""] [msg "Failed to parse request body."] [data "XML parsing error: XML: Failed to parse document."] [severity "2"] [ver ""] [maturity "0"] [accuracy "0"] [hostname "localhost"] [uri "/"] [unique_id "177868877880.055869"] [ref "v157,1"], client: 127.0.0.1, server: _, request: "POST / HTTP/1.1", host: "localhost:8080"
2026/05/13 18:12:58 [info] 132588#132588: *1 client 127.0.0.1 closed keepalive connection

Nothing more.
libmodsecurity3 is the current upstream (Github) version, connector is 1.0.4 (stable released).

[ssigwart]

It took me a while, but I was able to reproduce this in docker. Here's what I did.

docker run -ti --rm -p 8080:80 --platform=linux/arm64 amazonlinux:2023

dnf install -y nginx gcc-c++ flex bison yajl-devel curl-devel libxml2-devel pcre2-devel git libtool wget vim
cd /
git clone --depth 1 -b v3/master https://github.com/SpiderLabs/ModSecurity
cd ModSecurity/
git submodule init && git submodule update --init --recursive
./build.sh && ./configure && make && make install

cd /
git clone --depth 1 https://github.com/SpiderLabs/ModSecurity-nginx.git
nginxVersion=$(nginx -v 2>&1 | egrep -o [0-9.]+) # Currently 1.28.3
wget https://github.com/nginx/nginx/releases/download/release-${nginxVersion}/nginx-${nginxVersion}.tar.gz
tar xzvf nginx-${nginxVersion}.tar.gz
cd nginx-$nginxVersion
./configure --with-compat --add-dynamic-module=/ModSecurity-nginx
make modules
cp objs/ngx_http_modsecurity_module.so /usr/share/nginx/modules/ngx_http_modsecurity_module.so


cat <<'EOF' > /etc/nginx/nginx.conf
user nginx;
worker_processes auto;
error_log /var/log/nginx/error.log notice;
pid /run/nginx.pid;

load_module modules/ngx_http_modsecurity_module.so;

include /usr/share/nginx/modules/*.conf;

events {
    worker_connections 1024;
}

http {
    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  /var/log/nginx/access.log  main;

    sendfile            on;
    tcp_nopush          on;
    keepalive_timeout   65;
    types_hash_max_size 4096;

    include             /etc/nginx/mime.types;
    default_type        application/octet-stream;

    # Load modular configuration files from the /etc/nginx/conf.d directory.
    # See http://nginx.org/en/docs/ngx_core_module.html#include
    # for more information.
    include /etc/nginx/conf.d/*.conf;

    server {
        listen       80;
        listen       [::]:80;
        server_name  _;
        root         /usr/share/nginx/html;

        # Load configuration files for the default server block.
        include /etc/nginx/default.d/*.conf;

        error_page 404 /404.html;
        location / {
          proxy_method POST;
          proxy_pass http://localhost;
          modsecurity on;
          modsecurity_rules_file /etc/crs4/modsecurity.conf;
          modsecurity_rules_file /etc/crs4/crs-setup.conf;
          modsecurity_rules_file /etc/crs4/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf;
          modsecurity_rules_file /etc/crs4/rules/REQUEST-901-INITIALIZATION.conf;
        }
    }
}
EOF

wget https://github.com/coreruleset/coreruleset/archive/refs/tags/v4.26.0.tar.gz
mkdir /etc/crs4
tar -xzvf v4.26.0.tar.gz --strip-components 1 -C /etc/crs4

cd /etc/crs4/
mv crs-setup.conf.example crs-setup.conf
wget https://raw.githubusercontent.com/owasp-modsecurity/ModSecurity-nginx/refs/heads/master/.github/nginx/modsecurity.conf
cp /ModSecurity/unicode.mapping /etc/crs4/
cd rules/
mv REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf.example REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf
nginx
tail -f /var/log/nginx/error.log

Then, from outside of docker, I ran this:

curl http://localhost:8080/ -H "Content-Type: application/xml" -i -X POST --data '<xml></xml> Testing modsec'

[airween]

Thanks for the detailed explanation.

tail -f /var/log/nginx/error.log

What did you exactly get in the error log then?

[ssigwart]

Sorry, I closed the window already, but it included body.xml:1: parser error : Extra content at the end of the document like in the initial issue comment. If you ran me to run it again, let me know.