Google Chrome on macOS versions earlier than 150.0.7871.47 are affected by CVE-2026-13998, a Medium-severity flaw described as incorrect security UI in file input. A remote attacker can use crafted HTML to perform UI spoofing after persuading a user to complete specific gestures. The supplied record does not establish silent file theft, code execution, sandbox escape, or impact to Chrome on Windows, Microsoft Edge, or other Chromium-based browsers.
For remediation, Mac users and administrators should use Chrome 150.0.7871.47 as the minimum acceptable version, relaunch the browser, and verify that the new version is active.
The NVD record, sourced from Chrome, describes CVE-2026-13998 as “Incorrect security UI in File Input.” It says Google Chrome on Mac before version 150.0.7871.47 allowed a remote attacker to perform UI spoofing through crafted HTML after convincing a user to engage in specific UI gestures.
The available facts describe a deception-oriented vulnerability rather than a silent browser takeover. The record does not identify memory corruption, arbitrary code execution, sandbox escape, or automatic access to local files. Administrators should not add those outcomes to the vulnerability narrative without further evidence.
CISA-ADP associated the issue with CWE-451, User Interface Misrepresentation of Critical Information. That classification is consistent with the record’s focus on incorrect security UI and spoofing. The security concern is that attacker-controlled presentation could mislead a user during an interaction involving file input.
The CVSS 3.1 vector supplied by CISA-ADP is
The network attack vector indicates that the scenario can be initiated remotely.
Attack complexity is High and user interaction is required. Those constraints distinguish CVE-2026-13998 from an automatic compromise triggered solely by loading a page. The record says the attacker must convince the user to perform specific gestures, although it does not publicly establish the exact sequence.
The supplied CISA-ADP SSVC entry lists exploitation as none, automation as no, and technical impact as partial. Those are the precise published values and should not be converted into broader claims that exploitation cannot exist or that future activity is impossible.
The CVSS impact metrics list no confidentiality impact and Low integrity and availability impacts. NIST had not supplied an independent CVSS 3.x, CVSS 4.0, or CVSS 2.0 assessment in the supplied record. The displayed 4.2 score is therefore a CISA-ADP contribution presented through NVD, not a separate NIST score.
That context should guide prioritization. The record supports routine, prompt remediation, but it does not support treating the issue as an automatic browser takeover or an established active campaign.
This threshold describes whether a version falls inside or outside the stated affected range. The supplied NVD material alone does not prove that a particular release is currently available through every update channel or has already reached every managed device.
A browser relaunch matters operationally because administrators must verify the version that is actually running. The supplied CVE facts do not describe Chrome’s update mechanics or establish the conditions under which an update is downloaded, staged, or activated. The defensible verification step is simply to relaunch when Chrome requests it and then confirm the active version.
Administrators should avoid treating successful package delivery, an update command, or a dashboard status as a substitute for checking the running browser version. Those signals may be useful in a particular environment, but they are not direct evidence that Chrome has crossed the CVE’s version threshold.
Read literally, the two boundaries do not align. The CPE expression appears narrower than the explicit affected-version wording.
The record does not establish why the difference exists. It should not be attributed to a scanner defect, enrichment delay, encoding method, or any other cause without supporting evidence. Nor does the discrepancy prove that a particular vulnerability-management product will produce an incorrect result.
For remediation, use the vendor threshold reflected in the record: Chrome 150.0.7871.47 or later. A Mac running a lower version should not receive an exception merely because a CPE-based result appears to use the narrower boundary.
This is the article’s key vulnerability-management caveat. Standardized product expressions are useful for matching, but when a supplied CPE boundary conflicts with an explicit vendor affected-version statement, administrators should base the remediation decision on the vendor threshold.
It also does not establish impact to Microsoft Edge, including Edge on macOS, or to another Chromium-based browser. Shared Chromium heritage is not sufficient evidence to transfer a CVE from one named product and platform to another.
For Windows-focused administrators, the immediate task is therefore to identify Macs that run Google Chrome. A Windows-only inventory result does not resolve exposure in a mixed environment, while the presence of Chromium components in another browser does not establish that browser as vulnerable.
The scope should remain narrow unless another authoritative product record expands it:
It does not establish the exact gesture sequence, the detailed visual presentation, exploit reliability, or a particular social-engineering script. Administrators should not create a hypothetical workflow and present it as the documented exploit.
The linked Chromium issue requires permission to view, limiting the public technical detail available in the supplied material. That fact explains why some implementation questions remain unanswered, but it does not establish why access is restricted. Claims about disclosure strategy, exploit prevention, or update propagation would require additional sourcing.
The lack of public detail also means the record does not support a highly specific detection rule. It does not identify a distinctive network request, log event, page signature, or other indicator that administrators can use to find attempted exploitation.
Unsupported workaround claims should likewise be avoided. The record does not identify a browser policy, feature flag, macOS option, domain block, or configuration change that removes the affected behavior while an earlier Chrome version remains in use.
The practical control is version compliance. User caution may supplement that control, but the supplied facts do not establish training as a reliable mitigation for incorrect security UI.
The score should not become a reason for indefinite deferral. Chrome processes remote web content, and the record describes a flaw that can misrepresent security-relevant file-input UI. Moving affected Macs outside the stated version range is a direct and verifiable reduction in exposure.
The appropriate posture is prompt routine remediation with confirmation, not emergency isolation. Organizations can prioritize according to their own exposure and maintenance schedules, but any local risk adjustment should be identified as an internal decision rather than an assessment supplied by NVD, Chrome, CISA-ADP, or NIST.
The supplied CISA-ADP SSVC values—exploitation none, automation no, and technical impact partial—support that measured response. They do not justify categorical statements that the flaw is harmless, impossible to exploit, or certain to remain unused.
The supplied facts do not support a more detailed disclosure timeline or conclusions about the order in which Google, CISA, and NIST performed every publication or analysis step. For administrators, the important distinctions are the source of the 4.2 score and the mismatch between the vendor threshold and the CPE expression.
For remediation, Mac users and administrators should use Chrome 150.0.7871.47 as the minimum acceptable version, relaunch the browser, and verify that the new version is active.
A Medium Chrome Bug Requiring User Interaction
The NVD record, sourced from Chrome, describes CVE-2026-13998 as “Incorrect security UI in File Input.” It says Google Chrome on Mac before version 150.0.7871.47 allowed a remote attacker to perform UI spoofing through crafted HTML after convincing a user to engage in specific UI gestures.The available facts describe a deception-oriented vulnerability rather than a silent browser takeover. The record does not identify memory corruption, arbitrary code execution, sandbox escape, or automatic access to local files. Administrators should not add those outcomes to the vulnerability narrative without further evidence.
CISA-ADP associated the issue with CWE-451, User Interface Misrepresentation of Critical Information. That classification is consistent with the record’s focus on incorrect security UI and spoofing. The security concern is that attacker-controlled presentation could mislead a user during an interaction involving file input.
The CVSS 3.1 vector supplied by CISA-ADP is
AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:L/A:L, producing a base score of 4.2 and a Medium rating.The network attack vector indicates that the scenario can be initiated remotely.
PR:N means the attacker requires no prior privileges. It should not be expanded into claims about particular software, access methods, or footholds that are not described in the supplied record.Attack complexity is High and user interaction is required. Those constraints distinguish CVE-2026-13998 from an automatic compromise triggered solely by loading a page. The record says the attacker must convince the user to perform specific gestures, although it does not publicly establish the exact sequence.
The supplied CISA-ADP SSVC entry lists exploitation as none, automation as no, and technical impact as partial. Those are the precise published values and should not be converted into broader claims that exploitation cannot exist or that future activity is impossible.
The CVSS impact metrics list no confidentiality impact and Low integrity and availability impacts. NIST had not supplied an independent CVSS 3.x, CVSS 4.0, or CVSS 2.0 assessment in the supplied record. The displayed 4.2 score is therefore a CISA-ADP contribution presented through NVD, not a separate NIST score.
That context should guide prioritization. The record supports routine, prompt remediation, but it does not support treating the issue as an automatic browser takeover or an established active campaign.
The Operational Version Boundary
The affected-version wording covers Google Chrome on Mac before 150.0.7871.47. Administrators should therefore use 150.0.7871.47 or later as the remediation threshold.This threshold describes whether a version falls inside or outside the stated affected range. The supplied NVD material alone does not prove that a particular release is currently available through every update channel or has already reached every managed device.
| Deployment state | Platform | Chrome version | Administrative interpretation |
|---|---|---|---|
| Below threshold | macOS | Earlier than 150.0.7871.47 | Inside the stated affected range |
| At threshold | macOS | 150.0.7871.47 | Outside the stated affected range |
| Above threshold | macOS | Later than 150.0.7871.47 | Outside the stated affected range |
| Other platform | Non-Mac | Any | Not established as affected by this record |
| Microsoft Edge or another Chromium browser | Any | Any | Not established as affected by this record |
Administrators should avoid treating successful package delivery, an update command, or a dashboard status as a substitute for checking the running browser version. Those signals may be useful in a particular environment, but they are not direct evidence that Chrome has crossed the CVE’s version threshold.
The CPE Boundary Does Not Cleanly Match the Vendor Wording
The supplied data contains a compact but important discrepancy. The vendor wording covers Chrome on Mac versions before 150.0.7871.47, while the supplied NIST CPE expression appears to stop before 150.0.7871.46.Read literally, the two boundaries do not align. The CPE expression appears narrower than the explicit affected-version wording.
The record does not establish why the difference exists. It should not be attributed to a scanner defect, enrichment delay, encoding method, or any other cause without supporting evidence. Nor does the discrepancy prove that a particular vulnerability-management product will produce an incorrect result.
For remediation, use the vendor threshold reflected in the record: Chrome 150.0.7871.47 or later. A Mac running a lower version should not receive an exception merely because a CPE-based result appears to use the narrower boundary.
This is the article’s key vulnerability-management caveat. Standardized product expressions are useful for matching, but when a supplied CPE boundary conflicts with an explicit vendor affected-version statement, administrators should base the remediation decision on the vendor threshold.
Mac-Only Scope in the Supplied Record
CVE-2026-13998 is described as affecting Google Chrome on Mac. The supplied material does not establish that Chrome on Windows is affected, despite the shared Chrome product name.It also does not establish impact to Microsoft Edge, including Edge on macOS, or to another Chromium-based browser. Shared Chromium heritage is not sufficient evidence to transfer a CVE from one named product and platform to another.
For Windows-focused administrators, the immediate task is therefore to identify Macs that run Google Chrome. A Windows-only inventory result does not resolve exposure in a mixed environment, while the presence of Chromium components in another browser does not establish that browser as vulnerable.
The scope should remain narrow unless another authoritative product record expands it:
- Product: Google Chrome.
- Platform: macOS.
- Affected versions: Earlier than 150.0.7871.47.
- Windows impact: Not established by the supplied record.
- Microsoft Edge impact: Not established by the supplied record.
- Other Chromium-browser impact: Not established by the supplied record.
What the Public Record Does—and Does Not—Establish
The supplied record establishes crafted HTML, specific user gestures, UI spoofing, Mac-only Chrome scope, and an affected-version boundary.It does not establish the exact gesture sequence, the detailed visual presentation, exploit reliability, or a particular social-engineering script. Administrators should not create a hypothetical workflow and present it as the documented exploit.
The linked Chromium issue requires permission to view, limiting the public technical detail available in the supplied material. That fact explains why some implementation questions remain unanswered, but it does not establish why access is restricted. Claims about disclosure strategy, exploit prevention, or update propagation would require additional sourcing.
The lack of public detail also means the record does not support a highly specific detection rule. It does not identify a distinctive network request, log event, page signature, or other indicator that administrators can use to find attempted exploitation.
Unsupported workaround claims should likewise be avoided. The record does not identify a browser policy, feature flag, macOS option, domain block, or configuration change that removes the affected behavior while an earlier Chrome version remains in use.
The practical control is version compliance. User caution may supplement that control, but the supplied facts do not establish training as a reliable mitigation for incorrect security UI.
Prioritizing a 4.2 Vulnerability
The Medium rating reflects meaningful constraints. Exploitation requires user interaction, attack complexity is High, and the published impact metrics are limited. Those characteristics justify placing CVE-2026-13998 below unauthenticated remote-code-execution or sandbox-escape vulnerabilities when an organization must triage competing work.The score should not become a reason for indefinite deferral. Chrome processes remote web content, and the record describes a flaw that can misrepresent security-relevant file-input UI. Moving affected Macs outside the stated version range is a direct and verifiable reduction in exposure.
The appropriate posture is prompt routine remediation with confirmation, not emergency isolation. Organizations can prioritize according to their own exposure and maintenance schedules, but any local risk adjustment should be identified as an internal decision rather than an assessment supplied by NVD, Chrome, CISA-ADP, or NIST.
The supplied CISA-ADP SSVC values—exploitation none, automation no, and technical impact partial—support that measured response. They do not justify categorical statements that the flaw is harmless, impossible to exploit, or certain to remain unused.
Metadata Note
The NVD entry combines information from multiple contributors. The NVD record is sourced from Chrome, while CISA-ADP supplied the displayed CVSS 3.1 assessment, CWE classification, and SSVC values. NIST supplied product-matching information, including the CPE expression whose version boundary does not cleanly match the vendor wording.The supplied facts do not support a more detailed disclosure timeline or conclusions about the order in which Google, CISA, and NIST performed every publication or analysis step. For administrators, the important distinctions are the source of the 4.2 score and the mismatch between the vendor threshold and the CPE expression.
Administrator Checklist
- Identify Macs running Google Chrome.
- Flag versions earlier than 150.0.7871.47.
- Use 150.0.7871.47 or later as the remediation threshold.
- Do not grant an exception based solely on the narrower-looking NIST CPE expression.
- Use standard Chrome UI guidance—Chrome menu > Help > About Google Chrome—to inspect the installed version.
- Relaunch Chrome if prompted and confirm the active version afterward.
- Do not assume package delivery alone proves that the required browser version is running.
- Do not mark Chrome on Windows as affected based on this record.
- Do not mark Microsoft Edge or other Chromium browsers as affected without product-specific evidence.
- Do not claim that a policy change or configuration workaround mitigates the flaw unless supported by additional vendor guidance.
- Record devices that remain below the threshold for follow-up.
References
- Primary source: NVD / Chromium
Published: 2026-07-11T15:39:47-07:00
NVD - CVE-2026-13998
nvd.nist.gov
- Security advisory: MSRC
Published: 2026-07-11T15:39:47-07:00
Original feed URL
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
- Related coverage: ubuntu.com
- Related coverage: issues.chromium.org
Chromium
issues.chromium.org
- Related coverage: security.snyk.io
CVE-2026-13998 in chromium | CVE-2026-13998 | Snyk
CVE-2026-13998 in chromium | CVE-2026-13998security.snyk.io