Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128199
Message-ID: <b868eb26-8598-48ac-a75a-870bc22db93a@tu-braunschweig.de>
Date: Wed, 23 Jul 2025 20:24:49 +0200
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: [PHP-DEV] Study on unsafe extract() usage
To: <internals@lists.php.net>
Content-Language: de-DE, en-US
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: quoted-printable
From: jannik.hartung@tu-braunschweig.de (Jannik Hartung)

Hey everyone,

as part of our security research, we studied the attack surface of the=20
extract() function when being called with user-controlled input. Calling=20
extract($_GET) allows an attacker to overwrite all variables in the=20
current scope, which could lead to vulnerabilities. We analyzed the use=20
of extract() in 28325 open source projects on GitHub looking for cases=20
where extract() is called with user-controlled input. extract() was=20
called 4923 times and 146 of those calls involved user-input. The=20
majority of findings were vulnerable due to being able to overwrite=20
superglobals.

We would like to share the findings and start a discussion on if and how=20
the risks of unsafe extract() usage could be reduced without breaking=20
backwards compatibility. The vulnerable extract() calls could be=20
exploited primarily by overwriting superglobals who's state is expected=20
to be immutable by the user like $_SESSION or $_SERVER or empty like=20
$_POST on a GET request. Similar to how changing $GLOBALS through=20
extract() is already forbidden, we propose to block overwriting all=20
superglobals through extract(). This would prevent most of the=20
vulnerabilities found in the dataset and we cannot think of a valid use=20
case for allowing this behavior. Here is where we rely on your feedback=20
and experience.

The semantics of every EXTR_ flag need to be documented, considered, and=20
understood properly as invalid usage could still leave the application=20
vulnerable. Calling extract() in the global scope is particularly risky=20
and the warning in the documentation could be expanded to describe the=20
risks in more depth. Using EXTR_IF_EXISTS in the global scope for=20
example would still allow overwriting superglobals instead of the=20
documented intended use case of defining a list of valid variables to=20
extract beforehand.

Since empty prefix strings are allowed, even EXTR_PREFIX_ALL would allow=20
to overwrite superglobals since SESSION would become <empty=20
prefix>_SESSION -> _SESSION. We propose to disallow the use of empty=20
prefix strings in extract() to prevent this. No such code pattern was=20
found in the dataset, but we wanted to mention it since an empty prefix=20
string looks like a bug when using the EXTR_PREFIX_* flags.

You can find more details in our paper [0], especially the case studies=20
of vulnerable usage scenarios and possible exploits in chapter 5. We=20
propose further possible mitigations in section 6.4 that wouldn't fit in=20
this email. If the proposed mitigations are not feasible, we hope the=20
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=20
topic. The proposed changes aim to improve the security of PHP=20
applications in the hopes to avoid breaking existing code.

Kind regards
Jannik Hartung

Institute for Application Security (IAS)
Technische Universit=C3=A4t Braunschweig

[0] https://www.ias.tu-bs.de/publications/extract-woot-2025.pdf