Stop Killing Games guarantees unpatched network-reachable code

The Stop Killing Games initiative cleared the one-million-signature threshold a European Citizens’ Initiative needs to compel Commission review. Reported totals ran near 1.4 million. The demand is narrow and defensible: when a publisher ends support for a game it sold, it must leave that game in a playable state. Publishers release the server binary, remove the always-online license check, or hand the netcode to the community. The initiative is a consumer-rights and preservation instrument. It is being framed as a security outcome. It is not one, and the distance between those two things is the entire analysis.

Legislation defines publisher obligation. It does not define attacker capability. An EU directive can compel Ubisoft or EA to publish a dedicated server executable at end-of-life. It cannot compel that executable to be memory-safe. The vulnerability classes that make game infrastructure exploitable - unchecked parsers, deserialization sinks, integer overflows in asset loaders, command injection in RCON handlers - live in compiled code no statute reads. Attackers do not wait for legal precedent. They wait for a network-reachable service running unpatched code. Preservation law, as written, manufactures exactly that.

Game clients and servers are large C and C++ codebases that parse high volumes of untrusted input. Map files, replay demos, model and texture assets, save files, matchmaking payloads, voice packets, server-browser responses. Each is an input parser exposed to a hostile peer. The Source engine, Unreal, id Tech, proprietary MMO stacks - all carry decades of accreted parsing code written for throughput, not for adversarial input. That is the bug-class reservoir. Memory corruption in a demo-file parser is a remote primitive when the demo arrives from an untrusted server. A heap overflow in a model loader is client-side RCE when a malicious server serves the model. RCON makes it worse: the remote console protocol executes server commands by design, often behind a plaintext password and a default port, which turns a weak credential into direct command execution.

The canonical example is not subtle. CVE-2021-44228 - Log4Shell, CVSS 10.0. The mechanism: log4j performed JNDI lookups on strings it logged. An attacker who landed a crafted string into a logged field forced the server to fetch and deserialize a remote Java class. Remote code execution from a log line. The first widely circulated proof of concept used Minecraft Java Edition. A player sends the string in chat. The server logs it. The server executes attacker-controlled code. A game’s chat box became an RCE delivery channel because the logging dependency trusted its own input. T1190, exploitation of a public-facing application. T1059 once the class loads.

The Source engine case shows the client side. CVE-2021-30481 was a remote memory-corruption bug in Source’s handling of game-invite data - the connection parameters passed when a player accepts an invite. The fields were attacker-controllable and reached a fixed-size buffer without adequate bounds enforcement. Accepting an invite from a malicious actor was enough to corrupt memory in the client process. No exploitation of the matchmaking service required. The client trusted peer-supplied connection data. That is the shape of game RCE: untrusted input from a peer or a server, a parser that assumes well-formed data, a memory write the attacker steers.

One detail separates game RCE from the browser case practitioners are used to. A Chrome renderer compromise lands inside a restricted token, a job object, and a seccomp-bpf or Win32k-lockdown sandbox; the attacker still needs a second bug to escape to the host. A game client has no equivalent boundary. The process runs with the logged-in user’s full token, no syscall filtering, direct filesystem and network access. Client-side memory corruption in a game is host-context code execution on first primitive. The attacker leaks a pointer to defeat ASLR, builds a read/write primitive from the corrupted object, and pivots straight into the user session. There is no sandbox escape to chain because there was no sandbox. That makes a model-loader overflow or an invite-parser bug worth more, not less, than the equivalent renderer bug.

Steam itself carries the same weight. CVE-2019-14743 was a local privilege escalation in the Steam Windows client. The Steam service ran as SYSTEM and operated on registry keys and paths a low-privileged user could influence, enabling escalation to SYSTEM. The client sits on a hundred-plus million machines. The privilege boundary it sits on is the entire host.

The supply-chain layer compounds it. Game servers do not run alone. They run mod loaders and plugin frameworks - Bukkit and Spigot for Minecraft, the addon system for Garry’s Mod, Workshop content across Source titles. Those are third-party code execution paths bundled into the runtime. A community server that installs a popular plugin inherits whatever that plugin’s maintainer shipped, including abandoned dependencies frozen at a vulnerable version. Log4Shell reached Minecraft servers precisely because a logging dependency three layers down trusted untrusted input. The trust chain in a modded game server is longer than the operator can audit, and at end-of-life nobody is auditing it.

