Call of Duty 1 shipped in 2003, and its Linux dedicated server binary, cod_lnxded, is a 32-bit ELF with every standard exploit mitigation switched off: no PIE, no stack canary, no RELRO, executable stack. One evening, a researcher pointed an AI coding agent at that binary and walked away with a working remote code execution exploit. The game is trivia. The price collapse is the story.
What the agent actually did
The write-up comes from the zolder.io team, published 24 August 2026 as Part 1 of a three-part series called "Pentesting with AI." The author's framing is blunt:
"One evening I pointed an AI coding agent at the old Linux dedicated server binary, cod_lnxded, and asked a simple question: is there something in here that lets me run code on the box? There was."
The setup matters more than the target. The game server ran inside a disposable Docker container that the agent, Claude Code, could crash and restart at will. It had access to the binary and standard binutils, and it drove objdump and readelf while writing small scanning scripts of its own. It started with user-facing functionality, found nothing worth keeping, and then moved to the admin surface, the rcon remote console. That is where the bug lived.
The bug: 72 bytes and a missing bounds check
The vulnerable function is SV_Map_f, which handles the rcon map command. The map-name argument gets passed to a normalizer that copies it into a 72-byte stack buffer using memcpy, with the copy length taken from the attacker-controlled name. There is no bounds check. The saved return address sits at buf+76, so 76 bytes of map name plus four bytes of address is enough to decide where the function returns to. A textbook stack smash, reachable over the network.
The filter fight is the impressive part
Getting control of the return address was the easy half. The protocol's input routine, MSG_ReadString, rewrites bytes on the way in: some bytes get swapped, anything 0x80 or above becomes a dot, and a null byte terminates the string. That filter kills the usual exploitation options, because libc and stack addresses full of high bytes like 0xff and 0xf7 cannot survive the trip.
Since the binary has no PIE, .text lives down around 0x08, and those addresses pass through the filter cleanly. The agent pointed the overwritten return address at a jmp esp gadget in .text, landed on the executable stack, and wrote alphanumeric-safe shellcode that invokes execve("/bin/sh") through sysenter. It used sysenter because the opcode for the usual int 0x80 syscall contains the byte 0x80, which the filter destroys. The exploit worked end to end against the live container and dropped a shell in the game-server process, with id output coming back as the server user.
Two details deserve emphasis. First, when the exploit failed, the agent diagnosed the failure, fixed it, and retried until it worked, with no human interaction. Second, the author is unusually honest about scope:
"I want to be honest about the reach here, because I don't want to make this sound bigger than it is: this is reached through rcon, so it needs operator access. It is a post-authentication RCE, not an unauthenticated one."
Hold onto that sentence. It becomes relevant in a moment.
This is not the Call of Duty RCE you read about in 2025
If you search for this story, most of what comes back is a different incident, and the confusion is worth clearing up because the lessons differ.
Older Call of Duty PC builds have a documented RCE history. A community security advisory on Steam tracks CVE-2018-20817, a missing size check in SV_SteamAuthClient that lists Black Ops II among affected titles, and CVE-2019-20893, a buffer overflow in the joinParty handler in some Modern Warfare 2 builds. Then came July 2025: days after the 2017 game Call of Duty: WWII released through Xbox Game Pass on June 30, an RCE exploit was used against PC players in live matches. Players reported attackers opening command prompts, displaying taunting messages, forcing shutdowns, and changing desktop wallpapers, and on July 5 the PC version was pulled from the Microsoft Store while the issue was investigated. Malwarebytes researcher Pieter Arntz attributed the risk to older CoD titles shifting from dedicated servers to peer-to-peer networking.
The zolder.io finding is a different animal entirely: a 2003 title, a Linux server binary, a post-auth bug, and a machine as the auditor. Nicolas Krassas summarized it accurately on LinkedIn as exactly that. If you brief your leadership with the WWII story, you will draw the wrong conclusion. The WWII story is about attack surface in abandoned multiplayer games. This story is about who, or what, is doing the auditing now.
"It's a softball target." Correct, and beside the point
The skeptical read writes itself: a mitigation-free binary from 2003, a post-auth bug, a protocol almost nobody uses anymore. Of course the AI found something. I have three answers.
Start with post-auth. In enterprise environments, post-auth surfaces are where the bodies are buried: admin consoles, management agents, vendor remote-access daemons, the rcon equivalents of every product you run. Credentials for these get shared across ops teams, pasted into runbooks, left at defaults for years. Note also the order the agent worked in. It checked user-facing paths first, then moved to admin functionality. That is the same triage a competent human auditor runs, and it found the bug where the human would have.
Then consider what the mitigations actually affected. No PIE, no canary, and an executable stack made exploitation easy. They did not make discovery easy. The agent still had to orient itself inside an unfamiliar binary, locate the unchecked copy, model a byte-rewriting input filter, and engineer around constraints that broke its first attempts. Those are the transferable skills. Modern mitigations raise the cost of exploit development. They do nothing to hide the bug itself, and a discouraging amount of enterprise native code ships in comparable shape anyway, especially inside appliances and vendor libraries.
Finally, the economics, which is the whole point. The author estimates the same work would have taken a weekend or more by hand. The agent did it in an evening. When the marginal cost of "take a hard look at that old binary" falls from two days of a senior engineer's time to an evening of compute, every piece of code that was protected only by the fact that nobody could be bothered loses that protection. Attackers read the same write-ups you do.
Your estate has cod_lnxded in it
Probably not a game server. More likely the parsing library a vendor shipped a decade ago that still handles uploaded files, the firmware blob on an appliance nobody patches, the management agent installed by software your team forgot it owned. Security through obscurity in native code was never a property of the code. It was a property of auditor attention, and auditor attention just got cheap. Assume any network-reachable native parser in your environment gets examined this way within the next couple of years, by someone.
What to do about it this quarter
1. Find your mitigation-free binaries. checksec is the fastest first pass:
# single binary
checksec --file=/opt/vendor/bin/parserd
# sweep a tree for ELF binaries and report protections
find /opt /usr/local /srv -type f -exec sh -c \
'file -b "$1" | grep -q ELF && { echo "== $1"; checksec --file="$1"; }' _ {} \;The decision rule is simple. Anything that parses network traffic or untrusted files and shows NX disabled, no canary, or no PIE goes to the front of the audit queue. Then weight by reachability: internet-facing beats internal, and admin interfaces with shared or stale credentials count as exposed.
2. Reproduce the workflow defensively. The researcher's setup is directly copyable: a disposable container, no secrets inside, the target free to crash and restart, standard binutils, and an agent allowed to write its own scripts. Scope in the post-auth and admin surfaces, because that is where this bug lived. Keep the loop on a leash, though. An agent that autonomously fixes and retries an exploit will also wander if you let it, so give it a throwaway environment and strict tool scoping. The OWASP work on agentic skills is worth reading first, since agent skills and tool integrations can themselves be hostile.
3. Prioritize by exposure and patchability. You cannot patch a 2003 game server, and you probably cannot patch your vendor's ancient parser either. For code that will never get a fix, the honest controls are isolation, egress filtering, and a retirement date. For code that can be fixed, feed the findings into a continuous threat exposure pipeline rather than letting them fossilize in a PDF between annual tests. A binary that was "fine" only because nobody had looked at it is a standing liability, and it deserves a recurring review, not a one-time reprieve.
4. If you have no security team, start by enumerating your network-reachable native code with a 90-minute threat modeling pass. You cannot audit what you have not listed.
Take the author's hint on pentests
The write-up ends with a pitch: pentesters should adopt AI, and customers should let them. I agree, with one boring caveat. Authorization, logging, and scope discipline matter more at machine speed, because an agent will test everything in scope at a pace no human reviewer can shadow. A finding generated in an evening still needs a human to verify impact and explain it to your auditor.
That also changes what an audit should look like. Point-in-time evidence ages fast when binaries can be re-audited continuously, so for evidence between audits, Axeploit pentesting for audits is the page to send a buyer or auditor.
Key takeaways
- An AI agent found and exploited a stack overflow in Call of Duty 1's Linux server binary in one evening; the author estimates a weekend or more by hand. The cost of auditing legacy native code has collapsed for defenders and attackers alike.
- The bug is a post-auth RCE through the rcon console. It is unrelated to the July 2025 CoD: WWII incident and to CVE-2018-20817 and CVE-2019-20893. Brief the right story.
- "Old, post-auth, mitigation-free" describes a large share of enterprise native code. Inventory yours with checksec and rank it by exposure, not by age.
- The defensive workflow is cheap to copy: disposable container, crash-and-restart freedom, standard binutils, admin surfaces in scope, tight guardrails on the agent.
- Let your pentesters use these tools, and demand evidence between point-in-time audits, because the other side is already running this play.
