We Are Standing at the Edge

What happened?

On 17 October, attackers targeted Russian hosting providers’ infrastructure through a vulnerability in VMmanager 6, ISPsystem’s virtualisation platform. FirstVDS and other providers using the system were affected. In some cases, attackers gained access to customers’ virtual-server disks from the host infrastructure and could extract passwords, SSH keys, API tokens, configuration files and other sensitive data. The virtual servers themselves could keep running normally. Your website loads, your application responds and monitoring shows the usual charts, while someone outside is already examining your server’s contents. ISPsystem confirmed the incident.

This is more than another story about a leaked database…

When you rent a VPS, it usually feels as though you are buying an isolated slice of computing resources. You have your own operating system, applications, SSH access, firewall, backups and all the other trappings of responsible server ownership. Physically and architecturally, however, your server remains part of someone else’s infrastructure. Between you and the hardware are a hypervisor, a control panel, service accounts, internal networks and a whole chain of software most customers never even think about.

If the problem lies in the virtualisation management layer, your virtual server’s boundaries may be less reliable than you assume. You can configure Linux perfectly, close unnecessary ports, disable password login and install every update. But if an attacker accesses the disk from the host infrastructure, settings inside the guest system will not necessarily help. With VMmanager, the particularly unpleasant part is that a lack of obvious traces inside the virtual machine does not mean it was never compromised.

In other words, your server’s security is not always entirely in your hands. Sometimes it ends exactly where somebody else’s admin panel begins.

And now, PHP

On 21 October, the language’s developers released emergency updates addressing two critical vulnerabilities: CVE-2026-109618 and CVE-2026-109619. Both received a CVSS 4.0 score of 9.2 and, under certain conditions, allow an unauthenticated remote attacker to execute arbitrary code on a server. The vulnerabilities affect PHP installations serving web requests, including various PHP-FPM, Apache and other deployment configurations.

PHP still underpins a huge number of websites, online shops, content management systems and internal corporate applications. WordPress, Drupal, Joomla, Magento and custom applications operate under very different conditions but may depend on the same runtime. A PHP-level vulnerability can therefore affect a whole section of the web rather than a single product or developer.

According to an NHS England Digital advisory, researchers demonstrated remote-code execution using both vulnerabilities. Information began circulating before the scheduled disclosure, and reports of attacks appeared before updates could be installed everywhere. It is an unpleasant race: developers release a fix, administrators try to deploy it, and attackers only need to find the systems whose updates were delayed.

Our habits

We are used to treating the internet as an enormous but broadly stable system. Websites work, clouds scale, data syncs and applications communicate through APIs. It all feels almost natural. Behind the convenient interface, however, is an incredibly complex structure of libraries, runtimes, operating systems, containers, network services, management tools and third-party dependencies.

The problem is not simply the number of vulnerabilities. They have always existed, and discovering one does not mean that half the internet will stop working tomorrow. The question is how quickly they are found, how quickly they become usable attack tools, and how many systems get fixed before those tools see widespread use.

Finding complex bugs used to require substantial expertise, time and resources. AI tools now help researchers analyse large codebases and identify issues that went unnoticed for years. The same technology can also make attackers’ work easier, from studying source code to finding ways around defences and automating individual stages of an attack.

That does not mean a neural network will hack any server at the push of a button tomorrow. Reality is unfortunately less cinematic. But the barrier to entry is falling and software research is accelerating. That changes the economics of cybersecurity: defenders gain tools, and so do attackers. Defenders must follow procedures, preserve availability and answer for the consequences. An attacker only needs to find one route that works.

It is particularly revealing that vulnerabilities can exist for years in fundamental components. Software becomes a de facto standard used by millions of projects, and then a particular combination of conditions turns out to bypass familiar security boundaries. One project’s technical debt suddenly becomes a problem for an entire industry.

Infrastructure concentration is another part of the story. Thousands of servers are managed through the same platforms, projects rely on shared libraries, and hosting providers build services on identical technologies. This is convenient, cheap and efficient until a serious problem is discovered in one of those common components.

Scale turns from an advantage into a risk multiplier

A vulnerability in a small independent application may affect one owner. A vulnerability in a widely used runtime or control panel can open a path into many systems at once. They will not necessarily all be compromised, but the possibility of widespread impact changes the situation. The more dependencies hidden behind a “Create server” button, the harder it is for an ordinary customer to judge the real risk.

The industry continues to sell convenience as a synonym for reliability. Deploy infrastructure in a minute, connect integrations in a few clicks, store secrets in environment variables, move everything to the cloud and automate deployment. Automation itself is not the enemy, but it often creates the illusion that complexity has disappeared. It has merely moved somewhere users do not usually look.

One forgotten token, one vulnerable control panel or one missing patch can then outweigh all the other protective measures combined. If an attacker gains host-level access, the consequences may extend far beyond a single application.

This affects more than large companies. Small studios, independent developers, online-shop owners and people running their own services on a VPS usually have far fewer security resources. They do not have a round-the-clock SOC, a dedicated incident-response team or someone whose only job is reviewing logs. Usually there is a developer, a few projects and a hope that nothing breaks today.

Hope is an excellent budgeting tool, but a rather questionable way to protect servers.

What should we do? There is no obvious universal answer. But some things can no longer be treated as optional. Critical updates need to be installed promptly, rather than after the next website release. Control panels and admin interfaces should not be exposed to the public internet without a reason. Secrets should not be stored so that one compromised server automatically unlocks every other system. Backups need restoration tests as well as creation. After a confirmed incident, affected passwords, keys and tokens should be treated as potentially copied, even if no suspicious processes were found inside the system.

Above all, we need to stop confusing a working system with a secure one. A website may load, a server may answer requests, and a database may accept writes correctly. None of these facts proves that the system has not been compromised.

I do not think the internet will collapse tomorrow. Predictions like that are usually written by people selling another cybersecurity course or a prompt that supposedly makes Claude find and fix every vulnerability in a project. A more likely future is more incidents, more emergency updates, more temporarily disabled services and less time between discovering a vulnerability and exploiting it.

That does not make the situation any less serious.

We are building more of our economy, communication and everyday life on infrastructure whose complexity we cannot fully keep up with. Much of it depends on a limited set of software components, common standards and suppliers. The system becomes more powerful while the number of ways to destabilise it grows.

So, yes…

We are standing at the edge. The internet is not necessarily about to disappear, but the cost of a mistake is growing faster than many organisations can adapt their security processes.

The irony is that the more we automate, consolidate and simplify, the more we depend on things outside our direct control. We can write an application, choose a database, configure a server and close unnecessary ports ourselves. We cannot individually audit every line of code behind modern digital infrastructure.

At some point, the question is no longer whether another vulnerability will be found. More will be found. The question is how long it takes to turn one into a widespread problem, and how many systems will still be unprotected when that happens.

Perhaps that is the most worrying part: the speed at which software vulnerabilities stop being theoretical.