Google Chrome for iOS builds prior to 155.0.8059.39 contain a confused-deputy weakness that lets a remote, unauthenticated attacker bypass system access restrictions and reach a privileged browser page when a victim loads a crafted HTML page (CVSS 5.4, PR:N/UI:R). Exploitation is bounded by the required user interaction - the victim must open the attacker-supplied content - and impact is limited to partial confidentiality and integrity with no availability effect, while EPSS is only 0.18 percent (7th percentile) and there is no public exploit identified at time of analysis, matching CISA SSVC output of Exploitation: none and Technical Impact: partial. Desktop Chrome is not implicated by the advisory; only the iOS/mobile build is affected, and the real-world priority assessed is LOW.
Missing authorization in Google Chrome's Actor component allows remote attackers to bypass system access restrictions by socially engineering a user into opening a crafted HTML page. The flaw affects desktop versions prior to 155.0.8059.39, requires user interaction (UI:R) with no authentication needed (PR:N), and has a low EPSS score of 0.18% (7th percentile). No public exploit code or confirmed active exploitation has been identified, and a vendor patch is available.
Address-bar spoofing in Google Chrome prior to 155.0.8059.39 lets remote attackers misrepresent the page a victim is actually viewing, undermining the primary trust signal users rely on to confirm site identity. Exploitation requires the victim to navigate to an attacker-controlled crafted HTML page (UI:R, PR:N - no authentication needed), and the assessed impact is integrity-only: the deception itself does not grant code execution or direct data access, but it can be leveraged to trick users into submitting credentials or other sensitive information to a site they believe is legitimate. Google has released a fix in Chrome 155.0.8059.39; at time of analysis there is no confirmed active exploitation (not in CISA KEV) and no public exploit code identified, and Chromium rates the underlying issue as Medium severity.
UI spoofing in Google Chrome versions prior to 155.0.8059.39 allows remote attackers to deceive users with fabricated browser interface elements rendered by a crafted HTML page. The flaw is an incorrect authorization check (CWE-863) in Chromium's Input component; exploitation requires the victim to open the attacker's page and be successfully socially engineered into trusting the spoofed UI (CVSS 3.1 base 5.4, AV:N/AC:L/PR:N/UI:R), with the independently assessed impact limited to integrity only (C:N/I:L/A:N). No public exploit code and no confirmed active exploitation were identified at time of analysis, and the primary limiting factor remains user interaction rather than any technical prerequisite. A vendor patch is available in Chrome 155.0.8059.39, so this is a medium-risk, low-priority hardening item rather than an urgent emergency.
UI spoofing in the Autofill AI component of Google Chrome for Android lets a remote, unauthenticated attacker deceive users with fabricated interface elements rendered from a crafted HTML page, and only Android builds prior to 155.0.8059.39 are affected (desktop and other platform builds are not identified as impacted). Exploitation requires the victim to load and engage with the attacker's page, and no public exploit code has been identified at time of analysis; the vendor rates the Chromium severity as Low and scores the base vector 5.4 (AV:N/AC:L/PR:N/UI:R), though our read of the impact is narrower - deception of the user rather than code execution or direct data exfiltration. A vendor patch shipped in Chrome 155.0.8059.39, so this is best handled as a low-priority, routine update rather than an emergency.
UI misrepresentation in Google Chrome for Android before 155.0.8059.39 lets a remote attacker spoof browser interface elements by luring a victim to a crafted HTML page, potentially tricking the user into trusting falsified prompts, address-bar-like graphics, or permission dialogs rendered inside the page. The flaw is limited to the Android Chrome client and requires mandatory user interaction (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N per our independent assessment, CWE-451), so no authentication, privileges, or code execution are involved; Google rates it Chromium security severity Low. No public exploit code has been identified at time of analysis, CISA SSVC records exploitation as none with automatable: no, and vendor-released patches are available, making this a low-priority issue despite the mid-range base score reported by some sources.
UI misrepresentation in Google Chrome for Android before 155.0.8059.39 lets a remote attacker spoof trusted browser interface elements by getting a victim to open a crafted HTML page, which can mislead the user about which site, prompt, or state they are actually interacting with. Exploitation is unauthenticated (CVSS PR:N) but hinges on user interaction (UI:R) - the victim must actively navigate to the attacker-controlled page - and the assessed impact is limited to low confidentiality loss (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N), meaning no code execution, no data integrity change, and no denial of service; this aligns with Chromium's own Low security severity for the issue and with CISA SSVC's rating of no exploitation, non-automatable, and partial technical impact. Vendor patches are available in Chrome 155.0.8059.39, and no public exploit code or confirmed active exploitation was identified at time of analysis.
UI misrepresentation in Google Chrome on Android before 155.0.8059.39 lets a remote attacker spoof the address bar through a crafted HTML page that abuses the FullScreen feature. Exploitation requires the victim to navigate to the malicious page and enter fullscreen (UI:R), and it only yields low confidentiality impact with no code execution or authentication bypass; it is not confirmed actively exploited, no public exploit code has been identified, and vendor patch 155.0.8059.39 is available.
Address-bar spoofing in Google Chrome for Android (versions prior to 155.0.8059.39) lets a remote, unauthenticated attacker misrepresent the browser UI through the Picture-in-Picture code path, so that a crafted HTML page can make the displayed address bar show a false origin. Exploitation requires the victim to navigate to the attacker's page and be deceived by the spoofed UI (UI:R); the flaw yields UI deception only and cannot execute code, read data, or persist. No public exploit identified at time of analysis and no CISA KEV listing; a vendor patch (155.0.8059.39) was available at release, making this a low-priority issue despite the moderate 5.4 CVSS published by NVD, which our assessment narrows to integrity impact alone.
UI spoofing in Google Chrome's Payments interface allows a remote attacker to misrepresent browser payment UI elements on a crafted HTML page, potentially deceiving a victim into believing spoofed content is genuine browser-provided payment UI. All Chrome builds prior to 155.0.8059.39 are affected; exploitation requires the victim to be lured to an attacker-controlled page and then interact with the spoofed interface (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N), and no public exploit has been identified at time of analysis. CISA's SSVC assessment rates exploitation as none and the issue as non-automatable, matching Google's own Chromium severity rating of Low and the conclusion that this is a low-priority, social-engineering-dependent flaw despite its 5.4 medium base score.
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).