Vulnerabilities
All
My stack
Known exploited
Public exploit
Critical (9+)
Likely exploited (EPSS ≥ 50%)
Changed, 24 h
New, 24 h
Sort:
risk
modified
published
CVSS
EPSS
| CVE | CVSS | EPSS | Vendor, product | Description | Modified |
|---|---|---|---|---|---|
| CVE-2016-9840 | 8.8 high | 5.0% | boost, zlib, leap | inftrees.c in zlib 1.2.8 might allow context-dependent attackers to have unspecified impact by leveraging improper pointer arithmetic. | 8 Oct |
| CVE-2026-32555 | 9.3 critical | 0.00% | no CPE yet | Unauthenticated SQL Injection in Boost <= 2.0.4 versions. | 12 Oct |
| CVE-2026-103081 | 7.5 high | 0.00% | no CPE yet | Improper Control of Generation of Code ('Code Injection') vulnerability in VillaTheme Salevo woo-boost-sales allows Code Injection.This issue affects Salevo: from n/a through 1.3.0. | 15 Oct |
| CVE-2026-32556 | 7.1 high | 0.00% | no CPE yet | Unauthenticated Cross Site Scripting (XSS) in Boost <= 2.0.4 versions. | 12 Oct |
| CVE-2025-62511 | 6.3 medium | 0.00% | no CPE yet | yt-grabber-tui is a C++ terminal user interface application for downloading YouTube content. yt-grabber-tui version 1.0 contains a Time-of-Check to Time-of-Use (TOCTOU) race condition (CWE-367) in the creation of the default configuration file config.json. In version 1.0, load_json_settings in Settings.hpp checks for the existence of config.json using boost::filesystem::exists and, if the file is missing, calls create_json_settings which writes the JSON configuration with boost::property_tree::write_json. A local attacker with write access to the application’s configuration directory (~/.config/yt-grabber-tui on Linux or the current working directory on Windows) can create a symbolic link between the existence check and the subsequent write so that the write operation follows the symlink and overwrites an attacker-chosen file accessible to the running process. This enables arbitrary file overwrite within the privileges of the application process, which can corrupt files and cause loss of application or user data. If the application is executed with elevated privileges, this could extend to system file corruption. The issue is fixed in version 1.0.1. | 8 Oct |
| CVE-2026-103080 | 5.3 medium | 0.00% | no CPE yet | External Control of Assumed-Immutable Web Parameter vulnerability in VillaTheme Salevo woo-boost-sales allows Input Data Manipulation.This issue affects Salevo: from n/a through 1.3.0. | 13 Oct |
| CVE-2026-99005 | unscored | 0.00% | no CPE yet | In the Linux kernel, the following vulnerability has been resolved: drm/i915/gt: Unmask interrupts only when ACTIVE is true There is a small race window between intel_rps_boost() reading a stale ACTIVE state and queuing rps->work, where ACTIVE may be changed via asynchronous calls triggered by wakeref drop. This means that rps_work() could be triggered after the GT has been parked, so unmasking RPS PM interrupts would happen without holding PM wakelock. This sequence of events may be observed during live_rc6_ctx_wa() selftest: 1) live_rc6_ctx_wa() -> intel_engine_pm_put() -> wakeref_put() ASYNC1) wakeref_put() callback -> __engine_park() -> intel_gt_pm_put_async() -> intel_gt_pm_put_async_untracked() -> intel_wakeref_put_async() ASYNC2) wakeref_put_async() callback -> __gt_park() -> intel_rps_park() -> intel_rps_clear_active() [clear ACTIVE] WITH INTERRUPTS: -> rps_disable_interrupts() -> cancel_work_sync(rps->work) -> rps_reset_interrupts() [rps->pm_iir = 0] WITHOUT INTERRUPTS (TIMER mode): -> rps_stop_timer() -> cancel_work_sync(rps->work) 2) live_rc6_ctx_wa() -> intel_gt_wait_for_idle() -> intel_gt_retire_requests_timeout() -> dma_fence_wait_timeout() -> ops->wait() [i915_fence_wait()] -> i915_request_wait_timeout() -> intel_rps_boost() -> intel_rps_is_active() [check ACTIVE] [OPEN RACE WINDOW] -> queue_work(rps->work) -> retire_requests() -> i915_request_retire() -> intel_rps_dec_waiters() [from 1 to 0] If ASYNC1 and ASYNC2 would execute during [OPEN RACE WINDOW], then: 3) rps_work() executes from the workqueue and may satisfy "(!pm_iir && !client_boost)" test (in TIMER mode rps->pm_iir is zeroed by an earlier rps_work() call or never gets a new value after previous intel_rps_unpark() event), so it jumps to "out" label, bypassing intel_rps_is_active() guard and executes gen6_gt_pm_unmask_irq(); 4) GT is parked and runtime PM wakelock is dropped, so only a raw reference in __gt_park() -> intel_display_power_put_async() remains for 100ms, then the MMIO write in gen6_gt_pm_unmask_irq() detects missing wakelock via assert_rpm_wakelock_held() and emits "RPM wakelock ref not held during HW access" tainting kernel. Commit 3e7abf814193 ("drm/i915: Extract GT render power state management") dropped the "if (rps->interrupts_enabled)" guard that gen6_pm_rps_work() had around this unmask in i915_irq.c. INTEL_RPS_ACTIVE brackets the same window, since it is set in intel_rps_unpark() before rps_enable_interrupts() and rps_start_timer() and cleared in intel_rps_park() before rps_stop_timer() and rps_disable_interrupts(). Skip unmasking when RPS is no longer active (reaching unmask operation is independent of INTERRUPT mode). This does not prevent RPS operation from resuming on the next unpark. In interrupt mode, intel_rps_unpark() calls rps_enable_interrupts(), which enables and unmasks the PM interrupts. In timer mode, it calls rps_start_timer(), restarting periodic engine-busyness evaluation. The timer generates software RPS events and queues rps_work() directly, independently of PM interrupt delivery. Neither mode requires the late worker to unmask interrupts while the GT is parked (cherry picked from commit ca4a6deadad15b91ee083afe445fa6bdbfb68206) | Fri 23 Oct |
7 of 7
Download these 7 as CSV · subscribe to this list.
EPSS scores: 2026-10-28. NVD cursor: 2026-10-29 00:22. The News page shows only notable CVEs (KEV, your stack, new criticals, EPSS over 50%, or active exploitation per SSVC); this table has all of them.