Flapjack, an experimental security project, has identified the following potential security issue. If you’re a feature owner CC-ed on this bug, please do your best to review these reports without the Chrome Security team. Please see https://chromium.googlesource.com/chromium/src/+/main/docs/security/ai-generated-security-bugs-faq.md for more information.

Overview: The Lens SDK integration in Chrome for iOS fails to validate URL schemes extracted from scanned images (e.g., QR codes). The extracted URL is forwarded verbatim to the Chrome navigation stack. Because navigations from internal UI components are typically treated as trusted, this missing validation could allow an attacker to trigger Universal XSS (UXSS) or navigate to privileged internal pages using malicious javascript: or chrome: URLs.

Affected files:

• google_internal/Source/Lens/UrlOpenerProvider/GCRLensURLOpener.m
• google_internal/Source/Lens/GCRLensController.m

Estimated timestamp from git blame: Unknown (Google3 checkout)

Description

There is a potential vulnerability in the integration between the Google Lens SDK and Chrome for iOS (Bling) where extracted URLs are not validated before being passed to the browser’s navigation stack.

When a user scans an image or QR code using the Lens feature, the Lens SDK extracts any embedded URLs and calls the registered LNSUrlOpener provider to open them. In Chrome for iOS, this provider is implemented by GCRLensURLOpener.

The implementation in google_internal/Source/Lens/UrlOpenerProvider/GCRLensURLOpener.m receives the NSURL and forwards it directly to its delegate:

- (void)openUrl:(NSURL* _Nonnull)URL initiatedBy:(UIViewController* _Nullable)initiatedBy {
  [_delegate onLensOpenURLRequested:URL];
}

The delegate, GCRLensController (implemented in google_internal/Source/Lens/GCRLensController.m), subsequently forwards this request to the main open-source Chromium codebase:

- (void)onLensOpenURLRequested:(NSURL *_Nonnull)url {
  [_delegate lensController:self didSelectURL:url];
  // ...
}

At no point in this flow is the NSURL’s scheme validated or sanitized. Because the navigation request originates from a first-party, internal UI component (Lens), the main Chrome navigation stack (e.g., UrlLoadingBrowserAgent) is highly likely to treat the navigation as “browser-initiated” or trusted. This bypasses the strict security filters usually applied to untrusted web content.

Potential Attack Steps

Note: These are potential steps based on static analysis; our tooling agent does not yet have the ability to run code to confirm the exploit chain end-to-end.

1. Payload Creation: An attacker crafts a malicious QR code containing a dangerous URL scheme, such as javascript:alert(document.domain) or a privileged internal URL like chrome://settings.
2. Victim Interaction: The attacker tricks a victim into scanning the QR code using the Chrome Lens integration on iOS (e.g., via the camera icon in the Omnibox or the “Search Image with Google” context menu).
3. Extraction and Forwarding: The Lens SDK decodes the QR code and extracts the malicious URL. It passes the unvalidated URL through GCRLensURLOpener and GCRLensController to the browser’s navigation delegate.
4. Exploitation: The browser processes the trusted navigation request. If a javascript: URL is provided, it may execute arbitrary JavaScript in the context of the currently active WebState, resulting in Universal Cross-Site Scripting (UXSS). If a chrome: URL is provided, it may navigate to a sensitive internal page.

Suggested Fix

To prevent this issue, URL scheme validation should be implemented before forwarding the URL to the navigation stack.

The fix should ideally be applied in GCRLensURLOpener.m or GCRLensController.m. The implementation should:

1. Inspect the scheme property of the NSURL.
2. Strictly allow only safe schemes (e.g., http and https).
3. Explicitly drop or sanitize dangerous schemes such as javascript, chrome, file, and data.

Evaluated with Chrome root at commit: HEAD (Google3)

Results so far have been promising, but there can be wrong deductions. If this proves to be a false positive, please close as WAI; data from false positives will be used to improve accuracy over time. And please feel free to reach out to me directly if you have concerns or feedback on the project.