Who owns the patch? Name who applies the fix before you verify it

In October, exploited flaws in PHP, BeyondTrust Remote Support and Arista VeloCloud Orchestrator all reached CISA's Known Exploited Vulnerabilities catalog. Our read: in each one, the safe answer depended on how the product was deployed: a vendor-hosted copy was patched by the vendor, a self-hosted copy had to be patched by its owner, and a copy bundled inside someone else's product can only be fixed by that vendor. Here is what each publisher said, the Patch-Owner Map (our proposal) step by step, and the questions to send a host or vendor so you get a version and a date back, not a yes.

Our previous post was about the second pass after a patch: patch, then verify. This one is about the step before it. Before you can verify a fix, someone has to apply it. Our read: for many of the systems an MSP or IT lead looks after, that someone is not you.

Our read: when nobody can say who owns a patch, that gap is the real problem. Close it before the next advisory lands. (We print no severity scores in this post.)

PHP: find every install, including the ones inside other software

"PHP2Shell" is the name researchers and the press use; CISA uses CVE numbers and its own vulnerability names.

CISA's catalog. CISA added CVE-2026-109618 ("PHP Memory Corruption Vulnerability") and CVE-2026-109619 ("PHP Stale Internal Request-State Vulnerability") to KEV on Oct 26. CISA's short description of each says it allows unauthenticated remote code execution. The federal due date was Oct 29, and it binds federal civilian executive branch agencies only (BOD 26-04). Known ransomware campaign use, per CISA: Unknown.

CISA's PHP alert (URL-dated Oct 21, last revised Oct 26) urges organizations to update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35. Per CISA, PHP that serves web requests is affected through Apache mod_php, PHP-FPM, php-cgi, FrankenPHP and LiteSpeed. CISA says to take systems on unsupported PHP 8.1 or earlier, and any system that can't be updated right away, offline until patched. It asks organizations to inventory every system running PHP, including PHP that ships inside other software, to patch internet-facing systems first, and to watch for PHP worker processes launching shells or downloading tools. The alert mentions an optional WAF stopgap; a stopgap is not the fix.

The UK NCSC (21 Oct, since updated) says organisations using any version of PHP are affected and describes exploitation as possible "under certain conditions"; it does not report in-the-wild exploitation. Its advice: identify all PHP installations, internet-facing first; update to the latest PHP or, if that is not possible, apply the PHP Foundation's temporary mitigations, and take systems offline if those can't be applied in time; check for signs of compromise; and monitor third-party vendors whose products bundle PHP.

The FBI's IC3 (PSA I-102326-PSA, Oct 23) says the two CVEs could allow malicious cyber actors to remotely execute code in PHP core. It recommends updating per php.net, inventorying PHP including vendor products that bundle it, and watching web servers for PHP processes that spawn shells or download files. It does not say the flaws are being exploited.

The reporting. Per BleepingComputer (Sergiu Gatlan, Oct 26), Adel Karimi of Perplexity saw honeypot-confirmed remote code execution, and Expel's Marcus Hutchins independently confirmed it; per the same report, PHP patched the flaws on Oct 21. On Oct 27, BleepingComputer described the flaws as exploitable by attackers with no privileges "in high-complexity attacks", and reported that Karimi's honeypots recorded remote code execution against an Apache mod_php install running PHP 8.4.26. Honeypots, not victims. Amazon Threat Intelligence says its MadPot honeypots logged an exploitation attempt on Oct 17, before public disclosure: targeting, not a confirmed compromise. BleepingComputer's Oct 26 report also covers a separate flaw, CVE-2026-115560, which had no patch as of that report and needs an unusual combination of configuration and application code; check php.net for its current status.

The kernel piece. CISA added Linux kernel CVE-2026-46300 to KEV on Oct 28 (federal due date Oct 31, federal civilian executive branch agencies only; ransomware use Unknown). Per CISA's entry, it can be chained with the two PHP CVEs to implant PHP webshells and run commands as root. It is a kernel flaw, not a PHP flaw.

Our read: patching is the simpler half of this one. The harder half is the question all three government sources put first: where is PHP running, and who updates it? On a shared host, the host does. On a VPS or self-managed server, you do, kernel included. On an appliance or product that bundles PHP, only that vendor can.

BeyondTrust Remote Support: SaaS patched by the vendor, self-hosted on the owner

CISA added CVE-2026-102764 ("BeyondTrust Remote Support Authentication Bypass by Spoofing Vulnerability") to KEV on Oct 16 (federal due date Oct 19, federal civilian executive branch agencies only; ransomware use Unknown). We could not read BeyondTrust's advisory BT26-05 directly, so the details below are credited to Google Threat Intelligence Group (GTIG / Mandiant) and BleepingComputer.

