The Lock Was Set to 004

One of a certificate authority's private keys was the number 4.

Not a long number beginning with 4. Just 4. Security researcher Scott Helme recovered eight weak keys from publicly available certificates on his laptop in less than a second.

A certificate is a website's digital identity document. A certificate authority is an organisation your software trusts to sign that document. Its private key is the secret used to make the signature. If someone else can work out that secret, they can make certificates carrying the authority's signature too.

The authority was eMudhra. On October 17, 2026, a researcher reported the weak keys to the company and the major browser makers. eMudhra acknowledges a script error produced them. This was a failure in creating the keys; nobody needed to steal them first.

The number is what caught my attention. But the question I wanted answered was simpler: what could someone actually do with it? I am not a cybersecurity expert. I wanted to understand what this meant for people using these systems, including me.

The problem was not 4 by itself. All eight secrets were small enough to find by trying no more than 255 numbers. Figure 1 compares that with a key of the same type (P-384) made the proper way, from a random number.

Think of a combination lock set to 004. A strong box does not help much if someone can try every combination in seconds. (The real key was just 4. The zeros belong to the lock picture, not the key.)

Figure 1 also shows how a guess is checked. Every secret number produces a public key, and the certificate shows its public key to everyone. So you turn each guess into a public key and compare. When the two match, you have found the secret.

Finding the key does not reveal everyone's passwords. It lets an attacker make fake identity documents for websites. More has to go wrong before anyone's data is actually caught.

Imagine an application connecting to Stripe, the payments company. This is a hypothetical example of the consequence, not a report that Stripe was breached.

1. The attacker makes a false certificate. It names Stripe's address, but the attacker signs it using the recovered authority key.
2. The attacker redirects the connection. They also need a way to make the application reach their server, for example through control of the network path or the service that translates website names into addresses. Knowing the key alone does not do this.
3. The application accepts the false identity. This only works if the software still trusts the affected authority and no other check catches the fake.
4. The application sends data to the attacker. The connection can be encrypted and still end at the wrong person. The attacker could read the requests sent over it, including any passwords or API keys they contain, or change the replies. They might pass traffic on to the real service to keep the exchange looking normal.

Figure 2 puts those conditions together. Encryption keeps a connection private, but only between you and whoever is at the other end. The certificate check is what tells you who that is. If that check is fooled, encryption cannot help.

In Helme's controlled test, his command-line and programming clients accepted a certificate for Stripe's address; Chrome rejected it.

Chrome's own account explains why its users were protected. It blocked the affected website-signing keys on October 17. Chrome also requires certificates to be listed in public records called transparency logs, and no certificates from those issuers had been listed there before the block. So a correct signature alone was never enough to fool Chrome.

Software outside the browser can work differently. A script might use an old built-in list of trusted authorities and never check whether a certificate has been cancelled. Updating your browser does not update every script, application or server. This is also a moving situation: Node.js's October 21 release included a certificate-store update for this incident. It would be wrong to say that all those tools still trust the keys.

The keys had been weak since April 2025. That alone does not tell us whether anyone found or misused them before the report. It also does not mean an attack would leave no trace. eMudhra says its investigation has found no compromise of its infrastructure or customer data.

The scale comes from that shared trust. One authority can vouch for many unrelated websites, and many applications can rely on its signatures. A weakness there can reach beyond one company's own website. That is the potential reach, not a count of people actually harmed.

The rest of the week exposed other places where we rely on someone else's checks.

The next three problems were in software that runs behind websites and apps. In each one, a specially made request or file could make the software do something its owner never meant it to.

• PHP is a programming language used by many websites. Its maintainers published two critical security advisories on October 21. One was about what happens when a request runs out of memory; the other was about data left behind by an earlier request. In some setups, an attacker could make the server run their code without logging in. Think of a shared workbench where one job encounters dangerous material left by another. The exact exposure depends on how PHP is deployed, so this does not mean every PHP website was successfully attacked.
• GitLab helps developers store code and manage their work. Its October 21 patch notice describes a text-processing flaw that could let someone run code on an affected server without an account. GitLab.com was patched; people hosting their own installations needed to update.
• Node.js runs JavaScript outside the browser, including on this site's server. Its October security release fixed a flaw in Brotli, a format that makes data smaller for transport. If an application unpacked a maliciously constructed Brotli file, the unpacker could damage its own working memory. That could crash the program, leak data from memory, or let the attacker run their own code. It only mattered for applications that actually unpacked a file like that.

These are reasons to patch affected software, but also to know who is responsible for it. A visitor cannot update a shop's server by refreshing the page. The shop's operator or hosting provider has to apply the fix.

