Summary

My Radar has surfaced a pattern this week worth naming. The serious vulnerabilities are not clustering in ordinary applications, but in the systems we use to manage, recover, automate and control everything else — remote support, backup, storage, AI workflows and legacy collaboration servers. A medium-severity bug in one of those can matter more than a critical bug in something isolated. The perimeter has not disappeared. It has moved into the control plane.

Over the past few days, my vulnerability radar has picked up a pattern that is more important than any single CVE. It is not that serious vulnerabilities keep appearing — that is nothing new. What is interesting is where they are appearing: in remote support platforms, backup systems, storage appliances, SharePoint servers and AI workflow tools. Not in ordinary applications, but in the systems organisations use to manage, recover, automate and control everything else.

That shift changes the nature of the risk. A vulnerable website can be bad; a vulnerable control plane can become a path into the rest of the environment.

My Radar is not a threat intelligence service, and it is not meant to be exhaustive. It is a personal filter over advisories from sources such as CISA, Zero Day Initiative and CERT-EU, with short notes on what catches my eye from a European infrastructure perspective. This week, several items caught my eye for the same reason.

Remote support: when help becomes access

The first is CVE-2026-48558 in SimpleHelp, an authentication bypass added to CISA's Known Exploited Vulnerabilities catalog on evidence of active exploitation.

SimpleHelp is remote support software, and that is exactly what makes it interesting. A vulnerability in a remote support platform is not just a login problem. These platforms are built to reach other systems; they sit close to administrators, service providers, customers and internal endpoints. So if an attacker can bypass authentication there, the concern is not limited to the application itself. The real question is what that technician session, support workflow or remote access path could reach next.

Remote management and remote support tooling should therefore be treated as high-trust infrastructure — not because the products are bad, but because their entire purpose is to cross boundaries.

Backup: the recovery layer is also an attack surface

The second pattern is backup. Zero Day Initiative published a cluster of advisories affecting Quest NetVault Backup, including NVBULogDaemon command injection (CVE-2026-9787) and NVBUDashboard SQL injection (CVE-2026-7570), both leading to remote code execution. Several note that authentication is required — but that the existing authentication mechanism can itself be bypassed.

Backup systems are often filed mentally under "operations", and that category is far too small. A backup platform knows where the critical systems are. It may have agents deployed across the whole estate, and it may hold credentials, schedules, snapshots, retention policies and recovery paths. In a ransomware scenario it can be the difference between a bad week and an existential event.

So when backup software carries remote code execution vulnerabilities, the question is not only whether the backup server can be compromised. It is whether the organisation's ability to recover can be compromised.

Backup infrastructure belongs closer to Tier 0 than to ordinary tooling. It should be segmented, monitored, restricted and tested as part of incident response — not merely as part of IT operations.

Storage: if the data layer falls, everything above it shakes

CISA also published an advisory for StoneFly Storage Concentrator. The radar summary is blunt: successful exploitation could allow broad unauthorised access, arbitrary command execution with root privileges, theft of sensitive data, and actions taken on behalf of legitimate users across interconnected systems.

Storage is easy to underestimate, because it is not always visible to the business. It is not the login page, the app, or the dashboard people use every day — and yet almost everything depends on it.

When the storage layer is affected, the blast radius becomes strange and uncomfortable. You are no longer protecting a single service; you are protecting the substrate that many services sit on. That makes storage appliances, SAN/NAS platforms and backup targets especially sensitive. They should not be quiet boxes in the corner with broad network reach and weak operational visibility. They are part of the security boundary.

AI workflows: prompt injection is becoming an infrastructure risk

The most modern item on the list is ZDI-26-364 (CVE-2026-41264), affecting FlowiseAI's Flowise CSV Agent: a prompt injection vulnerability that can lead to remote code execution without authentication, which ZDI scored at CVSS 9.8.

It matters because it shows why prompt injection should not be dismissed as a chatbot problem. Prompt injection becomes materially different once the model is connected to tools, files, code execution, credentials, databases or internal workflows. At that point the prompt is no longer just text — it becomes part of a control path.

