Hello, hunters👾. Most researchers look for critical impact in complex business logic, race conditions, or deep application flows. But high-severity vulnerabilities often hide in places people ignore — a single misconfigured line, a weak regex, an assumption that "this is good enough."

In this case, the root cause wasn't an intricate logic flaw. It was configuration-level trust.

Here is the technical breakdown of the discovery, the bypass, and why I ended up with a name-drop in the official release notes instead of Swag.

The Discovery: /catalogs and the Proxy Trap

While auditing the Happa repository, I came across a specific Nginx configuration in

happa/nginx/nginx.conf

Giant Swarm uses Nginx to proxy requests for Kubernetes Chart indexes.

The goal of the configuration was simple: Only allow proxies to a specific Google APIs URL.

Here was the original, vulnerable code:

location /catalogs {
  root /dev/null;
# The "Security" Check
  if ($arg_url !~* https:\/\/kubernetes-charts\.storage\.googleapis\.com\/index\.yaml) {
    return 404;}
include resolvers.conf;
  proxy_pass $arg_url;
}

The Flaw: The Unanchored Regex

At first glance, it looks like it's enforcing a whitelist. But look closer at the regex operator: !~* . n Nginx, ~* performs a case-insensitive regular expression match. However, the regex provided was unanchored. It didn't use ^ (start of string) or $ (end of string).

This means as long as the whitelisted string

https://kubernetes-charts.storage.googleapis.com/index.yaml

existed anywhere within the $arg_url , the check would pass.

The Exploit: Proving the Bypass (Without Crossing the Line)

To demonstrate the vulnerability, I didn't need to actually exfiltrate their internal data. In professional bug bounty hunting, you prove the capability — the "locked door" is open — without actually "walking into the house."

To bypass the guard, I crafted a URL that pointed to a sensitive internal target while hiding the whitelisted URL in a query parameter. Because the regex was unanchored, Nginx saw the whitelist string anywhere in the input, felt "happy," and proceeded to "proxy_pass" the entire request.

The PoC Payload (Targeting the AWS Metadata IP)

GET /catalogs?url=http://169.254.169.254/latest/meta-data/?bypass=https://kubernetes-charts.storage.googleapis.com/index.yaml HTTP/1.1
Host: <happa-instance-url>

Technical Breakdown: What happened here?

1. Nginx checks $arg_url: It scans the entire url parameter string. It finds the mandatory

2. The Regex matches: Because the configuration lacked anchors (^and$), Nginx confirms the whitelisted string is present. The check passes.

3. Blind Proxying: Nginx executes proxy_pass http://169.254.169.254.... The request is now being fired from inside the Giant Swarm infrastructure toward an internal IP.

4. The Potential Impact: In a standard cloud setup, this is the "Game Over" point. Successfully hitting169.254.169.254 provides a path to leak IAM credentials, instance IDs, and sensitive configurations.

The Ethical Stop: Instead of pulling live credentials, I stopped as soon as the bypass was confirmed. Proving that Nginx would blindly proxy to an unauthorized internal IP was all the evidence Giant Swarm needed to confirm a Critical SSRF.

Impact: Why this was Critical 🫨

1. Cloud Credential Leakage: On AWS/GCP/Azure, hitting the metadata IP is the "Game Over" scenario. Attackers can grab temporary IAM credentials and escalate to full cloud environment takeover.
2. Internal Reconnaissance: The Happa pod acts as a pivot point. I could scan internal Kubernetes APIs or other microservices not exposed to the public internet.

The Remediation

The fix was straightforward: move from an unanchored regex to a strict string equality check.

Recommended Fix:

if ($arg_url != "https://kubernetes-charts.storage.googleapis.com/index.yaml") {
 return 404;
}

Giant Swarm's security team (shout-out to Zach Stone for handling the report) acted quickly and deployed the fix in v1.71.7.

The Bounty "Hustle": Swag vs Recognition.

After the vulnerability was triaged and patched, the team offered a standard swag package — T-shirts, hats, stickers.

Operating from India makes physical rewards inefficient. International shipments frequently stall in customs, tracking often stops at handoff, and import duties can exceed the value of the items themselves. In some cases, charges reach ₹800+ before delivery.

Cost calculation was simple:

Customs fees + delivery uncertainty > promotional merchandise.

I declined the physical package and requested a digital alternative. Due to German tax regulations, issuing cash equivalents or gift cards was not possible.

The final outcome was stronger from a long-term perspective: official public acknowledgment.

My GitHub handle, sumitshah00, was included in the release notes for Happa v1.71.7. Permanent attribution in a production infrastructure tool outweighs temporary merchandise.

Key Takeaway for Hunters & Devs

• For Devs: Never use regex for whitelisting without anchors ( ^ and $).
• For Hunters: Always look at how URLs are validated. Check for "contains" vs "equals". The difference is often a critical bug.

Stay curious. Stay ethical.✌️