Real-world exploitation of game infrastructure is documented and continuous. The 2011 PlayStation Network intrusion exposed roughly 77 million accounts and pulled the network offline for weeks; reporting attributed entry to an unpatched, network-reachable application server. Log4Shell was mass-exploited within days of disclosure - Cloudflare reported blocking exploitation attempts at internet scale almost immediately, and game servers were among the first reachable targets because they log untrusted chat and player names by default. The pattern repeats wherever a game exposes a network service that parses what a stranger sends.

The post-compromise value of an abandoned, internet-facing server is also concrete. An exploited game server is a Linux or Windows box with bandwidth, a stable IP, and no one watching it. That is botnet inventory, a cryptomining host, a residential or hosting-range proxy node, or a pivot point into whatever flat network a hobbyist operator placed it on. T1133, external remote services, describes the access; T1584, compromise of infrastructure, describes the reuse. Ransomware crews and access brokers scan for exactly this profile - reachable, unpatched, unmonitored, unowned. The preservation server is a permanent listing in that inventory because no patch is ever coming.

Apply that to Stop Killing Games. The initiative’s mechanism, enacted, distributes server binaries for end-of-life titles into community hands. Those binaries stop receiving patches the day official support ends - that is the definition of end-of-life. Community operators stand them up on rented VPS instances and home servers, internet-facing, indefinitely. The code is frozen at its last shipped state, including every unfixed memory-corruption bug, every vulnerable bundled dependency, every weak default in the matchmaking and RCON paths. Preservation does not remediate that code. It perpetuates it. A law written to keep games playable keeps vulnerable network services reachable long after the vendor that could patch them has walked away.

This is not an argument against preservation. It is an argument against calling preservation a security control. The two operate on different layers. One governs availability and ownership. The other governs whether a parser writes past the end of a buffer. Conflating them is a threat-modeling error - the assumption that a policy outcome changes a technical condition it never touched.

The telemetry reality makes the exposure worse. Vendor-run game infrastructure, whatever its flaws, sits inside an environment with logging, SIEM ingestion, and some EDR coverage. Community-run preservation servers have none of it. There is no Sysmon on a hobbyist’s game-server VPS. No EDR agent watching for the child process a deserialization exploit spawns. No SIEM correlating the outbound LDAP callback a JNDI payload triggers. The detection surface is whatever the operator built, which is usually nothing. An exploited preservation server produces no alert because no one is listening. Exposure is visible only from the outside - Shodan and equivalent scanners index these services by banner, old engine version strings, deprecated TLS, default ports. The same visibility attackers use for target selection.

Network-layer indicators exist but go uncollected in this context. A Log4Shell hit produces an outbound LDAP or RMI connection from a process that has no reason to make one - a textbook JNDI-callback IOC. A demo-parser RCE produces an anomalous child process under the game-server binary, the signature of T1059 execution after exploitation. On a monitored network those fire. On an unmonitored community box they happen in silence. The defender gap here is not a missing rule. It is a missing collector, a missing agent, a missing owner.

The patch boundary is the whole point. There is no patch boundary for end-of-life software. The last build is the last build. CVE-2021-44228 was fixed in log4j 2.17.x; an abandoned game server bundling 2.14 stays exploitable forever because no one ships it 2.17. Source-engine memory-corruption fixes landed in client and engine updates a frozen community fork never receives. Residual exposure after end-of-life is total and permanent for any bug class present at shutdown.

Stop Killing Games argues a legitimate point about ownership and digital permanence. The signature count reflects a real grievance. But the framing that legislation hardens anything technical is wrong on the mechanics. Statute changes publisher behavior. It does not change memory safety, does not enforce dependency hygiene, does not stand up monitoring on the servers it sets free. Attackers exploit code and protocol. They are indifferent to the legal status of the binary they are corrupting. A law can mandate that a game stays alive. It cannot mandate that the code keeping it alive is safe to expose - and exposing unpatched, unmonitored network services is precisely the condition the initiative, as written, would multiply.