Where software is weak, how that weakness has been used, and what you can check and change yourself. Backed by public records, advisories and the vendors’ own documents.
Some software has a long record of being broken into.
That record is public. Anyone can read it, count it and check it.
These posts read that record and say what it means for you.
They cover:
How often a product has had serious flaws, counted year by year.
Which flaws let an attacker in without a password.
How the way a product is usually installed makes each flaw worse.
What you can check on your own systems, and what to change.
Every figure links to its source, so you can check it yourself.
A Static Site Has Nothing To Break Into
This blog is built with Hugo and served as 6,343 plain files, with no code of mine running on any request. Against it, a stock WordPress 7.1.3 measured in a podman lab: 133 REST routes, 62 of them accepting writes, 80 XML-RPC methods, 1,514 PHP files, every one of its 3,785 files writable by the web server’s own user, and a database account holding every privilege. This post counts both attack surfaces, explains what Hugo’s own security model does at build time, owns up to where the risk moves once nothing runs at serve time, including two gaps in how this site was built, one of them now fixed, and sets out how to build a static site offline, once, and upload nothing but the finished files.
PHP: Twenty-Nine Years Of Leaving The Door Open
PHP2Shell, disclosed on 21st October 2026, is unauthenticated remote code execution in the PHP interpreter itself, every version back to 5.4, exploited before the patch existed. It is the latest entry in a long record: 757 CVEs against the interpreter since 1997, at least 288 of them memory corruption and 172 rated as full remote compromise without a login. This post counts that record from NVD and the CISA KEV catalogue, explains why a C engine and a language that took a decade to remove register_globals make the same mistake twice, looks at what WordPress does to the numbers, how web shells stay put and how to stop them, the two times php.net itself was broken into, the share of the web still running versions nobody patches, and why the usual deployment, one process holding the templates, the logic, the SQL and the database password, turns every one of those bugs into everything. And why, having given up on PHP myself, I think you should look at leaving it for a memory-safe language such as Go.