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-2025-12049 | 9.2 critical | 0.00% | sharp, mp-01_firmware | Missing Authentication for Critical Function vulnerability in Sharp Display Solutions Media Player MP-01 All Verisons allows a attacker may access to the web interface of the affected product without authentication and change settings or perform other operations, and deliver content from the authoring software to the affected product without authentication. | 19 Oct |
| CVE-2026-114111 | 8.9 high | 0.00% | no CPE yet | sharp before 0.35.5 bundles a librsvg dependency affected by a memory-related vulnerability (CVE-2026-96889) that, under certain runtime-specific conditions, can lead to code execution on glibc-based Linux. An attacker can supply a crafted SVG image that, when decoded by sharp through librsvg, may result in arbitrary code execution. | 23 h ago |
| CVE-2026-114112 | 8.9 high | 0.00% | no CPE yet | Sharp before 0.35.4 bundles a vulnerable libheif dependency that allows attackers to achieve possible remote code execution on glibc-based Linux by supplying crafted images. Attackers can submit malicious AVIF/HEIF input to applications processing untrusted images with sharp, triggering libheif decoding flaws to execute code. | Thu 22 Oct |
| CVE-2026-114113 | 8.4 high | 0.00% | no CPE yet | Sharp before 0.35.0 bundles a version of libvips affected by multiple vulnerabilities (CVE-2026-33327, CVE-2026-33328, CVE-2026-35590, CVE-2026-35591 and CVE-2026-69242) in its GIF, TIFF and VIPS image decoders. Attackers can supply crafted GIF, TIFF or VIPS files to applications using sharp to process untrusted input, triggering these libvips flaws. | Tue 27 Oct |
| CVE-2026-90009 | 7.8 high | 0.00% | no CPE yet | In the Linux kernel, the following vulnerability has been resolved: scsi: bsg: Fix TOCTOU in io_uring passthrough command setup scsi_bsg_uring_cmd() reads bsg_uring_cmd from the shared mmap'd SQE. Userspace can change a field after we check it and before we use it. request_len is the sharp case: it can grow past sizeof(scmd->cmnd) after the bound check and overflow scmd->cmnd in copy_from_user(). READ_ONCE() the SQE fields we check or use into locals before use. | 19 Oct |
| CVE-2026-47247 | 7.5 high | 0.00% | struktur, libheif | libheif is a HEIF and AVIF file format decoder and encoder. Prior to version 1.22.0, two bugs in libheif chain to leak process heap memory as visible pixel values in decoded grid images. An attacker who uploads a crafted AVIF/HEIC file to any server-side image processor (WordPress, Sharp/libvips, ImageMagick, etc.) can recover heap data - including library function pointers sufficient to defeat ASLR, or any other secret - from the publicly-downloadable transcoded JPEG/PNG/WebP output. Local attack vectors are also possible. Version 1.22.0 fixes the issue. | Sat 24 Oct |
| CVE-2025-61457 | 6.1 medium | 0.00% | no CPE yet | code16 Sharp v9.6.6 is vulnerable to Cross Site Scripting (XSS) src/Form/Fields/SharpFormUploadField.php. | Tue 27 Oct |
| CVE-2025-62798 | 5.4 medium | 0.00% | no CPE yet | Sharp is a content management framework built for Laravel as a package. Prior to 9.11.1, a Cross-Site Scripting (XSS) vulnerability was discovered in code16/sharp when rendering content using the SharpShowTextField component. In affected versions, expressions wrapped in {{ & }} were evaluated by Vue. This allowed attackers to inject arbitrary JavaScript or HTML that executes in the browser when the field is displayed. The issue has been fixed in v9.11.1 . | 8 Oct |
| CVE-2026-78116 | 5.2 medium | 0.00% | no CPE yet | The Broadcom AFBR-S50 time-of-flight sensor driver double-completes an RTIO submission when sensor data evaluation fails. In data_ready_work_handler() (drivers/sensor/broadcom/afbr_s50/afbr_s50.c), a non-STATUS_OK return from Argus_EvaluateData() calls handle_error_on_result(), which finalises the request with rtio_iodev_sqe_err(), but execution then fell through to the tail of the function and finalised the very same struct rtio_iodev_sqe a second time with rtio_iodev_sqe_ok(). Unlike the other error branches in the same function, this one did not return. Both completion helpers reach rtio_executor_done() in subsys/rtio/rtio_executor.c, which returns the submission to the pool via rtio_sqe_pool_free() and, for streaming (multishot) submissions, also releases the RX buffer with rtio_release_buffer(). The second completion therefore reads a freed rtio_iodev_sqe, pushes the same mpsc node onto the submission queue while it is already on the pool free list — splicing the two lists together — and re-submits the freed request so the next measurement is written through an already-released buffer. For one-shot submissions it emits a spurious success completion carrying stale userdata and frees the same pool entry twice. The failure branch is driven by sensor conditions rather than by host software. The vendor API documents statuses such as ERROR_ARGUS_BIAS_VOLTAGE_REINIT and ERROR_ARGUS_LASER_MONITOR_INACTIVE as transient results of harsh ambient light, so a party in front of the optical sensor can provoke the invalid-data condition without any physical contact with the board or any software access; SPI transfer errors reach the same branch. In releases before the payload.Status check was dropped, ordinary sharp distance transitions in the sensor's field of view were sufficient. Impact is corruption of the RTIO submission pool and mempool bookkeeping: aliased submissions, writes through released buffers, and duplicate completions delivered to the application. The attacker does not control the corrupted content, so the practical consequence is memory corruption and loss of availability on devices that instantiate brcm,afbr-s50, rather than directed code execution. Only builds that enable this driver are affected. | Fri 23 Oct |
| CVE-2026-90363 | unscored | 0.00% | no CPE yet | In the Linux kernel, the following vulnerability has been resolved: drm/msm: don't tear down KMS twice when KMS init fails When priv->kms_init() (mdp4_kms_init() / mdp5_kms_init()) fails partway through, both display drivers already tear their KMS state down via mdp4_destroy() / mdp5_kms_destroy() before returning the error. The common error path in msm_drm_init() then runs msm_drm_uninit() -> msm_drm_kms_uninit(), which tries to destroy the very same KMS a second time, which causes a use-after-free crash. Bring MDP4/MDP5 in line with the DPU driver whose dpu_kms_init() doesn't perform error cleanup on the failure. Let the common path own the cleanup, instead of freeing the KMS from their error paths. The crash trace for the reference: __lock_acquire from lock_acquire (kernel/locking/lockdep.c:5906 kernel/locking/lockdep.c:5863) lock_acquire from touch_wq_lockdep_map (kernel/workqueue.c:4094 (discriminator 1)) touch_wq_lockdep_map from __flush_workqueue (kernel/workqueue.c:4136) __flush_workqueue from msm_drm_kms_uninit (drivers/gpu/drm/msm/msm_kms.c:243 (discriminator 33)) msm_drm_kms_uninit from msm_drm_uninit (drivers/gpu/drm/msm/msm_drv.c:93) msm_drm_uninit from msm_drm_init (drivers/gpu/drm/msm/msm_drv.c:184) msm_drm_init from try_to_bring_up_aggregate_device (drivers/base/component.c:249 drivers/base/component.c:227) try_to_bring_up_aggregate_device from __component_add (drivers/base/component.c:269 drivers/base/component.c:748) __component_add from dsi_host_attach (drivers/gpu/drm/msm/dsi/dsi_host.c:1739) dsi_host_attach from mipi_dsi_attach (drivers/gpu/drm/drm_mipi_dsi.c:383) mipi_dsi_attach from sharp_nt_panel_probe (drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c:247) Patchwork: https://patchwork.freedesktop.org/patch/742068/ | 21 Oct |
10 of 10
Download these 10 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.