Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Multipart: data after the final boundary in a later chunk sets MULTIPART_DATA_BEFORE instead of MULTIPART_DATA_AFTER

Abierto
  • ¿Algo no está bien?
#3,695 1 comentario 0 reacciones 1 asignado Ver en GitHub

Los mantenedores suelen responder en 1 día

@airween ya está trabajando en esto.

Desde el 15/10/2026.

Evaluación

Este issue todavía no se ha evaluado.

Descripción

2.x 3.x bug

what

Both multipart parsers handle "data after the last boundary" in two places, and the two places set different flags.

When the epilogue data arrives in the same chunk as the closing delimiter, the parser sets the after flag:

  • v2: apache2/msc_multipart.c line 1382 (msr->mpd->flag_data_after = 1;)
  • v3: src/request_body_processor/multipart.cc line 1830 (m_flag_data_after = 1;)

When the epilogue data arrives in a later chunk, the early return at the top of the chunk processor sets the before flag instead:

  • v2: apache2/msc_multipart.c line 1158 (msr->mpd->flag_data_before = 1;, debug message "Ignoring data after last boundary")
  • v3: src/request_body_processor/multipart.cc line 1575 (m_flag_data_before = true;, same message)

The debug message in the second place already says "after", so this looks like a copy-paste slip that has been in both branches since the early-return guard was added.

where it is reachable

  • v2: modsecurity_request_body_store() calls multipart_process_chunk() once per stored chunk (apache2/msc_reqbody.c line 354), so a body whose closing delimiter ends one bucket and whose epilogue starts the next one takes the early-return path. Whether that split happens depends on how Apache delivers the body (chunked transfer, bucket sizes, proxy buffering), so the same request can yield different variable values on different deployments.
  • v3: Transaction::processRequestBody() creates one Multipart object and calls process() once with the whole buffered body (src/transaction.cc lines 775-777), so the early return never runs today. I confirmed this with a small harness: feeding the body through two appendRequestBody() calls still reaches the "bytes left" branch and sets MULTIPART_DATA_AFTER. The v3 line is dead code, but it should be fixed too so the two branches stay in sync and it does not bite if chunked processing is ever introduced.

effect (v2)

For a request whose body is delivered as ...--BOUNDARY--\r\n in one bucket and the epilogue in the next:

  • MULTIPART_DATA_AFTER stays 0, so a rule on it does not fire.
  • MULTIPART_DATA_BEFORE becomes 1, which is misleading in the audit log. MULTIPART_STRICT_ERROR still fires, since it includes both flags, so blocking with the recommended rule 200003 is unaffected.
  • The epilogue is never scanned for boundary-like lines, so it cannot affect MULTIPART_UNMATCHED_BOUNDARY. The same is true within a single chunk, so that part is at least consistent.

proposed regression test (v2)

SecRule MULTIPART_DATA_AFTER "!@eq 0" "id:1,phase:2,deny,status:403" and SecRule MULTIPART_DATA_BEFORE "!@eq 0" "id:2,phase:2,deny,status:402", body sent as two chunks:

  1. --0000\r\nContent-Disposition: form-data; name="a"\r\n\r\nx\r\n--0000--\r\n
  2. trailing garbage\r\n

Expected 403. By code reading the second chunk hits the early return and the request is answered 402 with "Ignoring data after last boundary (received 18 bytes)" in the debug log. I have not yet run this under Apache; the Perl regression framework sends the body in one piece, so the test needs a chunked request.

fix

Set the after flag on the early-return path in both branches. One-line change each, plus the test above for v2. Noticed while reviewing #3658; it is independent of that PR and predates it.

Lenguaje dominante
C++
Estrellas
9.8k
Forks
1.8k
Merge medio
1 d 1 h
PR fusionados (30 d)
13

Preparar el entorno

  • Sin Dockerfile ni archivo de Docker Compose
  • Tiene una plantilla de pull request
  • Sin guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de owasp-modsecurity/ModSecurity

Todos los issues de owasp-modsecurity/ModSecurity

Issues similares

Más issues de C++

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.