REPRO-2026-00228: Verified Repro With Script Download

A misconfigured charset_map directive with utf-8 in the first column (source charset) causes nginx to create wrong-format single-byte conversion tables. When a subsequent HTTP request triggers the charset filter's recode_from_utf8() path, the 256-byte single-byte table is cast to u_char ** and dereferenced as a pointer array (table[n >> 8]), reading garbage bytes as a memory address and crashing the worker process with SIGSEGV (signal 11). The upstream fix (commit 29c23ad846787e8baa1390b2edca479eb63ea8d7) adds a configuration-time validation that rejects charset_map with utf-8 in the first column, preventing the invalid configuration from ever being loaded.

• Package/Component affected: nginx src/http/modules/ngx_http_charset_filter_module.c (the ngx_http_charset_filter_module)
• Affected versions: nginx versions prior to commit 29c23ad846787e8baa1390b2edca479eb63ea8d7 (tested on nginx/1.31.3 at parent commit 8f3465ac7f02b0ae86304e1be4ed319abb9d2edb)
• Risk level: High — any attacker who can send an HTTP request to a server configured with the vulnerable charset_map directive causes an immediate worker process crash (denial of service). The crash occurs on every request to the affected location.
• Consequences: Repeated requests cause continuous worker respawns and crashes, degrading server availability. The crash is deterministic and triggered by a single HTTP GET request.

Impact Parity

• Disclosed/claimed maximum impact: Denial of Service (DoS) via NULL pointer dereference / segfault in nginx worker process when processing requests with the misconfigured charset_map.
• Reproduced impact from this run: DoS confirmed — nginx worker process crashes with SIGSEGV (signal 11, core dumped) on every HTTP request to the affected location. The worker is killed immediately when processing response body data containing non-ASCII bytes through the recode_from_utf8() code path.
• Parity: full — the reproduced segfault/DoS matches the claimed impact exactly.
• Not demonstrated: No code execution or privilege escalation was claimed or observed; the impact is purely a DoS crash.

Root Cause

The charset filter module supports two table formats:

1. Single-byte tables (256 bytes): used when neither charset in a charset_map is UTF-8. Each byte maps directly: table[src_byte] = dst_byte.
2. UTF-8 multi-byte tables (256 × NGX_UTF_LEN = 1024 bytes for src2dst, and an array of u_char * pointers for dst2src): used when the destination charset (second column) is UTF-8.

The bug occurs because ngx_http_charset_map_block() decides which table format to allocate based solely on whether value[2] (the destination/second column) is "utf-8". When utf-8 appears in value[1] (the source/first column) and the destination is a single-byte charset (e.g., windows-1251), the code takes the else branch and allocates 256-byte single-byte tables for both src2dst and dst2src.

During request processing, the charset filter's body filter calls ngx_http_charset_recode_from_utf8() when ctx->from_utf8 is true (i.e., the source charset is UTF-8). This function casts ctx->table (the 256-byte buffer) to u_char **table and dereferences table[n >> 8] as a pointer:

