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

Reply via email to