Per GTIG's Oct 15 post, the flaw was exploited as a zero-day starting in late August 2026. GTIG attributes the activity to a suspected PRC-nexus espionage actor it tracks as ARMORY CASTLE (formerly UNC5221). BleepingComputer reports that BeyondTrust described a suspected China-nexus espionage actor without naming a group.

Who applies the fix, per GTIG. Supported versions up to 26.2.3 are affected. BeyondTrust applied the patch to all SaaS tenants on Oct 9. Self-hosted owners apply BT26-05-RS from the /appliance interface on 24.3.1 or later; older instances must upgrade to a supported version first. BleepingComputer adds that self-hosted installations must be patched manually if automatic updates are not enabled. GTIG says upgrading closes the hole but does not remediate prior exposure.

On the appliances it investigated, GTIG reports the actor used the bt-secrets CLI to target a site service account's vault, then ran a fallback command against the global password safe to dump stored admin credentials. GTIG also reports the SAWFLY PHP webshell (mangoapi.php), the BARECLAW tunneler on localhost TCP 19800 exposed through an edited haproxy.conf, and deleted logs. That is what GTIG observed, not every appliance.

GTIG advises treating any appliance reachable from the internet on a vulnerable version during the window as potentially compromised until reviewed, then, in order:

  1. Preserve evidence (snapshot before change).
  2. Isolate: block inbound, restrict egress, and disable (not delete) sessions, Jump Clients and API accounts.
  3. Rebuild from a clean patched image with a new TLS certificate.
  4. Rotate credentials only after the appliance is patched or rebuilt. GTIG's list covers admin, API, SAML, vault and integration credentials, security-provider bind accounts, Password Safe / PRA credentials, SMTP / syslog / ITSM credentials, and any credential typed into a support session during the window.

Our read: the same product needed two answers. SaaS customers had the patch applied for them. Self-hosted owners had to apply it and then, per GTIG, ask whether someone was already in. Rotating before the rebuild hands fresh credentials to anyone still on the box.

Arista VeloCloud Orchestrator: hosted already patched, on-prem on the owner

Arista Networks' Security Advisory 0199 (revision 1.0, Oct 22) covers CVE-2026-114625 in VeloCloud Orchestrator (VCO). Arista says the issue was detected by Arista and is known to be actively exploited, and that hosted versions of VCO, including Dedicated, were impacted and have already been patched.

For VCO On-Prem, the affected trains are 5.2.x before 5.2.3.18, 6.1.x before 6.1.3.10 and 6.4.x before 6.4.2.12, per Arista. End-of-support versions have not been assessed; Arista tells customers on them to contact TAC. Per Arista, an attacker needs network access to the web interface and a valid authenticated session, with Enterprise Read Only, the lowest built-in tenant role, as the minimum. Arista also says VCO is exposed by default.

Arista's interim steps until you patch include restricting the web interface to trusted administrative networks, monitoring for access from known malicious source IPs, watching for unexpected outbound traffic, looking for backdoor daemons and webshells, and reviewing recent administrator activity. Arista's indicators section separately advises blocking two listed IPs (74.82.197.86 and 38.54.50.151) and reviewing logs for them. If compromise is suspected, Arista says to preserve logs and file-system timestamps before remediating, where operationally feasible. Patching remains the fix.

CISA added CVE-2026-114625 ("Arista VeloCloud Orchestrator SQL Injection Vulnerability") to KEV on Oct 23 (federal due date Oct 26, federal civilian executive branch agencies only; ransomware use Unknown).

Our read: one advisory, two answers. If Arista hosts your VCO, Arista already did the work; if you run it on-prem, the work is yours. Because a read-only session is enough per Arista, read-only accounts belong on the review list too.

Also: MeshCentral. If you or your MSP self-host MeshCentral, you are its patch owner. The project's 1.3.1 release notes on GitHub (Oct 23) urge an urgent upgrade, warn of an active exploit taking control of MeshCentral servers and their remote clients, and say the update "should hopefully" patch it. No CVE or advisory ID has been published. Our read: 1.3.0 (Oct 21) carries no security note, so a server updated only to 1.3.0 is not on the version the developer is urging; upgrade to 1.3.1, then review admin accounts, device groups and recent agent installs.

The Patch-Owner Map (our proposal)