table = (u_char **) ctx->table;   // 256-byte buffer cast to pointer array
...
n = ngx_utf8_decode(&src, len);   // decode UTF-8 sequence to codepoint
if (n < 0x10000) {
    p = table[n >> 8];            // reads 8 bytes at offset (n>>8)*8 as a pointer
    if (p) {
        c = p[n & 0xff];          // dereferences the garbage pointer → SIGSEGV

For example, with Cyrillic а (U+0430, encoded as 0xD0 0xB0), ngx_utf8_decode returns n = 0x0430, so n >> 8 = 4. table[4] reads bytes 32–39 of the 256-byte buffer (values 32,33,34,35,36,37,38,39), which on little-endian 64-bit forms the garbage pointer 0x0000002726252423. Since this is non-NULL, p[n & 0xff] dereferences 0x0000002726252453 — an unmapped address — causing SIGSEGV.

Fix commit: 29c23ad846787e8baa1390b2edca479eb63ea8d7 — "Charset: disabled charset_map with utf-8 in the first column". The fix adds a check in ngx_http_charset_map_block() that rejects the configuration at parse time:

if (ngx_strcasecmp(value[1].data, (u_char *) "utf-8") == 0) {
    ngx_conf_log_error(NGX_LOG_EMERG, cf, 0,
                       "\"charset_map\" with \"utf-8\" charset "
                       "should be given in the second column");
    return NGX_CONF_ERROR;
}

Reproduction Steps

1. Script: bundle/repro/reproduction_steps.sh
2. What the script does:
   • Locates pre-built nginx binaries from the project cache (vulnerable build at commit 8f3465ac7 and fixed build at commit 29c23ad84), with a fallback to clone-and-build from source.
   • Creates an HTML file containing real UTF-8 multi-byte characters (Cyrillic а, б, в — bytes 0xD0 0xB0, etc.) to trigger the non-ASCII code path.
   • Vulnerable test (×2): Writes an nginx config with charset_map utf-8 windows-1251 { } + charset windows-1251 + source_charset utf-8, starts nginx as a real TCP listener, sends an HTTP GET request via curl, and checks the error log for exited on signal 11 (SIGSEGV).
   • Fixed test (×2): Writes the same config and runs nginx -t to verify the config is rejected with the patch's error message.
   • Config acceptance contrast: Verifies the vulnerable binary accepts the config (exit 0) while the fixed binary rejects it.
   • Writes bundle/repro/runtime_manifest.json with proof artifacts.
3. Expected evidence: Two vulnerable attempts showing worker process N exited on signal 11 (core dumped) in the error log, and two fixed attempts showing "charset_map" with "utf-8" charset should be given in the second column.

Evidence

Log file locations

• bundle/logs/vuln_error_1.log — Vulnerable attempt 1 error log (segfault)
• bundle/logs/vuln_error_2.log — Vulnerable attempt 2 error log (segfault)
• bundle/logs/vuln_conf_1.conf / vuln_conf_2.conf — Vulnerable nginx configs
• bundle/logs/fixed_test_1.log / fixed_test_2.log — Fixed version config rejection
• bundle/logs/vuln_config_accept.log — Vulnerable config acceptance
• bundle/repro/runtime_manifest.json — Runtime evidence manifest

Key excerpts

Vulnerable worker segfault (attempt 1):

2026/07/04 18:20:50 [alert] 30827#0: worker process 30829 exited on signal 11 (core dumped)

Vulnerable worker segfault (attempt 2):

2026/07/04 18:20:57 [alert] 30847#0: worker process 30849 exited on signal 11 (core dumped)

Fixed version config rejection:

nginx: [emerg] "charset_map" with "utf-8" charset should be given in the second column
nginx: configuration file ... test is successful → test failed (exit 1)

Vulnerable version config acceptance:

nginx: the configuration file ... syntax is ok
nginx: configuration file ... test is successful (exit 0)

Environment

• nginx/1.31.3 built with --without-http_rewrite_module --without-http_gzip_module --with-cc-opt='-g -O0'
• Vulnerable commit: 8f3465ac7f02b0ae86304e1be4ed319abb9d2edb (parent of fix)
• Fixed commit: 29c23ad846787e8baa1390b2edca479eb63ea8d7
• gcc 15.2.0, Linux x86_64

Recommendations / Next Steps

1. Apply the upstream fix (commit 29c23ad846787e8baa1390b2edca479eb63ea8d7) to reject charset_map with utf-8 in the first column at configuration parse time.
2. Audit existing configurations for any charset_map directives using utf-8 as the source charset and remove or correct them.
3. Add a regression test that verifies nginx -t fails when charset_map utf-8 <charset> { } is present.
4. Consider defensive coding in recode_from_utf8() to validate table format before casting, as defense-in-depth against similar misconfigurations.

Additional Notes

• Idempotency: The script uses randomized port bases to avoid TCP TIME_WAIT conflicts between consecutive runs. Verified to pass twice consecutively with exit code 0.
• Ticket config note: The ticket's exact map entry D0B0 E0 (a 2-byte hex value) is rejected even in the vulnerable version because the single-byte parsing path (else branch in ngx_http_charset_map()) requires values ≤ 255. The vulnerability is triggered with any valid single-byte map entry (e.g., C0 E0) or even an empty charset_map block (charset_map utf-8 windows-1251 { }), since the table format mismatch occurs regardless of the entries.
• Two crash paths: The charset_map utf-8 <non-utf8> misconfiguration affects two request-time code paths:
  • recode_to_utf8 (when charset utf-8; source_charset <non-utf8>;): performs an out-of-bounds read at table[*src * NGX_UTF_LEN] on the 256-byte buffer, causing response corruption ("zero size buf" alert) and connection failure.
  • recode_from_utf8 (when charset <non-utf8>; source_charset utf-8;): casts the 256-byte buffer to u_char ** and dereferences table[n >> 8] as a pointer, causing a reliable SIGSEGV.
  • The reproduction uses the recode_from_utf8 path for its deterministic crash behavior. Both paths are eliminated by the same fix.