Suse
Monthly
A remote, unauthenticated denial-of-service condition exists in the RabbitMQ stream protocol when the stream plugin is enabled, allowing a client that completes the Tune handshake to declare a frame larger than the negotiated FrameMax and drive excessive memory consumption. Affected deployments are RabbitMQ 3.13.0 through 3.13.14, 4.0.x before 4.0.20, 4.1.x before 4.1.11, and 4.2.x before 4.2.6; the issue is availability-only with no confidentiality or integrity impact, and exploitation requires the non-default stream plugin (and its listener) to be exposed to the attacker. No public exploit code has been identified at time of analysis, and there is no confirmed active exploitation (CISA KEV) associated with this CVE. Independent assessment rates this as a genuine but low-to-moderate-severity DoS issue rather than a high-impact priority.
Unbounded pre-authentication state accumulation in RabbitMQ's Web STOMP WebSocket handler lets an unauthenticated remote client hold connections open with a slow trickle of small frames, causing memory and resource exhaustion on the broker. Only deployments that enable the non-default rabbitmq_web_stomp plugin and expose its WebSocket listener are affected; a single request is not enough, since the attacker must open and sustain many slow connections over time (reflected as AT:P in the assessed vector). RabbitMQ 3.13.0 through 3.13.14, 4.0.x before 4.0.20, 4.1.x before 4.1.11, and 4.2.x before 4.2.6 are vulnerable, and no public exploit code has been identified at time of analysis.
Opening a crafted Gnumeric workbook can trigger a heap use-after-free (CWE-416) during XML parsing of a malformed SheetObjectComponent element, crashing the application and causing a denial of service. This affects GNOME Gnumeric across versions (CPE: cpe:2.3:a:gnome:gnumeric:*:*:*:*:*:*:*:*). The vulnerability requires local access and user interaction (CVSS:3.1/AV:L/AC:L/PR:N/UI:R), and no public exploit identified at time of analysis.
Silent data-durability loss in the Linux kernel's nvdimm pmem driver occurs when a failed REQ_PREFLUSH barrier is not propagated synchronously, allowing data writes to proceed and a later successful REQ_FUA flush to overwrite the recorded error so the bio completes as if the ordering barrier succeeded. This affects Linux kernels with NVDIMM/PMEM persistent-memory support prior to fixed versions 6.18.52 and 7.2.6; the flaw requires local, low-privileged block I/O submission to a pmem device and only manifests when a real preflush error occurs, yielding silent integrity/durability loss rather than a directly attacker-controllable compromise. No public exploit code or confirmed active exploitation is identified (EPSS 0.15%, 4th percentile).
A mismatched memory free in the Linux kernel's staging rtl8723bs SDIO Wi-Fi driver can corrupt kernel memory: padapter->HalData is allocated with vzalloc() but is released with kfree() on the error path of rtw_sdio_if1_init(), mixing a vmalloc-backed pointer into the slab free path. The flaw is locally triggerable by an authenticated user (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H per independent assessment) and only on systems whose kernel is built with CONFIG_RTL8723BS and that have RTL8723BS SDIO hardware; because the faulty free executes only when interface initialization fails, it is far more likely to surface as an accidental crash or memory-corruption event than as a reliable attacker-controlled primitive. No public exploit code has been identified at time of analysis, EPSS is low at 0.17% (5th percentile), and vendor patches are available, so this is a low-priority, low-real-risk issue despite its MEDIUM 5.5 score.
A resource leak in the Linux kernel's nvmet-rdma driver - the RDMA transport for NVMe-over-Fabrics targets - causes a newly allocated queue and its associated InfiniBand resources to be leaked whenever incoming disconnecting queues exceed the configured connect backlog limit. The issue is reachable without authentication (CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H per independent assessment) but only on hosts actually configured as NVMe-oF RDMA targets with an active RDMA listener, and only via the adjacent RDMA fabric; an attacker or misbehaving initiator must generate rapid repeated connect/disconnect churn. Impact is limited to availability through slow, incremental resource exhaustion rather than an immediate crash, EPSS is very low (0.16%, 5th percentile), and no public exploit code or confirmed active exploitation (CISA KEV) has been identified at time of analysis.
Uninitialized-mutex use in the Linux kernel Bluetooth HCI core can be triggered by a local low-privileged user who causes an HCI controller flagged with quirks such as HCI_QUIRK_RAW_DEVICE (and therefore HCI_UNCONFIGURED) to be registered while the power_on work item races ahead of msft_register() initialization. The window is a narrow timing race in hci_register_dev(), where hdev->msft_data is published before mutex_init(&msft->filter_lock) completes, so hci_power_on() -> hci_dev_do_close() -> msft_do_close() can lock an uninitialized mutex, producing a DEBUG_LOCKS warning and a kernel warning/backtrace (availability impact, no confidentiality or integrity effect). EPSS is 0.17% (5th percentile), there is no CISA KEV listing, and no public exploit code has been identified at time of analysis; vendor-released patches exist for the affected stable branches.
Memory leak in the Linux kernel's btrfs RAID stripe tree error paths causes bioc objects held on a btrfs_ordered_extent's bioc_list to be dropped without being freed, allowing kernel memory to be exhausted over time when applications repeatedly hit those failure paths. Only systems running btrfs with the relatively new RAID stripe tree feature mounted are affected, and the assessed vector (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H) reflects a local, low-privilege condition whose impact requires sustained or abnormal error rates rather than a single operation. No public exploit code exists and EPSS is only 0.17% (5th percentile), so this is a genuinely low-priority issue despite warranting a patch.
In the Linux kernel's Btrfs filesystem, running a block-group balance/relocation on a filesystem that has quota groups enabled can force creation of a relocation root while qgroup_account_snapshot() is committing a pending snapshot, leaving a stale metadata tree reference whose extent item has already been dropped. When delayed refs are processed the kernel hits lookup_inline_extent_backref() with a WARNING and fails the ref insertion with -117 (EUCLEAN), aborting the transaction and flipping the affected Btrfs filesystem read-only; recovery requires unmount and repair/mount, making this strictly an availability issue (no confidentiality or integrity impact). The defect is local-only: the assessed vector is AV:L/AC:H/PR:L/UI:N with high attack complexity, and the assessed risk is LOW despite the Medium 5.5 CVSS base score, because it requires (a) local access able to issue Btrfs administrative ioctls - balance/relocation normally needs CAP_SYS_ADMIN - (b) a filesystem explicitly created or mounted with quota/qgroups enabled, a non-default option, and (c) tight timing between relocation and snapshot creation. EPSS is 0.17% (5th percentile), there is no KEV entry, and no public exploit code was identified at time of analysis; vendor-released patches exist in stable 6.12.111, 6.18.53, 7.2.7 and 7.3-rc2.
A local denial-of-service flaw in the Linux kernel's BPF tracing subsystem lets a user who can load and attach a BTF-enabled raw tracepoint (tp_btf) program panic the kernel by dereferencing the siginfo argument of the signal_generate or signal_deliver tracepoints, which the kernel may populate with the non-pointer sentinel values SEND_SIG_NOINFO (0) or SEND_SIG_PRIV (1). Exploitation requires local access with CAP_BPF plus CAP_PERFMON (or CAP_SYS_ADMIN) on a kernel built with BPF tracing support, matching the assessed CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H vector; there is no remote or network vector, and impact is limited to availability. Risk is considered low-to-moderate: EPSS is only 0.17% (5th percentile), no public exploit code has been identified at time of analysis, and the issue is not listed in CISA KEV. Vendor patches are available in the stable trees referenced by the advisory.
An unbalanced module reference count in the Linux kernel's Intel AVS (Audio, Voice, Speech) ASoC audio driver lets a local, authenticated user leak a module reference every time a specific error path in the driver-open routine is hit, which over repeated triggering can leave the driver module permanently pinned and degrade availability (module unload/reload fails). Only systems running a vulnerable kernel build with the Intel AVS DSP audio stack present and loaded are exposed, and our assessed vector is CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L, a low-to-moderate priority local availability issue rather than a widespread emergency. EPSS is 0.17% (5th percentile), the issue is not in CISA KEV, and no public exploit identified at time of analysis; vendor-released patches exist in stable 6.12.111, 6.18.53 and 7.2.7 plus mainline 7.3-rc3.
Out-of-bounds read in the Linux kernel's Intel AVS ASoC audio driver can crash the kernel when a local user with low privileges causes an oversized module config ID from a DSP topology binary to index the init_configs array. The flaw is limited to local, low-privilege access on systems with Intel AVS audio hardware and the relevant driver loaded; it is not remotely reachable and, per the assessed vector, has no confidentiality or integrity impact. EPSS is low (0.17%, 5th percentile), no public exploit code has been identified at time of analysis, and vendor fixes are available in Linux 6.18.53, 7.2.7, and 7.3-rc3 or corresponding stable backports.
Denial of service in the Linux kernel's bcmasp (Broadcom ASP 2.0) Ethernet driver lets a local user with low privileges (CVSS PR:L) disrupt the transmit path when the driver needs multiple consecutive descriptor slots: tx_spb_ring_full() re-initialises next_index from intf->tx_spb_index inside the loop, so incr_ring() yields the same slot every iteration and only one descriptor is ever tested instead of cnt. The defect affects kernels carrying the bcmasp driver from commit 490cb412007de593e07c1d3e2b1ec4233886707c onward and running on Broadcom embedded/SoC hardware, and is corrected in 6.12.111, 6.18.53, 7.2.7 and 7.3-rc3. EPSS is 0.17% (5th percentile) and no public exploit has been identified at time of analysis, so no public exploit identified at time of analysis and real-world priority is low.
Denial of service in containerd versions prior to 1.7.36, 2.0.13, 2.2.9, 2.3.6, and 2.4.1 allows an unauthenticated attacker who controls or poisons an image source to force excessive CPU and memory consumption during PullImage, causing long ContainerCreating stalls and potential node instability at larger graph sizes. The vulnerability is triggered before container start and requires no privileges on containerd itself, but is limited to environments that pull untrusted images; clusters pulling only trusted first-party images are not exposed. No public exploit identified at time of analysis, and impact is availability-only with no confidentiality or integrity effect.
Risk cannot be meaningfully assessed from the provided data. CVE-2026-94282 is reported solely by the vendor source 'ubuntu', indicating that a package distributed through Ubuntu channels is affected, but no description, CVSS score, CVSS vector, CWE identifier, or affected-version metadata accompanies the record, so the nature of the flaw, the attack surface, and the deployment contexts at risk are all unknown. Exploitation status: no public exploit identified at time of analysis. Authentication requirements are not confirmed from available data, and no CISA KEV listing or EPSS score was provided to indicate real-world exploitation or likelihood. Until the corresponding Ubuntu Security Notice and upstream advisory are retrieved, this record should be treated as an unresolved tracking identifier rather than a characterized vulnerability.
The MongoDB Python Driver (PyMongo) versions 3.9.0 through 4.18.1 can be induced to open connections to local Unix domain sockets on the application host when an attacker who already holds write access to the encryption key metadata in the database alters a key management (KMS) endpoint value so that it ends in '.sock' - a string the client-side field level encryption (CSFLE) code path mistakes for a local socket path instead of a remote host. Exploitation requires the opt-in, non-default CSFLE feature to be in use and an authenticated attacker with database-side write access to the key vault, and it is only reachable over the network in the sense that CVSS scores the vector AV:N/PR:L; the transmitted bytes are restricted to the beginning of a TLS handshake, so no attacker-chosen content reaches the socket and data exfiltration or arbitrary remote-host reachability is not achievable. No public exploit code has been identified at time of analysis and the issue is not in CISA KEV; despite the CWE-918 (SSRF) classification, this is a low-priority, low-impact defect. Vendor-released patch: 4.18.2.
Login CSRF through partial-pipeline session fixation in the social-core library of Python Social Auth before 5.0.0 allows an unauthenticated remote attacker (PR:N) to seed an authentication flow, harvest the resulting partial_token and verification data, and then induce a victim's browser to resume that attacker-controlled flow so the victim ends up authenticated as the attacker's account. Only applications that use resumable partial pipeline steps - such as the built-in mail_validation step or custom steps decorated with @partial - are exposed; success additionally requires victim interaction (UI:R) and reliable delivery of the attacker's token into the victim's browser, which is why the high attack complexity keeps the CVSS 3.1 base score at 4.2. The impact is limited to authenticating the victim as the attacker (a login-CSRF/session-fixation outcome) rather than taking over the victim's own account, and no public exploit has been identified at time of analysis.
Login CSRF in the LoginRadius backend of Python Social Auth (social-core) before 5.0.0 lets an attacker complete a victim's browser session authentication against an attacker-controlled LoginRadius identity, because the OAuth state parameter is never validated during the callback. Only applications that specifically enable the LoginRadius backend are affected; per the assessed vector (AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N, CVSS 4.3) the attacker must possess a valid LoginRadius token and induce user interaction, and the victim's own account is not compromised - they are simply logged in as the attacker, with no confidentiality impact. No public exploit code was identified at time of analysis and there is no CISA KEV listing; the vendor-released fix is social-core 5.0.0, which enforces callback state validation for LoginRadius.
Account impersonation in Python Social Auth (social-core) before version 5.0.0 allows an authenticated Vend user from one shop to be authenticated as a pre-existing local account that was linked to a user from a different shop sharing the same numeric Vend user_id. Only applications that use the Vend OAuth2 backend and authenticate users from more than one Vend shop are affected; the numeric-ID collision is not attacker-controlled and may be uncommon, but successful exploitation yields full compromise of the colliding local account (CVSS 6.8, AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N) with no victim interaction required. No public exploit identified at time of analysis.
SAML account association in python-social-auth (social-core) before 5.0.0 lets an attacker who already holds a valid account on an identity provider trusted by the target application link that SAML identity to a logged-in victim's local account, after which the attacker can authenticate through SAML and access the victim's account. The flaw only reaches deployments that use the SAML backend and enable authenticated account association, and it requires the victim to be logged in and driven through the association flow while the unsolicited SAML response is timed to that session, which is why the assessed vector is network-reachable but high-complexity with user interaction (CVSS:3.1/AV:N/AC:H/PR:L/UI:R, base 6.4). This is a conditional integrity and authentication problem rather than a mass-exploitable emergency; no public exploit identified at time of analysis, and version 5.0.0 resolves it by validating SAML responses against stored AuthnRequest IDs.
Denial of service in libXi before 1.8.4 allows a malicious or compromised X server to crash an attached X client by returning crafted input-device class data that triggers an out-of-bounds read inside XListInputDevices(). This is a client-side, inverted-trust flaw (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H, base 6.5): exploitation requires the victim application to connect to an attacker-controlled display and call the device-enumeration path, and the assessed effect is limited to an availability impact - no confidentiality or integrity loss - despite the CWE-125 classification and the 'Information Disclosure' tag. No public exploit code and no confirmed active exploitation were identified at time of analysis, and the flaw is not reachable when clients talk only to trusted local X servers.
A malicious X server can crash X clients that use libXi before 1.8.4 by returning a crafted reply to the XListInputDevices() call, triggering an out-of-bounds read (CWE-125). The flaw is purely availability-impacting (CVSS 3.1 base 6.5: AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H) and requires the victim to connect to the attacker-controlled X server - for example via X11 forwarding to an untrusted host - and invoke XListInputDevices(). No public exploit code has been identified at time of analysis, and there is no indication of active exploitation (CISA KEV).
Out-of-bounds read in libXi before 1.8.4 allows a malicious X server to crash an attached X client by sending a crafted reply to an XI2 XIQueryDevice request. This is a denial-of-service issue affecting systems where the X client communicates with an untrusted or compromised X server, such as via SSH X11 forwarding to a hostile host or a man-in-the-middle on the X protocol stream. The CVSS vector indicates unauthenticated remote exploitation requiring user interaction (UI:R), with no impact to confidentiality or integrity and only availability impact; no public exploit code has been identified, and the vendor has released a patch fixing the flaw in version 1.8.4.
libXi before 1.8.4 contains an out-of-bounds read in the XI2 device-class parsing helpers size_classes() and copy_classes(), which a malicious or compromised X server can trigger to crash a connecting X client. The issue inverts the usual X11 trust model: the server attacks the client, so exposure is limited to users who connect an affected client to an untrusted display - a remote/forwarded X session or a hostile server - and requires user interaction to establish that connection (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H, 6.5). Impact is confined to client-side denial of service with no code execution, data disclosure, or integrity loss; there is no public exploit identified at time of analysis and no CISA KEV listing, and a vendor fix is available (libXi 1.8.4, upstream commit f499944a).
Out-of-bounds reads in libXi before 1.8.4 can crash X11 client applications when they process a crafted XQueryDeviceState() reply, producing a denial-of-service condition with no code execution or confirmed data disclosure. Exploitation requires the victim to initiate a connection to an attacker-controlled or compromised X server, or an attacker able to tamper with an unauthenticated X protocol stream, matching the UI:R requirement; clients limited to trusted local X servers are effectively not exposed. No public exploit code has been identified at time of analysis, and a vendor fix is available.
RabbitMQ's shovel management resource fails to enforce a policymaker-level check on DELETE operations, so an authenticated user holding the low-privileged 'monitoring' tag - nominally read-only - can delete or restart any dynamic shovel in any vhost visible to that account. The flaw (CWE-862 missing authorization) is reachable over the network with no user interaction and yields high integrity impact against shovel configuration state, though it is bounded by a non-default configuration requiring both the rabbitmq_shovel and rabbitmq_shovel_management plugins to be enabled and by the attacker needing pre-existing credentials plus vhost-scoped visibility. Patches are released in RabbitMQ 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.1; no public exploit code has been identified and there is no confirmed active exploitation (no CISA KEV listing) at time of analysis.
Stack exhaustion in libfyaml 0.9.6 allows a crafted YAML document to crash the process that parses it, producing a denial of service. When fy_atom_iter_format() formats a literal or folded block scalar containing a long run of blank lines, it repeatedly calls alloca() inside a per-line loop; because alloca() memory is only reclaimed when the function returns, the stack grows cumulatively until the process stack limit is exceeded and SIGSEGV occurs. Exploitation is unauthenticated but requires user/application interaction (UI:R) - the target application must actually parse attacker-influenced YAML - and impact is limited to the single parsing process. No public exploit code has been identified at time of analysis, EPSS is low at 0.15% (4th percentile), and the upstream project has published fixing commits referenced from issue #315.
Authenticated users of Rapid7 Velociraptor can trigger a server-side deadlock in the platform's user-management module, hanging server operations and causing a denial of service (CVSS 6.5, AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Exploitation requires only a valid low-privileged account that can reach the user-management code path over the network - no user interaction, no elevated role, and no special configuration - but it offers no data read, modification, or code execution, so it cannot be used for initial access or lateral escalation. Impact is availability-only (CWE-833, lock management bug); no public exploit identified at time of analysis, no CISA KEV listing, and the vendor advisory is the authoritative source for version-specific guidance.
The CVE-2026-17545 record is effectively empty: it ships with no description, no CVSS vector, no CWE mapping, and no CPE data, and the only intelligence attached to it is that it was reported through the Ubuntu vendor coordination channel. Because the affected package, the vulnerable component, and the required attacker position are all unknown, the risk to any specific Ubuntu deployment cannot be meaningfully assessed from the available data and no impact statement should be issued yet. No public exploit code has been identified at time of analysis, and no EPSS score, KEV listing, or proof-of-concept reference accompanies the record, so there is currently no signal of exploitation activity. The immediate action is intelligence collection rather than mitigation: retrieve the corresponding Ubuntu Security Notice and CVE tracker entry to learn which package and version range are involved before assigning severity or exposure.
Risk assessment is currently not possible for CVE-2026-91768, an Ubuntu-tracked identifier that arrives with no description, no CVSS score, no CVSS vector, no CWE classification, and no CPE data; the only signal available is that the record was reported by the Ubuntu vendor source. Because attack vector, privileges required, user interaction, and affected package or deployment mode are all unspecified, no meaningful statement can be made about what an attacker could do or who is exposed. Exploitation status is unconfirmed: no public exploit identified at time of analysis, and there is no KEV listing, no EPSS score, and no proof-of-concept reference in the supplied intelligence. Security teams should treat this identifier as un-triageable and hold it in a watch state until the Ubuntu CVE tracker or the NVD/MITRE record supplies a description and affected package.
Denial of service in LibRaw 0.22.0: opening a crafted RAW, TIFF or DNG file whose TIFF tag 0x00fe (NewSubfileType) carries a value outside signed-int range drives an unchecked narrowing conversion in LibRaw::parse_tiff_ifd(), triggering undefined behavior that terminates the process. The issue is availability-only (CVSS 3.1 5.5, AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H) and requires user interaction - a victim or an automated pipeline must open the malicious file - with no privilege requirement, no data exposure and no code execution. There is no evidence of active exploitation (no CISA KEV listing) and EPSS is low at 0.15% (4th percentile), although the upstream fix PR contains a regression harness with a minimal crafted TIFF that reproduces the out-of-range value, so a public crash reproducer exists.
Opening a specially crafted WAV file with libsndfile 1.2.2 can cause a denial of service when the library's header parser performs an unaligned 4-byte store through a cast unsigned int pointer, which faults on strict-alignment CPU architectures. The flaw is reachable by remote attackers who can get a victim to process the malicious file, but requires user interaction and results in single-process crash only, with no code execution, data disclosure, or integrity impact. There is no public exploit code and no evidence of active exploitation; EPSS is 0.14% (3rd percentile) and the CVE is not in CISA KEV, so despite the medium 5.5 CVSS score this is a low real-world priority. Additionally, because x86/x86-64 tolerates misaligned access, the crash is largely limited to ARM, SPARC, MIPS and sanitizer-instrumented builds.
Risk cannot be meaningfully assessed from the provided data: CVE-2026-93682 is associated only with the Ubuntu security tracker (reported by vendor:ubuntu) and arrives with no description, no CVSS vector, no CWE classification, and no CPE mapping, so the affected Ubuntu source package, the exposed component, and the attack surface are all unidentified. Because no vulnerability class, privilege requirement, or user-interaction condition can be established, it is impossible to state whether this is remote code execution, privilege escalation, denial of service, or information disclosure. No public exploit code exists at time of analysis and no EPSS score or CISA KEV entry was supplied, but that silence reflects missing intelligence rather than a confirmed low risk, and no patch information was included in the input.
Ubuntu Linux packages are implicated by a security defect reported through Canonical's coordinated disclosure process, but the intelligence set contains no description, CVSS vector, CWE classification, affected package name, version range, or reference links. Because neither the vulnerable component nor the attack surface can be identified, it is not possible to state whether the issue is remotely or locally exploitable, what privileges an attacker would need, or what level of impact (code execution, privilege escalation, denial of service, information disclosure) would result. No public exploit code and no CISA KEV entry are indicated in the available data, and no vendor patch version is identified at time of analysis; treat this record as unresolved pending retrieval of the corresponding Ubuntu Security Notice (USN) and NVD entry.
The CVE-2026-91767 record currently carries no description, no CVSS score or vector, no CWE mapping, and no CPE data; the only intelligence available is that the report originates from the Ubuntu vendor channel. As a result, the affected package, deployment mode, attack vector, and required privileges are all unknown, and no public exploit code has been identified at time of analysis. Risk cannot be meaningfully assessed from the available data, and the assessment must be repeated once the corresponding Ubuntu Security Notice (USN) or NVD record is published.
CVE-2026-91766 is referenced only through a vendor-originated report from Ubuntu (vendor:ubuntu), and the identifier arrives with no description, no CVSS score or vector, no CWE classification, no CPE data, and no version information. Because the affected component, attack vector, and required privileges are all undefined, the concrete impact on Ubuntu systems cannot be stated, and risk cannot be meaningfully assessed from the available data. No public exploit has been identified at time of analysis, and patch availability could not be determined from the provided data; analysts must retrieve the corresponding Ubuntu Security Notice or the Ubuntu CVE tracker entry to establish the affected source package, supported releases at risk, and any prerequisites.
Impact, prerequisites, and exposure for CVE-2026-91769 cannot be determined from the available intelligence; the only confirmed datum is that Ubuntu's security team is tracking this identifier against a package in the Ubuntu archive (reported by vendor:ubuntu). No description, CVSS score or vector, CWE classification, CPE string, affected version range, or configuration prerequisite was supplied, so it is not possible to state whether the flaw is remotely or locally reachable, what privilege an attacker needs (authentication requirements not confirmed from available data), or how severe the consequence is. Exploitation status is unconfirmed: there is no CISA KEV listing and no public exploit identified at time of analysis, but this reflects absence of reporting rather than evidence of safety. Defenders should treat CVE-2026-91769 as an unassessed Ubuntu package issue until the Ubuntu Security Notice and NVD record are published.
CVE-2026-6103 is an as-yet uncharacterized security issue in software distributed and maintained through Ubuntu, reported to this pipeline solely by the Ubuntu vendor feed with no accompanying description, CVSS vector, or CWE classification. Because the report carries no affected package name, no version range, and no attack-vector metadata, it is not possible to state who is affected beyond Ubuntu users of whatever component the Ubuntu Security Tracker assigns to this CVE, or what an attacker could achieve. No public exploit identified at time of analysis, no CISA KEV entry is present, and no EPSS score was supplied; risk cannot be meaningfully assessed from the available data until the Ubuntu Security Tracker entry (and the corresponding NVD record) is retrieved.
Parsing a malformed OpenEXR image can terminate the host application: OpenEXR 3.4.14's C++ attribute parser constructs an OpaqueAttribute with a NULL packed_data pointer when an EXR file declares an unknown attribute type with dataSize set to zero, and the constructor forwards that NULL pointer to memcpy() without checking the zero-length case, triggering undefined behavior and a crash. The issue is local in vector terms (AV:L) and requires user interaction (UI:R) - an attacker must get the victim or an automated pipeline to open or otherwise ingest the crafted .exr file - and its impact is limited to availability (C:N/I:N/A:H, CVSS 5.5), with no code execution or data disclosure demonstrated. There is no KEV listing and no public exploit identified at time of analysis; the upstream fix is a guard in pull request #2615 rather than a confirmed tagged release.
Incorrect type casting in the Perl DBI module's internal DBI::sql_type_cast routine can cause incorrect conversion results, a crash, or a limited memory over-read when an affected application invokes that routine on a Perl scalar holding an internal integer (IV) or numeric/double (NV) value that an attacker can influence. The independently assessed vector (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:L) indicates a local, high-complexity attack requiring low privileges and no user interaction, with only low confidentiality, integrity and availability impact, and no public exploit code was identified at time of analysis. The entry is extremely data-sparse - no CVSS score or vector, no CWE, no EPSS, no CISA KEV listing and no POC were supplied - so the only substantive artifacts are a commit-message-style fix title ('Fix DBI::sql_type_cast on IV/NV') and a vendor report from Ubuntu, meaning exploitability depends entirely on whether a specific DBD driver or application actually reaches the affected code path with attacker-controlled input.
NanoSVG (memononen/nanosvg, revision 239e102ec) can be crashed by an SVG document whose stroke-width is large enough that floating-point rounding collapses the subdivision angle computed in nsvg__curveDivs() to zero, producing an infinite arc-division value that is converted to int without range validation (CWE-681). The result is undefined behavior that reliably terminates the process on hardening or trap-on-overflow builds, so applications that stroke-rasterize untrusted SVGs suffer a denial of service; the CVSS 3.1 vector AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H (6.5 Medium) means no authentication is required but the victim must open and render the crafted file. Exploitation signals are weak: EPSS is only 0.15% (3rd percentile), no CISA KEV entry exists, and no public exploit code has been identified at time of analysis, and impact is confined to a crash of the embedding process rather than code execution or data compromise.
A crafted Code 128 barcode can abort ZBar (commit 2ea2ca58) with SIGILL when the library is built with trap-mode UndefinedBehaviorSanitizer, because decode_e() returns -1 for an invalid edge pattern and decode6() then left-shifts that negative signed value while assembling the edge signature. The issue is local and requires the victim to feed attacker-supplied barcode input into a ZBar-embedding application (UI:R), and the deterministic crash only occurs in non-default sanitizer builds typically used for development, testing, or fuzzing; production binaries compiled without trap-mode UBSan are not expected to terminate reproducibly. With an EPSS score of only 0.15% (3rd percentile), no KEV listing, and no publicly available exploit code identified at time of analysis, this is a low-priority, sanitizer-configuration-dependent robustness bug rather than a broadly exploitable denial-of-service flaw.
Heap out-of-bounds write in libconfini 1.16.4 causes deterministic denial of service in applications that follow the library's bundled load_ini_buffer.h allocation pattern, which sizes the INI buffer to exactly ini_length bytes while strip_ini_cache() unconditionally writes a NUL terminator at ini_source[ini_length]. Any non-empty INI input is sufficient to trigger the resulting single-byte heap corruption, so exploitation requires no special payload or timing. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L, 5.3) frames the issue as unauthenticated and remotely reachable, but real-world network exposure depends entirely on whether the host application actually parses attacker-supplied INI content; no public exploit code was identified at time of analysis, there is no CISA KEV entry, and EPSS is only 0.15% (3rd percentile), supporting a low-priority availability assessment with no demonstrated code execution.
kube-controller-manager through v1.34.11, v1.35.8, v1.36.4, and v1.37.0 allows an authenticated principal with namespace-scoped write permissions on both StatefulSet and ControllerRevision objects to cause a pod to be created in a different namespace, because the StatefulSet controller restores more than just the spec field from ControllerRevisions in a confused-deputy flaw. The attacker controls the created pod's metadata and namespace selection, but the pod is immediately removed by the garbage collector unless the attacker also supplies a valid StatefulSet OwnerReference using the UID of an existing StatefulSet in the victim namespace, which is the limiting condition that drives the high attack complexity. Rated Medium (5.9) as CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:N; the provided data shows no public exploit identified at time of analysis and no confirmed active exploitation, and vendor patches are available in v1.34.12, v1.35.9, v1.36.5, and v1.37.1.
Denial of service in python-hyper/hpack prior to 4.2.0 allows unauthenticated remote attackers to force run-away computation by supplying malformed HTTP/2 header input containing a variable-length integer encoded as a long run of 0xFF octets; the pre-fix decoder imposes no upper bound on the integer length, producing O(n^2) decoding work that effectively blocks the processing path. The library is a core HPACK header-compression dependency of Python HTTP/2 stacks (h2/hyper), so any internet-facing or otherwise reachable Python HTTP/2 server or client that decodes attacker-influenced headers is exposed, though impact is limited to availability of the affected worker with no confidentiality or integrity effect. No KEV entry or public exploit code was identified at time of analysis, and risk is bounded: the vendor-released fix in hpack 4.2.0 caps variable integer decoding to uint32, and a documented input-sanitization workaround exists.
RabbitMQ's Shovel plugin leaks broker credentials on deployments that configure AMQP 1.0 shovels with the username and password embedded directly in the connection URI: in versions prior to 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.0 the plugin persists the raw URI instead of sanitizing it the way the AMQP 0-9-1 shovel does via amqp_uri:remove_credentials. Any authenticated user holding the 'monitoring' management tag can read those plaintext credentials from GET /api/shovels or rabbitmqctl shovel_status, and can then reuse them against the remote AMQP 1.0 endpoint. There is no public exploit code identified at time of analysis and no confirmed active exploitation (no CISA KEV listing); the exposure is a passive, read-only credential disclosure whose practical severity is narrowed by the non-default URI-embedded-credential configuration and the monitoring-tag requirement. This is a genuine but modest-priority information-disclosure issue rather than a high-urgency flaw.
Denial of service in RabbitMQ (all server releases prior to 3.13.15, 4.0.20, 4.1.11, 4.2.6 and 4.3.0) allows an authenticated user holding the management tag to burn broker CPU through the supported use_regex=true option on management list endpoints. The caller-supplied ?name= pattern is passed to Erlang/OTP's re:run without a match_limit and executed once per resource in the result set, so on a broker with roughly 5000 queues a single request can consume 12 or more minutes of scheduler time, and parallel requests can saturate the schedulers and degrade availability for all clients. There is no confidentiality or integrity impact, no public exploit code identified at time of analysis, and the risk is bounded by the management-tag requirement, no user interaction being needed but a resource-rich deployment being necessary for the effect to be felt.
Cross-Site WebSocket Hijacking (CWE-1385) in RabbitMQ's Web-MQTT and Web-STOMP plugins allows attacker-controlled JavaScript running in a victim's browser to open an authenticated WebSocket connection to the broker, because the WebSocket upgrade handlers at rabbit_web_mqtt_handler.erl:104 and rabbit_web_stomp_handler.erl:102 never validate the Origin header. The flaw is only reachable under non-default configuration - Web-STOMP with use_http_auth=true, or either plugin with ssl_cert_login=true - where the browser automatically presents the victim's TLS client certificate, letting the attacker inherit the victim's identity; the issue is harmless under the default in-band CONNECT credential setup, so default deployments are unaffected. No public exploit has been identified at time of analysis, but the CVSS:3.1 assessment (AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:N) rates the confidentiality and integrity impact as high where a vulnerable configuration is in use.
Memory exhaustion in the RabbitMQ consistent-hash exchange plugin lets an authenticated user with ordinary binding permissions drive broker-wide memory allocation from a single binding. Prior to 3.13.15, 4.0.20, 4.1.11, 4.2.6 and 4.3.0, validate_binding/2 accepts an unbounded integer weight N from the binding routing key and expands it with lists:seq/2; a weight of 100000000 allocates roughly 800 MB on every node, and because the resulting list is written into the exchange's Khepri record it is replicated cluster-wide and reloaded on restart, so a restart does not clear the condition. Exploitation requires the rabbitmq_consistent_hash_exchange plugin to be enabled (it is not enabled by default) plus a low-privilege account holding write on a consistent-hash exchange and read on a queue; no public exploit identified at time of analysis.
Denial of service in RabbitMQ prior to versions 4.2.7 and 4.3.1 allows a remote, authenticated user holding the 'policymaker' tag to crash a broker node by exhausting the Erlang atom table. The runtime-parameters API lookup path coerces the attacker-controlled :component URL segment into a brand-new atom on every request, and because the atom table is bounded and atoms are never garbage collected, roughly one million requests with distinct component values are enough to fill it and bring the node down. Impact is availability-only (no data exposure or modification), exploitation requires high privileges and a very large request volume, and no public exploit code has been identified at time of analysis - the independent assessment rates this a moderate, low-urgency issue and the vendor has released fixed versions 4.2.7 and 4.3.1.
RabbitMQ brokers running the Shovel plugin can write decrypted shovel URIs - including credentials embedded directly in the URI (amqp://user:password@host/) - into the broker log file when DEBUG-level logging is enabled and a shovel configured with src-delete-after=N (autodelete) completes and is torn down. The exposure is confined to log files: anyone who already holds read access to the broker log or a downstream log aggregation pipeline can recover working AMQP credentials, which they can then use to authenticate to the message broker. Exploitation is not remote or unauthenticated (the vendor-adjacent assessment rates it CVSS:3.1 AV:L/AC:L/PR:H/UI:N with high confidentiality impact only), and it requires a chain of non-default conditions: the Shovel plugin enabled, credentials embedded in shovel URIs, DEBUG logging explicitly turned on, and an autodelete shovel. No public exploit code has been identified at time of analysis and the issue is not confirmed actively exploited (no CISA KEV listing); no EPSS score was supplied with the source data.
Denial of service in RabbitMQ affects every server release prior to 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.0, where importing a crafted definitions file can exhaust the Erlang atom table and crash the node. The issue is reachable only by an authenticated user holding the RabbitMQ administrator tag: a definitions import containing a vhosts entry with roughly one million unique metadata keys slips under the 20 MB management body limit and is passed by add_vhost/2 into the unsafe rabbit_data_coercion:atomize_keys/1 path (binary_to_atom) with no whitelist or cap, killing the node that processes the request. Impact is limited to availability loss on a single node (no disclosure or tampering), exploitation is gated behind administrator privileges, and no public exploit code was identified at time of analysis; vendor-released fixes are available in the versions listed above.
Memory exhaustion in RabbitMQ Server (versions prior to 4.1.11, 4.2.6, and 4.3.0) lets a caller holding the management tag crash or severely degrade a broker by submitting a stream partition request whose count is unbounded - validate_partitions only enforces a lower bound of 1, so a value such as lists:seq(0, 500000000) drives roughly 8GB of allocation. Exploitation requires three conditions to hold simultaneously: the rabbitmq_stream_management plugin must be enabled (it is off by default), the caller must carry the management tag, and the caller must have access to the target vhost; with those met, impact is availability-only (CVSS 5.9, PR:H, no confidentiality or integrity effect) and can cross tenant boundaries on a shared broker. No public exploit code has been identified at time of analysis and there is no confirmed active exploitation, keeping this a genuine but bounded availability risk rather than an emergency.
An authenticated denial-of-service condition in RabbitMQ Server allows a stream-protocol user with read access to any stream to crash the broker node by exhausting the Erlang atom table. The flaw affects RabbitMQ Server releases prior to 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.1, but only when the rabbitmq_stream plugin is enabled - deployments without that plugin are not exposed. Exploitation requires valid stream credentials (CVSS 4.0 vector shows PR:L, and the assessed vector is CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H) and the repeated submission of many frames carrying distinct chunk_selector values, which is why the severity is scored as a moderate-priority availability issue rather than a critical remote-code flaw. No public exploit code or confirmed active exploitation has been identified at time of analysis.
Authenticated tenants can bypass operator-configured per-user and per-vhost connection limits in RabbitMQ by connecting to the stream protocol listener on port 5552 instead of the AMQP listener on port 5672, allowing resource-exhaustion conditions that the operator believed were prevented. The flaw affects RabbitMQ Server releases prior to 4.2.7 and 4.3.1 when the rabbitmq_stream plugin is enabled, and the code path was fixed in those two maintenance releases. Exploitation requires valid stream-protocol credentials and an environment where per-user or per-vhost connection caps are actually relied upon as a tenant-isolation control; no public exploit code was identified at time of analysis and there is no confirmed active exploitation (CISA KEV).
Atom-table exhaustion in RabbitMQ's x-jms-topic exchange lets an authenticated low-privilege AMQP user crash an entire broker node in fewer than 100 binding declarations, turning a vhost-confined account into a cross-tenant denial of service. The flaw is reachable only when the bundled rabbitmq_jms_topic_exchange plugin is enabled - standard in any JMS deployment - and the attacker holds read permission on an x-jms-topic exchange plus write permission on a queue, or configure rights to declare both; it also requires a raw AMQP client, because the broker does not enforce the client-side selector compilation that the Java JMS client performs. Fixed in RabbitMQ 3.13.15, 4.0.20, 4.1.11, 4.2.6 and 4.3.0; no public exploit identified at time of analysis and no CISA KEV listing, though the attack needs no user interaction and is network-reachable, with an assessed CVSS 3.1 score of AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H.
Out-of-bounds heap read in GIMP's TIM image loader is triggered when a user opens a crafted 4bpp TIM image that is promoted to an RGBA layer, causing the file-tim plug-in to allocate an undersized row buffer and then process it with the larger RGBA row size. The result is disclosure of adjacent heap memory into the decoded image and a possible plug-in crash, with exploitation requiring local access and victim user interaction (CVSS 4.4, CWE-125). No public exploit is identified at time of analysis, and impact is bounded to partial confidentiality loss and availability loss rather than code execution.
Catastrophic regex backtracking in the JLine3 `nano` editor's regex search mode allows an authenticated user to hang the editor session thread at high CPU, producing a denial of service. The flaw affects applications that embed `org.jline:jline-builtins` and expose the nano editor: `jline-builtins` 3.0.0 through 3.30.14 and 4.0.0 through 4.3.0 are impacted (CWE-1333, CVSS 6.5, CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). A proof-of-concept reproduction, using a buffer of repeated 'a' characters and the pattern `(a+)+b`, is documented in the vendor advisory, and vendor-released patches exist in 3.30.15 and 4.3.1; no confirmed active exploitation (CISA KEV) or public exploit code beyond the advisory PoC has been reported. Practical severity depends on deployment: in a single-user local terminal the user only hangs their own session, whereas remote multi-user services that share worker threads can lose a server thread indefinitely.
A crafted HISTORY_IGNORE value can hang a JLine reader session (org.jline:jline-reader) via catastrophic regular-expression backtracking, pinning the reader thread at high CPU each time a command line is written to history. Applications that embed JLine 3.x (>= 3.0.0, < 3.30.15) or 4.x (>= 4.0.0, < 4.3.1) and let HISTORY_IGNORE be set from user configuration or application settings are affected; the impact is limited to denial of service with no confidentiality or integrity effect. The attacker must already be able to control configuration (CVSS vector PR:L, AV:L), so this is a low-to-moderate real-world priority; no public exploit code was identified at time of analysis, although the vendor advisory documents deterministic reproduction steps, and vendor patches shipping the fix are available in 3.30.15 and 4.3.1.
Unauthenticated file disclosure in Caddy 2.11.3 and earlier allows remote attackers to bypass the file_server `hide` directive by requesting case variants of hidden files. This affects deployments on case-insensitive filesystems (Windows, default macOS/APFS) or where mixed-case path variants coexist; standard case-sensitive Linux filesystems (ext4/xfs) are not affected. Impact is limited to information disclosure of files intended to be hidden, with no integrity or availability impact. Caddy 2.11.4 contains the fix. No public exploit code or active exploitation has been identified at time of analysis.
Denial of service in Caddy Server 2.11.3 and earlier allows remote unauthenticated attackers to exhaust server memory by sending large request bodies when the site configuration resolves the http.request.body placeholder. The unbounded io.Copy in replacer.go reads the entire body before request-body size-limit middleware can apply, leading to process termination. This is not exploitable in default configurations; it requires an operator-defined Caddyfile that uses the placeholder. No public exploit identified at time of analysis, and the attack only affects availability (CVSS 3.1 A:L).
Out-of-bounds write in BusyBox's passwd and group applets allows an authenticated attacker with high privileges (PR:H) to corrupt heap memory via a stale endpoint pointer after field trimming. The vulnerability (CVSS 6.7, CWE-787) is local-only (AV:L), requires no user interaction (UI:N), and is confined to the host (S:U), meaning a would-be attacker must already hold root or equivalent privileges to supply the malformed passwd/group entry. No public exploit code or confirmed active exploitation (CISA KEV) has been identified at time of analysis, and no EPSS score was provided; the primary limiting factor is the PR:H requirement, which makes this a defense-in-depth hardening issue rather than a remotely reachable attack.
Authentication bypass in BusyBox httpd occurs when the server is configured with HTTP Basic Authentication backed by yescrypt ($y$-prefixed) password hashes, which the daemon fails to recognize as hashes and instead compares literally as plaintext - inverting the auth check so the stored hash string itself becomes a usable credential. The flaw is network-reachable and requires no prior authentication (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N, 6.5), with high attack complexity reflecting the dependency on the non-universal yescrypt configuration and the attacker's need to know or obtain the stored hash; impact skews to confidentiality (C:H) with limited integrity effect (I:L). Exposure is concentrated in Red Hat Hardened Images and other deployments where BusyBox httpd actually fronts authentication; there is no public exploit identified at time of analysis and no CISA KEV listing, so this is a configuration-gated weakness rather than a demonstrated in-the-wild attack.
An out-of-bounds heap read in BusyBox's dpkg applet (read_package_field()) allows a local attacker who supplies a malformed .deb package to crash the dpkg process and potentially expose a small amount of heap memory, since the assessed vector rates availability impact as High and confidentiality impact as Low (CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:H, 6.1 Medium). Exploitation is constrained: it requires a BusyBox build with the dpkg applet compiled in (a non-default option in many minimal configurations, though it is present in the Red Hat Hardened Images builds tracked under the associated CPE) and requires the victim or an automated pipeline to actively invoke BusyBox dpkg against the crafted package. No public exploit identified at time of analysis, and no EPSS data was provided for this CVE; Red Hat is tracking the defect for Red Hat Hardened Images.
IP-based deny rules in BusyBox httpd can be silently bypassed: when an administrator configures an access-control rule with an invalid CIDR prefix length, the parser zeroes the netmask so the rule matches no clients and the intended block never takes effect. The flaw is remotely reachable without authentication or user interaction (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N, 5.3), but it only manifests under that administrator-side precondition, so exposure is limited to deployments whose httpd configuration contains malformed deny entries - Red Hat Hardened Images are identified as affected via the published CPE. Impact is confined to confidentiality loss through bypass of the intended IP restriction, and no public exploit identified at time of analysis.
Symlink-following during ld.so cache regeneration in Flatpak before 1.18.1 lets a malicious sandboxed application replace its per-app ~/.var/app/$appid/.ld.so path with a symlink so that Flatpak's regenerate_ld_cache writes cache files at an arbitrary attacker-chosen location. The impact is limited to low-integrity file writes on the local host: the written filenames and content are generated by Flatpak and are not attacker-controlled, so this cannot deliver arbitrary code or leak data, and CVSS 3.1 is 4.0 (AV:L/AC:H/PR:N/UI:R/S:U/C:N/I:L/A:L per independent reassessment). Exploitation requires a user to have installed and run an untrusted Flatpak app from a non-trusted source; there is no public exploit code identified at time of analysis, and the vendor's own advisory characterizes it as hard to exploit.
Local denial of service in alsa-lib through 1.2.16.1 allows a local user with low privileges to crash applications that use the multi PCM plugin by supplying a crafted ALSA configuration file containing sparse binding indices. The flaw is an improper validation of array index (CWE-129) that leads to an out-of-bounds read and an assertion failure, aborting the process. No public exploit code has been identified, and the issue is assessed as low severity with availability-only impact; patching is available via upstream PR 527.
Integer overflow in the ALSA topology decoder of alsa-lib through 1.2.16.1 lets a crafted .tplg topology file wrap the combined control-element size calculation, so the decoder passes its bounds check and reads past the end of the topology buffer, potentially disclosing process memory or crashing the application. Exploitation is local (AV:L) and requires the victim to load an attacker-supplied topology file (UI:P/UI:R, PR:N); no public exploit code has been identified at time of analysis and the issue is not listed in CISA KEV. Independent assessment rates the real-world risk as low-to-moderate: topology files are normally trusted, system-provided sound-card configuration data, so the flaw is only practically reachable where alsa-lib processes topology input from an untrusted source, and the demonstrated impact is limited to low confidentiality and low availability loss.
Apache Tomcat's OpenSSL and OpenSSL-FFM TLS connectors ignore certificate revocation lists when the certificate is loaded from a keystore, so a client certificate that has already been revoked can still be accepted for mutual-TLS authentication. Affected releases are 11.0.0-M1 through 11.0.25, 10.1.0-M1 through 10.1.58, and 9.0.0-M1 through 9.0.121, with end-of-life 8.5.0 through 8.5.100 also known to be affected; fixed versions are 11.0.26, 10.1.59, and 9.0.122. No vendor CVSS score, EPSS value, CISA KEV entry, or public proof-of-concept was supplied, and our internal assessment rates the issue CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N, reachable unauthenticated but only in the non-default combination of an OpenSSL or OpenSSL-FFM TLS connector, keystore-based certificates, mutual-TLS client-certificate authentication, and CRL-based revocation checking; no public exploit identified at time of analysis.
Google Chrome desktop stable-channel builds are covered by a vendor security update that addresses CVE-2026-95375, a defect for which no description, CVSS score or vector, CWE mapping, EPSS probability, or CISA KEV entry is present in the available intelligence. Because the record is essentially a data void, the concrete attack impact, the prerequisite configuration, and the required user interaction cannot be confirmed from the supplied data; the only reliable signal is that Google published a Stable Channel update for Desktop (http://chromereleases.googleblog.com/2026/09/stable-channel-update-for-desktop_0856730748.html) and that the Ubuntu security team is tracking the CVE against its Chromium packaging, which indicates a Linux distribution impact in addition to the upstream browser. No public exploit code exists in the provided data (no POC reference, no KEV listing), so exploitation status is assessed as no public exploit identified at time of analysis, and no EPSS-based likelihood estimate can be cited. Treat this entry as patch-now hygiene rather than as a demonstrated emergency until NVD and the Chrome Releases advisory are populated with the affected component and severity.
CVE-2026-95342 cannot be characterized beyond its origin: the record is attributed to the Ubuntu vendor source, but no description, CVSS vector, CWE, or CPE data has been published, leaving the affected package, affected versions, and achievable attacker impact entirely unidentified. No CISA KEV entry and no public exploit code are associated with this identifier, so there is no public exploit identified at time of analysis; equally, no EPSS-style likelihood can be derived without a description or score. Ubuntu administrators should treat this as an intelligence gap rather than a confirmed threat and monitor the vendor advisory channel for the first substantive disclosure.
Google Chrome desktop on the stable channel is affected by a security defect tracked as CVE-2026-95360, which the vendor has corrected in a later stable-channel build documented on the Chrome Releases blog; the specific affected component, vulnerable version range, and impact are not confirmable because no description, CVSS score or vector, CWE, or CPE data was supplied. Based on the product identity (Chrome desktop stable channel) and typical browser-fix patterns, exploitation most plausibly requires the victim to load attacker-controlled web content in an unpatched Chrome build, making user interaction a likely limiting prerequisite that must be verified against the referenced advisory. No public exploit code has been identified at time of analysis, and there is no CISA KEV listing indicating confirmed active exploitation; patch available per vendor advisory.
Google Chrome on the desktop stable channel is the only affected product identified by the supplied intelligence, which consists of a single Chrome Releases stable-channel advisory, and the specific vulnerability class, affected component, and impact are not disclosed in the available data. No CVSS score or vector, CWE, EPSS probability, or KEV listing accompanies this record, so severity cannot be quantified and the exploitation prerequisites remain unconfirmed; there is no public exploit identified at time of analysis. Because a fixed build is already published, residual risk is chiefly a patch-rollout problem - users remain exposed only until they move to the patched stable-channel version - and no exploitation activity, in-the-wild evidence, or proof-of-concept has been reported in the data provided.
Risk cannot be meaningfully assessed for CVE-2026-95323 because the record contains no description, no CVSS score or vector, no CWE mapping, and no affected-product identifiers, leaving a vendor attribution to Ubuntu as the only intelligence available. With no information about the vulnerable component, its deployment mode, or the attacker's required position, no impact statement, authentication requirement, or exploitation precondition can be derived. There is no public exploit identified at time of analysis, and this should be handled as an unenriched placeholder record that is re-evaluated once NVD or the Ubuntu security team publishes a description and severity metrics.
Ubuntu Linux is the only attributed product for CVE-2026-95307, which reaches us solely through a vendor:ubuntu source with no description, CVSS vector, CWE, CPE, or reference data attached. Because the affected component, attack vector, authentication requirements, and user-interaction prerequisites are all missing, the impact an attacker could achieve cannot be stated and the overall risk cannot be meaningfully assessed from the provided data. There is no KEV listing, no public exploit code identified, and no EPSS score available at time of analysis, so no exploitation signal exists in either direction. Treat this identifier as an unresolved tracking item pending enrichment from the Ubuntu security tracker or NVD.
Impact for CVE-2026-95295 cannot be determined from the available data: the record is tracked by the Ubuntu security team against a package distributed with Ubuntu Linux, but it carries no description, no CVSS vector, and no CWE classification, so the attack vector, required privileges, and user interaction requirements are all unconfirmed. Because no exploitation evidence, KEV listing, or public proof-of-concept is provided, there is no public exploit identified at time of analysis, and the EPSS-style risk signal is absent. The practical consequence is that prioritization must be deferred until the Ubuntu CVE tracker and the corresponding upstream advisory are consulted to identify the specific package, the affected release(s), and whether default installations are exposed.
No impact statement can be made for CVE-2026-95321: the record carries an empty description, no CVSS score or vector, no CWE, no references, and no EPSS, KEV, or POC signals, so neither the vulnerable component nor the consequence of exploitation is defined. The single attribution is a vendor:ubuntu report, which indicates the CVE was surfaced through Ubuntu's security tracking channel but does not identify the affected package, source component, or upstream project. Authentication requirements, deployment prerequisites, and attack vector are all unconfirmable from the available data, and no public exploit code has been identified at time of analysis. Analysts should treat this as an intelligence gap requiring verification against Ubuntu security notices rather than as a validated vulnerability with a known severity.
Impact from CVE-2026-95293 cannot be characterized: the record concerns an unnamed package in the Ubuntu Linux distribution, reported by the Ubuntu security team, with no description, no CVSS score or vector, no CWE classification, and no affected version range supplied. Because the vulnerable component, its deployment mode, and its authentication requirements are all unknown, the attacker capability enabled by this flaw cannot be stated, and authentication requirements are not confirmed from available data. There is no public exploit identified at time of analysis, and the record should be treated as incomplete pending the Ubuntu Security Notice for CVE-2026-95293; risk of real-world exploitation is currently assessed as insufficient data to assess real-world risk.
Risk cannot be meaningfully assessed from the provided data for CVE-2026-95279, which arrives with no description, no CVSS vector, no CWE, and no affected-product detail. The only signal is that the record was reported by the Ubuntu security team, implying an affected open-source package distributed with Ubuntu (and likely Debian-derived distributions), but the specific component, attack vector, and impact remain unconfirmed. There is no confirmed actively exploited (CISA KEV) status, no publicly available exploit code, and no EPSS score in the available input, so triage depends on retrieving the underlying Ubuntu Security Notice or NVD entry before any technical conclusion can be drawn.
Google Chrome desktop builds are affected by a security weakness corrected in a Chrome Releases stable-channel update, but the vulnerability's description, CVSS score, CVSS vector, and CWE are all absent from the available intelligence, so the precise impact class (for example memory corruption, type confusion, or a sandbox escape) cannot be confirmed from this dataset. Consistent with the affected product and the referenced advisory, the most plausible exploitation path requires a victim to run an unpatched Chrome desktop build and load attacker-controlled web content, with user interaction via visiting a malicious or compromised page; authentication requirements are not confirmed from available data. No public exploit identified at time of analysis and no CISA KEV entry is present, while a vendor patch is available, which confines practical risk to installations that have not yet applied the stable-channel update.
CVE-2026-96279 is tracked against software maintained in the Ubuntu archive, based on the only source of intelligence available: a report attributed to the vendor:ubuntu channel that cross-references GitHub advisory GHSA-9rww-v4mm-x4jg. The advisory text itself was not supplied and could not be retrieved, so the vulnerable component, version range, attack vector, and security impact remain undefined; no CVSS score, CVSS vector, or CWE classification was provided. No public exploit code has been identified at time of analysis, and there is no KEV listing or EPSS signal to indicate active exploitation, so the practical risk cannot be meaningfully assessed until the underlying advisory is read. The authenticated/unauthenticated question cannot be answered because no CVSS vector containing PR metrics was provided, and no fix version appears in the available data.
Google Chrome's desktop stable channel is affected by an unspecified security defect that has been addressed in a vendor-released stable channel update (referenced via the Chrome Releases blog). Details of the underlying bug are not publicly characterized in the available data: the CVE carries no description, no CVSS score or vector, no CWE mapping, and no EPSS probability, so the precise attack surface, prerequisite configuration, and worst-case impact cannot be determined from the supplied intelligence. There is no CISA KEV listing and no public exploit identified at time of analysis, and because a patch is already available from the vendor and Chrome ships with an automatic update mechanism, real-world exposure is effectively bounded to installations that have not yet been updated.
CVE-2026-95296 currently has no published description, no CVSS score, no CWE classification, and no CPE identifiers; the only intelligence signal available is that it was reported through the Ubuntu vendor channel, indicating the flaw resides in a component packaged, shipped, or maintained within an Ubuntu release. Because the affected package, version range, exposed feature, and attack path are all unidentified, no impact statement can be made and risk cannot be meaningfully assessed from the provided data. There is no evidence of active exploitation (no CISA KEV entry was supplied) and no public exploit identified at time of analysis.
CVE-2026-95292 is tracked against Ubuntu, identified here only through the vendor:ubuntu reporting source, with no description, CVSS vector, CWE classification, CPE data, or affected package name supplied in the available intelligence. Because the vulnerability class, attack vector, and impacted component are all unknown, the exploitable impact on any Ubuntu release cannot be characterized, and remediation cannot name a fixed package version. No public exploit code has been identified at time of analysis, and no CISA KEV entry is present, so there is no indication of confirmed active exploitation; first-sentence risk cannot be meaningfully assessed from the provided data.
CVE-2026-95300 is currently an unpopulated record: the supplied intelligence contains no description, no CVSS score or vector, no CWE classification, and no CPE data, so the flaw's nature and impact cannot be characterized at this time. The single attribution available is that the record was reported by the Ubuntu vendor source, which suggests Ubuntu may be the coordinating or affected vendor, but no package, version, or component is identified. With no KEV listing and no public exploit code referenced in the input, there is no public exploit identified at time of analysis, and risk cannot be meaningfully assessed from the provided data.
Google Chrome desktop builds are the subject of a stable-channel security release documented in Google's Chrome Releases advisory, referenced under CVE-2026-95363, which was reported by the Ubuntu vendor channel. The record is effectively a data void: no description, CVSS score or vector, CWE, or CPE data were supplied, so raw severity cannot be computed and the affected feature, attack vector, and whether user interaction is required remain unconfirmed. There is no public exploit identified at time of analysis and no CISA KEV listing, while a vendor patch is available per the vendor-reported patch data; treat this as an undetermined-severity item until the advisory and NVD record are populated, and apply the Chrome stable-channel update as the primary action.
Ubuntu is the only product context associated with CVE-2026-95320, attributed solely through a vendor-coordination credit to the Ubuntu security team, and no description, affected package, version range, or vulnerable component has been published. Because the record carries no CVSS score or vector, no CWE assignment, no CPE identifiers, no EPSS estimate, no CISA KEV listing, and no public exploit code, the impact and attack prerequisites are entirely unknown and cannot be inferred. No public exploit has been identified at time of analysis, and no vendor-released patch has been identified at time of analysis; this entry should be treated as an unresolved placeholder to be re-triaged once the CVE record and the corresponding Ubuntu advisory are published.
Ubuntu Linux is the only identified touchpoint for CVE-2026-95290, which was reported through the vendor's own security channel but arrives with an empty description, no CVSS score or vector, no CWE mapping, and no listed affected versions. Because neither the affected package nor the exploitation prerequisites can be derived from the available data, the actual impact - whether local privilege escalation, denial of service, or remote code execution - remains undetermined, and no public exploit identified at time of analysis. Defenders should treat this as an intelligence gap rather than evidence of low severity, and pull the authoritative record from the Ubuntu Security tracker before making any exposure or patching decision.
CVE-2026-95288 is a security flaw tracked through the Ubuntu vendor feed, but its public description is listed as '[Unknown description]' and no CVSS score, CVSS vector, CWE identifier, affected package, or version range accompanies the record. Because exploitation prerequisites, attack vector, and required privilege level are all indeterminate from the supplied data, real-world risk cannot be assessed; defenders should treat this as an uncharacterized entry pending the corresponding Ubuntu Security Notice and NVD record. No CISA KEV listing, no public exploit reference, and no EPSS score were provided, so neither confirmed active exploitation nor publicly available exploit code can be asserted at this time.
Google Chrome desktop (stable channel) builds predating the September 2026 stable-channel update carry a flaw that the vendor has already fixed, but the available intelligence contains no description, CWE, or CVSS vector, so the precise impact cannot be characterized from the supplied data. The affected component is the Google Chrome stable desktop browser, and exploitation would require the victim to run an unpatched build and, in most realistic scenarios, to load attacker-controlled web content, meaning user interaction is likely a prerequisite. There is no KEV listing and no public exploit identified at time of analysis, and no EPSS score was provided to quantify exploitation likelihood; the principal mitigating factor is that the fix is already shipping through Chrome's automatic update mechanism, which sharply limits the exposure window for most managed and consumer deployments.
A remote, unauthenticated denial-of-service condition exists in the RabbitMQ stream protocol when the stream plugin is enabled, allowing a client that completes the Tune handshake to declare a frame larger than the negotiated FrameMax and drive excessive memory consumption. Affected deployments are RabbitMQ 3.13.0 through 3.13.14, 4.0.x before 4.0.20, 4.1.x before 4.1.11, and 4.2.x before 4.2.6; the issue is availability-only with no confidentiality or integrity impact, and exploitation requires the non-default stream plugin (and its listener) to be exposed to the attacker. No public exploit code has been identified at time of analysis, and there is no confirmed active exploitation (CISA KEV) associated with this CVE. Independent assessment rates this as a genuine but low-to-moderate-severity DoS issue rather than a high-impact priority.
Unbounded pre-authentication state accumulation in RabbitMQ's Web STOMP WebSocket handler lets an unauthenticated remote client hold connections open with a slow trickle of small frames, causing memory and resource exhaustion on the broker. Only deployments that enable the non-default rabbitmq_web_stomp plugin and expose its WebSocket listener are affected; a single request is not enough, since the attacker must open and sustain many slow connections over time (reflected as AT:P in the assessed vector). RabbitMQ 3.13.0 through 3.13.14, 4.0.x before 4.0.20, 4.1.x before 4.1.11, and 4.2.x before 4.2.6 are vulnerable, and no public exploit code has been identified at time of analysis.
Opening a crafted Gnumeric workbook can trigger a heap use-after-free (CWE-416) during XML parsing of a malformed SheetObjectComponent element, crashing the application and causing a denial of service. This affects GNOME Gnumeric across versions (CPE: cpe:2.3:a:gnome:gnumeric:*:*:*:*:*:*:*:*). The vulnerability requires local access and user interaction (CVSS:3.1/AV:L/AC:L/PR:N/UI:R), and no public exploit identified at time of analysis.
Silent data-durability loss in the Linux kernel's nvdimm pmem driver occurs when a failed REQ_PREFLUSH barrier is not propagated synchronously, allowing data writes to proceed and a later successful REQ_FUA flush to overwrite the recorded error so the bio completes as if the ordering barrier succeeded. This affects Linux kernels with NVDIMM/PMEM persistent-memory support prior to fixed versions 6.18.52 and 7.2.6; the flaw requires local, low-privileged block I/O submission to a pmem device and only manifests when a real preflush error occurs, yielding silent integrity/durability loss rather than a directly attacker-controllable compromise. No public exploit code or confirmed active exploitation is identified (EPSS 0.15%, 4th percentile).
A mismatched memory free in the Linux kernel's staging rtl8723bs SDIO Wi-Fi driver can corrupt kernel memory: padapter->HalData is allocated with vzalloc() but is released with kfree() on the error path of rtw_sdio_if1_init(), mixing a vmalloc-backed pointer into the slab free path. The flaw is locally triggerable by an authenticated user (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H per independent assessment) and only on systems whose kernel is built with CONFIG_RTL8723BS and that have RTL8723BS SDIO hardware; because the faulty free executes only when interface initialization fails, it is far more likely to surface as an accidental crash or memory-corruption event than as a reliable attacker-controlled primitive. No public exploit code has been identified at time of analysis, EPSS is low at 0.17% (5th percentile), and vendor patches are available, so this is a low-priority, low-real-risk issue despite its MEDIUM 5.5 score.
A resource leak in the Linux kernel's nvmet-rdma driver - the RDMA transport for NVMe-over-Fabrics targets - causes a newly allocated queue and its associated InfiniBand resources to be leaked whenever incoming disconnecting queues exceed the configured connect backlog limit. The issue is reachable without authentication (CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H per independent assessment) but only on hosts actually configured as NVMe-oF RDMA targets with an active RDMA listener, and only via the adjacent RDMA fabric; an attacker or misbehaving initiator must generate rapid repeated connect/disconnect churn. Impact is limited to availability through slow, incremental resource exhaustion rather than an immediate crash, EPSS is very low (0.16%, 5th percentile), and no public exploit code or confirmed active exploitation (CISA KEV) has been identified at time of analysis.
Uninitialized-mutex use in the Linux kernel Bluetooth HCI core can be triggered by a local low-privileged user who causes an HCI controller flagged with quirks such as HCI_QUIRK_RAW_DEVICE (and therefore HCI_UNCONFIGURED) to be registered while the power_on work item races ahead of msft_register() initialization. The window is a narrow timing race in hci_register_dev(), where hdev->msft_data is published before mutex_init(&msft->filter_lock) completes, so hci_power_on() -> hci_dev_do_close() -> msft_do_close() can lock an uninitialized mutex, producing a DEBUG_LOCKS warning and a kernel warning/backtrace (availability impact, no confidentiality or integrity effect). EPSS is 0.17% (5th percentile), there is no CISA KEV listing, and no public exploit code has been identified at time of analysis; vendor-released patches exist for the affected stable branches.
Memory leak in the Linux kernel's btrfs RAID stripe tree error paths causes bioc objects held on a btrfs_ordered_extent's bioc_list to be dropped without being freed, allowing kernel memory to be exhausted over time when applications repeatedly hit those failure paths. Only systems running btrfs with the relatively new RAID stripe tree feature mounted are affected, and the assessed vector (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H) reflects a local, low-privilege condition whose impact requires sustained or abnormal error rates rather than a single operation. No public exploit code exists and EPSS is only 0.17% (5th percentile), so this is a genuinely low-priority issue despite warranting a patch.
In the Linux kernel's Btrfs filesystem, running a block-group balance/relocation on a filesystem that has quota groups enabled can force creation of a relocation root while qgroup_account_snapshot() is committing a pending snapshot, leaving a stale metadata tree reference whose extent item has already been dropped. When delayed refs are processed the kernel hits lookup_inline_extent_backref() with a WARNING and fails the ref insertion with -117 (EUCLEAN), aborting the transaction and flipping the affected Btrfs filesystem read-only; recovery requires unmount and repair/mount, making this strictly an availability issue (no confidentiality or integrity impact). The defect is local-only: the assessed vector is AV:L/AC:H/PR:L/UI:N with high attack complexity, and the assessed risk is LOW despite the Medium 5.5 CVSS base score, because it requires (a) local access able to issue Btrfs administrative ioctls - balance/relocation normally needs CAP_SYS_ADMIN - (b) a filesystem explicitly created or mounted with quota/qgroups enabled, a non-default option, and (c) tight timing between relocation and snapshot creation. EPSS is 0.17% (5th percentile), there is no KEV entry, and no public exploit code was identified at time of analysis; vendor-released patches exist in stable 6.12.111, 6.18.53, 7.2.7 and 7.3-rc2.
A local denial-of-service flaw in the Linux kernel's BPF tracing subsystem lets a user who can load and attach a BTF-enabled raw tracepoint (tp_btf) program panic the kernel by dereferencing the siginfo argument of the signal_generate or signal_deliver tracepoints, which the kernel may populate with the non-pointer sentinel values SEND_SIG_NOINFO (0) or SEND_SIG_PRIV (1). Exploitation requires local access with CAP_BPF plus CAP_PERFMON (or CAP_SYS_ADMIN) on a kernel built with BPF tracing support, matching the assessed CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H vector; there is no remote or network vector, and impact is limited to availability. Risk is considered low-to-moderate: EPSS is only 0.17% (5th percentile), no public exploit code has been identified at time of analysis, and the issue is not listed in CISA KEV. Vendor patches are available in the stable trees referenced by the advisory.
An unbalanced module reference count in the Linux kernel's Intel AVS (Audio, Voice, Speech) ASoC audio driver lets a local, authenticated user leak a module reference every time a specific error path in the driver-open routine is hit, which over repeated triggering can leave the driver module permanently pinned and degrade availability (module unload/reload fails). Only systems running a vulnerable kernel build with the Intel AVS DSP audio stack present and loaded are exposed, and our assessed vector is CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L, a low-to-moderate priority local availability issue rather than a widespread emergency. EPSS is 0.17% (5th percentile), the issue is not in CISA KEV, and no public exploit identified at time of analysis; vendor-released patches exist in stable 6.12.111, 6.18.53 and 7.2.7 plus mainline 7.3-rc3.
Out-of-bounds read in the Linux kernel's Intel AVS ASoC audio driver can crash the kernel when a local user with low privileges causes an oversized module config ID from a DSP topology binary to index the init_configs array. The flaw is limited to local, low-privilege access on systems with Intel AVS audio hardware and the relevant driver loaded; it is not remotely reachable and, per the assessed vector, has no confidentiality or integrity impact. EPSS is low (0.17%, 5th percentile), no public exploit code has been identified at time of analysis, and vendor fixes are available in Linux 6.18.53, 7.2.7, and 7.3-rc3 or corresponding stable backports.
Denial of service in the Linux kernel's bcmasp (Broadcom ASP 2.0) Ethernet driver lets a local user with low privileges (CVSS PR:L) disrupt the transmit path when the driver needs multiple consecutive descriptor slots: tx_spb_ring_full() re-initialises next_index from intf->tx_spb_index inside the loop, so incr_ring() yields the same slot every iteration and only one descriptor is ever tested instead of cnt. The defect affects kernels carrying the bcmasp driver from commit 490cb412007de593e07c1d3e2b1ec4233886707c onward and running on Broadcom embedded/SoC hardware, and is corrected in 6.12.111, 6.18.53, 7.2.7 and 7.3-rc3. EPSS is 0.17% (5th percentile) and no public exploit has been identified at time of analysis, so no public exploit identified at time of analysis and real-world priority is low.
Denial of service in containerd versions prior to 1.7.36, 2.0.13, 2.2.9, 2.3.6, and 2.4.1 allows an unauthenticated attacker who controls or poisons an image source to force excessive CPU and memory consumption during PullImage, causing long ContainerCreating stalls and potential node instability at larger graph sizes. The vulnerability is triggered before container start and requires no privileges on containerd itself, but is limited to environments that pull untrusted images; clusters pulling only trusted first-party images are not exposed. No public exploit identified at time of analysis, and impact is availability-only with no confidentiality or integrity effect.
Risk cannot be meaningfully assessed from the provided data. CVE-2026-94282 is reported solely by the vendor source 'ubuntu', indicating that a package distributed through Ubuntu channels is affected, but no description, CVSS score, CVSS vector, CWE identifier, or affected-version metadata accompanies the record, so the nature of the flaw, the attack surface, and the deployment contexts at risk are all unknown. Exploitation status: no public exploit identified at time of analysis. Authentication requirements are not confirmed from available data, and no CISA KEV listing or EPSS score was provided to indicate real-world exploitation or likelihood. Until the corresponding Ubuntu Security Notice and upstream advisory are retrieved, this record should be treated as an unresolved tracking identifier rather than a characterized vulnerability.
The MongoDB Python Driver (PyMongo) versions 3.9.0 through 4.18.1 can be induced to open connections to local Unix domain sockets on the application host when an attacker who already holds write access to the encryption key metadata in the database alters a key management (KMS) endpoint value so that it ends in '.sock' - a string the client-side field level encryption (CSFLE) code path mistakes for a local socket path instead of a remote host. Exploitation requires the opt-in, non-default CSFLE feature to be in use and an authenticated attacker with database-side write access to the key vault, and it is only reachable over the network in the sense that CVSS scores the vector AV:N/PR:L; the transmitted bytes are restricted to the beginning of a TLS handshake, so no attacker-chosen content reaches the socket and data exfiltration or arbitrary remote-host reachability is not achievable. No public exploit code has been identified at time of analysis and the issue is not in CISA KEV; despite the CWE-918 (SSRF) classification, this is a low-priority, low-impact defect. Vendor-released patch: 4.18.2.
Login CSRF through partial-pipeline session fixation in the social-core library of Python Social Auth before 5.0.0 allows an unauthenticated remote attacker (PR:N) to seed an authentication flow, harvest the resulting partial_token and verification data, and then induce a victim's browser to resume that attacker-controlled flow so the victim ends up authenticated as the attacker's account. Only applications that use resumable partial pipeline steps - such as the built-in mail_validation step or custom steps decorated with @partial - are exposed; success additionally requires victim interaction (UI:R) and reliable delivery of the attacker's token into the victim's browser, which is why the high attack complexity keeps the CVSS 3.1 base score at 4.2. The impact is limited to authenticating the victim as the attacker (a login-CSRF/session-fixation outcome) rather than taking over the victim's own account, and no public exploit has been identified at time of analysis.
Login CSRF in the LoginRadius backend of Python Social Auth (social-core) before 5.0.0 lets an attacker complete a victim's browser session authentication against an attacker-controlled LoginRadius identity, because the OAuth state parameter is never validated during the callback. Only applications that specifically enable the LoginRadius backend are affected; per the assessed vector (AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N, CVSS 4.3) the attacker must possess a valid LoginRadius token and induce user interaction, and the victim's own account is not compromised - they are simply logged in as the attacker, with no confidentiality impact. No public exploit code was identified at time of analysis and there is no CISA KEV listing; the vendor-released fix is social-core 5.0.0, which enforces callback state validation for LoginRadius.
Account impersonation in Python Social Auth (social-core) before version 5.0.0 allows an authenticated Vend user from one shop to be authenticated as a pre-existing local account that was linked to a user from a different shop sharing the same numeric Vend user_id. Only applications that use the Vend OAuth2 backend and authenticate users from more than one Vend shop are affected; the numeric-ID collision is not attacker-controlled and may be uncommon, but successful exploitation yields full compromise of the colliding local account (CVSS 6.8, AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N) with no victim interaction required. No public exploit identified at time of analysis.
SAML account association in python-social-auth (social-core) before 5.0.0 lets an attacker who already holds a valid account on an identity provider trusted by the target application link that SAML identity to a logged-in victim's local account, after which the attacker can authenticate through SAML and access the victim's account. The flaw only reaches deployments that use the SAML backend and enable authenticated account association, and it requires the victim to be logged in and driven through the association flow while the unsolicited SAML response is timed to that session, which is why the assessed vector is network-reachable but high-complexity with user interaction (CVSS:3.1/AV:N/AC:H/PR:L/UI:R, base 6.4). This is a conditional integrity and authentication problem rather than a mass-exploitable emergency; no public exploit identified at time of analysis, and version 5.0.0 resolves it by validating SAML responses against stored AuthnRequest IDs.
Denial of service in libXi before 1.8.4 allows a malicious or compromised X server to crash an attached X client by returning crafted input-device class data that triggers an out-of-bounds read inside XListInputDevices(). This is a client-side, inverted-trust flaw (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H, base 6.5): exploitation requires the victim application to connect to an attacker-controlled display and call the device-enumeration path, and the assessed effect is limited to an availability impact - no confidentiality or integrity loss - despite the CWE-125 classification and the 'Information Disclosure' tag. No public exploit code and no confirmed active exploitation were identified at time of analysis, and the flaw is not reachable when clients talk only to trusted local X servers.
A malicious X server can crash X clients that use libXi before 1.8.4 by returning a crafted reply to the XListInputDevices() call, triggering an out-of-bounds read (CWE-125). The flaw is purely availability-impacting (CVSS 3.1 base 6.5: AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H) and requires the victim to connect to the attacker-controlled X server - for example via X11 forwarding to an untrusted host - and invoke XListInputDevices(). No public exploit code has been identified at time of analysis, and there is no indication of active exploitation (CISA KEV).
Out-of-bounds read in libXi before 1.8.4 allows a malicious X server to crash an attached X client by sending a crafted reply to an XI2 XIQueryDevice request. This is a denial-of-service issue affecting systems where the X client communicates with an untrusted or compromised X server, such as via SSH X11 forwarding to a hostile host or a man-in-the-middle on the X protocol stream. The CVSS vector indicates unauthenticated remote exploitation requiring user interaction (UI:R), with no impact to confidentiality or integrity and only availability impact; no public exploit code has been identified, and the vendor has released a patch fixing the flaw in version 1.8.4.
libXi before 1.8.4 contains an out-of-bounds read in the XI2 device-class parsing helpers size_classes() and copy_classes(), which a malicious or compromised X server can trigger to crash a connecting X client. The issue inverts the usual X11 trust model: the server attacks the client, so exposure is limited to users who connect an affected client to an untrusted display - a remote/forwarded X session or a hostile server - and requires user interaction to establish that connection (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H, 6.5). Impact is confined to client-side denial of service with no code execution, data disclosure, or integrity loss; there is no public exploit identified at time of analysis and no CISA KEV listing, and a vendor fix is available (libXi 1.8.4, upstream commit f499944a).
Out-of-bounds reads in libXi before 1.8.4 can crash X11 client applications when they process a crafted XQueryDeviceState() reply, producing a denial-of-service condition with no code execution or confirmed data disclosure. Exploitation requires the victim to initiate a connection to an attacker-controlled or compromised X server, or an attacker able to tamper with an unauthenticated X protocol stream, matching the UI:R requirement; clients limited to trusted local X servers are effectively not exposed. No public exploit code has been identified at time of analysis, and a vendor fix is available.
RabbitMQ's shovel management resource fails to enforce a policymaker-level check on DELETE operations, so an authenticated user holding the low-privileged 'monitoring' tag - nominally read-only - can delete or restart any dynamic shovel in any vhost visible to that account. The flaw (CWE-862 missing authorization) is reachable over the network with no user interaction and yields high integrity impact against shovel configuration state, though it is bounded by a non-default configuration requiring both the rabbitmq_shovel and rabbitmq_shovel_management plugins to be enabled and by the attacker needing pre-existing credentials plus vhost-scoped visibility. Patches are released in RabbitMQ 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.1; no public exploit code has been identified and there is no confirmed active exploitation (no CISA KEV listing) at time of analysis.
Stack exhaustion in libfyaml 0.9.6 allows a crafted YAML document to crash the process that parses it, producing a denial of service. When fy_atom_iter_format() formats a literal or folded block scalar containing a long run of blank lines, it repeatedly calls alloca() inside a per-line loop; because alloca() memory is only reclaimed when the function returns, the stack grows cumulatively until the process stack limit is exceeded and SIGSEGV occurs. Exploitation is unauthenticated but requires user/application interaction (UI:R) - the target application must actually parse attacker-influenced YAML - and impact is limited to the single parsing process. No public exploit code has been identified at time of analysis, EPSS is low at 0.15% (4th percentile), and the upstream project has published fixing commits referenced from issue #315.
Authenticated users of Rapid7 Velociraptor can trigger a server-side deadlock in the platform's user-management module, hanging server operations and causing a denial of service (CVSS 6.5, AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Exploitation requires only a valid low-privileged account that can reach the user-management code path over the network - no user interaction, no elevated role, and no special configuration - but it offers no data read, modification, or code execution, so it cannot be used for initial access or lateral escalation. Impact is availability-only (CWE-833, lock management bug); no public exploit identified at time of analysis, no CISA KEV listing, and the vendor advisory is the authoritative source for version-specific guidance.
The CVE-2026-17545 record is effectively empty: it ships with no description, no CVSS vector, no CWE mapping, and no CPE data, and the only intelligence attached to it is that it was reported through the Ubuntu vendor coordination channel. Because the affected package, the vulnerable component, and the required attacker position are all unknown, the risk to any specific Ubuntu deployment cannot be meaningfully assessed from the available data and no impact statement should be issued yet. No public exploit code has been identified at time of analysis, and no EPSS score, KEV listing, or proof-of-concept reference accompanies the record, so there is currently no signal of exploitation activity. The immediate action is intelligence collection rather than mitigation: retrieve the corresponding Ubuntu Security Notice and CVE tracker entry to learn which package and version range are involved before assigning severity or exposure.
Risk assessment is currently not possible for CVE-2026-91768, an Ubuntu-tracked identifier that arrives with no description, no CVSS score, no CVSS vector, no CWE classification, and no CPE data; the only signal available is that the record was reported by the Ubuntu vendor source. Because attack vector, privileges required, user interaction, and affected package or deployment mode are all unspecified, no meaningful statement can be made about what an attacker could do or who is exposed. Exploitation status is unconfirmed: no public exploit identified at time of analysis, and there is no KEV listing, no EPSS score, and no proof-of-concept reference in the supplied intelligence. Security teams should treat this identifier as un-triageable and hold it in a watch state until the Ubuntu CVE tracker or the NVD/MITRE record supplies a description and affected package.
Denial of service in LibRaw 0.22.0: opening a crafted RAW, TIFF or DNG file whose TIFF tag 0x00fe (NewSubfileType) carries a value outside signed-int range drives an unchecked narrowing conversion in LibRaw::parse_tiff_ifd(), triggering undefined behavior that terminates the process. The issue is availability-only (CVSS 3.1 5.5, AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H) and requires user interaction - a victim or an automated pipeline must open the malicious file - with no privilege requirement, no data exposure and no code execution. There is no evidence of active exploitation (no CISA KEV listing) and EPSS is low at 0.15% (4th percentile), although the upstream fix PR contains a regression harness with a minimal crafted TIFF that reproduces the out-of-range value, so a public crash reproducer exists.
Opening a specially crafted WAV file with libsndfile 1.2.2 can cause a denial of service when the library's header parser performs an unaligned 4-byte store through a cast unsigned int pointer, which faults on strict-alignment CPU architectures. The flaw is reachable by remote attackers who can get a victim to process the malicious file, but requires user interaction and results in single-process crash only, with no code execution, data disclosure, or integrity impact. There is no public exploit code and no evidence of active exploitation; EPSS is 0.14% (3rd percentile) and the CVE is not in CISA KEV, so despite the medium 5.5 CVSS score this is a low real-world priority. Additionally, because x86/x86-64 tolerates misaligned access, the crash is largely limited to ARM, SPARC, MIPS and sanitizer-instrumented builds.
Risk cannot be meaningfully assessed from the provided data: CVE-2026-93682 is associated only with the Ubuntu security tracker (reported by vendor:ubuntu) and arrives with no description, no CVSS vector, no CWE classification, and no CPE mapping, so the affected Ubuntu source package, the exposed component, and the attack surface are all unidentified. Because no vulnerability class, privilege requirement, or user-interaction condition can be established, it is impossible to state whether this is remote code execution, privilege escalation, denial of service, or information disclosure. No public exploit code exists at time of analysis and no EPSS score or CISA KEV entry was supplied, but that silence reflects missing intelligence rather than a confirmed low risk, and no patch information was included in the input.
Ubuntu Linux packages are implicated by a security defect reported through Canonical's coordinated disclosure process, but the intelligence set contains no description, CVSS vector, CWE classification, affected package name, version range, or reference links. Because neither the vulnerable component nor the attack surface can be identified, it is not possible to state whether the issue is remotely or locally exploitable, what privileges an attacker would need, or what level of impact (code execution, privilege escalation, denial of service, information disclosure) would result. No public exploit code and no CISA KEV entry are indicated in the available data, and no vendor patch version is identified at time of analysis; treat this record as unresolved pending retrieval of the corresponding Ubuntu Security Notice (USN) and NVD entry.
The CVE-2026-91767 record currently carries no description, no CVSS score or vector, no CWE mapping, and no CPE data; the only intelligence available is that the report originates from the Ubuntu vendor channel. As a result, the affected package, deployment mode, attack vector, and required privileges are all unknown, and no public exploit code has been identified at time of analysis. Risk cannot be meaningfully assessed from the available data, and the assessment must be repeated once the corresponding Ubuntu Security Notice (USN) or NVD record is published.
CVE-2026-91766 is referenced only through a vendor-originated report from Ubuntu (vendor:ubuntu), and the identifier arrives with no description, no CVSS score or vector, no CWE classification, no CPE data, and no version information. Because the affected component, attack vector, and required privileges are all undefined, the concrete impact on Ubuntu systems cannot be stated, and risk cannot be meaningfully assessed from the available data. No public exploit has been identified at time of analysis, and patch availability could not be determined from the provided data; analysts must retrieve the corresponding Ubuntu Security Notice or the Ubuntu CVE tracker entry to establish the affected source package, supported releases at risk, and any prerequisites.
Impact, prerequisites, and exposure for CVE-2026-91769 cannot be determined from the available intelligence; the only confirmed datum is that Ubuntu's security team is tracking this identifier against a package in the Ubuntu archive (reported by vendor:ubuntu). No description, CVSS score or vector, CWE classification, CPE string, affected version range, or configuration prerequisite was supplied, so it is not possible to state whether the flaw is remotely or locally reachable, what privilege an attacker needs (authentication requirements not confirmed from available data), or how severe the consequence is. Exploitation status is unconfirmed: there is no CISA KEV listing and no public exploit identified at time of analysis, but this reflects absence of reporting rather than evidence of safety. Defenders should treat CVE-2026-91769 as an unassessed Ubuntu package issue until the Ubuntu Security Notice and NVD record are published.
CVE-2026-6103 is an as-yet uncharacterized security issue in software distributed and maintained through Ubuntu, reported to this pipeline solely by the Ubuntu vendor feed with no accompanying description, CVSS vector, or CWE classification. Because the report carries no affected package name, no version range, and no attack-vector metadata, it is not possible to state who is affected beyond Ubuntu users of whatever component the Ubuntu Security Tracker assigns to this CVE, or what an attacker could achieve. No public exploit identified at time of analysis, no CISA KEV entry is present, and no EPSS score was supplied; risk cannot be meaningfully assessed from the available data until the Ubuntu Security Tracker entry (and the corresponding NVD record) is retrieved.
Parsing a malformed OpenEXR image can terminate the host application: OpenEXR 3.4.14's C++ attribute parser constructs an OpaqueAttribute with a NULL packed_data pointer when an EXR file declares an unknown attribute type with dataSize set to zero, and the constructor forwards that NULL pointer to memcpy() without checking the zero-length case, triggering undefined behavior and a crash. The issue is local in vector terms (AV:L) and requires user interaction (UI:R) - an attacker must get the victim or an automated pipeline to open or otherwise ingest the crafted .exr file - and its impact is limited to availability (C:N/I:N/A:H, CVSS 5.5), with no code execution or data disclosure demonstrated. There is no KEV listing and no public exploit identified at time of analysis; the upstream fix is a guard in pull request #2615 rather than a confirmed tagged release.
Incorrect type casting in the Perl DBI module's internal DBI::sql_type_cast routine can cause incorrect conversion results, a crash, or a limited memory over-read when an affected application invokes that routine on a Perl scalar holding an internal integer (IV) or numeric/double (NV) value that an attacker can influence. The independently assessed vector (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:L) indicates a local, high-complexity attack requiring low privileges and no user interaction, with only low confidentiality, integrity and availability impact, and no public exploit code was identified at time of analysis. The entry is extremely data-sparse - no CVSS score or vector, no CWE, no EPSS, no CISA KEV listing and no POC were supplied - so the only substantive artifacts are a commit-message-style fix title ('Fix DBI::sql_type_cast on IV/NV') and a vendor report from Ubuntu, meaning exploitability depends entirely on whether a specific DBD driver or application actually reaches the affected code path with attacker-controlled input.
NanoSVG (memononen/nanosvg, revision 239e102ec) can be crashed by an SVG document whose stroke-width is large enough that floating-point rounding collapses the subdivision angle computed in nsvg__curveDivs() to zero, producing an infinite arc-division value that is converted to int without range validation (CWE-681). The result is undefined behavior that reliably terminates the process on hardening or trap-on-overflow builds, so applications that stroke-rasterize untrusted SVGs suffer a denial of service; the CVSS 3.1 vector AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H (6.5 Medium) means no authentication is required but the victim must open and render the crafted file. Exploitation signals are weak: EPSS is only 0.15% (3rd percentile), no CISA KEV entry exists, and no public exploit code has been identified at time of analysis, and impact is confined to a crash of the embedding process rather than code execution or data compromise.
A crafted Code 128 barcode can abort ZBar (commit 2ea2ca58) with SIGILL when the library is built with trap-mode UndefinedBehaviorSanitizer, because decode_e() returns -1 for an invalid edge pattern and decode6() then left-shifts that negative signed value while assembling the edge signature. The issue is local and requires the victim to feed attacker-supplied barcode input into a ZBar-embedding application (UI:R), and the deterministic crash only occurs in non-default sanitizer builds typically used for development, testing, or fuzzing; production binaries compiled without trap-mode UBSan are not expected to terminate reproducibly. With an EPSS score of only 0.15% (3rd percentile), no KEV listing, and no publicly available exploit code identified at time of analysis, this is a low-priority, sanitizer-configuration-dependent robustness bug rather than a broadly exploitable denial-of-service flaw.
Heap out-of-bounds write in libconfini 1.16.4 causes deterministic denial of service in applications that follow the library's bundled load_ini_buffer.h allocation pattern, which sizes the INI buffer to exactly ini_length bytes while strip_ini_cache() unconditionally writes a NUL terminator at ini_source[ini_length]. Any non-empty INI input is sufficient to trigger the resulting single-byte heap corruption, so exploitation requires no special payload or timing. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L, 5.3) frames the issue as unauthenticated and remotely reachable, but real-world network exposure depends entirely on whether the host application actually parses attacker-supplied INI content; no public exploit code was identified at time of analysis, there is no CISA KEV entry, and EPSS is only 0.15% (3rd percentile), supporting a low-priority availability assessment with no demonstrated code execution.
kube-controller-manager through v1.34.11, v1.35.8, v1.36.4, and v1.37.0 allows an authenticated principal with namespace-scoped write permissions on both StatefulSet and ControllerRevision objects to cause a pod to be created in a different namespace, because the StatefulSet controller restores more than just the spec field from ControllerRevisions in a confused-deputy flaw. The attacker controls the created pod's metadata and namespace selection, but the pod is immediately removed by the garbage collector unless the attacker also supplies a valid StatefulSet OwnerReference using the UID of an existing StatefulSet in the victim namespace, which is the limiting condition that drives the high attack complexity. Rated Medium (5.9) as CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:N; the provided data shows no public exploit identified at time of analysis and no confirmed active exploitation, and vendor patches are available in v1.34.12, v1.35.9, v1.36.5, and v1.37.1.
Denial of service in python-hyper/hpack prior to 4.2.0 allows unauthenticated remote attackers to force run-away computation by supplying malformed HTTP/2 header input containing a variable-length integer encoded as a long run of 0xFF octets; the pre-fix decoder imposes no upper bound on the integer length, producing O(n^2) decoding work that effectively blocks the processing path. The library is a core HPACK header-compression dependency of Python HTTP/2 stacks (h2/hyper), so any internet-facing or otherwise reachable Python HTTP/2 server or client that decodes attacker-influenced headers is exposed, though impact is limited to availability of the affected worker with no confidentiality or integrity effect. No KEV entry or public exploit code was identified at time of analysis, and risk is bounded: the vendor-released fix in hpack 4.2.0 caps variable integer decoding to uint32, and a documented input-sanitization workaround exists.
RabbitMQ's Shovel plugin leaks broker credentials on deployments that configure AMQP 1.0 shovels with the username and password embedded directly in the connection URI: in versions prior to 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.0 the plugin persists the raw URI instead of sanitizing it the way the AMQP 0-9-1 shovel does via amqp_uri:remove_credentials. Any authenticated user holding the 'monitoring' management tag can read those plaintext credentials from GET /api/shovels or rabbitmqctl shovel_status, and can then reuse them against the remote AMQP 1.0 endpoint. There is no public exploit code identified at time of analysis and no confirmed active exploitation (no CISA KEV listing); the exposure is a passive, read-only credential disclosure whose practical severity is narrowed by the non-default URI-embedded-credential configuration and the monitoring-tag requirement. This is a genuine but modest-priority information-disclosure issue rather than a high-urgency flaw.
Denial of service in RabbitMQ (all server releases prior to 3.13.15, 4.0.20, 4.1.11, 4.2.6 and 4.3.0) allows an authenticated user holding the management tag to burn broker CPU through the supported use_regex=true option on management list endpoints. The caller-supplied ?name= pattern is passed to Erlang/OTP's re:run without a match_limit and executed once per resource in the result set, so on a broker with roughly 5000 queues a single request can consume 12 or more minutes of scheduler time, and parallel requests can saturate the schedulers and degrade availability for all clients. There is no confidentiality or integrity impact, no public exploit code identified at time of analysis, and the risk is bounded by the management-tag requirement, no user interaction being needed but a resource-rich deployment being necessary for the effect to be felt.
Cross-Site WebSocket Hijacking (CWE-1385) in RabbitMQ's Web-MQTT and Web-STOMP plugins allows attacker-controlled JavaScript running in a victim's browser to open an authenticated WebSocket connection to the broker, because the WebSocket upgrade handlers at rabbit_web_mqtt_handler.erl:104 and rabbit_web_stomp_handler.erl:102 never validate the Origin header. The flaw is only reachable under non-default configuration - Web-STOMP with use_http_auth=true, or either plugin with ssl_cert_login=true - where the browser automatically presents the victim's TLS client certificate, letting the attacker inherit the victim's identity; the issue is harmless under the default in-band CONNECT credential setup, so default deployments are unaffected. No public exploit has been identified at time of analysis, but the CVSS:3.1 assessment (AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:N) rates the confidentiality and integrity impact as high where a vulnerable configuration is in use.
Memory exhaustion in the RabbitMQ consistent-hash exchange plugin lets an authenticated user with ordinary binding permissions drive broker-wide memory allocation from a single binding. Prior to 3.13.15, 4.0.20, 4.1.11, 4.2.6 and 4.3.0, validate_binding/2 accepts an unbounded integer weight N from the binding routing key and expands it with lists:seq/2; a weight of 100000000 allocates roughly 800 MB on every node, and because the resulting list is written into the exchange's Khepri record it is replicated cluster-wide and reloaded on restart, so a restart does not clear the condition. Exploitation requires the rabbitmq_consistent_hash_exchange plugin to be enabled (it is not enabled by default) plus a low-privilege account holding write on a consistent-hash exchange and read on a queue; no public exploit identified at time of analysis.
Denial of service in RabbitMQ prior to versions 4.2.7 and 4.3.1 allows a remote, authenticated user holding the 'policymaker' tag to crash a broker node by exhausting the Erlang atom table. The runtime-parameters API lookup path coerces the attacker-controlled :component URL segment into a brand-new atom on every request, and because the atom table is bounded and atoms are never garbage collected, roughly one million requests with distinct component values are enough to fill it and bring the node down. Impact is availability-only (no data exposure or modification), exploitation requires high privileges and a very large request volume, and no public exploit code has been identified at time of analysis - the independent assessment rates this a moderate, low-urgency issue and the vendor has released fixed versions 4.2.7 and 4.3.1.
RabbitMQ brokers running the Shovel plugin can write decrypted shovel URIs - including credentials embedded directly in the URI (amqp://user:password@host/) - into the broker log file when DEBUG-level logging is enabled and a shovel configured with src-delete-after=N (autodelete) completes and is torn down. The exposure is confined to log files: anyone who already holds read access to the broker log or a downstream log aggregation pipeline can recover working AMQP credentials, which they can then use to authenticate to the message broker. Exploitation is not remote or unauthenticated (the vendor-adjacent assessment rates it CVSS:3.1 AV:L/AC:L/PR:H/UI:N with high confidentiality impact only), and it requires a chain of non-default conditions: the Shovel plugin enabled, credentials embedded in shovel URIs, DEBUG logging explicitly turned on, and an autodelete shovel. No public exploit code has been identified at time of analysis and the issue is not confirmed actively exploited (no CISA KEV listing); no EPSS score was supplied with the source data.
Denial of service in RabbitMQ affects every server release prior to 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.0, where importing a crafted definitions file can exhaust the Erlang atom table and crash the node. The issue is reachable only by an authenticated user holding the RabbitMQ administrator tag: a definitions import containing a vhosts entry with roughly one million unique metadata keys slips under the 20 MB management body limit and is passed by add_vhost/2 into the unsafe rabbit_data_coercion:atomize_keys/1 path (binary_to_atom) with no whitelist or cap, killing the node that processes the request. Impact is limited to availability loss on a single node (no disclosure or tampering), exploitation is gated behind administrator privileges, and no public exploit code was identified at time of analysis; vendor-released fixes are available in the versions listed above.
Memory exhaustion in RabbitMQ Server (versions prior to 4.1.11, 4.2.6, and 4.3.0) lets a caller holding the management tag crash or severely degrade a broker by submitting a stream partition request whose count is unbounded - validate_partitions only enforces a lower bound of 1, so a value such as lists:seq(0, 500000000) drives roughly 8GB of allocation. Exploitation requires three conditions to hold simultaneously: the rabbitmq_stream_management plugin must be enabled (it is off by default), the caller must carry the management tag, and the caller must have access to the target vhost; with those met, impact is availability-only (CVSS 5.9, PR:H, no confidentiality or integrity effect) and can cross tenant boundaries on a shared broker. No public exploit code has been identified at time of analysis and there is no confirmed active exploitation, keeping this a genuine but bounded availability risk rather than an emergency.
An authenticated denial-of-service condition in RabbitMQ Server allows a stream-protocol user with read access to any stream to crash the broker node by exhausting the Erlang atom table. The flaw affects RabbitMQ Server releases prior to 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.1, but only when the rabbitmq_stream plugin is enabled - deployments without that plugin are not exposed. Exploitation requires valid stream credentials (CVSS 4.0 vector shows PR:L, and the assessed vector is CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H) and the repeated submission of many frames carrying distinct chunk_selector values, which is why the severity is scored as a moderate-priority availability issue rather than a critical remote-code flaw. No public exploit code or confirmed active exploitation has been identified at time of analysis.
Authenticated tenants can bypass operator-configured per-user and per-vhost connection limits in RabbitMQ by connecting to the stream protocol listener on port 5552 instead of the AMQP listener on port 5672, allowing resource-exhaustion conditions that the operator believed were prevented. The flaw affects RabbitMQ Server releases prior to 4.2.7 and 4.3.1 when the rabbitmq_stream plugin is enabled, and the code path was fixed in those two maintenance releases. Exploitation requires valid stream-protocol credentials and an environment where per-user or per-vhost connection caps are actually relied upon as a tenant-isolation control; no public exploit code was identified at time of analysis and there is no confirmed active exploitation (CISA KEV).
Atom-table exhaustion in RabbitMQ's x-jms-topic exchange lets an authenticated low-privilege AMQP user crash an entire broker node in fewer than 100 binding declarations, turning a vhost-confined account into a cross-tenant denial of service. The flaw is reachable only when the bundled rabbitmq_jms_topic_exchange plugin is enabled - standard in any JMS deployment - and the attacker holds read permission on an x-jms-topic exchange plus write permission on a queue, or configure rights to declare both; it also requires a raw AMQP client, because the broker does not enforce the client-side selector compilation that the Java JMS client performs. Fixed in RabbitMQ 3.13.15, 4.0.20, 4.1.11, 4.2.6 and 4.3.0; no public exploit identified at time of analysis and no CISA KEV listing, though the attack needs no user interaction and is network-reachable, with an assessed CVSS 3.1 score of AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H.
Out-of-bounds heap read in GIMP's TIM image loader is triggered when a user opens a crafted 4bpp TIM image that is promoted to an RGBA layer, causing the file-tim plug-in to allocate an undersized row buffer and then process it with the larger RGBA row size. The result is disclosure of adjacent heap memory into the decoded image and a possible plug-in crash, with exploitation requiring local access and victim user interaction (CVSS 4.4, CWE-125). No public exploit is identified at time of analysis, and impact is bounded to partial confidentiality loss and availability loss rather than code execution.
Catastrophic regex backtracking in the JLine3 `nano` editor's regex search mode allows an authenticated user to hang the editor session thread at high CPU, producing a denial of service. The flaw affects applications that embed `org.jline:jline-builtins` and expose the nano editor: `jline-builtins` 3.0.0 through 3.30.14 and 4.0.0 through 4.3.0 are impacted (CWE-1333, CVSS 6.5, CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). A proof-of-concept reproduction, using a buffer of repeated 'a' characters and the pattern `(a+)+b`, is documented in the vendor advisory, and vendor-released patches exist in 3.30.15 and 4.3.1; no confirmed active exploitation (CISA KEV) or public exploit code beyond the advisory PoC has been reported. Practical severity depends on deployment: in a single-user local terminal the user only hangs their own session, whereas remote multi-user services that share worker threads can lose a server thread indefinitely.
A crafted HISTORY_IGNORE value can hang a JLine reader session (org.jline:jline-reader) via catastrophic regular-expression backtracking, pinning the reader thread at high CPU each time a command line is written to history. Applications that embed JLine 3.x (>= 3.0.0, < 3.30.15) or 4.x (>= 4.0.0, < 4.3.1) and let HISTORY_IGNORE be set from user configuration or application settings are affected; the impact is limited to denial of service with no confidentiality or integrity effect. The attacker must already be able to control configuration (CVSS vector PR:L, AV:L), so this is a low-to-moderate real-world priority; no public exploit code was identified at time of analysis, although the vendor advisory documents deterministic reproduction steps, and vendor patches shipping the fix are available in 3.30.15 and 4.3.1.
Unauthenticated file disclosure in Caddy 2.11.3 and earlier allows remote attackers to bypass the file_server `hide` directive by requesting case variants of hidden files. This affects deployments on case-insensitive filesystems (Windows, default macOS/APFS) or where mixed-case path variants coexist; standard case-sensitive Linux filesystems (ext4/xfs) are not affected. Impact is limited to information disclosure of files intended to be hidden, with no integrity or availability impact. Caddy 2.11.4 contains the fix. No public exploit code or active exploitation has been identified at time of analysis.
Denial of service in Caddy Server 2.11.3 and earlier allows remote unauthenticated attackers to exhaust server memory by sending large request bodies when the site configuration resolves the http.request.body placeholder. The unbounded io.Copy in replacer.go reads the entire body before request-body size-limit middleware can apply, leading to process termination. This is not exploitable in default configurations; it requires an operator-defined Caddyfile that uses the placeholder. No public exploit identified at time of analysis, and the attack only affects availability (CVSS 3.1 A:L).
Out-of-bounds write in BusyBox's passwd and group applets allows an authenticated attacker with high privileges (PR:H) to corrupt heap memory via a stale endpoint pointer after field trimming. The vulnerability (CVSS 6.7, CWE-787) is local-only (AV:L), requires no user interaction (UI:N), and is confined to the host (S:U), meaning a would-be attacker must already hold root or equivalent privileges to supply the malformed passwd/group entry. No public exploit code or confirmed active exploitation (CISA KEV) has been identified at time of analysis, and no EPSS score was provided; the primary limiting factor is the PR:H requirement, which makes this a defense-in-depth hardening issue rather than a remotely reachable attack.
Authentication bypass in BusyBox httpd occurs when the server is configured with HTTP Basic Authentication backed by yescrypt ($y$-prefixed) password hashes, which the daemon fails to recognize as hashes and instead compares literally as plaintext - inverting the auth check so the stored hash string itself becomes a usable credential. The flaw is network-reachable and requires no prior authentication (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N, 6.5), with high attack complexity reflecting the dependency on the non-universal yescrypt configuration and the attacker's need to know or obtain the stored hash; impact skews to confidentiality (C:H) with limited integrity effect (I:L). Exposure is concentrated in Red Hat Hardened Images and other deployments where BusyBox httpd actually fronts authentication; there is no public exploit identified at time of analysis and no CISA KEV listing, so this is a configuration-gated weakness rather than a demonstrated in-the-wild attack.
An out-of-bounds heap read in BusyBox's dpkg applet (read_package_field()) allows a local attacker who supplies a malformed .deb package to crash the dpkg process and potentially expose a small amount of heap memory, since the assessed vector rates availability impact as High and confidentiality impact as Low (CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:H, 6.1 Medium). Exploitation is constrained: it requires a BusyBox build with the dpkg applet compiled in (a non-default option in many minimal configurations, though it is present in the Red Hat Hardened Images builds tracked under the associated CPE) and requires the victim or an automated pipeline to actively invoke BusyBox dpkg against the crafted package. No public exploit identified at time of analysis, and no EPSS data was provided for this CVE; Red Hat is tracking the defect for Red Hat Hardened Images.
IP-based deny rules in BusyBox httpd can be silently bypassed: when an administrator configures an access-control rule with an invalid CIDR prefix length, the parser zeroes the netmask so the rule matches no clients and the intended block never takes effect. The flaw is remotely reachable without authentication or user interaction (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N, 5.3), but it only manifests under that administrator-side precondition, so exposure is limited to deployments whose httpd configuration contains malformed deny entries - Red Hat Hardened Images are identified as affected via the published CPE. Impact is confined to confidentiality loss through bypass of the intended IP restriction, and no public exploit identified at time of analysis.
Symlink-following during ld.so cache regeneration in Flatpak before 1.18.1 lets a malicious sandboxed application replace its per-app ~/.var/app/$appid/.ld.so path with a symlink so that Flatpak's regenerate_ld_cache writes cache files at an arbitrary attacker-chosen location. The impact is limited to low-integrity file writes on the local host: the written filenames and content are generated by Flatpak and are not attacker-controlled, so this cannot deliver arbitrary code or leak data, and CVSS 3.1 is 4.0 (AV:L/AC:H/PR:N/UI:R/S:U/C:N/I:L/A:L per independent reassessment). Exploitation requires a user to have installed and run an untrusted Flatpak app from a non-trusted source; there is no public exploit code identified at time of analysis, and the vendor's own advisory characterizes it as hard to exploit.
Local denial of service in alsa-lib through 1.2.16.1 allows a local user with low privileges to crash applications that use the multi PCM plugin by supplying a crafted ALSA configuration file containing sparse binding indices. The flaw is an improper validation of array index (CWE-129) that leads to an out-of-bounds read and an assertion failure, aborting the process. No public exploit code has been identified, and the issue is assessed as low severity with availability-only impact; patching is available via upstream PR 527.
Integer overflow in the ALSA topology decoder of alsa-lib through 1.2.16.1 lets a crafted .tplg topology file wrap the combined control-element size calculation, so the decoder passes its bounds check and reads past the end of the topology buffer, potentially disclosing process memory or crashing the application. Exploitation is local (AV:L) and requires the victim to load an attacker-supplied topology file (UI:P/UI:R, PR:N); no public exploit code has been identified at time of analysis and the issue is not listed in CISA KEV. Independent assessment rates the real-world risk as low-to-moderate: topology files are normally trusted, system-provided sound-card configuration data, so the flaw is only practically reachable where alsa-lib processes topology input from an untrusted source, and the demonstrated impact is limited to low confidentiality and low availability loss.
Apache Tomcat's OpenSSL and OpenSSL-FFM TLS connectors ignore certificate revocation lists when the certificate is loaded from a keystore, so a client certificate that has already been revoked can still be accepted for mutual-TLS authentication. Affected releases are 11.0.0-M1 through 11.0.25, 10.1.0-M1 through 10.1.58, and 9.0.0-M1 through 9.0.121, with end-of-life 8.5.0 through 8.5.100 also known to be affected; fixed versions are 11.0.26, 10.1.59, and 9.0.122. No vendor CVSS score, EPSS value, CISA KEV entry, or public proof-of-concept was supplied, and our internal assessment rates the issue CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N, reachable unauthenticated but only in the non-default combination of an OpenSSL or OpenSSL-FFM TLS connector, keystore-based certificates, mutual-TLS client-certificate authentication, and CRL-based revocation checking; no public exploit identified at time of analysis.
Google Chrome desktop stable-channel builds are covered by a vendor security update that addresses CVE-2026-95375, a defect for which no description, CVSS score or vector, CWE mapping, EPSS probability, or CISA KEV entry is present in the available intelligence. Because the record is essentially a data void, the concrete attack impact, the prerequisite configuration, and the required user interaction cannot be confirmed from the supplied data; the only reliable signal is that Google published a Stable Channel update for Desktop (http://chromereleases.googleblog.com/2026/09/stable-channel-update-for-desktop_0856730748.html) and that the Ubuntu security team is tracking the CVE against its Chromium packaging, which indicates a Linux distribution impact in addition to the upstream browser. No public exploit code exists in the provided data (no POC reference, no KEV listing), so exploitation status is assessed as no public exploit identified at time of analysis, and no EPSS-based likelihood estimate can be cited. Treat this entry as patch-now hygiene rather than as a demonstrated emergency until NVD and the Chrome Releases advisory are populated with the affected component and severity.
CVE-2026-95342 cannot be characterized beyond its origin: the record is attributed to the Ubuntu vendor source, but no description, CVSS vector, CWE, or CPE data has been published, leaving the affected package, affected versions, and achievable attacker impact entirely unidentified. No CISA KEV entry and no public exploit code are associated with this identifier, so there is no public exploit identified at time of analysis; equally, no EPSS-style likelihood can be derived without a description or score. Ubuntu administrators should treat this as an intelligence gap rather than a confirmed threat and monitor the vendor advisory channel for the first substantive disclosure.
Google Chrome desktop on the stable channel is affected by a security defect tracked as CVE-2026-95360, which the vendor has corrected in a later stable-channel build documented on the Chrome Releases blog; the specific affected component, vulnerable version range, and impact are not confirmable because no description, CVSS score or vector, CWE, or CPE data was supplied. Based on the product identity (Chrome desktop stable channel) and typical browser-fix patterns, exploitation most plausibly requires the victim to load attacker-controlled web content in an unpatched Chrome build, making user interaction a likely limiting prerequisite that must be verified against the referenced advisory. No public exploit code has been identified at time of analysis, and there is no CISA KEV listing indicating confirmed active exploitation; patch available per vendor advisory.
Google Chrome on the desktop stable channel is the only affected product identified by the supplied intelligence, which consists of a single Chrome Releases stable-channel advisory, and the specific vulnerability class, affected component, and impact are not disclosed in the available data. No CVSS score or vector, CWE, EPSS probability, or KEV listing accompanies this record, so severity cannot be quantified and the exploitation prerequisites remain unconfirmed; there is no public exploit identified at time of analysis. Because a fixed build is already published, residual risk is chiefly a patch-rollout problem - users remain exposed only until they move to the patched stable-channel version - and no exploitation activity, in-the-wild evidence, or proof-of-concept has been reported in the data provided.
Risk cannot be meaningfully assessed for CVE-2026-95323 because the record contains no description, no CVSS score or vector, no CWE mapping, and no affected-product identifiers, leaving a vendor attribution to Ubuntu as the only intelligence available. With no information about the vulnerable component, its deployment mode, or the attacker's required position, no impact statement, authentication requirement, or exploitation precondition can be derived. There is no public exploit identified at time of analysis, and this should be handled as an unenriched placeholder record that is re-evaluated once NVD or the Ubuntu security team publishes a description and severity metrics.
Ubuntu Linux is the only attributed product for CVE-2026-95307, which reaches us solely through a vendor:ubuntu source with no description, CVSS vector, CWE, CPE, or reference data attached. Because the affected component, attack vector, authentication requirements, and user-interaction prerequisites are all missing, the impact an attacker could achieve cannot be stated and the overall risk cannot be meaningfully assessed from the provided data. There is no KEV listing, no public exploit code identified, and no EPSS score available at time of analysis, so no exploitation signal exists in either direction. Treat this identifier as an unresolved tracking item pending enrichment from the Ubuntu security tracker or NVD.
Impact for CVE-2026-95295 cannot be determined from the available data: the record is tracked by the Ubuntu security team against a package distributed with Ubuntu Linux, but it carries no description, no CVSS vector, and no CWE classification, so the attack vector, required privileges, and user interaction requirements are all unconfirmed. Because no exploitation evidence, KEV listing, or public proof-of-concept is provided, there is no public exploit identified at time of analysis, and the EPSS-style risk signal is absent. The practical consequence is that prioritization must be deferred until the Ubuntu CVE tracker and the corresponding upstream advisory are consulted to identify the specific package, the affected release(s), and whether default installations are exposed.
No impact statement can be made for CVE-2026-95321: the record carries an empty description, no CVSS score or vector, no CWE, no references, and no EPSS, KEV, or POC signals, so neither the vulnerable component nor the consequence of exploitation is defined. The single attribution is a vendor:ubuntu report, which indicates the CVE was surfaced through Ubuntu's security tracking channel but does not identify the affected package, source component, or upstream project. Authentication requirements, deployment prerequisites, and attack vector are all unconfirmable from the available data, and no public exploit code has been identified at time of analysis. Analysts should treat this as an intelligence gap requiring verification against Ubuntu security notices rather than as a validated vulnerability with a known severity.
Impact from CVE-2026-95293 cannot be characterized: the record concerns an unnamed package in the Ubuntu Linux distribution, reported by the Ubuntu security team, with no description, no CVSS score or vector, no CWE classification, and no affected version range supplied. Because the vulnerable component, its deployment mode, and its authentication requirements are all unknown, the attacker capability enabled by this flaw cannot be stated, and authentication requirements are not confirmed from available data. There is no public exploit identified at time of analysis, and the record should be treated as incomplete pending the Ubuntu Security Notice for CVE-2026-95293; risk of real-world exploitation is currently assessed as insufficient data to assess real-world risk.
Risk cannot be meaningfully assessed from the provided data for CVE-2026-95279, which arrives with no description, no CVSS vector, no CWE, and no affected-product detail. The only signal is that the record was reported by the Ubuntu security team, implying an affected open-source package distributed with Ubuntu (and likely Debian-derived distributions), but the specific component, attack vector, and impact remain unconfirmed. There is no confirmed actively exploited (CISA KEV) status, no publicly available exploit code, and no EPSS score in the available input, so triage depends on retrieving the underlying Ubuntu Security Notice or NVD entry before any technical conclusion can be drawn.
Google Chrome desktop builds are affected by a security weakness corrected in a Chrome Releases stable-channel update, but the vulnerability's description, CVSS score, CVSS vector, and CWE are all absent from the available intelligence, so the precise impact class (for example memory corruption, type confusion, or a sandbox escape) cannot be confirmed from this dataset. Consistent with the affected product and the referenced advisory, the most plausible exploitation path requires a victim to run an unpatched Chrome desktop build and load attacker-controlled web content, with user interaction via visiting a malicious or compromised page; authentication requirements are not confirmed from available data. No public exploit identified at time of analysis and no CISA KEV entry is present, while a vendor patch is available, which confines practical risk to installations that have not yet applied the stable-channel update.
CVE-2026-96279 is tracked against software maintained in the Ubuntu archive, based on the only source of intelligence available: a report attributed to the vendor:ubuntu channel that cross-references GitHub advisory GHSA-9rww-v4mm-x4jg. The advisory text itself was not supplied and could not be retrieved, so the vulnerable component, version range, attack vector, and security impact remain undefined; no CVSS score, CVSS vector, or CWE classification was provided. No public exploit code has been identified at time of analysis, and there is no KEV listing or EPSS signal to indicate active exploitation, so the practical risk cannot be meaningfully assessed until the underlying advisory is read. The authenticated/unauthenticated question cannot be answered because no CVSS vector containing PR metrics was provided, and no fix version appears in the available data.
Google Chrome's desktop stable channel is affected by an unspecified security defect that has been addressed in a vendor-released stable channel update (referenced via the Chrome Releases blog). Details of the underlying bug are not publicly characterized in the available data: the CVE carries no description, no CVSS score or vector, no CWE mapping, and no EPSS probability, so the precise attack surface, prerequisite configuration, and worst-case impact cannot be determined from the supplied intelligence. There is no CISA KEV listing and no public exploit identified at time of analysis, and because a patch is already available from the vendor and Chrome ships with an automatic update mechanism, real-world exposure is effectively bounded to installations that have not yet been updated.
CVE-2026-95296 currently has no published description, no CVSS score, no CWE classification, and no CPE identifiers; the only intelligence signal available is that it was reported through the Ubuntu vendor channel, indicating the flaw resides in a component packaged, shipped, or maintained within an Ubuntu release. Because the affected package, version range, exposed feature, and attack path are all unidentified, no impact statement can be made and risk cannot be meaningfully assessed from the provided data. There is no evidence of active exploitation (no CISA KEV entry was supplied) and no public exploit identified at time of analysis.
CVE-2026-95292 is tracked against Ubuntu, identified here only through the vendor:ubuntu reporting source, with no description, CVSS vector, CWE classification, CPE data, or affected package name supplied in the available intelligence. Because the vulnerability class, attack vector, and impacted component are all unknown, the exploitable impact on any Ubuntu release cannot be characterized, and remediation cannot name a fixed package version. No public exploit code has been identified at time of analysis, and no CISA KEV entry is present, so there is no indication of confirmed active exploitation; first-sentence risk cannot be meaningfully assessed from the provided data.
CVE-2026-95300 is currently an unpopulated record: the supplied intelligence contains no description, no CVSS score or vector, no CWE classification, and no CPE data, so the flaw's nature and impact cannot be characterized at this time. The single attribution available is that the record was reported by the Ubuntu vendor source, which suggests Ubuntu may be the coordinating or affected vendor, but no package, version, or component is identified. With no KEV listing and no public exploit code referenced in the input, there is no public exploit identified at time of analysis, and risk cannot be meaningfully assessed from the provided data.
Google Chrome desktop builds are the subject of a stable-channel security release documented in Google's Chrome Releases advisory, referenced under CVE-2026-95363, which was reported by the Ubuntu vendor channel. The record is effectively a data void: no description, CVSS score or vector, CWE, or CPE data were supplied, so raw severity cannot be computed and the affected feature, attack vector, and whether user interaction is required remain unconfirmed. There is no public exploit identified at time of analysis and no CISA KEV listing, while a vendor patch is available per the vendor-reported patch data; treat this as an undetermined-severity item until the advisory and NVD record are populated, and apply the Chrome stable-channel update as the primary action.
Ubuntu is the only product context associated with CVE-2026-95320, attributed solely through a vendor-coordination credit to the Ubuntu security team, and no description, affected package, version range, or vulnerable component has been published. Because the record carries no CVSS score or vector, no CWE assignment, no CPE identifiers, no EPSS estimate, no CISA KEV listing, and no public exploit code, the impact and attack prerequisites are entirely unknown and cannot be inferred. No public exploit has been identified at time of analysis, and no vendor-released patch has been identified at time of analysis; this entry should be treated as an unresolved placeholder to be re-triaged once the CVE record and the corresponding Ubuntu advisory are published.
Ubuntu Linux is the only identified touchpoint for CVE-2026-95290, which was reported through the vendor's own security channel but arrives with an empty description, no CVSS score or vector, no CWE mapping, and no listed affected versions. Because neither the affected package nor the exploitation prerequisites can be derived from the available data, the actual impact - whether local privilege escalation, denial of service, or remote code execution - remains undetermined, and no public exploit identified at time of analysis. Defenders should treat this as an intelligence gap rather than evidence of low severity, and pull the authoritative record from the Ubuntu Security tracker before making any exposure or patching decision.
CVE-2026-95288 is a security flaw tracked through the Ubuntu vendor feed, but its public description is listed as '[Unknown description]' and no CVSS score, CVSS vector, CWE identifier, affected package, or version range accompanies the record. Because exploitation prerequisites, attack vector, and required privilege level are all indeterminate from the supplied data, real-world risk cannot be assessed; defenders should treat this as an uncharacterized entry pending the corresponding Ubuntu Security Notice and NVD record. No CISA KEV listing, no public exploit reference, and no EPSS score were provided, so neither confirmed active exploitation nor publicly available exploit code can be asserted at this time.
Google Chrome desktop (stable channel) builds predating the September 2026 stable-channel update carry a flaw that the vendor has already fixed, but the available intelligence contains no description, CWE, or CVSS vector, so the precise impact cannot be characterized from the supplied data. The affected component is the Google Chrome stable desktop browser, and exploitation would require the victim to run an unpatched build and, in most realistic scenarios, to load attacker-controlled web content, meaning user interaction is likely a prerequisite. There is no KEV listing and no public exploit identified at time of analysis, and no EPSS score was provided to quantify exploitation likelihood; the principal mitigating factor is that the fix is already shipping through Chrome's automatic update mechanism, which sharply limits the exposure window for most managed and consumer deployments.