Written by Jaiz Anuar

The Certificate Was Valid. The Software Update Was Malicious.

The Virtualizor incident demonstrates why secure transport cannot substitute for software integrity. A valid certificate may authenticate the connection while a compromised update channel delivers malicious code.

A secure connection does not guarantee secure software.

In late August 2026, attackers reportedly used a Border Gateway Protocol hijack to divert internet traffic intended for Softaculous infrastructure. The affected addresses included the update service used by Virtualizor, a platform for managing virtual private servers.

The attackers did not simply create a convincing imitation of the vendor’s website.

They obtained a valid TLS certificate for the diverted infrastructure. Systems connecting through HTTPS therefore received no certificate warning. During the incident window, some Virtualizor installations reportedly downloaded a modified software package from the attacker-controlled server.

The connection was encrypted.

The certificate was valid.

The software update was malicious.

According to Virtualizor’s incident disclosure, only a small number of installations were confirmed to have received the malicious package. However, the company could not produce a definitive list of affected systems because requests diverted to the attacker never reached its own infrastructure or logs.

The incident exposes an important weakness in how organisations think about digital trust.

HTTPS Protected the Wrong Thing

TLS performs an essential function.

It encrypts communication between a client and a server. It also helps the client confirm that the server controls the expected domain.

But TLS does not prove that every file delivered by that server is safe.

In this incident, the attacker allegedly manipulated internet routing so traffic was directed somewhere it was never supposed to go. A valid certificate then made that diverted connection appear legitimate.

The certificate did what it was designed to do.

The security failure occurred because too much trust was placed in what the certificate represented.

A valid certificate confirmed that the connection was encrypted and associated with the requested domain at that moment. It did not prove that the software package came from the vendor’s authorised build process.

It did not prove that the package had not been modified.

It did not prove that the code was safe to execute.

Most importantly, it did not prove that the system at the other end of the connection was still under the vendor’s control.

Transport Security Is Not Software Integrity

Secure software distribution requires at least two different forms of trust.

The first is transport security.

This protects the connection used to retrieve the software.

The second is software integrity.

This verifies that the package was produced or approved by the expected publisher and has not been altered since it was released.

These controls address different risks.

If software integrity depends only on HTTPS, the update process is effectively saying:

If the connection looks legitimate, trust whatever arrives through it.

That assumption becomes dangerous when DNS, routing, certificate issuance, hosting infrastructure or the update server itself can be compromised.

A stronger update mechanism cryptographically signs the package. The client then verifies that signature using a trusted public key before installation.

If the signature is missing, invalid or associated with an unapproved publisher, the update must be rejected even when it was downloaded through a perfectly valid HTTPS connection.

Encryption protects the journey.

Digital signing protects the package.

A mature architecture needs both.

Automatic Updates Create Privileged Trust

Automatic updates are usually treated as good security practice.

They reduce the time between vulnerability disclosure and remediation. They help organisations remove known weaknesses without waiting for administrators to perform every installation manually.

But an update mechanism also possesses significant privilege.

It can download software.

It can replace trusted files.

It can modify configurations.

It may execute code as root or another highly privileged account.

That makes the update channel part of the privileged security architecture.

An attacker who controls it may not need to bypass endpoint protection, exploit an application or steal an administrator’s password. The trusted update process can deliver and execute the attacker’s code for them.

This is why software distribution infrastructure must be protected with the same seriousness as identity systems, privileged-access platforms and deployment pipelines.

As discussed previously in The Tools We Trust To Secure The Supply Chain Can Become The Supply Chain Risk, concentrated trust creates concentrated consequences. A tool connected to many systems can become an efficient path into all of them when that trust is compromised.

A Trusted Source Is Not a Permanent Condition

Organisations often approve software sources once.

The vendor is assessed.

The domain is allowlisted.

The certificate is valid.

The update service is permitted through the firewall.

From that point onward, the source may be treated as permanently trusted.

But trust is not a permanent attribute.

A legitimate vendor can be compromised.

A valid domain can be redirected.

A trusted certificate can be issued during an infrastructure attack.

A genuine update service can distribute a malicious package.

A previously approved supplier can become the path through which an attacker enters.

Trust should therefore be continuously verified at multiple layers. The identity of the server, integrity of the package, authority of the publisher and behaviour of the installed software should not depend on one shared assumption.

What Security Architecture Should Require

Critical software update processes should include several independent controls:

• Cryptographic signing of every package
• Mandatory signature verification before installation
• Protection of signing keys through tightly controlled hardware or services
• Separation between build, signing and distribution environments
• Approved publisher and version policies
• Tamper-resistant logging of update activity
• Monitoring for unexpected routing, DNS and certificate changes
• Staged deployment before updates reach critical systems
• Behavioural monitoring after installation
• A tested method to revoke compromised signing keys and packages

For highly privileged infrastructure, organisations should also determine whether an update can be installed automatically or requires additional validation.

A hypervisor management platform, identity system, security appliance or orchestration tool should not necessarily inherit the same update policy as an ordinary desktop application.

The greater the privilege of the software, the stronger the verification required before new code is allowed to execute.

Detection Must Extend Beyond the Vendor

This incident also demonstrates the limitation of relying entirely on a supplier’s telemetry.

If traffic is diverted before it reaches the legitimate service, the vendor may never see the affected request. Its logs can appear normal while customers are communicating with attacker-controlled infrastructure.

Customers therefore need their own evidence.

Which systems checked for updates?

What packages were downloaded?

What hashes were installed?

Which processes were created afterward?

Were privileged accounts, SSH keys, services or scheduled tasks changed?

Did affected systems establish unexpected outbound connections?

Supplier assurance cannot replace customer visibility.

The vendor may investigate the source of the incident, but each organisation must determine whether its own systems were exposed and whether trust can still be restored.

Removing the Malware May Not Restore Trust

When malicious code gains root-level access, deleting the known files is not necessarily enough.

The attacker may have created additional accounts, installed alternative persistence, captured credentials or modified other trusted components.

A scanner can identify known indicators.

It cannot prove that an attacker with complete administrative control made no other changes.

For systems confirmed to have suffered root compromise, rebuilding from a known-good source may be more reliable than attempting to clean the existing installation. Credentials, API keys and administrative secrets accessible from the affected system should also be treated as potentially exposed.

Containment removes known malicious activity.

Recovery must restore confidence in the system.

Those are not the same outcome.

Final Thought

The lesson from the Virtualizor incident is not that TLS has failed.

TLS remains necessary.

The lesson is that one valid security control should never be mistaken for complete trust.

A certificate can confirm an encrypted connection without confirming the integrity of the software travelling through it.

An approved vendor can remain legitimate while part of its delivery path is compromised.

An automatic update can close vulnerabilities while also possessing enough privilege to create a much larger breach.

Security architecture must verify the connection, the publisher, the package and the behaviour that follows installation.

The certificate was valid.

The software update was malicious.

Between those two facts lies the difference between trusting a connection and engineering digital trust.

Question assumptions. Share knowledge. Build trust.