The current version are Kakao = “2.4.0” and KakaoUserSdk = “2.20.3”.
For example,
Intent intent1 = new Intent().setClassName(“xxx”,“FirstActivity”).putExtra(“url”,“https://ATTACKER.COM”);
Intent intent2 = new Intent().setClassName(“xxx”,“com.kakao.sdk.auth.TalkAuthCodeActivity”).putExtra(“key.login.intent”,intent1);
Intent intent3 = new Intent().setClassName(“xxx”, “SecondActivity”).putExtra(“xxx”, intent2);
startActivity(intent3);
When we start the intent3:
It will be delivered to the SecondActivity
The SecondActivity will start the TalkAuthCodeActivity
The TalkAuthCodeActivity will start the FirstActivity (the screen with user already sign in) leading to account takeover
Is this a known issue,
if yes, how can I set up the environment to prevent it?
if no, would you come up with the solution to solve it?
intent redirection / nested intent abuse is a well-known Android security issue (see CWE-926). If an SDK or your app starts untrusted Intent objects received from outside without validation, it can lead to account takeover or session hijacking.
App-Level Hardening Against Intent Chaining
The attack scenario you describe works because an attacker passes a nested Intent as a Parcelable extra, and your app (via SecondActivity) eventually starts it without sanitization.
A. Reduce Exposure in AndroidManifest
Sensitive activities (like your FirstActivity that shows a signed-in screen) should not be exported (android:exported=“false”).
If SecondActivity must receive external intents:
Keep intent-filter minimal.
Use App Links with HTTPS domain verification — avoid custom schemes where possible.
On Android 12+, explicitly set android:exported to the intended value.
B. Sanitize Incoming Intents
Don’t start incoming intents directly. Use AndroidX’s IntentSanitizer to whitelist only safe fields.
Never allow Intent-typed extras from external sources.
C. Verify Caller Package
If you only expect callbacks from KakaoTalk, use getReferrer(), getCallingPackage(), and PackageManager to whitelist the caller (com.kakao.talk).
D. Lock Down Intent Execution
Use setPackage(…) or explicit component names for targets.
Avoid Intent.createChooser(…) for security-sensitive flows.
Never execute nested Intents from untrusted input.
For PendingIntent, use FLAG_IMMUTABLE and do not hand it to external apps.
