Re: [RFC] [Discussion] Query Parameter Manipulation Support

Hi On 2026-10-27 14:54, Máté Kocsis wrote:

1. I don't think QueryParamParsingOptions::$maxQueryStringLength is

necessary or useful to have. Checking the input length is easy to do manually (it's just a strlen() call) and I don't see a practical way to abuse the API with large input lengths alone: The API will not “blow up” inputs into considerably larger data structures, the input strings are mostly just “copied” over, not too different from e.g. str_replace().

I was also thinking a lot about whether this option is necessary to have. My main reason for including it was that people would otherwise easily forget to limit the input length, whereas the dedicated option enforces the limit everywhere. So the real question is whether QueryParams really cannot be abused via long strings, and whether $maxParamCount alone could mitigate those risks ? And now by thinking about it more, neither I could identify any specific vulnerability that would become possible by not enforcing the upper limit. In the previous iteration of the RFC, limiting the length was more useful, because parsing would have been a more resource intensive operation due to the requirements of the old "array API". The operations that are performed now during parsing are cheap, so as far as I can see, it's possible to get rid of this option if no one can come up with a good enough use-case.

Just after sending my previous reply, I realized that even if parsing long query strings isn't an expensive operation on its own, the rest of the operations supported by QueryParams may be. For example, sorting by long keys can cause significant slowdown. (To be fair: I haven't done any measurements yet). And in the light of the recent CVEs, increased memory consumption can cause troubles, so IMO an automatically enforced maximum length can still be useful.

Let me get this out of the way first, because I find it easy to give an answer here and it seems like this point is important to you with the follow-up. I'll reply separately on the other points. To the quoted point: Checking the length manually is easy to do and in some cases (e.g. when parsing the $_SERVER['REQUEST_URI']) the length is already bounded by a gateway in front FPM. With regard to “increased memory usage” bullet point (1) in my previous email was already in anticipation of the recent security releases and I checked with the others in the security team before giving my answer. The most important part is that an attacker is not able to exceed the (new) hard limit and more generally, an attacker should be unable to cause “superlinear” memory consumption. As I had mentioned in that earlier email, the input query string is mostly just “copied as is” with some overhead added for house keeping of each individual entry. Thus a query string consisting of just & is the extreme case. And that is already limited by a maximum number of parameters. Similarly sorting should also be O(n * log n) in the number of parameters, which is already limited during input time. Each individual comparison is bounded by key length, making this overall a O(l * log n) with l being the input length. If necessary a user can also verify the number of parsed elements themselves before sorting - but I don't expect that to be necessary, there are already much more expensive operations that are regularly performed on user input. Parsing itself should be linear in the length of the input string. Best regards Tim Düsterhus