Research

When a PHP Web Worker Reads, Writes and Queries: What an EDR Sensor and Native Logs Recorded on Windows and Ubuntu

On one temporary Windows lab host and one temporary Ubuntu lab host on 2026-10-21, a PHP web worker we controlled read a file, wrote a file and inserted a database row. This page reports what the enterprise EDR sensor under test and the hosts' own logs recorded, and how far those records tie each action back to the PHP worker.

Sennin Security Labsv1.1October 22, 202611 min read

On 2026-10-21, PHP released fixes for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. CISA published an alert the same day. It states: "While CISA has not observed exploitation of these vulnerabilities as of the time of publication, they pose a risk to organizations if left unpatched." As of a check of CISA's Known Exploited Vulnerabilities (KEV) catalog at 10:10 AM PT on 2026-10-27 (catalog version 2026.10.26), both CVE-2026-109618 and CVE-2026-109619 are listed; CISA added both to the catalog on 2026-10-26. CVE-2024-4577, an older PHP flaw affecting PHP running in CGI mode on Windows, is listed in KEV (added 2024-06-12).

If an attacker gains code execution inside a PHP web worker, the attacker acts with that worker's privileges: reading files, writing files and querying databases the worker can reach. We asked a narrow question. When a PHP worker does those three things, what does endpoint telemetry record, and can those records be tied back to the PHP worker? EDR (endpoint detection and response) is security software that watches each computer and records what programs do. The product is not named.

The alert result is not a detection or prevention claim. This page makes no detection, prevention, coverage, customer, product-comparison or scoring claim.

Results by operating system

The two runs are scored separately. The Windows run had two witnesses; the Ubuntu run had one. The table keeps them apart.

Only Windows and Ubuntu were tested. A third operating system in the study plan, a different Linux distribution, has not been tested yet; its result is open. The Ubuntu results do not carry over to it, and this page states no result across three operating systems.

Disclosures

1. SSS did not exploit CVE-2026-109618, CVE-2026-109619, or CVE-2024-4577. We measured whether endpoint telemetry records a PHP worker performing file and database access after a controlled local trigger.
2. The lab used a benign, lab-written PHP script, identical on both hosts, as a stand-in for attacker code running inside the PHP worker. It reads one marker file, writes one marker file and inserts one database row, and it answers only requests from the same host.
3. During package install, the operating system's needrestart briefly restarted the enterprise EDR sensor (~18.6 seconds). That gap ended before the process-create control and before all three actions; those steps were recorded after the sensor was back online.
4. Each host was temporary and was used for one run.

Environment

Tested against a commercial EDR platform; vendor not named.

• Windows: one temporary Windows lab host running the PHP 8.4 built-in web server, listening only on the host's own loopback address. The native witness was the host's security process-creation log, with the PHP server's web-access log alongside it.
• Ubuntu: one temporary Ubuntu lab host running a PHP 8.3 PHP-FPM worker behind a local web server, listening only on the host's own loopback address. The planned native witness was the operating system's audit log, with the web server's access log alongside it.
• On both hosts, the marker files sat outside the web root, and the database was a local SQLite file.
• Terms: PHP-FPM is PHP's FastCGI process manager, which runs pools of PHP worker processes behind a web server. needrestart is an operating-system tool that restarts services after software packages are updated.

Method and commands

Each run used a fresh unique token. First, short positive controls started a process with the token on its command line and wrote a token-named file, so that each witness's recording could be checked before the actions. Then three actions were triggered by a web request from the same host: read a marker file (A), write a new marker file (B) and insert a row in a local SQLite database (C). Host-side checks confirmed each result.

The study's attribution bar asks whether a witness sealed a record that names the PHP worker together with the marker file path or the SQL marker string. A record of the web request alone does not meet that bar.

# The trigger: one same-host web request per action (identical form on both hosts)
curl -sS "http://[LOOPBACK]:8080/marker.php?action=A&token=[RUN-TOKEN]"   # A: read a marker file
curl -sS "http://[LOOPBACK]:8080/marker.php?action=B&token=[RUN-TOKEN]"   # B: write a new marker file
curl -sS "http://[LOOPBACK]:8080/marker.php?action=C&token=[RUN-TOKEN]"   # C: insert a SQLite row

Bracketed tokens are redactions.

// Excerpt of the lab-written stand-in script (action B). It has no exploit code, no network calls and no shell execution.
  case 'B':
    $f = $base.$sep.'markers'.$sep.'write-'.$token.'.txt';
    $d = 'WRITE-'.$token."\n";
    if (@file_put_contents($f, $d) === false) { http_response_code(500); $out['result'] = 'write-failed'; break; }
    $out['result'] = 'write-ok'; $out['sha256'] = hash('sha256', $d); break;

What was recorded

Observed on Windows. On one temporary Windows lab host, a PHP built-in web worker we controlled was told, by a same-host web request, to read a marker file outside the web root, write a new marker file, and insert a row in a local SQLite database. Host proofs confirm each action completed with the run's marker token. Before those actions, a short process-create control that put a unique token on the command line was recorded by both the enterprise EDR sensor under test and the host's native security process-creation log. For each of the three actions, both witnesses recorded a token-matched local web-trigger process (and the host web-access log shows the matching request to the PHP worker). Under the study's attribution bar, neither witness sealed a record that names the PHP worker together with the marker file path or the SQL marker string for the in-process effect.

