Red Hat
Monthly
OAuth2 token-endpoint misuse in Gitea 28.0.0 and earlier allows anyone holding a valid, unexpired OAuth2 access token to submit it under the refresh_token grant and receive a brand-new access token plus refresh token, effectively extending access past the credential's original expiry. Exploitation requires a pre-existing valid access token issued for the same OAuth2 application and grant, so this is a persistence/escalation-of-lifetime flaw rather than an entry point for an unauthenticated outsider; the assessed vector is CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N (NVD rates it 9.1 with PR:N). Multi-source signals conflict: NVD's score and CISA's SSVC rating of total technical impact are severe, while EPSS is only 0.17% (6th percentile) and SSVC lists exploitation as none - no public exploit code has been identified at time of analysis and the issue is not in CISA KEV.
Path traversal in the Backstage Scaffolder Bitbucket pull-request publish actions allows an authenticated user who can execute an eligible template and influence an allowlisted Bitbucket repository to write files outside the expected working area, potentially compromising backend confidentiality, integrity, and availability. Affected are @backstage/plugin-scaffolder-backend-module-bitbucket-cloud before 0.3.10 and @backstage/plugin-scaffolder-backend-module-bitbucket-server before 0.2.25 (shipped with Backstage before the v1.54.6 release). Exploitation requires an authenticated account with template-execution privileges, control over the contents of a repository already present in the Bitbucket allowlist, and the source-branch creation flow to be exercised, which is why the assessed vector carries high attack complexity (CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H, score 8.5); this is not reachable by an anonymous remote attacker on a default install, and no public exploit code has been identified at time of analysis.
OpenSSH sshd before 10.6 can incorrectly persist GSSAPIAuthentication state across authentication attempts when GSSAPIAuthentication is enabled, allowing a remote, unauthenticated attacker to influence authentication integrity on the same connection. This is a non-default configuration issue: stock OpenSSH deployments without Kerberos/GSSAPI are not affected, and the attacker must drive a sequence of authentication attempts (high attack complexity). No public exploit code has been identified, EPSS is very low (0.08%, 0th percentile), and CISA SSVC reports no exploitation; the vendor has released a fix in OpenSSH 10.6.
Unauthenticated attackers who can reach Gitea's web installer on an instance whose INSTALL_LOCK has been reset to false (or is otherwise unset) can obtain a fully authenticated session for any existing account - including an administrator - simply by submitting the install form with a username that matches that account, with no password verification whatsoever. Full administrative takeover follows, allowing the attacker to change the account's password and control the instance. The bypass only exists while the installer is network-reachable against a database that already contains users; the default hardened post-install state (INSTALL_LOCK=true) is not affected. Independent assessment rates this CVSS 8.1 (AV:N/AC:H/PR:N/UI:N, C:H/I:H/A:H); EPSS is low at 0.16% (4th percentile) and no public exploit code has been identified at time of analysis.
Fork-originated Gitea Actions workflows can run on a base repository's registered runners without the required approval when a repository maintainer performs ordinary pull request triage, such as adding a label, because the approval decision was keyed to the user who triggered the event rather than the fork pull request author, allowing fork-controlled workflow code to execute in the base repository's CI context. Gitea versions up to and including 1.27.3 are affected when Actions is enabled and a matching runner is registered; the issue is fixed in Gitea 28.0.0. No public exploit code was identified at time of analysis and EPSS is low (0.15%, 3rd percentile), but exploitation is not autonomous: the assessed vector (CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:H/I:H/A:H) requires an attacker-submitted fork pull request plus a privileged maintainer action, and CISA SSVC rates the technical impact as total, so the outcome when the prerequisite chain is met is full compromise of confidentiality, integrity, and availability of the workflow execution environment.
Local authenticated attackers who share a writable Java temporary directory with a victim JVM can exploit a time-of-check/time-of-use race in lz4-java 1.7.0 through 1.11.3 to replace the native LZ4 library extracted by net.jpountz.util.Native.load(), potentially executing native code with the victim's privileges. The vulnerability is local-only and requires winning a race against native-library extraction, plus a shared java.io.tmpdir and native binding use; hardened configurations may instead fail loading and fall back to Java implementations. Version 1.11.4 fixes the issue; no public exploit identified at time of analysis.
Code execution in Handlebars.js versions 4.0.0 through 4.7.9 occurs when an application hands an attacker-controllable, pre-parsed AST object - rather than a template string - to Handlebars.compile() or Handlebars.precompile(); the compiler writes JavaScript expressions carried in unchecked AST fields straight into the generated code, which then executes in the server process wherever the compiled output runs. The flaw is an incomplete fix: the AST validation added in 4.7.9 for CVE-2026-33937 covered only PathExpression, NumberLiteral and BooleanLiteral values, leaving fields such as Program.blockParams.length, a non-PathExpression parameter depth, a non-string StringLiteral.value and a non-string PathExpression.original unvalidated. The published CVSS 3.1 vector is AV:N/AC:L/PR:N/UI:N/C:H/I:H/A:H (9.8) and treats this as trivially remote and unauthenticated, but that materially overstates real-world exposure: the vulnerable path is a non-default application design pattern that the vendor explicitly warns against, so applications that compile only template strings - the standard, documented usage - are completely unaffected, and no public exploit code has been identified at time of analysis. Vendor-released patch: 4.7.10.
Server-side remote code execution affects Handlebars versions 4.0.0 through releases prior to 4.7.10, where a flaw in the lookupProperty prototype-access check lets a rendered template reach Function.prototype.constructor and obtain the JavaScript Function constructor, executing attacker-supplied code with the server application's privileges. Exploitation is conditional: an unauthenticated remote attacker must be able to render a template whose source they control, the runtime must have allowProtoMethodsByDefault enabled (not the default configuration), and the template context must expose an accessible function value that can be traversed via __proto__. No public exploit code was identified at time of analysis and the issue is not confirmed as actively exploited (no CISA KEV listing); vendor-released patch: 4.7.10.
Access-control bypass in SSSD lets an already-authenticated user from a trusted identity domain reach hosts and services that Host-Based Access Control (HBAC) rules are supposed to protect. Because SSSD strips the domain qualifier and compares only short usernames during HBAC evaluation, a trusted-domain user whose short name collides with an authorized local account is silently granted that local account's access. Publicly available exploit code exists, but exploitation is not automatable and EPSS is low at 0.28% (18th percentile); exposure is limited to trust-enabled FreeIPA/IdM-style deployments that delegate host access decisions to SSSD.
Authentication bypass in Gitea's built-in SSH server (affected releases up to and including 1.27.3) lets a remote attacker authenticate as another user by presenting a case-variant of that user's registered RSA public key. Three conditions must all hold: the built-in SSH server must be enabled via START_SSH_SERVER = true (non-default on many deployments), the backing database must perform case-insensitive text comparison (the default SQLite qualifies), and the attacker must possess or derive a working RSA private key whose public key differs from the victim's only by letter case, which is cryptographically very hard and is why the effort is assessed as high complexity rather than the low complexity of the published vendor vector. No public exploit code identified at time of analysis; EPSS is 0.16% (4th percentile) and the CISA SSVC assessment records exploitation: none. The flaw is fixed in v28.0.0 by matching keys on their SHA256 fingerprint instead of encoded content.
Authorization bypass in Elasticsearch's Remote Cluster Security (RCS) 2.0 cross-cluster search path lets an authenticated principal holding a cross-cluster API key for one index send a crafted request that is authorized against that permitted index while actually executing against a different, unauthorized index, exposing that index's document contents, field mappings and other metadata, and in limited cases permitting modification of retention-lease state on it. The flaw is an authenticated authorization-boundary bypass (CVSS 7.1, CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N), so the real-world risk is concentrated in multi-tenant or shared clusters that issue cross-cluster API keys to less-trusted tenants, while single-tenant clusters without shared cross-cluster keys are not meaningfully exposed. No public exploit code has been identified at time of analysis.
Incorrect authorization in Elasticsearch 8.x and 9.x allows an authenticated, already-privileged user (CVSS PR:H) who has been granted a non-default, delegated role-management privilege to escalate privileges within a cluster. By abusing a role-definition setting that expands the set of indices matched against a delegated index-scoped privilege, the holder can modify their own assigned role and reach indices that should remain restricted, including internal security data, and from there potentially obtain full administrative control of the cluster. Exploitation is only possible when the cluster has the configurable delegated role-management privilege explicitly enabled and granted with a broadly-scoped index pattern; default deployments that never delegate this capability are not affected. No public exploit code has been identified at time of analysis and the flaw is not confirmed as actively exploited (not in CISA KEV). Vendor-released patches are available in Elasticsearch 8.19.22, 9.4.7, and 9.5.4.
Denial of service in Mozilla node-convict 6.2.2 and later allows remote, unauthenticated attackers to overwrite core JavaScript methods on the global Object function via config.set(), causing persistent process-wide failure that requires a restart. The flaw arises because the library's prototype-pollution filters only block constructor.prototype.* and __proto__.* key paths, while a key such as constructor.assign is resolved by walk() to the global Object constructor, permitting tampering with methods like Object.assign. Exploitation is not automatic: it requires an application endpoint or handler that forwards attacker-controlled property names directly into config.set(), so only configurations driven by untrusted keys are exposed; no public exploit code has been identified and EPSS is low (0.24%, 14th percentile), with CISA SSVC recording Exploitation: none and no KEV listing.
Server-side request forgery in the Backstage @backstage/plugin-techdocs-node package (0.11.12 through 1.14.6, and 1.15.0 through 1.15.4) lets an authenticated user who controls a TechDocs source repository have documentation builds fetch and publish content from network locations reachable by the build environment. The issue is rated CVSS 7.7 (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N), reflecting a confidentiality-only, scope-changing impact that requires repo write access and a build topology where internal endpoints are reachable without token or special-header protections; newer cloud metadata services that require tokens or custom headers are explicitly not directly accessible. Vendor-released patches exist in @backstage/plugin-techdocs-node 1.14.7 and 1.15.5 (and in Backstage releases v1.50.6, v1.54.8, v1.55.0); no public exploit identified at time of analysis.
Ghostscript can execute arbitrary shell commands with the privileges of its process when it renders a crafted PostScript or EPS document, chaining memory corruption in document parsing with a runtime bypass of the -dSAFER sandbox. The flaw affects Ghostscript as shipped in Red Hat Enterprise Linux 6, 7, 8, 9, and 10, and the assessed vector is CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H, meaning no privileges are required but a victim or automated pipeline must render the malicious file, with the malicious document first reaching the processing system. Publicly available exploit code exists, including a GitHub proof-of-concept, but the provided data does not confirm CISA KEV active exploitation, so -dSAFER should not be treated as a protective mitigation for affected versions.
WeasyPrint releases prior to 70.0 hand attacker-controlled bytes - from HTML img URLs, CSS image values, SVG image references, and data URIs - to Pillow's generic image dispatcher, which does not exclude Encapsulated PostScript, so on any host with Ghostscript installed Pillow's EpsImagePlugin shells out to that interpreter and runs the attacker's PostScript. This produces interpreter-permitted effects, demonstrated by the fix commit's dangerous.eps sample writing /tmp/test-marker.txt, and escalates to remote code execution when the installed Ghostscript has a usable -dSAFER sandbox bypass; hosts without Ghostscript never reach the rasterization path and are not exploitable. No public exploit code and no CISA KEV entry were identified at time of analysis, and the vendor-released patch is WeasyPrint 70.0; the published CVSS is 8.8 while our own assessment rates attack complexity as High with no privileges and no user interaction required.
Hydra 1.3.4 through 1.3.5 and the 1.4.0.dev line prior to 1.4.0.dev9 can execute attacker-chosen code when an application runs Hydra's instantiate() on configuration an attacker can influence, because the callable blacklist added for CVE-2026-68508 is name-based and can be sidestepped via wrappers, aliases, dispatch helpers, or deferred invocation. The CVSS 3.1 vector (AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H, score 7.8) indicates no attacker privileges are required but a victim application must actually instantiate untrusted or externally sourced config, which is why user interaction is scored; the flaw is CWE-184 (Incomplete List of Disallowed Inputs) and is best understood as an incomplete fix rather than a new class of bug. There is no public exploit identified at time of analysis and the issue is not in CISA KEV, and vendor-released patches exist in Hydra 1.3.6 and 1.4.0.dev9. Applications that only ever instantiate developer-authored, trusted configuration are not exposed, and the vendor explicitly documents the blocklist as a best-effort defense-in-depth stopgap rather than a security boundary.
Code injection in the Hydra configuration framework (all releases prior to 1.3.6 and 1.4.0.dev9) lets an attacker who controls the application's Hydra logging configuration name an arbitrary importable class or factory that Hydra will then import and invoke with the application's own privileges. Hydra routes logging settings to Python's logging.config.dictConfig() without applying its own target policy, so the handler 'class' values and the formatter, filter, handler, queue and listener factories are resolved and called directly - this bypasses the _target_whitelist_ protection that otherwise guards instantiate(), meaning even hardened deployments are exposed. The assessed vector is CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H (7.8): a local, unprivileged attacker must plant malicious logging configuration (a config file, an override, or a shared/untrusted config source) and the victim must then run the Hydra application, yielding high confidentiality, integrity and availability impact; no public exploit code has been identified at time of analysis and the flaw is not in CISA KEV, but exploitation only requires that the victim execute the tampered configuration.
Configuration-controlled code execution in the hydra-optuna-sweeper package (Hydra 1.2.0 up to but not including 1.3.0, plus 1.4.0 development builds before 1.4.0.dev10) allows an attacker who controls Optuna sweep configuration or command-line overrides to name an arbitrary importable Python callable in hydra.sweeper.custom_search_space that Hydra resolves and then invokes inside the controller process at the application's privilege level, including bypassing the trusted execution whitelist introduced on affected 1.4.0 development releases. The assessed CVSS 3.1 vector is AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H (7.8 High): delivery is local and unauthenticated, but a victim must actually launch the sweep, after which confidentiality, integrity, and availability impact is total for the affected process. Exploitation is only meaningful where sweep configuration or overrides cross a trust boundary; no public exploit code and no confirmed active exploitation (CISA KEV) were identified at time of analysis.
Code execution with the hosting application's privileges is possible in Hydra 1.3.4 through versions before 1.3.7 (and before 1.4.0.dev10) when an attacker controls multiple sibling target entries in a configuration that the application passes to instantiate(). One sibling resolves hydra._internal.target_policy.UNCONTROLLED_EXECUTION_TARGETS.discard to delete a denied target from Hydra's process-global blocklist, and a later sibling - processed in insertion order against the same mutated policy - invokes the now-permitted callable; the mutation persists for the life of the process. The CVSS 4.0 vector (AV:L/AC:L/AT:N/PR:N/UI:P, 8.5) indicates no privileges are required and only passive user interaction, and no public exploit identified at time of analysis (not in CISA KEV, no POC referenced); exploitation is limited to deployments that feed untrusted configuration content to instantiate(), and a narrow execution whitelist supplied by trusted Python code is not bypassed by the reported direct mutation path.
Use-after-free in Google Chrome's CSS handling affects builds prior to 155.0.8059.39 and allows a remote, unauthenticated attacker to execute arbitrary code inside the renderer sandbox when a victim loads a crafted HTML page. The flaw scores CVSS 3.1 base 8.8 (AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H), yet Google assigned it Chromium severity Low because the resulting code execution is confined to the browser sandbox and requires user interaction - full host compromise would require chaining a separate sandbox-escape bug. No public exploit identified at time of analysis, and a vendor patch is available.
Code execution outside the Chrome sandbox is possible in Google Chrome desktop builds prior to 155.0.8059.39, where a use-after-free in the network component (CVE-2026-106234, CWE-416) can be triggered by a crafted Chrome extension that a remote, unauthenticated attacker convinces a victim to install. The UI:R prerequisite - social engineering the user into installing the extension - is the primary limiting factor, which is why the vendor assigned a Chromium security severity of Low even though the assessed CVSS is 9.6 (AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H) and technical impact is rated total in the CISA SSVC framework; the high CVSS and the Low vendor severity are sharply conflicting signals. No public exploit identified at time of analysis (SSVC exploitation: none), and a vendor patch is available.
A low-severity information disclosure exists in the Payments component of Google Chrome, where a remote attacker using a crafted HTML page and social-engineering lures could cause the browser to leak sensitive information handled by the payments/autofill feature in builds prior to 155.0.8059.39. Exploitation is not automatic: the victim must be convinced to open the attacker's page while running a vulnerable build, and the assessed vector (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N) confines realistic impact to confidentiality loss with no integrity or availability effect. There is no confirmed active exploitation (not in CISA KEV) and no public exploit identified at time of analysis; a vendor patch is available in Chrome 155.0.8059.39. Note that the supplied CVSS base score of 8.8 (C:H/I:H/A:H) is inconsistent with both the Chromium severity rating of Low and the independent assessment, and should not be used for prioritization without reconciliation.
Incomplete cleanup in the Chromoting (Chrome Remote Desktop) component of Google Chrome on macOS before 155.0.8059.39 lets a remote, unauthenticated attacker bypass system access restrictions using crafted network traffic, per the assessed CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N vector. Impact is materially constrained: only macOS hosts on an affected build with Chromoting enabled and reachable are in scope, and the realistic outcome is limited information exposure rather than full compromise, which is consistent with the vendor's 'Low' Chromium severity rating. Risk signals conflict sharply - the supplied CVSS score of 9.1 (C:H/I:N/A:H) and the authoritative assessed vector of C:L/I:N/A:N disagree - and must be reconciled before prioritization; EPSS is negligible at 0.17% (6th percentile), there is no KEV listing, and no public exploit identified at time of analysis. Vendor-released patch: Chrome 155.0.8059.39.
Authorization bypass in the Chromoting (Chrome Remote Desktop) host component of Google Chrome on macOS prior to 155.0.8059.39 lets remote attackers circumvent macOS system access restrictions by sending crafted network traffic to the remoting service; the provided CVSS vector is AV:N/PR:N/UI:N so the flaw is treated as network-reachable and unauthenticated. Exploitation is conditional rather than opportunistic: it requires Chrome Remote Desktop (Chromoting) to be installed, enabled and network-reachable on a macOS host, and Google's Chromium team rated the underlying defect only 'Low' severity, which is why our independent assessment reduces impact to C:L/I:L/A:N with AC:H instead of the vendor's 9.1. No public exploit code or confirmed active exploitation has been identified at time of analysis, and EPSS is low at 0.21% (10th percentile), so this should not be triaged as a 9.1-equivalent emergency even though the vendor score is high.
Information disclosure in Google Chrome for Android lets a remote attacker who successfully socially engineers a victim into opening a crafted HTML page expose sensitive data handled by the browser's Passwords component; builds prior to 155.0.8059.39 are affected, and no authentication or non-default configuration is required. The vendor classifies the issue as Low severity (CWE-200) and no public exploit code was identified at time of analysis. Note that the supplied CVSS base score of 8.8 (C:H/I:H/A:H) is inconsistent with the information-disclosure description and the vendor's Low rating; our independent assessment scores it AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N, i.e. a confidentiality leak that strictly depends on user interaction.
Google Chrome for Android prior to 155.0.8059.39 contains an incorrect-authorization flaw in its Transactions Platform component that lets an unauthenticated remote attacker read sensitive information from the browser by luring the victim into opening a crafted HTML page. No public exploit code has been identified at time of analysis and the issue is not reported as actively exploited, though the attack is fully remote (AV:N/PR:N) and requires only that a user on a vulnerable Android build load the attacker's page (UI:R). Note that public severity signals conflict: the vendor rates this Chromium security severity 'Low' and limits impact to information disclosure, while a widely replicated CVSS 3.1 base score of 8.8 lists high integrity and availability impact that is not supported by the description - our independent assessment scores it 8.8-adjacent only on confidentiality (C:H/I:N/A:N).
The signals here conflict sharply and must be reconciled before prioritization: the supplied CVSS 3.1 base score of 8.8 (AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H) and the 'Authentication Bypass' tag imply full compromise, while the authoritative assessed vector AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N describes only a confidentiality impact with mandatory user interaction. As assessed, an unauthenticated remote attacker can obtain sensitive information from Google Chrome desktop builds prior to 155.0.8059.39 when a victim opens a crafted HTML page, with no integrity or availability impact and no authenticated-session or special-configuration prerequisite in the product itself. There is no CISA KEV listing and no public exploit code identified at time of analysis, Chromium rates the underlying issue Low severity, and the vendor-released patch is Chrome 155.0.8059.39.
Information disclosure in the Permissions component of Google Chrome before 155.0.8059.39 allows a remote, unauthenticated attacker to bypass the browser's site-isolation boundary by luring a victim into loading a crafted HTML page. Exploitation requires user interaction (UI:R) - the target must visit attacker-controlled content - and the resulting impact is limited to leaking information across origins rather than code execution, data modification, or denial of service. A vendor fix is already available in 155.0.8059.39, there is no confirmed active exploitation (no CISA KEV listing) and no public exploit code identified at time of analysis, and EPSS is 0.18% (7th percentile), indicating a low near-term exploitation likelihood.
Type confusion in the V8 JavaScript engine of Google Chrome before 155.0.8059.39 allows a remote attacker to execute arbitrary code inside the renderer sandbox when a victim renders a crafted HTML page, requiring user interaction (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H, 8.8). Signals conflict and must be weighed carefully: the numeric severity is high, yet Google's own Chromium security severity for this issue is 'Low' and CISA's SSVC assessment records no exploitation and a non-automatable attack path, with no public exploit identified at time of analysis. A vendor-released patch exists in Chrome 155.0.8059.39, so fully updated installations are not exposed.
Information disclosure in Google Chrome for Android (versions prior to 155.0.8059.39) allows remote, unauthenticated attackers to reach sensitive data held by the browser's Autofill feature via a crafted HTML page, with the flaw rooted in incorrect authorization (CWE-863) in the Autofill path. Per the assessed vector (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N), exploitation requires the victim to actively navigate to the attacker's page and the impact is confined to confidentiality, with no integrity or availability effect; the vendor-supplied 8.8 score (C:H/I:H/A:H) and the 'Low' Chromium severity conflict with this assessment and should be reconciled before prioritization. Chrome on Android is the affected build, no public exploit was identified at time of analysis, and a vendor-released patch (155.0.8059.39) is available.
Origin policy bypass in Google Chrome for Android prior to 155.0.8059.39 lets a remote attacker acting through a confused deputy have actions carried out under a different web origin's authority, so a victim who is socially engineered into opening a crafted HTML page can have that page reach resources or capabilities it should never hold for its own origin. Only Chrome on Android is affected, exploitation is not silent (it requires the user to open attacker-supplied content, CVSS PR:N/UI:R), and no public exploit code or active exploitation has been identified at time of analysis; EPSS is 0.22% (12th percentile), and Google rates the underlying Chromium bug as Low severity. Note the sharp signal conflict that must be reconciled before prioritization: the nominal vendor CVSS is 8.3 while EPSS, vendor severity, and our independent assessment (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:L/A:N) all point to materially lower real-world risk.
Integer overflow in the Media component of Google Chrome (all versions prior to 155.0.8059.39) allows a remote, unauthenticated attacker to corrupt memory via a crafted HTML page containing specially formed media content, with the potential to execute arbitrary code outside the browser sandbox. Exploitation is not automatic: the CVSS vector (UI:R) confirms the victim must actively load the attacker-controlled or compromised page, and Google rated this a Chromium severity of 'Low', indicating the sandbox-escape outcome is not reliably achievable and probably depends on specific memory conditions or combining this primitive with others. No public exploit code and no CISA KEV entry were identified at time of analysis; the 9.6 score reflects the scope-change metric (S:C) and high C/I/A impact rather than proven real-world exploitation, so the practical risk is lower than the headline score suggests.
Information disclosure in the Passwords component of Google Chrome desktop builds prior to 155.0.8059.39 lets a remote, unauthenticated attacker obtain sensitive data when a victim renders a crafted HTML page. The vendor rates the issue Chromium security severity Low, and the independent assessment converges on a limited-confidentiality impact (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N) rather than the 8.8 figure carried in some feeds, so the mandatory user interaction and the low-confidentiality scope are the real risk drivers. There is no public exploit identified at time of analysis, and a vendor patch is already shipping in the stable channel as 155.0.8059.39.
Sandbox escape in Google Chrome before 155.0.8059.39 via a heap-based buffer overflow (CWE-122) in ANGLE, Chrome's graphics translation layer: a remote attacker who has already compromised a sandboxed renderer process can use a crafted HTML page to execute arbitrary code outside the sandbox. It is a second-stage primitive rather than an initial-access bug - the assessed vector CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H (8.3) reflects high attack complexity, a required pre-existing renderer exploit chain, and active user interaction (UI:R), with the scope change S:C capturing the crossing of the sandbox boundary, even though Chromium rates the underlying bug Low severity. No public exploit code was identified at time of analysis and CISA's SSVC data records no observed exploitation, so the headline 8.3 should be weighed against the significant preconditions.
Code execution outside the Chrome sandbox on Windows is possible through CVE-2026-106186, an uncontrolled search path flaw in Chrome's CredentialProvider component affecting Chrome builds prior to 155.0.8059.39. The issue is local-only (CVSS:3.1/AV:L) and requires both a pre-existing local foothold with write access to a directory the component searches and user interaction to load the affected program, yet because the credential provider loads in a more privileged Windows context the scope changes (S:C) and confidentiality, integrity, and availability impacts are all High, yielding a base score of 8.6 with no privileges required (PR:N). No public exploit code has been identified at time of analysis and the issue is not listed in CISA KEV; SSVC rates exploitation as 'none' and automatable as 'no', and Chromium's own internal severity rating is 'Low', which sharply tempers the headline CVSS figure. A vendor patch is available as Chrome 155.0.8059.39.
Site isolation bypass in Google Chrome for Android (versions prior to 155.0.8059.39) lets an attacker who has already compromised the renderer process cross the per-site process boundary and reach data that should remain isolated to other origins, triggered when the victim loads a crafted HTML page. It is a second-stage flaw rather than an initial-access vector: exploitation is gated on a separate, pre-existing renderer compromise plus required user interaction (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N), which is why the vendor assigned a Chromium severity of Low even though the base score is 8.2. No public exploit identified at time of analysis, no CISA KEV listing, and EPSS is only 0.21% (11th percentile); a vendor patch is available, so the residual risk is concentrated in unpatched Android clients that are simultaneously exposed to a first-stage renderer exploit.
Arbitrary code execution confined to Chrome's renderer sandbox is possible in Google Chrome versions prior to 155.0.8059.39, where an incorrect comparison in the font rendering pipeline can be triggered by a crafted HTML page. This is an unauthenticated remote attack (AV:N/PR:N) that requires the victim to load attacker-controlled web content (UI:R); the resulting code execution stays inside the renderer sandbox (S:U), and escaping to the host operating system requires a separate, unrelated sandbox-escape vulnerability - which is why Chromium assigned a Low security severity despite the CVSS 8.8 base score. No public exploit code was identified at time of analysis, and a vendor-released patch (155.0.8059.39) is available.
Incorrect authorization in the Selection component of Google Chrome for iOS lets a remote, unauthenticated attacker obtain sensitive information when a victim opens a crafted HTML page, and the issue is resolved in Chrome 155.0.8059.39. Only the iOS build of Chrome below that version is in scope; desktop and Android builds are not named as affected, and exploitation requires the user to actively visit the attacker-controlled page (UI:R per the assessed vector). No public exploit code has been identified at time of analysis and the issue is not in CISA KEV, so the practical risk is bounded by mandatory user interaction, the narrow iOS-only affected population, and the fact that a vendor fix already ships; note that the supplied base score of 8.8 (C:H/I:H/A:H) is inconsistent with both the Chromium 'Low' severity label and the assessed vector, which rates impact as confidentiality-only.
Missing authorization in the Actor component of Google Chrome prior to 155.0.8059.39 allows code to escape the browser sandbox, but only after the attacker has already compromised the renderer process via a separate bug and then gets the victim to load a crafted HTML page. This prerequisite, combined with required user interaction (UI:R) and high attack complexity (AC:H) from the assessed CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H vector, means the flaw is only usable as a link in an exploit chain rather than as a standalone initial-access vector; the changed scope (S:C) and high confidentiality, integrity and availability impact reflect the potential for full code execution outside the sandbox. No public exploit code identified at time of analysis and there is no confirmed actively exploited (CISA KEV) status, so risk should be weighed against the conflicting 8.3 score versus the demanding exploitation preconditions. A vendor patch is available in Chrome 155.0.8059.39.
Arbitrary code execution outside the browser sandbox is possible in Google Chrome on macOS prior to 155.0.8059.39, where incorrect reference resolution in the WebAppInstalls component allows crafted network traffic to cross a process trust boundary. Exploitation is not standalone: the attacker must already have compromised the Chrome renderer process, which makes this a second-stage sandbox-escape primitive in a larger exploit chain rather than a directly reachable remote compromise, and the assessed vector (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H) reflects that non-trivial precondition. A vendor-released patch (Chrome 155.0.8059.39) is available, and no public exploit code was identified at the time of analysis.
Type confusion in V8, Chrome's default JavaScript and WebAssembly engine, enables a remote attacker to run arbitrary code inside the browser's renderer sandbox in Google Chrome releases below 155.0.8059.39. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H, 8.8) confirms the attack is network-reachable and requires no authentication, though it does require the victim to open attacker-controlled web content, so a phishing, malvertising, or watering-hole lure is a prerequisite. No public exploit code has been identified at time of analysis and CISA's SSVC assessment records exploitation as 'none' and the issue as not automatable, so real-world priority currently sits below what the 8.8 base score alone implies; note that code execution is confined to the renderer sandbox, meaning full host compromise would require chaining a separate sandbox-escape flaw. Google has shipped a vendor patch.
Incorrect authorization in the Google Chrome user-interface layer allows a crafted HTML page to escape the renderer sandbox and execute arbitrary code outside it on all Chrome builds prior to 155.0.8059.39. Exploitation requires the victim to open an attacker-supplied page (UI:R in the assessed vector) and, while no authentication is required (PR:N) and no unusual configuration is needed, the attack is not fully remote - it depends on that user action, which is the main limiting factor. Severity signals are mixed: the assessed CVSS vector scores 9.6 with scope change (S:C) and high confidentiality, integrity and availability impact, yet Google rates the underlying Chromium issue as Medium, and no public exploit code or confirmed active exploitation (CISA KEV) has been identified at time of analysis.
Arbitrary code execution inside the Chrome renderer sandbox is possible in Google Chrome builds prior to 155.0.8059.39, where a race condition (CWE-367) in the V8 JavaScript engine can be won by a crafted HTML page. Exploitation requires only that the victim load the attacker's page in a vulnerable browser (UI:R, PR:N per the CVSS vector), with no credentials or prior privileges needed, but success additionally depends on hitting a time-of-check/time-of-use timing window, which our assessment captures by raising attack complexity to High (CVSS 3.1 base 8.1 under AC:H, versus the 8.8 score supplied with the CVE under AC:L). The critical caveat is scope: the code execution achieved stays within the renderer sandbox and does not by itself compromise the host operating system, so full system impact requires chaining a separate sandbox-escape vulnerability. No public exploit code has been identified at time of analysis, CISA SSVC records Exploitation: none (Automatable: no, Technical Impact: total), and a vendor-released patch exists in Chrome 155.0.8059.39.
Incorrect authorization in Google Chrome's WebProtect component lets a remote, unauthenticated attacker who socially engineers a victim into opening a crafted HTML page read sensitive information held in the browser context - the assessed impact is confidentiality-only (C:H/I:N/A:N), with no integrity or availability loss. Every Chrome build prior to 155.0.8059.39 is affected across platforms, and Google rates the underlying issue as Chromium security severity Medium. Exploitation is not drive-by: the CVSS vector requires user interaction (UI:R) and PR:N, so no credentials or non-default configuration are needed but the victim must be lured to the attacker-controlled page, and no public exploit code has been identified at time of analysis, making the base score of 8.8 an overstatement of realistic risk.
An out-of-bounds write in the Media component of Google Chrome before 155.0.8059.39 lets a remote attacker corrupt memory and potentially achieve arbitrary code execution outside the browser sandbox when a victim opens an attacker-crafted HTML page containing malicious media content. The attack is fully remote and requires no authentication (CVSS:3.1/AV:N/AC:L/PR:N), but it is gated by user interaction (UI:R) - the victim must visit the malicious or compromised page - and the 'outside the sandbox' outcome implies defeating Chrome's process sandbox, which is materially harder in practice than the 9.6 base score suggests. No public exploit code or confirmed active exploitation was identified at time of analysis, and the vendor has released a fixed build.
Site isolation bypass in Google Chrome affects versions prior to 155.0.8059.39, where a missing authorization check (CWE-862) in the browser's Workers implementation lets an attacker who has already compromised a renderer process cross the site-isolation boundary using a crafted PDF file. The attack is remote (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N, score 8.1), but exploitation is gated on a pre-existing renderer foothold obtained through a separate vulnerability, so this is a chained sandbox/site-isolation escape rather than a standalone remote compromise. There is no public exploit identified at time of analysis and no CISA KEV listing; EPSS is low at 0.17% (5th percentile), and CISA SSVC rates exploitation as 'none' with automation as 'no', while acknowledging total technical impact if the chain is completed. A vendor patch is available in Chrome 155.0.8059.39.
Incorrect authorization in Google Chrome's Autofill feature (versions prior to 155.0.8059.39) allows an unauthenticated remote attacker (PR:N) to obtain sensitive information via a crafted HTML page, but exploitation requires social engineering to trick the victim into visiting and interacting with the page (UI:R). The independent assessment limits the impact to confidentiality (C:L) with no integrity or availability effect, and exploitation further depends on the victim having relevant data stored in Autofill; no public exploit or active exploitation has been identified. A vendor patch is available.
Incomplete cleanup in Dawn, Chrome's WebGPU implementation, allows a crafted HTML page to potentially corrupt GPU-process state and achieve code execution outside the browser sandbox in Google Chrome builds prior to 155.0.8059.39. Exploitation requires the victim to render attacker-controlled content that reaches the affected WebGPU/Dawn code path (CVSS UI:R with PR:N - unauthenticated remote attackers, but user interaction required), and the outcome is probabilistic rather than a guaranteed silent drive-by; the published base score is 9.6 while Google rates the issue Medium, and our assessed vector raises attack complexity to AC:H to reflect the difficulty of chaining a cleanup flaw into a reliable sandbox escape. No public exploit code has been identified at time of analysis, and Google has released Chrome 155.0.8059.39 as the fix.
Heap-based buffer overflow in Google Chrome's font-handling code (CWE-122) lets an attacker who has already compromised the renderer process execute arbitrary code outside the sandbox when a victim renders a crafted HTML page containing malicious font data. All Chrome builds prior to 155.0.8059.39 on default configurations are affected; exploitation is unauthenticated (PR:N) but requires user interaction (UI:R) and a pre-existing renderer compromise, so it functions as a sandbox-escape chain component rather than a standalone drive-by, and is rated high complexity (AC:H) despite a CVSS base of 8.3 (S:C). No public exploit code has been identified at time of analysis and CISA's SSVC assessment records no exploitation, but the vendor has shipped a fix in 155.0.8059.39.
Confused-deputy bypass in Google Chrome's Contextual Tasks feature allows a remote attacker who already holds renderer code execution to cross a security boundary into a privileged page by loading a crafted HTML page, with high confidentiality and integrity impact (unauthenticated per the CVSS vector, but requiring user interaction). The flaw affects Chrome builds prior to 155.0.8059.39 and functions primarily as a chain link - the prerequisite renderer compromise from a separate bug is the real gate, which sharply narrows standalone risk despite the 8.1 score. No public exploit code has been identified at time of analysis and EPSS is very low at 0.18% (7th percentile), with CISA SSVC recording no observed exploitation; a vendor-released patch exists in 155.0.8059.39.
Use-after-free in Chrome's font handling on Windows allows a remote attacker to execute arbitrary code inside the renderer sandbox when a victim opens a crafted HTML page; the flaw affects Google Chrome versions prior to 155.0.8059.39. Exploitation requires user interaction (UI:R) - the victim must load attacker-controlled content - and there are no authentication prerequisites (PR:N), but the resulting code execution is confined to the Chrome sandbox, so host-level compromise would require a second, independent sandbox-escape bug. Consistent with the medium severity rating assigned by the Chromium team, CISA's SSVC assessment records no known exploitation and no automatable exploitation path, and no public exploit code has been identified at time of analysis.
Site isolation bypass in Google Chrome versions earlier than 155.0.8059.39 lets a remote attacker who has already compromised a renderer process escape Chrome's process boundary and reach data or privileged accessibility functionality belonging to other origins by way of a crafted HTML page the victim loads. The flaw is an incorrect-authorization bug (CWE-863) in the browser's Accessibility component, making it a chained, second-stage primitive rather than a standalone remote compromise, which is why the assessed vector uses AC:H (AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N) despite an underlying base score of 8.1. Google has released a vendor patch in 155.0.8059.39; no public exploit code and no confirmed active exploitation were identified at time of analysis (EPSS 0.18%, CISA SSVC exploitation: none, automatable: no), so the risk is real but is not currently a frontline emergency.
Arbitrary code execution outside Chrome's sandbox on Android affects Google Chrome builds prior to 155.0.8059.39, where a missing authorization check (CWE-862) can be abused by a malicious co-installed Android app. The attack is local - it requires an attacker-controlled app to already be present on the same device plus successful social engineering to get the victim to install it and trigger the action - so a default, lone Chrome installation is not directly exploitable. Google rates this Chromium security severity Medium, the vendor CVSS is 8.4 (AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) while our assessment substitutes UI:R, no publicly available exploit code or confirmed active exploitation has been identified at time of analysis, and EPSS is only 0.12% (2nd percentile).
Site isolation bypass in Google Chrome on Android (prior to 155.0.8059.39) allows an attacker who has already compromised the renderer process to reach the browser's Passwords component via a crafted HTML page and a missing authorization check, exposing stored credential data. The bug is a chained, second-stage issue: it cannot be triggered by an unprivileged remote attacker without pre-existing renderer code execution, and it requires user interaction to load the crafted page, which is why the assessed vector (AV:N/AC:H/PR:L/UI:R/C:H/I:N/A:N) makes realistic risk LOW despite the 8.1 base score. No public exploit identified at time of analysis, EPSS is only 0.21% (11th percentile), CISA SSVC records Exploitation: none, and Google rated the Chromium security severity Medium, so this is a routine patch-cycle fix rather than an emergency.
Sensitive-information disclosure in Google Chrome for iOS before 155.0.8059.39 allows a remote, unauthenticated attacker to abuse a missing authorization check by socially engineering a victim into opening a crafted HTML page. The independent assessment limits the impact to confidentiality (C:H/I:N/A:N), so this should be treated as an information disclosure issue rather than code execution or data tampering, and exploitation requires user interaction on the iOS build only. Vendor patch 155.0.8059.39 is available, and no public exploit code or CISA KEV active exploitation was identified in the supplied intelligence.
Sandbox escape and potential arbitrary code execution outside the browser sandbox in Google Chrome via a confused-deputy flaw in the Google Lens feature, affecting all desktop releases prior to 155.0.8059.39. Exploitation is not standalone: a remote attacker must first have compromised the Chrome renderer process (a separate renderer-stage bug), then convince the victim to load a crafted HTML page, after which the Lens component can be induced to perform a privileged operation that crosses the sandbox boundary on the renderer's behalf - consistent with the CVSS:3.1 vector AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H and high attack complexity. No public exploit code has been identified at time of analysis and there is no confirmed active exploitation (CISA KEV absent, SSVC exploitation: none), but the maximum technical impact rating means the issue is worth prioritizing within normal patch cycles; vendor-released patch: 155.0.8059.39.
Race condition in the V8 JavaScript engine allows remote code execution inside the browser sandbox in Google Chrome builds prior to 155.0.8059.39. A remote, unauthenticated attacker can trigger the flaw by getting a victim to open attacker-supplied HTML that drives V8 into the timing window (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H) - the required user interaction is the only precondition, and code execution is confined to the renderer/V8 sandbox, so host compromise would require a second, separate sandbox-escape bug. Google has shipped a fixed stable-channel build, and no public exploit code or confirmed active exploitation was identified at time of analysis (CISA SSVC records Exploitation: none; no KEV listing or PoC in the available sources).
Remote attackers can bypass system access restrictions and reach a privileged internal page in Google Chrome for Android versions prior to 155.0.8059.39 by way of a confused-deputy weakness in the SignIn component, which performs privileged navigation on behalf of an untrusted caller. Exploitation requires the victim to load attacker-controlled crafted HTML (for example, visiting a malicious or compromised page), needs no authentication or prior privileges, and is limited to the Android build on pre-patch versions. No public exploit code has been identified at time of analysis, EPSS is low at 0.22% (12th percentile), and the issue is not confirmed as actively exploited; a vendor patch (155.0.8059.39) is available, so this is a moderate-priority patch-and-move-on item rather than an emergency.
Sandbox escape in Google Chrome on iOS (versions prior to 155.0.8059.39) allows a local attacker who has already compromised the renderer process to execute arbitrary code outside the browser sandbox via a local program. The flaw is an incorrect reference resolution (CWE-706) in the Passwords component, rated Medium by Chromium and carrying a CVSS 7.4 (AV:L/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H). No public exploit code or confirmed active exploitation has been identified at time of analysis; a vendor patch is available.
Information disclosure in Google Chrome's Autofill component lets a remote, unauthenticated attacker read sensitive data by luring a victim to a crafted HTML page on any Chrome build prior to 155.0.8059.39. Exploitation requires user interaction (UI:R) - the victim must actually navigate to the attacker's page - which is the primary limiting factor, and no non-default configuration or privileges are needed since Autofill is enabled by default. The independent assessment scopes impact to confidentiality only (C:H/I:N/A:N), while the supplied vector additionally claims high integrity and availability impact; no public exploit code and no confirmed active exploitation have been identified at time of analysis, and vendor-patched builds are available.
Cross-origin data disclosure in Google Chrome (all versions prior to 155.0.8059.39) stems from a missing authorization check in the browser's FileSystem component, allowing a crafted HTML page to breach the web origin boundary and read data it should not reach. Exploitation is strictly a second-stage condition: an attacker must first have already compromised Chrome's renderer process through a separate flaw, and the victim must load attacker-controlled content (UI:R), so a default, fully patched Chrome with an intact renderer sandbox is not directly exploitable - a limitation that makes real-world risk moderate despite the 8.2 base score, and is reflected in the low EPSS of 0.22% (12th percentile). Google has shipped a fix in Chrome 155.0.8059.39, there is no confirmed active exploitation (CISA KEV) and no public exploit identified at time of analysis.
Sandbox escape in Google Chrome on macOS, affecting releases prior to 155.0.8059.39, allows an attacker who has already compromised the browser's renderer process to execute arbitrary code outside the sandbox when the victim views a crafted HTML page. The CVSS 3.1 vector (AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H, base 8.3) confirms a network-reachable, scope-changing escape that requires user interaction and carries high confidentiality, integrity and availability impact once triggered, but the AC:H rating and CISA SSVC 'Automatable: no' reflect that it cannot be used standalone - a prior renderer compromise is a hard prerequisite. Per the authoritative assessment this is a chained second-stage exploit limited to macOS; no public exploit code and no confirmed active exploitation were identified at time of analysis.
Improper input validation in the Mobile component of Google Chrome on iOS allows a remote attacker to potentially execute arbitrary code outside the browser sandbox when a victim is socially engineered into opening a crafted HTML page, fixed in Chrome 155.0.8059.39. Successful exploitation requires user interaction (CVSS vector PR:N/UI:R with S:C), meaning the attack hinges on phishing or a malicious link rather than a zero-click path, and the scope change reflects the assessed ability to escape the sandbox boundary. No public exploit code has been identified at time of analysis and the issue is not a confirmed actively exploited (CISA KEV) vulnerability, but the 9.6 CVSS score and the RCE tag make prompt patching of older mobile Chrome installations the priority.
Web origin policy bypass in Google Chrome's Navigation component on iOS allows a remote, unauthenticated attacker to escape intended origin boundaries and reach a privileged page when a victim opens a crafted HTML page. Exploitation is constrained by two factors: the mandatory user interaction (CVSS UI:R - the victim must actively load the malicious page) and the narrow platform scope, since only the iOS build of Chrome is affected rather than Chrome on other operating systems. Risk signals are modest - EPSS is 0.22% (12th percentile), there is no CISA KEV listing, and no public exploit code has been identified at time of analysis - and Google has shipped a fix, so this is a moderate-priority issue rather than an urgent one.
A use-after-free memory-safety flaw in Google Chrome's Media component lets a remote, unauthenticated attacker execute arbitrary code inside the renderer sandbox when a user loads a crafted HTML page containing malicious media content. All Chrome builds prior to 155.0.8059.39 are affected, and exploitation requires the victim to visit or load the attacker-controlled page (UI:R), which is the main practical barrier; no credentials or special privileges are needed. There is no public exploit identified at time of analysis and the CISA SSVC assessment records no exploitation, but the vendor has shipped a fix in 155.0.8059.39, and the EPSS-style risk picture is dominated by Chrome's ubiquity and the high CVSS base score (8.8) rather than by observed attacks.
Code injection in the Reader Mode feature of Google Chrome on iOS (versions prior to 155.0.8059.39) lets a remote, unauthenticated attacker bypass the web origin policy by convincing a victim to open a crafted HTML page in the browser. The flaw is confined to the iOS build and depends on social engineering to drive the victim to the malicious page, so effective user interaction is required; impact is limited to a partial confidentiality, integrity and availability loss through origin-policy circumvention rather than full system compromise. No public exploit code has been identified at time of analysis, EPSS is a low 0.27% (17th percentile), and the issue is not listed in CISA KEV, so despite the 7.3 High CVSS the real-world priority is low-to-moderate. Google has shipped a vendor patch, fixed in Chrome 155.0.8059.39.
System access restriction bypass in Google Chrome versions prior to 155.0.8059.39 allows a remote attacker to break out of the browser's security boundary through the FullScreen component, but only after having already compromised the Chrome renderer process and only with successful social engineering to make the victim interact with a crafted HTML page. Because it is a chain component rather than a standalone bug, exploitation requires a pre-existing renderer foothold plus mandatory user interaction (UI:R) and carries high attack complexity (AC:H), so it is not exploitable against a fully patched default browser on its own. No KEV listing and no publicly available exploit code have been identified at time of analysis, and EPSS is low at 0.22% (12th percentile), consistent with the conditional nature of the flaw despite the 8.3 CVSS base score and a Chromium security severity rating of Medium.
Google Chrome builds prior to 155.0.8059.39 contain a missing authorization check in the Autofill component that allows a remote attacker to read sensitive information in the browser's stored autofill data. Exploitation is not silent: it requires the victim to be socially engineered into opening an attacker-crafted HTML page (CVSS UI:R, PR:N), and the SSVC assessment records Exploitation=none and Automatable=no, meaning this cannot be triggered at scale or without user action. Our independent assessment rates the impact as confidentiality-only (C:H/I:N/A:N), so real-world risk is MODERATE and meaningfully lower than the headline CVSS 8.8 suggests; no public exploit code has been identified at time of analysis and the issue is not in CISA KEV, though a vendor patch is available.
Incorrect authorization in the Search component of Google Chrome for Android before 155.0.8059.39 can allow a remote, unauthenticated attacker to execute arbitrary code outside the browser sandbox when a victim is socially engineered into opening a crafted HTML page. The vendor-rated Chromium severity is Medium, yet the assessed CVSS is 9.6 (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H) because the flaw crosses a security boundary (scope changed) with high confidentiality, integrity and availability impact. The risk signals conflict and must be weighed carefully: the impact score is severe, but exploitation requires a click of user interaction, is confined to Android builds (desktop Chrome is unaffected), and no public exploit code or confirmed active exploitation has been identified at the time of analysis. Vendor patches are available.
Sensitive information disclosure in Google Chrome builds prior to 155.0.8059.39 lets an unauthenticated remote attacker obtain data through the browser's Bluetooth handling by convincing a victim to open a crafted HTML page (CVSS 3.1 AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N per the independent assessment). The root cause is an incorrect authorization check (CWE-863) in the Web Bluetooth code path, so exploitation is limited to an information leak rather than code execution; the mandatory UI:R requirement means this is not a no-interaction drive-by, and the victim must be running a vulnerable Chrome version that reaches the affected Bluetooth logic. No public exploit identified at time of analysis, and the issue is not confirmed actively exploited (no CISA KEV entry), although the vendor-rated 8.8 score conflicts with the assessed confidentiality-only vector and should be weighed as a severity signal rather than proof of integrity or availability impact. Vendor-released patch: 155.0.8059.39.
Use-after-free in Google Chrome's garbage-collection code before 155.0.8059.39 allows an unauthenticated remote attacker to corrupt memory and execute arbitrary code inside the renderer sandbox when a victim loads a crafted HTML page. Exploitation requires user interaction (PR:N, UI:R) and the code execution stays contained in the browser sandbox, so OS-level compromise would require chaining a separate sandbox-escape flaw; no public exploit identified at time of analysis, and CISA's SSVC assessment records exploitation as 'none' and automatable as 'no', which tempers the high 8.8 CVSS base score. Vendor-released patch: 155.0.8059.39, distributed through Chrome's stable channel.
Use-after-free in the Streaming component of Google Chrome prior to 155.0.8059.39 allows unauthenticated remote attackers to execute arbitrary code inside the renderer sandbox when a victim is socially engineered into loading a crafted HTML page, consistent with the CVSS vector AV:N/AC:L/PR:N/UI:R. Google rates the issue Medium severity (Chromium) while the CVSS base score is 8.8, reflecting high confidentiality, integrity, and availability impact on the renderer process rather than the host. There is no CISA KEV listing and no public exploit identified at time of analysis, and the SSVC assessment records exploitation as none; the primary containment is Chrome's process sandbox, so full host compromise would require chaining a separate sandbox-escape flaw.
Sandbox escape in Google Chrome's WebAppInstalls component allows a remote attacker who has already compromised the renderer process to execute arbitrary code outside the browser sandbox when a victim visits a crafted HTML page and is socially engineered into interacting with the web app installation flow. The flaw is a missing authorization check (CWE-862) affecting Chrome versions prior to 155.0.8059.39; the technical impact is total, but the vendor rates it Medium because exploitation requires a prior renderer compromise, deliberate user interaction (UI:R), and high attack complexity (AC:H) rather than a default-configuration remote hit. No public exploit code and no confirmed active exploitation have been identified at time of analysis (CISA SSVC Exploitation: none, Automatable: no).
Incorrect reference resolution in Google Chrome on macOS before 155.0.8059.39 can disclose sensitive information to a remote attacker who uses social engineering to make the victim load a crafted HTML page. Exploitation requires a macOS user running an affected Chrome build who actively opens attacker-supplied content (UI:R), with no authentication required (PR:N) and network-delivered payloads (AV:N); there is no confirmed active exploitation and no public exploit code identified at time of analysis, and the only data supplied is a vendor patch and a Chromium issue. The signals conflict sharply: the headline CVSS of 8.8 (C:H/I:H/A:H) is not supported by the available evidence, and the assessed vector is confidentiality-only (AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N, roughly 6.5 Medium), matching Chromium's own 'Medium' severity label, so real-world priority is lower than the 8.8 figure implies.
Use-after-free in Google Chrome allows unauthenticated remote attackers to execute arbitrary code within the renderer sandbox by convincing a victim to load a crafted HTML page, affecting all versions prior to 155.0.8059.39. The attack requires user interaction (UI:R) but no authentication or special configuration, and while code execution is confined to the sandbox, the CVSS 3.1 score is 8.8. No public exploit or active exploitation has been identified, and a vendor patch is available.
A sandbox escape in Google Chrome before 155.0.8059.39 lets an attacker who has already compromised the browser's renderer process trigger a race condition in Chrome's font handling and execute arbitrary code outside the sandbox, via a crafted HTML page the victim must load (CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H, score 8.3). The prerequisite is significant: a separate, prior renderer compromise is required, and AC:H reflects the non-deterministic nature of winning the race, so this is a chained post-exploitation primitive rather than a standalone drive-by. Unauthenticated from a network perspective, with UI:R meaning the target must open attacker-controlled content; no CISA KEV entry, no public exploit code identified at time of analysis, and CISA's SSVC assessment rates exploitation as none and automatable as no, though technical impact is total once the race is won. Vendor-released patch: 155.0.8059.39.
Use-after-free in Google Chrome's Track component before 155.0.8059.39 allows an unauthenticated remote attacker to execute arbitrary code inside the renderer sandbox when a victim loads a crafted HTML page. The CVSS 3.1 base score is 8.8 (High) with UI:R, meaning exploitation requires user interaction but no authentication; successful code execution remains confined to Chrome's renderer sandbox and would require a separate sandbox-escape bug to affect the host OS. No public exploit identified at time of analysis, and SSVC records Exploitation: none; CISA KEV does not list this CVE.
Use-after-free in Google Chrome's built-in PDF handling (fixed in 155.0.8059.39) lets remote, unauthenticated attackers execute arbitrary code inside the Chrome renderer sandbox when a victim opens a crafted PDF file - exploitation is not automatic and depends entirely on the user interaction of opening the document (CVSS 8.8, AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H, CWE-416). Because the code execution is confined to the sandboxed renderer, turning this into full host compromise would require chaining a separate sandbox-escape bug; the advisory rates it Chromium severity High. At the time of analysis there is no public exploit identified and CISA SSVC records exploitation as none, though the vulnerability is fully described and a vendor patch plus the underlying Chromium issue tracker entry are publicly referenced. Google Chrome versions before 155.0.8059.39 are affected on all platforms tracked under cpe:2.3:a:google:chrome.
Google Chrome builds prior to 155.0.8059.39 contain a use-after-free in PDF handling that allows a remote, unauthenticated attacker to execute arbitrary code inside the browser's renderer sandbox when a victim loads a crafted HTML page that embeds a malicious PDF. Exploitation requires the user to open attacker-controlled web content processed by Chrome's built-in PDF (PDFium) viewer - a mandatory interaction step (CVSS UI:R) with no zero-click vector, and any code execution is confined to the sandboxed renderer unless chained with a separate sandbox escape. There is no public exploit identified at time of analysis, SSVC records no observed exploitation and rates the issue not automatable, but technical impact is rated total given high confidentiality, integrity, and availability impact; a vendor patch exists in 155.0.8059.39.
Use-after-free in Google Chrome's V8 JavaScript engine (all releases prior to 155.0.8059.39) lets unauthenticated remote attackers execute arbitrary code inside the renderer sandbox when a victim navigates to an attacker-controlled page containing crafted HTML/JavaScript. The bug carries a CVSS v3.1 base score of 8.8 (AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H) and Chromium's own 'High' severity rating, and because the V8 engine is enabled by default in every standard installation, no special configuration or privileges are needed on the target side. Impact is bounded, however: per the vendor description code execution is confined to the sandbox, so a standalone exploit does not by itself compromise the host and a separate sandbox-escape would be required, and no public exploit identified at time of analysis (SSVC Exploitation: none, Automatable: no) - a genuine priority-worthy issue whose urgency is tempered by the required user interaction, sandbox confinement, and absence of observed exploitation.
Use-after-free in the Media component of Google Chrome prior to 155.0.8059.39 lets a remote attacker execute arbitrary code within the browser's renderer sandbox by luring a victim to open a crafted HTML page. The flaw carries a CVSS v3.1 base score of 8.8 (AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H), meaning no authentication or prior privileges are required, but successful exploitation depends on the user actively navigating to attacker-controlled content. There is no public exploit identified at time of analysis - CISA's SSVC assessment lists exploitation as 'none' - and code execution is contained within the renderer sandbox, so a separate sandbox-escape would be needed to reach the host OS; the vendor has released a patched build.
Type confusion in the V8 JavaScript engine of Google Chrome prior to 155.0.8059.39 lets a remote, unauthenticated attacker execute arbitrary code inside the browser's renderer sandbox when a victim loads a crafted HTML page; the CVSS vector is AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H, so the sole prerequisite is that the victim renders attacker-controlled content in an unpatched desktop build. No public exploit code or active exploitation was identified at time of analysis, and CISA KEV does not list this CVE. The vendor-released patch is Chrome 155.0.8059.39, and installations already updated past that version are not affected. Because the impact is scoped to the sandbox (S:U) per the description, full host compromise would require chaining a separate sandbox-escape vulnerability.
Google Chrome versions prior to 155.0.8059.39 contain a use-after-free in the WebRTC component that a remote, unauthenticated attacker can trigger by convincing a victim to visit a crafted HTML page, resulting in arbitrary code execution within the renderer sandbox (CVSS 3.1 base 8.8, AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H). Exploitation is not automatable and requires user interaction, and the resulting code execution is confined to Chrome's renderer sandbox per the vendor description, so full host compromise would additionally require chaining a separate sandbox-escape flaw. No public exploit code has been identified at time of analysis, and CISA's SSVC assessment records no known exploitation; Chrome's built-in auto-update is the primary exposure-reduction control, as patched versions 155.0.8059.39 and later are not vulnerable.
Arbitrary code execution inside the renderer sandbox is achievable in Google Chrome builds prior to 155.0.8059.39, where a use-after-free in the browser's Media component can be triggered when a victim loads a crafted HTML page. Scoring 8.8 under CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H, the bug requires no authentication but does require the user to visit attacker-controlled content, and because the resulting code execution is confined to the renderer sandbox, full host compromise would require chaining a separate sandbox-escape flaw. A vendor patch is available in the Chrome Stable channel update, and no public exploit has been identified at time of analysis - this is a high-priority patching item rather than an emergency.
Arbitrary code execution confined to the renderer sandbox in Google Chrome builds prior to 155.0.8059.39, reachable when a user opens a crafted HTML page that drives the DevTools state-validation path into an inconsistent state. The flaw is network-delivered and requires no authentication (CVSS:3.1/AV:N/AC:L/PR:N), but exploitation is gated by mandatory user interaction (UI:R), which is why CISA's SSVC decision framework rates it as not automatable. No public exploit code and no confirmed active exploitation were identified at time of analysis; Google rates the Chromium severity as High and has shipped a fixed build, so the practical exposure is limited to unpatched clients that have not yet received the auto-update.
Use-after-free in Google Chrome's Media component allows a remote attacker to execute arbitrary code inside the browser's renderer sandbox by luring a victim into loading a crafted HTML page in any Chrome build prior to 155.0.8059.39. The flaw is rated CVSS 8.8 (AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H), consistent with Google's own 'High' Chromium security severity, and requires no authentication or privileges on the victim host beyond the user visiting the malicious content (UI:R). Exploitation is confirmed to be constrained by user interaction and by the renderer sandbox - CISA SSVC scores it Exploitation: none, Automatable: no, Technical Impact: total - and there is no public exploit identified at time of analysis, though a vendor-released patch is available.
Use-after-free in Google Chrome's parser allows remote, unauthenticated attackers to execute arbitrary code inside the renderer sandbox by convincing a victim to load a crafted HTML page, affecting all Chrome versions prior to 155.0.8059.39. Exploitation requires user interaction (the victim must visit or open the malicious page), and the resulting code execution is contained by Chrome's renderer sandbox, so full host compromise would require chaining with a separate sandbox-escape vulnerability. A vendor patch is available in 155.0.8059.39, and no public exploit identified at time of analysis, with CISA's SSVC assessment recording exploitation as none.
Remote code execution inside the renderer sandbox is possible in Google Chrome builds prior to 155.0.8059.39, where a use-after-free in the Media component can be triggered by a crafted HTML page. Exploitation requires the victim to load attacker-controlled web content (UI:R) but no authentication or special privileges (PR:N), so default desktop installs are affected; resulting code execution is contained within the renderer sandbox rather than the host operating system. At time of analysis there is no public exploit identified at time of analysis per available intelligence (SSVC exploitation: none, automatable: no), and a vendor patch is available from Google. Rated CVSS 8.8 (AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H) and Chromium security severity High, this is a genuine high-priority patching item, though the signals are mixed on urgency.
A use-after-free in Chrome's Metrics component (CWE-416) lets an attacker who has already compromised a sandboxed renderer process execute arbitrary code outside the sandbox - a sandbox-escape primitive rather than an initial-access bug. Only users running Chrome versions below 155.0.8059.39 are affected; the flaw is unauthenticated from the network perspective (PR:N) but requires the victim to load attacker-controlled crafted HTML (UI:R) and carries High attack complexity (AC:H) because the attacker must win a use-after-free race and defeat sandbox mitigations. Google has released a fix in Chrome 155.0.8059.39, no public exploit code has been identified at time of analysis, CISA SSVC records Exploitation: none, and the overall posture is patch-promptly-but-not-emergency rather than urgent.
OAuth2 token-endpoint misuse in Gitea 28.0.0 and earlier allows anyone holding a valid, unexpired OAuth2 access token to submit it under the refresh_token grant and receive a brand-new access token plus refresh token, effectively extending access past the credential's original expiry. Exploitation requires a pre-existing valid access token issued for the same OAuth2 application and grant, so this is a persistence/escalation-of-lifetime flaw rather than an entry point for an unauthenticated outsider; the assessed vector is CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N (NVD rates it 9.1 with PR:N). Multi-source signals conflict: NVD's score and CISA's SSVC rating of total technical impact are severe, while EPSS is only 0.17% (6th percentile) and SSVC lists exploitation as none - no public exploit code has been identified at time of analysis and the issue is not in CISA KEV.
Path traversal in the Backstage Scaffolder Bitbucket pull-request publish actions allows an authenticated user who can execute an eligible template and influence an allowlisted Bitbucket repository to write files outside the expected working area, potentially compromising backend confidentiality, integrity, and availability. Affected are @backstage/plugin-scaffolder-backend-module-bitbucket-cloud before 0.3.10 and @backstage/plugin-scaffolder-backend-module-bitbucket-server before 0.2.25 (shipped with Backstage before the v1.54.6 release). Exploitation requires an authenticated account with template-execution privileges, control over the contents of a repository already present in the Bitbucket allowlist, and the source-branch creation flow to be exercised, which is why the assessed vector carries high attack complexity (CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H, score 8.5); this is not reachable by an anonymous remote attacker on a default install, and no public exploit code has been identified at time of analysis.
OpenSSH sshd before 10.6 can incorrectly persist GSSAPIAuthentication state across authentication attempts when GSSAPIAuthentication is enabled, allowing a remote, unauthenticated attacker to influence authentication integrity on the same connection. This is a non-default configuration issue: stock OpenSSH deployments without Kerberos/GSSAPI are not affected, and the attacker must drive a sequence of authentication attempts (high attack complexity). No public exploit code has been identified, EPSS is very low (0.08%, 0th percentile), and CISA SSVC reports no exploitation; the vendor has released a fix in OpenSSH 10.6.
Unauthenticated attackers who can reach Gitea's web installer on an instance whose INSTALL_LOCK has been reset to false (or is otherwise unset) can obtain a fully authenticated session for any existing account - including an administrator - simply by submitting the install form with a username that matches that account, with no password verification whatsoever. Full administrative takeover follows, allowing the attacker to change the account's password and control the instance. The bypass only exists while the installer is network-reachable against a database that already contains users; the default hardened post-install state (INSTALL_LOCK=true) is not affected. Independent assessment rates this CVSS 8.1 (AV:N/AC:H/PR:N/UI:N, C:H/I:H/A:H); EPSS is low at 0.16% (4th percentile) and no public exploit code has been identified at time of analysis.
Fork-originated Gitea Actions workflows can run on a base repository's registered runners without the required approval when a repository maintainer performs ordinary pull request triage, such as adding a label, because the approval decision was keyed to the user who triggered the event rather than the fork pull request author, allowing fork-controlled workflow code to execute in the base repository's CI context. Gitea versions up to and including 1.27.3 are affected when Actions is enabled and a matching runner is registered; the issue is fixed in Gitea 28.0.0. No public exploit code was identified at time of analysis and EPSS is low (0.15%, 3rd percentile), but exploitation is not autonomous: the assessed vector (CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:H/I:H/A:H) requires an attacker-submitted fork pull request plus a privileged maintainer action, and CISA SSVC rates the technical impact as total, so the outcome when the prerequisite chain is met is full compromise of confidentiality, integrity, and availability of the workflow execution environment.
Local authenticated attackers who share a writable Java temporary directory with a victim JVM can exploit a time-of-check/time-of-use race in lz4-java 1.7.0 through 1.11.3 to replace the native LZ4 library extracted by net.jpountz.util.Native.load(), potentially executing native code with the victim's privileges. The vulnerability is local-only and requires winning a race against native-library extraction, plus a shared java.io.tmpdir and native binding use; hardened configurations may instead fail loading and fall back to Java implementations. Version 1.11.4 fixes the issue; no public exploit identified at time of analysis.
Code execution in Handlebars.js versions 4.0.0 through 4.7.9 occurs when an application hands an attacker-controllable, pre-parsed AST object - rather than a template string - to Handlebars.compile() or Handlebars.precompile(); the compiler writes JavaScript expressions carried in unchecked AST fields straight into the generated code, which then executes in the server process wherever the compiled output runs. The flaw is an incomplete fix: the AST validation added in 4.7.9 for CVE-2026-33937 covered only PathExpression, NumberLiteral and BooleanLiteral values, leaving fields such as Program.blockParams.length, a non-PathExpression parameter depth, a non-string StringLiteral.value and a non-string PathExpression.original unvalidated. The published CVSS 3.1 vector is AV:N/AC:L/PR:N/UI:N/C:H/I:H/A:H (9.8) and treats this as trivially remote and unauthenticated, but that materially overstates real-world exposure: the vulnerable path is a non-default application design pattern that the vendor explicitly warns against, so applications that compile only template strings - the standard, documented usage - are completely unaffected, and no public exploit code has been identified at time of analysis. Vendor-released patch: 4.7.10.
Server-side remote code execution affects Handlebars versions 4.0.0 through releases prior to 4.7.10, where a flaw in the lookupProperty prototype-access check lets a rendered template reach Function.prototype.constructor and obtain the JavaScript Function constructor, executing attacker-supplied code with the server application's privileges. Exploitation is conditional: an unauthenticated remote attacker must be able to render a template whose source they control, the runtime must have allowProtoMethodsByDefault enabled (not the default configuration), and the template context must expose an accessible function value that can be traversed via __proto__. No public exploit code was identified at time of analysis and the issue is not confirmed as actively exploited (no CISA KEV listing); vendor-released patch: 4.7.10.
Access-control bypass in SSSD lets an already-authenticated user from a trusted identity domain reach hosts and services that Host-Based Access Control (HBAC) rules are supposed to protect. Because SSSD strips the domain qualifier and compares only short usernames during HBAC evaluation, a trusted-domain user whose short name collides with an authorized local account is silently granted that local account's access. Publicly available exploit code exists, but exploitation is not automatable and EPSS is low at 0.28% (18th percentile); exposure is limited to trust-enabled FreeIPA/IdM-style deployments that delegate host access decisions to SSSD.
Authentication bypass in Gitea's built-in SSH server (affected releases up to and including 1.27.3) lets a remote attacker authenticate as another user by presenting a case-variant of that user's registered RSA public key. Three conditions must all hold: the built-in SSH server must be enabled via START_SSH_SERVER = true (non-default on many deployments), the backing database must perform case-insensitive text comparison (the default SQLite qualifies), and the attacker must possess or derive a working RSA private key whose public key differs from the victim's only by letter case, which is cryptographically very hard and is why the effort is assessed as high complexity rather than the low complexity of the published vendor vector. No public exploit code identified at time of analysis; EPSS is 0.16% (4th percentile) and the CISA SSVC assessment records exploitation: none. The flaw is fixed in v28.0.0 by matching keys on their SHA256 fingerprint instead of encoded content.
Authorization bypass in Elasticsearch's Remote Cluster Security (RCS) 2.0 cross-cluster search path lets an authenticated principal holding a cross-cluster API key for one index send a crafted request that is authorized against that permitted index while actually executing against a different, unauthorized index, exposing that index's document contents, field mappings and other metadata, and in limited cases permitting modification of retention-lease state on it. The flaw is an authenticated authorization-boundary bypass (CVSS 7.1, CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N), so the real-world risk is concentrated in multi-tenant or shared clusters that issue cross-cluster API keys to less-trusted tenants, while single-tenant clusters without shared cross-cluster keys are not meaningfully exposed. No public exploit code has been identified at time of analysis.
Incorrect authorization in Elasticsearch 8.x and 9.x allows an authenticated, already-privileged user (CVSS PR:H) who has been granted a non-default, delegated role-management privilege to escalate privileges within a cluster. By abusing a role-definition setting that expands the set of indices matched against a delegated index-scoped privilege, the holder can modify their own assigned role and reach indices that should remain restricted, including internal security data, and from there potentially obtain full administrative control of the cluster. Exploitation is only possible when the cluster has the configurable delegated role-management privilege explicitly enabled and granted with a broadly-scoped index pattern; default deployments that never delegate this capability are not affected. No public exploit code has been identified at time of analysis and the flaw is not confirmed as actively exploited (not in CISA KEV). Vendor-released patches are available in Elasticsearch 8.19.22, 9.4.7, and 9.5.4.
Denial of service in Mozilla node-convict 6.2.2 and later allows remote, unauthenticated attackers to overwrite core JavaScript methods on the global Object function via config.set(), causing persistent process-wide failure that requires a restart. The flaw arises because the library's prototype-pollution filters only block constructor.prototype.* and __proto__.* key paths, while a key such as constructor.assign is resolved by walk() to the global Object constructor, permitting tampering with methods like Object.assign. Exploitation is not automatic: it requires an application endpoint or handler that forwards attacker-controlled property names directly into config.set(), so only configurations driven by untrusted keys are exposed; no public exploit code has been identified and EPSS is low (0.24%, 14th percentile), with CISA SSVC recording Exploitation: none and no KEV listing.
Server-side request forgery in the Backstage @backstage/plugin-techdocs-node package (0.11.12 through 1.14.6, and 1.15.0 through 1.15.4) lets an authenticated user who controls a TechDocs source repository have documentation builds fetch and publish content from network locations reachable by the build environment. The issue is rated CVSS 7.7 (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N), reflecting a confidentiality-only, scope-changing impact that requires repo write access and a build topology where internal endpoints are reachable without token or special-header protections; newer cloud metadata services that require tokens or custom headers are explicitly not directly accessible. Vendor-released patches exist in @backstage/plugin-techdocs-node 1.14.7 and 1.15.5 (and in Backstage releases v1.50.6, v1.54.8, v1.55.0); no public exploit identified at time of analysis.
Ghostscript can execute arbitrary shell commands with the privileges of its process when it renders a crafted PostScript or EPS document, chaining memory corruption in document parsing with a runtime bypass of the -dSAFER sandbox. The flaw affects Ghostscript as shipped in Red Hat Enterprise Linux 6, 7, 8, 9, and 10, and the assessed vector is CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H, meaning no privileges are required but a victim or automated pipeline must render the malicious file, with the malicious document first reaching the processing system. Publicly available exploit code exists, including a GitHub proof-of-concept, but the provided data does not confirm CISA KEV active exploitation, so -dSAFER should not be treated as a protective mitigation for affected versions.
WeasyPrint releases prior to 70.0 hand attacker-controlled bytes - from HTML img URLs, CSS image values, SVG image references, and data URIs - to Pillow's generic image dispatcher, which does not exclude Encapsulated PostScript, so on any host with Ghostscript installed Pillow's EpsImagePlugin shells out to that interpreter and runs the attacker's PostScript. This produces interpreter-permitted effects, demonstrated by the fix commit's dangerous.eps sample writing /tmp/test-marker.txt, and escalates to remote code execution when the installed Ghostscript has a usable -dSAFER sandbox bypass; hosts without Ghostscript never reach the rasterization path and are not exploitable. No public exploit code and no CISA KEV entry were identified at time of analysis, and the vendor-released patch is WeasyPrint 70.0; the published CVSS is 8.8 while our own assessment rates attack complexity as High with no privileges and no user interaction required.
Hydra 1.3.4 through 1.3.5 and the 1.4.0.dev line prior to 1.4.0.dev9 can execute attacker-chosen code when an application runs Hydra's instantiate() on configuration an attacker can influence, because the callable blacklist added for CVE-2026-68508 is name-based and can be sidestepped via wrappers, aliases, dispatch helpers, or deferred invocation. The CVSS 3.1 vector (AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H, score 7.8) indicates no attacker privileges are required but a victim application must actually instantiate untrusted or externally sourced config, which is why user interaction is scored; the flaw is CWE-184 (Incomplete List of Disallowed Inputs) and is best understood as an incomplete fix rather than a new class of bug. There is no public exploit identified at time of analysis and the issue is not in CISA KEV, and vendor-released patches exist in Hydra 1.3.6 and 1.4.0.dev9. Applications that only ever instantiate developer-authored, trusted configuration are not exposed, and the vendor explicitly documents the blocklist as a best-effort defense-in-depth stopgap rather than a security boundary.
Code injection in the Hydra configuration framework (all releases prior to 1.3.6 and 1.4.0.dev9) lets an attacker who controls the application's Hydra logging configuration name an arbitrary importable class or factory that Hydra will then import and invoke with the application's own privileges. Hydra routes logging settings to Python's logging.config.dictConfig() without applying its own target policy, so the handler 'class' values and the formatter, filter, handler, queue and listener factories are resolved and called directly - this bypasses the _target_whitelist_ protection that otherwise guards instantiate(), meaning even hardened deployments are exposed. The assessed vector is CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H (7.8): a local, unprivileged attacker must plant malicious logging configuration (a config file, an override, or a shared/untrusted config source) and the victim must then run the Hydra application, yielding high confidentiality, integrity and availability impact; no public exploit code has been identified at time of analysis and the flaw is not in CISA KEV, but exploitation only requires that the victim execute the tampered configuration.
Configuration-controlled code execution in the hydra-optuna-sweeper package (Hydra 1.2.0 up to but not including 1.3.0, plus 1.4.0 development builds before 1.4.0.dev10) allows an attacker who controls Optuna sweep configuration or command-line overrides to name an arbitrary importable Python callable in hydra.sweeper.custom_search_space that Hydra resolves and then invokes inside the controller process at the application's privilege level, including bypassing the trusted execution whitelist introduced on affected 1.4.0 development releases. The assessed CVSS 3.1 vector is AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H (7.8 High): delivery is local and unauthenticated, but a victim must actually launch the sweep, after which confidentiality, integrity, and availability impact is total for the affected process. Exploitation is only meaningful where sweep configuration or overrides cross a trust boundary; no public exploit code and no confirmed active exploitation (CISA KEV) were identified at time of analysis.
Code execution with the hosting application's privileges is possible in Hydra 1.3.4 through versions before 1.3.7 (and before 1.4.0.dev10) when an attacker controls multiple sibling target entries in a configuration that the application passes to instantiate(). One sibling resolves hydra._internal.target_policy.UNCONTROLLED_EXECUTION_TARGETS.discard to delete a denied target from Hydra's process-global blocklist, and a later sibling - processed in insertion order against the same mutated policy - invokes the now-permitted callable; the mutation persists for the life of the process. The CVSS 4.0 vector (AV:L/AC:L/AT:N/PR:N/UI:P, 8.5) indicates no privileges are required and only passive user interaction, and no public exploit identified at time of analysis (not in CISA KEV, no POC referenced); exploitation is limited to deployments that feed untrusted configuration content to instantiate(), and a narrow execution whitelist supplied by trusted Python code is not bypassed by the reported direct mutation path.
Use-after-free in Google Chrome's CSS handling affects builds prior to 155.0.8059.39 and allows a remote, unauthenticated attacker to execute arbitrary code inside the renderer sandbox when a victim loads a crafted HTML page. The flaw scores CVSS 3.1 base 8.8 (AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H), yet Google assigned it Chromium severity Low because the resulting code execution is confined to the browser sandbox and requires user interaction - full host compromise would require chaining a separate sandbox-escape bug. No public exploit identified at time of analysis, and a vendor patch is available.
Code execution outside the Chrome sandbox is possible in Google Chrome desktop builds prior to 155.0.8059.39, where a use-after-free in the network component (CVE-2026-106234, CWE-416) can be triggered by a crafted Chrome extension that a remote, unauthenticated attacker convinces a victim to install. The UI:R prerequisite - social engineering the user into installing the extension - is the primary limiting factor, which is why the vendor assigned a Chromium security severity of Low even though the assessed CVSS is 9.6 (AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H) and technical impact is rated total in the CISA SSVC framework; the high CVSS and the Low vendor severity are sharply conflicting signals. No public exploit identified at time of analysis (SSVC exploitation: none), and a vendor patch is available.
A low-severity information disclosure exists in the Payments component of Google Chrome, where a remote attacker using a crafted HTML page and social-engineering lures could cause the browser to leak sensitive information handled by the payments/autofill feature in builds prior to 155.0.8059.39. Exploitation is not automatic: the victim must be convinced to open the attacker's page while running a vulnerable build, and the assessed vector (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N) confines realistic impact to confidentiality loss with no integrity or availability effect. There is no confirmed active exploitation (not in CISA KEV) and no public exploit identified at time of analysis; a vendor patch is available in Chrome 155.0.8059.39. Note that the supplied CVSS base score of 8.8 (C:H/I:H/A:H) is inconsistent with both the Chromium severity rating of Low and the independent assessment, and should not be used for prioritization without reconciliation.
Incomplete cleanup in the Chromoting (Chrome Remote Desktop) component of Google Chrome on macOS before 155.0.8059.39 lets a remote, unauthenticated attacker bypass system access restrictions using crafted network traffic, per the assessed CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N vector. Impact is materially constrained: only macOS hosts on an affected build with Chromoting enabled and reachable are in scope, and the realistic outcome is limited information exposure rather than full compromise, which is consistent with the vendor's 'Low' Chromium severity rating. Risk signals conflict sharply - the supplied CVSS score of 9.1 (C:H/I:N/A:H) and the authoritative assessed vector of C:L/I:N/A:N disagree - and must be reconciled before prioritization; EPSS is negligible at 0.17% (6th percentile), there is no KEV listing, and no public exploit identified at time of analysis. Vendor-released patch: Chrome 155.0.8059.39.
Authorization bypass in the Chromoting (Chrome Remote Desktop) host component of Google Chrome on macOS prior to 155.0.8059.39 lets remote attackers circumvent macOS system access restrictions by sending crafted network traffic to the remoting service; the provided CVSS vector is AV:N/PR:N/UI:N so the flaw is treated as network-reachable and unauthenticated. Exploitation is conditional rather than opportunistic: it requires Chrome Remote Desktop (Chromoting) to be installed, enabled and network-reachable on a macOS host, and Google's Chromium team rated the underlying defect only 'Low' severity, which is why our independent assessment reduces impact to C:L/I:L/A:N with AC:H instead of the vendor's 9.1. No public exploit code or confirmed active exploitation has been identified at time of analysis, and EPSS is low at 0.21% (10th percentile), so this should not be triaged as a 9.1-equivalent emergency even though the vendor score is high.
Information disclosure in Google Chrome for Android lets a remote attacker who successfully socially engineers a victim into opening a crafted HTML page expose sensitive data handled by the browser's Passwords component; builds prior to 155.0.8059.39 are affected, and no authentication or non-default configuration is required. The vendor classifies the issue as Low severity (CWE-200) and no public exploit code was identified at time of analysis. Note that the supplied CVSS base score of 8.8 (C:H/I:H/A:H) is inconsistent with the information-disclosure description and the vendor's Low rating; our independent assessment scores it AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N, i.e. a confidentiality leak that strictly depends on user interaction.
Google Chrome for Android prior to 155.0.8059.39 contains an incorrect-authorization flaw in its Transactions Platform component that lets an unauthenticated remote attacker read sensitive information from the browser by luring the victim into opening a crafted HTML page. No public exploit code has been identified at time of analysis and the issue is not reported as actively exploited, though the attack is fully remote (AV:N/PR:N) and requires only that a user on a vulnerable Android build load the attacker's page (UI:R). Note that public severity signals conflict: the vendor rates this Chromium security severity 'Low' and limits impact to information disclosure, while a widely replicated CVSS 3.1 base score of 8.8 lists high integrity and availability impact that is not supported by the description - our independent assessment scores it 8.8-adjacent only on confidentiality (C:H/I:N/A:N).
The signals here conflict sharply and must be reconciled before prioritization: the supplied CVSS 3.1 base score of 8.8 (AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H) and the 'Authentication Bypass' tag imply full compromise, while the authoritative assessed vector AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N describes only a confidentiality impact with mandatory user interaction. As assessed, an unauthenticated remote attacker can obtain sensitive information from Google Chrome desktop builds prior to 155.0.8059.39 when a victim opens a crafted HTML page, with no integrity or availability impact and no authenticated-session or special-configuration prerequisite in the product itself. There is no CISA KEV listing and no public exploit code identified at time of analysis, Chromium rates the underlying issue Low severity, and the vendor-released patch is Chrome 155.0.8059.39.
Information disclosure in the Permissions component of Google Chrome before 155.0.8059.39 allows a remote, unauthenticated attacker to bypass the browser's site-isolation boundary by luring a victim into loading a crafted HTML page. Exploitation requires user interaction (UI:R) - the target must visit attacker-controlled content - and the resulting impact is limited to leaking information across origins rather than code execution, data modification, or denial of service. A vendor fix is already available in 155.0.8059.39, there is no confirmed active exploitation (no CISA KEV listing) and no public exploit code identified at time of analysis, and EPSS is 0.18% (7th percentile), indicating a low near-term exploitation likelihood.
Type confusion in the V8 JavaScript engine of Google Chrome before 155.0.8059.39 allows a remote attacker to execute arbitrary code inside the renderer sandbox when a victim renders a crafted HTML page, requiring user interaction (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H, 8.8). Signals conflict and must be weighed carefully: the numeric severity is high, yet Google's own Chromium security severity for this issue is 'Low' and CISA's SSVC assessment records no exploitation and a non-automatable attack path, with no public exploit identified at time of analysis. A vendor-released patch exists in Chrome 155.0.8059.39, so fully updated installations are not exposed.
Information disclosure in Google Chrome for Android (versions prior to 155.0.8059.39) allows remote, unauthenticated attackers to reach sensitive data held by the browser's Autofill feature via a crafted HTML page, with the flaw rooted in incorrect authorization (CWE-863) in the Autofill path. Per the assessed vector (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N), exploitation requires the victim to actively navigate to the attacker's page and the impact is confined to confidentiality, with no integrity or availability effect; the vendor-supplied 8.8 score (C:H/I:H/A:H) and the 'Low' Chromium severity conflict with this assessment and should be reconciled before prioritization. Chrome on Android is the affected build, no public exploit was identified at time of analysis, and a vendor-released patch (155.0.8059.39) is available.
Origin policy bypass in Google Chrome for Android prior to 155.0.8059.39 lets a remote attacker acting through a confused deputy have actions carried out under a different web origin's authority, so a victim who is socially engineered into opening a crafted HTML page can have that page reach resources or capabilities it should never hold for its own origin. Only Chrome on Android is affected, exploitation is not silent (it requires the user to open attacker-supplied content, CVSS PR:N/UI:R), and no public exploit code or active exploitation has been identified at time of analysis; EPSS is 0.22% (12th percentile), and Google rates the underlying Chromium bug as Low severity. Note the sharp signal conflict that must be reconciled before prioritization: the nominal vendor CVSS is 8.3 while EPSS, vendor severity, and our independent assessment (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:L/A:N) all point to materially lower real-world risk.
Integer overflow in the Media component of Google Chrome (all versions prior to 155.0.8059.39) allows a remote, unauthenticated attacker to corrupt memory via a crafted HTML page containing specially formed media content, with the potential to execute arbitrary code outside the browser sandbox. Exploitation is not automatic: the CVSS vector (UI:R) confirms the victim must actively load the attacker-controlled or compromised page, and Google rated this a Chromium severity of 'Low', indicating the sandbox-escape outcome is not reliably achievable and probably depends on specific memory conditions or combining this primitive with others. No public exploit code and no CISA KEV entry were identified at time of analysis; the 9.6 score reflects the scope-change metric (S:C) and high C/I/A impact rather than proven real-world exploitation, so the practical risk is lower than the headline score suggests.
Information disclosure in the Passwords component of Google Chrome desktop builds prior to 155.0.8059.39 lets a remote, unauthenticated attacker obtain sensitive data when a victim renders a crafted HTML page. The vendor rates the issue Chromium security severity Low, and the independent assessment converges on a limited-confidentiality impact (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N) rather than the 8.8 figure carried in some feeds, so the mandatory user interaction and the low-confidentiality scope are the real risk drivers. There is no public exploit identified at time of analysis, and a vendor patch is already shipping in the stable channel as 155.0.8059.39.
Sandbox escape in Google Chrome before 155.0.8059.39 via a heap-based buffer overflow (CWE-122) in ANGLE, Chrome's graphics translation layer: a remote attacker who has already compromised a sandboxed renderer process can use a crafted HTML page to execute arbitrary code outside the sandbox. It is a second-stage primitive rather than an initial-access bug - the assessed vector CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H (8.3) reflects high attack complexity, a required pre-existing renderer exploit chain, and active user interaction (UI:R), with the scope change S:C capturing the crossing of the sandbox boundary, even though Chromium rates the underlying bug Low severity. No public exploit code was identified at time of analysis and CISA's SSVC data records no observed exploitation, so the headline 8.3 should be weighed against the significant preconditions.
Code execution outside the Chrome sandbox on Windows is possible through CVE-2026-106186, an uncontrolled search path flaw in Chrome's CredentialProvider component affecting Chrome builds prior to 155.0.8059.39. The issue is local-only (CVSS:3.1/AV:L) and requires both a pre-existing local foothold with write access to a directory the component searches and user interaction to load the affected program, yet because the credential provider loads in a more privileged Windows context the scope changes (S:C) and confidentiality, integrity, and availability impacts are all High, yielding a base score of 8.6 with no privileges required (PR:N). No public exploit code has been identified at time of analysis and the issue is not listed in CISA KEV; SSVC rates exploitation as 'none' and automatable as 'no', and Chromium's own internal severity rating is 'Low', which sharply tempers the headline CVSS figure. A vendor patch is available as Chrome 155.0.8059.39.
Site isolation bypass in Google Chrome for Android (versions prior to 155.0.8059.39) lets an attacker who has already compromised the renderer process cross the per-site process boundary and reach data that should remain isolated to other origins, triggered when the victim loads a crafted HTML page. It is a second-stage flaw rather than an initial-access vector: exploitation is gated on a separate, pre-existing renderer compromise plus required user interaction (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N), which is why the vendor assigned a Chromium severity of Low even though the base score is 8.2. No public exploit identified at time of analysis, no CISA KEV listing, and EPSS is only 0.21% (11th percentile); a vendor patch is available, so the residual risk is concentrated in unpatched Android clients that are simultaneously exposed to a first-stage renderer exploit.
Arbitrary code execution confined to Chrome's renderer sandbox is possible in Google Chrome versions prior to 155.0.8059.39, where an incorrect comparison in the font rendering pipeline can be triggered by a crafted HTML page. This is an unauthenticated remote attack (AV:N/PR:N) that requires the victim to load attacker-controlled web content (UI:R); the resulting code execution stays inside the renderer sandbox (S:U), and escaping to the host operating system requires a separate, unrelated sandbox-escape vulnerability - which is why Chromium assigned a Low security severity despite the CVSS 8.8 base score. No public exploit code was identified at time of analysis, and a vendor-released patch (155.0.8059.39) is available.
Incorrect authorization in the Selection component of Google Chrome for iOS lets a remote, unauthenticated attacker obtain sensitive information when a victim opens a crafted HTML page, and the issue is resolved in Chrome 155.0.8059.39. Only the iOS build of Chrome below that version is in scope; desktop and Android builds are not named as affected, and exploitation requires the user to actively visit the attacker-controlled page (UI:R per the assessed vector). No public exploit code has been identified at time of analysis and the issue is not in CISA KEV, so the practical risk is bounded by mandatory user interaction, the narrow iOS-only affected population, and the fact that a vendor fix already ships; note that the supplied base score of 8.8 (C:H/I:H/A:H) is inconsistent with both the Chromium 'Low' severity label and the assessed vector, which rates impact as confidentiality-only.
Missing authorization in the Actor component of Google Chrome prior to 155.0.8059.39 allows code to escape the browser sandbox, but only after the attacker has already compromised the renderer process via a separate bug and then gets the victim to load a crafted HTML page. This prerequisite, combined with required user interaction (UI:R) and high attack complexity (AC:H) from the assessed CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H vector, means the flaw is only usable as a link in an exploit chain rather than as a standalone initial-access vector; the changed scope (S:C) and high confidentiality, integrity and availability impact reflect the potential for full code execution outside the sandbox. No public exploit code identified at time of analysis and there is no confirmed actively exploited (CISA KEV) status, so risk should be weighed against the conflicting 8.3 score versus the demanding exploitation preconditions. A vendor patch is available in Chrome 155.0.8059.39.
Arbitrary code execution outside the browser sandbox is possible in Google Chrome on macOS prior to 155.0.8059.39, where incorrect reference resolution in the WebAppInstalls component allows crafted network traffic to cross a process trust boundary. Exploitation is not standalone: the attacker must already have compromised the Chrome renderer process, which makes this a second-stage sandbox-escape primitive in a larger exploit chain rather than a directly reachable remote compromise, and the assessed vector (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H) reflects that non-trivial precondition. A vendor-released patch (Chrome 155.0.8059.39) is available, and no public exploit code was identified at the time of analysis.
Type confusion in V8, Chrome's default JavaScript and WebAssembly engine, enables a remote attacker to run arbitrary code inside the browser's renderer sandbox in Google Chrome releases below 155.0.8059.39. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H, 8.8) confirms the attack is network-reachable and requires no authentication, though it does require the victim to open attacker-controlled web content, so a phishing, malvertising, or watering-hole lure is a prerequisite. No public exploit code has been identified at time of analysis and CISA's SSVC assessment records exploitation as 'none' and the issue as not automatable, so real-world priority currently sits below what the 8.8 base score alone implies; note that code execution is confined to the renderer sandbox, meaning full host compromise would require chaining a separate sandbox-escape flaw. Google has shipped a vendor patch.
Incorrect authorization in the Google Chrome user-interface layer allows a crafted HTML page to escape the renderer sandbox and execute arbitrary code outside it on all Chrome builds prior to 155.0.8059.39. Exploitation requires the victim to open an attacker-supplied page (UI:R in the assessed vector) and, while no authentication is required (PR:N) and no unusual configuration is needed, the attack is not fully remote - it depends on that user action, which is the main limiting factor. Severity signals are mixed: the assessed CVSS vector scores 9.6 with scope change (S:C) and high confidentiality, integrity and availability impact, yet Google rates the underlying Chromium issue as Medium, and no public exploit code or confirmed active exploitation (CISA KEV) has been identified at time of analysis.
Arbitrary code execution inside the Chrome renderer sandbox is possible in Google Chrome builds prior to 155.0.8059.39, where a race condition (CWE-367) in the V8 JavaScript engine can be won by a crafted HTML page. Exploitation requires only that the victim load the attacker's page in a vulnerable browser (UI:R, PR:N per the CVSS vector), with no credentials or prior privileges needed, but success additionally depends on hitting a time-of-check/time-of-use timing window, which our assessment captures by raising attack complexity to High (CVSS 3.1 base 8.1 under AC:H, versus the 8.8 score supplied with the CVE under AC:L). The critical caveat is scope: the code execution achieved stays within the renderer sandbox and does not by itself compromise the host operating system, so full system impact requires chaining a separate sandbox-escape vulnerability. No public exploit code has been identified at time of analysis, CISA SSVC records Exploitation: none (Automatable: no, Technical Impact: total), and a vendor-released patch exists in Chrome 155.0.8059.39.
Incorrect authorization in Google Chrome's WebProtect component lets a remote, unauthenticated attacker who socially engineers a victim into opening a crafted HTML page read sensitive information held in the browser context - the assessed impact is confidentiality-only (C:H/I:N/A:N), with no integrity or availability loss. Every Chrome build prior to 155.0.8059.39 is affected across platforms, and Google rates the underlying issue as Chromium security severity Medium. Exploitation is not drive-by: the CVSS vector requires user interaction (UI:R) and PR:N, so no credentials or non-default configuration are needed but the victim must be lured to the attacker-controlled page, and no public exploit code has been identified at time of analysis, making the base score of 8.8 an overstatement of realistic risk.
An out-of-bounds write in the Media component of Google Chrome before 155.0.8059.39 lets a remote attacker corrupt memory and potentially achieve arbitrary code execution outside the browser sandbox when a victim opens an attacker-crafted HTML page containing malicious media content. The attack is fully remote and requires no authentication (CVSS:3.1/AV:N/AC:L/PR:N), but it is gated by user interaction (UI:R) - the victim must visit the malicious or compromised page - and the 'outside the sandbox' outcome implies defeating Chrome's process sandbox, which is materially harder in practice than the 9.6 base score suggests. No public exploit code or confirmed active exploitation was identified at time of analysis, and the vendor has released a fixed build.
Site isolation bypass in Google Chrome affects versions prior to 155.0.8059.39, where a missing authorization check (CWE-862) in the browser's Workers implementation lets an attacker who has already compromised a renderer process cross the site-isolation boundary using a crafted PDF file. The attack is remote (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N, score 8.1), but exploitation is gated on a pre-existing renderer foothold obtained through a separate vulnerability, so this is a chained sandbox/site-isolation escape rather than a standalone remote compromise. There is no public exploit identified at time of analysis and no CISA KEV listing; EPSS is low at 0.17% (5th percentile), and CISA SSVC rates exploitation as 'none' with automation as 'no', while acknowledging total technical impact if the chain is completed. A vendor patch is available in Chrome 155.0.8059.39.
Incorrect authorization in Google Chrome's Autofill feature (versions prior to 155.0.8059.39) allows an unauthenticated remote attacker (PR:N) to obtain sensitive information via a crafted HTML page, but exploitation requires social engineering to trick the victim into visiting and interacting with the page (UI:R). The independent assessment limits the impact to confidentiality (C:L) with no integrity or availability effect, and exploitation further depends on the victim having relevant data stored in Autofill; no public exploit or active exploitation has been identified. A vendor patch is available.
Incomplete cleanup in Dawn, Chrome's WebGPU implementation, allows a crafted HTML page to potentially corrupt GPU-process state and achieve code execution outside the browser sandbox in Google Chrome builds prior to 155.0.8059.39. Exploitation requires the victim to render attacker-controlled content that reaches the affected WebGPU/Dawn code path (CVSS UI:R with PR:N - unauthenticated remote attackers, but user interaction required), and the outcome is probabilistic rather than a guaranteed silent drive-by; the published base score is 9.6 while Google rates the issue Medium, and our assessed vector raises attack complexity to AC:H to reflect the difficulty of chaining a cleanup flaw into a reliable sandbox escape. No public exploit code has been identified at time of analysis, and Google has released Chrome 155.0.8059.39 as the fix.
Heap-based buffer overflow in Google Chrome's font-handling code (CWE-122) lets an attacker who has already compromised the renderer process execute arbitrary code outside the sandbox when a victim renders a crafted HTML page containing malicious font data. All Chrome builds prior to 155.0.8059.39 on default configurations are affected; exploitation is unauthenticated (PR:N) but requires user interaction (UI:R) and a pre-existing renderer compromise, so it functions as a sandbox-escape chain component rather than a standalone drive-by, and is rated high complexity (AC:H) despite a CVSS base of 8.3 (S:C). No public exploit code has been identified at time of analysis and CISA's SSVC assessment records no exploitation, but the vendor has shipped a fix in 155.0.8059.39.
Confused-deputy bypass in Google Chrome's Contextual Tasks feature allows a remote attacker who already holds renderer code execution to cross a security boundary into a privileged page by loading a crafted HTML page, with high confidentiality and integrity impact (unauthenticated per the CVSS vector, but requiring user interaction). The flaw affects Chrome builds prior to 155.0.8059.39 and functions primarily as a chain link - the prerequisite renderer compromise from a separate bug is the real gate, which sharply narrows standalone risk despite the 8.1 score. No public exploit code has been identified at time of analysis and EPSS is very low at 0.18% (7th percentile), with CISA SSVC recording no observed exploitation; a vendor-released patch exists in 155.0.8059.39.
Use-after-free in Chrome's font handling on Windows allows a remote attacker to execute arbitrary code inside the renderer sandbox when a victim opens a crafted HTML page; the flaw affects Google Chrome versions prior to 155.0.8059.39. Exploitation requires user interaction (UI:R) - the victim must load attacker-controlled content - and there are no authentication prerequisites (PR:N), but the resulting code execution is confined to the Chrome sandbox, so host-level compromise would require a second, independent sandbox-escape bug. Consistent with the medium severity rating assigned by the Chromium team, CISA's SSVC assessment records no known exploitation and no automatable exploitation path, and no public exploit code has been identified at time of analysis.
Site isolation bypass in Google Chrome versions earlier than 155.0.8059.39 lets a remote attacker who has already compromised a renderer process escape Chrome's process boundary and reach data or privileged accessibility functionality belonging to other origins by way of a crafted HTML page the victim loads. The flaw is an incorrect-authorization bug (CWE-863) in the browser's Accessibility component, making it a chained, second-stage primitive rather than a standalone remote compromise, which is why the assessed vector uses AC:H (AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N) despite an underlying base score of 8.1. Google has released a vendor patch in 155.0.8059.39; no public exploit code and no confirmed active exploitation were identified at time of analysis (EPSS 0.18%, CISA SSVC exploitation: none, automatable: no), so the risk is real but is not currently a frontline emergency.
Arbitrary code execution outside Chrome's sandbox on Android affects Google Chrome builds prior to 155.0.8059.39, where a missing authorization check (CWE-862) can be abused by a malicious co-installed Android app. The attack is local - it requires an attacker-controlled app to already be present on the same device plus successful social engineering to get the victim to install it and trigger the action - so a default, lone Chrome installation is not directly exploitable. Google rates this Chromium security severity Medium, the vendor CVSS is 8.4 (AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) while our assessment substitutes UI:R, no publicly available exploit code or confirmed active exploitation has been identified at time of analysis, and EPSS is only 0.12% (2nd percentile).
Site isolation bypass in Google Chrome on Android (prior to 155.0.8059.39) allows an attacker who has already compromised the renderer process to reach the browser's Passwords component via a crafted HTML page and a missing authorization check, exposing stored credential data. The bug is a chained, second-stage issue: it cannot be triggered by an unprivileged remote attacker without pre-existing renderer code execution, and it requires user interaction to load the crafted page, which is why the assessed vector (AV:N/AC:H/PR:L/UI:R/C:H/I:N/A:N) makes realistic risk LOW despite the 8.1 base score. No public exploit identified at time of analysis, EPSS is only 0.21% (11th percentile), CISA SSVC records Exploitation: none, and Google rated the Chromium security severity Medium, so this is a routine patch-cycle fix rather than an emergency.
Sensitive-information disclosure in Google Chrome for iOS before 155.0.8059.39 allows a remote, unauthenticated attacker to abuse a missing authorization check by socially engineering a victim into opening a crafted HTML page. The independent assessment limits the impact to confidentiality (C:H/I:N/A:N), so this should be treated as an information disclosure issue rather than code execution or data tampering, and exploitation requires user interaction on the iOS build only. Vendor patch 155.0.8059.39 is available, and no public exploit code or CISA KEV active exploitation was identified in the supplied intelligence.
Sandbox escape and potential arbitrary code execution outside the browser sandbox in Google Chrome via a confused-deputy flaw in the Google Lens feature, affecting all desktop releases prior to 155.0.8059.39. Exploitation is not standalone: a remote attacker must first have compromised the Chrome renderer process (a separate renderer-stage bug), then convince the victim to load a crafted HTML page, after which the Lens component can be induced to perform a privileged operation that crosses the sandbox boundary on the renderer's behalf - consistent with the CVSS:3.1 vector AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H and high attack complexity. No public exploit code has been identified at time of analysis and there is no confirmed active exploitation (CISA KEV absent, SSVC exploitation: none), but the maximum technical impact rating means the issue is worth prioritizing within normal patch cycles; vendor-released patch: 155.0.8059.39.
Race condition in the V8 JavaScript engine allows remote code execution inside the browser sandbox in Google Chrome builds prior to 155.0.8059.39. A remote, unauthenticated attacker can trigger the flaw by getting a victim to open attacker-supplied HTML that drives V8 into the timing window (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H) - the required user interaction is the only precondition, and code execution is confined to the renderer/V8 sandbox, so host compromise would require a second, separate sandbox-escape bug. Google has shipped a fixed stable-channel build, and no public exploit code or confirmed active exploitation was identified at time of analysis (CISA SSVC records Exploitation: none; no KEV listing or PoC in the available sources).
Remote attackers can bypass system access restrictions and reach a privileged internal page in Google Chrome for Android versions prior to 155.0.8059.39 by way of a confused-deputy weakness in the SignIn component, which performs privileged navigation on behalf of an untrusted caller. Exploitation requires the victim to load attacker-controlled crafted HTML (for example, visiting a malicious or compromised page), needs no authentication or prior privileges, and is limited to the Android build on pre-patch versions. No public exploit code has been identified at time of analysis, EPSS is low at 0.22% (12th percentile), and the issue is not confirmed as actively exploited; a vendor patch (155.0.8059.39) is available, so this is a moderate-priority patch-and-move-on item rather than an emergency.
Sandbox escape in Google Chrome on iOS (versions prior to 155.0.8059.39) allows a local attacker who has already compromised the renderer process to execute arbitrary code outside the browser sandbox via a local program. The flaw is an incorrect reference resolution (CWE-706) in the Passwords component, rated Medium by Chromium and carrying a CVSS 7.4 (AV:L/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H). No public exploit code or confirmed active exploitation has been identified at time of analysis; a vendor patch is available.
Information disclosure in Google Chrome's Autofill component lets a remote, unauthenticated attacker read sensitive data by luring a victim to a crafted HTML page on any Chrome build prior to 155.0.8059.39. Exploitation requires user interaction (UI:R) - the victim must actually navigate to the attacker's page - which is the primary limiting factor, and no non-default configuration or privileges are needed since Autofill is enabled by default. The independent assessment scopes impact to confidentiality only (C:H/I:N/A:N), while the supplied vector additionally claims high integrity and availability impact; no public exploit code and no confirmed active exploitation have been identified at time of analysis, and vendor-patched builds are available.
Cross-origin data disclosure in Google Chrome (all versions prior to 155.0.8059.39) stems from a missing authorization check in the browser's FileSystem component, allowing a crafted HTML page to breach the web origin boundary and read data it should not reach. Exploitation is strictly a second-stage condition: an attacker must first have already compromised Chrome's renderer process through a separate flaw, and the victim must load attacker-controlled content (UI:R), so a default, fully patched Chrome with an intact renderer sandbox is not directly exploitable - a limitation that makes real-world risk moderate despite the 8.2 base score, and is reflected in the low EPSS of 0.22% (12th percentile). Google has shipped a fix in Chrome 155.0.8059.39, there is no confirmed active exploitation (CISA KEV) and no public exploit identified at time of analysis.
Sandbox escape in Google Chrome on macOS, affecting releases prior to 155.0.8059.39, allows an attacker who has already compromised the browser's renderer process to execute arbitrary code outside the sandbox when the victim views a crafted HTML page. The CVSS 3.1 vector (AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H, base 8.3) confirms a network-reachable, scope-changing escape that requires user interaction and carries high confidentiality, integrity and availability impact once triggered, but the AC:H rating and CISA SSVC 'Automatable: no' reflect that it cannot be used standalone - a prior renderer compromise is a hard prerequisite. Per the authoritative assessment this is a chained second-stage exploit limited to macOS; no public exploit code and no confirmed active exploitation were identified at time of analysis.
Improper input validation in the Mobile component of Google Chrome on iOS allows a remote attacker to potentially execute arbitrary code outside the browser sandbox when a victim is socially engineered into opening a crafted HTML page, fixed in Chrome 155.0.8059.39. Successful exploitation requires user interaction (CVSS vector PR:N/UI:R with S:C), meaning the attack hinges on phishing or a malicious link rather than a zero-click path, and the scope change reflects the assessed ability to escape the sandbox boundary. No public exploit code has been identified at time of analysis and the issue is not a confirmed actively exploited (CISA KEV) vulnerability, but the 9.6 CVSS score and the RCE tag make prompt patching of older mobile Chrome installations the priority.
Web origin policy bypass in Google Chrome's Navigation component on iOS allows a remote, unauthenticated attacker to escape intended origin boundaries and reach a privileged page when a victim opens a crafted HTML page. Exploitation is constrained by two factors: the mandatory user interaction (CVSS UI:R - the victim must actively load the malicious page) and the narrow platform scope, since only the iOS build of Chrome is affected rather than Chrome on other operating systems. Risk signals are modest - EPSS is 0.22% (12th percentile), there is no CISA KEV listing, and no public exploit code has been identified at time of analysis - and Google has shipped a fix, so this is a moderate-priority issue rather than an urgent one.
A use-after-free memory-safety flaw in Google Chrome's Media component lets a remote, unauthenticated attacker execute arbitrary code inside the renderer sandbox when a user loads a crafted HTML page containing malicious media content. All Chrome builds prior to 155.0.8059.39 are affected, and exploitation requires the victim to visit or load the attacker-controlled page (UI:R), which is the main practical barrier; no credentials or special privileges are needed. There is no public exploit identified at time of analysis and the CISA SSVC assessment records no exploitation, but the vendor has shipped a fix in 155.0.8059.39, and the EPSS-style risk picture is dominated by Chrome's ubiquity and the high CVSS base score (8.8) rather than by observed attacks.
Code injection in the Reader Mode feature of Google Chrome on iOS (versions prior to 155.0.8059.39) lets a remote, unauthenticated attacker bypass the web origin policy by convincing a victim to open a crafted HTML page in the browser. The flaw is confined to the iOS build and depends on social engineering to drive the victim to the malicious page, so effective user interaction is required; impact is limited to a partial confidentiality, integrity and availability loss through origin-policy circumvention rather than full system compromise. No public exploit code has been identified at time of analysis, EPSS is a low 0.27% (17th percentile), and the issue is not listed in CISA KEV, so despite the 7.3 High CVSS the real-world priority is low-to-moderate. Google has shipped a vendor patch, fixed in Chrome 155.0.8059.39.
System access restriction bypass in Google Chrome versions prior to 155.0.8059.39 allows a remote attacker to break out of the browser's security boundary through the FullScreen component, but only after having already compromised the Chrome renderer process and only with successful social engineering to make the victim interact with a crafted HTML page. Because it is a chain component rather than a standalone bug, exploitation requires a pre-existing renderer foothold plus mandatory user interaction (UI:R) and carries high attack complexity (AC:H), so it is not exploitable against a fully patched default browser on its own. No KEV listing and no publicly available exploit code have been identified at time of analysis, and EPSS is low at 0.22% (12th percentile), consistent with the conditional nature of the flaw despite the 8.3 CVSS base score and a Chromium security severity rating of Medium.
Google Chrome builds prior to 155.0.8059.39 contain a missing authorization check in the Autofill component that allows a remote attacker to read sensitive information in the browser's stored autofill data. Exploitation is not silent: it requires the victim to be socially engineered into opening an attacker-crafted HTML page (CVSS UI:R, PR:N), and the SSVC assessment records Exploitation=none and Automatable=no, meaning this cannot be triggered at scale or without user action. Our independent assessment rates the impact as confidentiality-only (C:H/I:N/A:N), so real-world risk is MODERATE and meaningfully lower than the headline CVSS 8.8 suggests; no public exploit code has been identified at time of analysis and the issue is not in CISA KEV, though a vendor patch is available.
Incorrect authorization in the Search component of Google Chrome for Android before 155.0.8059.39 can allow a remote, unauthenticated attacker to execute arbitrary code outside the browser sandbox when a victim is socially engineered into opening a crafted HTML page. The vendor-rated Chromium severity is Medium, yet the assessed CVSS is 9.6 (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H) because the flaw crosses a security boundary (scope changed) with high confidentiality, integrity and availability impact. The risk signals conflict and must be weighed carefully: the impact score is severe, but exploitation requires a click of user interaction, is confined to Android builds (desktop Chrome is unaffected), and no public exploit code or confirmed active exploitation has been identified at the time of analysis. Vendor patches are available.
Sensitive information disclosure in Google Chrome builds prior to 155.0.8059.39 lets an unauthenticated remote attacker obtain data through the browser's Bluetooth handling by convincing a victim to open a crafted HTML page (CVSS 3.1 AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N per the independent assessment). The root cause is an incorrect authorization check (CWE-863) in the Web Bluetooth code path, so exploitation is limited to an information leak rather than code execution; the mandatory UI:R requirement means this is not a no-interaction drive-by, and the victim must be running a vulnerable Chrome version that reaches the affected Bluetooth logic. No public exploit identified at time of analysis, and the issue is not confirmed actively exploited (no CISA KEV entry), although the vendor-rated 8.8 score conflicts with the assessed confidentiality-only vector and should be weighed as a severity signal rather than proof of integrity or availability impact. Vendor-released patch: 155.0.8059.39.
Use-after-free in Google Chrome's garbage-collection code before 155.0.8059.39 allows an unauthenticated remote attacker to corrupt memory and execute arbitrary code inside the renderer sandbox when a victim loads a crafted HTML page. Exploitation requires user interaction (PR:N, UI:R) and the code execution stays contained in the browser sandbox, so OS-level compromise would require chaining a separate sandbox-escape flaw; no public exploit identified at time of analysis, and CISA's SSVC assessment records exploitation as 'none' and automatable as 'no', which tempers the high 8.8 CVSS base score. Vendor-released patch: 155.0.8059.39, distributed through Chrome's stable channel.
Use-after-free in the Streaming component of Google Chrome prior to 155.0.8059.39 allows unauthenticated remote attackers to execute arbitrary code inside the renderer sandbox when a victim is socially engineered into loading a crafted HTML page, consistent with the CVSS vector AV:N/AC:L/PR:N/UI:R. Google rates the issue Medium severity (Chromium) while the CVSS base score is 8.8, reflecting high confidentiality, integrity, and availability impact on the renderer process rather than the host. There is no CISA KEV listing and no public exploit identified at time of analysis, and the SSVC assessment records exploitation as none; the primary containment is Chrome's process sandbox, so full host compromise would require chaining a separate sandbox-escape flaw.
Sandbox escape in Google Chrome's WebAppInstalls component allows a remote attacker who has already compromised the renderer process to execute arbitrary code outside the browser sandbox when a victim visits a crafted HTML page and is socially engineered into interacting with the web app installation flow. The flaw is a missing authorization check (CWE-862) affecting Chrome versions prior to 155.0.8059.39; the technical impact is total, but the vendor rates it Medium because exploitation requires a prior renderer compromise, deliberate user interaction (UI:R), and high attack complexity (AC:H) rather than a default-configuration remote hit. No public exploit code and no confirmed active exploitation have been identified at time of analysis (CISA SSVC Exploitation: none, Automatable: no).
Incorrect reference resolution in Google Chrome on macOS before 155.0.8059.39 can disclose sensitive information to a remote attacker who uses social engineering to make the victim load a crafted HTML page. Exploitation requires a macOS user running an affected Chrome build who actively opens attacker-supplied content (UI:R), with no authentication required (PR:N) and network-delivered payloads (AV:N); there is no confirmed active exploitation and no public exploit code identified at time of analysis, and the only data supplied is a vendor patch and a Chromium issue. The signals conflict sharply: the headline CVSS of 8.8 (C:H/I:H/A:H) is not supported by the available evidence, and the assessed vector is confidentiality-only (AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N, roughly 6.5 Medium), matching Chromium's own 'Medium' severity label, so real-world priority is lower than the 8.8 figure implies.
Use-after-free in Google Chrome allows unauthenticated remote attackers to execute arbitrary code within the renderer sandbox by convincing a victim to load a crafted HTML page, affecting all versions prior to 155.0.8059.39. The attack requires user interaction (UI:R) but no authentication or special configuration, and while code execution is confined to the sandbox, the CVSS 3.1 score is 8.8. No public exploit or active exploitation has been identified, and a vendor patch is available.
A sandbox escape in Google Chrome before 155.0.8059.39 lets an attacker who has already compromised the browser's renderer process trigger a race condition in Chrome's font handling and execute arbitrary code outside the sandbox, via a crafted HTML page the victim must load (CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H, score 8.3). The prerequisite is significant: a separate, prior renderer compromise is required, and AC:H reflects the non-deterministic nature of winning the race, so this is a chained post-exploitation primitive rather than a standalone drive-by. Unauthenticated from a network perspective, with UI:R meaning the target must open attacker-controlled content; no CISA KEV entry, no public exploit code identified at time of analysis, and CISA's SSVC assessment rates exploitation as none and automatable as no, though technical impact is total once the race is won. Vendor-released patch: 155.0.8059.39.
Use-after-free in Google Chrome's Track component before 155.0.8059.39 allows an unauthenticated remote attacker to execute arbitrary code inside the renderer sandbox when a victim loads a crafted HTML page. The CVSS 3.1 base score is 8.8 (High) with UI:R, meaning exploitation requires user interaction but no authentication; successful code execution remains confined to Chrome's renderer sandbox and would require a separate sandbox-escape bug to affect the host OS. No public exploit identified at time of analysis, and SSVC records Exploitation: none; CISA KEV does not list this CVE.
Use-after-free in Google Chrome's built-in PDF handling (fixed in 155.0.8059.39) lets remote, unauthenticated attackers execute arbitrary code inside the Chrome renderer sandbox when a victim opens a crafted PDF file - exploitation is not automatic and depends entirely on the user interaction of opening the document (CVSS 8.8, AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H, CWE-416). Because the code execution is confined to the sandboxed renderer, turning this into full host compromise would require chaining a separate sandbox-escape bug; the advisory rates it Chromium severity High. At the time of analysis there is no public exploit identified and CISA SSVC records exploitation as none, though the vulnerability is fully described and a vendor patch plus the underlying Chromium issue tracker entry are publicly referenced. Google Chrome versions before 155.0.8059.39 are affected on all platforms tracked under cpe:2.3:a:google:chrome.
Google Chrome builds prior to 155.0.8059.39 contain a use-after-free in PDF handling that allows a remote, unauthenticated attacker to execute arbitrary code inside the browser's renderer sandbox when a victim loads a crafted HTML page that embeds a malicious PDF. Exploitation requires the user to open attacker-controlled web content processed by Chrome's built-in PDF (PDFium) viewer - a mandatory interaction step (CVSS UI:R) with no zero-click vector, and any code execution is confined to the sandboxed renderer unless chained with a separate sandbox escape. There is no public exploit identified at time of analysis, SSVC records no observed exploitation and rates the issue not automatable, but technical impact is rated total given high confidentiality, integrity, and availability impact; a vendor patch exists in 155.0.8059.39.
Use-after-free in Google Chrome's V8 JavaScript engine (all releases prior to 155.0.8059.39) lets unauthenticated remote attackers execute arbitrary code inside the renderer sandbox when a victim navigates to an attacker-controlled page containing crafted HTML/JavaScript. The bug carries a CVSS v3.1 base score of 8.8 (AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H) and Chromium's own 'High' severity rating, and because the V8 engine is enabled by default in every standard installation, no special configuration or privileges are needed on the target side. Impact is bounded, however: per the vendor description code execution is confined to the sandbox, so a standalone exploit does not by itself compromise the host and a separate sandbox-escape would be required, and no public exploit identified at time of analysis (SSVC Exploitation: none, Automatable: no) - a genuine priority-worthy issue whose urgency is tempered by the required user interaction, sandbox confinement, and absence of observed exploitation.
Use-after-free in the Media component of Google Chrome prior to 155.0.8059.39 lets a remote attacker execute arbitrary code within the browser's renderer sandbox by luring a victim to open a crafted HTML page. The flaw carries a CVSS v3.1 base score of 8.8 (AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H), meaning no authentication or prior privileges are required, but successful exploitation depends on the user actively navigating to attacker-controlled content. There is no public exploit identified at time of analysis - CISA's SSVC assessment lists exploitation as 'none' - and code execution is contained within the renderer sandbox, so a separate sandbox-escape would be needed to reach the host OS; the vendor has released a patched build.
Type confusion in the V8 JavaScript engine of Google Chrome prior to 155.0.8059.39 lets a remote, unauthenticated attacker execute arbitrary code inside the browser's renderer sandbox when a victim loads a crafted HTML page; the CVSS vector is AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H, so the sole prerequisite is that the victim renders attacker-controlled content in an unpatched desktop build. No public exploit code or active exploitation was identified at time of analysis, and CISA KEV does not list this CVE. The vendor-released patch is Chrome 155.0.8059.39, and installations already updated past that version are not affected. Because the impact is scoped to the sandbox (S:U) per the description, full host compromise would require chaining a separate sandbox-escape vulnerability.
Google Chrome versions prior to 155.0.8059.39 contain a use-after-free in the WebRTC component that a remote, unauthenticated attacker can trigger by convincing a victim to visit a crafted HTML page, resulting in arbitrary code execution within the renderer sandbox (CVSS 3.1 base 8.8, AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H). Exploitation is not automatable and requires user interaction, and the resulting code execution is confined to Chrome's renderer sandbox per the vendor description, so full host compromise would additionally require chaining a separate sandbox-escape flaw. No public exploit code has been identified at time of analysis, and CISA's SSVC assessment records no known exploitation; Chrome's built-in auto-update is the primary exposure-reduction control, as patched versions 155.0.8059.39 and later are not vulnerable.
Arbitrary code execution inside the renderer sandbox is achievable in Google Chrome builds prior to 155.0.8059.39, where a use-after-free in the browser's Media component can be triggered when a victim loads a crafted HTML page. Scoring 8.8 under CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H, the bug requires no authentication but does require the user to visit attacker-controlled content, and because the resulting code execution is confined to the renderer sandbox, full host compromise would require chaining a separate sandbox-escape flaw. A vendor patch is available in the Chrome Stable channel update, and no public exploit has been identified at time of analysis - this is a high-priority patching item rather than an emergency.
Arbitrary code execution confined to the renderer sandbox in Google Chrome builds prior to 155.0.8059.39, reachable when a user opens a crafted HTML page that drives the DevTools state-validation path into an inconsistent state. The flaw is network-delivered and requires no authentication (CVSS:3.1/AV:N/AC:L/PR:N), but exploitation is gated by mandatory user interaction (UI:R), which is why CISA's SSVC decision framework rates it as not automatable. No public exploit code and no confirmed active exploitation were identified at time of analysis; Google rates the Chromium severity as High and has shipped a fixed build, so the practical exposure is limited to unpatched clients that have not yet received the auto-update.
Use-after-free in Google Chrome's Media component allows a remote attacker to execute arbitrary code inside the browser's renderer sandbox by luring a victim into loading a crafted HTML page in any Chrome build prior to 155.0.8059.39. The flaw is rated CVSS 8.8 (AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H), consistent with Google's own 'High' Chromium security severity, and requires no authentication or privileges on the victim host beyond the user visiting the malicious content (UI:R). Exploitation is confirmed to be constrained by user interaction and by the renderer sandbox - CISA SSVC scores it Exploitation: none, Automatable: no, Technical Impact: total - and there is no public exploit identified at time of analysis, though a vendor-released patch is available.
Use-after-free in Google Chrome's parser allows remote, unauthenticated attackers to execute arbitrary code inside the renderer sandbox by convincing a victim to load a crafted HTML page, affecting all Chrome versions prior to 155.0.8059.39. Exploitation requires user interaction (the victim must visit or open the malicious page), and the resulting code execution is contained by Chrome's renderer sandbox, so full host compromise would require chaining with a separate sandbox-escape vulnerability. A vendor patch is available in 155.0.8059.39, and no public exploit identified at time of analysis, with CISA's SSVC assessment recording exploitation as none.
Remote code execution inside the renderer sandbox is possible in Google Chrome builds prior to 155.0.8059.39, where a use-after-free in the Media component can be triggered by a crafted HTML page. Exploitation requires the victim to load attacker-controlled web content (UI:R) but no authentication or special privileges (PR:N), so default desktop installs are affected; resulting code execution is contained within the renderer sandbox rather than the host operating system. At time of analysis there is no public exploit identified at time of analysis per available intelligence (SSVC exploitation: none, automatable: no), and a vendor patch is available from Google. Rated CVSS 8.8 (AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H) and Chromium security severity High, this is a genuine high-priority patching item, though the signals are mixed on urgency.
A use-after-free in Chrome's Metrics component (CWE-416) lets an attacker who has already compromised a sandboxed renderer process execute arbitrary code outside the sandbox - a sandbox-escape primitive rather than an initial-access bug. Only users running Chrome versions below 155.0.8059.39 are affected; the flaw is unauthenticated from the network perspective (PR:N) but requires the victim to load attacker-controlled crafted HTML (UI:R) and carries High attack complexity (AC:H) because the attacker must win a use-after-free race and defeat sandbox mitigations. Google has released a fix in Chrome 155.0.8059.39, no public exploit code has been identified at time of analysis, CISA SSVC records Exploitation: none, and the overall posture is patch-promptly-but-not-emergency rather than urgent.