Re: [RFC] [Discussion] Hardening PHP against filter chain attacks

Hi, On Tue, May 19, 2026 at 1:02 PM Sjoerd Langkemper <sjoerd-php@linuxonly.nl> wrote: > I made some updates to the PHP RFC: Limit maximum number of filter chains > > <https://wiki.php.net/rfc/limit-maximum-number-of-filter-chains>. > > Any more opinions on this? I am currently thinking about these specifics: > > - Set a limit of at most 16 filters in a php://filter URL. This is > quite a high limit and won't prevent all attacks, but also has a negligable > chance of breaking legimitate functionality. > > This sounds reasonable as a default. > > - Start with raising a deprecation warning, and in a later version > give an actual error. This is technically a BC break, and it can't hurt to > follow the proper path for this. > > This might be a bit safer in terms of BC. > > - Hardcode the limit, don't provide a INI setting. I think it is > unlikely that people want to change this limit. I think it is acceptable to > require recompilation to change the limit. > > There should be some way how to change the limit. Might be worth to explore if it could be through stream context option. > > - Raise a warning and return false, instead of throwing an exception. > This is how stream functions currently work. It is not pretty, but it is > consistent. > > It should use the new stream errors that got just approved and will get soon merged. Kind regards, Jakub