Repository navigation
Change session.upload_progress.enabled from default-on to default-off #24648
Description
Given this feature is pretty much unused in most code, and it clearly wasn't well-tested prior to this week, I think it makes sense for it to not be enabled by default 😄 (like what happened to my beloved short_open_tag 😞)
Activity
srayuth089 commentedon Oct 25, 2026
+1 with measured data — we ran the A/B on this exact knob in our lab (php:8.4.26-apache, single-worker prefork, public Chain D PoC, container restarted per trial):
session.upload_progress.enabled(An earlier 10-trial run on the same lab with the default gave 10/10, so the On-side rate is stable across 15 trials total; raw TSVs available.)
In other words the default isn't just "extra attack surface" in the abstract sense — it is the single config knob that determines whether the public pre-auth chains function at all, because every published chain (both CVEs) parks its OOM/stale-state work inside the rfc1867 upload-progress session window, which runs before application code.
One honest scoping note for the record, so the change isn't oversold: flipping this default off removes the upload-progress/session chains (the pre-auth entry point of all published chains for these two CVEs), but it does not by itself harden the multipart parser generally — the recent header-amplification technique (duplicate part headers → ~50x memory amplification, small bodies OOMing large
memory_limit) lives in the shared rfc1867 parsing path and still reaches OOM with the feature off. The 8.4.27+/8.5.12 patch addresses that side (unknown-header filtering + streamingpost_max_sizeenforcement).So: default-off = correct defense-in-depth decision, empirically the difference between a working pre-auth chain and a dead one, and it costs nothing to the (rare) applications that don't use the feature — they can opt back in with one ini line.