The PHP CVE impacted you, too
23 Oct 2026
Even if you didn’t program any of your applications in PHP, you were impacted by PHP CVE-2026-109618 & CVE-2026-109619, because it’s time to go look at how your vendors managed it. After all, they’ll be handling similar attacks against whatever programming language you do use.
What to know if you do not use PHP
Maybe you host Java, .NET, Python, Ruby, NodeJS, etc. applications on a hyperscaler cloud provider’s managed platform – AWS Elastic Beanstalk, Azure App Service, or GCP App Engine, perhaps. The exciting thing is that they patch the operating system and the programming language. But will they patch yours, specifically? It’s worth researching.
- Microsoft blog: “Critical PHP Security Release: What It Means for Azure App Service”
- If you use PHP Azure App Service on Linux, they mostly fixed it promptly.
- Takeaway: Hooray for managed services!
- However, if you had your Azure App Service resources set in “Change is good; you go first” (“Extended” or “Standard” instead of “Latest”) update-timing mode, then it wouldn’t have been all that promptly.
- Takeaway: Prepare to have to flip settings on all your resources’ configuration settings, and then flip them all back again to whatever they were before after the crisis has passed. And know how long it would take to do so, because you’ll need to compare that against the vendor’s promises. (Even if you’ve got a well-managed infrastructure-as-code program, maybe you segmented it into a bunch of different source control repositories specifically to prevent people who haven’t had enough coffee from breaking things on every enterprise resource all at the same time with a single typo. So you might have this something that takes a few hours of toil, by design.) You’ll want to know how it compares against the vendor’s timelines, so you can decide whether to flip the switch or just wait, etc.
- If you were using a configuration that they were still willing to run but had deprecated to “end of life,” like PHP Azure App Service on Windows, they didn’t bother patching you and left you to do it.
- Takeaway: Get your monitoring and governance house in order. Do you know exactly which cloud resources are out of compliance with what’s fully supported by the vendor? Do the people at your company responsible for fixing it know? How soon are they going to get to that? And if not soon, are they ready to have to be the one wearing the pager to personally do the next patch that they could’ve otherwise let the vendor do?
- If you use PHP Azure App Service on Linux, they mostly fixed it promptly.
- Google blog: “Responding to core PHP vulnerabilities CVE-2026-109618 and CVE-2026-109619” & Amazon blog “Release: Elastic Beanstalk Amazon Linux 2023 PHP platform updates on October 21, 2026”:
- I didn’t see anything as clearly and helpfully worded in terms of “we’re not covering this; that’s your problem” as I saw on Azure, but if you were on less than PHP 8.2, you were in the same boat as the PHP Azure App Service on Windows folks – GCP & AWS weren’t going to fix that for you. (AWS really didn’t even spell anything helpful out at all. At least Google bothered to say “PHP 8.1 & under – this means you.”)
- Takeaway: Get your monitoring and governance house in order. See above. Do you definitely know if your company’s got any poorly-configured GCP or AWS resources?
- I didn’t see anything as clearly and helpfully worded in terms of “we’re not covering this; that’s your problem” as I saw on Azure, but if you were on less than PHP 8.2, you were in the same boat as the PHP Azure App Service on Windows folks – GCP & AWS weren’t going to fix that for you. (AWS really didn’t even spell anything helpful out at all. At least Google bothered to say “PHP 8.1 & under – this means you.”)
- GitHub Runner Images issue 15027: Ooof, yikes. The PHP runtime in vendor-managed GitHub Actions runners and Azure Pipelines (ADO) agents aren’t being expedited – it looks like they’re taking about a week to actually get up-to-date in real runtimes, from the day that the team updated their image. Of course, such vendor-hosted CI/CD runtimes are usually pretty ephemeral (except in the case of stateful Managed DevOps Pools on ADO), so hopefully no one will hack any given CI/CD runtime from the outside during the brief time it exists. However, if either of these CVEs happened to be the kind of vulnerability that can be exploited during, say, a build process by dependency installation the way Sha1-Hulud variants infected CI/CD runtimes, well, you wouldn’t need to notice the machine exists from the outside. You could just let the workload it’s running serve as the attack vector. I get that they want to honor “change is good; you go first” customer concerns and don’t have a risk-tolerance feature flag the way Azure App Service does, for example, but simply letting “the usual weekly change cadence” be the release timeline for the patch seems a little extreme.
Also, speaking of seeing how vendors did, I’ve got a neighbor whose business uses Lightningbase for managed Wordpress hosting, and they seemed patched pretty promptly, so shoutout to a Minnesota company for that. I mean, hopefully all the major managed Wordpress & managed Drupal hosts did that, but, ope, I’m always happy to see Minnesota just quietly gittin ‘er done. (They say there’re just 3 things Minnesotans like most – 1. Minnesota, 2. Minnesotans, & 3. Hearing how great Minnesota is.)
How to see if you do use PHP
Update: added this section as bonus content that seemed vaguely relevant, and because I didn’t feel like thinking of a title for a new post.
I’m no expert, but I did a quick Google search, and here’s what I found. (One note: a lot of enterprises don’t seem to try to go this alone – they have a vulnerability management 3rd-party vendor’s daemon/agent installed on all their servers, and it’s its job to tell them if they got hit by a given CVE.)
Consult your application or service catalog
Hopefully, your enterprise has some sort of central catalog where details like the tech stack for every application you run on servers, endpoints, or in CI/CD pipelines is catalogued.
It might be out of date, but it can’t hurt to look around for PHP or for known things that tend to use PHP (like Wordpress, Laravel, or Drupal).
Ask about cloud resource configurations
Hopefully, there’s someone at your enterprise who can see every single resource ever provisioned in any cloud ever.
- Ask them if any managed web hosting platforms like AWS Elastic Beanstalk, Azure App Service, or GCP App Engine, are configured for running PHP.
- For example, a KQL query against all
microsoft.web/sitesAzure resources, looking at theirsiteConfig.linuxFxVersionand/orsiteConfig.windowsFxVersion, could help turn up indicators of PHP pretty fast on Azure App Service.- (Many thanks to a colleague for this one!)
- For example, a KQL query against all
- Ask them for contact information for the owners of other cloud resources related to more arbitrary images and workloads (e.g. container registries, VM image registries, container runtimes & orchestrators, VM runtimes & orchestrators), so that you can follow up one-by-one and check inside them.
- Bonus: The team that can look at all cloud resources’ management-plane-level configurations also might be able to make an educated guess, even for such things, if, say, someone used some sort of cloud provider marketplace “extension” or something at cloud-resource-provision-time. For example, maybe the cloud resource provisioning team provisioned a given Azure VM to use some sort of PHP/Wordpress/etc. “VM extension,” and can save you the trouble of reaching out to the VM’s owner, because they can already tell you that PHP is on that VM. (This doesn’t help figure out which VMs don’t have PHP, but it can be a faster way of figuring out some that do.)
Actually inspecting VMs and endpoints
I don’t personally know, but Googling around, I got these top links:
- PHP2Shell: two critical PHP RCEs, and how to tell if you’re affected – Maze
- How are you figuring out which servers are running vulnerable PHP after this week’s critical patch? : r/sysadmin
- How do we scan to see if an attacker got in before we could take down websites? : r/PHP
- PHP emergency release drops today. How are you finding the PHP you don’t know you’re running? : r/sysadmin
- How do I know if any of my servers are running PHP? : r/SelfHosting
- reliable way to detect if node runs PHP : r/f5networks
- (No idea if this itself is true community service or if it’s a honeypot that’s helping hackers find easy targets, but it did successfully detect that www.irs.gov runs on Drupal, for example, so anyway, BE CAREFUL if playing with it, and probably not your best bet, but intriguing)
And here are 3 AI summaries to questions I asked Google:
LLM summary 1 of 3
Question:
“How to tell if a server or endpoint is running PHP?”
Here was its response:
- (click expander icon at left – it’s a rightward-facing triangle – if its answer below is not showing up)
To tell if a server or an endpoint is running PHP, you can use several techniques depending on whether you have internal access (server command line) or external access (testing an endpoint over the internet).
Internal Access (You have access to the server)
If you can log into the server via SSH or a terminal, you can directly check for the PHP process or binary:
- Check the CLI version: Run php -v. This tells you if PHP is installed for the Command Line Interface (CLI). (Note: Web servers often use a separate configuration or binary than the CLI). [1, 2]
- Check running processes: Look for running PHP processes (like PHP-FPM, Apache’s mod_php, or the built-in server) using:
ps aux | grep php
Use code with caution.
- Check listening sockets: See what service is handling web requests (usually port 80 or 443) by running:
sudo lsof -i :80
\# or
sudo netstat -plnt
Use code with caution.
Look for names like php-fpm, apache2, or nginx configured to proxy to a FastCGI PHP backend.
External Access (You only have the URL/Endpoint)
If you are inspecting a remote endpoint from the outside, you have to look for specific behavioral clues. Because many servers actively hide this information for security reasons, these methods are not always 100% foolproof.
1. Inspect HTTP Response Headers
Web servers often expose the language or engine powering them in the response headers. You can check these using the Network tab in your browser’s Developer Tools, or via a terminal tool like curl: [1]
curl -I <https://example.com>
Use code with caution.
Look for these specific headers:
- X-Powered-By: PHP/8.x.x (Directly states PHP is running)
- Server: Apache or Server: Nginx (Indicates the web server, which commonly hosts PHP)
2. Analyze the URL Extensions
Check the file extensions in the website’s paths or API routes:
- Direct files ending in .php (e.g., https://example.com or login.php) mean the server is actively handling PHP files.
- Caveat: Many modern PHP applications use routing engines (like Laravel or Symfony) that hide the .php extension entirely.
3. Test Session Cookie Names
When PHP starts a user session, it defaults to a unique cookie name unless a developer explicitly changes it. Inspect the site’s cookies in your browser’s dev tools or curl response.
- Look for a cookie named PHPSESSID. If this cookie exists, the backend is almost certainly running PHP.
4. Trigger Known Errors or Appended Queries
Some older or default PHP installations respond to specific URL behaviors:
- Adding queries: Historically, appending ?=PHP95B3415D-2304-469d-BB3F-10656D18B14F (the PHP Logo GUID) to a URL would output a graphic if exposed, though this is largely disabled in modern setups.
- Forcing an error: Sending malformed data to an endpoint (like changing an expected integer ID to a string, or adding brackets like ?id[]=test) might trigger a database or runtime crash. If error display is turned on, the resulting stack trace or error layout may explicitly mention PHP file tracks (e.g., /var/www/html/index.php).
If you’d like to narrow this down, let me know:
- Do you have SSH/terminal access to this server, or are you looking at it from the outside?
- Are you troubleshooting a specific application (like WordPress, Laravel, or a custom API)?
- Are you checking this to audit for security updates or patch vulnerabilities?
LLM summary 2 of 3
Question:
“What about if it might be under the hood of various CLI tools, the way the Terraform CLI has Go under the hood?”
Here was its response:
- (click expander icon at left – it’s a rightward-facing triangle – if its answer below is not showing up)
When a Command Line Interface (CLI) tool is built “on top” of PHP, it usually means the tool itself is a PHP script packaged into an executable format. Unlike Go, Rust, or C++, PHP does not compile into native machine code binary by default.
If a CLI tool is running PHP under the hood, it leaves behind very distinct technical fingerprints. You can figure out if a tool is built on PHP using the following methods:
1. Check for the Composer Signature
Just as Node.js uses package.json and Rust uses Cargo.toml, PHP CLI tools almost universally rely on Composer for dependency management.
- Look inside the tool’s installation directory (often found in /usr/local/bin/, ~/.config/, or ~/.composer/vendor/bin/).
- If you see folders named vendor/, or files named composer.json and autoload.php, it is definitively a PHP application.
2. Inspect the Binary File Type (The file command)
True compiled languages like Go output a native binary (like an ELF executable on Linux or a Mach-O binary on macOS). A PHP CLI tool is often just a text script with a hidden interpreter instruction, or a compressed archive wrapper called a Phar (PHP Archive).
Run the file command on the CLI tool’s executable path:
file $(which your-cli-tool)
Use code with caution.
Look for these telltale outputs:
- PHP script, ASCII text executable: This means the “binary” is actually just a plain text PHP file with a #!/usr/bin/env php shebang at the very top.
- PHP php file, … or references to a Zip archive: Many professional PHP CLI tools (like composer itself, wp-cli, or psalm) are distributed as .phar files. The file command or an inspection of the binary’s hex headers will reveal it is a PHP Archive.
3. Force a PHP Error Trace
Compiled binaries handle crashes via core dumps or structured language runtimes (like Go’s panic stack trace). PHP has a highly recognizable error output structure.
- Try intentionally breaking the tool by feeding it missing arguments, or corrupting its internal files if you are analyzing it in a sandbox.
- If it crashes and outputs references to .php file paths, lines of code, or terms like Fatal error:, Uncaught Exception, or thrown in /path/to/tool, it’s PHP.
4. Check for Bundled Runtimes (Static Compilation)
While rare, some modern PHP CLI tools use projects like static-php-cli or FrankenPHP to bundle the entire PHP interpreter and the script into a single, self-contained binary file (mimicking a Go binary).
Even when compiled this way, you can extract strings from the binary to find the underlying language:
strings $(which your-cli-tool) | grep -i "php"
Use code with caution.
If the tool is a bundled PHP runtime, this command will print out internal PHP configuration strings, standard PHP function names (like implode, explode, serialize), or PHP extension identifiers.
Are you trying to inspect a specific CLI tool right now? If you share its name or run file on it and tell me the output, I can tell you exactly what it’s built on.
LLM summary 3 of 3
Question:
“How to tell if an endpoint (e.g. cli tool under the hood, or occasional localhost development) is running or can run php? (cve)”
Here was its response:
- (click expander icon at left – it’s a rightward-facing triangle – if its answer below is not showing up)
To determine if a system or hidden CLI tool is running or capable of executing PHP—especially in light of the PHP2Shell vulnerabilities (CVE-2026-109618 & CVE-2026-109619)—you can use the following methods to inspect local binaries, active background processes, and tool components. [1]
1. Check for Active or Idle Running PHP Processes
If a CLI tool or local stack runs PHP silently under the hood, a PHP engine instance or master process will spawn in the background. Look for them directly via your OS process manager:
- Linux / macOS: Open your terminal and check for active php, php-fpm, or php-cgi processes:
ps aux | grep -i php
Use code with caution.
- Windows: Open Command Prompt or PowerShell and check for active php.exe or php-cgi.exe executables:
Get-Process -Name \*php\*
Use code with caution.
2. Check if PHP is in the System Environment (Can Run)
Even if a background process isn’t running 24/7, a CLI tool might invoke PHP on demand if the binary is present on your system path.
- Run the version check:
php -v
Use code with caution.
- Locate where it is hiding:
which php # Linux/macOS
whereis php # Linux/macOS
where php # Windows (Command Prompt)
Use code with caution.
Note: If the system returns a version or path, any tool calling shell commands can invoke PHP. To stay safe from the PHP2Shell flaws, your version must be at or above 8.5.12, 8.4.27, 8.3.36, or 8.2.35. [1, 2]
3. Check for Bundled PHP Binaries inside CLI Tools
Many modern CLI tools and local development environments (like older versions of LocalWP, DDEV, or custom Electron/Node apps) bundle a standalone PHP binary inside their own execution folder so they don’t rely on your global system path. [1]
- Scan the tool’s directory: Search inside the tool’s local node_modules, vendor, .bin, or core installation folder for hidden executables: [1]
find /path/to/cli-tool-folder -name "\*php\*"
Use code with caution.
- Inspect package.json or Cargo.toml / go.mod: If the CLI tool is open-source or built on JavaScript/Rust/Go, inspect its source repository or configuration files. Look for dependencies that invoke PHP wrapper commands or package standalone runtimes. [1]
4. Inspect Local Network Endpoints (Localhost Development)
If you have an occasional development server running on localhost, 127.0.0.1, or Docker containers, you can inspect their headers: [1]
- Query the endpoint with curl:
curl -I <http://localhost:8080>
Use code with caution.
- Look for PHP signatures: Check the response for the following HTTP headers:
o Server: Apache/… (mod_php)
o X-Powered-By: PHP/…
o Set-Cookie: PHPSESSID=… [1, 2]
5. Automated Local Auditing
If you manage multiple endpoints or have an extensive directory structure, you can use local auditing tools to sweep for PHP assets:
- Using a Software Inventory script: Use an automation tool or simple local script to scan for all files ending in .php or named php across common application paths (/var/www, /opt, C:\Program Files, etc.). [1]
If you are investigating a specific tool or local stack, let me know the name of the CLI tool or development environment you suspect is using PHP, and I can give you the exact steps to check it.
