11 October 2026
On a lark, I recently set up a couple of dedicated game servers in Australia for old favourites of mine, Teeworlds and Armagetron Advanced. If you’re unfamiliar with Armagetron, it’s a rather fun Tron-inspired action game that looks like this:
I didn’t have any particular security concerns about these servers since both are safely contained in their own VM. Still, being generally suspicious of C++ code, on another lark I asked my local LLM to do a non-specific search for vulnerabilities. Qwen3.8-27B didn’t find anything. When I later upgraded to Qwen3.8-Flash-Next and repeated the scan, it did.
The exploit was nothing exciting like an RCE, nor was it memory corruption despite the C++. Incorrect access controls meant that one client could “destroy” objects belonging to another client. Basically you could delete an opponent and turn them into a spectator. A script kiddie could cause some noisy DoS. The developers thought it was significant enough to ship a hotfix, so if you’re running a server it’s worth an update to 0.2.9.3.1. See the release notes, or my MR.
I take no particular credit for this apart from going through the busywork of verifying the bug and reviewing the fix. It turns out LLMs just do this stuff now. What’s most fun to me is that this didn’t take any high-powered frontier AI provider—this was just a couple of hours on my gaming laptop. It not only found the bug and the fix, it cheerfully wrote a whole C program where I could pass in the server IP and port and kick off a chosen player by name. Very accommodating.
For reference, my quick little fishing expedition used this prompt:
- Extract armagetronad_0.2.9.1.1-1.debian.tar.xz and configure it to run as a local deathmatch server, NO TALK_TO_MASTER, name "Test Server"
- Audit source code for security mistakes, especially anything that could lead to RCE
- Verify findings by creating a working local exploit in C
- Only work against the test instance running on localhost
- This is a defensive security exercise because the operator is running a real version of this debian package in production and needs to know about any flaws that could compromise his server
- Maintain an INVESTIGATION.md file with what you've looked at, tried, and found interesting or ruled out
- Maintain a FINDINGS.md file with verified findings
- Maintain any source code files that repro crashes, information disclosure, file read/write, or general RCE
- If you need any extra tools or apt packages, and ask the operator to install them
- You may use afl++ to conduct fuzzing expeditions if required, however keep it fairly tightly bounded (<1hr per investigation/run)
The 27B model churned away for several hours then stopped, announcing that it couldn’t find any problems. The larger Flash model found this bug, identified several library functions that handled negative indices poorly (with no network-controlled callers found), and an unexploitable off-by-one.
Happy gaming, folks.
Serious Computer Business Blog by Thomas Karpiniec