I Was Just Checking an API Endpoint… Then I Found Its Internal Metrics 👀 Telekom Hall Of Fame

Last night, I was doing some routine reconnaissance on a Telekom IoT API.

Nothing fancy.

No brute force. No payloads. No complicated exploit chain.

Just looking at what the application was exposing.

I started with the usual mindset:

"What does this application reveal before I even authenticate?"

It all started with Recon -Can you believe it?

1️⃣ Find All Domains & Subdomains amass enum -passive -d target.com -o subdomains.txt

2️⃣ Resolve Live Subdomains cat subdomains.txt | httpx -silent -mc 200,403,401 -o live_subdomains.txt

3️⃣Using Nuclei, which is my Best Friend [Blossom Tool] nuclei -l live_subdomains.txt

And then I found something interesting.

An endpoint that probably wasn't meant for public users:

/metrics

And it wasn't empty.

It was exposing Prometheus monitoring data directly to the internet.

But that wasn't the end.

A second endpoint caught my attention:

/debug/vars

This one exposed application debugging information as well.

That's when the finding became more interesting.

The Finding

The Telekom IoT API exposed two operational endpoints without authentication:

1️⃣ `/metrics`

A publicly accessible Prometheus metrics endpoint.

2️⃣ `/debug/vars`

A publicly accessible debugging/diagnostic endpoint.

These endpoints are generally intended for internal monitoring, troubleshooting, or development/operations purposes, not unrestricted public access.

How It Started -Recon

As always, I started with basic reconnaissance.

Nothing complicated.

The first thing I wanted to understand was:

"What is this API exposing?"

I accessed the publicly available API host:

https://sample.com/

The application was reachable.

So I started checking commonly exposed operational endpoints.

One of the first things that came to mind was:

What about Prometheus?

I tried:

/metrics

And…

Bingo.

The endpoint was accessible without authentication.

Finding #1 -Public Prometheus Metrics

The endpoint:

https://sample.telekom.com/metrics

returned Prometheus-formatted monitoring information.

This immediately caught my attention because metrics endpoints can sometimes reveal much more than developers expect.

Depending on the application's instrumentation, exposed metrics can provide information about:

Application behavior
Internal service names
Request statistics
Error rates
Runtime information
Process statistics
Memory and resource usage
Technology/framework information
Internal operational details

Finding #2 -`/debug/vars` Information Disclosure

The /debug/vars endpoint exposed application diagnostic information.

Again, the issue wasn't that debugging information exists.

Developers need debugging information.

The problem is where it is exposed and who can access it.

A production application shouldn't unnecessarily expose internal diagnostic information to unauthenticated internet users.

Two Endpoints. One Configuration Problem.

At this point, the finding became much clearer.

I wasn't looking at two completely unrelated bugs.

I was looking at a broader security problem:

Operational and debugging interfaces were exposed to the public internet without appropriate access controls.

The application was effectively exposing information intended for internal monitoring and troubleshooting.

The Interesting Part

This wasn't an SQL Injection.

It wasn't an RCE.

It wasn't an authentication bypass.

It wasn't an IDOR.

There was no fancy payload.

It was simply:

"What happens if I request an endpoint that developers normally use internally?"

And that question uncovered something interesting.

What I Did Next (The Ethical Way)

Instead of abusing the access or ignoring the issue, I:

Responsible disclosed the vulnerability to the application's security team.
Clearly demonstrated how this allowed access to Metrics and Other Data.
Worked with the team to validate the impact, ensuring the issue was patched and proper access controls were enforced.

I Was Just Checking an API Endpoint… Then I Found Its Internal Metrics 👀 Telekom Hall Of Fame

Contents