How a Single JWT ‘iss’ Field Leaked an Entire Kubernetes Internal Network – And Why You’re Probably Ignoring It

By /

Listen to this Post

Featured Image

Introduction:

JSON Web Tokens (JWTs) are ubiquitous in modern APIs, but their claims – especially “iss” (issuer) – often reveal more than intended. In a recent healthcare patient portal test, a researcher found that the JWT’s “iss” field exposed an internal Kubernetes service URL (http://keycloak--http.keycloak.svc:8180), leaking the auth server’s internal hostname, namespace, and port directly to a public browser. This seemingly minor info leak becomes a powerful reconnaissance tool for attackers, enabling SSRF mapping, internal realm enumeration, and WAF bypass.

Learning Objectives:

  • Identify dangerous JWT claims (iss, aud, kid, alg) that leak internal infrastructure.
  • Transform leaked internal URLs into SSRF attack surfaces and internal network maps.
  • Exploit misconfigured JWT issuer validation to bypass external security controls.

You Should Know:

1. Decoding JWTs and Spotting Internal URL Leaks

Every intercepted JWT should be decoded – even in mobile apps or “simple” portals. The “iss” (issuer) claim tells the client where the token was generated. If it contains an internal hostname (like .svc, .cluster.local, or raw IP:port), an attacker now knows your auth architecture.

Step‑by‑Step Guide:

  • Intercept an API call (using Burp Suite or OWASP ZAP) that includes an `Authorization: Bearer ` header.
  • Copy the JWT (three base64 strings separated by dots).
  • Decode it manually on Linux: 
    Split the token and decode the payload (second segment)
echo "<JWT_TOKEN>" | cut -d '.' -f2 | base64 -d 2>/dev/null | jq .
  • On Windows (PowerShell): 
    $token = "<JWT_TOKEN>"
$payload = $token.Split('.')[bash]
  • Look for iss, `aud` (audience), `kid` (key ID), and `jku` (JWK set URL). Any internal reference (e.g., http://keycloak.default.svc:8080`,https://10.0.0.1:8443`) is a leak.

What this does: Reveals the authentication server’s internal network location, Kubernetes namespace, and port. Screenshot the decoded token alongside the request/response as proof.

2. Mapping SSRF Attack Vectors from Leaked URLs

Once you have an internal URL like http://keycloak-<app>-http.keycloak.svc:8180, you can pivot to Server‑Side Request Forgery (SSRF). Find any feature that accepts a URL (webhooks, profile images, import functions) and test if the server can be tricked into calling that internal endpoint.

Step‑by‑Step Guide:

  • Identify parameters that accept URLs (e.g., ?callbackUrl=, webhook=, imageUrl=).
  • Attempt a simple SSRF probe: replace the value with your leaked internal URL.
  • If the application makes the request, observe the response. A timeout, different error, or status code indicates successful internal access.
  • Enumerate Keycloak realms: append `/realms/` to the internal URL (e.g., `http://keycloak.keycloak.svc:8180/realms/master`).
  • Use Burp’s Collaborator or `curl` to confirm out‑of‑band SSRF: 
    curl -v "https://target.com/api/fetch?url=http://keycloak.keycloak.svc:8180/realms/demo"
  • If SSRF works, map internal services by trying common ports (8080, 8443, 9090) and known K8s API endpoints (`https://kubernetes.default.svc`).

Why it works: The external WAF sees only the public domain, but the backend server can resolve internal hostnames. Leaking the `iss` URL gives you a ready‑made target for SSRF.

  1. Exploiting Weak JWT Algorithms (alg: none, HS256 with leaked key)
    Exposed internal URLs sometimes correlate with other JWT misconfigurations. If the `alg` claim is `none` or `HS256` while the token is signed with an RSA key, you may perform algorithm confusion attacks.

Step‑by‑Step Guide:

  • Use `jwt_tool` (https://github.com/ticarpi/jwt_tool) to test for common flaws: 
    python3 jwt_tool.py <JWT_TOKEN> -X a  Check for alg: none
python3 jwt_tool.py <JWT_TOKEN> -X k  Key confusion (RS256 to HS256)
  • For HS256 (symmetric), if you can guess or leak the secret (e.g., from exposed internal configs), forge tokens: 
    import jwt
forged = jwt.encode({"user": "admin", "iss": "http://keycloak.keycloak.svc:8180"}, "secret", algorithm="HS256")
  • Test the forged token against the API – if accepted, you have privilege escalation.

Real‑world impact: Many internal auth servers use weak default secrets. The leaked `iss` URL may point to a development Keycloak instance where keycloak/keycloak credentials are still active.

4. Hardening Keycloak and Kubernetes Deployments

To prevent this leak, never expose internal service URLs in public‑facing tokens. Override the issuer URL in your identity provider configuration.

Step‑by‑Step Guide for Mitigation:

  • In Keycloak, set the Frontend URL and Backend URL under Realm Settings → General.
  • Ensure the `iss` claim uses a public, HTTPS domain (e.g., `https://auth.yourdomain.com/realms/prod`).
  • For Kubernetes, use an Ingress or LoadBalancer with external DNS – never reference `.svc.cluster.local` in public responses.
  • Implement network policies to restrict SSRF: 
    apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: deny-internal-egress
spec:
podSelector: {}
policyTypes:</li>
<li>Egress
egress:</li>
<li>to:</li>
<li>ipBlock:
cidr: 0.0.0.0/0
except:</li>
<li>10.0.0.0/8  Block internal ranges
  • Use `jq` to audit existing tokens: 
    echo $TOKEN | cut -d '.' -f2 | base64 -d | jq '.iss | test("svc|cluster.local|10\.")'

Validation: After changes, re‑capture a JWT and verify the `iss` field no longer contains internal addressing.

5. Automated Recon Script for JWT Analysis

Manually checking every JWT is tedious. Automate the extraction and flagging of internal URLs.

Step‑by‑Step Guide:

  • Save this bash script as jwt_recon.sh: 
    !/bin/bash
Extract JWTs from HTTP logs or Burp export
grep -oP 'Bearer [A-Za-z0-9-<em>=]+.[A-Za-z0-9-</em>=]+.[A-Za-z0-9-_=]+' "$1" | while read -r token; do
payload=$(echo "$token" | cut -d '.' -f2 | base64 -d 2>/dev/null)
if echo "$payload" | jq -e '.iss | test("http://|https://.svc|10\\.|172\\.|192\\.168")' >/dev/null; then
echo "[!] LEAK: $token"
echo "$payload" | jq '.iss, .aud'
fi
done
  • Run it: `./jwt_recon.sh burp_export.txt`
    – For Windows, use PowerShell with regex and ConvertFrom-Json.

What it does: Automatically highlights any JWT whose issuer or audience contains internal hostnames, IP ranges, or Kubernetes service suffixes.

6. Reporting and Getting Paid for Such Findings

This type of infrastructure leak is often rewarded in bug bounty programs because it can lead to full internal compromise. Document it professionally.

Step‑by‑Step Report Structure:

  • JWT issuer leak exposes internal Keycloak URL, enabling SSRF and realm enumeration.
  • Steps to Reproduce: Intercept login API response (or request) → Decode JWT → Observe `iss` field.
  • Impact: Attackers can map internal network, attempt SSRF to the auth server, enumerate realms, and potentially bypass WAF.
  • Proof: Annotated screenshot of Burp showing the decoded token with the internal URL.
  • Remediation: Configure Keycloak to use public HTTPS issuer URL; apply network policies to block egress to internal ranges.

Resources to Learn More:

What Undercode Say:

  • Key Takeaway 1: Always decode JWTs from any application – even mobile or “simple” portals. An internal URL in the `iss` claim is a direct infrastructure leak that most testers ignore.
  • Key Takeaway 2: Combine JWT recon with SSRF testing. One leaked auth server URL can escalate from an info leak to a full internal network compromise if the backend is vulnerable to server‑side requests.

Analysis: The healthcare portal case shows how cloud‑native architectures inadvertently leak internal service discovery information. Developers often forget that JWT claims are visible to clients; they set the issuer to the internal Keycloak service name for functional reasons, not realizing an attacker can read it. This becomes a force multiplier for recon – the attacker learns the exact auth endpoint, Kubernetes namespace, and port. Combined with SSRF (common in webhooks or file fetchers), they can probe the internal Keycloak API, list realms, and even attempt to reset passwords or obtain tokens for other applications. The root cause is a missing “issuer override” for public endpoints. Mitigations are simple but frequently overlooked, making this a high‑value, low‑effort finding.

Expected Output:

  • A comprehensive understanding of how JWT claims leak internal infrastructure.
  • Step‑by‑step commands to decode JWTs, test SSRF, and exploit algorithm weaknesses.
  • Actionable hardening guidance for Keycloak and Kubernetes deployments.
  • Automated recon scripts and professional reporting templates to get paid for such findings.

Prediction:

+1 Increased integration of JWT scanning into automated recon tools (e.g., Nuclei templates, Burp extensions) as bug hunters recognize the value of `iss` field analysis.
-1 More internal service exposures will occur as organizations adopt service meshes and sidecar proxies without auditing public‑facing tokens, leading to a rise in SSRF‑to‑cluster attacks.
+1 The OWASP JWT Cheat Sheet will see a surge in updates regarding “infrastructure leakage” as a new vulnerability class, influencing API security standards.

🎯Let’s Practice For Free:

🎓 Live Courses & Certifications:

Join Undercode Academy for Verified Certifications

🚀 Request a Custom Project:

Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands

IT/Security Reporter URL:

Reported By: Riya Nair – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅

🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]

💬 Whatsapp | 💬 Telegram

📢 Follow UndercodeTesting & Stay Tuned:

𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin | 🦋BlueSky

Related Posts: