Secure by Design

The month the internet flinched

Every so often, the digital world stops pretending it is invincible.

October 2026 was one of those months — a stretch so bad that security researchers have started calling it "Black October." Across a single busy week, the people who keep the internet running watched failure after failure roll across the systems we all quietly depend on.

It started with the runtimes and servers the web is built on. Researchers disclosed two critical flaws in PHP — CVE-2026-109618 and CVE-2026-109619, each rated a severe 9.2 — that let an attacker run their own code on a web server without logging in at all. The details leaked a day before the patch was ready, and within hours real-world attacks began. Node.js shipped urgent fixes for ten vulnerabilities, including one that could execute code through compressed data and others that weakened TLS and DNS checks. Java patched fifty-five flaws, forty-nine of them remotely exploitable. Even the plumbing of anonymity was not spared: hijacked Tor relays were caught intercepting SSH traffic.

Then it reached the layer of trust itself. The AI gateway LiteLLM had a malicious version pushed to the world's package registries. OVHcloud's official command-line tool was found shipping backdoored binaries. The cloud platforms Railway and Zeabur disclosed breaches that exposed customer credentials, API keys and database passwords — Zeabur citing more than 321,000 affected accounts. And most unsettling of all, the certificate authority eMudhra was found to have eight intermediate signing keys so weak that researchers cracked them almost instantly — forcing Mozilla, Google and Apple to block the certificates worldwide (CVE-2026-111943).

Online, someone summed up the mood in five words: "one-third of the internet is broken." An exaggeration — but not by as much as we would like.

What these threats actually are

Behind the logos and the jargon, almost all of October's failures fall into four plain-language categories. Understanding them is the first step to not fearing them.

Remote Code Execution (the PHP and Node flaws). This is the nightmare scenario. "RCE" means an outsider can make your server run their instructions — install malware, read your database, take over the machine — often without any password. A single unpatched web server with an RCE flaw is an unlocked front door. That is why the PHP flaws, scoring 9.2 out of 10 and needing no login, set off alarms everywhere.

