Post cover image

September 3, 2026

CORS Finding | I Almost Skipped This Target Until I Did This…

Hello hackers! I’m back with another writeup. This time, I want to share a very unique Cross-Origin Resource Sharing (CORS)…

By Coolorangee

3 min read

Hello hackers! I'm back with another writeup. This time, I want to share a very unique Cross-Origin Resource Sharing (CORS) misconfiguration finding.

So in this pentest session i almost skipped this one. If it weren't for the fact that I fully trust the tool I was using (https://github.com/coolORANGE3/CORS-X) which rarely produces false positives. This case is a perfect example of why you should never take a single HTTP response as the absolute truth when testing modern web architectures.

Here is how a stubborn tool and a bit of request spamming led to a valid bug.

🔍 The Discovery: Trusting the Tool

During my reconnaissance on a target, my CORS scanner (https://github.com/coolORANGE3/CORS-X) flagged a vulnerable endpoint. According to the tool, the endpoint was reflecting arbitrary origins and allowing credentials.

None

I fired up Burp Suite to verify it manually. I intercepted the request, added the header Origin: [https://evil.com](https://evil.com), and sent it to Repeater.

The response came back completely normal. No Access-Control-Allow-Origin (ACAO) reflecting my payload, or it just returned ACAO: * without Access-Control-Allow-Credentials: true.

None

But I know how "cors-x" works under the hood, and it doesn't just hallucinate vulnerabilities. So, instead of moving on, I decided to spam the Send button in Burp Repeater.

Request 1: Safe.

Request 2: Safe.

Request 3: Safe.

Request 4: Safe.

Request 5: VULNERABLE!

Suddenly, the response headers changed completely:

None

🧠 Root Cause Analysis: The Security Guard Analogy

So, why did the exact same request produce entirely different responses?

After i do research i found that the answer lies in the target's infrastructure. The application was sitting behind a Cloudflare Load Balancer, which routed incoming traffic to multiple backend instances. The problem was that these instances did not have synchronized configurations.

To put it simply, imagine the load balancer as the main gate of a building, and the backend instances are different security guards on duty.

  • Guard A (Proper Instance): Is strict, follows the standard operating procedure, checks your ID, and rejects unauthorized access.
  • Guard B (Misconfigured Instance): Is careless, using outdated instructions (maybe a leftover staging config), and just waves anyone through.

When you send a single request and it fails, it just means you met Guard A. But if you keep trying, eventually the load balancer will route your request to Guard B.

The Architecture Breakdown

Here is a visual representation of what was happening under the hood:

Request: Origin: https://evil.com
               ↓
Load Balancer (Cloudflare) picks a random backend instance
               ↓
┌─────────────────────────────────────────────────────────────┐
│                                                             │
│    Instance A (Production)         Instance B (Staging/Old) │
│    ┌───────────────────┐           ┌───────────────────┐    │
│    │ CORS Config:      │           │ CORS Config:      │    │
│    │ origin: '*'       │           │ origin: true      │    │
│    │ (Wildcard, no     │           │ (Reflects input,  │    │
│    │  credentials)     │           │  credentials ON)  │    │
│    └───────────────────┘           └───────────────────┘    │
│             ↓                                ↓              │
│    ACAO: *                         ACAO: https://evil.com   │
│    (Browser blocks)                ACAC: true               │
│                                    (Browser ALLOWS) ← VULN  │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Because Instance B was configured to dynamically reflect whatever was in the Origin header and set ACAC: true, any attacker who gets routed to this specific instance can bypass the Same-Origin Policy (SOP).

🚨 Impact

By exploiting this misconfiguration, an attacker can craft a malicious HTML page hosting a JavaScript payload. When an authenticated victim visits this page, the script will send cross-origin requests to the vulnerable endpoint.

Because the load balancer routes traffic dynamically, the script only needs to send the request in a loop (spamming the endpoint) until it hits the misconfigured instance. Once it does, the browser will allow the attacker to read the victim's sensitive data from the response.

💡 Takeaways

  1. This teach and remind us that we should definitely understand how the pentest going, like in this case when i was using my tool (that i believe powerfull enough that wouldn't get False/Positive), after my tool found vulns target i would confirm it and when i send the injected request (add header "Origin: evil.com") the response still the same even a couple like 2–3 request sending but i know my tool wont miss so 1 thing that come up to my mind is do multiple request sending, so i do spam send on repeater and boom! reflected on the response then i understand that my tool's payload that posisition like in the middle got it stack (triger the vuln) and if i dont understand my tool, on the confirm tool's finding session for the first or a couple response…i would skip this target and think my tool was F/P…

Anyways Thanks for reading yall! Keep digging, keep learning, much love and happy hacking guys❤!