Total
331669 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2026-23850 | 1 B3log | 1 Siyuan | 2026-01-30 | N/A | 7.5 HIGH |
| SiYuan is a personal knowledge management system. In versions prior to 3.5.4, the markdown feature allows unrestricted server side html-rendering which allows arbitrary file read (LFD). Version 3.5.4 fixes the issue. | |||||
| CVE-2026-23851 | 1 B3log | 1 Siyuan | 2026-01-30 | N/A | 6.5 MEDIUM |
| SiYuan is a personal knowledge management system. Versions prior to 3.5.4 contain a logic vulnerability in the /api/file/globalCopyFiles endpoint. The function allows authenticated users to copy files from any location on the server's filesystem into the application's workspace without proper path validation. The vulnerability exists in the api/file.go source code. The function globalCopyFiles accepts a list of source paths (srcs) from the JSON request body. While the code checks if the source file exists using filelock.IsExist(src), it fails to validate whether the source path resides within the authorized workspace directory. Version 3.5.4 patches the issue. | |||||
| CVE-2026-23852 | 1 B3log | 1 Siyuan | 2026-01-30 | N/A | 9.6 CRITICAL |
| SiYuan is a personal knowledge management system. Versions prior to 3.5.4 have a stored Cross-Site Scripting (XSS) vulnerability that allows an attacker to inject arbitrary HTML attributes into the `icon` attribute of a block via the `/api/attr/setBlockAttrs` API. The payload is later rendered in the dynamic icon feature in an unsanitized context, leading to stored XSS and, in the desktop environment, potential remote code execution (RCE). This issue bypasses the previous fix for issue `#15970` (XSS → RCE via dynamic icons). Version 3.5.4 contains an updated fix. | |||||
| CVE-2022-50932 | 1 Kyocera | 1 Command Center Rx | 2026-01-30 | N/A | 7.5 HIGH |
| Kyocera Command Center RX ECOSYS M2035dn contains a directory traversal vulnerability that allows unauthenticated attackers to read sensitive system files by manipulating file paths under the /js/ path. Attackers can exploit the issue by sending requests like /js/../../../../.../etc/passwd%00.jpg (null-byte appended traversal) to access critical files such as /etc/passwd and /etc/shadow. | |||||
| CVE-2025-52981 | 1 Juniper | 13 Junos, Srx1600, Srx2300 and 10 more | 2026-01-30 | N/A | 7.5 HIGH |
| An Improper Check for Unusual or Exceptional Conditions vulnerability in the flow processing daemon (flowd) of Juniper Networks Junos OS on SRX1600, SRX2300, SRX 4000 Series, and SRX5000 Series with SPC3 allows an unauthenticated, network-based attacker to cause a Denial-of-Service (DoS). If a sequence of specific PIM packets is received, this will cause a flowd crash and restart. This issue affects Junos OS: * all versions before 21.2R3-S9, * 21.4 versions before 21.4R3-S11, * 22.2 versions before 22.2R3-S7, * 22.4 versions before 22.4R3-S6, * 23.2 versions before 23.2R2-S4, * 23.4 versions before 23.4R2-S4, * 24.2 versions before 24.2R2. This is a similar, but different vulnerability than the issue reported as CVE-2024-47503, published in JSA88133. | |||||
| CVE-2026-1144 | 1 Quickjs-ng | 1 Quickjs | 2026-01-30 | 7.5 HIGH | 6.3 MEDIUM |
| A vulnerability was detected in quickjs-ng quickjs up to 0.11.0. Affected is an unknown function of the file quickjs.c of the component Atomics Ops Handler. The manipulation results in use after free. The attack can be executed remotely. The exploit is now public and may be used. The patch is identified as ea3e9d77454e8fc9cb3ef3c504e9c16af5a80141. Applying a patch is advised to resolve this issue. | |||||
| CVE-2026-1145 | 1 Quickjs-ng | 1 Quickjs | 2026-01-30 | 7.5 HIGH | 6.3 MEDIUM |
| A flaw has been found in quickjs-ng quickjs up to 0.11.0. Affected by this vulnerability is the function js_typed_array_constructor_ta of the file quickjs.c. This manipulation causes heap-based buffer overflow. The attack is possible to be carried out remotely. The exploit has been published and may be used. Patch name: 53aebe66170d545bb6265906fe4324e4477de8b4. It is suggested to install a patch to address this issue. | |||||
| CVE-2026-22807 | 1 Vllm | 1 Vllm | 2026-01-30 | N/A | 8.8 HIGH |
| vLLM is an inference and serving engine for large language models (LLMs). Starting in version 0.10.1 and prior to version 0.14.0, vLLM loads Hugging Face `auto_map` dynamic modules during model resolution without gating on `trust_remote_code`, allowing attacker-controlled Python code in a model repo/path to execute at server startup. An attacker who can influence the model repo/path (local directory or remote Hugging Face repo) can achieve arbitrary code execution on the vLLM host during model load. This happens before any request handling and does not require API access. Version 0.14.0 fixes the issue. | |||||
| CVE-2026-24779 | 1 Vllm | 1 Vllm | 2026-01-30 | N/A | 7.1 HIGH |
| vLLM is an inference and serving engine for large language models (LLMs). Prior to version 0.14.1, a Server-Side Request Forgery (SSRF) vulnerability exists in the `MediaConnector` class within the vLLM project's multimodal feature set. The load_from_url and load_from_url_async methods obtain and process media from URLs provided by users, using different Python parsing libraries when restricting the target host. These two parsing libraries have different interpretations of backslashes, which allows the host name restriction to be bypassed. This allows an attacker to coerce the vLLM server into making arbitrary requests to internal network resources. This vulnerability is particularly critical in containerized environments like `llm-d`, where a compromised vLLM pod could be used to scan the internal network, interact with other pods, and potentially cause denial of service or access sensitive data. For example, an attacker could make the vLLM pod send malicious requests to an internal `llm-d` management endpoint, leading to system instability by falsely reporting metrics like the KV cache state. Version 0.14.1 contains a patch for the issue. | |||||
| CVE-2025-65098 | 1 Typebot | 1 Typebot | 2026-01-30 | N/A | 7.4 HIGH |
| Typebot is an open-source chatbot builder. In versions prior to 3.13.2, client-side script execution in Typebot allows stealing all stored credentials from any user. When a victim previews a malicious typebot by clicking "Run", JavaScript executes in their browser and exfiltrates their OpenAI keys, Google Sheets tokens, and SMTP passwords. The `/api/trpc/credentials.getCredentials` endpoint returns plaintext API keys without verifying credential ownership. Version 3.13.2 fixes the issue. | |||||
| CVE-2025-64709 | 1 Typebot | 1 Typebot | 2026-01-30 | N/A | 9.6 CRITICAL |
| Typebot is an open-source chatbot builder. In versions prior to 3.13.1, a Server-Side Request Forgery (SSRF) vulnerability in the Typebot webhook block (HTTP Request component) functionality allows authenticated users to make arbitrary HTTP requests from the server, including access to AWS Instance Metadata Service (IMDS). By bypassing IMDSv2 protection through custom header injection, attackers can extract temporary AWS IAM credentials for the EKS node role, leading to complete compromise of the Kubernetes cluster and associated AWS infrastructure. Version 3.13.1 fixes the issue. | |||||
| CVE-2025-64706 | 1 Typebot | 1 Typebot | 2026-01-30 | N/A | 5.0 MEDIUM |
| Typebot is an open-source chatbot builder. In version 3.9.0 up to but excluding version 3.13.0, an Insecure Direct Object Reference (IDOR) vulnerability exists in the API token management endpoint. An authenticated attacker can delete any user's API token and retrieve its value by simply knowing the target user's ID and token ID, without requiring authorization checks. Version 3.13.0 fixes the issue. | |||||
| CVE-2024-30264 | 1 Typebot | 1 Typebot | 2026-01-30 | N/A | 8.1 HIGH |
| Typebot is an open-source chatbot builder. A reflected cross-site scripting (XSS) in the sign-in page of typebot.io prior to version 2.24.0 may allow an attacker to hijack a user's account. The sign-in page takes the `redirectPath` parameter from the URL. If a user clicks on a link where the `redirectPath` parameter has a javascript scheme, the attacker that crafted the link may be able to execute arbitrary JavaScript with the privileges of the user. Version 2.24.0 contains a patch for this issue. | |||||
| CVE-2022-50925 | 1 Prowise | 1 Reflect | 2026-01-30 | N/A | 9.8 CRITICAL |
| Prowise Reflect version 1.0.9 contains a remote keystroke injection vulnerability that allows attackers to send keyboard events through an exposed WebSocket on port 8082. Attackers can craft malicious web pages to inject keystrokes, opening applications and typing arbitrary text by sending specific WebSocket messages. | |||||
| CVE-2025-13925 | 1 Ibm | 1 Aspera Console | 2026-01-30 | N/A | 4.9 MEDIUM |
| IBM Aspera Console 3.4.7 stores potentially sensitive information in log files that could be read by a local privileged user. | |||||
| CVE-2026-24061 | 2 Debian, Gnu | 2 Debian Linux, Inetutils | 2026-01-30 | N/A | 9.8 CRITICAL |
| telnetd in GNU Inetutils through 2.7 allows remote authentication bypass via a "-f root" value for the USER environment variable. | |||||
| CVE-2026-1281 | 1 Ivanti | 1 Endpoint Manager Mobile | 2026-01-30 | N/A | 9.8 CRITICAL |
| A code injection in Ivanti Endpoint Manager Mobile allowing attackers to achieve unauthenticated remote code execution. | |||||
| CVE-2025-68749 | 2026-01-30 | N/A | N/A | ||
| In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix race condition when unbinding BOs Fix 'Memory manager not clean during takedown' warning that occurs when ivpu_gem_bo_free() removes the BO from the BOs list before it gets unmapped. Then file_priv_unbind() triggers a warning in drm_mm_takedown() during context teardown. Protect the unmapping sequence with bo_list_lock to ensure the BO is always fully unmapped when removed from the list. This ensures the BO is either fully unmapped at context teardown time or present on the list and unmapped by file_priv_unbind(). | |||||
| CVE-2025-68358 | 2026-01-30 | N/A | N/A | ||
| 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-68351 | 2026-01-30 | N/A | N/A | ||
| In the Linux kernel, the following vulnerability has been resolved: exfat: fix refcount leak in exfat_find Fix refcount leaks in `exfat_find` related to `exfat_get_dentry_set`. Function `exfat_get_dentry_set` would increase the reference counter of `es->bh` on success. Therefore, `exfat_put_dentry_set` must be called after `exfat_get_dentry_set` to ensure refcount consistency. This patch relocate two checks to avoid possible leaks. | |||||