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

From: Date: Tue, 19 May 2026 10:58:59 +0000
Subject: Re: [RFC] [Discussion] Hardening PHP against filter chain attacks
References: 1  Groups: php.internals 
Request: Send a blank email to internals+get-130959@lists.php.net to get a copy of this message
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. • 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. • 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. • 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. Regards, Sjoerd Langkemper

« previous php.internals (#130959) next »