Authenticated users of Twisted-based IMAP4 servers (Twisted 25.5.0 and earlier running the twisted.mail.imap4 server component) can stall the entire service by supplying a crafted LIST or LSUB mailbox pattern whose regex metacharacters survive wildcardToRegexp() and reach re.compile(), triggering catastrophic backtracking. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L, base 4.3) confirms this is a network-reachable availability issue that requires valid credentials and has no impact on confidentiality or integrity. Because Twisted's cooperative single-threaded reactor performs the match inline, a single expensive match suspends all server input and output for its duration; no public exploit code has been identified at time of analysis, and this is a genuine but modest-priority issue rather than a top-tier emergency.
Gitea through 1.27.3 grants the named recipient of a private-repository transfer temporary read collaborator access so they can review the repository, but rejecting or cancelling that transfer never revokes the collaboration, leaving the recipient with persistent read access to the private repository's code, issues, pull requests and wiki, including the ability to clone it, without any notification to the repository owner. Exploitation requires the repository owner to initiate a transfer of a private repository to a specific authenticated Gitea user who lacks prior access, and the affected party is that designated recipient rather than an arbitrary user; it is not attacker-initiated against default configurations. Severity is moderate (assessed CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N; published base score 4.3) with no public exploit identified at time of analysis and a low EPSS of 0.27% (17th percentile). Vendor-released patch: Gitea 28.0.0.
An origin-policy bypass in Chrome's DeviceBoundSessionCredentials component allows remote attackers to make the browser act as a confused deputy for an untrusted site via a crafted HTML page, affecting Chrome builds prior to 155.0.8059.39 (Chromium security severity: Low, CVSS 4.3). Exploitation is network-reachable and requires no attacker authentication (PR:N), but it depends entirely on the victim navigating to an attacker-controlled page (UI:R) and is limited to an integrity impact on web origin rules (C:N/I:L/A:N). No public exploit code has been identified at time of analysis, the issue is not in CISA KEV, and EPSS is low at 0.24% (13th percentile), which is consistent with the low-priority assessment of this defect.
Cross-origin information disclosure in Google Chrome's Payments component (all platforms, versions prior to 155.0.8059.39) allows an unauthenticated remote attacker to obtain limited cross-origin data by luring a victim to a crafted HTML page; exploitation requires the victim to actively visit or load the attacker's content (CVSS vector AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N, base score 4.3). There is no integrity or availability impact and no scope change - the leak is confined to read-only disclosure of payment-related cross-origin data in the victim's browser session. The issue is not in CISA KEV and no public exploit code has been identified at time of analysis, and CISA's SSVC assessment scores exploitation as none and automatable as no, indicating a low-to-moderate practical risk rather than an urgent, wormable threat; a vendor patch is available in Chrome 155.0.8059.39.
Information disclosure in Google Chrome versions prior to 155.0.8059.39 allows a remote, unauthenticated attacker who convinces a victim to open a crafted HTML page to read data belonging to other origins, bypassing the browser's same-origin boundary. Exploitation requires user interaction (UI:R) but no privileges, and default Chrome installations are exposed because the vulnerable Media code path is standard browser functionality; the impact is confidentiality-only, consistent with a CVSS base score of 4.3. No public exploit code has been identified at time of analysis and CISA's SSVC records no known exploitation, so the practical risk is concentrated in unpatched endpoints rather than active attacks; Google has shipped a fixed build.
Missing authorization checks in Google Chrome's Google Lens component let a remote attacker read cross-origin data when a victim loads a crafted HTML page, affecting Chrome builds prior to 155.0.8059.39. The practical hurdle is steep: the attacker must already hold a compromised renderer process (a separate sandbox-bypass prerequisite not reflected in the PR:N metric), and the victim must be induced into loading the malicious page, which confines real-world risk to low-sensitivity information disclosure. No public exploit has been identified at time of analysis, CISA's SSVC assessment rates exploitation as 'none' with automation judged not feasible, and the technical impact is partial - making this a low-priority issue despite Chromium's 'Medium' severity label.
Cross-origin data leakage in Google Chrome before 155.0.8059.39 stems from incorrect reference resolution in the browser's Core component, allowing a remote attacker to read data belonging to another origin through a crafted HTML page. Exploitation is not silent: it requires the victim to visit an attacker-controlled or compromised page (UI:R), typically reached via phishing or a malicious link, and no privileges are needed on the target (PR:N). The impact is limited to confidentiality (C:L) with no memory corruption, code execution, integrity, or availability effect, and no public exploit has been identified at time of analysis - this is a genuinely low-priority issue despite being network-reachable.
Missing authorization in Kibana's Metrics Experience feature lets an authenticated user who holds only Elasticsearch index-level read privileges - but no corresponding Kibana feature privilege - pull back index-derived metric data that a correctly protected sibling API would have blocked. Exploitation requires valid credentials (CVSS PR:L, remote, no user interaction) and is confined to information disclosure (C:L), giving a modest CVSS 3.1 base score of 4.3. Kibana installations running 9.4.0 or later are not affected, and no public exploit code or active exploitation has been identified at time of analysis.
Cross-origin information disclosure in Google Chrome's Glic integrated AI assistant component allows a remote attacker to leak data from other origins by convincing a victim to open a crafted HTML page; the flaw is an incomplete-cleanup bug (CWE-459) affecting Chrome builds prior to 155.0.8059.39. The attack is remote but requires user interaction (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N, base 4.3), and impact is limited to low-sensitivity read access with no integrity or availability effect, so the practical risk is low. There is no public exploit identified at time of analysis, CISA SSVC records no known exploitation and marks the issue as not automatable, and the vendor has already shipped a fix in the stable channel.
Inconsistent property-permission matching in the @backstage/plugin-catalog-backend package (Backstage releases prior to the fix) allows an authenticated user to receive catalog entity data that policy authors intended to restrict, because value-based catalog permission conditions evaluate keys and values inconsistently. Exposure is limited to deployments that use these value-based property conditions as a confidentiality boundary; installations without such value-based restrictions are not affected, and no public exploit has been identified at time of analysis. The issue is rated CVSS 4.3 (low severity, information disclosure only) and is fixed in @backstage/plugin-catalog-backend 3.9.1, shipped with Backstage release v1.54.6.
Incorrect authorization in the Backstage scaffolder backend (@backstage/plugin-scaffolder-backend) prior to 4.1.0 lets an authenticated user with a valid portal account list scaffolder task metadata that the deployment's permission policy intended to restrict, yielding low-impact information disclosure (CVSS 3.1 base 4.3, PR:L - authentication requirements confirmed by the vector, which contains PR:L). Exposure is confined to task metadata because stored task secrets are not part of the affected response, and deployments that do not enforce a restrictive task visibility policy have essentially nothing to leak. No public exploit code was identified at time of analysis and the issue is not listed in CISA KEV; a vendor-released patch is available in version 4.1.0.
Cross-origin data disclosure in Google Chrome's Skia graphics engine allows a remote attacker to read limited amounts of data belonging to other origins by getting a victim to open a crafted HTML page. The flaw is an uninitialized-resource bug (CWE-908) that affects Chrome builds prior to 155.0.8059.39 running on default configurations; no authentication or special privileges are needed, but exploitation hinges entirely on user interaction (UI:R) since the victim must load the attacker's page, which is why the overall severity is only CVSS 4.3 with confidentiality impact limited to C:L and no integrity or availability effect. No public exploit code has been identified at time of analysis and there is no confirmed active exploitation (CISA KEV), though the vendor has shipped a fixed release and the underlying bug is tracked as a High-severity Chromium security issue.
Cross-origin information disclosure in Google Chrome's ANGLE graphics layer affects builds prior to 155.0.8059.39, letting a remote, unauthenticated attacker read limited data belonging to other origins when a victim loads an attacker-crafted HTML page. The bug is an uninitialized-resource flaw (CWE-908) that Chromium rates 'High' on its internal severity scale, but the CVSS 3.1 vector (4.3, AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N) confines impact to partial confidentiality loss and requires the victim to actively open the page. No public exploit identified at time of analysis, and there is no confirmed actively exploited (CISA KEV) signal; a vendor-released patch, Chrome 155.0.8059.39, is available.
Google Chrome releases earlier than 155.0.8059.39 ship an API whose authorization checks are incorrect, letting a remote attacker bypass web origin policy by getting a victim to open a crafted HTML page. No authentication or non-default setting is required (PR:N), but this is not drive-by exploitation - the target must navigate to the attacker's page (UI:R), and the assessed impact is a single low-severity confidentiality/integrity metric with no availability loss, matching Chromium's own 'Low' severity rating and the modest 4.3 base score. There is no public exploit identified at time of analysis, EPSS is only 0.19% (8th percentile), and a vendor patch is available, so this is a routine patch-cycle item rather than an urgent one.
Incorrect authorization in Google Chrome's Scheduling component prior to version 155.0.8059.39 allows a remote attacker to bypass the browser's web origin policy by convincing a victim to load a crafted HTML page. Exploitation requires user interaction - the target must actively navigate to the attacker-controlled page (UI:R per the assessed CVSS vector) - but needs no authentication or privileges (PR:N), and the resulting impact is limited to integrity (I:L) with no confidentiality or availability effect. There is no public exploit code identified and no evidence of active exploitation at time of analysis, and the EPSS score of 0.19% (8th percentile) confirms a low likelihood of imminent exploitation; a vendor patch is available.
Cross-origin data leakage in Google Chrome is possible when a victim opens a crafted HTML page that triggers a race condition in the browser's WebAudio implementation; the issue affects all Chrome builds prior to 155.0.8059.39 on every platform covered by the generic CPE cpe:2.3:a:google:chrome:*:*:*:*:*:*:*:*. The impact is confidentiality-only and low severity (CVSS 4.3, CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N), requiring the user to interact with attacker-supplied content before any data can be exposed, and no public exploit code has been identified at time of analysis, with CISA's SSVC assessment recording exploitation as 'none', automatability as 'no', and technical impact as 'partial'. Google has released a vendor patch in Chrome 155.0.8059.39, so this is best handled as a low-to-moderate priority update rather than an emergency response, as reflected in our assessment that this is a genuinely low-to-moderate priority issue despite being in ubiquitous software.
Cross-origin data disclosure in Google Chrome desktop (Compositing component) affects builds prior to 155.0.8059.39, where a remote attacker can use a crafted HTML page to exploit an integer overflow and read limited data belonging to another origin. Exploitation is not passive: per the assessed vector (AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N) the victim must load the attacker-controlled page, so a malicious-site, malvertising, or social-engineering delivery is required, and the impact is confined to low-confidentiality leakage with no integrity or availability effect. No public exploit code has been identified at time of analysis - this is not on CISA KEV - and the vendor patch is already available, meaning the effective window is mostly determined by how quickly browsers auto-update; despite the 'High' Chromium internal severity label, this is a moderate-severity, low-real-risk issue.
Cross-origin data leakage in Google Chrome prior to 155.0.8059.39 allows a remote attacker to read limited data belonging to other origins by convincing a user to load a crafted HTML page that drives the browser's Paint component into an observable rendering discrepancy (CWE-203). The vulnerability carries a CVSS 3.1 base score of 4.3 (AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N), meaning exploitation requires no credentials or privileges but does require the victim to actively load attacker-controlled markup, and the resulting impact is confined to confidentiality with no integrity or availability effect on default configurations. At time of analysis there is no public exploit identified, the issue is not referenced as confirmed actively exploited (CISA KEV), and a vendor-released patch is available in Chrome 155.0.8059.39, making this a low-to-moderate priority update rather than an emergency response, despite Chrome's ubiquity.
Information disclosure in Google Chrome lets a remote attacker who convinces a victim to open a crafted HTML page leak cross-origin data from vulnerable builds prior to 155.0.8059.39, exposing limited confidentiality across the same-origin policy boundary. The flaw lives in the Animation component and cannot be used for code execution or data tampering; it requires user interaction and no privileges (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N, 4.3). No public exploit code has been identified at time of analysis and the issue is not confirmed actively exploited (CISA KEV); CISA's SSVC assessment rates exploitation as none, automation as not possible, and technical impact as partial, making this a low-urgency update item rather than an emergency.
Cross-origin data exposure in the WebAudio implementation of Google Chrome lets a remote attacker leak limited information from other origins when a victim loads a crafted HTML page in any Chrome build prior to 155.0.8059.39. Exploitation requires the target user to actively navigate to the attacker-controlled page (CVSS 3.1 AV:N/AC:L/PR:N/UI:R, confidentiality-only, partial impact, base score 4.3), so the flaw is a low-to-moderate priority information-disclosure issue rather than a code-execution or full-data-compromise primitive. There is no confirmed active exploitation (not in CISA KEV) and no public exploit code identified at time of analysis, and CISA's SSVC evaluation rates the issue as not automatable with only partial technical impact.
Information disclosure in Google Chrome before 155.0.8059.39 allows a remote attacker to leak sensitive information from the browser when a victim loads a crafted HTML page that exercises the Sanitizer API, exploiting an implementation that does not deliver the functionality as specified. The attack requires no authentication (PR:N) but does require the user to open attacker-controlled web content (UI:R), and the impact is confined to low confidentiality with no integrity or availability effect, yielding a CVSS 3.1 base score of 4.3 and a Chromium-assigned severity of Low. No public exploit code has been identified at time of analysis and CISA's SSVC decision framework rates exploitation as none, so this is a low-priority update-and-move-on issue rather than an urgent threat.
Information disclosure in Google Chrome's Editing component prior to version 155.0.8059.39 lets a remote, unauthenticated attacker leak sensitive data out of the browser by persuading a victim to open a crafted HTML page. Exploitation requires the user to actively navigate to the attacker-controlled page (UI:R), and the outcome is limited to confidentiality loss - no code execution, data modification, or denial of service - which is why the flaw is rated Medium (CVSS 4.3, CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N) and carries Chromium's 'Medium' security severity. No confirmed active exploitation (no CISA KEV listing) and no public exploit code were identified at time of analysis, and a vendor-released patch (155.0.8059.39) is available, so risk is primarily tied to unpatched fleets where social-engineering delivery remains viable.
Sensitive information can be leaked from Google Chrome's Paint rendering component in all versions prior to 155.0.8059.39 when a victim loads a crafted HTML page, exposing data that should have remained protected within the browser's rendering pipeline. The attack is network-delivered and needs no attacker credentials (PR:N, AV:N), but it is gated by a mandatory user-interaction step (UI:R) - the victim must actively navigate to attacker-controlled HTML - and the resulting impact is limited to partial confidentiality loss with no integrity or availability effect, which is why the assigned CVSS is only 4.3. No public exploit code and no confirmed active exploitation were identified at time of analysis, and Chrome's automatic update mechanism combined with the narrow leak-only impact keeps realistic exposure low-to-moderate.
Cross-origin data exposure in Google Chrome before 155.0.8059.39 lets an unauthenticated remote attacker leak limited data from other origins by getting a victim to open a crafted HTML page that abuses an Extensions resource-exposure weakness. The issue is confidentiality-only and rated medium (CVSS 4.3, AV:N/AC:L/PR:N/UI:R/C:L/I:N/A:N), so exploitation depends on user interaction and yields only low-value data rather than code execution or integrity loss. No public exploit code was identified at time of analysis and CISA KEV does not list this CVE; a vendor patch is available in the 155.0.8059.39 stable release, and any user already on that build or later is not affected.
Information disclosure in the Enterprise component of Google Chrome allows a remote attacker to leak sensitive information from affected browsers when a victim opens a crafted HTML page. Only Chrome versions prior to 155.0.8059.39 are affected; the CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N) confirms a network-reachable, unauthenticated attack that nonetheless requires the user to actively load attacker-controlled content, so there is no zero-click path and the impact is limited to confidentiality with no integrity or availability effect. CISA's SSVC assessment records no known exploitation and no automatable vector, and no public exploit has been identified at time of analysis; the issue is rated Chromium security severity Medium and is addressed by the vendor's stable channel update.
Incorrect authorization in the DevTools component of Google Chrome before 155.0.8059.39 lets a remote attacker leak cross-origin data by luring a victim into opening a crafted HTML page. The attack is network-delivered and requires no authentication, but it depends on social engineering and successful user interaction (CVSS UI:R), which is the main limiting factor; impact is confined to limited confidentiality disclosure with no integrity or availability effect. No public exploit code or active exploitation has been identified at time of analysis, patch status is vendor-available, and the Chromium security severity is Low, making this a genuinely low-priority issue with consistent signals rather than conflicting ones.
Google Chrome versions prior to 155.0.8059.39 are affected by an incorrect authorization weakness in the Media component that enables a remote, unauthenticated attacker to leak limited cross-origin data when a victim loads a crafted HTML page. The CVSS vector (AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N, score 4.3) confirms that exploitation hinges on user interaction and results only in confidentiality impact, with no integrity or availability effects; CISA's SSVC assessment rates exploitation as 'none' and technical impact as 'partial', and no public exploit code has been identified at time of analysis. Vendor patches are available in the Chrome 155.0.8059.39 stable channel release.
Improper CORS handling in Google Chrome versions prior to 155.0.8059.39 allows a remote attacker to bypass the browser's web origin policy by delivering crafted cross-origin network traffic to a victim who visits attacker-controlled content (UI:R). The assessed vector (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N, 4.3) shows no authentication requirement but a mandatory user-interaction step and integrity-only impact, matching Chromium's own 'Low' severity rating; there is no public exploit identified at time of analysis and EPSS is negligible at 0.17% (6th percentile). Risk is further reduced by Chrome's silent auto-update channel, which quickly shrinks the exposed population.
Cross-origin data disclosure in Google Chrome before 155.0.8059.39 results from incorrect authorization logic in the browser's Extensions component, which lets a specially crafted Chrome extension read data across origin boundaries that the extension permission model should have blocked. Reaching the flaw requires a remote attacker to convince a victim to install that crafted extension (UI:R); the extension itself needs no elevated privileges (PR:N), and the resulting impact is limited to confidentiality (C:L) with no integrity or availability effect, so data cannot be altered and the browser cannot be crashed. There is confirmed actively exploited status is not present - no CISA KEV listing - and no public exploit code identified at time of analysis, with SSVC scoring Exploitation: none, Automatable: no, Technical Impact: partial, and Chromium rating the issue Medium severity.
Missing authorization checks in the WordPress plugin WDS MCP Content Manager (versions up to and including 3.10.4) let an authenticated Contributor-level user invoke functionality that should be reserved for higher-privileged roles, enabling limited unauthorized modification of plugin-managed content and settings. Exploitation requires only a Contributor account - a role that is trivially obtained on multi-author blogs and sites with open registration - needs no user interaction, and is reachable over the network, but the resulting impact is confined to a low-integrity change with no confidentiality or availability loss. No public exploit code has been identified at time of analysis, and the 'Authentication Bypass' tag is somewhat overstated: this is an authenticated privilege/authorization gap, making it a low-to-moderate priority issue rather than a critical one.
Gitea through 28.0.0 fails to apply profile visibility checks when a profile page is requested through content negotiation, allowing unauthenticated remote attackers to confirm the existence of limited or private users and private organizations and to read their profile details and public activity feed. A simple GET request to /{username} carrying an 'Accept: application/rss+xml' or 'Accept: application/atom+xml' header bypasses the checks used by the normal profile page and the explicit .rss/.atom routes, and the bypass also works when the '[other] ENABLE_FEED' setting is turned off; activity in private repositories is not disclosed. There is no public exploit code and no indication of active exploitation (EPSS 0.15%, 3rd percentile), so real-world risk is low, and the issue is fixed in Gitea 28.1.0.
Authorization bypass in Gitea's issue attachment API (CVE-2026-105268) lets an authenticated user who authored an issue rename or delete attachments that other users posted in comments on that same issue, because the endpoint `/api/v1/repos/{owner}/{repo}/issues/{index}/assets/{attachment_id}` failed to exclude comment-owned attachments from the set the issue author is allowed to manage. Only metadata operations (rename/delete) are possible - attachment contents cannot be altered (C:N), and no data outside the attacker's own repository scope is reachable. Rated CVSS 4.3 (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N) with an EPSS of 0.15% (3rd percentile) and an SSVC assessment of Exploitation:none / Automatable:no / Technical Impact:partial, so no public exploit was identified at time of analysis; this is a low-priority integrity/data-destruction defect, not a confidentiality or code-execution issue.
Server-side request forgery in Gitea's repository migration feature lets an authenticated user who is permitted to start migrations force the Gitea server to connect to reserved or link-local addresses, including the cloud metadata endpoint 169.254.169.254. The flaw only manifests in a non-default configuration where the administrator has set [migrations] ALLOWED_DOMAINS to a wildcard such as `*` or a hostname wildcard, which bypasses the intended ALLOW_LOCALNETWORKS = false protection because the local-network block list omitted reserved/link-local ranges and hostname allow-list matching was accepted irrespective of the resolved IP. Impact is bounded to reachability and read-style access from the server (no code execution or data modification), authentication is required per the CVSS vector (PR:L), and no public exploit has been identified at time of analysis, so this is a low-to-moderate priority issue whose real-world severity rises mainly where a reachable instance metadata service exists on the Gitea host.
Authenticated low-privileged users on self-hosted Gitea through 1.27.3 can bypass the repository migration and pull-mirror egress checks by supplying a hostname with multiple DNS answers, so the address Gitea validates is not necessarily the address Git later connects to. This lets an attacker with migration or mirror creation rights reach internal Git or HTTP endpoints on the server's network, with limited read and write impact (assessed CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:L/A:N), and internal response content may additionally leak through migration and mirror error messages (CWE-209). Exploitation is non-deterministic and depends on winning a multi-answer DNS race plus a reachable internal target, and no public exploit code was identified at time of analysis; EPSS is 0.12% (2nd percentile), CISA SSVC rates exploitation as none and the issue as not automatable.
OpenSSH servers prior to 10.6 fail to enforce the 'restrict' keyword in authorized_keys against tunnel (tun/tap) forwarding, letting a user who already holds a restricted key open a forwarding tunnel that the administrator explicitly intended to block. This is a control-bypass rather than an access-control failure: the attacker must already possess a valid SSH key provisioned with 'restrict' (assessed CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:N), and the flaw only matters on servers older than 10.6 where tunnel forwarding was the specific capability the keyword was relied on to deny. Impact is limited to integrity (establishing the forwarding channel) with no confidentiality or availability loss, the base score is 2.5, and no public exploit code or CISA KEV activity is identified at time of analysis.
UI spoofing in Google Chrome builds prior to 155.0.8059.39 lets an attacker who has already compromised the browser's renderer process present falsified interface elements to the victim through a crafted HTML page. The precondition of an existing renderer foothold, combined with required user interaction and the high attack complexity of reliably triggering the underlying use-after-release on a Session object, sharply limits practical exploitation - the realized effect is spoofed UI, not code execution or data theft. No public exploit code has been identified at time of analysis, CISA's SSVC assessment records exploitation as none, and Google classifies the underlying Chromium issue as low severity, making this a routine, low-priority patching item.
UI spoofing in Google Chrome (all versions prior to 155.0.8059.39) lets an attacker who has already compromised the renderer process fake browser interface elements - such as dialogs, permission prompts or address-bar style chrome - in front of the user via a crafted HTML page. The weakness is a use-after-free of a released resource (CWE-672) in UI code: unauthenticated from a network standpoint (PR:N), but gated behind a prior renderer compromise, mandatory user interaction (UI:R) and non-trivial timing/state conditions (AC:H). Independent assessment scores it CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:L/A:N - strictly a user-interface integrity issue with no confidentiality or availability impact - and Chromium rated it Low. No public exploit code and no confirmed active exploitation were identified at time of analysis; a vendor patch is available in Chrome 155.0.8059.39.
Address bar spoofing in Google Chrome versions prior to 155.0.8059.39 lets an attacker who has ALREADY compromised the browser's renderer process display a falsified URL in the address bar via a crafted HTML page, so that a victim who views or interacts with that page is misled about which site they are visiting. This is a secondary, post-exploitation primitive rather than a standalone remote vulnerability: it requires a working renderer-compromise chain plus user interaction (CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:L/A:N, base 4.2), and the impact is bounded to UI/URL spoofing with no direct code execution or data exfiltration from this flaw alone. There is no confirmed active exploitation (not in CISA KEV) and no public exploit code identified at time of analysis; EPSS/KEV signals are absent, and the upstream Chromium severity is Medium.
Missing authorization checks in the Permissions component of Google Chrome allow a remote attacker to spoof UI elements through a crafted HTML page, but only after that attacker has already compromised the browser's sandboxed renderer process. The flaw affects Chrome builds prior to 155.0.8059.39 and requires the victim to load the attacker-supplied page (CVSS 3.1: 4.2, AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:L); it does not by itself grant code execution, sandbox escape, or data exfiltration beyond limited confidentiality impact. Exploitation is rated 'none' under CISA SSVC, no public exploit code has been identified, and a vendor patch is available in Chrome 155.0.8059.39, so this is a low-priority, chained post-exploitation issue rather than a standalone remote threat.
Incomplete cleanup in Chrome's GetUserMedia camera/microphone permission flow before version 155.0.8059.39 allows an attacker who has already compromised the renderer process, and who lures the victim to a crafted HTML page using social engineering, to spoof UI elements associated with media-capture prompts; Chromium rates it Medium and the assessed CVSS is 4.2 (AV:N/AC:H/PR:N/UI:R/C:L/I:N/A:L). The layered prerequisites - a pre-existing renderer compromise plus active user deception - make this a post-compromise, targeted scenario rather than an opportunistic mass attack, and SSVC records exploitation as none with no public exploit code identified at time of analysis. Google has released a vendor patch in Chrome 155.0.8059.39.
Site isolation bypass in Google Chrome versions prior to 155.0.8059.39 allows an attacker who has already compromised a renderer process to abuse the BrowserTag component and cross site boundaries when the victim interacts with a crafted HTML page. The issue is a missing authorization check (CWE-862) rated CVSS 4.2 (AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:L/A:N) and Chromium security severity Medium; it is unauthenticated from the network perspective and requires user interaction plus social engineering, with impact limited to Low confidentiality and Low integrity and no availability effect. Risk signals are consistent and low: EPSS is 0.19% (8th percentile), no CISA KEV listing, and no public exploit code identified at time of analysis, making this a defense-in-depth concern rather than a front-line threat. A vendor patch is available in Chrome 155.0.8059.39.
Missing authorization in the Translate component of Google Chrome before 155.0.8059.39 lets a remote attacker bypass site isolation via a crafted HTML page, but only after the renderer process has already been compromised by a separate flaw. The assessed vector (CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:L/A:N, 4.2) requires victim interaction and high attack complexity, and the bug grants no initial access on its own; there is no public exploit identified at time of analysis and EPSS is 0.19% (8th percentile). The 'High' Chromium security severity reflects impact within Chrome's security model, not real-world exploitability.
UI spoofing in Google Chrome on Android (versions prior to 155.0.8059.39) stems from incorrect authorization handling in the WebShare feature and allows a remote attacker who has already compromised the renderer process to spoof UI elements via a crafted HTML page that the victim must interact with. The assessed impact is limited to integrity spoofing (CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:L/A:N), with no confidentiality or availability impact, and no public exploit identified at time of analysis. Exploitation is gated by the non-default prerequisite of a compromised renderer plus required user interaction, making this a low-priority issue despite the medium Chromium severity label.
UI spoofing in Google Chrome versions prior to 155.0.8059.39 allows a remote attacker who has already compromised the browser's renderer process to draw deceptive interface elements (for example convincing fake prompts, dialogs, or origin indicators) by delivering a crafted HTML page that the victim must interact with. Google rates this as a Medium-severity Chromium issue with a CVSS 3.1 base of 4.2, and the assessed vector (AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:L/A:N) confirms only low integrity impact - no confidentiality or availability loss - with high attack complexity and no privileges required. No public exploit code and no confirmed active exploitation were identified at the time of analysis; the pre-existing renderer compromise prerequisite plus required user interaction keeps real-world risk low, making this primarily a defense-in-depth fix.
Missing authorization checks in the Permissions component of Google Chrome prior to 155.0.8059.39 let a remote attacker who has already compromised the browser's renderer process spoof UI elements by way of a crafted HTML page. The attack is network-reachable and unauthenticated (CVSS:3.1/AV:N/PR:N) but requires high attack complexity (AC:H) and victim interaction (UI:R), and impact is limited to low confidentiality and availability effects (C:L/I:N/A:L, base score 4.2). There is no public exploit identified at time of analysis and no evidence of exploitation in CISA KEV; CISA's SSVC assessment rates exploitation as 'none' and automatable as 'no', so this should be treated as a low-priority hardening item rather than an urgent threat. Google has shipped a fix in Chrome 155.0.8059.39.
UI spoofing in Google Chrome desktop versions prior to 155.0.8059.39 lets an attacker who has already compromised the renderer process win a race condition and draw forged browser UI on top of legitimate chrome, potentially tricking a victim into trusting a deceptive dialog, prompt, or page indicator. The published CVSS 3.1 base score is 4.2 (AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:L), and our independent assessment narrows the realistic impact further to integrity-only (I:L) with no confidentiality or availability effect; regardless of scoring, the operationally decisive constraint is that the attacker must first hold a renderer compromise, making this a post-exploitation secondary primitive rather than a standalone remote attack. No public exploit code was identified at time of analysis, there is no CISA KEV listing, and CISA's SSVC decision framework rates exploitation as 'none' and the attack as not automatable, so this is a low-priority hardening item for environments already patched against renderer RCE bugs.
Backstage deployments prior to 1.54.6 that use Azure Blob Storage or AWS S3 catalog sources can be induced to read catalog descriptors from outside the configured storage boundary - an object-storage path traversal in the cloud storage catalog providers and cloud URL readers. Exploitation requires an authenticated principal with high privileges (CVSS PR:H) who already has permission to create or rename objects in the trusted catalog bucket or container, and who then crafts object names containing dot-path segments (including encoded forms such as %2e%2e or backslash-delimited variants) to escape the intended prefix; the read is limited to locations reachable with the backend's own configured storage credentials, and impact is confidentiality-only (CVSS 3.0, AV:N/AC:H/PR:H/S:C/C:L/I:N/A:N). No public exploit code has been identified at time of analysis and the issue is not listed in CISA KEV; a vendor-released patch is available in 1.54.6.
The @quasar/app-vite build tooling (versions 1.0.0 through pre-3.3.0) recursively deletes the resolved build.distDir path before compilation without validating that the target is a safe location, so a dangerous distDir setting - a filesystem root, the user's home directory, the project root, or a symlink resolving outside the project - can cause destructive deletion of data writable by the build user. Authentication and interaction are constrained: per the assessed vectors (CVSS:4.0/AV:L/AC:H/AT:P/PR:H/UI:A and CVSS:3.1/AV:L/AC:H/PR:H/UI:R) this requires local, high-privileged access and deliberate build invocation, and no attacker-controlled input reaches build.distDir by default, so exploitation depends on compromised or less-trusted automation influencing the build configuration or a developer authoring a mistaken configuration. This is a low-to-medium real-world risk that should NOT be treated as an urgent priority; no public exploit code and no confirmed active exploitation (CISA KEV) were identified at time of analysis, and the impact is bounded to availability (data loss), with no confidentiality or integrity impact in the assessed vector.
Memory disclosure in Google Chrome versions prior to 155.0.8059.39 allows an attacker who has already compromised the browser's renderer process to use a crafted Chrome extension to read memory outside the sandbox in the Audio component. Because the renderer must be pre-compromised through a separate exploit and the impact is confidentiality-only (CVSS 4.0, AV:N/AC:H/PR:N/UI:N/S:C/C:L/I:N/A:N), this is a chainable sandbox information-leak primitive rather than a self-contained remote compromise, and its high attack complexity reflects non-trivial preconditions such as a specific memory state. Google has released a fixed build, EPSS is low at 0.16% (5th percentile), and no public exploit code has been identified at time of analysis.
Filename-based upload restrictions can be bypassed in applications that parse multipart/form-data uploads and enforce security-relevant filename rules using only the standard Content-Disposition 'filename' parameter, because the RFC 2231 extended 'filename*' parameter can carry a different, restricted value that a downstream component may consume instead. Tracked as GHSA-5pww-8rfg-9crf and reported through the vendor:ubuntu channel, the issue carries a limited-integrity impact profile (independent assessment CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N), meaning an unauthenticated network attacker can influence which file name value is acted upon but cannot read data or cause denial of service. No affected product, version range, CPE, patch, or public exploit information was supplied, so exploitation is assessed as no public exploit identified at time of analysis.