When HTTPS Lies: What a BGP Hijack Teaches Product Teams

A software update arrived through the expected domain, over HTTPS, with a valid certificate. It was also malicious.

That is the uncomfortable lesson from the recent Virtualizor security incident. Between 28 and 30 August 2026, an attacker used a Border Gateway Protocol hijack to divert traffic intended for Softaculous infrastructure. Some Virtualizor servers that checked for updates during the diverted intervals could receive a modified package. The update client did not cryptographically verify packages, so the impostor was dressed correctly enough to get through the door.

For founders, the important point is not that everyone must become a routing engineer by Friday. It is that familiar security signals can prove only one part of the chain. A green padlock says the connection is encrypted to whoever controls the destination at that moment. It does not certify the software, the route, the release process or the judgement behind any of them.

What happened to Virtualizor?

Virtualizor is control-panel software used by hosting providers to manage virtual private servers. Its developer, Softaculous, reported that an unauthorised route announcement diverted traffic for part of its IP space in two waves. The incident window began at 20:57 UTC on 28 August and ended at 06:10 UTC on 30 August.

The attacker-controlled destination obtained a valid TLS certificate. That meant update connections could complete without the sort of browser warning that makes even the most optimistic operations team pause. A server requesting an update during a diverted period could therefore download a modified package from the wrong machine through an apparently legitimate encrypted connection.

Softaculous said only a small number of installations were believed to be affected, but it could not produce a definitive list. Its advice was consequently sensible and broad: treat every Virtualizor server as in scope for checks. The company released a Security Analyzer in version 3.2.9.9, advised customers to rotate API credentials, review privileged access and inspect systems for persistence.

Ars Technica's independent account also highlighted the missing control that matters most to ordinary product teams: the update clients did not cryptographically verify update packages. HTTPS protected transport. It did not prove that the package itself was an authorised Venturist-style release, signed by the expected publisher and unchanged since signing.

The green padlock has a smaller job than people think

Teams often treat HTTPS as a complete trust verdict. It is closer to a secure courier bag. The bag can stop casual inspection in transit, but it cannot tell you whether the address label was redirected, whether the sender put the right item inside or whether the recipient should execute it as root.

Modern products depend on several connected trust systems:

• Internet routing decides where traffic travels.
• DNS maps names to destinations.
• TLS protects the connection and authenticates control of a name under the certificate system's rules.
• Release infrastructure builds and distributes software.
• Code signing proves that an artefact came from an authorised signing identity and has not changed.
• The update client decides what evidence it will require before installation.

Each layer is useful. None deserves the burden of impersonating all the others. Security becomes brittle when a product team quietly assumes that one layer will rescue every failure above and below it.

Five controls that make software updates worthy of trust

1. Sign releases and verify before installation

Every production update should be signed through a controlled release process. More importantly, the client must refuse an artefact when signature verification fails. Producing a checksum on the same compromised server is not equivalent. If an attacker can replace both the package and the displayed checksum, the ceremony has achieved very little beyond providing extra text.

2. Separate build, signing and distribution

A build system should not casually hold the keys that authorise production releases. Use a dedicated signing step with tightly restricted access, protected keys and auditable approvals. Distribution infrastructure should be able to serve a release, but not invent an authorised one.

This separation feels slower until the day it prevents a compromised content-delivery path from becoming a production compromise. Then it feels suspiciously like planning.

3. Make updates observable

Know which version each environment requested, downloaded, verified and installed. Record the artefact identity, signature result, deployment time and approving release. Alerts should detect unexpected update origins, unusual installation patterns and privileged changes immediately after an update.

If a supplier later says, “check everything during this 33-hour window”, your team should be able to answer with evidence rather than a tour of server history conducted by torchlight.

4. Design privileged software for containment

Control panels, deployment agents and auto-updaters often run with sweeping permissions because their work is inherently powerful. That makes their update path part of the security boundary. Restrict network access, isolate management planes, minimise stored credentials and ensure one compromised component cannot stroll through every environment wearing an administrator badge.

5. Rehearse supplier compromise

Your incident plan should cover a trusted vendor distributing an untrusted release. Identify how to pause updates, revoke credentials, isolate affected systems, rebuild from known-good images and preserve evidence. Decide who can make those calls before the incident, when calendars are calmer and nobody is learning what BGP means from an urgent group chat.

What founders should ask before the next release

You do not need to audit the global routing table. You do need clear answers from the people building and operating your product:

• How does the application verify the identity and integrity of an update?
• Where are signing keys held, and who can use them?
• Can distribution infrastructure publish an unsigned release?
• Can we identify every environment that installed a particular artefact?
• What happens when verification, download or installation fails?
• Can we revoke credentials and rebuild a compromised environment quickly?
• Which suppliers sit inside our production trust chain?

These questions apply well beyond server control panels. Desktop apps, mobile releases, plugins, infrastructure agents, AI model packages, container images and internal deployment tools all move executable material from somewhere else into a system you care about.

Product readiness includes the boring machinery

A prototype proves that a feature can work. A production product must also prove what it will trust, how it will change and how it will recover when a trusted path fails.

That machinery rarely appears in a launch video. There is no tasteful animation for signing-key custody, and observability dashboards tend not to attract standing ovations. Yet these controls decide whether a supplier incident becomes a contained investigation or a week of rebuilding systems while issuing statements written by committee.

Venturist product audits examine this operational layer alongside application security, architecture, deployment, monitoring, backups and maintainability. The aim is not to eliminate every possible failure. It is to remove single assumptions that can turn someone else's compromised route into your compromised product.

If your update process currently depends on “the URL looked right”, show Venturist what you have built and arrange a practical product audit before that assumption receives an unscheduled production test.