Supply-chain attacks (LiteLLM, OVHcloud's CLI, the poisoned packages). Modern software is assembled, not written from scratch — every app pulls in hundreds of ready-made components. A supply-chain attack poisons one trusted ingredient at the source, so everyone who installs it is compromised at once, through the front door they opened themselves. You did everything right and still got hit, because you trusted a tool that was quietly turned against you.

Certificate-authority compromise (eMudhra). When your browser shows a padlock, it is trusting a "certificate authority" to vouch that a website really is who it claims to be. That trust is the foundation of every secure connection online. When a CA's secret keys leak — as eMudhra's did — an attacker can forge that proof and impersonate banks, governments, anyone. It is not one broken lock; it is a broken locksmith, and every door he ever made is now suspect.

Credential and secrets exposure (Railway, Zeabur, SBI). The keys, passwords and tokens that systems use to talk to each other are the crown jewels. Leak them, and an attacker does not need to break in — they simply log in as you. Worse, rotating a leaked key usually requires a redeployment, and at Railway deployments were frozen during the incident. The lock was fine; someone copied the key.

None of these are exotic. They are the ordinary consequences of an extraordinary pace.

Why a wave like this reaches every government

Here is the part that should concern every public institution, including ours.

Governments do not run on a separate, special, safer internet. They run on the same PHP, the same Node.js, the same web servers, the same cloud platforms and the same certificate authorities that failed in October. A flaw in a shared ingredient is not one vulnerability — it is the same vulnerability sitting inside thousands of government systems at once, from tax portals to land records to health databases.

That is why a single bad week can ripple into public life around the world. When a certificate authority is compromised, every service that trusted it — including government ones — may have to be treated as impersonable until certificates are replaced. When a critical RCE is disclosed with active exploitation, the safe response is often to take public-facing systems offline to patch them before an attacker gets in — a precautionary shutdown, chosen as the lesser harm. It is not that every government "fell." It is that a wave like this forces hard choices everywhere at once: patch in a panic, or pull the plug to stay safe.

And the stakes are not abstract. Think about it:

• Government — what happens when citizens' identities, public records, or essential digital services are compromised, or must be taken offline to protect them?
• Healthcare — what happens when a hospital loses access to critical systems, or to sensitive patient information?
• Banking and finance — what happens when financial data, credentials or transactions are exposed?
• Businesses and startups — what happens when one poisoned dependency or leaked cloud credential undermines an entire platform?
• AI and emerging technology — what happens when we accelerate innovation without securing the systems and supply chains behind it?

These are not IT questions. They are questions about human trust, human safety, and human lives.

Why this matters more for a country like ours

It would be easy for Nepal to read a list of foreign breaches and feel like a bystander. That would be a mistake.

We are digitising fast — government services, health records, payments, identity. Every one of those systems inherits the same software, the same clouds, the same open-source dependencies, the same certificate authorities that failed in October. We do not get a separate, safer internet. We get the same one, and we carry the same risks — often with thinner margins and fewer specialists to absorb the blow. A backdoored tool, a poisoned package, a leaked key: none of them check your passport at the border.

The lesson is not "slow down." Nepal cannot afford to slow down. The lesson is build it right the first time, because retrofitting security onto a live national system after a breach is the most expensive and painful way to learn it.

What must actually change

At DigiNepal, we did not arrive at this view after October. We built the platform around it — government to health, payments to AI, on infrastructure we can stand behind. These are the principles I believe every serious digital effort, public or private, now has to adopt:

1. Security by design, not as an afterthought. Security belongs in the architecture, the code, the deployment and the daily operation — from day one, not after the first incident.

2. Modernise before old systems become liabilities. Stay on supported technologies. Patch promptly. Continuously assess what your dependencies actually are — you cannot defend what you have forgotten you are running.

3. Adopt Zero Trust. Never assume access is safe. Verify identities, enforce least privilege, and design so one compromised credential cannot bring the whole house down.

4. Secure the software supply chain. Review third-party components. Protect your CI/CD pipelines. Verify releases — yes, even the "official" ones. Treat secrets management as a first-class discipline. October was, above all, a supply-chain month.

5. Build resilience, not just defences. Assume something will eventually get through. Continuous monitoring, tested backups, rehearsed incident response and real recovery plans are what turn a catastrophe into an inconvenience — and what let you patch without pulling the plug.

6. Make cybersecurity a leadership responsibility. Security is not the IT team's problem to carry alone. It needs budget, accountability, policy, and a security-aware culture that starts at the top.

The real measure of transformation

I keep coming back to one line, because I think it is the whole argument in a sentence: digital transformation without digital trust is incomplete.

True transformation is not measured only by how quickly we ship new technology. It is measured by how safely, how reliably, and how responsibly we deliver it. The platforms — and the governments — that will still be standing a decade from now are not the ones that moved fastest. They are the ones that earned, and kept, the trust of the people who depend on them.

Black October was a wake-up call the world did not ask for but badly needed. For those of us building Nepal's digital future, the right response is not fear. It is resolve.

Let us evolve with technology. Let us modernise with purpose. And above all, let us build systems that are secure by design, and resilient by default.

The future belongs not to those who innovate the fastest — but to those who innovate responsibly.

You cannot protect what you cannot see

Read back the roll-call of October 2026 and a quiet pattern emerges. A backdoored command-line tool. A poisoned package pulled onto thousands of machines. A certificate key compromised at the root. Almost none of it began with a dramatic break-in. It began on an endpoint — a laptop, a server, a workstation — running something nobody was watching closely enough.

That is the uncomfortable gap in most organisations. They know their mission, their people and their data. They do not always know, at any given moment, exactly which machines are on their network, what software those machines are running, whether they are patched, or whether one of them is quietly doing something it should not. And you cannot protect what you cannot see.

SecInv — the Security and Management Console we built inside the NIHIS health-information programme — exists to close that gap. It is an agent-based endpoint management and security tool: not a dashboard of guesses, but a live, verifiable picture of a real fleet of devices, and the controls to act on it.

How it actually works

Every managed device runs a small agent. On first contact it enrolls using a client certificate, and from then on every conversation between the device and the console happens over mutual TLS — both sides prove who they are, every time. There is no shared password to leak, no anonymous device quietly checking in.

Once enrolled, the agent periodically reports what the machine actually is: hostname and platform, operating system name, version and build, CPU and cores, memory, disk capacity and free space, network addresses, manufacturer, model and serial — and the full list of installed software, by name, version and publisher. That inventory is the foundation everything else stands on, because the first question in any incident is always the same: which machines are affected, and what are they running? With SecInv, that is a query, not a week of frantic phone calls.

On top of the inventory sits security posture — the compliance checks that tell you whether a device is in the state it is supposed to be in. And when something needs to change, the console does not send a polite request. It issues a signed command — inventory refresh, reboot, run a script, open a remote session, view the screen — cryptographically signed so the agent can verify it came from the console and nothing else. A compromised network cannot forge an order to a machine.

Built for how real organisations are shaped

Few institutions are a single flat fleet. A health-information exchange is dozens of facilities, each with its own devices, its own staff, its own responsibilities. SecInv is multi-tenant by design: every device, user and policy belongs to an entity, and the console scopes what each person can see to the entity they are responsible for. Access is role-based — a viewer sees; an administrator acts — so the power to reboot a machine or push a script is never handed out by accident.

The console itself is deliberately plain: Dashboard, Devices, Agents, Entities, Policies, Users. No theatre. Just the few things a security team actually needs to answer at 2 a.m. — what do we have, what state is it in, and what can we do about it right now.

Why this belongs in a story about October

The breaches of last month were not, mostly, failures of firewalls. They were failures of visibility and control — of not knowing what was running, not verifying what was trusted, not being able to move fast when it mattered. Every principle in the companion piece to this article — know your inventory, verify your supply chain, adopt zero trust, build to recover — lands on the same hard surface: the endpoint.

SecInv is one answer to that, and it is the kind of answer I believe in — not bolted on after a breach, but secure by design: identity proven with certificates, commands signed, access scoped, inventory continuous. It will not make an organisation invincible. Nothing will. But it replaces the dangerous comfort of "we think we're fine" with something far more useful on the day it matters: we know.

That is the whole point. In a month that reminded the world how little it sometimes sees of its own systems, the quiet advantage goes to those who can answer, honestly and instantly, a single question — what is actually running on our machines?