An AI Model Completed a Full Network Intrusion in Government Testing. Audit Your Open Ports

The UK AI Security Institute and the US Center for AI Standards and Innovation published a joint assessment this week of Kimi K3, a Chinese open-weight model whose weights are scheduled for public release on July 27. In their network attack simulation, the model completed a full 32-step intrusion end to end in one of ten attempts, and the institutes concluded it poses a real threat to "small, weakly defended and vulnerable enterprise systems." That phrase describes a large share of the servers run by solo founders and small teams. If you operate your own VPS, the response fits in about an hour: list every port your machine answers on, firewall everything except your product and SSH, and get your databases off the public internet. The exact commands are below.

What government testers actually saw

The preliminary assessment (checked July 25, 2026) is worth reading precisely because it is not hype. Kimi K3 is not a frontier cyber weapon: it scored 32% on the institutes' exploit development benchmark, failed to achieve arbitrary code execution on all 41 test samples where frontier models average 20, and on the 32-step attack simulation it reached step 17 on average against 28.5 for frontier models. The findings are preliminary, based on what the institutes call a small set of public and private benchmarks.

Three details matter more than the rankings. First, the model outperformed GLM-5.2, the previous leading open-weight model, so the freely downloadable tier keeps climbing. Second, its built-in safeguards "did not prevent it from attempting cyber exploit development or offensive cyber operations." Third, that one-in-ten full completion happened in a scenario modeled on weakly defended systems. Put together: a capability that used to require a skilled human attacker is about to be a free download, and it works best against exactly the kind of infrastructure small teams run.

The economics of being a small target

"Nobody would bother attacking us" was always an argument about attacker attention, not attacker capability. Human attention is scarce and goes where the money is; automated capability is cheap and goes everywhere. The same shift happened to payment fraud when business email compromise became an industrialized crime, and to credential leaks when scanners started finding shipped secrets within minutes. When the cost of running an attack drops toward zero, weak targets stop being protected by their obscurity, because nobody needs to choose them; a script does.

Sort every service into three buckets

Before touching commands, walk through everything running on your servers and assign each service one of three labels. This framework is ours; the facts underneath it come from the vendor docs linked below.

Never exposed. Databases (Postgres, MySQL, MongoDB), Redis, Elasticsearch, metrics dashboards, admin panels, message brokers. These listen on localhost or a private network interface, full stop. There is no hardening story for a database on a public IP; there is only a countdown.

Reachable through a tunnel. Internal tools you genuinely need from outside: staging environments, Grafana, database admin UIs. Put them behind WireGuard or Tailscale rather than a public port with a password. The service stays invisible to internet scans entirely.

Exposed and hardened. The short list that must face the internet: your product on ports 443 and 80, and SSH. These earn ongoing patching, key-based auth, and monitoring.

The one-hour audit

1. See what is listening (5 minutes). On each server, run ss -tlnp. Every line showing 0.0.0.0 or [::] is a service answering the whole internet. Expect surprises; that is the point of looking.

2. Turn on the host firewall (10 minutes). On Ubuntu, ufw ships disabled. Per Ubuntu's firewall documentation, allow what you need before enabling, then switch it on and verify:

sudo ufw allow ssh
sudo ufw allow 443
sudo ufw allow 80
sudo ufw enable
sudo ufw status verbose

If you are on a cloud provider, do the same at the provider layer, where the rules survive server rebuilds: AWS security groups, DigitalOcean Cloud Firewalls, or Hetzner Cloud Firewalls all default new rules to deny.

3. Fix Redis properly, not incidentally (15 minutes). Redis is the canonical example because its official security page is blunt: Redis "is designed to be accessed by trusted clients inside trusted environments," and a single FLUSHALL from an outside attacker deletes your entire dataset. Since version 3.2.0, protected mode refuses remote connections when Redis runs with the default config and no password, but it deactivates the moment someone sets a password or binds interfaces manually, which is exactly what tutorials tell people to do. In redis.conf: bind to loopback with bind 127.0.0.1, set a long password with requirepass (or use ACLs, the recommended method since Redis 6), and remember that AUTH travels in plaintext unless you also enable TLS. The same logic applies to Postgres and MongoDB: private interfaces, authentication required, no public listener.

4. Look at yourself from the outside (15 minutes). Shodan is a search engine that indexes internet-connected devices by crawling the internet itself and recording what each service announces. Search your server IPs and see what an attacker's tooling already knows about you. Shodan Monitor (monitor.shodan.io) will watch your IP ranges continuously and alert on new exposure. An nmap scan of your own IP from a machine outside your network gives a second opinion in real time.

5. Write down the rule that keeps it fixed (10 minutes). One line in your deployment notes: new services bind to localhost or the private network unless they are on the exposed list, and the exposed list has an owner and a reason per entry. Exposure is not a one-time cleanup; it is a default you set. This belongs in the same document as your platform dependency audit.

Two days

The gap between the assessment's publication and the July 27 weight release is the point of this piece. Once weights are public, capability does not degrade and cannot be recalled; the institutes have effectively published the "before" photo of the internet's next automated scanning wave. The work above requires no budget and no new vendors, just an hour before the weekend ends. Weakly defended is now a measurable category that models are tested against. The only move you control is not being in it.