Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta
#3,695 1 commento 0 reazioni 1 assegnatario Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@airween ci sta già lavorando.

Dal 15/10/2026.

Valutazione

Questa issue non è ancora stata valutata.

Descrizione

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.

Lingua principale
C++
Stelle
9.8k
Fork
1.8k
Merge medio
1g 1h
PR unite (30g)
13

Preparare l'ambiente

  • Nessun Dockerfile né file Docker Compose
  • Ha un modello di pull request
  • Nessuna guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di owasp-modsecurity/ModSecurity

Tutte le issue di owasp-modsecurity/ModSecurity

Issue simili

Altre issue su C++

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.