Re: [RFC] [Discussion] Hardening PHP against filter chain attacks
| From: | Sjoerd Langkemper | 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