Observed on Ubuntu. On one temporary Ubuntu lab host, a PHP-FPM web worker we controlled was told, by a same-host web request, to read a marker file outside the web root, write a new marker file, and insert a row in a local SQLite database. Host proofs confirm each action completed with the run's marker token. A short process-create control that put a unique token on the command line was recorded by the enterprise EDR sensor under test. The native OS audit extract for this run is undetermined (collection error), so this Ubuntu result is single-witness on the sensor side only. For each of the three actions, the enterprise EDR sensor under test recorded a token-matched local web-trigger process. Under the study's attribution bar, the sealed sensor export does not attribute the PHP worker together with the marker file path or the SQL marker string for the in-process effect. (Same attribution-depth class as the Windows leg for those cells.)

What this does and does not show

On both hosts, the records tie each action to the web request that triggered it, through the run's token. On neither host did the sealed records name the PHP worker together with the file it read or wrote, or the database row it inserted. The step from "a request reached the worker" to "the worker touched this file or this database" rests on the host-side checks, not on the witnesses' records.

This is one run per operating system. It does not show how the sensor or the native logs behave on other hosts, other PHP setups or other operating systems, and it says nothing about the PHP vulnerabilities themselves, which we did not test.

Limitations

Windows

• Windows run: one temporary Windows lab host, one run, one date (2026-10-21). The result applies to that host only.
• Attribution depth (Windows): both witnesses recorded the token-matched web trigger for each action, but neither sealed a record naming the PHP worker together with the marker file path or the SQL marker string. This page therefore does not say that either witness recorded the PHP worker reading or writing the marker file, or recorded the database insert.
• On Windows, a second control that wrote a test file was confirmed on the host, but the endpoint sensor's export did not include a separate file-write record for it. The study therefore relied on the process-creation control, which both records captured, to confirm the sensor was recording during the run (2026-10-21).
• Install deviation (Windows): the first install command ran long and was cancelled after the host had already built the PHP stack; one resend failed harmlessly and changed nothing. Read-only checks afterward confirmed the stack and the lab script before the test.

Ubuntu

• Ubuntu run: one temporary Ubuntu lab host, one run, one date (2026-10-21). The result applies to that host only and is reported separately from the Windows result.
• Native witness (Ubuntu): the native OS audit extract for this run is undetermined because of a collection error (the audit query rejected its start-time format and returned nothing). The Ubuntu result is single-witness, on the enterprise EDR sensor under test only.
• Attribution depth (Ubuntu): the sealed sensor export does not attribute the PHP worker together with the marker file path or the SQL marker string. This page therefore does not say that the sensor recorded the PHP worker reading or writing the marker file, or recorded the database insert.
• During package install, the operating system's needrestart briefly restarted the enterprise EDR sensor (~18.6 seconds). That gap ended before the process-create control and before all three actions; those steps were recorded after the sensor was back online.
• Install deviation (Ubuntu): the first package install failed because the host could not reach the package mirror over the configured transport; after a package-transport fix only, the same install script succeeded on its second send. The lab script and the test steps were unchanged.
• On Ubuntu, the web access log also shows one earlier action-A request made during setup on 2026-10-22 (UTC), before the scored run. It was not scored, and the results above cover only the three scored requests.

Both runs

• SSS did not test the PHP vulnerabilities. The lab used a benign, lab-written PHP script as a stand-in for an attacker who already has code running inside the PHP worker.
• The exploitation status above is CISA's statement as of its publication, and the KEV status is as of the dated check above. Both can change; check CISA's current pages.
• Only Windows and Ubuntu were tested. A third operating system in the study plan, a different Linux distribution, has not been tested yet; its result is open. The Ubuntu results do not carry over to it, and this page states no result across three operating systems.
• The alert result is not a detection or prevention claim. This page makes no detection, prevention, coverage, customer, product-comparison or scoring claim.

References

1. PHP Group, security release announcement, 2026-10-21: https://www.php.net/archive/2026.php#2026-10-21-5
2. CISA, "Critical Vulnerabilities in PHP Require Immediate Patching," alert, 2026-10-21: https://www.cisa.gov/news-events/alerts/2026/10/21/critical-vulnerabilities-php-require-immediate-patching
3. CISA, Known Exploited Vulnerabilities catalog (checked 2026-10-27, 10:10 AM PT): https://www.cisa.gov/known-exploited-vulnerabilities-catalog
4. CERT-EU, Security Advisory 2026-018: https://cert.europa.eu/publications/security-advisories/2026-018/
5. Distribution security advisories, e.g. Ubuntu USN-8948-1 and USN-8948-2: https://ubuntu.com/security/notices/USN-8948-1
6. SSS Research Validation scores for the Windows run and the Ubuntu run (2026-10-21)
7. SSS case record and study design for this test (2026-10-21)

Want to know if your endpoint defenses still work?

We test them in your environment and give you a plain written answer.