On Thu, Aug 1, 2024 at 1:37 PM Yann Ylavic <ylavic....@gmail.com> wrote: > > On Thu, Aug 1, 2024 at 5:51 PM Eric Covener <cove...@gmail.com> wrote: > > > > But does it leave the splitting problem with decoded %3F? > > Yeah but I'm not sure that it's _our_ problem, a "proxy:" r->filename > does never contain the query-string in the first place, so any '?' in > there (hence in SCRIPT_FILENAME) is part of the actual file path > (which we'd encode for proxying any other scheme than fcgi). And the > '?' will be in SCRIPT_NAME/PATH_INFO/etc too. If the scripts want the > decoded uri-path they have to be consistent and consider that > SCRIPT_FILENAME is nothing else than a path (no query-string, which is > in ... QUERY_STRING).
Just to recap, FPM doesn't want to find the query it in SCRIPT_FILENAME, it wants to toss it away because it used to accidentally end up in there (via mod_rewrite?) But this is where the mismatch between what we've walked/mapped/authorized and what will be executed is. What about, for now, just failing it here as if it were a ctl? If more users come out of the woodwork, at least we will have some concrete examples of how it can currently end up this way w/o malicious input.
