Most vulnerabilities belong to a named product. You can look up the version and decide whether it is yours. A flaw in PHP does not sit still like that. PHP runs under a large part of the web, so the question stops being whether you run the affected software and becomes where, and the honest answer is usually: in more places than the asset list shows.
Both flaws are reachable without logging in, through a feature PHP enables by default: multipart upload handling and the session upload-progress mechanism. The attacker pushes the interpreter out of memory while it is still setting up the request, which leaves request data half-built, then leans on a later request that reuses the same worker while that half-built state is still trusted. The exact path changes with the PHP version and the server, and the research teams report it working on default settings.
What makes it slow to clean up afterwards is where it lands. Code runs as the web service account, so a foothold is useful straight away. The application barely executes, so its logs hold little. And PHP is baked into things no one manages as a web server, from content platforms to firewalls and routers, which is how the same flaw turns up on a box whose owner never thinks of it as PHP.