Bug bounty hunting constantly reminds me of one thing:

A vulnerability that looks "useless" alone can become critical when combined with another weakness.

This report was one of those moments. At first glance, I had:

• a reflected XSS on an out-of-scope domain,
• and a seemingly boring CORS issue on another asset.

Individually, neither looked exciting.

Together, they formed a complete cross-origin authenticated data-theft chain capable of extracting private user information from logged-in users.

The best part?

The attack worked with a single click.

The Target

While testing assets belonging to the same organization, I noticed two related domains:

• event.example.com
• honoristen.example.com

One handled event-related functionality. The other exposed a WordPress REST API.

At this point, nothing looked particularly dangerous.

But bug bounty hunting is often about asking:

"What happens if two weak things touch each other?"

Phase 1 — Discovering the CORS Misconfiguration

While enumerating the WordPress API, I found the endpoint:

/wp-json/wp/v2/users/me

Normally, this endpoint returns information about the currently authenticated user.

That is expected behavior.

The important question was:

"Can another origin read this response?"

So I sent a request with a fake Origin header.

GET /wp-json/wp/v2/users/me HTTP/1.1
Host: honoristen.example.com
Origin: https://attacker-site.com

The response immediately caught my attention.

Access-Control-Allow-Origin: https://attacker-site.com
Access-Control-Allow-Credentials: true

That combination is extremely dangerous.

The server was:

• reflecting arbitrary origins,
• while simultaneously allowing credentialed requests.

Meaning:

If JavaScript could execute from any allowed origin, the browser would happily send the victim's authenticated cookies and allow the malicious origin to read the response.

In simple words:

Any trusted execution context could silently steal authenticated API data.

At this point, the issue was already serious.

But there was a problem.

The Problem — "You Still Need JavaScript Execution"

A dangerous CORS policy alone is not always enough.

You still need:

• JavaScript execution,
• on an attacker-controlled or trusted origin,
• while the victim is authenticated.

And that is where the second vulnerability entered the story.

Phase 2 — Finding the "Useless" XSS

On another related domain, event.example.comI found a reflected XSS vulnerability in the PAGEID parameter.

The payload reflected directly into the page.

Simple reflected XSS.

Normally, this would already be valuable.

But there was a catch:

The domain itself was considered out of scope.

Most hunters would probably move on.

But something interesting clicked in my head:

"Wait… the browser does not care about bug bounty scope."

The infrastructure trusted itself.

And browsers trust origins — not scope policies.

That changed everything.

The Pivot

The moment I connected both issues, the attack chain became clear.

The out-of-scope XSS could act as a trusted execution environment.

And the vulnerable CORS configuration on the in-scope domain would allow cross-origin authenticated data extraction.

So the flow became:

1. The victim logs into honoristen.example.com
2. The victim clicks on a malicious link on event.example.com
3. XSS executes
4. The browser automatically attaches authenticated cookies
5. Cross-origin request succeeds
6. Sensitive user profile data is stolen

No CSRF token bypass needed.

No account takeover needed.

Just browser trust abuse.

The Unexpected Obstacle

When testing the exploit, something strange happened.

The page redirected too quickly.

The injected JavaScript sometimes failed before the fetch request completed.

Initially, the exploit looked unstable.

Then I remembered an old browser trick:

window.stop()

This function stops further resource loading and interrupts page navigation.

By calling it immediately, I could terminate the native logout redirect before the page unloaded.

That gave my malicious JavaScript enough time to complete the authenticated API request.

Sometimes exploitation is less about advanced payloads…

…and more about understanding browser behavior deeply.

The Final Payload

The final exploit became:

<script>
window.stop();fetch('https://honoristen.example.com/wp-json/wp/v2/users/me', {
    credentials: 'include'
})
.then(r => r.json())
.then(d => {
    alert('STOLEN DATA: ' + JSON.stringify(d));
});
</script>

And delivered through:

https://event.example.com/index.php?ACTION=logout&PAGEID=<script>...</script>

Once opened by an authenticated victim:

• The browser sent session cookies,
• The API trusted the request,
• Sensitive user data became accessible cross-origin.

What Was Exposed?

The endpoint returned:

• full names,
• email addresses,
• user roles,
• WordPress capabilities,
• account metadata.

Most importantly:

"roles":["administrator"]

This created an administrative mapping primitive.

An attacker could identify privileged accounts before launching further attacks.

That significantly increases real-world impact.

Why This Bug Matters

This vulnerability demonstrates a very important real-world lesson:

Security Boundaries Are Often Illusions

Organizations frequently separate:

• products,
• applications,
• subsidiaries,
• environments,
• or bug bounty scopes.

But browsers do not understand organizational boundaries.

They only understand:

• origins,
• trust relationships,
• and permissions.

An "unimportant" XSS on one domain can become the bridge into a highly sensitive production system.

Key Takeaways

1. Never Ignore "Low Severity" Findings

A simple reflected XSS became part of a critical exploit chain.

2. CORS Misconfigurations Are Extremely Dangerous

Especially when:

• origins are dynamically reflected,
• and credentials are allowed.

That combination is often catastrophic.

3. Out-of-Scope Does Not Mean Irrelevant

Even if a domain is outside the bounty scope, it may still:

• share authentication,
• share trust,
• or act as a pivot point.

4. Exploit Chains Matter More Than Individual Bugs

Modern bug bounty hunting is increasingly about chaining:

• weak points,
• browser behavior,
• trust relationships,
• and architectural assumptions.

Final Thoughts

This report ended up being one of my favorite findings because it perfectly captured the mindset difference between:

"finding vulnerabilities"

and

"thinking like an attacker."

The XSS alone was not the real story.

The real story was understanding:

• browser trust,
• cross-origin behavior,
• authentication flow,
• and how independent weaknesses combine into something far more dangerous.

Sometimes the best bugs are hidden between two systems that both believe:

"That's someone else's problem."