An Open Kibana Exposed native.org's Trading Stack

Coordinated disclosure, reported in good faith with no bounty or payment involved. native.org has remediated the issue and cleared this writeup for publication. The affected host address is withheld.

Summary

• 207index patterns exposed
• 21live API keys recovered
• 8,700+log entries every 15 min

A native.org Kibana instance indexed the company’s trading infrastructure across staging and UAT, 207 index patterns in total, and the API gateway behind it was logging live API keys in plaintext.

native.org is a DeFi liquidity platform. Its on-chain RFQ system sources quotes from private market makers and serves them to traders across chains, with the resulting flow hedged on centralized exchanges. The exposed instance was part of a UAT environment. native.org confirmed that none of the leaked keys were used in production, added authentication to the instance, and rotated the keys.

Exposed Kibanas are common. Two things here deserve more attention: what an open observability stack gives away, and how ordinary the mistake behind the key leak was.

Key points

• The instance required no authentication. The Kibana UI loaded, every index was queryable, and saved objects enumerated, all with zero credentials.
• The 207 index names were a map of the whole operation: pricing, hedging, risk, liquidation, settlement, on-chain monitoring, centralized-exchange integration, cross-chain pegs, and emergency stop controls. You could read the architecture without opening a single document.
• The API gateway logged raw API keys to its output, which flowed into Elasticsearch. We recovered 21 keys from the live log stream. At the time, one index was taking more than 8,700 log entries every 15 minutes, so the system was clearly live.

What an open dashboard gives away

Index names are meant to be operational plumbing, not a threat surface. A complete, named list of every service tells an attacker exactly how a system is built. In native.org’s case the names described the trading stack end to end: quote-order-task and order-manager for order flow, pricer and quote-ticker for pricing, risk-manager and liquidation-price-task for risk, trade-hedger-task and hedge-signer for hedging, cex-monitor and cex-position-monitor for centralized-exchange integration, settlement for clearing, soft-peg tasks across several chains, and emergency-stop-task and emergency-paused-task for the kill switches.

None of that needed a document or a credential. The list of index names on its own is a design review. For anyone planning an attack, that is most of the homework done.

The leak goes past architecture. The same names spell out strategy: indexes for arbitrage, pair trading, market-impact estimation, and cross-chain pegging, which tell a competitor how the firm tries to make money, often the more valuable half. The cluster wasn’t only trading data either. It also held the firm’s own security telemetry, the host, network, and endpoint audit logs and the alerts meant to catch an intruder. Anyone reading that can see what the defenders can and can’t.

Even the smaller operational details bleed through the naming: the hosting region, the cloud provider, the components partway through a rewrite into a new language, and the internal protocols in use. Any one of them is trivia. Together they hand an attacker the reconnaissance they would otherwise have to do themselves.

The names themselves are fine. They are the kind of clear, sensible naming any team would use. What went wrong is that the dashboard they live in was open to anyone.

The keys in the logs

The more direct problem was in the API gateway logs. The gateway’s key-lookup function logged the full key object on every successful lookup, and those log lines landed in Elasticsearch like everything else. Opening the gateway index and filtering for that function returned a stream of entries like this:

[refreshApiKey] auth.GetByApiKey success, apiKey:
{"id": 9, "api_key": "faa79a…362f1f", "name": "[redacted]", "rate_limit": 20}

We recovered 21 distinct keys this way. This is one of the most common logging mistakes there is: log the whole request or auth object while debugging, then forget it ships to a store that someone else can read. The credential and the place you keep your logs become the same thing.

Impact, in proportion

This was a UAT environment, and native.org confirmed the keys were not used in production. That matters, and we’re not going to dress it up as a near-miss on a live trading desk. It wasn’t that.

It was still serious. A live, internet-facing instance with no authentication was logging real credentials in plaintext and exposing the full design of a money-handling platform. The keys were UAT keys, but the index was taking thousands of log lines every few minutes, so the traffic was real, and the architecture it exposed is the same architecture the production system runs on. The gap between “it’s only UAT” and “it’s on the public internet logging live keys” is the whole story.

Proof of concept

The instance answered unauthenticated requests on its HTTP port. Confirming it took three steps, none of which needed a tool more exotic than curl or a browser:

• GET /api/status returned the Kibana version and node name with no credentials.
• GET /api/saved_objects/_find?type=index-pattern&per_page=500 returned all 207 index patterns.
• Opening the gateway index in Discover and filtering for the key-lookup function showed the logged keys.

A TLS certificate on the host’s 443 port (CN=*.native.org, issued by Cloudflare Origin CA) confirmed the instance belonged to native.org.

Disclosure timeline

• 2 June 2026We found the exposed instance during threat intelligence research and reported it to native.org with the affected endpoint, the index list, a redacted sample of the logged keys, and remediation steps.
• 18 June 2026native.org confirmed the exposure. They added authentication to the instance, rotated the affected keys, confirmed that the instance and keys belonged to a UAT environment with no production keys involved, and set out the redactions they wanted for publication.
• 19 June 2026Published with native.org's input, applying the redactions they requested.

native.org responded quickly, fixed the issue, and worked with us on the writeup. We flagged it because the exposure was serious and they needed to know, not for anything in return. That is how coordinated disclosure should work.

For teams running the same stack

• Put Kibana and Elasticsearch behind authentication. Enable xpack.security.enabled and keep the HTTP port off the public internet. An ELK stack with no auth is a database with a web UI open to the world.
• Treat your log store as readable by anyone who can reach it. If a credential can land in a log line, assume it will be read.
• Do not log whole auth or request objects. Log an identifier, never the secret. The key-lookup path is exactly where this goes wrong.
• Remember that your index and service names describe your system. Keep the place they live private.
• Inventory your old environments. The names here carried tags like uat-v1, uat-v2, staging, and shadow, layers of test setups built up over time. The forgotten one is usually the one that ends up public.

Credit

Thanks to the native.org team for a fast, professional response, and for working with us on what could and could not go into this report.