Export limit exceeded: 400318 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (400318 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-34189 | 2026-10-01 | N/A | ||
| Cross-Site Request Forgery (CSRF) vulnerability allows unauthorized deletion of event responses via a forged GET request when an authenticated administrator visits a malicious page. This issue affects Pandora FMS: from 777 onwards. | ||||
| CVE-2026-96577 | 1 Redhat | 2 Assisted Installer, Openshift | 2026-10-01 | 7.1 High |
| A flaw was found in oc-mirror. During mirroring operations, the embedded local cache registry binds to all network interfaces without authentication or encryption instead of restricting access to the local system. An unauthenticated attacker on an adjacent network can connect to the exposed service to push tampered container images, delete cached images, or access mirrored content. | ||||
| CVE-2026-83589 | 2 Oauth2 Proxy Project, Redhat | 2 Oauth2 Proxy, Openshift | 2026-10-01 | 6.1 Medium |
| A flaw was found in oauth-proxy. The application fails to properly validate the destination redirect parameter (`rd`) during post-login redirection. A remote attacker can exploit this vulnerability by enticing a user to follow a specially crafted link, resulting in the user being redirected to an arbitrary external website after authenticating. This open redirect can be leveraged to conduct phishing attacks or credential theft. | ||||
| CVE-2026-103497 | 2026-10-01 | 5.5 Medium | ||
| In JetBrains YouTrack before 2026.2.19422 sSRF was possible via the GitHub VCS integration | ||||
| CVE-2026-103496 | 2026-10-01 | 5.4 Medium | ||
| In JetBrains YouTrack before 2026.2.19422 iDOR in inbox threads allowed reading other users' notifications | ||||
| CVE-2026-103495 | 2026-10-01 | 4.3 Medium | ||
| In JetBrains YouTrack before 2026.2.19422 missing authorisation allowed reloading of translation catalogs | ||||
| CVE-2026-103494 | 2026-10-01 | 6.6 Medium | ||
| In JetBrains YouTrack before 2026.2.19422 privilege escalation was possible via user group membership changes | ||||
| CVE-2026-103493 | 2026-10-01 | 8.1 High | ||
| In JetBrains YouTrack before 2026.2.19422 stored XSS via Mermaid and LaTeX content was possible | ||||
| CVE-2026-103492 | 2026-10-01 | 6.5 Medium | ||
| In JetBrains YouTrack before 2026.2.19422 doS attack was possible via crafted PSD attachments | ||||
| CVE-2026-103491 | 2026-10-01 | 6.5 Medium | ||
| In JetBrains YouTrack before 2026.2.19422 iDOR in the issue activities API allowed reading restricted issues | ||||
| CVE-2026-103490 | 2026-10-01 | 7.2 High | ||
| In JetBrains YouTrack before 2026.2.19422 privilege escalation was possible via user group links | ||||
| CVE-2026-103489 | 2026-10-01 | 2 Low | ||
| In JetBrains YouTrack before 2026.2.19422 hTML injection in VCS command failure notifications was possible | ||||
| CVE-2026-103488 | 2026-10-01 | 7.1 High | ||
| In JetBrains YouTrack before 2026.2.19422 missing authorisation allowed authenticated users to add themselves to project teams and access restricted issues | ||||
| CVE-2026-97575 | 1 Linux | 1 Linux Kernel | 2026-10-01 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: media: v4l2-ctrls: validate AV1 tile counts The stateless AV1 decoders use tile_info.tile_cols and tile_rows as loop bounds and as indices into the mi_*_starts[] and *_in_sbs_minus_1[] arrays, as the divisor for context_update_tile_id, and their product bounds the per-tile descriptor buffers, but std_validate_compound() does not bound these u8 fields. Reject a V4L2_CTRL_TYPE_AV1_FRAME whose tile_cols or tile_rows exceeds V4L2_AV1_MAX_TILE_COLS / _ROWS, or whose product exceeds V4L2_AV1_MAX_TILE_COUNT. A zero tile count is left to the consuming driver so the zero-initialised control that existing userspace submits is still accepted. | ||||
| CVE-2026-97596 | 1 Linux | 1 Linux Kernel | 2026-10-01 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: ipvs: reject invalid states in connection template sync records IPVS sync receivers validate protocol states before creating or updating a connection. For connection templates, however, they only log states outside the template state range and still store the value in the connection. A template can be returned by ordinary connection lookup. TCP and SCTP then use the invalid state as an index into their transition tables. Reject invalid template states in both sync protocol versions before looking up or modifying a connection. The version 1 path handles both IPv4 and IPv6 records. | ||||
| CVE-2026-97599 | 1 Linux | 1 Linux Kernel | 2026-10-01 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: ieee802154: hwsim: serialize pib updates to fix double-free hwsim_update_pib() does an unserialized read-swap-free of phy->pib: pib_old = rtnl_dereference(phy->pib); ... rcu_assign_pointer(phy->pib, pib); kfree_rcu(pib_old, rcu); It assumes the RTNL is held, but ->set_channel is not always called under it: the mac802154 scan worker changes channels via drv_set_channel() without the RTNL. Such an update can race an RTNL-held one on the same phy; both read the same pib_old and both kfree_rcu() it, double-freeing the object. With SLUB percpu sheaves batching kfree_rcu(), this surfaces as a KASAN invalid-free in rcu_free_sheaf(). struct hwsim_phy has no lock for pib. Add one and make the swap atomic with rcu_replace_pointer() under it, dropping the misleading rtnl_dereference(). | ||||
| CVE-2026-97600 | 1 Linux | 1 Linux Kernel | 2026-10-01 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: ieee802154: cc2520: fix FIFOP work use-after-free The FIFOP interrupt handler queues cc2520_fifop_irqwork. On removal, cc2520_remove() only flushes the work. The devm-managed FIFOP IRQ remains active until after ->remove() returns and can queue the work again after that flush, allowing it to run after the private data is released. Disable the work with disable_work_sync() instead of flushing it, so the handler can no longer queue it once removal begins. Destroy the buffer mutex last, since the worker and the stop callback invoked through ieee802154_unregister_hw() both take it. Found by an in-house static analysis tool. | ||||
| CVE-2026-97603 | 1 Linux | 1 Linux Kernel | 2026-10-01 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: idpf: disable DIM work before freeing q_vectors idpf never drains the Tx/Rx DIM works before freeing the memory they live in. tx_dim and rx_dim are embedded in struct idpf_q_vector, they are queued from the NAPI poll via net_dim(), and idpf_vport_intr_rel() ends with kfree(rsrc->q_vectors). Nothing in the driver cancels them. idpf_tx_dim_work() and idpf_rx_dim_work() then run on freed memory: idpf_vport_intr_write_itr() writes the ITR register through q_vector->intr_reg.tx_itr / rx_itr, void __iomem pointers loaded out of the freed q_vector. No configuration is needed to get there -- IDPF_ITR_IS_DYNAMIC() is defined as (itr_mode) and idpf_vport_alloc() initialises both modes to IDPF_ITR_DYNAMIC. Draining after idpf_vport_intr_napi_dis_all() is not enough on its own. idpf_net_dim() is called from inside the "if (napi_complete_done(napi, work_done))" branch of the poll, and napi_complete_done() has already cleared NAPIF_STATE_SCHED by then. napi_disable_locked() waits only while (val & (NAPIF_STATE_SCHED | NAPIF_STATE_NPSVC)), so napi_disable() can return while the poll tail is still queueing the work, and a plain cancel_work_sync() would be re-armed behind the drain. Use disable_work_sync(): schedule_work() on a work with a non-zero disable count is dropped by clear_pending_if_disabled() before __queue_work() is reached. Move idpf_init_dim() to idpf_vport_intr_alloc() so the works are initialised on every path that can reach the drain -- the three "goto intr_deinit" sites between idpf_vport_intr_init() and idpf_vport_intr_ena() get there without the enable side having run. Nothing re-enables them: rsrc->q_vectors is freed on every exit from idpf_vport_open() and on every idpf_vport_stop(), so the count dies with the object. It is a race, not a deterministic failure -- net_dim() only schedules once DIM_NEVENTS events have accumulated and the profile index changes. A KASAN ifup/ifdown loop under load is the way to see it. | ||||
| CVE-2026-97604 | 1 Linux | 1 Linux Kernel | 2026-10-01 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: fbdev: vfb: defer cleanup until the last reference FBIOGETCMAP takes a shallow snapshot of info->cmap and performs the usercopy after dropping info->lock. vfb_remove() frees the colormap immediately after unregistering the framebuffer, even when an open file still holds a reference to fb_info. A concurrent driver unbind can therefore free the colormap while the ioctl copies it to userspace. KASAN reports: BUG: KASAN: slab-use-after-free in _copy_to_user Read of size 512 by task poc/125 _copy_to_user (./include/linux/instrumented.h:129 ./include/linux/uaccess.h:201 lib/usercopy.c:24) fb_cmap_to_user (./include/linux/uaccess.h:230 drivers/video/fbdev/core/fbcmap.c:211) do_fb_ioctl (drivers/video/fbdev/core/fb_chrdev.c:114) Allocated by task 1: fb_alloc_cmap_gfp (./include/linux/slab.h:973 ./include/linux/slab.h:1290 drivers/video/fbdev/core/fbcmap.c:108) vfb_probe (drivers/video/fbdev/vfb.c:459) Freed by task 124: fb_dealloc_cmap (drivers/video/fbdev/core/fbcmap.c:151) vfb_remove (drivers/video/fbdev/vfb.c:489) unregister_framebuffer() drops the registration reference, and fbdev calls fb_destroy after the last put_fb_info(). Move the registered framebuffer's cleanup into an fb_destroy callback so its colormap and screen buffer stay alive until all file references have been released. | ||||
| CVE-2026-97607 | 1 Linux | 1 Linux Kernel | 2026-10-01 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: vdpa: ifcvf: Put device on unsupported feature error Route unsupported provisioned features through the common error path after vdpa_alloc_device() so the allocated device and adapter pointer are released consistently. | ||||