CVE-2026-13991: Update Chrome for iOS to 150.0.7871.47

Google fixed CVE-2026-13991, a medium-severity Chrome for iOS input-validation flaw affecting versions before 150.0.7871.47. According to the supplied NVD record, a remote attacker can use a crafted HTML page to produce UI spoofing after user interaction. The record does not describe browser takeover, code execution, a sandbox escape, or complete compromise of an iPhone. It documents a narrower failure in which untrusted web content can present misleading interface information.
The immediate response is straightforward: update Chrome on affected iPhones and verify that the installed application is version 150.0.7871.47 or later. The supplied SSVC assessment records exploitation as none, but that point-in-time value should not be expanded into a claim that no public exploit or active campaign existed.

What to do now​

Affected product: Google Chrome on iOS
Affected versions: Earlier than 150.0.7871.47
Documented mechanism: Crafted HTML leading to UI spoofing with user interaction
Exploitation status: No exploitation was recorded in the supplied SSVC assessment
User action: Open App Store > profile picture/account icon > Available Updates > Chrome > Update
Enterprise action: Inventory the Chrome application and complete version, require 150.0.7871.47 or later, deploy or require the update through the supported managed-app process, and re-query the installed version
Verification: If the current Chrome for iOS interface does not provide a verified version path, use the organization’s MDM or managed-application inventory rather than relying on an assumed in-app menu location

A Medium Rating Still Deserves a Direct Patch Response​

CVE-2026-13991 is described as insufficient validation of untrusted input in Chrome for iOS. The Chrome-originated description presented through NVD says that a remote attacker can use a crafted HTML page to produce UI spoofing in versions earlier than 150.0.7871.47.
The operative phrase is UI spoofing. The record does not say that the attacker executes native code, escapes a browser sandbox, installs software, or takes control of the device. The documented consequence is that crafted web content can cause misleading interface presentation after user interaction.
That distinction should keep the response proportionate, but it should not delay the update. Browser interface integrity helps users interpret what is happening during a web interaction. If an affected browser can present that information incorrectly, the browser is no longer providing the expected separation between untrusted content and the interface used to interpret it.
The public record does not identify the exact Chrome interface element involved, the required page structure, or the complete sequence needed to trigger the condition. The linked Chromium issue requires permission. That establishes only that the issue details are not publicly accessible through the supplied reference; it does not establish why access is restricted or when additional details may become available.
The defensible summary is therefore narrow:

• The issue affects Chrome on iOS before 150.0.7871.47.
• A remote attacker can deliver the condition through crafted HTML.
• User interaction is required.
• The documented result is UI spoofing.
• The corrected-version boundary is 150.0.7871.47.
• The public issue reference does not provide enough information to reconstruct the exploit.

No more elaborate attack narrative is necessary to justify remediation.

What the CVSS and SSVC Data Actually Establish​

The supplied CISA-ADP CVSS 3.1 assessment assigns a base score of 4.3 and the vector AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N.
In plain English, that vector describes an issue that is network reachable, has low attack complexity, requires no prior privileges, and depends on user interaction. The assessment records unchanged scope, no direct confidentiality impact, low integrity impact, and no availability impact.
Those characteristics explain why the issue is rated Medium rather than like a remote code-execution vulnerability. The user-interaction requirement means the attacker cannot complete the documented outcome without user participation. The impact fields do not describe information disclosure, service disruption, or total integrity loss.
The score should remain properly attributed. It is the CISA-ADP CVSS 3.1 assessment displayed through NVD, not an independently calculated NVD score. The supplied record does not include an NVD-authored CVSS assessment.
The SSVC values provide separate prioritization context. The supplied assessment records:

• Exploitation: none
• Automatable: no
• Technical impact: partial

These are assessment values, not universal findings. “Exploitation: none” means no exploitation was recorded in the supplied SSVC assessment. It does not prove that exploitation had never occurred, that no private testing existed, or that no public exploit could exist elsewhere.
Likewise, “automatable: no” should not be converted into assumptions about campaign scale, delivery methods, exploit reliability, or the amount of tailoring an attacker would need. “Technical impact: partial” describes the supplied SSVC categorization and should not be used to invent additional downstream consequences.
Taken together, the record supports prompt but measured remediation: there is no supplied evidence of exploitation in the SSVC assessment, but there is a clear affected product, a remote crafted-page mechanism, and a precise fixed-version threshold.

---

The Platform Boundary Must Remain Attached to the Finding​

