Hey everyone,
as part of our security research, we studied the attack surface of the
extract() function when being called with user-controlled input. Calling
extract($_GET) allows an attacker to overwrite all variables in the
current scope, which could lead to vulnerabilities. We analyzed the use
of extract() in 28325 open source projects on GitHub looking for cases
where extract() is called with user-controlled input. extract() was
called 4923 times and 146 of those calls involved user-input. The
majority of findings were vulnerable due to being able to overwrite
superglobals.
We would like to share the findings and start a discussion on if and how
the risks of unsafe extract() usage could be reduced without breaking
backwards compatibility. The vulnerable extract() calls could be
exploited primarily by overwriting superglobals who's state is expected
to be immutable by the user like $_SESSION or $_SERVER or empty like
$_POST on a GET request. Similar to how changing $GLOBALS through
extract() is already forbidden, we propose to block overwriting all
superglobals through extract(). This would prevent most of the
vulnerabilities found in the dataset and we cannot think of a valid use
case for allowing this behavior. Here is where we rely on your feedback
and experience.
The semantics of every EXTR_ flag need to be documented, considered, and
understood properly as invalid usage could still leave the application
vulnerable. Calling extract() in the global scope is particularly risky
and the warning in the documentation could be expanded to describe the
risks in more depth. Using EXTR_IF_EXISTS in the global scope for
example would still allow overwriting superglobals instead of the
documented intended use case of defining a list of valid variables to
extract beforehand.
Since empty prefix strings are allowed, even EXTR_PREFIX_ALL would allow
to overwrite superglobals since SESSION would become <empty
prefix>_SESSION -> _SESSION. We propose to disallow the use of empty
prefix strings in extract() to prevent this. No such code pattern was
found in the dataset, but we wanted to mention it since an empty prefix
string looks like a bug when using the EXTR_PREFIX_* flags.
You can find more details in our paper [0], especially the case studies
of vulnerable usage scenarios and possible exploits in chapter 5. We
propose further possible mitigations in section 6.4 that wouldn't fit in
this email. If the proposed mitigations are not feasible, we hope the
raw study results could be of use for further discussion on their own.
We are looking forward to your feedback and any discussion on this
topic. The proposed changes aim to improve the security of PHP
applications in the hopes to avoid breaking existing code.
Kind regards
Jannik Hartung
Institute for Application Security (IAS)
Technische Universität Braunschweig
[0] https://www.ias.tu-bs.de/publications/extract-woot-2025.pdf
