Tenable Research has identified a remote code execution (RCE) vulnerability in Oracle Cloud Infrastructure (OCI)’s Code Editor, which could have allowed attackers to take over user environments and execute commands without consent. Although the issue has since been resolved by Oracle, the vulnerability highlighted significant security implications for users working with Cloud Shell and other integrated OCI services.
The flaw allowed attackers to hijack a user’s Cloud Shell session with a single click, potentially enabling lateral movement across Oracle’s developer ecosystem. Because the Code Editor and Cloud Shell share the same file system, session context, and authentication layer, any malicious file uploaded through the editor could be executed in Cloud Shell, posing a major security risk.
Deep integration exposes wider attack surface
OCI’s Code Editor is a browser-based development tool closely tied to core developer services including Resource Manager, Functions, and Data Science. These services all run on the same Cloud Shell environment, meaning files uploaded via Code Editor are immediately accessible within Cloud Shell.
Tenable researchers discovered that the Code Editor’s file upload endpoint, unlike Cloud Shell’s, did not include safeguards against Cross-Site Request Forgery (CSRF). Without CSRF protection, attackers could craft a webpage that, when visited by a logged-in Oracle Cloud user, would silently upload a malicious file into their Cloud Shell environment. This upload could modify sensitive files such as .bashrc, enabling arbitrary code execution the next time Cloud Shell is launched.
The vulnerability relied on how the Code Editor’s router handled file uploads. It accepted multipart/form-data POST requests without requiring extra authentication beyond an existing session cookie. That cookie, set with a SameSite=None attribute, failed to prevent cross-site requests. As a result, a malicious website could submit an unauthorised request on the user’s behalf, uploading a file without their knowledge.
Tenable’s proof-of-concept attack used this method to insert a reverse shell payload into .bashrc. Once the victim opened Cloud Shell again, the shell executed the payload, giving attackers interactive access to the environment and allowing them to run commands or extract credentials. With access to the Oracle Cloud Identity and the OCI Command Line Interface, attackers could then access or manipulate additional services.
Broader risks to integrated services
The vulnerability’s impact extended beyond Cloud Shell. Because services such as Resource Manager, Functions, and Data Science also rely on the same shared environment, any tampered files could disrupt or compromise these services as well. An attacker could, for instance, inject malicious code into a function or alter deployment scripts in Resource Manager, escalating the scope of the attack significantly.
Tenable researchers emphasised that such deep integration between services—while improving user experience—also increases security risk. “Cloud services, especially with their deep integrations and shared environments, function similarly [to a Jenga tower],” said Liv Matan, Senior Security Researcher at Tenable. “If a hidden integration or shared environment introduces a weakness, those risks can cascade into dependent services.”
Oracle patches vulnerability with new CSRF protection
In response to the report, Oracle has introduced a mandatory CSRF protection header for the affected endpoint. All file uploads must now include a custom header, x-csrf-token, with a fixed value. This header prevents unauthorised cross-site requests because modern browsers do not allow JavaScript from external sites to add arbitrary headers to cross-origin requests.
The patch effectively blocks attempts to exploit the issue, and no further action is required from users. The vulnerability was disclosed responsibly and remediated by Oracle before public release.
Tenable’s findings highlight the need for thorough security evaluations across all layers of cloud services, especially when shared environments and integrated tools are involved. While Oracle has closed this specific vulnerability, the case serves as a broader reminder of the importance of securing cloud development environments.
