UI spoofing in Google Chrome on Android (versions prior to 155.0.8059.39) lets a remote, unauthenticated attacker misrepresent browser UI elements by luring a victim to a crafted HTML page, which can be used to make spoofed origins or prompts look trustworthy. Exploitation requires the user to actively navigate to the attacker-controlled page (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N), and the resulting harm is limited to user deception rather than code execution or direct data theft. There is no public exploit identified at time of analysis, and CISA's SSVC decision framework rates exploitation as 'none' with low automability, consistent with the low-to-moderate EPSS-style risk profile of a Medium-severity Chromium UI bug.
UI misrepresentation in the WebOTP API of Google Chrome versions prior to 155.0.8059.39 lets a remote, unauthenticated attacker deceive users with spoofed interface elements rendered from a crafted HTML page. The victim must navigate to the attacker-controlled page and interact with the spoofed WebOTP prompt (CVSS UI:R), so successful abuse depends on social engineering rather than any authentication or elevated privilege. Impact is bounded and low: the independent assessment rates confidentiality loss only (C:L) with no integrity or availability effect, and no public exploit code or confirmed active exploitation has been identified at time of analysis.
UI spoofing in Google Chrome before 155.0.8059.39 lets a remote, unauthenticated attacker deceive users by impersonating or falsifying browser interface elements through a specially crafted HTML page, which can lead victims to disclose information based on a falsified prompt or dialog. The flaw depends on social engineering: the victim must first be lured to an attacker-controlled page and then act on the spoofed interface, so it is not a silent drive-by compromise, and it carries a CVSS v3.1 base score of 5.4 (Medium) with low confidentiality impact and no integrity or availability impact under our assessment. There is no public exploit identified at time of analysis, and a vendor patch is available in Chrome 155.0.8059.39 and later; Google rates the underlying Chromium issue as Medium severity.
Improper authorization in Backstage's GitLab organization discovery plugin (@backstage/plugin-catalog-backend-module-gitlab) before 0.8.7 causes catalog user-creation events to be applied for GitLab accounts that are not members of the configured group, admitting an unintended catalog identity into the software catalog. Deployments that enable GitLab organization event ingestion and treat the scoped set of ingested catalog users as an access or sign-in boundary may consequently grant an attacker the permissions of a standard authenticated user, consistent with the assessed CVSS 3.1 vector 5.4 (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N), which confirms an authenticated precondition rather than unauthenticated exploitation. The vulnerable org-ingestion/events path is an optional, non-default configuration and no public exploit identified at time of analysis, so this is a moderate-severity authorization hygiene issue rather than an urgent, remotely exploitable bug.
UI spoofing in Google Chrome on Android before 155.0.8059.39 allows a remote, unauthenticated attacker to render deceptive Messages interface elements from a crafted HTML page, tricking a victim who has been socially engineered into interacting with the spoofed content. Successful exploitation requires the victim to actively open the attacker's page and then engage with the fake UI (UI:R), and the resulting impact is limited to Low confidentiality - there is no code execution, memory corruption, or data exfiltration path described. There is no public exploit identified at time of analysis and no CISA KEV listing; Chromium rates the issue Medium, and the affected scope appears confined to the Android build of Chrome, with desktop and other platforms not indicated.
Clickjacking in Google Chrome's PermissionElement lets remote, unauthenticated attackers spoof browser UI through a crafted HTML page, so a victim who visits the page may be misled about which control they are actually interacting with and could disclose information or take an unintended action. Only Chrome builds prior to 155.0.8059.39 on default configurations are affected, and exploitation requires the victim to both visit the attacker-controlled page and actively click or interact with it (UI:R), meaning a convincing social-engineering lure is the primary precondition rather than any missing browser hardening. Google has shipped a stable-channel fix, no public exploit code has been identified at time of analysis, and the issue is rated Medium with a base CVSS of 5.4 (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N per independent assessment).
UI spoofing in the iOS build of Google Chrome prior to 155.0.8059.39 lets a remote, unauthenticated attacker forge trusted browser interface elements by luring a victim to a crafted HTML page, giving the page a false appearance of legitimacy that can manipulate what the user believes they are approving or reading. Exploitation is constrained to a deception outcome only - the independent assessment rates the impact as integrity-only (C:N/I:L/A:N) with no code execution, credential theft, or denial of service achievable by the flaw itself - and it hinges on successful social engineering plus the victim actually interacting with or trusting the forged UI. There is no CISA KEV entry and no public exploit code identified at time of analysis, and a vendor patch (Chrome 155.0.8059.39) already exists, making this a medium-tier, low-urgency issue rather than a high-priority emergency.
UI misrepresentation in the Chromoting (Chrome Remote Desktop) component of Google Chrome on Windows allows a remote, unauthenticated attacker to spoof interface elements by delivering crafted network traffic, provided the victim is socially engineered into interacting with the session. Only Windows installations of Chrome prior to 155.0.8059.39 are affected, and the outcome is limited to misleading the user (low confidentiality impact) rather than code execution or credential compromise. No public exploit code or confirmed active exploitation was identified at time of analysis, and the Chromium team rated the security severity as Low.
UI misrepresentation in Google Chrome's Chromoting (Chrome Remote Desktop) component on macOS prior to 155.0.8059.39 allows a remote attacker who can inject or manipulate a remote-desktop session's network traffic to spoof interface elements and deceive the user into trusting falsified content. The attack cannot succeed on its own: it requires an active Chromoting session, the victim's interaction, and a social-engineering lure, which is why the independent assessment caps impact at low confidentiality and availability with no integrity or scope change despite the network attack vector. Chromium rates the security severity as Low (CVSS 5.4), and no public exploit identified at time of analysis.
UI spoofing within the Chromoting (Chrome Remote Desktop) component of Google Chrome on macOS lets a remote attacker who can deliver crafted network traffic misrepresent interface elements and deceive the user into trusting a falsified prompt or control in Chrome versions prior to 155.0.8059.39. Exploitation is not autonomous: per the assessed vector (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N) an unauthenticated remote attacker is required but the attack only succeeds if the victim is deceived and interacts with the spoofed UI, and the assessed impact is limited to a low integrity effect with no confidentiality or availability loss, keeping this a low-priority issue. No public exploit code and no active exploitation have been identified at time of analysis, and a vendor-released fix is available.
UI spoofing in Google Chrome on Windows prior to 155.0.8059.39 allows an unauthenticated remote attacker (PR:N) to misrepresent browser interface elements to a victim who has installed and interacted with a crafted Chrome extension obtained through social engineering, as reflected by UI:R in the CVSS vector. The incorrect calculation (CWE-682) in an API erodes user trust in what Chrome displays, but the assessed impact is limited to low confidentiality and low availability with no integrity impact (C:L/I:N/A:L). A vendor-released patch exists in Chrome 155.0.8059.39, no public exploit has been identified at time of analysis, and the overall risk is a genuinely low-to-moderate priority issue rather than a top-tier emergency.
Gitea instances configured with the non-default setting `[repository] FORCE_PRIVATE = true` can be made to host public repositories in violation of that instance-wide policy: an authenticated user with repository-creation rights who creates a repository via git push can supply the `repo.private=false` push option and have it honored on the freshly created empty repository. Only versions 1.27.0 through 28.0.0 are affected, the default configuration is explicitly not exposed, and the exposure is limited to a confidentiality/integrity policy bypass (CVSS 5.4, PR:L) rather than code execution or data theft. No public exploit code has been identified at time of analysis, and there is no CISA KEV listing; the issue is a genuine but modest-priority authorization-logic defect that matters most to operators who deliberately enforce repository privacy by policy.
Incorrect authorization in Chrome's DevTools component lets a crafted HTML page bypass local system access restrictions in Google Chrome builds prior to 155.0.8059.39, yielding limited confidentiality and integrity impact against the browsing user. Exploitation is unauthenticated on the attacker side (PR:N) but requires the victim to load the attacker-controlled page (UI:R), and the DevTools-specific code path keeps realistic abuse narrow, consistent with Chromium's 'Low' severity rating and a partial technical impact under CISA SSVC. No public exploit code has been identified at time of analysis, EPSS is only 0.12% (2nd percentile), SSVC records exploitation as 'none' and automation as 'no', and the vendor has released a patched version.
DOM-based cross-site scripting in the Red Hat Ansible Automation Platform UI allows an attacker-crafted link to execute arbitrary JavaScript inside a logged-in user's session, because a specific redirect route takes the destination from the 'next' query parameter and assigns it straight to the browser's location.href while bypassing the platform's own URL and scheme validation. Exploitation is constrained by two concrete prerequisites: the victim must already be authenticated to the platform UI (PR:L) and must actively click the malicious link (UI:R), which is why the issue carries a moderate CVSS 3.1 base score of 5.4 rather than a critical rating. No public exploit code and no confirmed active exploitation were identified at the time of analysis, and the risk is best characterized as a moderate, not top-priority, issue that should be scheduled rather than emergency-patched.
Microsoft UFO versions prior to 3.0.9 expose a file-overwrite primitive through the execute_command tool of its Linux MCP HTTP server, where the allow-list classifies 'sort' and 'uniq' as read-only but does not block their file-output forms. An authenticated caller who can reach the MCP server can pass 'sort -o <file>' / 'sort --output=<file>' or supply the optional second operand of 'uniq <in> <out>' to create or overwrite any file writable by the UFO server process, without needing shell metacharacters, because the allowed binary itself opens the destination path. Impact is confined to integrity and availability - corrupted configuration or writable data that can disrupt the service - with no file disclosure and no demonstrated code execution; no public exploit code has been identified at time of analysis and the issue is fixed in 3.0.9.
CVE-2026-61702 is recorded in this dataset solely as a vendor-sourced report from Ubuntu, with no description, no CVSS score or vector, no CWE mapping, and no CPE data, so the specific Ubuntu package, upstream component, and version range involved cannot be identified. Because the description is '[Unknown description]', no attacker capability, impact, or exploitation precondition can be stated, and the EPSS, KEV, and proof-of-concept signals are all absent - there is no evidence of active exploitation and no public exploit code identified at time of analysis, though that absence reflects missing data rather than a positive finding of safety. Risk cannot be meaningfully assessed from the provided data because nearly every decision signal is absent; prioritization should be deferred until the Ubuntu Security Notice and canonical CVE description are retrieved.
Denial of service in yawkat lz4-java before 1.11.2: an attacker who can feed compressed bytes into LZ4DecompressorWithLength's buffer-allocating decompress methods can exhaust JVM heap. A five-byte payload whose four-byte length header declares a huge output causes the library to allocate up to roughly 2 GiB before it validates the compressed data, resulting in OutOfMemoryError and transient heap pressure. The flaw is remotely triggerable and unauthenticated (CVSS:3.1/AV:N/AC:L/PR:N/UI:N) but availability-only with low impact (C:N/I:N/A:L), yielding a 5.3 score; no public exploit code was identified at time of analysis, and the vendor-released fix is version 1.11.2.
Malformed 64-bit BigTIFF input can pin a single ImageSharp decoder thread in an unbounded loop, causing sustained CPU consumption in applications that decode untrusted images with SixLabors ImageSharp versions 2.0.0 through 4.1.1. The root cause is that ExifReader.ReadValues64 trusts the 64-bit BigTIFF IFD entry count and iterates once per declared entry, while ExifReader.ReadValue64 returns without advancing the stream or terminating the outer loop when fewer than 20 bytes remain, so a small crafted file keeps one decoder thread spinning for an attacker-controlled duration. The advisory explicitly does not claim worker-pool or thread-pool exhaustion, so the practical effect is degradation rather than a complete denial of service; a fix is available in version 4.1.2, and no public exploit code or confirmed active exploitation was identified at time of analysis.
ICC profile parsing in SixLabors ImageSharp (1.0.0-beta0001 through before 4.1.2) trusts attacker-declared CLUT channel and grid dimensions when sizing allocations, so a short truncated color profile can force oversized memory allocation from a tiny input - a medium-severity memory-pressure and input-validation failure (CVSS 5.3, CWE-789). Two paths exist: the public IccProfile.Entries parsing path, reachable regardless of configuration, and in version 4 the conversion path through IccDataReader.ReadClutF32, which is only reached when DecoderOptions.ColorProfileHandling is explicitly set to Convert - the default Preserve mode does not trigger it. Unauthenticated remote attackers (CVSS PR:N/UI:N) can trigger it by getting a vulnerable application to decode a crafted image; there is confirmed actively exploited status absent (no CISA KEV entry) and no public exploit identified at time of analysis, but the exploit is conceptually simple since it requires only a malformed, truncated profile rather than a memory-corruption primitive. The demonstrated impact is bounded to memory pressure and input-validation failure, not unhandled process termination or code execution, and the vendor-released patch is version 4.1.2.
Captcha bypass in the WordPress plugin Captcha by BestWebSoft (versions 5.2.8 and earlier) lets unauthenticated remote attackers defeat the plugin's anti-automation challenge on any form it protects, including login, registration, comment and password reset, without user interaction. Classified as CWE-290 (authentication bypass by spoofing) and scored CVSS 5.3, the issue degrades only integrity of the protected workflow: bypassing the captcha removes a defense-in-depth control but does not itself grant account access or expose data. No public exploit identified at time of analysis, and real-world severity depends on which forms the plugin guards and whether separate rate-limiting, MFA or WAF controls are active.
Information disclosure in SixLabors ImageSharp 4.0.0 through 4.1.1 allows an attacker who supplies a crafted OpenEXR image to leak process-local memory contents into decoded pixel output, making this a genuine but moderate-priority confidentiality flaw rather than an urgent patch-now emergency. The bug lives in EXR ZIP/ZIPS decompression, where the inflate result can be shorter than the block size the decoder expects; the decoder then reads the full expected block from a pooled buffer obtained through Configuration.Default, so bytes left over from an earlier completed ImageSharp operation can surface in the decoded image. Exploitation requires the host application to decode an attacker-supplied EXR and expose the resulting pixels or output back to that attacker, is unauthenticated (PR:N) with no user interaction (UI:N), but is rated hard to exploit (AC:H) because the attacker cannot control or predict the residual buffer contents; no public exploit code was identified at time of analysis and fixed in 4.1.2.
Log-integrity tampering in the RemoteSyslogAppender of Apache log4net affects versions from 1.2.12 up to but not including 3.5.0, where characters outside the visible ASCII range are silently deleted from syslog records instead of being escaped. An unauthenticated remote party who can influence a value that reaches a log message (for example, a username containing a zero-width space) can make a distinct value appear identical to another in the audit record, such as a user name being logged as 'admin'. Only applications that explicitly configure RemoteSyslogAppender are affected; deployments using file, console, or other appenders are not. Impact is limited to integrity of the log record (CVSS I:L) with no confidentiality or availability effect, and no public exploit has been identified at time of analysis.
Log-record suppression in the %aspnet-request pattern converter of Apache log4net lets an unauthenticated remote sender erase the log entry for their own request by placing markup such as <script> in a parameter, because reading HttpRequest.Params triggers ASP.NET request validation, throws HttpRequestValidationException inside the layout, and causes the appender to discard the entire event. Only applications running on ASP.NET for .NET Framework (the converter depends on System.Web, which netstandard/.NET Core lacks) with log4net 1.2.11 through 3.4.x and a layout that explicitly uses %aspnet-request are affected; versions from 3.5.0 onward are fixed. Impact is confined to the attacker suppressing logging of their own request - it cannot read data, delete other users' records, or crash the service - and there is no public exploit identified at time of analysis, no CISA KEV listing, and the assessed vector is AV:N/AC:L/PR:N/UI:N with only a low integrity impact (CVSS 5.3), making this a real but low-priority issue whose practical value is helping an attacker evade audit trails for a separate attack.
Improper handling of Unicode encoding in Apache log4net's SmtpPickupDirAppender lets an attacker who can place unencodable content - such as an unpaired UTF-16 surrogate like U+D800 - into a logged message break the appender's file writer, causing the entire buffered batch of logging events to be discarded rather than just the offending event, and leaving a truncated mail file in the pickup directory for the mail service to send. Only applications configured to use SmtpPickupDirAppender (the SMTP pickup-directory appender) with event buffering are affected; versions from 1.2.9 before 3.5.0 are impacted. The issue is rated CVSS 5.3 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N) - remote and unauthenticated once attacker data reaches a rendered log field - but impact is confined to integrity of log output (suppression/truncation of audit records), with no confidentiality or availability loss; no public exploit code was identified at time of analysis and it is not confirmed actively exploited (not in CISA KEV).
Log-record truncation in Apache log4net's EventLogAppender silently drops everything a layout renders after a NUL (\0) character, so a party whose data reaches a log message can hide the remainder of that Windows Event Log record - including exception text and trailing fields - with no error raised. The flaw (CWE-158, CVSS 5.3, AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N) affects Apache log4net from 1.2.9 before 3.5.0 and only Windows applications configured to use EventLogAppender; non-Windows hosts and any other appender are unaffected. Impact is limited to integrity of a single log entry (no code execution, confidentiality or availability loss), and no public exploit code was identified at time of analysis - this is a medium/low-priority log-suppression issue rather than an urgent compromise vector. The upstream fix escapes NUL characters before the message-size limit is applied and is shipped in log4net 3.5.0.
Silent suppression of Windows event-log records in Apache log4net's EventLogAppender lets a party that can influence logged content erase a whole event record without any error being raised. Applications on Windows that use EventLogAppender in log4net 1.2.9 through versions before 3.5.0 are affected: messages are truncated to a hard-coded 31,837-character ceiling that exceeds the real Event Log record budget once the log name, source name, and machine name are counted, so the service silently stores and reports nothing for the oversized record. No public exploit identified at time of analysis, and the independent assessment rates this a genuine but low-priority, niche-configuration issue (CVSS 3.1 base 5.3, AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N), since an attacker must be able to push a single logged message into the tens-of-kilobytes range.
A NUL character (U+0000) embedded in content that reaches a log message causes Apache log4net's OutputDebugStringAppender to truncate the emitted debug record at that point, silently discarding everything the layout rendered afterwards, including exception text and trailing fields. Only Windows applications that explicitly configure the non-default OutputDebugStringAppender are affected, across log4net versions from 1.2.9 up to (but excluding) 3.5.0. Per the CVSS:3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N, score 5.3) the flaw is unauthenticated and remotely reachable where attacker-controlled data is logged, but it is limited to log-record integrity with no confidentiality, availability, or code-execution impact; no public exploit code has been identified at time of analysis and the issue is not in CISA KEV, so overall real-world risk is low-to-moderate.
Cross-site scripting in the Forums feature of OpenText Content Management (Content Server) allows an unauthenticated remote attacker to inject malicious script into a Forums web page, which then executes in the browser session of any user who views that page. The affected deployments are those running Content Server with the Forums feature enabled and reachable by untrusted users; the CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:P) confirms no authentication is required to attempt injection, and the independent CVSS 3.1 assessment (AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N) confirms that a victim must view the poisoned page and that impact is confined to that victim's browser session rather than the server. Rated 5.3 medium severity under CWE-79, with no public exploit identified at time of analysis.
Zero Spam plugin versions up to 5.7.11 for WordPress can be bypassed by unauthenticated attackers to defeat its anti-spam protections, allowing forged or unwanted form submissions. This moderate-severity (CVSS 5.3) authentication bypass (CWE-290) requires no authentication or user interaction, but its impact is limited to integrity (I:L) - no data confidentiality or availability loss, and no code execution or site takeover. No public exploit or active exploitation is identified at time of analysis.
Information disclosure in the Backstage Scaffolder backend (@backstage/plugin-scaffolder-backend) prior to 4.1.0 allows an authenticated user who can run or view a Scaffolder task to recover backend-managed credentials from persisted task failure events. When a template injects secrets (for example via ${{ secrets.secret }}) into an action or checkpoint and that step fails, the raw secret values were written into the failure reason, error name, and error message without passing through the configured log redaction, and nested error objects were attached to the surfaced error. Exploitation requires a valid Backstage account (PR:L) and a narrow combination of template content and failure path (AC:H), so this is a genuine but moderate-priority CWE-532 leak rather than a broadly weaponizable flaw; no public exploit has been identified at time of analysis, and installations on @backstage/plugin-scaffolder-backend 4.1.0 or Backstage v1.54.6 and later are not affected.
Unauthenticated remote attackers who can reach the API interface of HPE Aruba ClearPass Policy Manager can circumvent existing authentication controls and read sensitive information from the appliance. The flaw is rated CVSS 3.1 5.3 (AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N), so no credentials or user interaction are required and the impact is confined to confidentiality disclosure with no integrity or availability effect. Exposure is the key risk driver: ClearPass management and API listeners are normally isolated on a management VLAN, and no public exploit code or confirmed active exploitation was identified at time of analysis.
Information disclosure in Google Chrome's DevTools affects versions prior to 155.0.8059.39, where incorrect resolution of internal references can leak sensitive data to a crafted HTML page. The attack is not a standalone entry point: it requires the attacker to have already compromised the Chrome renderer process (typically through a separate bug), to have a malicious HTML page rendered in a DevTools context, and to rely on user interaction, which the CVSS vector reflects as AV:N/AC:H/PR:UnR/UI:R. There is no confirmed active exploitation (not listed in CISA KEV) and no public exploit code identified at time of analysis, and CISA's SSVC assessment records Exploitation: none with Automatable: no, so this should be handled as a routine monthly-patch item rather than an emergency.
Incorrect reference resolution in the Offline component of Google Chrome on Android before 155.0.8059.39 allows an attacker to obtain sensitive information from beyond the renderer's own data. Exploitation is not autonomous: it requires that the attacker has already compromised the Chrome renderer process on the Android device and that the victim loads a crafted HTML page, which is why the assessed vector carries high attack complexity (AC:H) and a user-interaction requirement (UI:R) despite network reachability. Impact is limited to confidentiality with no integrity or availability effect, no public exploit code has been identified at time of analysis, and CISA's SSVC decision framework rates exploitation as "none" and the issue as not automatable, making this a defense-in-depth fix rather than a frontline emergency. A vendor patch is available and the issue is tracked as EUVD-2026-93741 and in the Chromium issue tracker.
Unauthenticated attackers can defeat the Google reCAPTCHA verification performed by the Advanced Google reCAPTCHA WordPress plugin (versions up to and including 5.40), allowing anti-bot/authentication checks on protected forms to be bypassed. The flaw is a CWE-288 authentication bypass using an alternate path or channel, rated CVSS 5.3 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N), so no credentials, privileges, or user interaction are required and impact is limited to the integrity of the CAPTCHA control with no confidentiality or availability effect. Exploitation is constrained mainly by footprint - only WordPress sites running the vulnerable plugin version on a reachable form or authentication endpoint are affected - and no public exploit is identified at time of analysis.
Information disclosure in Google Chrome's Media component on Windows affects builds prior to 155.0.8059.39, where missing authorization checks allow a crafted HTML page to expose sensitive data - but only if the attacker has already compromised Chrome's renderer process. That prior-foothold prerequisite is the dominant limiting factor: this defect cannot be triggered against a clean, default browser by a remote attacker, which is why CISA's SSVC assessment records no exploitation and no automability, and why the issue is treated as low priority despite the 5.3 Medium base score. No public exploit code has been identified at time of analysis, and a vendor-released fix is available in Chrome 155.0.8059.39.
Authenticated users of Payload CMS who are confined to a single tenant can create new records inside a different tenant whenever the @payloadcms/plugin-multi-tenant plugin (before 3.90.0, or canary before 4.0.0-canary.34) is installed and at least one tenant-enabled collection exists. The bypass is confined to record creation: reads and direct edits of pre-existing documents in the target tenant are still enforced, so the impact is integrity-only data injection rather than cross-tenant data disclosure or destruction, consistent with a CVSS score of 5.3. No public exploit code has been identified at time of analysis and the issue is not listed in CISA KEV.
Remote unauthenticated attackers can access sensitive information on WordPress sites running the Mailjet Email Marketing plugin version 6.2.3 or earlier. The flaw, rated CVSS 5.3, stems from insertion of sensitive data into sent responses (CWE-201), affecting confidentiality only; no public exploit code or confirmed active exploitation has been identified at time of analysis. Exploitation requires only that the vulnerable plugin be installed and network-reachable, as the CVSS vector (AV:N/AC:L/PR:N/UI:N) confirms remote, low-complexity, unauthenticated access with no user interaction.
Hotel-restricted back-office employees in QloApps through 1.7.0 can modify room records belonging to hotels they are not authorized to manage, because AdminProductsController::ajaxProcessBulkUpdateRooms trusts the client-supplied id_rooms parameter without verifying that those rooms belong to hotels the employee's profile can access. An authenticated low-privileged employee submitting foreign room IDs can change room status, floor, comments, or inactive dates, disrupting availability and bookings at other properties. Rated 5.3, this is a moderate-severity cross-tenant IDOR (CWE-639) that is meaningful only in multi-hotel deployments with non-super-admin, hotel-restricted staff accounts; no public exploit code or confirmed active exploitation was identified at time of analysis, and an upstream fix is available in GitHub PR #1892.
Improper input validation in the Backstage Scaffolder backend (@backstage/plugin-scaffolder-backend) before version 4.1.0 allows an authenticated user with permission to create and read scaffolder tasks to influence how the task list endpoint orders results, enabling inference of confidential task data such as secrets. Exploitation is not straightforward: the assessed vector is CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N (5.3 Medium), and the advisory requires four stacked preconditions - the target task's secrets must still be retained (not purged), the attacker must be able to see the target task, the attacker must already know the structure of the secret being inferred, and the attack depends on many repeated list requests - so the practical outcome is partial inference rather than guaranteed full secret disclosure. There is no public exploit identified at time of analysis, and no KEV listing; the issue is fixed in @backstage/plugin-scaffolder-backend 4.1.0 (Backstage release v1.54.6).
Information disclosure in Google Chrome's DataTransfer component affects desktop builds prior to 155.0.8059.39 and lets a remote attacker who already controls the Chrome renderer process read sensitive data by luring a victim into opening a crafted HTML page. The root cause is a missing authorization check (CWE-862), rated Medium by Chromium with a CVSS 3.1 score of 5.3 (AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:N/A:N), meaning the vector indicates no required privileges (PR:N) but user interaction (UI:R) and high attack complexity (AC:H). Because the renderer compromise must occur first, this is a chained/secondary bug rather than a standalone remote primitive; no public exploit code is identified at time of analysis and it is not confirmed actively exploited (CISA KEV).
Information disclosure in Google Chrome's Omnibox affects versions prior to 155.0.8059.39, where a remote attacker who has already compromised the browser's renderer process can obtain sensitive information by enticing the victim to open a crafted HTML page. Exploitation is constrained by the renderer-compromise prerequisite, high attack complexity (AC:H), and required user interaction (UI:R), and the resulting impact is limited to confidentiality (C:H, I:N, A:N), consistent with a CVSS 3.1 base score of 5.3 and CWE-863 incorrect authorization. There is no public exploit identified at time of analysis and CISA SSVC records exploitation as none; a vendor patch (155.0.8059.39) is available.
Information disclosure in Google Chrome for iOS (Google's Safe Browsing component) affects versions prior to 155.0.8059.39, where a crafted HTML page can be used to observe a measurable discrepancy and extract sensitive information. The flaw is only reachable by a remote attacker who has already compromised Chrome's renderer process on iOS and who can get the victim to load the crafted page (UI:R), making exploitation a two-stage, high-complexity (AC:H) operation rather than a standalone attack, and CISA's SSVC assessment records Exploitation=None. There is no CISA KEV listing and no public exploit identified at time of analysis; Chromium rates the bug Medium and the vendor has released a patch, so the practical risk is best characterized as moderate with a strong precondition rather than imminent.
Information disclosure in Google Chrome's Autofill AI component (builds prior to 155.0.8059.39) lets an attacker who has already compromised the renderer process read sensitive data by luring the victim to a crafted HTML page that engages the autofill feature. The flaw is rated CVSS 5.3 (AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:N/A:N) and stems from an observable discrepancy (CWE-203) rather than a memory-safety bug, so it is a chained post-exploitation primitive, not an initial-access vector: exploitation requires a separate renderer compromise plus socially engineered user interaction, and patched builds are not exploitable. No public exploit code has been identified at time of analysis and the issue is not confirmed actively exploited (CISA KEV); CISA SSVC rates exploitation as 'none' and automatable as 'no', consistent with a genuine-but-low-priority information leak.
An unauthenticated remote attacker can exploit a race condition in Chromoting (Chrome Remote Desktop) within Google Chrome before version 155.0.8059.39 by socially engineering a victim into opening the vulnerable code path while delivering crafted network traffic, potentially bypassing system access restrictions. Exploitation requires the victim to be actively using Chromoting and to win a timing-dependent race condition (AC:H), making reliable attacks unlikely. The EPSS score is 0.14% (3rd percentile), the Chromium severity is Low, and no public exploit has been identified at time of analysis; the vendor has released a patch in 155.0.8059.39.
Information disclosure in Google Chrome's Proxy component on Windows allows an attacker positioned on the same adjacent network to obtain sensitive information from a victim by delivering crafted network traffic to Chrome builds prior to 155.0.8059.39. The high attack complexity (AC:H) means a single attempt is unlikely to succeed - specific proxy state or timing conditions must line up - and no public exploit has been identified at time of analysis, with CISA SSVC recording exploitation as 'none' and automatable as 'no'. Because the impact is confidentiality-only (no code execution, no integrity or availability effect) and the disclosure is rated partial technical impact, the practical priority is low-to-moderate despite Chromium's 'High' security severity label; Google has already published a fixed build.
Cross-origin WebSocket probing in the Punk Perl web framework (versions 0.48 up to but not including 0.55) allows a malicious web page to learn whether arbitrary GET paths, API operations, or mounted applications return a 2xx status. When Punk serves HTTP/2 or HTTP/3, an Extended CONNECT WebSocket handshake is routed as a GET by ps_serve_one, so it reaches every GET route while the Origin check - which only runs for matched websocket routes - is skipped; the handler's returned status becomes the handshake response, and any 2xx accepts the socket. Exploitation is unauthenticated (CVSS:3.1/AV:N/AC:L/PR:N) but requires user interaction (UI:R): a victim must load an attacker-controlled cross-origin page that scripts the WebSocket, and it is not exploitable over HTTP/1.1. The impact is limited to endpoint and authorization probing - no response content, integrity, or availability impact - and no public exploit code was identified at time of analysis.
Information disclosure in SSSD deployments configured to use Microsoft Entra ID as their identity backend, where a local low-privileged user can submit a crafted lookup request that is incorporated unsanitized into a directory query filter, manipulating the query logic to return directory data outside the requester's intended scope. Only hosts explicitly configured with the Entra ID backend are affected; standard AD, LDAP, or IPA backend deployments are not. Exploitation requires a pre-existing local account with low privileges (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N) and there is no remote path, so this is assessed as a moderate-severity, low-urgency issue with no public exploit identified at time of analysis.
Information disclosure in Google Chrome's Proxy Auth handling lets an attacker on the same adjacent network segment (same broadcast domain or a man-in-the-middle position on the traffic path) capture sensitive data that Chrome failed to properly clear from memory. Exploitation is unauthenticated per the assessed vector (CVSS:3.1/AV:A/AC:H/PR:N/UI:N) but carries high attack complexity, and it only works meaningfully when the victim's browser is configured to route traffic through an authenticating proxy, making this a narrow, environment-dependent leak rated CVSS 5.3. The flaw is rated Chromium security severity High, is tracked as EUVD-2026-93809, and is fixed in Chrome 155.0.8059.39; there is no confirmed active exploitation (no CISA KEV listing) and no public exploit identified at time of analysis.
Heap exhaustion in the yawkat LZ4 Java library before 1.11.2 allows remote denial of service: net.jpountz.lz4.LZ4BlockInputStream.refill() checks that the compressedLen field of a legacy LZ4Block header is nonnegative but then allocates a compressed-input buffer of exactly that attacker-controlled size before any payload is read. Because each header is only a handful of bytes, a header-only stream can request a near-2 GiB allocation and crash the JVM with OutOfMemoryError, affecting any application that decompresses attacker-influenced LZ4 legacy-block data with the default reader configuration; no public exploit code or active exploitation was identified at time of analysis (CVSS 5.3, availability-only impact). The flaw is fixed in version 1.11.2, which rejects non-canonical oversized blocks by default.
Open redirect in the Arista CloudVision Portal login flow (CWE-601) lets a remote, unauthenticated attacker craft a login URL that, once a victim clicks it and completes the normal authentication process, sends that user's browser to an arbitrary external site. The issue carries a CVSS 4.0 base score of 5.3 and was assessed as CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:N/A:N; the attacker needs no credentials but cannot trigger the redirect without victim interaction, and impact is limited to browser redirection with low confidentiality loss - primarily useful for enabling phishing or credential theft rather than code execution or data modification. Affected releases are CloudVision Portal 2020.3.0 through <2025.3.0, 2025.3.0 ≤2025.3.3, 2026.1.0 ≤2026.1.2, and 2026.2.0; no public exploit code or confirmed active exploitation was identified at time of analysis, and a vendor patch is available per the Arista security advisory.