The supplied NVD record identifies Chrome on iOS. It does not list Windows, macOS, Linux, Android, or desktop Chrome as affected by this CVE.
That is the precise platform conclusion administrators should preserve. It is not an independent technical determination that related code can never exist elsewhere, nor is it a general statement about every Chromium-based product. It is the scope established by the supplied affected-product record.
For WindowsForum readers, this distinction matters in both directions. A vulnerability scanner that matches only the product name “Google Chrome” may incorrectly create findings for Windows endpoints if it loses the iOS platform condition. At the same time, a Windows-focused organization may still manage iPhones that have Chrome installed and use those devices for organizational work.
The remediation population should therefore be defined by all three relevant facts:

1. The device is within the Apple mobile environment identified by the record.
2. Google Chrome is installed.
3. The complete Chrome version is earlier than 150.0.7871.47.

Do not turn the version threshold into a universal Chrome or Chromium rule. Chrome on Windows, Chrome on Android, Microsoft Edge, Safari, embedded Chromium applications, and other browsers require their own product-specific evidence.

Deployment state	Reported Chrome for iOS version	CVE-2026-13991 status	Required action
Below the fixed threshold	Earlier than 150.0.7871.47	Within the documented affected range	Update and verify
At the fixed threshold	Exactly 150.0.7871.47	Outside the documented affected range	Retain current version evidence
Above the fixed threshold	Later than 150.0.7871.47	Outside the documented affected range	Maintain normal update management
Incomplete version	“Chrome 150” or another partial value	Unresolved	Obtain the complete version
Version unavailable	No trustworthy application-version result	Unresolved	Re-query inventory or obtain verified evidence
Different platform	Windows, macOS, Linux, or Android	Not listed as affected by the supplied record	Evaluate separately; do not copy this finding

The complete version matters. An inventory result showing only major version 150 does not establish whether the application is below, equal to, or above 150.0.7871.47.
An update instruction or deployment assignment also does not prove that the corrected version is installed. Closure should be based on a current installed-version result rather than the fact that an update was offered, assigned, or requested.

End Users Should Update Through the App Store​

An affected user should update Chrome through Apple’s application-update interface:

1. Open the App Store.
2. Select the profile picture or account icon.
3. Open or review Available Updates.
4. Find Google Chrome.
5. Select Update.
6. Reopen Chrome after the update completes.

The remediation target is Chrome 150.0.7871.47 or later.
The supplied material does not verify a current, universal in-app path for displaying Chrome’s complete version on iOS. Interface locations can change, and an assumed menu sequence should not be presented as fact. Where an organization manages the device, administrators should confirm the installed application version through the MDM or managed-application inventory.
Where no managed inventory is available, the help desk should use a version-verification method that it has tested against the currently deployed Chrome for iOS release. It should not instruct users to follow an unverified “About Chrome” path merely because a similar menu exists on another platform.
Users should not be told that the vulnerability allows attackers to “hack an iPhone.” That overstates the supplied evidence. A concise notification can say:

Older Chrome for iOS versions contain a flaw that can allow a crafted webpage to display misleading browser interface information. Update Chrome through the App Store and confirm that the installed version is 150.0.7871.47 or later.

That wording communicates the reason for the update without inventing code execution, device takeover, credential theft, or a specific phishing scenario.

The Public Record Supports Patching, Not Exploit Reconstruction​

The supplied references provide enough information to identify affected installations and apply the correction. They do not provide enough technical detail to reconstruct the vulnerability.
The Chromium issue reference requires permission. From that fact alone, defenders cannot determine:

• The precise Chrome component or interface state involved
• The exact crafted-HTML structure
• The interaction sequence needed to trigger the issue
• The reliability of the condition
• The patch implementation
• Whether any specific site design resembles the vulnerable behavior
• Whether a particular browser log, URL pattern, script sequence, or endpoint event identifies exploitation

The issue’s restricted state should not be assigned an unsupported disclosure rationale. It does not prove that Google withheld the report to prevent reproduction, that the company was waiting for a deployment target, or that public details will appear on a particular schedule.
The lack of public mechanics also does not prevent remediation. Exposure can be determined through the installed version:

• Chrome for iOS earlier than 150.0.7871.47 remains within the affected range.
• Chrome for iOS 150.0.7871.47 or later has crossed the published correction boundary.
• An incomplete, stale, or missing version remains unresolved.

This version-based approach is more defensible than speculative exploit detection. General web-security controls may still provide useful protection, but the supplied record does not establish a CVE-specific network signature, endpoint alert, browser event, content rule, or workaround.
If suspicious web activity is reported, investigators can follow their normal evidence-preservation procedures. However, the presence of an affected Chrome version and an unusual page does not, by itself, prove exploitation of CVE-2026-13991.

