Google Chrome is one of the most popular browsers worldwide—with security patched constantly. But sometimes, even low-severity bugs can unlock surprising doors. CVE-2022-3317 is one of those: it affected Chrome for Android before version 106..5249.62, letting a remote attacker bypass Chrome's navigation intent restrictions using a specially crafted web page.

In this long read, I'll walk you through what CVE-2022-3317 was, show you some code, explain how the exploit worked, and provide links for your own research.

What Was the Bug?

CVE-2022-3317 was about insufficient validation of untrusted input in Intents. When Chrome encounters links or web content that want to open another app via an Intent (an Android system message for jumping between apps), it needs to make sure the request is “safe” and not tricking the user.

But before Chrome 106..5249.62, it didn’t always validate these requests enough. A malicious webpage could send a special intent that bypassed Chrome’s navigation restrictions, potentially taking users to unexpected places or even launching apps in unintended ways.

The official bug summary

> Insufficient validation of untrusted input in Intents in Google Chrome on Android prior to 106..5249.62 allowed a remote attacker to bypass navigation restrictions via a crafted HTML page. (Chromium security severity: Low)

References

- Chrome Release Notes - Stable Channel Update for Android
- Chromium Issue Tracker 1359813
- NVD CVE-2022-3317

What Are Intents in Android?

Intents are how Android sends messages between apps. It’s like when you click “Share” or a website opens your Maps app. For security, browsers like Chrome try to control which intents a web page can trigger, so you don’t get hijacked by a malicious site.

A malicious web page creates a special link or JavaScript payload.

2. This payload tries to open a crafted Intent URL, pointing to something outside of what Chrome would usually allow.
3. Due to insufficient checks, Chrome before 106..5249.62 could be tricked into sending the intent through, defeating its own restrictions.

Example of a Crafted Intent

Suppose an attacker wants to open a banking app or launch a callback in an external app. They can prepare an HTML file like this:

<!-- crafted_intent.html -->
<a href="intent://example.com#Intent;scheme=example;package=com.example.bankapp;end">
  Open Bank App
</a>

Or, to trigger it via JavaScript

window.location = "intent://malicious-content/#Intent;scheme=example;package=com.potentially.dangerous.app;S.browser_fallback_url=https://bad-actor.com;end";;

The “intent://” URL scheme is Android’s way of passing Intents from browsers.

Before the fix: Chrome didn’t properly vet whether it should allow this navigation, so if a user tapped the above link or a script set window.location, Chrome might open the target app or follow the fallback URL.

Step-by-Step Attack Scenario

Let’s say a victim visits an attacker-controlled website on Chrome for Android (version < 106..5249.62):

Because of the validation bug, Chrome bypasses its normal navigation protections.

5. The intent is handed off to Android, possibly opening a different app or triggering an action the user didn’t anticipate (app link, custom protocol, etc).
6. This could be used for phishing, spamming with app launch intents, or attempting to escalate to more serious attacks if another vulnerable app is targeted.

Let’s say an attacker wants to force-launch a vulnerable app with a particular payload

<a href="intent://evil/#Intent;scheme=evil;package=com.vulnerable.app;S.some_data=bad_data;end">
  Do something
</a>

Users who click this link (or if a script triggers a redirect to it) will have com.vulnerable.app launched, possibly with parameters set (some_data=bad_data). It could even include a fallback, so if the app isn’t installed, the browser_fallback_url is loaded, maybe a phishing page.

<a href="intent://evil/#Intent;scheme=evil;package=com.vulnerable.app;S.fake=payload;S.browser_fallback_url=https://phishing-site.com;end">;
  Try to launch app
</a>

The Fixed Code (What Changed?)

The Chromium team improved intent filtering and validation in this commit, meaning Chrome doesn’t just accept an intent URL from any page—it checks the source, the destination, and validates navigation rules.

If you want details, see the issue

- Chromium Tracker 1359813 (May require a Chromium log-in)

Is This Vulnerability Serious?

Severity: Low (per Google’s security rating systems)

It’s a bypass of navigation rules, not a total browser or system compromise.

- Could be used for phishing, abusing app-linking, or launching splashy but not outright devastating attacks.

How to Stay Safe?

- Always update Chrome and your other browsers. This was fixed in Chrome 106 (released September 2022).

Resources and References

- Official Chrome Security Release Notes
- Full NVD Entry
- Crbug Issue 1359813
- Android Intents Documentation

Conclusion

CVE-2022-3317 reminds us that even small holes—like a check missed when handing off Intents—can make a door for clever attackers. While this wasn’t the most severe bug, it could still be the first step in bigger attacks. Always keep browsers and all your apps updated so these little holes don’t stack into bigger ones.

If you want to try reproducing holistically, set up a test Android device and run a Chrome version below 106..5249.62—then visit a custom HTML exploiting “intent://” URLs like the snippets above.

Timeline

Published on: 11/01/2022 20:15:00 UTC
Last modified on: 08/08/2023 14:22:00 UTC