React2shell Leads to Full Microsoft 365 SharePoint compromise: How One Server Exploit Exposed an Entire Tenant

As security researchers, we often analyze vulnerabilities in isolation. A Remote Code Execution (RCE) in a web app is one thing; sharepoint compromise in an enterprise cloud is another. But what happens when these two converge? To understand the true "blast radius" of modern application vulnerabilities, we designed a controlled research scenario in our test lab.

This post details a proof-of-concept (PoC) attack chain where a simulated Next.js Server-Side RCE was used to compromise a test organization's Microsoft SharePoint and OneDrive environment.

The critical lesson? Your web application's environment variables can be the keys to your entire kingdom.

The Setup: Simulating the Next.js RCE (CVE-2025-55182)

In our isolated test environment, we deployed a vulnerable Next.js application configured to mimic a common production setup, specifically targeting instances utilizing the App Router and window.__next_f. We then reproduced the conditions for CVE-2025-55182, a flaw allowing arbitrary command execution on the underlying server. Upon successful exploitation of our test instance, our first action was simple enumeration for secrets through environment variables. We executed a command to dump all environment variables accessible to the running process.

In this scenario, we intentionally mirrored a common misconfiguration: passing high-privilege credentials directly into the container's environment.

The Initial Compromise: Next.js RCE (CVE-2025-55182)

We started with REDACTED Target the discovery of a critical Remote Code Execution (RCE) vulnerability in a Next.js application, specifically targeting instances utilizing the App Router and window.__next_f. This particular flaw, now designated CVE-2025-55182, allowed for arbitrary command execution on the underlying server.

Upon successful exploitation, our first action was simple enumeration for secrets through environment variables. This command dumps all environment variables accessible to the running process. What we found was alarming.

CLIENT_ID=xxxxxxxxx
CLIENT_SECRET=xxxxx
TENANT_ID=xxxxxx
SHAREPOINT_BASE_URL=https://graph.microsoft.com/v1.0/drives
....

The server, running as root (itself a critical misconfiguration), exposed a treasure trove of secrets. Among them, the CLIENT_ID, CLIENT_SECRET, and TENANT_ID for Microsoft Azure Active Directory (now Entra ID). This was our golden ticket for lateral movement.

Attack Plot:

Lateral Movement: Pivoting to Microsoft 365

The exposed credentials belonged to an Azure AD Application Registration. This application was configured to use the Client Credentials Flow (a.k.a. "App-only authentication"), meaning it acted as a service principal without needing user interaction or MFA.

Our next step was to craft a curl request to Azure AD's OAuth2 endpoint to obtain an access token:

Bash

curl -X POST -H "Content-Type: application/x-www-form-urlencoded" \
-d "client_id=<EXPOSED_CLIENT_ID>" \
-d "scope=https://graph.microsoft.com/.default" \
-d "client_secret=<EXPOSED_CLIENT_SECRET>" \
-d "grant_type=client_credentials" \
https://login.microsoftonline.com/<EXPOSED_TENANT_ID>/oauth2/v2.0/token

The response was a valid Bearer token. Upon decoding the JWT, the permissions were shockingly broad:

JSON

"roles": [
  "Sites.Read.All",
  "Sites.ReadWrite.All"
]

This confirmed the service principal had full read and write access to all SharePoint sites and OneDrive for Business drives across the entire redacted.com tenant. This isn't just a web app compromise; it's an enterprise data breach.

Data Exfiltration and Integrity Attack Potential

With Sites.ReadWrite.All permissions, the possibilities for an attacker are vast:

1. Mass Data Exfiltration: Access to all confidential documents, client lists, financial records, and intellectual property.

2. Integrity Attacks: Modifying existing documents or uploading malicious files (e.g., infected PDFs, ransomware) to internal SharePoint sites.

3. Ransomware: Deleting or encrypting critical company documents, leading to operational paralysis.

To demonstrate the severity, we used the obtained access token to enumerate files across various SharePoint sites. Instead of blindly crawling, we targeted specific sites that screamed "sensitive data."

Our custom Python script, iterating through discovered sites, quickly hit paydirt:

--- Checking Site: REDACTED Client Files for Website Client Login ---
    [!] FOUND 1 FILES:
        -> XXXXXXXX

--- Checking Site: REDACTED TEAM DOCUMENT ---
    [!] FOUND 15 FILES:

--- Checking Site: REDACTED Clients ---
    [!] FOUND 18 FILES:


--- Checking Site: REDACTED DOCUMENTS ---
    [!] FOUND 69 FILES:

The discovery of files like XXX_Account_Statement.pdf, client agreement..., Contacts_11.csv, and especially Client List.xlsx confirms a Critical data breach. These files represent:

• Financial PII: Bank account details for high-net-worth individuals.

• Legal Documents: Client agreements and Statements of Work.

• Business Intelligence: Proprietary client lists and lead generation data.

Crucially, the presence of @microsoft.graph.downloadUrl with tempauth tokens directly provides pre-authenticated access to these documents. An attacker could use these links to mass-download confidential data without requiring further authentication.

The Takeaway: Supply Chain Security Beyond Code

This incident highlights a critical vulnerability in the modern software supply chain. A flaw in a web framework (Next.js RCE CVE-2025-55182) directly led to the compromise of an entirely separate, mission-critical enterprise system (Microsoft 365 SharePoint).

Recommendations for organizations:

1. Strict Least Privilege: Application Registrations in Azure AD should be granted the absolute minimum permissions required. Sites.ReadWrite.All is almost never justified for a frontend application. Use Sites.Selected where possible.

2. Secure Secret Management: Never store sensitive credentials (like Client Secrets, API keys, Database URIs) directly in environment variables. Utilize secure secret stores like Azure Key Vault, AWS Secrets Manager, or HashiCorp Vault.

3. Runtime Sandboxing: Web applications should run with the lowest possible privileges (e.g., non-root user, containerized with strict security policies).

4. Regular Audits: Continuously audit Azure AD App Registration permissions and review service principal sign-in logs for anomalous activity.

5. Secure Defaults: Frameworks and cloud providers should strive for more secure-by-default configurations that prevent such broad access by compromised services.

The attack surface of a modern application extends far beyond its direct codebase. Securing your applications means securing their entire interconnected ecosystem.