Affected: Chrome for iOS versions earlier than 150.0.7871.47 are affected by CVE-2026-13917. Action: Update or require Chrome for iOS 150.0.7871.47 or later, then use current application inventory to verify that managed devices crossed the fixed-version threshold.
Google describes CVE-2026-13917 as an input-validation flaw in Chrome for iOS that allowed a remote attacker to use crafted HTML and specific interface gestures to bypass navigation restrictions. Chromium rates the vulnerability Medium, while CISA-ADP contributed a CVSS v3.1 base score of 6.5. For WindowsForum readers, the most important distinctions are operational: this is an iOS-specific Chrome finding, the visible score is attributed to CISA-ADP rather than NIST, and remediation should be closed with application-version evidence rather than a generic “Chrome updated” status.
Google’s description establishes a narrow but meaningful browser-security failure. Chrome for iOS did not sufficiently validate untrusted input, allowing crafted HTML to bypass navigation restrictions after the user performed specific interface gestures. The affected range is Chrome for iOS earlier than 150.0.7871.47.
The public record does not provide the underlying reproduction steps, the precise gesture sequence, or the internal browser state that was handled incorrectly. It therefore cannot support a detailed account of the exploit mechanics. The defensible conclusion is that attacker-controlled web content could cause Chrome to make a navigation decision that its restrictions were intended to prevent.
That is primarily an integrity problem. The browser is responsible for applying navigation policy consistently, including when a page tries to initiate a transition that depends on user interaction. If crafted content can defeat that policy, the browser may permit an action that should have been rejected.
The record does not establish what destination or subsequent activity would follow a successful bypass. It does not document arbitrary code execution, sandbox escape, file access, credential theft, device takeover, or another downstream outcome. Those possibilities should not be inferred merely because navigation is security-sensitive.
The flaw still deserves prompt remediation. Browser navigation controls help maintain the boundary between what a page requests and what the browser permits. A weakness at that boundary can matter even when its documented impact is narrower than memory corruption or remote code execution.
The contributed vector models a network-reachable vulnerability with low attack complexity, no privileges required, and required user interaction. It records unchanged scope, no confidentiality impact, high integrity impact, and no availability impact.
Those selections define the risk more precisely than the severity word alone. The vulnerability is reachable through remote content and does not require the attacker to begin with an account or existing privileges. Successful exploitation nevertheless depends on user participation, and the modeled direct consequence is a significant change to an integrity-relevant browser decision rather than disclosure or loss of availability.
The absence of assessed confidentiality and availability impact places important limits on reporting. The score does not support a claim that the flaw directly exposes stored data or makes Chrome unavailable. Its central consequence is the alteration of a navigation decision that Chrome should have enforced.
CISA-ADP’s Stakeholder-Specific Vulnerability Categorization data adds a separate decision-support layer:
These values should be preserved as attributed assessments. “Exploitation: none” should not be expanded into a claim that exploitation is impossible, and “automatable: no” should not be used to predict campaign scale or attacker interest. The entries provide context for prioritization, but they do not replace the version test.
Medium means constrained, not irrelevant. The required interaction limits the attack model, while the high integrity component reflects the importance of the navigation decision being bypassed. The appropriate response is prompt version-based remediation without turning the vulnerability record into evidence of a broader compromise.
In browser-security contexts, “input” can include more than text entered into a page. Web content, browser events, state transitions, and user actions may all affect security decisions. That general context helps explain why input validation matters to navigation policy, but it does not reveal the implementation error in this CVE.
The public material does not establish that the flaw involved a particular URL format, frame relationship, gesture type, timing condition, or cross-context state transfer. It also does not identify a vulnerable function, class, browser component, or WebKit behavior. Those details would require technical evidence that is not available in the supplied record.
The Chromium issue-tracking reference requires permission. That establishes that the issue is not publicly readable through the supplied reference; it does not establish why access is restricted or when more information might become available.
As a result, defenders cannot use the issue report to inspect a public proof of concept, patch explanation, affected code path, or reliable reproduction procedure. The missing details should narrow the article’s claims rather than invite a speculative reconstruction.
The practical lesson is straightforward: browser security decisions must validate the conditions under which page-controlled activity is allowed. CVE-2026-13917 shows that a failure in that validation can affect navigation integrity. The fixed-version boundary provides enough information to remediate even though the internal cause remains undisclosed.
This distinction is particularly valuable to Windows-focused administrators. Vulnerability tools and remediation queues may shorten an affected-product record to “Google Chrome,” even when the configuration is platform-specific. That can send an iOS issue into a Windows browser queue or leave it unassigned because no desktop system matches the version.
CVE-2026-13917 does not provide a reason to search Windows workstations for version 150.0.7871.47, apply a desktop Chrome workaround, or create an Edge remediation ticket. The supplied affected configuration identifies Chrome for iOS.
The reverse problem is equally important. A desktop Chrome deployment report cannot demonstrate that Chrome on an iPhone was updated. Likewise, an iOS operating-system version does not establish which Chrome application version is installed. Product, platform, and complete application version must remain associated in the inventory record.
A useful mobile-browser inventory should include:
This is the strongest WindowsForum angle: the underlying vulnerability is not a Windows flaw, but Windows-centered security teams may still receive, triage, and close the ticket. Correct handling means routing the work to the team that can inventory Chrome on managed iPhones while preventing the same rule from being applied to desktop Chrome or Edge.
That requirement limits the supported attack description. The attacker must provide crafted content and persuade the user to interact in the manner required by the vulnerable condition. Google has not publicly specified the exact gesture or sequence in the supplied material, so awareness guidance should avoid presenting examples as confirmed reproduction steps.
General browser-security experience shows why user interaction can become part of a security decision, but that background should remain separate from the CVE facts. Browsers may use user actions when deciding whether to permit sensitive behavior. CVE-2026-13917 establishes only that specific gestures were involved in bypassing navigation restrictions; it does not disclose how Chrome represented or processed those gestures internally.
CISA-ADP’s “automatable: no” value is consistent with an attack requiring participation, but it should be repeated narrowly. It does not establish which parts of a hypothetical campaign could or could not be automated, and it should not be used to estimate victim counts or campaign efficiency.
For response purposes, the interaction requirement supports proportionate treatment. Finding an outdated version establishes exposure to the documented condition, not evidence that the device was attacked. Separate incident analysis becomes appropriate when there is independent evidence, such as a user report of unexpected browser behavior after interacting with an untrusted page.
The supplied record does not include CVE-specific malicious domains, scripts, network signatures, or other indicators. Security teams should not create supposedly precise detections from guessed gesture sequences or assumed delivery methods. Version remediation is the clearest control supported by the available evidence.
For managed environments, the distinction between issuing an update action and proving installation is central. A management platform may report that an application update was assigned, requested, or made available. Those states do not by themselves show that the device now reports Chrome 150.0.7871.47 or later.
The organization should use whatever supported mobile-management capability it already operates to answer three questions:
A device with missing, truncated, stale, or conflicting application data should remain unverified. Unknown status should not silently become compliance, particularly when the affected range depends on the final component of a four-part version.
That division matters when information is copied into scanners, tickets, dashboards, and reports. A score appearing on an NVD page is not automatically an NVD-authored score. In this case, the visible 6.5 value should remain attributed to CISA-ADP.
The same rule applies to reference handling. The supplied record establishes that one Google reference is classified as a vendor advisory and that the Chromium issue reference is classified as issue tracking with permissions required. It does not establish the full contents or title of the vendor-advisory page. Reporting should not infer its packaging, platform focus, or list of included vulnerabilities without reviewing and sourcing the page itself.
CISA-ADP enrichment: CISA-ADP contributed the CVSS v3.1 vector and 6.5 base score, along with SSVC values recording exploitation as none, automatable as no, and technical impact as partial.
NIST/NVD analysis: NIST added normalized affected-product configuration tying the vulnerable Chrome range to Apple’s iPhone operating system and classified the available references.
Later record activity: The supplied history shows subsequent modification activity, but it does not establish that a particular CWE contribution was removed or identify a substantive change to the affected range, score, or SSVC decision points.
Organizational remediation: Users update through the App Store, while administrators inventory Chrome on iOS, identify installations below the fixed boundary, deploy or require the update, and collect current post-action version evidence.
This sequence is more useful than unsupported calendar precision. Exact June and July dates previously attached to record submission, publication, enrichment, and modification should not be repeated without direct verification against the applicable source record.
The operational facts do not depend on those dates. The product is Chrome for iOS, versions earlier than 150.0.7871.47 are affected, and version 150.0.7871.47 establishes the documented remediation boundary.
The restriction itself should not be overinterpreted. It does not prove that Google is following a particular disclosure timetable, waiting for a specific update percentage, or planning to release technical details on a known date. Those explanations would require separate evidence.
The public record also identifies no supported configuration workaround. That makes the corrected version the primary remediation. General advice to be cautious with unexpected web interactions may be sensible defense in depth, but it cannot demonstrate that the vulnerable condition has been removed.
Version evidence is more dependable than exploit speculation:
If a user reports suspicious behavior on an outdated installation, analysts can preserve the available page, link, timing, navigation history, and user description. They should still avoid declaring exploitation based solely on the vulnerable version and an unexpected destination.
Conversely, a quiet device should not be considered remediated while its Chrome version remains below the threshold. Exposure and incident evidence are separate questions. Version inventory answers the first; a fact-based investigation answers the second.
The practical lessons are:
The larger WindowsForum lesson is not that every Chrome advisory belongs in a Windows patch queue. It is that modern browser inventory must preserve product, platform, version, and assessment provenance well enough to send each finding to the right owner. Future browser vulnerabilities will differ in severity, exploitability, and technical impact, but the durable process remains the same: define the exact affected population, deploy the correction, collect current version evidence, and refuse to close the finding on assumptions alone.
Google describes CVE-2026-13917 as an input-validation flaw in Chrome for iOS that allowed a remote attacker to use crafted HTML and specific interface gestures to bypass navigation restrictions. Chromium rates the vulnerability Medium, while CISA-ADP contributed a CVSS v3.1 base score of 6.5. For WindowsForum readers, the most important distinctions are operational: this is an iOS-specific Chrome finding, the visible score is attributed to CISA-ADP rather than NIST, and remediation should be closed with application-version evidence rather than a generic “Chrome updated” status.
A Navigation Bypass Is a Trust Failure, Not Just a Bad Redirect
Google’s description establishes a narrow but meaningful browser-security failure. Chrome for iOS did not sufficiently validate untrusted input, allowing crafted HTML to bypass navigation restrictions after the user performed specific interface gestures. The affected range is Chrome for iOS earlier than 150.0.7871.47.The public record does not provide the underlying reproduction steps, the precise gesture sequence, or the internal browser state that was handled incorrectly. It therefore cannot support a detailed account of the exploit mechanics. The defensible conclusion is that attacker-controlled web content could cause Chrome to make a navigation decision that its restrictions were intended to prevent.
That is primarily an integrity problem. The browser is responsible for applying navigation policy consistently, including when a page tries to initiate a transition that depends on user interaction. If crafted content can defeat that policy, the browser may permit an action that should have been rejected.
The record does not establish what destination or subsequent activity would follow a successful bypass. It does not document arbitrary code execution, sandbox escape, file access, credential theft, device takeover, or another downstream outcome. Those possibilities should not be inferred merely because navigation is security-sensitive.
The flaw still deserves prompt remediation. Browser navigation controls help maintain the boundary between what a page requests and what the browser permits. A weakness at that boundary can matter even when its documented impact is narrower than memory corruption or remote code execution.
The Score Explains the Attack Better Than the Word “Medium”
Chromium rates CVE-2026-13917 Medium, while CISA-ADP assigned a CVSS v3.1 base score of 6.5. NVD did not provide its own CVSS 4.0, 3.x, or 2.0 assessment in the supplied record, so internal reports should identify 6.5 as a CISA-ADP contribution rather than calling it “the NVD score.”The contributed vector models a network-reachable vulnerability with low attack complexity, no privileges required, and required user interaction. It records unchanged scope, no confidentiality impact, high integrity impact, and no availability impact.
Those selections define the risk more precisely than the severity word alone. The vulnerability is reachable through remote content and does not require the attacker to begin with an account or existing privileges. Successful exploitation nevertheless depends on user participation, and the modeled direct consequence is a significant change to an integrity-relevant browser decision rather than disclosure or loss of availability.
The absence of assessed confidentiality and availability impact places important limits on reporting. The score does not support a claim that the flaw directly exposes stored data or makes Chrome unavailable. Its central consequence is the alteration of a navigation decision that Chrome should have enforced.
CISA-ADP’s Stakeholder-Specific Vulnerability Categorization data adds a separate decision-support layer:
| SSVC field | Recorded value | Careful operational reading |
|---|---|---|
| Exploitation | None | The supplied assessment records no exploitation at that point; it is not a permanent prediction |
| Automatable | No | The assessment does not treat the attack as automatable from start to finish |
| Technical impact | Partial | The documented result compromises part of the browser’s security function rather than establishing unrestricted control |
Medium means constrained, not irrelevant. The required interaction limits the attack model, while the high integrity component reflects the importance of the navigation decision being bypassed. The appropriate response is prompt version-based remediation without turning the vulnerability record into evidence of a broader compromise.
Improper Input Validation Is Broader Than a Form-Field Error
Chrome associates CVE-2026-13917 with CWE-20, Improper Input Validation. At a general level, this category describes software using input without adequately confirming that it is valid for the operation being performed.In browser-security contexts, “input” can include more than text entered into a page. Web content, browser events, state transitions, and user actions may all affect security decisions. That general context helps explain why input validation matters to navigation policy, but it does not reveal the implementation error in this CVE.
The public material does not establish that the flaw involved a particular URL format, frame relationship, gesture type, timing condition, or cross-context state transfer. It also does not identify a vulnerable function, class, browser component, or WebKit behavior. Those details would require technical evidence that is not available in the supplied record.
The Chromium issue-tracking reference requires permission. That establishes that the issue is not publicly readable through the supplied reference; it does not establish why access is restricted or when more information might become available.
As a result, defenders cannot use the issue report to inspect a public proof of concept, patch explanation, affected code path, or reliable reproduction procedure. The missing details should narrow the article’s claims rather than invite a speculative reconstruction.
The practical lesson is straightforward: browser security decisions must validate the conditions under which page-controlled activity is allowed. CVE-2026-13917 shows that a failure in that validation can affect navigation integrity. The fixed-version boundary provides enough information to remediate even though the internal cause remains undisclosed.
The Platform Boundary Is Narrow—and Operationally Important
NVD’s affected configuration associates Google Chrome versions earlier than 150.0.7871.47 with Apple’s iPhone operating system. That makes platform identification essential. The product name “Google Chrome” by itself is not sufficiently precise for vulnerability routing.| Deployment state | Chrome for iOS version | CVE status | Required treatment |
|---|---|---|---|
| Vulnerable | Earlier than 150.0.7871.47 | Within the affected range | Update and retain current version evidence |
| Fixed boundary | 150.0.7871.47 | Outside the documented affected range | Record as compliant when installation is verified |
| Later release | Later than 150.0.7871.47 | Outside the documented affected range | Retain and monitor through normal inventory |
| Version unavailable or stale | Unknown | Compliance cannot be established | Keep open until current evidence is obtained |
| Chrome not installed on the iPhone | Not applicable | No installation-level exposure to this CVE | Record the product absence separately |
CVE-2026-13917 does not provide a reason to search Windows workstations for version 150.0.7871.47, apply a desktop Chrome workaround, or create an Edge remediation ticket. The supplied affected configuration identifies Chrome for iOS.
The reverse problem is equally important. A desktop Chrome deployment report cannot demonstrate that Chrome on an iPhone was updated. Likewise, an iOS operating-system version does not establish which Chrome application version is installed. Product, platform, and complete application version must remain associated in the inventory record.
A useful mobile-browser inventory should include:
- Device or asset identity
- Product name
- Operating platform
- Complete installed application version
- Device ownership or management state
- Time of the most recent inventory result
- Remediation status
- Exception owner and review date, where applicable
This is the strongest WindowsForum angle: the underlying vulnerability is not a Windows flaw, but Windows-centered security teams may still receive, triage, and close the ticket. Correct handling means routing the work to the team that can inventory Chrome on managed iPhones while preventing the same rule from being applied to desktop Chrome or Edge.
The User-Interaction Requirement Shapes the Attack Model
The disclosure says exploitation involves specific interface gestures. It does not say merely loading the crafted page is sufficient.That requirement limits the supported attack description. The attacker must provide crafted content and persuade the user to interact in the manner required by the vulnerable condition. Google has not publicly specified the exact gesture or sequence in the supplied material, so awareness guidance should avoid presenting examples as confirmed reproduction steps.
General browser-security experience shows why user interaction can become part of a security decision, but that background should remain separate from the CVE facts. Browsers may use user actions when deciding whether to permit sensitive behavior. CVE-2026-13917 establishes only that specific gestures were involved in bypassing navigation restrictions; it does not disclose how Chrome represented or processed those gestures internally.
CISA-ADP’s “automatable: no” value is consistent with an attack requiring participation, but it should be repeated narrowly. It does not establish which parts of a hypothetical campaign could or could not be automated, and it should not be used to estimate victim counts or campaign efficiency.
For response purposes, the interaction requirement supports proportionate treatment. Finding an outdated version establishes exposure to the documented condition, not evidence that the device was attacked. Separate incident analysis becomes appropriate when there is independent evidence, such as a user report of unexpected browser behavior after interacting with an untrusted page.
The supplied record does not include CVE-specific malicious domains, scripts, network signatures, or other indicators. Security teams should not create supposedly precise detections from guessed gesture sequences or assumed delivery methods. Version remediation is the clearest control supported by the available evidence.
Mobile Browser Patching Is an Inventory Problem
For an individual user, the immediate procedure is short:- Open the App Store on the iPhone.
- Search for Google Chrome.
- Tap Update if the option is available.
- Reopen Chrome after the update completes.
For managed environments, the distinction between issuing an update action and proving installation is central. A management platform may report that an application update was assigned, requested, or made available. Those states do not by themselves show that the device now reports Chrome 150.0.7871.47 or later.
The organization should use whatever supported mobile-management capability it already operates to answer three questions:
- Which managed iPhones have Google Chrome installed?
- What complete Chrome version does each reporting device currently show?
- Which installations remain below 150.0.7871.47 or lack trustworthy current data?
A device with missing, truncated, stale, or conflicting application data should remain unverified. Unknown status should not silently become compliance, particularly when the affected range depends on the final component of a four-part version.
Action checklist for admins
- Inventory Google Chrome specifically on managed iPhones.
- Keep the iOS platform condition attached to the CVE rule.
- Collect the complete installed Chrome version, including all four numeric components.
- Identify every installation earlier than 150.0.7871.47.
- Use the organization’s normal managed-application process to require or deploy an eligible current release.
- Re-query application inventory after the update action.
- Treat assignment, notification, or update-request status as activity—not installation evidence.
- Keep devices with missing or stale version data open for follow-up.
- Test version-comparison logic against values immediately below, equal to, and above 150.0.7871.47.
- Route remediation to the team responsible for managed iOS applications rather than a Windows desktop-browser queue.
- Keep Chrome on Windows, Chrome on Android, Edge, Safari, and unrelated products outside this CVE’s remediation scope unless separate vendor evidence applies.
- Preserve the CISA-ADP attribution when recording the 6.5 CVSS v3.1 score.
- Document unresolved devices through the organization’s normal exception process.
- Close the finding only when current inventory shows 150.0.7871.47 or later, Chrome is confirmed absent, or an approved exception remains under management.
The Disclosure Record Shows Why Score Provenance Matters
CVE records may display material supplied by several organizations on one page. For CVE-2026-13917, Chrome supplied the central vulnerability description, weakness association, affected-version information, and references. CISA-ADP supplied the visible CVSS v3.1 assessment and SSVC values. NIST’s NVD analysis supplied normalized affected-configuration and reference-classification information.That division matters when information is copied into scanners, tickets, dashboards, and reports. A score appearing on an NVD page is not automatically an NVD-authored score. In this case, the visible 6.5 value should remain attributed to CISA-ADP.
The same rule applies to reference handling. The supplied record establishes that one Google reference is classified as a vendor advisory and that the Chromium issue reference is classified as issue tracking with permissions required. It does not establish the full contents or title of the vendor-advisory page. Reporting should not infer its packaging, platform focus, or list of included vulnerabilities without reviewing and sourcing the page itself.
Timeline of record development
Chrome-originated CVE information: Chrome supplied the core description, identifying insufficient validation of untrusted input, crafted HTML, required interface gestures, a navigation-restriction bypass, and the affected boundary before 150.0.7871.47.CISA-ADP enrichment: CISA-ADP contributed the CVSS v3.1 vector and 6.5 base score, along with SSVC values recording exploitation as none, automatable as no, and technical impact as partial.
NIST/NVD analysis: NIST added normalized affected-product configuration tying the vulnerable Chrome range to Apple’s iPhone operating system and classified the available references.
Later record activity: The supplied history shows subsequent modification activity, but it does not establish that a particular CWE contribution was removed or identify a substantive change to the affected range, score, or SSVC decision points.
Organizational remediation: Users update through the App Store, while administrators inventory Chrome on iOS, identify installations below the fixed boundary, deploy or require the update, and collect current post-action version evidence.
This sequence is more useful than unsupported calendar precision. Exact June and July dates previously attached to record submission, publication, enrichment, and modification should not be repeated without direct verification against the applicable source record.
The operational facts do not depend on those dates. The product is Chrome for iOS, versions earlier than 150.0.7871.47 are affected, and version 150.0.7871.47 establishes the documented remediation boundary.
A Restricted Bug Report Forces Defenders to Resist Guesswork
The permission-required Chromium issue leaves important details unavailable. Defenders cannot use the supplied reference to determine the vulnerable code path, exact trigger, gesture sequence, patch mechanics, exploit reliability, or a CVE-specific network signature.The restriction itself should not be overinterpreted. It does not prove that Google is following a particular disclosure timetable, waiting for a specific update percentage, or planning to release technical details on a known date. Those explanations would require separate evidence.
The public record also identifies no supported configuration workaround. That makes the corrected version the primary remediation. General advice to be cautious with unexpected web interactions may be sensible defense in depth, but it cannot demonstrate that the vulnerable condition has been removed.
Version evidence is more dependable than exploit speculation:
| Evidence | What it establishes |
|---|---|
| Chrome for iOS earlier than 150.0.7871.47 | The installation remains within the documented affected range |
| Chrome for iOS 150.0.7871.47 or later in current inventory | The installation has crossed the documented fixed boundary |
| Update assigned or offered | An administrative or store action occurred, but installation is not yet proven |
| iOS updated | The operating system changed; the Chrome application version remains a separate fact |
| Desktop Chrome updated | No conclusion about Chrome on the iPhone |
| Unexpected navigation reported | A browser event requires investigation, but it does not prove CVE exploitation |
| No alert generated | No conclusion about whether the navigation bypass occurred |
Conversely, a quiet device should not be considered remediated while its Chrome version remains below the threshold. Exposure and incident evidence are separate questions. Version inventory answers the first; a fact-based investigation answers the second.
Chrome’s Medium Fix Carries Five Concrete Lessons
CVE-2026-13917 is useful because it can be scoped precisely. It is a mobile Chrome vulnerability with a clear version boundary, an interaction-dependent navigation-policy impact, and attributed assessment data that should not be confused with an independent NIST score.The practical lessons are:
- Platform must remain part of the vulnerability rule. “Google Chrome” is too broad when the affected configuration is Chrome on iOS.
- Complete version evidence is the closure test. An update action or generic compliance status does not replace a current result showing 150.0.7871.47 or later.
- Assessment provenance matters. The 6.5 CVSS v3.1 score and SSVC values come from CISA-ADP, while NVD presents those contributions alongside its configuration analysis.
- Restricted technical details are not permission to speculate. The record supports a navigation-restriction bypass through crafted HTML and specific gestures, not an invented exploit sequence or downstream compromise.
- Windows teams should route rather than misapply the finding. The ticket may arrive in a Windows-centered security workflow, but the remediation target is Chrome on managed iPhones.
The larger WindowsForum lesson is not that every Chrome advisory belongs in a Windows patch queue. It is that modern browser inventory must preserve product, platform, version, and assessment provenance well enough to send each finding to the right owner. Future browser vulnerabilities will differ in severity, exploitability, and technical impact, but the durable process remains the same: define the exact affected population, deploy the correction, collect current version evidence, and refuse to close the finding on assumptions alone.
References
- Primary source: NVD / Chromium
Published: 2026-07-11T15:40:28-07:00
Loading…
nvd.nist.gov - Security advisory: MSRC
Published: 2026-07-11T15:40:28-07:00
Original feed URL
Loading…
msrc.microsoft.com - Related coverage: chromereleases.googleblog.com
Chrome Releases: Chrome Stable for iOS Update
Hi everyone! We've just released Chrome Stable 150 (150.0.7871.34) for iOS; it'll become available on App Store in the next few hours. This ...chromereleases.googleblog.com
- Related coverage: cvepremium.circl.lu
Loading…
cvepremium.circl.lu