AI just found thousands of zero-days. Your firewall is still pattern-matching from 2014

Christopher Karatzinis — Fri, 10 Apr 2026 15:31:48 +0000

Anthropic just announced Claude Mythos, a LLModel so good at finding software vulnerabilities that they decided to keep it under lock and not release it publicly. While testing it, it unearthed thousands of high-severity zero-days across every major OS and browser. Some of them include a 27-year-old bug in OpenBSD (for some, the most secure OS out there), a 16-year-old flaw in FFmpeg and a memory corruption bug inside a memory-safe VMM. Some companies managed to get access (AWS, Apple, Google, Microsoft, NVIDIA, the Linux Foundation, JPMorgan, CrowdStrike, Palo Alto, Cisco, Broadcom) but not me or you! We have to wait for ... another life? (Full story: https://thehackernews.com/2026/04/anthropics-claude-mythos-finds.html)

It is natural to say "forget the press release", Anthropic is a responsible company but the interesting fact is the capability and the bugs exist and we only have to wait for the next LLM to reach the levels of Mythos without the safety brakes of Anthropic. Also certain nation states may already have something equivalent (or better) and obviously, they won't tell us.

Up to now, the economics of vulnerability discovery used to favor defenders: bugs were expensive to find, expensive to weaponize, and most attackers reused the same handful of public exploits. AI flips the curve. Discovery gets cheap, weaponization gets easy, the pool of "attackers using novel techniques" stops being a tiny elite and becomes the average Mirai operator with a GPU. Anyone with a basic knowledge of how to use claude code can become the next Project Zero researcher.

"But I have a firewall"

Most teams I talk about told me: probing for live services is just background noise (the most valuable resource is categorised as background noise???). I have super-configured a firewall, moved ssh to port 2222, I'm hidden behind cloudflare, I don't run anything on my server except a web project and ssh. Done, right?

That stack only works against threats that announce themselves on ports you're watching and more importantly with signatures you already know. It does nothing about:

A scanner hitting port 6379 with a Redis exploit you've never seen.
A new Confluence RCE landing 30 minutes after disclosure.
A pivoted attacker already inside your network probing your internal services.
A model driven scanner that doesn't brute force anything, it just walks straight to a real vulnerability on the first try, the way Mythos walked straight into 27-year-old OpenBSD code.

A firewall is a list of "no". It can't tell you who tried or what they tried or whether they came back from a different IP an hour later. It is an access control and not a detection system. This is the reason why sysadmins end up surprised in incident reports.

Detection is the missing half

What you actually want is two layers:

A door that's locked (firewall, hardening, patching).
A motion sensor on the lawn (something that sees the attacker before they reach the door, and tells you who they are).

The motion sensor is the half almost nobody has. It's the half that matters most when the attacker has new tools you've never seen. Because you don't need to recognize the exploit to recognize the behavior. Someone scanning your Redis port isn't your customer and will never be. Someone hitting fake SSH on a random VPS at 03:14 UTC isn't your sysadmin. You don't need a CVE to ban them but you still need to see them. This is what tarpits and honeypots are for and it's an embarrassingly old idea that most sysadmins still don't run.

Where TarPit.pro fits

Disclosure: I build TarPit.pro. It exists because I got tired of explaining this to people one server at a time. It's a single binary you drop on a server. It opens believable fake versions of the services attackers love — SSH, MySQL, Redis, Postgres, FTP, Telnet plus 70+ others (you can configure as many as you want) and does three things:

Catches anything that touches them. Real users have no reason to connect to a fake Redis on a server they don't manage. So every connection is hostile by definition. No false positives, no rule tuning.
Tarpits them. Holds the connection open, wastes their scanner budget and slows down whatever automated sweep they're running.
Bans them automatically — and on paid tiers, propagates that ban across every server in your fleet. One server catches a scanner, the rest of your fleet is already protected before the attacker gets there.

You get the data a firewall will never give you: who is hitting you, what they're trying, when, and where they're coming from. That's the half of security that turns "we got owned by a zero-day" into "we banned them at 03:14, here's the log."

Tarpit.pro runs on Linux, macOS and Windows. Free tier is a single binary + cloud dashboard, no Docker, no agent stack, no YAML safari. You can install it in about 60 seconds. Just visit https://tarpit.pro

Mythos is a glimpse of where attacker tooling is going. Cheap, fast, novel exploits at scale. The defenders who do fine in that world are the ones who stop relying purely on prevention and start running detection — actual eyes on the wire, not just a hardened door.

Firewalls are necessary. They are not sufficient. They have not been sufficient for years. AI just made the gap impossible to ignore.

How a passwordless Redis install led to a full rootkit and why I started running honeypots to protect my servers

Christopher Karatzinis — Wed, 08 Apr 2026 17:13:59 +0000

Everyone in my company talks about wp-login brute force, Wordfence, Sucuri, fail2ban to protect our customer servers. All of them are all great tools for protecting the door … unless you have broken windows. All these tools only see port 80/443 and they don’t care about the other 65,000 ports on your server. What caused me to add honey traps that fully block bad guys? One of my wordpress customers installed redis to check some speed improvements. Instead of talking to us, they decided to do some testing so they used some AI tool that installed a passwordless redis. A “lucky” probe found it and the hacker executed RCE. All those in just a few minutes that their test lasted! By the time we discovered it, it was too late. Rootkit was installed and my team had to spend a lot of time wiping out the whole server and recovering from backups.

The speed of the hack was amazing, but this is what you can expect from automated probes with nasty payloads. No amount of tools can beat misconfigurations and honest mistakes. I am a firm believer of processes: you can fix a process you can’t fix a person (especially developers). That’s why I decided to create the tarpit for our own use. Tarpit is effectively a personal honeypot. But instead of collecting information from attackers (not very useful to my customers) it does something else: it opens a bunch of ports that usually host legitimate software (like redis, mysql, postgres, irc, telnet, etc). When something connects to these ports, it gives you a realistic prompt and expects a reply. Then the fun starts: firstly, it delays the response… 3 seconds per character. If they’re unlucky enough to hit our honey trap, we might as well waste as much of the probe’s time as possible. Every second they spend stuck in our fake service, is a second they are not using to hit someone else (even if we don’t own the servers). Secondly, the moment they disconnect, the local firewall (whatever is available based on OS: win, mac and linux) grabs their IP and blocks them from all the services on that server for 24 hours (auto-clear). Thirdly, it shows on the dashboard map where the attack originated and keeps all the attack data. Finally, in cases where someone owns many servers (like in our case), the attack IP is propagated to all our fleet of servers: a bad IP is a bad IP - so they will never be able to hit anything else anywhere on our “micro universe”.

Looking at that, I thought: I bet more people might need this and it gave me the idea of a saas product: tarpit.pro - democratization of honeypot for server protection. There is an AI layer that proposes permanent bans depending on various patterns. After running it on 5 servers for 20 days, the numbers speak for themselves: ~40k attacks, ~14k unique IPs, ~5k auto-banned. SSH gets hammered the most (14k hits), then Telnet (yes, Telnet in 2026: 3.2k hits), then SMB…. Top source countries: US, China, UK, Hong Kong, Netherlands (I’m really surprised from this list, I was expecting a completely different mix). Most tried passwords: 123456, admin, password, foobared, the same Redis default that started this whole story. The first attack showed up 90 seconds after going live.

If you want to see what's hitting your servers: tarpit.pro . We offer a usable free tier for 2 servers - free forever including a web dashboard. You can use the code LAUNCH100 that will allow you to test the Pro for up to 4 servers for a month, so you can play with firewall rule propagation and all the other nice features of Pro.

DEV Community: Christopher Karatzinis

AI just found thousands of zero-days. Your firewall is still pattern-matching from 2014

"But I have a firewall"

Detection is the missing half

Where TarPit.pro fits

How a passwordless Redis install led to a full rootkit and why I started running honeypots to protect my servers