Same here, though what stuck with me is that a firewall's admin PHP page was reachable from the internet at all, keep that on a mgmt VLAN.

▲ cowlevel 5 hours ago | parent [-]

it probably starts with a correct and safe authorization check, but this vulnerability happens before any user code runs, so every PHP page is vulnerable.

▲ bell-cot 4 hours ago | parent [-]

True-ish? If your firewall's admin page is internet-accessible, you have no excuse for not doing "bolted to bedrock" lockdowns of your web server config and your PHP config. Either of which could have blocked exploitation of the PHP vuln.

▲ cowlevel 4 hours ago | parent [-]

What's the right level of lockdown? Starting a page with "if not authorized, return 403" would've seemed adequate before this.

▲ bell-cot 3 hours ago | parent [-]

I'd suggest reading https://github.com/php/php-src/blob/master/php.ini-productio..., then doing a web search for "editing php.ini for maximum security".

Maybe compare with https://github.com/php/php-src/blob/master/php.ini-developme..., too.

Then similar for your web server (Apache, nginx, whatever).

EDIT: About your "would've seemed adequate before this" - I dug up a copy of a PHP v5.2 php.ini file (2-ish decades ago). That file begins thus:

   ;;;;;;;;;;;
   ; WARNING ;
   ;;;;;;;;;;;
   ; This is the default settings file for new PHP installations.
   ; By default, PHP installs itself with a configuration suitable for
   ; development purposes, and *NOT* for production purposes.
   ; For several security-oriented considerations that should be taken
   ; before going online with your site, please consult php.ini-recommended
   ; and http://php.net/manual/en/security.php.

	▲	cowlevel 2 hours ago \| parent [-]
		Zero of these recommendations have anything to do with the present vulnerability.