In 30 seconds
- New KEV additions landed on 30 October. CISA added CVE-2026-111357 and CVE-2026-118527 to the Known Exploited Vulnerabilities catalogue. Exploitation is confirmed. If the affected products are in your estate, treat this as a patch priority with evidence, not a backlog item.
- PHP patching: the follow-up question. Last week we covered the php2shell disclosure. CISA's "patch now" alert is still live. The question this week is not whether you heard about it. It is whether you have actually confirmed what PHP runs in your estate, who owns it, and whether the patch is applied. If the answer is still "we are looking into it", the window is closing.
- Developer tooling is a soft spot. A malicious extension for the Cursor AI code editor was found planting SSH backdoors. It is a reminder that supply chain risk is not just big vendors. A single plugin with access to credentials or production environments can open a door that is very hard to close.
Why it matters
For regulated Channel Islands organisations, the biggest risk is not the headline. It is the knock-on impact. A compromised internet-facing service can quickly become an availability issue, a data handling issue, and a regulator conversation. This week's mix points to one theme: reduce the unknowns in your estate, especially web services and tools that can touch credentials or remote access.
KEV: two more confirmed exploitations
CISA added CVE-2026-111357 and CVE-2026-118527 to the Known Exploited Vulnerabilities catalogue on 30 October. For those less familiar, CISA is the US Cybersecurity and Infrastructure Security Agency, and their KEV catalogue is a public register of software flaws confirmed to be actively exploited in the wild. Every entry means someone, somewhere, is already using that vulnerability to break into organisations.
The KEV catalogue is the most practical signal we get that exploitation is already happening. Even if the product is not common in your environment, it is worth a quick check, because niche services often sit unmanaged and unpatched. If the affected product is in your estate, including at third parties, identify it, confirm the patch level, document ownership, and set a deadline. Evidence, not intent.
PHP: have you actually patched it?
Last week's brief covered the php2shell disclosure in detail, two critical CVEs allowing unauthenticated remote code execution on any PHP web server. CISA, the UK NCSC, and Five Eyes partners all issued emergency guidance. That was the alarm. This week is the follow-up.
PHP is everywhere. It runs underneath content management systems, supplier portals, internal tools, and third-party applications that may not be immediately obvious. The risk is not just your own servers. It is the PHP running at your web hosting provider, your marketing agency, or a supplier who manages a client-facing portal on your behalf.
The practical question is simple. Can you name every PHP instance in your estate? Can you confirm the version and patch status of each one? If the answer is still "we are working on it", that is the gap to close today. The exploit is public, the tooling is available, and the window between disclosure and mass exploitation is measured in days, not weeks. Patch to PHP 8.5.12, 8.4.27, 8.3.36, or 8.2.35. If you cannot patch immediately, take the service offline or restrict access until you can.
Developer tooling: the supply chain risk you are not watching
A malicious extension for the Cursor AI code editor was caught planting SSH backdoors on developer machines. Cursor is popular among developers using AI-assisted coding, and extensions in these tools often have broad access to files, credentials, and network connections.
This is not an exotic attack. It is the same supply chain pattern we have seen with browser extensions, npm packages, and VS Code plugins. The difference is that developer tools often have access to production credentials, SSH keys, API tokens, and deployment pipelines. A compromised developer workstation can quickly become a path into production systems.
For regulated firms, the question is straightforward. What controls stop staff installing browser or IDE extensions that can access credentials, code, or production environments? If the answer is "nothing", that is a policy gap you can close this week. Restrict extension installation to approved sources, review what is already installed, and ensure developer machines are included in your endpoint monitoring scope.
Questions to ask your team this week
- 1.Do we have any instances of the products affected by CVE-2026-111357 or CVE-2026-118527 in our environment, including at suppliers who host or manage services for us, and can we evidence patching or mitigation?
- 2.Where do we run PHP today, covering public sites, internal applications, and third-party platforms, and who owns patching and verification for each instance?
- 3.What controls stop staff installing browser or IDE extensions that can access credentials, code, or production environments?
- 4.If we had to prove "we acted" within 48 hours of a disclosure, what artefacts would we produce: change records, screenshots, version checks, vulnerability scan output?
One thing to do this week
Run a 60-minute "web stack ownership" drill: list every internet-facing web service and its tech stack (including PHP), name the owner, confirm patch status, and capture evidence. If ownership is unclear, that is the action. Then spend 15 minutes reviewing what extensions are installed on developer and admin workstations, and confirm whether your policy covers IDE and browser extensions.
Sources
- CISA, Known Exploited Vulnerabilities Catalog (30 October 2026 additions):
cisa.gov - CISA, "Critical Vulnerabilities in PHP Require Immediate Patching" (21 October 2026):
cisa.gov - BleepingComputer, "Malicious Claude Code extension on Cursor planted SSH backdoors":
bleepingcomputer.com