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

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:

// 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.

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.

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.

{
  "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.

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

["BYES_Comm_WallboxBasic", "Pricing_Template_v2", ...]

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.

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