Post cover image

August 20, 2026

How I Got RCE Through a Simple Collaboration Invitation in a Desktop Application

“قَالَ اللَّهُ تَعَالَى: “يَرْفَعِ اللَّهُ الَّذِينَ آمَنُوا مِنكُمْ وَالَّذِينَ أُوتُوا الْعِلْمَ دَرَجَاتٍ ۚ وَاللَّهُ بِمَا تَعْمَلُونَ…

By 0xvar

5 min read

"قَالَ اللَّهُ تَعَالَى: "يَرْفَعِ اللَّهُ الَّذِينَ آمَنُوا مِنكُمْ وَالَّذِينَ أُوتُوا الْعِلْمَ دَرَجَاتٍ ۚ وَاللَّهُ بِمَا تَعْمَلُونَ خَبِيرٌ

While testing a desktop application similar to Google Drive, I found an interesting issue that allowed me to get an attacker-controlled file onto another user's computer.

The interesting part?

The victim didn't even need to accept the collaboration invitation.

This turned a simple collaboration feature into a potential Remote Code Execution attack chain.

Understanding the Application

The application is a cloud storage platform.

Users can:

  • Upload files and folders
  • Share files with other users
  • Add collaborators
  • Download files
  • Synchronize their cloud files with the desktop application

The desktop application automatically syncs files between the cloud and the local computer.

At first, this looks like a normal cloud-storage application.

But while testing the collaboration functionality, I noticed something interesting.

The First Finding

When a user adds another account as a collaborator, the second user receives an invitation.

Normally, I would expect the shared files to become available only after the user accepts the invitation.

So I started testing what happens if the invitation is not accepted.

And this is where things became interesting.

Even without accepting the invitation, the desktop application started synchronizing the shared content.

That meant the collaboration invitation itself was enough to make the files appear on the victim's machine.

This immediately raised a question:

What happens if the shared folder contains an executable or script?

Creating the Malicious File

I created a new folder from my attacker account.

Then I uploaded a simple Windows batch file:

accounts.bat

For the proof of concept, I used a harmless command:

@echo off
cmd /k

The file was uploaded using the application's API:

POST /api/2.0/files/content
------geckoformboundary16ddf9110a385ac9817f21c53f9c0842
Content-Disposition: form-data; name="attributes"
{"name":"accounts.bat","parent":{"id":"410001760472"},"content_modified_at":"2026-08-18T16:03:59Z"}
------geckoformboundary16ddf9110a385ac9817f21c53f9c0842
Content-Disposition: form-data; name="file"; filename="accounts.bat"
Content-Type: application/octet-stream
@echo off
cmd /k
------geckoformboundary16ddf9110a385ac9817f21c53f9c0842--

At this point, I had an attacker-controlled file stored in my account.

Nothing special yet.

Sending the Invitation

Next, I added the victim's email address as a collaborator on the folder.

The victim received the collaboration invitation.

I did not accept the invitation from the victim account.

I wanted to see whether the desktop application would actually synchronize the folder.

And it did.

None

The Victim Never Accepted the Invitation

This was the most important part of the vulnerability.

The victim account still had a pending collaboration invitation.

There was no explicit acceptance.

However, the desktop application started synchronizing the shared folder.

After synchronization, the malicious file appeared on the victim's local computer:

accounts.bat

So the attacker's file had crossed from the attacker's cloud storage to the victim's local filesystem without the victim accepting the collaboration.

This gave me the following attack chain:

Attacker
   |
   | Upload malicious file
   v
Attacker's folder
   |
   | Send collaboration invitation
   v
Victim
   |
   | Does NOT accept invitation
   v
Desktop Application
   |
   | Automatic synchronization
   v
accounts.bat appears on victim's PC

From File Delivery to RCE

Now there was one more step.

The file was a accounts.bat file.

None None None

If the victim opens it, Windows executes the commands inside the batch file.

For my proof of concept, the command was simply:

@echo off
cmd /k

When the victim opens the file, a command prompt is opened.

This demonstrates that the attacker-controlled file can execute commands under the victim's local user context.

The important thing here is that the application itself does not need to automatically execute the .bat file.

The security issue is that the attacker can deliver the file to the victim's computer without the victim accepting the collaboration.

The final step depends on the victim opening the file.

Why This Is Dangerous

At first look, someone might say:

"The victim still has to open the file."

None

That's true.

But the important security boundary has already been crossed.

The attacker was able to place attacker-controlled content on the victim's computer through a trusted desktop application without the victim accepting the collaboration.

This makes the synchronization feature a potential file-delivery mechanism.

An attacker could potentially use this for social engineering by giving the file a convincing name and placing it inside a directory that the victim already trusts.

The Complete Attack

The complete attack can be summarized as:

1. Attacker creates a folder
          ↓
2. Attacker uploads malicious .bat
          ↓
3. Attacker adds victim as collaborator
          ↓
4. Victim does NOT accept the invitation
          ↓
5. Desktop application synchronizes the folder
          ↓
6. Malicious file appears on victim's computer
          ↓
7. Victim opens the file
          ↓
8. Commands execute with victim's privileges
None

Root Cause

The main problem appears to be the way the application handles collaboration status.

A collaboration invitation can have different states:

Pending
Accepted
Rejected

A pending invitation should not give the desktop application permission to synchronize the shared content.

However, in this case, the desktop application synchronized the content while the invitation was still pending.

The application effectively treated:

Invitation Sent

as:

Collaboration Accepted

This is the authorization problem that makes the attack possible.

What Should Happen?

The expected behavior should be:

Invitation Sent
       ↓
     Pending
       ↓
No synchronization
       ↓
Victim accepts
       ↓
Synchronization starts

Instead, the actual behavior was:

Invitation Sent
       ↓
     Pending
       ↓
Synchronization starts
       ↓
Files appear on victim's computer

The victim's acceptance was not required.

What Can an Attacker Do?

None

The vulnerability can potentially allow an attacker to:

  • Deliver attacker-controlled files to another user's computer.
  • Use the desktop synchronization system as a file-delivery mechanism.
  • Deliver scripts or other potentially executable files.
  • Execute commands if the victim opens the malicious file.
  • Potentially perform further actions depending on the privileges of the victim's account.

For the proof of concept, I used a harmless cmd /k command and did not perform any destructive actions.

And after all that… I found out someone had already reported the same issue 4 days before me. 💀

Well, at least I know I was looking in the right place. 😅

None

References:

ZDI-25–773 — Google Drive File Sharing Mark-of-the-Web Bypass Vulnerability — Zero Day Initiative. Read the advisory