The AI Picked Its Own Target: Autonomous Discovery of Hardcoded OAuth Credentials on a YesWeHack Program

Executive Summary

This is not a story about a critical, headline vulnerability. It is a story about who found it, and how much they had to do to find it.

During a research session on a live, authorized YesWeHack public program, an XHack researcher pointed XHack AI at a wildcard scope, gave it a single instruction, and walked away. The target was not a soft one. It was a program that had already been worked over by strong researchers, the kind of scope where you assume everything easy is long gone.

About 25 minutes later, XHack AI had, with no further guidance:

• Chosen its own target inside the wildcard
• Found a live OAuth client_secret hardcoded in a publicly downloadable Flutter web bundle
• Confirmed the secret was valid by exchanging it for a real access token
• Written a full finding report
• Generated a standalone Python proof of concept to demonstrate validity to the program's triage team

The finding was submitted, triaged, and accepted. The program rated it Low severity (CVSS 3.7) under CWE-798: Use of Hard-coded Credentials and paid a €100 bounty. The total compute cost of the run was on the order of $5.

The point of this case study is the ratio. A researcher gave one line of instruction and a few dollars of compute, and an autonomous agent returned a valid, accepted, paid finding on a hard target. The vulnerability class is old. The way it was found is not.

The Setup

The engagement was informal by design. There was no scoping call, no defined target list beyond the program's own wildcard, and no human hypothesis about where a bug might live. The researcher deliberately provided as little context as possible, to see what the agent would do on its own.

The instruction, in full, was effectively: "Recon. Pick your own target. Go."

That is the part worth sitting with. On a normal engagement, a human decides which host, which endpoint, which asset is worth attention. Here, that decision was handed to the agent. The wildcard covered a broad surface, and XHack AI had to reduce it to something worth attacking before it could attack anything.

Autonomous Recon

XHack AI began the way a human researcher would, but without being told to. It enumerated subdomains, mapped HTTP surfaces, pulled down and inspected client-side assets, and organized its own working notes as it went. It maintained its own scope file, its own recon output, and its own findings directory, deciding for itself what was worth keeping.

Among the assets it pulled was the JavaScript for a Flutter web application, an "instant mini-loan" product sitting inside the wildcard. Flutter web compiles to a single large main.dart.js bundle, in this case around 3.7 MB, shipped in full to every visitor's browser. Bundles that size are exactly where secrets hide: too large to review by eye, small enough to grep with intent.

XHack AI parsed the bundle and flagged something that did not belong in client-side code.

The Finding: A Live OAuth client_secret in the Bundle

Inside main.dart.js, XHack AI identified two hardcoded OAuth client_credentials pairs, each a client_id and a base64-encoded client_secret, embedded directly in the compiled application. A client_secret is a confidential, server-side value. Shipping one in a public bundle is equivalent to publishing it.

The agent did not stop at "this looks like a secret." It tested the claim.

Technical Breakdown

The vulnerability is a clean example of CWE-798: Use of Hard-coded Credentials (with CWE-522: Insufficiently Protected Credentials).

Location. The credentials were extracted from GET /main.dart.js, the public Flutter bundle. The secret in question was a base64-encoded UUID sitting in a plaintext string inside the compiled JavaScript.

Validation. XHack AI confirmed the secret was live rather than stale by exchanging it directly at the token endpoint:

• It issued a POST to the OAuth token endpoint with grant_type=client_credentials, authenticating with HTTP Basic auth built from the extracted client_id and client_secret.
• The endpoint returned HTTP 200 with a fresh access_token and expires_in: 3600, a real, hour-long bearer token minted on demand.
• As a control, the agent mutated a single character of the secret and repeated the request. That returned HTTP 403 unauthorized_client. The control matters: it proves the endpoint actually validates the secret, so the 200 was genuine authentication and not an endpoint that accepts anything.

The second pair was present in the bundle but its tenant returned 404 at the token endpoint, so the agent recorded it as unverified rather than claiming it worked. It reported only what it could prove.

What the Token Reaches

The minted token was not inert. It passed the API gateway and reached the upstream authentication application, the one exposing routes such as login, forgot/request, forgot/send-sms/{phone}, and password reset/{token}.

Because this is a consumer credit and payments product, the realistic worst case that flows from a valid gateway token is serious: account takeover through the reset and OTP flow, SMS OTP flooding and phishing against arbitrary phone numbers, and fraud enablement on a live payments platform, with the associated ACPR and GDPR exposure. The same Flutter source also ships inside the Android and iOS builds, so the pattern very likely reaches production mobile as well.

Proof of Concept and Report

By the time the researcher returned to the session, XHack AI had already written up the finding and produced the tooling to back it. Its working directory contained a full markdown report, engagement notes, a per-finding writeup, and, critically, a standalone Python proof of concept plus a secret-validation script and an auth-difference verifier.

The Python proof of concept is the part that made triage straightforward. Rather than asking the program to trust a claim, XHack AI generated a script that performs the exact client_credentials exchange, prints the returned token, and demonstrates the mutated-secret control returning 403. A triage analyst could run it and watch a valid token appear. That is the difference between a report that gets debated and a report that gets accepted.

Human Verification

The autonomy does not remove the human from the loop; it changes what the human spends time on. The XHack researcher did not do the finding. The researcher did the checking. Every claim the agent made, the extracted secret, the successful token exchange, the 403 control, the reachable upstream routes, was manually reproduced before anything was submitted. The finding held up.

This is the honest shape of AI-assisted offensive security today. The agent handled discovery, validation, and reporting at machine speed. The human confirmed it was real and took responsibility for submitting it. Neither half would have produced this result alone in 25 minutes.

Outcome

The finding was submitted to the program through YesWeHack and accepted.

• Class: CWE-798, Use of Hard-coded Credentials
• Program rating: Low severity, CVSS 3.7
• Reward: €100, plus reputation points
• Effort: one line of human instruction, roughly $5 of compute, about 25 minutes unattended

It is worth being precise about the severity. XHack AI's own analysis rated the confirmed, exploitable path as High. The program triaged it as Low and rewarded it accordingly. Both facts are true, and the gap between an agent's risk assessment and a program's payout decision is normal in bug bounty. We report the finding as accepted and paid, not as critical, because that is what it was.

What the low number does not capture is the method. A picked-over target. A wildcard the agent had to narrow itself. A confidential credential recovered from a 3.7 MB bundle and proven live against a production token endpoint. A working exploit and a triage-ready report waiting when the researcher got back to the desk.

Why This Matters

Hardcoded credentials are one of the oldest vulnerability classes there is. That is exactly why this case is interesting. The bug was not novel; the discovery was. On a scope where experienced humans had already looked, an autonomous agent chose its own target, found a real secret, proved it, and packaged it for triage, on a compute budget smaller than a lunch.

Most of the industry has not internalized what that means yet. The bottleneck in finding this class of bug was never the exploitation. It was the patience to grep a multi-megabyte bundle, the discipline to validate rather than assume, and the time to write it up cleanly. Those are precisely the things an agent does not get bored of.

Note on disclosure: This finding was made against a live target under an authorized YesWeHack public program, within that program's scope and rules. All identifying details of the target, its domains, endpoints, and credentials have been redacted. No exploitation was performed beyond the minimum needed to confirm the secret was valid, and nothing beyond a proof of concept was executed. The target has been redacted throughout at the researcher's discretion and in line with responsible disclosure.