AI showed up on both sides. The PHP and Node.js advisories credit AI security researchers; Railway describes attackers using AI. The tools can help find weaknesses or exploit them. People still decide how they are used and whether a finding is acted on.

Updating is necessary. But an update is also how new code gets into your system, and that path can be hijacked.

On October 21, a malicious release of LiteLLM, a library that helps AI applications connect to different model providers, appeared in its normal distribution channels. The incident notice identifies version 1.107.0. It contained malware that stole passwords and keys, and let the attacker run more of their own code. The Python package was available for roughly two hours; affected container images (ready-to-run packaged copies of the software) stayed up longer.

The project's completed attack-chain report explains how it got there. A powerful access key had been published accidentally in May. The file was removed from public view, but the key itself was never switched off. The attacker used it to get into an agent platform, took a GitHub access token belonging to one of the project's owners, and gained more access from there. With that, they changed where a release was built from and got their poisoned version published.

The delivery-box analogy fits here. The box arrives through the supplier you recognise, but somebody has gained enough control of the warehouse to change what is inside it.

That does not make "never update" a sensible answer. Updating, and protecting how releases are made, are two different jobs. It also shows why deleting a leaked key from a file is not enough: the key itself has to be switched off.

Then there are the platforms you deliberately give secrets to because your application needs them to run.

Railway hosts applications and stores their configuration, including database passwords and API keys. An API key is a credential that lets software use another service, often with access or spending attached to it. In its preliminary incident report, Railway says an attacker obtained encrypted customer secrets and could open some of them using other stolen credentials. It recommended that customers who signed up before October 21 replace the keys they had stored there: switch off the old ones and create new ones.

Encryption still matters. But a service that uses your secrets must also be able to open them, so who can get into that service matters just as much. Locking a cupboard helps until someone gets both access to the cupboard and the key that opens it.

OpenCode's hosted Console leaked the AI provider keys people had saved in it; its open-source app was unaffected, according to its co-founder's statement reported by TechCrunch.

Using a coding tool and storing credentials in its hosted service are different choices. A saved key lets something act for you. That ability needs protecting.

My own version of this is smaller. I recently set up Tailscale so I could reach my Mac from my phone. Tailscale creates a private network between approved devices. Heeler gives me access to my terminal sessions over that connection. It works well, and the convenience is real.

Then I read the Tailworm research report, which describes problems in particular Tailscale and headscale features. These are problems the researcher reproduced in a test lab. The remote-login (SSH) findings only apply when someone already has approved access and particular features and permissions are switched on. They do not show that every private network has been broken into.

My setup uses the Mac's ordinary SSH service, a way to log in remotely, rather than Tailscale's built-in SSH server. So those particular findings matter less for me. That does not mean my whole setup is safe. My phone can reach a machine that holds my work. I need to think about what happens if a device or its access is compromised, not just whether the connection works.

I am doing what I can, including asking AI agents to help review my systems. For months I have asked them to improve security. That has produced audits, hardening notes and checklists, but asking for security and checking each change are different things.

I recently installed an audit skill from Cloudflare's repository. A skill guides an agent through a task. I had its code checked and locked my copy to that exact checked version. That prepares for an audit; it does not mean my applications have passed one.

There is a further problem I cannot resolve just by installing a tool. The auditor is software too. It has its own code, instructions and updates. I still have to check what it does and verify its findings. An AI answer is a place to start investigating, not a certificate of safety.

I want my systems to be safe. I do not think I can honestly promise that they will stay safe. A flaw can exist for years before anyone notices it, and a useful tool can introduce a risk I had not considered.

What I can do is make the checking more deliberate. If you build or run something, start with a rough drawing of your own setup. A diagram is useful when it helps answer concrete questions:

1. What runs where? Draw the devices, applications and services, and connect the ones that talk to each other.
2. Who or what has access? Mark where credentials are stored and what they allow. Use labels, never the actual passwords or keys.
3. What happens if one part is compromised? Ask what else it could reach, who would notice, and how you could cut off that access.
4. Who checks it next? Choose who applies updates, reviews findings and checks that the changes actually worked. An agent can help, but someone still has to verify the result.

I would rather read one relevant security source regularly, or use an agent to flag reports affecting what I run, than keep scrolling through warnings with no connection to my systems.

Fireship's video, The most vulnerable week in internet history, prompted this piece. Its title is a framing, not a measured ranking. The incident links here lead to primary reports where available; the OpenCode account is secondary reporting.

A certificate authority vouches for a website's identity. If its secret is easy to recover, that assurance can be copied. Shared trust lets one failure travel far; it does not prove every user was attacked.

I want to understand whose trust failed, who could be affected and what needs checking. I can draw my setup, question the access I have given it, and check what changes.