This is our framing, not a standard: a starting point to adapt. It comes before the fix-verification loop from our previous post. The map says whose fix it is; the loop verifies the fixes that are yours.

  1. List what runs, including what runs inside other things. One row per client system that faces the internet or that you manage: websites, remote-support and RMM tools, network orchestrators, appliances, hosted apps. Then add the components advisories name: a website row gets a PHP row under it, and a self-managed Linux web server gets a kernel row.
  2. Tag how each one is deployed. Vendor-hosted SaaS, shared hosting, VPS or cloud server, vendor appliance or bundled runtime, self-hosted by us, or self-hosted by the client. The tag decides who applies the fix.
  3. Name the patch owner and the channel. One named owner per row (us, client IT, the web host, the vendor), plus how they hear about fixes: advisory feed, partner portal, auto-update or support ticket. Any row without an owner is red. Our read: a red row is the real finding, more than any single CVE.
  4. Ask in writing and get a version back. For every row someone else owns: what version is running, and when was it applied? Log the date sent, who answered, the version stated and where the reply is stored. For vendor-hosted rows, the vendor's own advisory statement (Arista's note that hosted VCO is patched, for example) is the record; keep a dated copy.
  5. Close your own rows, then reduce exposure on the unanswered ones. Patch your rows to the version the vendor names today. Restrict reach where the advisory says to (Arista for the VCO web interface; GTIG for /login and /appliance). Unsupported runtimes get the advisory's own answer, such as CISA's offline-until-updated for PHP 8.1 or earlier. For unanswered rows, agree with the client what happens next and by when.
  6. Check for prior access where the advisory tells you to. Patching does not answer whether someone already got in. Follow GTIG's preserve, rebuild, then rotate order; Arista's preserve-logs step if compromise is suspected; CISA's watch for PHP workers launching shells. Record what you checked and found.

What a few rows might look like for one client (illustrative, not real data):

System Component Deployment Patch owner Version confirmed Date Status
Website PHP Shared hosting Web host as stated by host date of reply amber until answered
Client portal PHP + kernel VPS Us read from the server date checked green
Remote support BeyondTrust RS Self-hosted by client not named yet unknown none red
SD-WAN VCO Vendor-hosted Arista per SA 0199 date of copy green

Green: owner named and answered. Amber: asked, no answer yet. Red: no owner. Our read: the map does not stop anything on its own. It turns "who patches this?" into a name, a version and a date.

The questions to send a host or vendor

Our read: ask for a version and a date, not a yes. "Are you patched?" invites an answer you can't check. "Which version, applied on which date?" gives you something to record. Our wording; adapt it.

  • Web host: Which PHP version is serving [site] today, and on what date was it applied? Which handler runs it: mod_php, PHP-FPM, php-cgi, FrankenPHP or LiteSpeed?
  • VPS or cloud provider: On [server], who applies PHP and kernel updates, you or us? If you, which versions are installed and when?
  • Vendor that bundles PHP: Does [product] ship its own PHP? Which version is in the release we run, and which of your releases carries a version CISA names as fixed?
  • SaaS vendor: Is our tenant on the fixed version for [advisory], and on what date was it applied? Where is your written statement, so we can keep a dated copy?
  • Client, or whoever built something for them: Who installs security fixes on [system]? If nobody is sure, who can tell us, and by when?

Log each one. Our read: keep it about responsibility, not suspicion; the point is to ask, not to judge who has or hasn't patched. With a non-technical client, skip the CVE numbers: ask who built or hosts each thing, then ask those people in writing.

What we do not know

  • Which of our readers run PHP on shared hosts, VPSs or appliances, and how many BeyondTrust or VCO instances among readers are self-hosted. That is what the map is for.
  • Whether any organization GTIG investigated was an MSP.
  • The real-world success rate of PHP2Shell attacks.
  • Who is behind the Arista-listed IPs. Arista does not say, and neither do we.
  • Current status. We read these sources on Oct 29. Check the KEV catalog, CISA's alert, php.net, GTIG's post and Arista's advisory directly before acting.

Take the map with you

The Patch-Owner Kit (Gatorbyte #018) is the map above as something you can hand over: a Patch-Owner Map with green, amber and red rows, an Ask-the-Owner Log, an Advisory Triage Sheet, a Question Bank for hosts and vendors, a Red-Row Checklist and an Evidence Register, with CSV and Excel export. It is worksheets you fill in, not a scanner or a PHP finder, and it runs offline as a Windows app. Free to use inside your organization and with your clients, including in paid engagements.
→ https://thesecuritygator.gumroad.com/l/gb018-patch-owner-kit

Once the map says a fix is yours, The Fix-Verification Kit (Gatorbyte #017) verifies it. When an advisory says to rotate credentials after a rebuild, as GTIG does for BeyondTrust, The Leaked-Secret Response Kit (Gatorbyte #016) handles the rotation bookkeeping.

A practical starting point to review and adapt for your organization; not legal, compliance or audit advice, and not a substitute for the vendor's advisory, your incident-response plan or a forensic investigation. The Security Gator is not affiliated with the PHP Group / PHP Foundation, BeyondTrust, Arista, Google / Mandiant, Amazon, Perplexity, Expel, Shadowserver, CrowdStrike, the MeshCentral project, or any vendor, agency or researcher named in this post.

Sources: