We found 35 vulnerabilities in our own website

What we found

On 4 August 2026 we ran a routine check on this website — the one you are reading. One command, composer audit, which compares the components the site runs on against a public list of known vulnerabilities.

The result: 35 known vulnerabilities across 13 components. Among them a flaw that could have allowed unrequested database commands to run, and another that made the email-sending module abusable.

None of them were ours. They were all third-party components — building blocks that nearly every modern website uses, made and maintained by open source projects. Which is exactly why this is not a story about sloppy code. It is a story about something every website has and almost nobody checks.

Why it sat there for two months

This is the uncomfortable part to write down.

Every change to this site runs through four automated checks. They verify that the code works, that it is written consistently, that it holds no logical errors, and that every test passes. If one fails, nothing reaches production. That system works and has caught plenty of careless mistakes.

None of those four looked at the components our code rests on. They checked our own work, not the foundation beneath it.

Something had in fact spotted it. An external scan had flagged the vulnerabilities and dutifully filed a task. That task sat for two months while work carried on and releases kept going out.

There is the lesson, and it reaches beyond software: a notification is not a check. Something that warns but does not stop anything disappears into the pile. Something that stops things gets fixed.

What we did about it

The first round resolved 24 of the 35. The patch already existed — it was the very task that had waited two months. But because it had sat so long it was itself out of date: eleven new advisories had appeared in the meantime. Those were cleared in a second round.

The count is now zero. But the change that matters is a different one: that same check now runs automatically on every change, and it blocks. If a vulnerability is discovered tomorrow in a component we use, nothing ships until it is resolved.

That is less comfortable day to day — a release can now stall on something somebody else caused. That is precisely the point.

How to find out about your own software

You do not need to be technical for this. These four questions to whoever maintains your software produce an answer within a day:

• Is there an automated check for known vulnerabilities in the components we use? Most platforms have a standard command for this that runs in seconds. "We keep an eye on that" is not a yes.
• Does that check block a release, or does it only produce a notification? This is the core of it. Keep asking until you hear the difference.
• When did it last run, and what came out? A date and a number. Ours was 4 August 2026 and 35.
• How long does it take before a reported vulnerability is resolved? Not "quickly". An agreement: critical within a week, the rest at the next release.

A supplier who answers these directly has it covered. One who deflects to "our hosting handles that" or "that is what the firewall is for" is answering a different question. A firewall guards the door; this is about what sits on the shelves inside.

What this check does not cover

Honestly about the limits, because this tool is narrower than it sounds.

composer audit and its equivalents only compare against vulnerabilities that have already been discovered and published. They say nothing about flaws in your own custom code, nothing about weak passwords, nothing about an employee clicking a phishing link, and nothing about a hole nobody has found yet.

So it is not a security guarantee. If a component turns out to be unpatchable, that is incidentally the one replacement signal with a hard deadline. Beyond that, this is the cheapest, most automatable floor that exists — and that is exactly why not laying it is indefensible. We had four other checks running and not this one, and that is precisely how something stays unnoticed for two months.

What this says about how we work

We could have written this piece without mentioning our own part in it. It would have said that we take security seriously and that we scan for vulnerabilities — both true, and both meaningless.

This is more useful: the command is public, the result is verifiable, and the lapse was ours. You can ask today when it last ran on your own software. If the answer does not come, you know enough — and knowing is worth more than any promise about security.