The Record’s Provenance Matters​

The vulnerability record presents contributions from several sources, and those contributions should not be collapsed into a single “NVD says” attribution.
Chrome supplied the core vulnerability information, including the affected product, the crafted-HTML mechanism, the UI-spoofing result, the Medium severity classification, the weakness information, and the fixed-version boundary.
CISA-ADP supplied the visible CVSS 3.1 score and vector along with the SSVC values. The 4.3 score should therefore be identified as CISA-ADP’s assessment rather than an NVD-authored score.
NVD presents the standardized record and affected configuration. The normalized configuration ties the affected Google Chrome version range to the Apple mobile operating-system environment identified in the supplied material.
Reference classifications should also be described conservatively. The record identifies a vendor reference and a permission-required issue-tracking reference, but the supplied excerpt does not establish the vendor page’s title, its platform emphasis, how prominently the CVE appears, or the editorial reasoning behind its placement.

Timeline​

The supplied material supports an attribution-based sequence without relying on unverified calendar dates:
Chrome-originated disclosure: Chrome supplied the core vulnerability description, identifying insufficient validation of untrusted input, crafted HTML, user interaction, UI spoofing, Chrome on iOS, and the affected boundary before 150.0.7871.47.
CISA-ADP assessment: CISA-ADP contributed the CVSS 3.1 vector and 4.3 Medium score. It also supplied the SSVC values recording exploitation as none, automatable as no, and technical impact as partial.
NVD configuration and presentation: NVD presented the record and the affected-product configuration associating the vulnerable Chrome range with the Apple mobile operating-system environment.
Operational remediation: Chrome for iOS 150.0.7871.47 establishes the documented correction threshold. Earlier versions should be updated, and the complete installed version should be verified afterward.
This sequence is more useful than unsupported timestamp precision. It preserves the source of each material fact while keeping the operational conclusion stable: Chrome for iOS below 150.0.7871.47 is affected according to the supplied record.

---

Enterprise Remediation Should Produce Version Evidence​

CVE-2026-13991 belongs in mobile application inventory and compliance workflows, not in a generic Windows desktop-browser queue.
The enterprise objective is simple: identify every managed or work-enabled device with Chrome for iOS, determine the complete installed version, update affected installations, and collect fresh evidence that the application now reports 150.0.7871.47 or later.
The supplied material does not establish one universally valid MDM workflow or product-specific command. Organizations should use their supported management platform without presenting local configuration steps as Google, NVD, or CISA guidance.
A platform-neutral procedure is:

1. Inventory the application. Query managed Apple mobile devices for the Google Chrome application bundle and installed application version.
2. Preserve the platform condition. Ensure that the finding applies to Chrome on iOS rather than every asset carrying the Google Chrome product name.
3. Compare the complete version. Flag every installation earlier than 150.0.7871.47.
4. Treat incomplete data as unresolved. A missing, stale, truncated, or major-version-only result does not prove compliance.
5. Deploy or require the update. Use the organization’s supported managed-app deployment process where that capability exists. Otherwise, direct users through the App Store update procedure.
6. Re-query the application version. Collect a fresh installed-version result after the remediation action.
7. Apply an access decision where supported. For devices that fail to report compliance, gate sensitive browser-based access only where the organization’s management and access platforms can enforce that requirement.
8. Document exceptions. Assign an owner and next action to every device whose version cannot be verified or brought to the required threshold.
9. Close with evidence. Close the finding only when current inventory reports 150.0.7871.47 or later, Chrome is confirmed absent, or an approved exception remains under active management.

Access gating is an organizational control, not a workaround documented for the CVE. Teams should confirm that their own MDM and access platforms can evaluate the required application data before claiming that enforcement is active.

Action checklist for admins​

• Inventory managed and work-enabled Apple mobile devices with Google Chrome installed.
• Collect the application bundle identity and complete installed Chrome version.
• Identify every Chrome for iOS installation earlier than 150.0.7871.47.
• Keep missing, stale, partial, or conflicting inventory results in an unresolved state.
• Require or deploy the current Chrome update through the supported managed-app process.
• Provide users with the App Store update sequence where central deployment is unavailable.
• Re-query the installed application version after remediation.
• Require version 150.0.7871.47 or later for closure.
• Gate sensitive access for devices that fail to report compliance where supported by the organization’s management and access platforms.
• Keep Windows, macOS, Linux, Android, desktop Chrome, Edge, Safari, and other browsers outside this finding unless separate evidence establishes applicability.
• Record the 4.3 score as CISA-ADP’s CVSS 3.1 assessment, not an NVD-authored score.
• Describe exploitation precisely: no exploitation was recorded in the supplied SSVC assessment.
• Continue monitoring authoritative records for changes in the affected range, technical description, or exploitation assessment.

