# Sanity to Insanity: Chaining Public CMS Misconfigurations to Remote Admin Access on Production

In this write-up, I’m going to show you how I pulled a single loose thread a forgotten JavaScript file on a dev server and unraveled an entire company’s security architecture, achieving full Administrative Account Takeover on their live production environment.

My recon started as it always does: broad subdomain enumeration. I was scanning the target (let’s call them `TargetCorp`) when I noticed a standard development instance:

[`https://project-dev.target-domain.ch`](https://project-dev.target-domain.ch/)

Most hunters would glance at this, see a broken UI or a generic login page, and move on.

But I decided to dig deeper. I opened Chrome DevTools and started auditing the static assets. I opened a file named `main.js` and searched for keywords like `api`, `key`, `user`, and `password`.

And there it was. Hardcoded right inside the client-side code:

![](https://miro.medium.com/v2/resize:fit:1281/1*PZ9lWRDraCFYRnRgeQSZWw.png align="center")

```javascript
// Snippet reconstructed from main.js
export const authConfig = {
    username: "internal_admin_svc",
    password: "10255fa7-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
    sanityProjectID: "REDACTED_ID",
    partnerKeys: {
        GlobalCarManufacturer_A: "accce0eda...",
        GlobalCarManufacturer_B: "2752A1FC..." 
    }
};
```

At first glance, this looked like test data. Surely this was just a dummy account for the dev environment.

I had two pieces of information:

* **Credentials:** A username and a password.
    
* **Target API:** The code was configured to send requests to [`https://theia-api.target-domain.ch`.](https://theia-api.target-domain.ch./)
    

I checked the target API. It wasn’t a dev endpoint. It was the **Live Production API** used by the company and its partners (**Three of the biggest Global Car Manufacturer in the world**) to calculate pricing offers and manage installation projects.

> ***Did the developers reuse the same “test” credentials on the live server?***

I fired up my terminal. It was time to test the “Skeleton Key.”

I constructed a `curl` request, attempting to exchange the credentials I found in the dev file for an access token.

```bash
curl -X POST "https://theia-api.target-domain.ch/connect/token" \
  -H "Authorization: Basic [Base64_Encoded_internal_admin_svc_Creds]" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "grant_type=client_credentials"
```

I hit Enter and held my breath.

![](https://miro.medium.com/v2/resize:fit:1281/1*WTPqHGqw7pFkcWYdBy_p2g.png align="left")

```json
{
  "access_token": "eyJhbGciOiJSUzI1NiIsImtp...",
  "expires_in": 3600,
  "token_type": "Bearer",
  "scope": "lead-project"
}
```

I decoded the JWT to check my permissions. The scope was `lead-project`. In the context of this application, It grants full CRUD (Create, Read, Update, Delete) access to the customer database.

I could now:

* Retrieve names, addresses, and project details for every customer.
    
* Delete active installation projects or cancel leads.
    
* Create fake orders to disrupt the business.
    

I had walked through the front door of the production environment.

---

But I wasn’t done. Remember the `partnerKeys` I saw in the JavaScript file?

The `main.js` file also leaked API keys for major B2B partners like *GlobalCarManufacturer\_A* and *GlobalCarManufacturer\_B*. I wanted to see if these were active. I used the leaked GlobalCarManufacturer\_A App Key to query the company’s internal "NBO" (Next Best Offer) API the engine that calculates pricing.

```bash
curl "https://internal-pricing.target-domain.ch/api/nbo/em/templates?appKey=[REDACTED_GlobalCarManufacturer_A_KEY]"
```

```json
["BYES_Comm_WallboxBasic", "Pricing_Template_v2", ...]
```

![](https://miro.medium.com/v2/resize:fit:1281/1*SP30NCPK8P7p7wi-OWaO4w.png align="left")

It worked. I was now authenticated as `GlobalCarManufacturer_A`. I could see their specific product configurations, pricing logic, and internal templates. A competitor could use this to scrape proprietary pricing data and undercut the company in the market.

---

Digging even further, I realized *why* these keys were in the file.

The application relied on **Runtime Configuration**. Instead of building environment variables into the code during the CI/CD build process (which would hide them on the server), the frontend was designed to fetch its configuration (API keys, endpoints, secrets) from a CMS *after* the page loaded.

I checked the CMS instance (`redacted.api.sanity.io`). The dataset was set to **Public**.

Because the CMS dataset had to be public for the website content to load, it inadvertently made the **configuration secrets** public too.

---

To summarize the damage:

* Full administrative access to customer data (PII) and corporate IP (pricing logic).
    
* Ability to modify or delete real-world solar installation projects.
    

![](https://miro.medium.com/v2/resize:fit:1281/1*SFV7-Pf23NWVLdb33XknlQ.png align="left")

*Thanks for reading! If you learned something new, pray for* ***Gaza*** *and* ***Sudan****.*