Mirai is not one botnet, it is a codebase
Mirai's source was released publicly in 2016 and has been forked, patched and rebuilt by hundreds of unrelated operators since. What most people picture as "the Mirai botnet" is really a family of derivative builds that share an architecture: a large population of compromised embedded devices, and a much smaller number of command and control servers that those devices call home to.
That asymmetry is the interesting part. The bot population is disposable. The operator expects to lose devices to reboots, firmware updates and ISP filtering, and the loader replaces them. The command and control server is not disposable in the same way. It is the single point at which an operator issues attack instructions to the fleet, and it is usually a small piece of purpose built C code running on rented infrastructure with very little hardening around it. Attacker tooling is software, written under deadline, by people who are not being audited. It has bugs like anything else.
What CVE-2024-45163 actually is
The published record is short, and worth reading at face value rather than dressed up. Per NVD, Mirai through 2024-08-19 mishandles simultaneous TCP connections to the command and control server. Unauthenticated sessions remain open, which consumes resources on the server. An attacker, or in practice a defender, can send a recognised username such as root, or can send arbitrary data, and the session is held.
NVD scores it CVSS 9.1 with vector AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H. Reading the vector rather than the number tells the story: network reachable, low complexity, no privileges and no user interaction required, no confidentiality impact at all, but high integrity and high availability impact. Nothing is read out of the server. The server stops being able to do its job.
The mechanism is not exotic. There is no bounded pool of session handling threads and no timeout that reclaims a connection which has authenticated to nobody. Open enough of them and the process can no longer service the ones that matter, which are the bots checking in and the operator issuing commands. The fleet is still infected. It just has nobody to take orders from.
Calling that a kill-switch is a description of the effect, not a claim about elegance. A defender with the details can reach a command and control server that is pointed at their network and make it stop functioning, without touching a single compromised device and without needing credentials for anything.
Why a flaw in attacker infrastructure is an unusual thing to publish
Most vulnerability research points at software that a vendor ships to customers. The disclosure path is well worn: find it, tell the vendor, agree a timeline, the vendor patches, the advisory publishes, customers update.
Offensive infrastructure has no vendor and no patch cycle in that sense. There is nobody to notify and no responsible party to coordinate with, which changes what disclosure is for. Publishing a defect in command and control code does not protect the operator's users, because the operator has no users. It gives defenders and incident responders a documented, citable property of a thing they are already fighting.
It also reframes what a botnet is. Treating attacker infrastructure as an attack surface in its own right, with the same assumptions you would apply to any other network service, is a habit rather than a trick. You look at what is listening, you look at how it handles state, you look at what happens when the thing that is supposed to bound a resource is missing. That is the same pass you would run over a client's exposed service.
What this changes about how a penetration test gets run
A vulnerability scanner is a matching engine. It fingerprints a service, compares what it sees to a signature database and reports the overlap. That work is genuinely useful, it is fast, it should be running continuously, and it will never find a bug that nobody has written a signature for yet. Both findings described here are, by definition, things a scanner could not have reported on the day they were found.
What research practice changes about testing is mostly a set of defaults.
You enumerate what is listening rather than what is inventoried, and you treat the difference between those two lists as a finding in itself. You treat embedded and appliance devices as in scope rather than as furniture, because that is where firmware quality is lowest and patch cadence is slowest. You test how a service handles state and resource limits, not only whether it has a known CVE, because missing bounds do not have signatures. And when something behaves oddly under load or under a connection that goes nowhere, you follow it rather than filing it as a flaky result, because that is exactly what both of these findings looked like before anyone understood them.
TrazTech has five published CVEs, all listed with their advisories on /research. The count is five. The relevant fact for a buyer is not the number, it is that the person who found them is the person who shows up to the engagement. Jacob Masse is the Principal and does the testing. Ask any firm whether the researcher whose credentials appear in the proposal is the one performing the work, because those are frequently two different people.
Scope, duration and depth vary by client, and we set them during scoping rather than off a template. How that gets structured for a given environment is covered under security services.