I am AgentZeroX — a penetration tester, bug hunter, red teamer, and overall security researcher.

I live for those moments where a bit of out-of-the-box thinking cracks open a critical vulnerability. The kind of moments where something small, almost invisible, turns into a full-scale security issue.

This write-up is about one of those moments.

Sometimes the most critical vulnerabilities aren't hidden behind complex exploit chains.

Sometimes…

They're just sitting inside a JavaScript file.

This is the story of how a seemingly harmless JavaScript bundle, combined with simple reconnaissance and manual inspection, resulted in full Owner-level access to a B2B translation infrastructure, exposing internal systems, employee information, and business-critical data.

More importantly, it demonstrates how thinking differently during reconnaissance can reveal vulnerabilities others completely overlook.

🎯 Target

https://b2b.redacted.cz/

The target was part of a B2B platform infrastructure used for managing translation systems across internal applications.

To begin the assessment, I started with reconnaissance.

🔎 Step 1 — Initial Reconnaissance

The process started with subdomain enumeration to discover additional assets belonging to the target organization.

Using subfinder, I gathered all available subdomains:

subfinder -d target.com -all -silent -o subdomains.txt

This helped identify multiple subdomains associated with the platform.

Next, I checked which subdomains were alive using httpx:

cat subdomains.txt | httpx -silent > subdomains_alive.txt

This provided a list of active web services worth investigating further.

🌐 Step 2 — Crawling the Target

Once the live hosts were identified, the next step was endpoint discovery.

To enumerate hidden routes, JavaScript files, and potential API endpoints, I used katana:

katana -list subdomains_alive.txt -silent -o urls.txt

The crawler extracted multiple resources including:

  • API endpoints
  • Static resources
  • JavaScript bundles
  • Internal routes

Among these results were several JavaScript files, which often contain valuable information for security researchers.

📜 Step 3 — Extracting JavaScript Files

JavaScript files frequently contain:

  • Hidden API endpoints
  • Internal logic
  • Configuration variables
  • Occasionally hardcoded secrets

To isolate the JavaScript resources discovered during crawling:

grep "\.js" urls.txt | sort -u > js_files.txt

This created a refined list of JavaScript files to analyze.

During this process, one specific file stood out:

/main-OMYF25AZ.js

Instead of simply viewing it in the browser, I began searching inside it for sensitive patterns.

🕵️ Step 4 — Searching for Secrets

When analyzing JavaScript files, I typically search for patterns related to:

  • API keys
  • Access tokens
  • Authorization headers
  • Internal endpoints

Using grep, I scanned the files:

cat js_files.txt | xargs -I{} curl -s {} | grep -i "token"

During this inspection, something alarming appeared.

A hardcoded access token was embedded directly inside one of the JavaScript files.

This wasn't a frontend token.

It was a production API token for Phrase, a translation management platform used by organizations to manage localization pipelines across applications.

That's where things escalated quickly.

🚨 Step 5 — Verifying the Token

To confirm whether the token was still valid, I tested it against the platform's API endpoints.

Example request:

curl -H "Authorization: Bearer <TOKEN>" https://api.target.com/v2/projects/projectid/members?access_token=redacted

The response confirmed several critical details:

  • Manager-level account
  • Corporate email address
  • Active production user
  • Recently updated activity

This was not a test credential.

It was a live production token tied to a privileged account.

None

🚨 Step 6 — Enumerating Phrase Projects

Using the exposed token against the Target API:

curl https://api.target.com/v2/projects?access_token=REDACTED

The response revealed several internal environments including:

  • B2B Front Office
  • B2B API
  • Internal systems
  • Security Test Project
  • Multiple production environments

At this point it became clear:

This wasn't just translation data.

This was business infrastructure.

None

🚨 Step 7 — Owner-Level Privilege Discovery

While inspecting account metadata, I identified an account_id.

account_id = redacted

Querying the account metadata revealed that the token had the following roles:

  • Owner
  • Admin
  • ProjectManager
  • Developer
  • Designer
  • Translator

This effectively meant Owner-level control over the Phrase account.

🔥 Impact Demonstration

To safely demonstrate the impact without affecting production systems, I performed controlled testing.

Creating a Test Project

POST /v2/projects?access_token=$TOKEN

A project was successfully created.

Deleting the Project

DELETE /v2/projects/{id}?access_token=$TOKEN

The project was immediately deleted after creation.

This confirmed:

  • Full administrative privileges
  • Project creation permissions
  • Project deletion permissions
  • No secondary verification

☢️ Stored Translation Injection

The most dangerous part was not administrative access.

It was the ability to inject malicious translations.

Phrase stores translation strings used by:

  • Web applications
  • Mobile applications
  • Backend services

I uploaded a translation file containing a malicious payload:

{
 "login_error": "<script>alert(document.cookie)</script>",
 "welcome_message": "System compromised"
}

The upload succeeded.

This means malicious code could propagate through translation pipelines into production applications.

Potential impact:

  • Persistent Stored XSS
  • Cross-platform injection
  • Supply chain risk
  • Difficult detection inside localization workflows

📊 Business Intelligence Exposure

Using the same token, I was able to:

  • Enumerate 25+ internal users.
  • Extract usernames, roles, timestamps
  • Access full project metadata
  • Download entire translation databases in:
  • JSON
  • i18next
  • YML
  • Properties
  • XLF

Some files exceeded 400KB+ of structured business content.

This includes:

  • API endpoints
  • Error messages
  • Feature flags
  • Internal naming conventions
  • Potential hidden functionality references

This is gold for attackers

⚠️ Severity

Critical (P1)

Impact includes:

  • Complete account compromise
  • Owner-level project manipulation
  • Persistent cross-platform injection
  • Internal data exposure
  • Business intelligence harvesting
  • Potential supply chain exploitation

🧠 Important Mindset Shift

This vulnerability wasn't found using a zero-day exploit.

It wasn't found using a custom scanner.

It wasn't found using brute force.

It was found by doing one simple thing:

Looking where others don't.

Stop thinking:

"How do I finish labs?"

Start thinking:

"How do I find what others miss?"

That's where money is.

That's where impact is.

That's where you become dangerous.

Final Thoughts

This wasn't just a bug.

This was a reminder.

Sometimes, the biggest breaches start with a single exposed string in a JavaScript file.

The difference between a lab solver and a real hacker?

Curiosity.

Keep digging.

Peace.