When Call of Duty: WWII debuted on Game Pass, fans of the game were ecstatic. The addition of Call of Duty titles, one of the most expensive in the Activision universe, was widely celebrated in the Xbox ecosystem.
Thousands eagerly signed on to play, certain they had left Steam’s remote code execution (RCE) nightmares in the dust.
But upon firing up Call of Duty: WWII, they were met with none other than an RCE attack. Many experienced forced shutdowns, while others had their games frozen mid-match, followed by command line pop-ups and Notepad messages like, “Marc E Payer just RCE’d your a**, please contact Mitchell Silberberg and Knupp LLC.”
So, how does a favorite pastime open the door to a hostile takeover of one’s computer – and trolling messages about contacting a Los Angeles law firm? More importantly, what is remote code execution (RCE)?
Why is remote code execution (RCE) bad?
Remote code execution (RCE) is the kind of attack no one wants to face. In a nutshell, it means an attacker can run any code they like on your computer and take complete control of your device. And they can do it without your permission, from anywhere in the world.
Imagine letting a stranger into your home, where they can rearrange your furniture, take whatever they want, and even break a few things.
That’s an RCE attack, where hackers can steal your information, corrupt your files, install ransomware on your device, and demand payment to release your data.
In 2025, we’ve seen a wave of RCE attacks on gaming platforms.
Due to a reliance on P2P (peer-to-peer) hosting, which allows one player’s console or PC to serve as a host server, malicious players hosting Call of Duty: WWII matches were able to take control of other players’ PCs.
The game’s remote code execution vulnerabilities have prompted Activision to pull the PC version offline (console versions remain unaffected). Fans (especially those who purchased Xbox PC season passes) have voiced frustration that older Call of Duty titles with known RCE vulnerabilities were added to Game Pass without security improvements.
But it isn’t just gamers at risk. Businesses have suffered devastating breaches due to RCE. Take, for example, CVE-2025-53783. That’s the buffer overflow vulnerability found in Microsoft Teams on August 12, 2025, which exposed corporate environments to RCE.
Imagine your computer’s memory as a series of labeled buckets sitting side by side. Next, think of the buffer as a bucket holding incoming data. In a buffer overflow scenario, an attacker sends more data than what the buffer can hold.
That means too much data is “poured” in, and the data “spills” over into neighboring buckets (adjacent memory spaces), some of which control what the program does next. This overflow lets the attacker overwrite the original data and redirect the program to carry out new, malicious instructions after it executes its current task.
According to Microsoft, this overflow vulnerability doesn’t require any special privileges to exploit. Merely the action of clicking a malicious link or attachment is enough to trigger the overflow.
Once the malicious code runs inside the Teams process, the attackers can perform almost any action: read your private messages, modify existing data, disrupt Teams functionality, and even install backdoors to maintain persistent access to your device.
You don’t need to be a multinational corporation for this to matter. Anyone using Teams (freelancers, remote workers, or small business owners) can be targeted. This can put your most sensitive information like passwords, proprietary data, intellectual property, or private conversations at risk of exposure.
Now that you’ve seen how P2P glitches and buffer vulnerabilities can cause havoc, you may be wondering: Does every code-injection attack occur remotely, and more importantly, how can it be stopped?
Breaking it down: What’s the difference between ACE (arbitrary code execution) and RCE (remote code execution)?
To put it simply, RCE is part of a broader threat called arbitrary code execution (ACE).
With ACE, attackers either have a measure of physical access to a device or have access credentials that allow them to execute malicious code on that device.
ACE becomes RCE, however, when an attacker can execute that malicious code remotely - without needing any prior access to the device or machine.
This means attackers can breach your defenses even if you’re careful to avoid clicking on links, like in the Call of Duty RCE breach.
And that’s not all: Our modern world is a connected web of servers, IoT devices, gaming platforms, and collaboration tools. So, any device with a network connection becomes a target, widening the attack surface exponentially. One unpatched RCE exploit can put millions of users (and entire networks) at risk simultaneously.
Stop being an easy target: What you should know about remote code execution (RCE) types
As mentioned, RCE attacks are some of the most dangerous threats you can face in the digital world. Understanding these threats is the first step you can take to protect yourself. Below, you’ll find a straightforward guide to the key types of RCE attacks, what they do, and why they matter.
Attack category |
Attack type |
What it does |
Why it matters |
Injection-based attacks |
Adds improperly sanitized user-provided input into SQL queries/ commands |
Lets attackers bypass security controls, corrupt database records, and access sensitive data like passwords and financial records | |
|
OS command injection |
Tricks the system into running unsafe OS commands |
Can lead to full system compromise, resulting in data theft, deletion of critical files, malware installation, and lateral movement |
|
Cross-site scripting (XSS) |
Attackers inject harmful scripts (usually JavaScript) into websites you visit |
Steals session cookies and hijacks your online accounts |
|
NoSQL injection |
Same as SQL injection but targets modern databases that rely on flexible JSON-based queries rather than traditional SQL syntax |
Tricks the database system into authenticating users without valid login credentials |
|
LDAP injection |
Attacks directory databases that manage user info |
Apps that don’t properly sanitize user inputs allow attackers to bypass login screens, retrieve sensitive info (like usernames and passwords), or modify data. |
Deserialization attacks |
Unsafe deserialization |
Manipulates data before deserialization (when the application converts data in a simplified format back into complex data or objects) |
Tricks the application into creating harmful objects or running malicious code that gives attackers control or unauthorized access to your system |
File-related exploits |
Local file inclusion (LFI) |
Tricks apps into exposing private files from a server |
Lets hackers see private information such as configuration files or password lists |
|
Remote file inclusion (RFI) |
Loads and runs files from external servers |
Executes code from remote sources to infect your system with malware |
Scripting & Runtime |
Template injection |
Occurs when improperly validated user-supplied input is injected into an app's template system, which results in remote code execution on the server |
Allows attackers to access and modify data in configuration files and databases or execute malicious code on the server, potentially taking control of the backend system |
|
PHP object injection |
Injects malicious serialized objects into PHP apps |
Injected objects can crash the app, disrupt services, and act as a launchpad for SQL injections, path traversal, and command injections |
Protocol exploits |
XML external entity (XXE) |
Malicious entities injected when application parses XML inputs insecurely |
Can lead to disclosure of sensitive files, DoS (Denial of Service), and data exfiltration |
|
Server-side request forgery (SSRF) |
Forces servers to access internal systems |
Exposes private network resources, allowing attackers to reach systems you thought were protected |
Memory exploits |
Buffer overflow |
Overwriting a part of device memory with malicious instructions |
Can lead to full system compromise |
|
Heap spray |
Floods the heap (part of a system’s memory that stores data temporarily) with many copies of malicious code |
Triggers execution of attack code to crash your system or let attackers take over your device |
|
Return-oriented programming (ROP) |
Uses legitimate code in malicious ways |
Runs harmful payloads and evades protections by reusing trusted code |
Web app framework exploits |
Shell injection |
Also known as OS command injection and occurs when an application passes un-sanitized user input to a system shell (like Bash, PowerShell, or CMD). |
Gives attackers full control over your system through the command line interface |
|
Cross-site request forgery (CSRF) |
Tricks users into performing actions unknowingly |
Changes settings or makes unauthorized transactions without your consent |
|
JavaScript injection |
Runs unauthorized JavaScript in your browser |
Can hijack your sessions and puts your browser data at risk |
Network protocol exploits |
DNS rebinding |
Tricks your browser into treating a malicious website as part of your trusted private network, thus allowing the site to interact with the devices in your network |
Allows the attacker-controlled site to read data from your internal devices, change settings, and even potentially take over your network |
|
SMTP injection |
Injects commands in email servers |
Can turn your email system into a tool for attackers to distribute spam or malware campaigns, often without your knowledge |
Advanced attack vectors |
Path traversal |
Accesses files and folders outside allowed areas |
Can expose sensitive files or take control of your system |
|
Library or DLL hijacking |
Swaps out trusted system files for attacker-created files |
Allows attackers to run malicious code when the app starts, resulting in persistent infections that are hard to remove |
|
Code injection in configurations |
Injects harmful code in configuration files |
Once injected, malicious code is executed as part of system operations every time configuration loads |
|
JNDI injection |
Manipulates how message lookups are done in JNDI (Java Naming & Directory Interface), so the Apache server fetches data from attacker-controlled servers |
Targets Java apps frequently used in enterprise environments and served as the basis for Log4Shell attacks compromising high-value corporate networks |
|
Memory corruption exploits |
Exploits corrupted device memory |
Can lead to remote code execution, Denial of Service (DoS), or full device takeover |
Seven (7) powerful steps to protect yourself against RCE attacks
RCE attacks have one alarming purpose: to sneak malicious code into your system and take complete control without you knowing it.
But here’s the good news: The power to protect yourself is already in your hands. It comes down to several key strategies, which we highlight below.
#1 Update and patch promptly: Every RCE attack takes advantage of known weaknesses. Be sure to keep your operating systems, applications, libraries, and third-party software regularly updated with the latest patches (to reduce the window of opportunity for attacks.
That said, for vulnerabilities like Log4Shell, the complexities of layered dependencies in large systems can make it difficult to patch comprehensively and promptly. In such cases, implementing a formal vulnerability and patch management program may be necessary.
#2 Validate and sanitize all user-supplied input: Always check to ensure that user inputs adhere to defined rules for data types, lengths, and allowed characters. Once validated, sanitize the input by removing potentially malicious characters.
That said, input validation & sanitization alone isn’t enough. To prevent injection attacks, consider using parametrized queries (prepared statements) to separate user input from SQL code.
This ensures no user input can be interpreted as executable code. So, even if an attacker manages to insert malicious commands as part of the user input, the database won’t run that input as code.
#3 Limit access with strict permissions: Limit the access rights of every user or application to only what is necessary for their functions. This is the principle of least privilege.
So, even if an attacker manages to access one area of your network, they have very limited privileges. With minimal permissions, they can’t easily run malicious code or move laterally inside your network.
#4 Disable server-side JavaScript execution: This prevents JavaScript code in user input from executing on the server, preventing attackers from performing unauthorized actions like reading and modifying files.
MongoDB, for instance, allows the disabling of server-side JavaScript execution in two ways: (1) using the --noscripting command-line (2) setting security.javascriptEnabled to false in the configuration file.
#5 Use web application firewalls (WAF): Think of a web application firewall as a digital security guard. It filters suspicious traffic and blocks attacks before it reaches your applications. This adds an extra layer of defense against RCE attacks.
#6 Layer on run-time application self-protection (RASP): RASP embeds security directly into a running application. It continuously monitors any attempts to inject unauthorized code or exploit vulnerabilities that could lead to RCE.
Ultimately, RASP provides application-aware protection, while WAF filters malicious traffic before it reaches your applications.
#7 Implement ASLR (Address Space Layout Randomization): ASLR randomizes the base addresses of key memory segments, such as the stack, heap, and shared libraries, each time the program runs.
This randomization makes it extremely difficult for attackers to predict where specific functions will reside in memory, thus hindering their ability to craft reliable exploits.
When combined with measures like Data Execution Prevention (DEP), Control Flow Integrity (CFI), and stack canaries, ASLR dramatically reduces the success of RCE attacks.
Related articles
Invisible threats, visible protection: Securing your data with LastPass
Every month, there’s an update about yet another new RCE vulnerability. Take, for instance, CVE-2025-49712. This vulnerability has a severity score of 8.8 out of 10.0, just below the threshold of “critical.”
According to Microsoft, the weakness rests in how SharePoint deserializes user-supplied input without checking (or validating) the contents.
This means an attacker who has phished SharePoint login credentials can exploit this vulnerability by embedding malicious code into a serialized payload, knowing the application will run it automatically.
But here’s the part attackers don’t want you to know: A Secure Access provider like LastPass can level the playing field when it comes to protecting your login credentials.
Here’s how:
- User-friendly password generator: RCE attackers thrive on reused passwords to get initial access. With LastPass, every login gets its own unique password. Our built-in generator lets you easily customize each password according to the newest CISA and NIST rules, so each of your accounts stays safe.
- Military-grade AES-256 encryption: LastPass encrypts your vault with AES-256, the gold standard trusted by the military, hospitals, banks, and federal agencies. And with AES-256 largely resistant against quantum-assisted attacks, this means uninterrupted security from RCE-driven credential theft.
- Encrypted vault URLs: LastPass goes beyond encrypting your passwords. We also encrypt the URLs linked to each login in your vault. This means that attackers face an additional barrier to theft, as they can’t easily map credentials to your accounts.
- Smart autofill: The LastPass autofill tool minimizes risky behaviors that RCE attackers often exploit – like copy-pasting passwords from browser managers. Autofill functionality means you’ll never have to type in passwords again, preventing attackers from harvesting them through keyloggers.
- Continuous Dark Web Monitoring: With our premier Dark Web Monitoring services (available even for free users), you get instant alerts the second your email addresses are compromised. This means you can act fast to update your passwords before attackers can exploit them.
- Transparent disclosure: LastPass doesn’t just talk about security – we prove it. We employ world-class security organizations to conduct thorough, independent audits of our services and infrastructure. Alongside these audits, LastPass adheres to industry-tested compliance standards, which you can review openly at our new Compliance Center. This means LastPass infrastructure defenses have been vetted by top-tier experts. When we say that your security is our #1 priority, you can see the proof with your own eyes.
- Bug bounty program: We believe in rewarding those who help keep valued customers like you safe. Our bug bounty program ensures ethical hackers are rewarded for finding and reporting security flaws before the criminals do. This proactive approach means that potential vulnerabilities can be patched quickly, fulfilling our commitment to your safety and peace of mind.
If you’re ready to enjoy effortless security, unlock your free trial today and join millions of our happy customers who trust LastPass to protect their accounts.
It makes passwords for me; I don't have to try to think up another combination of random characters every time I make a new account somewhere. LastPass then remembers it for me, I'm an IT admin and I have a lot of passwords - so having LastPass keep up with them is very helpful indeed. It also auto fills them in websites when I return. LastPass also stores them in a searchable format so it's easy to find what I'm looking for and I [can] launch the site directly from it. It has an app for the cellphone so I can carry all my passwords with me in case I don't have my company laptop. As an admin, [it’s] super easy to add new users and check on their status. Can update their master passwords, and it does notify all admins when you do this, so can't sneakily get into people's accounts! (John R, network administrator and verified G2 user)