What is remote code execution (RCE)?

Remote code execution (RCE) in plain English

“Remote” means from a distance, and “code execution” means running program code. With an RCE vulnerability, an attacker gets a server to execute commands sent over the internet – without being on-site and often without even having a valid user account.

Imagine a mailroom that doesn’t just sort incoming letters but immediately carries out every instruction they contain. A letter saying “Hand over all the keys to the sender” wouldn’t be filed away – it would be carried out. An application with an RCE vulnerability behaves in exactly this way: it confuses data it’s only supposed to process with commands.

RCE is not a single attack technique but a group of vulnerabilities with the same outcome: the attacker can execute their own code. Accordingly, such vulnerabilities receive high severity ratings. On the CVSS scale from 0.0 to 10.0, they often land in the critical range.

How remote code execution works

Common causes include:

1. Command injection: An application inserts input into a system command without checking it – for example, a diagnostics form that checks whether an IP address is reachable. If the attacker appends their own command to the address, the server executes it too.
2. Unchecked file uploads: Instead of an image, the attacker uploads a script file that the web server then runs as a program. The result is what’s known as a web shell – a remote control for the server that can be operated through the browser.
3. Insecure deserialization: Programs package data for transmission and later unpack it again. If an application accepts such packages from outside without checking them, an attacker can send a crafted package that executes code when it is unpacked.
4. Template injection: Many web pages are generated from templates. If input flows into a template unchecked, the attacker can inject program logic.
5. Memory corruption bugs: In software written in the programming languages C or C++, a buffer overflow – too much data for too small a memory area – can, for example, cause injected data to be executed as code.

Depending on the database, even an SQL injection can lead to code execution. For publicly known RCE vulnerabilities, ready-made exploits – attack programs – often circulate quickly. If a vulnerability is still unknown to the vendor, it’s called a zero-day vulnerability.

The injected code usually runs with the privileges of the affected application. If that application runs with administrator rights, the attacker immediately has full control. Otherwise, a privilege escalation – an expansion of rights – often follows.

A practical example

A fictional scenario: An online shop for spare parts lets its customers upload photos of defective parts. The application only checks whether the file name ends in “.jpg” – not what the file actually contains. An attacker could therefore upload a file named “part.php.jpg” that is really a script. Because the web server is misconfigured, it would execute the file as a program. With this web shell, the attacker could read the customer database and manipulate the payment page.

In this case, a penetration test uncovers the vulnerability before criminals find it. The tester uploads a harmless test file that merely displays the server’s name – enough to prove the vulnerability. The development team has since started checking the actual file content, storing uploads outside the publicly accessible web directory, and assigning random file names.

Why does this matter for businesses?

RCE is among the most critical findings of a penetration test. With control over a server, an attacker can steal data, download malware such as ransomware, manipulate payment pages, or use the server as a springboard into the internal network.

Vulnerabilities in systems that are reachable from the internet and can be exploited without signing in are particularly dangerous. When such a vulnerability becomes publicly known, criminals often scan the internet automatically for vulnerable systems. If personal data falls into the wrong hands, reporting obligations under the GDPR may also apply.

How to protect your organization

• Prioritize updates: Install security updates for critical vulnerabilities immediately – especially on systems that are reachable from the internet.
• Never use input unchecked: Input belongs neither directly in system commands nor in templates or deserialization functions.
• Check uploads strictly: Verify the actual file content, store uploads outside the web directory, and prevent them from being executed.
• Least privilege for services: Don’t run web applications with administrator rights.
• Isolate systems: Publicly accessible servers belong in a separate network segment, such as a DMZ.
• Add a protective layer: A web application firewall filters many typical attacks but is no substitute for secure coding.
• Test regularly: Penetration tests and code reviews find RCE vulnerabilities before attackers do.

How Rootsektor can help

In a penetration test for Web Applications & Online Shops, we specifically look for vulnerabilities that lead to code execution – from file uploads and injection vulnerabilities to insecure deserialization. We demonstrate exploitability in a controlled manner and with care for your ongoing operations. We report critical vulnerabilities such as RCE to your agreed contact person immediately, while the test is still running. We recheck remediated vulnerabilities in a free retest.