Total
35571 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2025-6199 | 2 Gnome, Redhat | 2 Gdkpixbuf, Enterprise Linux | 2026-06-17 | N/A | 3.3 LOW |
| A flaw was found in the GIF parser of GdkPixbuf’s LZW decoder. When an invalid symbol is encountered during decompression, the decoder sets the reported output size to the full buffer length rather than the actual number of written bytes. This logic error results in uninitialized sections of the buffer being included in the output, potentially leaking arbitrary memory contents in the processed image. | |||||
| CVE-2025-6083 | 1 Extremenetworks | 1 Extremecloud Universal Ztna | 2026-06-17 | N/A | 4.3 MEDIUM |
| In ExtremeCloud Universal ZTNA, a syntax error in the 'searchKeyword' condition caused queries to bypass the owner_id filter. This issue may allow users to search data across the entire table instead of being restricted to their specific owner_id. | |||||
| CVE-2025-69983 | 1 Frangoteam | 1 Fuxa | 2026-06-17 | N/A | 9.8 CRITICAL |
| FUXA v1.2.7 allows Remote Code Execution (RCE) via the project import functionality. The application does not properly sanitize or sandbox user-supplied scripts within imported project files. An attacker can upload a malicious project containing system commands, leading to full system compromise. | |||||
| CVE-2025-69651 | 1 Gnu | 1 Binutils | 2026-06-17 | N/A | 5.5 MEDIUM |
| GNU Binutils thru 2.46 readelf contains a vulnerability that leads to an invalid pointer free when processing a crafted ELF binary with malformed relocation or symbol data. If dump_relocations returns early due to parsing errors, the internal all_relocations array may remain partially uninitialized. Later, process_got_section_contents() may attempt to free an invalid r_symbol pointer, triggering memory corruption checks in glibc and causing the program to terminate with SIGABRT. No evidence of further memory corruption or code execution was observed; the impact is limited to denial of service. NOTE: this is disputed by third parties because the observed behavior occurred only in pre-release code and did not affect any tagged version. | |||||
| CVE-2025-69618 | 1 Coto.world | 1 Coto | 2026-06-17 | N/A | 6.5 MEDIUM |
| An arbitrary file overwrite vulnerability in the file import process of Tarot, Astro & Healing v11.4.0 allows attackers to overwrite critical internal files, potentially leading to arbitrary code execution or exposure of sensitive information. | |||||
| CVE-2025-69288 | 1 Kromit | 1 Titra | 2026-06-17 | N/A | 9.1 CRITICAL |
| Titra is open source project time tracking software. Prior to version 0.99.49, Titra allows any authenticated Admin user to modify the timeEntryRule in the database. The value is then passed to a NodeVM value to execute as code. Without sanitization, it leads to a Remote Code Execution. Version 0.99.49 fixes the issue. | |||||
| CVE-2025-69279 | 2 Google, Unisoc | 5 Android, T8100, T8200 and 2 more | 2026-06-17 | N/A | 7.5 HIGH |
| In nr modem, there is a possible system crash due to improper input validation. This could lead to remote denial of service with no additional execution privileges needed. | |||||
| CVE-2025-69278 | 2 Google, Unisoc | 6 Android, T7300, T8100 and 3 more | 2026-06-17 | N/A | 7.5 HIGH |
| In nr modem, there is a possible system crash due to improper input validation. This could lead to remote denial of service with no additional execution privileges needed. | |||||
| CVE-2025-68970 | 1 Huawei | 2 Emui, Harmonyos | 2026-06-17 | N/A | 6.1 MEDIUM |
| Permission verification bypass vulnerability in the media library module. Impact: Successful exploitation of this vulnerability may affect service confidentiality. | |||||
| CVE-2025-68967 | 1 Huawei | 1 Harmonyos | 2026-06-17 | N/A | 5.7 MEDIUM |
| Vulnerability of improper permission control in the print module. Impact: Successful exploitation of this vulnerability may affect service confidentiality. | |||||
| CVE-2025-68966 | 1 Huawei | 1 Harmonyos | 2026-06-17 | N/A | 5.1 MEDIUM |
| Permission control vulnerability in the Notepad module. Impact: Successful exploitation of this vulnerability may affect service confidentiality. | |||||
| CVE-2025-68965 | 1 Huawei | 1 Harmonyos | 2026-06-17 | N/A | 4.7 MEDIUM |
| Permission control vulnerability in the Notepad module. Impact: Successful exploitation of this vulnerability may affect service confidentiality. | |||||
| CVE-2025-68964 | 1 Huawei | 1 Harmonyos | 2026-06-17 | N/A | 6.2 MEDIUM |
| Data verification vulnerability in the HiView module. Impact: Successful exploitation of this vulnerability may affect availability. | |||||
| CVE-2025-68963 | 1 Huawei | 2 Emui, Harmonyos | 2026-06-17 | N/A | 5.7 MEDIUM |
| Man-in-the-middle attack vulnerability in the Clone module. Impact: Successful exploitation of this vulnerability may affect service confidentiality. | |||||
| CVE-2025-68959 | 1 Huawei | 2 Emui, Harmonyos | 2026-06-17 | N/A | 6.2 MEDIUM |
| Permission verification bypass vulnerability in the media library module. Impact: Successful exploitation of this vulnerability may affect service confidentiality. | |||||
| CVE-2025-68725 | 1 Linux | 1 Linux Kernel | 2026-06-17 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: bpf: Do not let BPF test infra emit invalid GSO types to stack Yinhao et al. reported that their fuzzer tool was able to trigger a skb_warn_bad_offload() from netif_skb_features() -> gso_features_check(). When a BPF program - triggered via BPF test infra - pushes the packet to the loopback device via bpf_clone_redirect() then mentioned offload warning can be seen. GSO-related features are then rightfully disabled. We get into this situation due to convert___skb_to_skb() setting gso_segs and gso_size but not gso_type. Technically, it makes sense that this warning triggers since the GSO properties are malformed due to the gso_type. Potentially, the gso_type could be marked non-trustworthy through setting it at least to SKB_GSO_DODGY without any other specific assumptions, but that also feels wrong given we should not go further into the GSO engine in the first place. The checks were added in 121d57af308d ("gso: validate gso_type in GSO handlers") because there were malicious (syzbot) senders that combine a protocol with a non-matching gso_type. If we would want to drop such packets, gso_features_check() currently only returns feature flags via netif_skb_features(), so one location for potentially dropping such skbs could be validate_xmit_unreadable_skb(), but then otoh it would be an additional check in the fast-path for a very corner case. Given bpf_clone_redirect() is the only place where BPF test infra could emit such packets, lets reject them right there. | |||||
| CVE-2025-68697 | 1 N8n | 1 N8n | 2026-06-17 | N/A | 7.1 HIGH |
| n8n is an open source workflow automation platform. Prior to version 2.0.0, in self-hosted n8n instances where the Code node runs in legacy (non-task-runner) JavaScript execution mode, authenticated users with workflow editing access can invoke internal helper functions from within the Code node. This allows a workflow editor to perform actions on the n8n host with the same privileges as the n8n process, including: reading files from the host filesystem (subject to any file-access restrictions configured on the instance and OS/container permissions), and writing files to the host filesystem (subject to the same restrictions). This issue has been patched in version 2.0.0. Workarounds for this issue involve limiting file operations by setting N8N_RESTRICT_FILE_ACCESS_TO to a dedicated directory (e.g., ~/.n8n-files) and ensure it contains no sensitive data, keeping N8N_BLOCK_FILE_ACCESS_TO_N8N_FILES=true (default) to block access to .n8n and user-defined config files, and disabling high-risk nodes (including the Code node) using NODES_EXCLUDE if workflow editors are not fully trusted. | |||||
| CVE-2025-68398 | 1 Weblate | 1 Weblate | 2026-06-17 | N/A | 9.1 CRITICAL |
| Weblate is a web based localization tool. In versions prior to 5.15.1, it was possible to overwrite Git configuration remotely and override some of its behavior. Version 5.15.1 fixes the issue. | |||||
| CVE-2025-68358 | 1 Linux | 1 Linux Kernel | 2026-06-17 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: btrfs: fix racy bitfield write in btrfs_clear_space_info_full() From the memory-barriers.txt document regarding memory barrier ordering guarantees: (*) These guarantees do not apply to bitfields, because compilers often generate code to modify these using non-atomic read-modify-write sequences. Do not attempt to use bitfields to synchronize parallel algorithms. (*) Even in cases where bitfields are protected by locks, all fields in a given bitfield must be protected by one lock. If two fields in a given bitfield are protected by different locks, the compiler's non-atomic read-modify-write sequences can cause an update to one field to corrupt the value of an adjacent field. btrfs_space_info has a bitfield sharing an underlying word consisting of the fields full, chunk_alloc, and flush: struct btrfs_space_info { struct btrfs_fs_info * fs_info; /* 0 8 */ struct btrfs_space_info * parent; /* 8 8 */ ... int clamp; /* 172 4 */ unsigned int full:1; /* 176: 0 4 */ unsigned int chunk_alloc:1; /* 176: 1 4 */ unsigned int flush:1; /* 176: 2 4 */ ... Therefore, to be safe from parallel read-modify-writes losing a write to one of the bitfield members protected by a lock, all writes to all the bitfields must use the lock. They almost universally do, except for btrfs_clear_space_info_full() which iterates over the space_infos and writes out found->full = 0 without a lock. Imagine that we have one thread completing a transaction in which we finished deleting a block_group and are thus calling btrfs_clear_space_info_full() while simultaneously the data reclaim ticket infrastructure is running do_async_reclaim_data_space(): T1 T2 btrfs_commit_transaction btrfs_clear_space_info_full data_sinfo->full = 0 READ: full:0, chunk_alloc:0, flush:1 do_async_reclaim_data_space(data_sinfo) spin_lock(&space_info->lock); if(list_empty(tickets)) space_info->flush = 0; READ: full: 0, chunk_alloc:0, flush:1 MOD/WRITE: full: 0, chunk_alloc:0, flush:0 spin_unlock(&space_info->lock); return; MOD/WRITE: full:0, chunk_alloc:0, flush:1 and now data_sinfo->flush is 1 but the reclaim worker has exited. This breaks the invariant that flush is 0 iff there is no work queued or running. Once this invariant is violated, future allocations that go into __reserve_bytes() will add tickets to space_info->tickets but will see space_info->flush is set to 1 and not queue the work. After this, they will block forever on the resulting ticket, as it is now impossible to kick the worker again. I also confirmed by looking at the assembly of the affected kernel that it is doing RMW operations. For example, to set the flush (3rd) bit to 0, the assembly is: andb $0xfb,0x60(%rbx) and similarly for setting the full (1st) bit to 0: andb $0xfe,-0x20(%rax) So I think this is really a bug on practical systems. I have observed a number of systems in this exact state, but am currently unable to reproduce it. Rather than leaving this footgun lying around for the future, take advantage of the fact that there is room in the struct anyway, and that it is already quite large and simply change the three bitfield members to bools. This avoids writes to space_info->full having any effect on ---truncated--- | |||||
| CVE-2025-68340 | 1 Linux | 1 Linux Kernel | 2026-06-17 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: team: Move team device type change at the end of team_port_add Attempting to add a port device that is already up will expectedly fail, but not before modifying the team device header_ops. In the case of the syzbot reproducer the gre0 device is already in state UP when it attempts to add it as a port device of team0, this fails but before that header_ops->create of team0 is changed from eth_header to ipgre_header in the call to team_dev_type_check_change. Later when we end up in ipgre_header() struct ip_tunnel* points to nonsense as the private data of the device still holds a struct team. Example sequence of iproute2 commands to reproduce the hang/BUG(): ip link add dev team0 type team ip link add dev gre0 type gre ip link set dev gre0 up ip link set dev gre0 master team0 ip link set dev team0 up ping -I team0 1.1.1.1 Move team_dev_type_check_change down where all other checks have passed as it changes the dev type with no way to restore it in case one of the checks that follow it fail. Also make sure to preserve the origial mtu assignment: - If port_dev is not the same type as dev, dev takes mtu from port_dev - If port_dev is the same type as dev, port_dev takes mtu from dev This is done by adding a conditional before the call to dev_set_mtu to prevent it from assigning port_dev->mtu = dev->mtu and instead letting team_dev_type_check_change assign dev->mtu = port_dev->mtu. The conditional is needed because the patch moves the call to team_dev_type_check_change past dev_set_mtu. Testing: - team device driver in-tree selftests - Add/remove various devices as slaves of team device - syzbot | |||||