A useful closure record should include the device identifier, operating-system platform, application identity, complete pre-remediation version, remediation action, complete post-remediation version, time of the latest observation, and the owner of any unresolved exception.
That is an evidence model, not a claim that every MDM platform automatically reports all of those fields.

Detection Guidance Must Remain Clearly Inferential​

The supplied public information does not establish a CVE-specific indicator of compromise. It identifies crafted HTML and UI spoofing, but it does not provide a malicious URL pattern, page signature, network sequence, browser-log event, endpoint alert, or forensic artifact that uniquely identifies CVE-2026-13991.
Administrators should therefore avoid claims that ordinary telemetry either will or will not capture exploitation. The record does not support a categorical conclusion in either direction.
As a defensive inference, an organization investigating a user report may preserve the available page address, referral source, screenshots, browser history, link-delivery message, timing, and actions taken after viewing the page. Those are general investigation steps for suspicious web activity. They are not documented detection methods for this CVE and should not be represented as proof that the vulnerability was used.
Likewise:

• An unexpected interface or navigation event does not prove exploitation.
• An affected application version establishes exposure, not compromise.
• The absence of an alert does not establish remediation.
• An update assignment establishes administrative action, not installation.
• A current version at or above 150.0.7871.47 establishes that the application has crossed the documented correction boundary.

The primary control is the corrected build. Detection and investigation remain secondary, evidence-driven activities.

---

What Defenders Should Carry Forward​

CVE-2026-13991 is a contained Chrome for iOS vulnerability with a clear remediation boundary. The public record documents crafted HTML, required user interaction, and UI spoofing. It does not document code execution, browser takeover, sandbox escape, complete iPhone compromise, or exposure across every Chrome platform.
The practical conclusions are precise:

• Google Chrome on iOS versions earlier than 150.0.7871.47 is affected.
• Chrome 150.0.7871.47 or later crosses the documented correction boundary.
• The supplied NVD record identifies Chrome on iOS; it does not list Windows, macOS, Linux, Android, or desktop Chrome as affected by this CVE.
• CISA-ADP supplied the 4.3 Medium CVSS 3.1 assessment.
• No exploitation was recorded in the supplied SSVC assessment.
• The permission-required Chromium issue does not reveal enough information to reconstruct the vulnerability or explain why access is restricted.
• End users should update through App Store > profile picture/account icon > Available Updates > Chrome > Update.
• Enterprises should inventory the application and complete version, enforce or require the corrected release, re-query the version, and keep unverifiable devices unresolved.
• Where supported, organizations can gate sensitive access for devices that fail to report the required version, but that control should not be portrayed as a vendor-provided workaround.
• Version evidence is the dependable closure criterion.

CVE-2026-13991 is unlikely to demand the response reserved for a remotely exploitable browser takeover. Its value as an operational test is different: can an organization preserve a mobile-specific platform condition, route remediation to the correct owner, provide users with a concrete update procedure, and prove that affected installations have reached the corrected version?
Organizations that can answer those questions have a repeatable mobile-browser vulnerability process. Those that cannot should treat the missing inventory and verification capability as the larger finding—because the next mobile-browser issue may not be limited to partial integrity impact or accompanied by an SSVC assessment recording no exploitation.

---

References​

1. Primary source: NVD / Chromium
   Published: 2026-07-11T15:40:36-07:00
   
   

   NVD - CVE-2026-13991

   nvd.nist.gov
2. Security advisory: MSRC
   Published: 2026-07-11T15:40:36-07:00
   Original feed URL
   
   

   Security Update Guide - Microsoft Security Response Center

   msrc.microsoft.com
3. Related coverage: cvefeed.io
   
   

   CVE-2026-13991 - Google Chrome for iOS UI Spoofing Vulnerability

   Insufficient validation of untrusted input in Chrome for iOS in Google Chrome on iOS prior to 150.0.7871.47 allowed a remote attacker to perform UI spoofing via a crafted HTML page. (Chromium security severity: Medium)

   cvefeed.io
4. 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
5. Related coverage: chromium.googlesource.com
   
   Chromium Docs - Chrome Security FAQ