Google Earth Studio Vulnerability: Arbitrary File Insertion Explained

  • September 18, 2025

Discover how improper ID handling allowed arbitrary file insertion in Google Earth Studio projects. Learn the implications and security lessons.

Understanding Arbitrary File Insertion Vulnerability in Google Earth Studio Projects

Google Earth Studio is a powerful web-based animation tool that leverages Google Earth’s satellite and 3D imagery to create compelling visualizations. Launched in 2018 as an invite-only beta, it transformed how professionals generate geospatial animations directly in the browser.

Introduction to Google Earth Studio and Project Management

Users of Google Earth Studio create 3D animations grouped into projects. Each project is characterized by metadata such as the project name, its storage folder, creation, and last edit timestamps.

Projects are organized within folders—these can be either the root level or nested subfolders users create for better management. Notably, these folders are identified by incremental numeric IDs (e.g., Folder ID 0 for the very first folder, ID 999 for the thousandth folder), a practice that has significant security ramifications.

Security Risks of Incremental IDs: The IDOR Vulnerability

Using incremental IDs to reference resources opens the door to Insecure Direct Object Reference (IDOR) vulnerabilities. When applications rely solely on easily predictable identifiers without robust authorization checks, malicious actors can enumerate these IDs to access or manipulate resources they don’t own.

To mitigate IDOR risks, modern development practices recommend using UUIDs (Universally Unique Identifiers) which are random and much harder to guess.

The Flaw in Saving Projects: Cross-User Folder Access

When a user saves a project, Google Earth Studio sends a POST request to its API endpoint with project details, including the target folder specified by its ID:

{
  "name": "My project",
  "data": { /* project JSON data */ },
  "version": 16,
  "folder": "https://earth.google.com/studio/api/folders/31337/"
}

The folder parameter determines where the project will be saved. Due to insufficient authorization checks, a user can specify a folder ID belonging to another user’s account.

Implication: This loophole allows attackers to save arbitrary projects into other users’ folders, thereby injecting unauthorized content into their project archives.

Discovery of Arbitrary File Injection via Project Data Manipulation

The project’s core content resides in the data JSON attribute, which is serialized and stored as a file with a .esp extension inside users’ zipped project archives. Because the server does not restrict the contents of this JSON data, an attacker can inject any valid JSON, including strings containing malicious scripts or payloads.

  • For example, replacing data with "<script>alert('oops')</script>" embeds JavaScript code within the file.
  • The project’s filename is derived from the project name concatenated with the .esp extension, giving limited control over file naming.

Bypassing Filename Restrictions Using Null Byte Injection

Ordinarily, changing the project name to dangerous_file.html results in a filename dangerous_file.html.esp, rendering the malicious payload inert.

However, the attacker discovered that adding a null byte character (u0000) to the project name, e.g., dangerous_file.htmlu0000, exploits how many programming languages interpret strings by terminating at the null byte. This truncates the filename on disk to dangerous_file.html, effectively converting the file into an executable HTML file containing malicious JavaScript.

Note: Many frameworks guard against null byte injection, but this vulnerability was not mitigated within Google Earth Studio’s platform at the time.

Security Implications of the Vulnerability

This vulnerability enabled an attacker to insert arbitrary files, including potentially executable scripts, into any user’s project archive without their knowledge.

  • When users download their entire project archives—a feature available through the Preferences page—they unknowingly retrieve compromised files embedded by attackers.
  • These files can execute malicious code if opened in appropriate environments, potentially leading to data breaches or system compromise.

Case Study: Attack Vector Using Executable Script Files

In an exemplary attack scenario, an attacker injects an executable shell script named initProject.sh into the project archive structure:

GoogleEarthStudio_MyProjects_07_28_2021/
└── Example Project/
    ├── projectData.esp
    └── initProject.sh

Upon quarantine removal, if a user inadvertently runs initProject.sh (e.g., double-clicking on Windows with Git Bash installed), the embedded malicious code gets executed.

This attack vector is particularly insidious because:

  1. The victim downloads the archive directly from the trusted official site (earth.google.com).
  2. The downloaded archive appears legitimate, being a direct backup/copy of their projects.
  3. No explicit delivery of suspicious files is needed; the infected archive is spread across all users.

Response and Resolution

Initially, Google did not issue a vulnerability reward, categorizing the severity as lower. However, after further elaboration and demonstration of potential exploitation scenarios, the vulnerability was reassessed and awarded later.

Google addressed the issue by tightening authorization checks and eliminating the possibility of null byte injection in project filenames.

Key Security Lessons and Best Practices

  • Avoid Incremental IDs: Using predictable sequential IDs exposes applications to IDOR vulnerabilities. Instead, adopt UUIDs or similar unpredictable identifiers.
  • Implement Strict Access Controls: Server-side validation must strictly enforce ownership verification to prevent unauthorized access or modification of resources.
  • Sanitize Input and File Names: Prevent injection techniques including null byte injection by rigorously validating and sanitizing all inputs affecting filenames or content stored on disk.
  • Secure Data Export and Import: Downloads such as project archives should be scanned and verified for integrity and safety before delivery to users.
  • Educate Users: Users should be cautious when executing files from untrusted sources, even if they appear to come from a trusted platform.

Current Relevance and Broader Context

According to the OWASP Top Ten Security Risks, IDOR remains a prevalent issue in web applications globally. The 2023 HackerOne report indicates that IDOR issues accounted for approximately 14% of critical vulnerabilities disclosed on their platform.

This Google Earth Studio case exemplifies how IDOR combined with insufficient input sanitization can escalate into significant risks, including malware spread and system compromise.

Conclusion

Google Earth Studio’s arbitrary file insertion vulnerability serves as a critical reminder of the importance of secure resource referencing and strict validation in web applications.

Organizations must continuously audit and test their systems to prevent IDOR vulnerabilities and protect end users from indirect attacks via trusted platforms. Developers should follow secure coding standards and ensure comprehensive input sanitization to avoid exploitation by attackers leveraging overlooked flaws like null byte injection.

Further Reading