Re: [RFC] [Discussion] array_get and array_has functions

On Sun, Apr 5, 2026, at 10:22, Hans Krentel wrote: > > > > > On Sunday 05 April 2026 08:51:30 (+02:00), Rob Landers wrote: > > > On Sat, Apr 4, 2026, at 16:06, Barel wrote: > > > Hi, > > > > > > I would like to open the discussion on my proposal to add two small, focused array > > > functions for retrieving and checking nested array elements using dot notation. > > > > > > This is the link to the RFC: > > > https://wiki.php.net/rfc/array_get_and_array_has > > > > > > This is the link to the proposed implementation: > > > https://github.com/php/php-src/pull/21637 > > > > > > Thanks!! > > > > > > Carlos > > > > Hi Barel, > > > > Interesting! As dot-notation isn't used anywhere else, and I don't see it > > discussed as part of the RFC, how are developers to prevent injections of dots in user input? With > > SQL, we have parameters and escaping .... but I don't see any of that here. > > > > As an example: > > > > $user = [ 'data' => [...], 'password' => 'secret' ]; > > > > If the path is completely user-controlled (as in the examples given), then they can access > > sensitive information in the array. Even if it is prefixed, ie., "data.%s" -- an attacker > > can simply enumerate all possible keys and subkeys. > > > > As it stands, it appears to add a new vulnerability to PHP that will be unfamiliar with > > PHP developers -- unless they're using a framework that already does this sort of notation. > > I wouldn’t go that far, but I’d like to start by emphasizing that the dot notation > described here clearly does not provide a mechanism for escaping the dot. That’s probably a > shortcoming, but if any user-supplied string key poses a security risk, then PHP arrays are also > affected, and this vulnerability would be nothing new! (Rather, it would be to be expected.) > > -- hakre > My point is that this is different and distinct from regular array vulnerabilities and injections. $user['data'][$key] !== array_get($user['data'], $key, null); In the former 'some.key' is a full key; in the latter, it would access ['some']['key']. Further, the former could be a valid key, but there is no way to access it using the proposed RFC — Rob