News & Sicurezza
Aggiornamenti da ENISA, NVD e le principali fonti di cybersecurity europee. Tutto quello che un Responsabile Tecnico deve sapere.
23880 risultati
CVE ID :CVE-2026-53943 Published : June 24, 2026, 6:13 p.m. | 1 hour, 31 minutes ago Description :Ghost is a Node.js content management system. From until 6.37.0, when Ghost is behind a shared caching layer that results in cached content being shared between different visitors, an unauthenticated user could send an x-ghost-preview header that altered the rendered frontend response. In affected cache configurations, that response could be stored and served to subsequent visitors requesting the same page, allowing cache poisoning of request-specific preview output. When running Ghost's frontend and admin panel on the same domain this could be used to take over staff user accounts. When running these on different domains staff accounts have no exposure. This vulnerability is fixed in 6.37.0. Severity: 0.0 | NA Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID :CVE-2026-12760 Published : June 24, 2026, 6:10 p.m. | 1 hour, 33 minutes ago Description :A denial-of-service (DoS) vulnerability has been identified in Tapo C200 v3 in the network packet handling logic due to improper handling of IPv4 fragmented packets. An unauthenticated adjacent attacker can send crafted packets to cause excessive resource consumption, leading to instability of the device.Successful exploitation can remotely trigger a temporary denial-of-service condition, causing the camera to become unresponsive and resulting in intermittent loss of video monitoring and recording. Severity: 7.1 | HIGH Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID :CVE-2026-53944 Published : June 24, 2026, 6:10 p.m. | 1 hour, 34 minutes ago Description :Ghost is a Node.js content management system. From 6.0.9 until 6.21.1, when making an external request, it is possible to bypass the IP filter that ensures the request isn't going to an internal service using an IPv6 literal which maps to a private IPv4 address. This vulnerability is fixed in 6.21.1. Severity: 0.0 | NA Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CISA Warns Critical Lantronix EDS5000 Flaw Is Being Actively Exploited The U.S. Cybersecurity and Infrastructure Security Agency (CISA) on Tuesday warned of active exploitation of a critical security flaw impacting Lantronix EDS5000 Series devices, urging Federal Civilia ... Read more Published Date: Jun 24, 2026 (4 days, 8 hours ago) Vulnerabilities has been mentioned in this article. CVE-2026-11645 CVE-2026-34910 CVE-2026-34909 CVE-2026-34908 CVE-2025-67038
CVE ID :CVE-2026-53130 Published : June 24, 2026, 4:30 p.m. | 1 hour, 13 minutes ago Description :In the Linux kernel, the following vulnerability has been resolved: fs/omfs: reject s_sys_blocksize smaller than OMFS_DIR_START omfs_fill_super() rejects oversized s_sys_blocksize values (> PAGE_SIZE), but it does not reject values smaller than OMFS_DIR_START (0x1b8 = 440). Later, omfs_make_empty() uses sbi->s_sys_blocksize - OMFS_DIR_START as the length argument to memset(). Since s_sys_blocksize is u32, a crafted filesystem image with s_sys_blocksize b_data + OMFS_DIR_START and overwrites kernel memory far beyond the backing block buffer. Add the corresponding lower-bound check alongside the existing upper-bound check in omfs_fill_super(), so that malformed images are rejected during superblock validation before any filesystem data is processed. Severity: 0.0 | NA Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID :CVE-2026-53129 Published : June 24, 2026, 4:30 p.m. | 1 hour, 13 minutes ago Description :In the Linux kernel, the following vulnerability has been resolved: fs/mbcache: cancel shrink work before destroying the cache mb_cache_destroy() calls shrinker_free() and then frees all cache entries and the cache itself, but it does not cancel the pending c_shrink_work work item first. If mb_cache_entry_create() schedules c_shrink_work via schedule_work() and the work item is still pending or running when mb_cache_destroy() runs, mb_cache_shrink_worker() will access the cache after its memory has been freed, causing a use-after-free. This is only reachable by a privileged user (root or CAP_SYS_ADMIN) who can trigger the last put of a mounted ext2/ext4/ocfs2 filesystem. Cancel the work item with cancel_work_sync() before calling shrinker_free(), ensuring the worker has finished and will not be rescheduled before the cache is torn down. Severity: 0.0 | NA Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID :CVE-2026-53128 Published : June 24, 2026, 4:30 p.m. | 1 hour, 13 minutes ago Description :In the Linux kernel, the following vulnerability has been resolved: drbd: Balance RCU calls in drbd_adm_dump_devices() Make drbd_adm_dump_devices() call rcu_read_lock() before rcu_read_unlock() is called. This has been detected by the Clang thread-safety analyzer. Severity: 0.0 | NA Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID :CVE-2026-53127 Published : June 24, 2026, 4:30 p.m. | 1 hour, 13 minutes ago Description :In the Linux kernel, the following vulnerability has been resolved: block: fix zones_cond memory leak on zone revalidation error paths When blk_revalidate_disk_zones() fails after disk_revalidate_zone_resources() has allocated args.zones_cond, the memory is leaked because no error path frees it. Severity: 0.0 | NA Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID :CVE-2026-53126 Published : June 24, 2026, 4:30 p.m. | 1 hour, 13 minutes ago Description :In the Linux kernel, the following vulnerability has been resolved: blk-cgroup: fix disk reference leak in blkcg_maybe_throttle_current() Add the missing put_disk() on the error path in blkcg_maybe_throttle_current(). When blkcg lookup, blkg lookup, or blkg_tryget() fails, the function jumps to the out label which only calls rcu_read_unlock() but does not release the disk reference acquired by blkcg_schedule_throttle() via get_device(). Since current->throttle_disk is already set to NULL before the lookup, blkcg_exit() cannot release this reference either, causing the disk to never be freed. Restore the reference release that was present as blk_put_queue() in the original code but was inadvertently dropped during the conversion from request_queue to gendisk. Severity: 0.0 | NA Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID :CVE-2026-53124 Published : June 24, 2026, 4:30 p.m. | 1 hour, 13 minutes ago Description :In the Linux kernel, the following vulnerability has been resolved: ublk: reset per-IO canceled flag on each fetch If a ublk server starts recovering devices but dies before issuing fetch commands for all IOs, cancellation of the fetch commands that were successfully issued may never complete. This is because the per-IO canceled flag can remain set even after the fetch for that IO has been submitted - the per-IO canceled flags for all IOs in a queue are reset together only once all IOs for that queue have been fetched. So if a nonempty proper subset of the IOs for a queue are fetched when the ublk server dies, the IOs in that subset will never successfully be canceled, as their canceled flags remain set, and this prevents ublk_cancel_cmd from actually calling io_uring_cmd_done on the commands, despite the fact that they are outstanding. Fix this by resetting the per-IO cancel flags immediately when each IO is fetched instead of waiting for all IOs for the queue (which may never happen). Severity: 0.0 | NA Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID :CVE-2026-53125 Published : June 24, 2026, 4:30 p.m. | 1 hour, 13 minutes ago Description :In the Linux kernel, the following vulnerability has been resolved: md: fix array_state=clear sysfs deadlock When "clear" is written to array_state, md_attr_store() breaks sysfs active protection so the array can delete itself from its own sysfs store method. However, md_attr_store() currently drops the mddev reference before calling sysfs_unbreak_active_protection(). Once do_md_stop(..., 0) has made the mddev eligible for delayed deletion, the temporary kobject reference taken by sysfs_break_active_protection() can become the last kobject reference protecting the md kobject. That allows sysfs_unbreak_active_protection() to drop the last kobject reference from the current sysfs writer context. kobject teardown then recurses into kernfs removal while the current sysfs node is still being unwound, and lockdep reports recursive locking on kn->active with kernfs_drain() in the call chain. Reproducer on an existing level: 1. Create an md0 linear array and activate it: mknod /dev/md0 b 9 0 echo none > /sys/block/md0/md/metadata_version echo linear > /sys/block/md0/md/level echo 1 > /sys/block/md0/md/raid_disks echo "$(cat /sys/class/block/sdb/dev)" > /sys/block/md0/md/new_dev echo "$(($(cat /sys/class/block/sdb/size) / 2))" > \ /sys/block/md0/md/dev-sdb/size echo 0 > /sys/block/md0/md/dev-sdb/slot echo active > /sys/block/md0/md/array_state 2. Wait briefly for the array to settle, then clear it: sleep 2 echo clear > /sys/block/md0/md/array_state The warning looks like: WARNING: possible recursive locking detected bash/588 is trying to acquire lock: (kn->active#65) at __kernfs_remove+0x157/0x1d0 but task is already holding lock: (kn->active#65) at sysfs_unbreak_active_protection+0x1f/0x40 ... Call Trace: kernfs_drain __kernfs_remove kernfs_remove_by_name_ns sysfs_remove_group sysfs_remove_groups __kobject_del kobject_put md_attr_store kernfs_fop_write_iter vfs_write ksys_wr...
CVE ID :CVE-2026-53123 Published : June 24, 2026, 4:30 p.m. | 1 hour, 13 minutes ago Description :In the Linux kernel, the following vulnerability has been resolved: md: wake raid456 reshape waiters before suspend During raid456 reshape, direct IO across the reshape position can sleep in raid5_make_request() waiting for reshape progress while still holding an active_io reference. If userspace then freezes reshape and writes md/suspend_lo or md/suspend_hi, mddev_suspend() kills active_io and waits for all in-flight IO to drain. This can deadlock: the IO needs reshape progress to continue, but the reshape thread is already frozen, so the active_io reference is never dropped and suspend never completes. raid5_prepare_suspend() already wakes wait_for_reshape for dm-raid. Do the same for normal md suspend when reshape is already interrupted, so waiting raid456 IO can abort, drop its reference, and let suspend finish. The mdadm test tests/25raid456-reshape-deadlock reproduces the hang. Severity: 0.0 | NA Visit the link for more details, such as CVSS details, affected products, timeline, and more...
Pagina 49 di 1990