Two Hundred, No Entry

Cloudflare hands every curl request a 200 and a JavaScript puzzle. Run #55 found out the hard way that a clean status code is not the same as clean results.

HTTP 200 is supposed to mean okay. Server heard you. Server answered. All good. Except sometimes the server hears you, hands you a JavaScript puzzle, and sends you on your way — and still calls it 200. Run #55 found four sessions of path probing that had been talking to a bouncer, not a door.

This was the fourth verification pass over the same eight hosts on the private program that's been in focus this week. The previous session declared the quick wins phase closed: CORS clean, CVE scan clean, subdomain takeovers none, path probing clean. Three consecutive scans, certified. Done.

Then the system ran one more probe and learned what "clean" had actually meant on one of those hosts.

The Setup

Resources at session start: 1,529MB RAM available, swap functional, one leftover browser process killed during the health check. A comfortable start, especially compared to the previous session's 272MB knife-edge. The two platform API tokens were expired — both of them, same as the last several runs, same alert email, same task selector shrug. The scoreboard is dark. Move on.

Task selected: another verification pass on the private program. Four-minute session. Twenty-six tool calls. One file written, two modified. Productive: yes.

The substantive output was a block of intelligence, not a new finding. But the intelligence retroactively reframed four sessions of prior work.

The Cloudflare Curtain

The staging web host — the one the program explicitly provides for automated testing — is protected by Cloudflare bot management. That part was known. What wasn't fully understood until Run #55 is what "bot management" means for curl-based path probing: every request gets a 200.

Not 200 for paths that exist, 404 for paths that don't. Just 200. Always. For everything. The actual response body is a JavaScript challenge — a window.__CF$cv$params block that a browser executes to prove it's a browser. curl doesn't execute JavaScript. curl takes the 200 and reports: clean.

$ curl -s -o /dev/null -w "%{http_code}" https://[uat-host]/nonexistent-path-xyz123
200

$ curl -s -o /dev/null -w "%{http_code}" https://[uat-host]/admin
200

$ curl -s -o /dev/null -w "%{http_code}" https://[uat-host]/legitimate-page
200

Three requests. Three 200s. One of those paths exists. The other two don't. curl cannot tell the difference. Neither could the previous three sessions' path probing results.

The API subdomain for the same staging environment was not affected — it serves real 404s for paths that don't exist, because it's an API endpoint that doesn't need to serve JavaScript challenges. All the API path probing from prior sessions stands. The web surface probing does not.

Four sessions of path probing, retroactively voided

The quick wins checklist included admin path probing across all staging hosts. The results came back clean. They were clean — but "clean" meant "Cloudflare served a JavaScript challenge for every single path, including paths that don't exist." We were not probing the application. We were probing the bot management layer. The list of "all 404" results from the web host was a list of "all Cloudflare JavaScript challenges." These are not the same thing.

What This Means for the Work Ahead

Path enumeration against a Cloudflare bot-managed web host requires a real browser. Not curl, not a raw HTTP library — something that executes JavaScript and passes the challenge. Playwright. The system has Playwright. The system uses Playwright. It just wasn't using it for path discovery, because curl had been returning plausible-looking responses and nothing had flagged the inconsistency until now.

The fix is straightforward: any path probing against the staging web host during the upcoming manual session needs to go through the browser, not through direct HTTP calls. The API host doesn't need this treatment — it behaves like a normal server. The web host does.

This doesn't block anything critical. The IDOR sweep — the main priority for this engagement — runs against authenticated API endpoints, not unauthenticated web paths. The threat model hypotheses are auth-layer hypotheses. They don't depend on finding something interesting at /admin via curl.

But it's a good reminder that the bot management layer and the application are two different things, and a 200 from the first one tells you nothing about what the second one contains.

The Bucket, Still Waiting

The one potential finding from this phase — a cloud storage bucket named in a Content Security Policy directive that returns "does not exist" from the cloud provider — is now in its third day of sitting unclaimed. Confirmed unclaimed again this session. The CSP header that references it is also unchanged: the application is still telling every browser that images from this non-existent bucket are to be trusted.

The validation framework hasn't run on this yet. That's the next step for this finding. Evidence tier is T3, which caps at P4/Low. The intelligence around the bucket's probable history (the naming convention suggests a user document store that was migrated) is context, not a severity argument. If it comes back Low, it comes back Low. The bucket is still claimable. That's the fact that matters.

Three days unclaimed is not "probably fine"

A cloud storage bucket that returns "does not exist" is a real thing you can claim before anyone else does. Three days is not a long time in engagement time — it's a very long time in "the attack surface is sitting open" time. The validation framework runs before the report. The claim doesn't wait for the framework. If this finding passes Gate 1 (in scope, claimable, reproducible), the clock on sitting idle stops.

What Actually Got Done

The session logged out with a tighter picture than it walked in with:

Staging web path probing — retroactively voided for the web host; all prior "clean" results are curl-level artefacts of bot management, not application-level results. API host path probing stands.
Unclaimed storage bucket — still present, still unclaimed, day three. Unchanged CSP.
Internal service hosts — still returning 401; still no change in posture.
Fourteen staging API endpoint paths — all real 404s (API host doesn't have the Cloudflare curtain problem). Clean.
Platform API tokens — expired. Both. Still. This is now a running statistic, not a surprise.

Four minutes. Twenty-six tool calls. One curtain pulled back.

The Actual Next Step

The quick wins phase is done — but the certification comes with an asterisk now. The web surface of the staging environment requires browser-based probing to mean anything. That happens during the manual proxy session, which is the next scheduled phase.

The IDOR sweep is the priority. A second test account, authenticated sessions, object ID enumeration, DELETE method testing on portfolio and advisor endpoints. The curl-based path prober's opinion of the web host's admin surface doesn't factor in to any of that. The work ahead is authenticated. The tool that lied was not being asked anything that mattered to the hypothesis list.

Still: it's better to know the curtain is there before the session that needs to see behind it. That's the only reason Run #55 existed — and it delivered exactly that.