The old lesson still applies: never mix untrusted input with privileged action without strict boundaries. Large language models do not remove that lesson; they only make it easier to forget.

AI workflow tools need the same unglamorous controls as everything else — authentication, authorisation, sandboxing, least privilege, network isolation, audit logging, secure defaults, and a clear separation between user-provided content and executable actions. The AI part is new. The trust-boundary problem is not.

SharePoint: the old perimeter never fully disappeared

Then there is CVE-2026-45659 in Microsoft SharePoint Server, which CISA added to the KEV catalog for active exploitation. The flaw involves deserialisation of untrusted data, and it is a useful reminder that the cloud did not magically remove on-premise risk.

Many organisations still run collaboration platforms, document systems, legacy portals, hybrid services and forgotten internal tools that became externally reachable for entirely practical reasons: partners needed access to files, integrations needed endpoints, remote work needed portals, business continuity needed uptime. Over time, yesterday's internal system quietly becomes today's perimeter system.

That is why the phrase "publicly exposed asset" carries weight. If a system is reachable from the internet and sits close to identity, documents, workflows or internal integrations, it is not just another server — it is part of the organisation's attack surface, whether the organisation thinks of it that way or not.

The pattern

Technically, these advisories have little in common. One is a remote support authentication bypass, one a backup RCE, one a storage exposure, one an AI workflow prompt injection leading to code execution, one a SharePoint deserialisation under active exploitation. Operationally, though, they all point the same way: attackers are not only targeting applications, but the systems used to control, restore, automate and administer those applications.

That is why "control plane" — a concept born in hyperscale cloud architecture — is now spreading well beyond it. For a cloud provider, MSP, SaaS operator, municipality, hospital, manufacturer or ordinary mid-sized company, the control plane may include:

  • remote support tools
  • backup platforms
  • storage appliances
  • identity systems
  • admin portals
  • orchestration tools
  • monitoring systems
  • AI automation platforms
  • legacy collaboration servers
  • privileged service accounts

These are not side systems. They are the systems that decide what every other system is allowed to do.

What leaders should take from this

The lesson is not panic; it is prioritisation. Not all vulnerabilities are equal. A medium-severity bug in a control plane can matter more than a critical bug in an isolated system, and a product that can reach many others deserves more scrutiny than one that can only harm itself.

The practical question for leadership is simple: if this system were compromised, what else could the attacker reach, control, restore, delete or impersonate? That is usually more useful than asking for a CVSS score, because it shifts the discussion from vulnerability management to consequence management.

For operators, the immediate questions are just as concrete:

  1. Do we run any of these products?
  2. Are they exposed to the internet or reachable from untrusted networks?
  3. Are they patched?
  4. Do we have signs of prior compromise?
  5. Are they segmented from the systems they manage?
  6. Are their service accounts overprivileged?
  7. Would we notice if they were abused?

In many organisations the honest answer to several of these is "maybe not" — which is exactly why these systems deserve attention before an incident, not during one.

Europe should care about this

From a European infrastructure perspective, this connects to something larger. Digital sovereignty is not only about where data is stored or which jurisdiction a vendor sits in. Those things matter, but sovereignty also depends on operational resilience: whether we actually understand, control and can recover the systems we depend on.

A dependency is not only a cloud region. It can just as easily be a remote support tool, a backup product, a storage appliance, an AI automation platform, a forgotten SharePoint server, or a privileged integration nobody has reviewed in years. Sovereignty without operational control is mostly branding.

The serious work is less glamorous: inventory, segmentation, logging, patching, identity hygiene, backup testing, least privilege, and knowing which systems can control which others. This week's radar items are a useful reminder of that.

Closing

So the perimeter is not gone. It moved — into the control plane, into the systems that decide what everything else is allowed to do. That is where the scrutiny, the segmentation and the recovery testing now belong.

Sources

Tags Cybersecurity Infrastructure