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.
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.
Credentials can incorrectly persist after a failed GSSAPIAuthentication attempt in the sshd daemon of OpenSSH before 10.6, allowing an authentication context that should have been discarded to remain usable and potentially granting access under another identity (CWE-669, integrity impact). Only hosts that explicitly enable GSSAPIAuthentication are affected, since the OpenSSH default is 'no', so exposure is largely limited to Kerberos/GSSAPI-integrated environments; the flaw is fixed in OpenSSH 10.6. No public exploit code has been identified at time of analysis, EPSS is negligible (0.08%), and CISA SSVC records no observed exploitation and rates the issue as non-automatable with partial technical impact, so real-world risk is moderate despite the 7.5 'High' base score.
Uncontrolled recursion in yawkat LZ4 Java's net.jpountz.lz4.LZ4BlockInputStream can crash the decoding thread: when the stream is explicitly configured with stopOnEmptyBlock set to false, each well-formed empty LZ4 block causes refill() to call itself recursively, so an attacker-supplied compressed stream containing a long run of empty blocks drives the stack to exhaustion and throws StackOverflowError. Only applications that both use LZ4BlockInputStream with the non-default stopOnEmptyBlock=false setting and feed it attacker-controlled or injectable compressed data are exposed; the default stopOnEmptyBlock=true is not affected, no authentication or user interaction is required under those conditions (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L), and impact is limited to availability of the decoding thread with no memory corruption, confidentiality, or integrity effect. There is no public exploit identified at time of analysis and the flaw is fixed in version 1.11.4.
The sshd and ssh components of OpenSSH before 10.6 can be made to negotiate and use the LZ77 dictionary-coder compression scheme, a behavior the 'Crossing the Streams' research (arXiv 2609.07709) identifies as contraindicated because compression-derived information leakage can be measured from an observed session. A remote, unauthenticated attacker who can observe and influence the target connection and repeatedly sample it may recover a limited amount of confidential data, but only where the vulnerable compression mode is actually in use; integrity and availability are unaffected. This is a low-severity, low-priority issue (CVSS 3.1 base 3.7; AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N) despite being network-reachable and unauthenticated, because exploitation demands an active compression configuration, a privileged observation vantage point, and sustained measurement - no public exploit code has been identified at time of analysis and there is no confirmed active exploitation (CISA KEV).
URL injection and server-side request forgery (SSRF) in i18next-http-backend prior to 4.0.2 allows attacker-controlled language or namespace values to redirect translation resource requests away from the intended origin, but only when the application configures a custom loadPath or addPath template that begins directly with the {{lng}} or {{ns}} placeholder. Because the placeholder must occupy the URL's structural beginning for a colon to form an absolute URL (or, in browsers, a double-slash namespace to form a protocol-relative URL), the default '/locales/{{lng}}/{{ns}}.json' template and any template with a leading path or origin prefix are unaffected; this uncommon configuration and the need to control the language/namespace input drive the High attack complexity rating. Impact is limited to low confidentiality loss (blind SSRF/URL injection with no integrity or availability effect), and all signals indicate a low-priority issue - no public exploit code and no confirmed active exploitation were identified at time of analysis. The issue is fixed in version 4.0.2.
Improper input validation (CWE-20) in HCL BigFix Service Management lets an attacker who already holds a low-privilege authenticated account on the adjacent network submit unexpected or malformed data, producing processing errors, limited business-logic bypasses, and unintended application behavior. The assessed vector (CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N, score 3.5) confines impact to a low-integrity effect with no confidentiality or availability loss, and exploitation requires both adjacency to the deployment and an existing account, so this is a low-severity, low-priority item despite being a published CVE. No public exploit code or CISA KEV listing was identified at time of analysis, and no EPSS score was supplied; HCL's own tag of 'Authentication Bypass' is broader than the assessed integrity-only impact and should not be read as a full authentication defeat.
Ubuntu Linux carries CVE-2026-55453, a security issue that has so far been reported only by the vendor (Ubuntu) with no published description, no CVSS score or vector, no CWE classification, and no CPE or version data. Because the flaw is entirely undisclosed, it is not possible to state which package, subsystem, or Ubuntu release is affected, what an attacker would need to reach it, or what the resulting impact would be. There is no public exploit identified at time of analysis, no KEV listing, no EPSS score, and no confirmed patch availability, so the item should be treated as an unassessed placeholder pending the corresponding Ubuntu Security Notice (USN) and NVD entry.
An out-of-bounds read in Google Chrome's Skia graphics rendering library (CWE-125) allows an attacker to read a limited amount of process memory when a victim is socially engineered into opening a crafted file that Chrome renders, with the flaw present in all Chrome builds prior to 155.0.8059.39. The assessed vector (CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N, base 3.3) shows no authentication requirement but a mandatory victim interaction and only a low-confidentiality memory exposure with no integrity or availability impact, which keeps real-world risk small; Google rates it Low. EPSS is 0.11% (1st percentile), no public exploit has been identified at time of analysis, and Chrome builds at or above 155.0.8059.39 are not affected.
Misinterpretation of the literal configuration value "none" in sshd in OpenSSH before 10.6 causes the daemon to treat the keyword as a filename instead of as a feature-disable value, yielding limited integrity and availability impact with no confidentiality loss. Per our independent assessment this is a low-severity, low-priority issue despite being in ubiquitous software: exploitation is local only (AV:L), requires high attack complexity (AC:H) and high privileges (PR:H), and depends entirely on an administrator having set an sshd option to the literal string "none" in a non-default configuration, so there is no remote or default-configuration exposure. Exploitation status: no public exploit identified at time of analysis, and the issue is not listed in CISA KEV; the only reference is the upstream OpenSSH 10.6 release notes.
ssh-keygen in OpenSSH versions before 10.6 can assign incorrect expiration timestamps to generated certificates when a Daylight Saving Time transition is mishandled, producing a bounded integrity error in the certificate's validity window. The issue is local: it requires a user to run ssh-keygen for certificate creation or signing, and it only manifests around DST changes, with slightly more pronounced effects noted for certain Antarctic time zones. With a CVSS score of 2.5 and no public exploit identified at time of analysis, this is a low-priority correctness bug rather than a remotely exploitable security flaw.
Cross-origin data disclosure in Google Chrome versions prior to 155.0.8059.39 stems from a use-after-release defect in the browser's Core component, but it is not independently exploitable: a remote attacker must first have already compromised Chrome's sandboxed renderer process through a separate, unrelated vulnerability, then persuade the victim to load a crafted HTML page. Only limited confidentiality impact is possible (CVSS 3.1, AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N; Chromium security severity: Low), with high attack complexity reflecting the non-deterministic timing needed to touch the freed resource. No public exploit code has been identified at time of analysis and there is no confirmed active exploitation (CISA SSVC exploitation: none), so this is best treated as a chain-stage bug rather than a standalone threat.