Introduction
Some of the biggest applications get constant attention from hunters. Every API, every endpoint, every feature is poked at.
But I've always been drawn to the parts people ignore: desktop clients.
Most hunters skip them. They're "out of scope" or considered boring. But for me, that's the fun part. I love exploring places no one else bothers to check. I like to think of it as being an explorer and navigator.
Why Desktop?
For this research, I targeted a large management platform. I'll call it Kaizen.
(Yes, the name is unusual, but if you look up the meaning of Kaizen, it actually fits pretty well.)
Instead of starting with the web, I installed the desktop client. Sure, it's an Electron app, which opens a few obvious attack surfaces:
- DLL hijacking
- Weak permissions
- Node integration abuse
- Preload script injection
I knew these were well-trodden paths. I wanted something different.
My focus?
- How the app talks to APIs
- Which third-party services does it communicate with
Intercepting Everything
I configured Burp to intercept all traffic coming from the desktop client. Not just the app traffic.
All Windows traffic.
This created a huge amount of requests, but I actually prefer working this way.
Many researchers set a strict scope in Burp to reduce noise. The problem is that sometimes important requests get filtered out before you even notice them. And in this case, that exact decision ended up revealing something interesting.
I used the app like a normal user: creating tasks, checking dashboards, triggering notifications. After a while, I had a huge request history.
To reduce the noise, I simply filtered for the application name: "Kaizen"
Not just in domains, but anywhere in requests and responses. That's when the first vulnerability appeared.
Vulnerability #1 — Iterable API Key Exposure (Desktop Only)
While reviewing the filtered traffic, I noticed a request to a third‑party CDN.
The response returned a JSON file containing various configuration values used by the application.
Things like: environment configs and API keys
This is not uncommon for modern applications. However, one entry caught my attention. It referenced a service called Iterable.
Iterable is a customer engagement and marketing automation platform used by companies to manage communications
So naturally, I checked their API documentation.
https://api.iterable.com/api/docs
And I started testing a few endpoints using the exposed key.
GET /api/campaigns HTTP/1.1
Host: api.iterable.com
Api-Key: API_KEY
Another endpoint:
GET /api/workflows HTTP/1.1
Host: api.iterable.com
Api-Key: API_KEY
Both requests worked immediately. The responses contained large datasets of user information.
The exposed data included:
- full names
- email addresses
- phone numbers
But that wasn't the surprising part.
Among the records were internal employee accounts as well.
Meaning the API key granted access to both external user PII and internal staff data. At this point the impact was clear:
Critical data exposure through a publicly accessible API key.
Reporting the Issue
Interestingly, the company did not appear to have a public bug bounty program. However, they did run a VDP, so I submitted the report there.
The team responded quickly. They confirmed the issue, labeled it Critical, and — surprisingly — offered me a reward and invited me to their private bug bounty program.
During the discussion, they asked:
"How did you discover that CDN endpoint?"
I explained intercepting desktop traffic and filtering requests.
Their reply:
They confirmed that the desktop client was the only way to access this endpoint. That made the discovery even cooler — it was a hidden path most hunters would never see.
Vulnerability #2 — Split SDK Key Exposure
While analyzing the application further, I collected all JavaScript files used by the desktop client and started reviewing them.
Inside one of the files I noticed a configuration block:
splitConfiguration:{
core:{
authorizationKey:"KEY",
key:"DUMMY_KEY"
}
}
This looked like a Split.io SDK key.
Split is a feature flag management platform that allows developers to control application features dynamically.
If you have access to the SDK key, you can query the feature flag service.
So I tested their API.
curl -H "Authorization: Bearer KEY" \\
<https://sdk.split.io/api/splitChanges?since=-1>The response returned a large list of feature flag configurations.
The response contained numerous feature flags — some included whitelisted user emails, both internal staff and external customers.
Because the response was huge, I wrote a small script to extract all emails.
The result confirmed that the API response exposed a significant amount of PII.
Duplicate Discovery
I reported the issue, but the security team noted it had already been reported. The same JavaScript file with the SDK key was present in the web application, so it wasn't desktop-specific.
Still, it highlighted how exposed SDK keys can easily lead to unintended data leaks
Thank you for taking the time to read, and I hope it proves beneficial to you.