🚨 CVE-2026-62241
clawvet self-hosted API server (apps/api) before 0.7.5 hard-codes a fallback JWT secret ('clawvet-dev-secret-change-me') in auth.ts and ships it as the default in .env.example. Because GET /api/v1/scans returns scan records containing userId values without authentication, a remote unauthenticated attacker can harvest a victim's userId, forge a valid HS256 cg_session cookie offline using the known secret, and call GET /api/v1/auth/me to obtain the victim's email address, subscription plan, and secret apiKey. The published clawvet npm package (CLI only) is not affected.
🎖@cveNotify
clawvet self-hosted API server (apps/api) before 0.7.5 hard-codes a fallback JWT secret ('clawvet-dev-secret-change-me') in auth.ts and ships it as the default in .env.example. Because GET /api/v1/scans returns scan records containing userId values without authentication, a remote unauthenticated attacker can harvest a victim's userId, forge a valid HS256 cg_session cookie offline using the known secret, and call GET /api/v1/auth/me to obtain the victim's email address, subscription plan, and secret apiKey. The published clawvet npm package (CLI only) is not affected.
🎖@cveNotify
GitHub
Hard-coded JWT Secret Allows Session Forgery and API Key Disclosure
## Hard-coded JWT Secret Allows Session Forgery and API Key Disclosure
### Summary
The clawvet API hard-codes a fallback JWT secret (`clawvet-dev-secret-change-me`) directly in source and shi...
### Summary
The clawvet API hard-codes a fallback JWT secret (`clawvet-dev-secret-change-me`) directly in source and shi...
🚨 CVE-2026-14932
In Progress® Telerik® UI for AJAX prior to v2026.2.708, the obsolete RadChart component's ChartImage.axd handler is vulnerable to unauthenticated file read and deletion of image-extension files within the application directory.
🎖@cveNotify
In Progress® Telerik® UI for AJAX prior to v2026.2.708, the obsolete RadChart component's ChartImage.axd handler is vulnerable to unauthenticated file read and deletion of image-extension files within the application directory.
🎖@cveNotify
Telerik
Telerik Web Forms Unauthenticated File Read and Deletion via Hardcoded Encryption Key in RadChart (CVE-2026-14932) - Telerik UI…
Security notification CVE-2026-14932, unauthenticated file read and deletion via hardcoded encryption key in the obsolete RadChart component.
🚨 CVE-2026-12482
A vulnerability in keras-team/keras version 3.12.0 allows an attacker to craft a malicious tar archive that bypasses the `filter_safe_tarinfos` validation in `keras/src/utils/file_utils.py`. Specifically, symlink entries are not subjected to the same `is_path_in_dir` validation as regular file entries, allowing symlinks to be created outside the intended extraction directory. This can lead to symlink-based file read, file overwrite, or directory escape attacks. The issue is particularly impactful on Python 3.10 and 3.11, where `filter_safe_tarinfos` is the sole defense against tar path traversal. This vulnerability is distinct from CVE-2025-12060 and other previously reported issues.
🎖@cveNotify
A vulnerability in keras-team/keras version 3.12.0 allows an attacker to craft a malicious tar archive that bypasses the `filter_safe_tarinfos` validation in `keras/src/utils/file_utils.py`. Specifically, symlink entries are not subjected to the same `is_path_in_dir` validation as regular file entries, allowing symlinks to be created outside the intended extraction directory. This can lead to symlink-based file read, file overwrite, or directory escape attacks. The issue is particularly impactful on Python 3.10 and 3.11, where `filter_safe_tarinfos` is the sole defense against tar path traversal. This vulnerability is distinct from CVE-2025-12060 and other previously reported issues.
🎖@cveNotify
🚨 CVE-2026-10669
On Xtensa SoCs built with CONFIG_XTENSA_MPU and CONFIG_USERSPACE, arch_buffer_validate() in arch/xtensa/core/mpu.c — the architecture hook that verifies a user-mode-supplied buffer is accessible to the calling user thread with the requested permission — defaulted its return value to 0 (access permitted) and only set a denial result inside its per-MPU-region probe loop. When the rounded extent of the buffer wraps the 32-bit address space (size + alignment offset near SIZE_MAX, or ROUND_UP(size + offset) overflowing to 0), the loop executes zero iterations and the function returns 0 = permitted without probing any MPU region.
The syscall-layer pre-checks (K_SYSCALL_MEMORY_SIZE_CHECK / Z_DETECT_POINTER_OVERFLOW) only catch a raw addr+size wrap and do not cover the ROUND_UP-induced wrap, and the string path (arch_user_string_nlen -> arch_buffer_validate) has no syscall-layer guard at all.
An unprivileged user-mode thread can therefore pass a crafted (addr, size) to any syscall that validates user buffers via k_usermode_from_copy/to_copy or k_usermode_string_copy and have validation succeed for memory it must not access; the kernel then reads from (disclosure) or, with write=1, writes to (corruption) attacker-chosen kernel or other-partition memory on the thread's behalf, enabling information disclosure, memory corruption, privilege escalation, and denial of service.
Affected from v3.7.0 (when Xtensa MPU userspace support was added) through v4.4.0. The fix changes the default to -EINVAL (deny by default), adds an explicit size_add_overflow check, and sets the success value only after the full range has been validated.
🎖@cveNotify
On Xtensa SoCs built with CONFIG_XTENSA_MPU and CONFIG_USERSPACE, arch_buffer_validate() in arch/xtensa/core/mpu.c — the architecture hook that verifies a user-mode-supplied buffer is accessible to the calling user thread with the requested permission — defaulted its return value to 0 (access permitted) and only set a denial result inside its per-MPU-region probe loop. When the rounded extent of the buffer wraps the 32-bit address space (size + alignment offset near SIZE_MAX, or ROUND_UP(size + offset) overflowing to 0), the loop executes zero iterations and the function returns 0 = permitted without probing any MPU region.
The syscall-layer pre-checks (K_SYSCALL_MEMORY_SIZE_CHECK / Z_DETECT_POINTER_OVERFLOW) only catch a raw addr+size wrap and do not cover the ROUND_UP-induced wrap, and the string path (arch_user_string_nlen -> arch_buffer_validate) has no syscall-layer guard at all.
An unprivileged user-mode thread can therefore pass a crafted (addr, size) to any syscall that validates user buffers via k_usermode_from_copy/to_copy or k_usermode_string_copy and have validation succeed for memory it must not access; the kernel then reads from (disclosure) or, with write=1, writes to (corruption) attacker-chosen kernel or other-partition memory on the thread's behalf, enabling information disclosure, memory corruption, privilege escalation, and denial of service.
Affected from v3.7.0 (when Xtensa MPU userspace support was added) through v4.4.0. The fix changes the default to -EINVAL (deny by default), adds an explicit size_add_overflow check, and sets the success value only after the full range has been validated.
🎖@cveNotify
GitHub
xtensa: mpu: fix arch_buffer_validate() if overflow · zephyrproject-rtos/zephyr@3b1bdaf
If the (addr + size) overflows the memory address space,
the inner loop may not run to check for permission. Since
the default return value was 0 (meaning permitted), it
would incorrectly say memor...
the inner loop may not run to check for permission. Since
the default return value was 0 (meaning permitted), it
would incorrectly say memor...
🚨 CVE-2026-10670
The CONFIG_USERSPACE verification handler for the k_thread_name_copy() system call (z_vrfy_k_thread_name_copy() in kernel/thread.c) calls k_object_find() on the caller-supplied thread pointer and then dereferences the returned struct k_object without checking it for NULL. k_object_find() returns NULL whenever the supplied pointer is not a registered (static or dynamic) kernel object.
The pre-fix guard tested thread == NULL instead of ko == NULL, so an unprivileged user-mode thread that invokes k_thread_name_copy() with any non-NULL but unregistered pointer (e.g. an arbitrary address) passes the NULL test, after which the verifier reads ko->type through a NULL pointer.
Because the syscall verifier runs in supervisor mode, this NULL dereference is a kernel-mode fault that halts or reboots the system, allowing untrusted user code to crash the kernel across the userspace security boundary (denial of service). The marshaller passes the thread argument to the verifier without any prior K_SYSCALL_OBJ validation, so the bad pointer reaches the defect directly.
The flaw affects builds with CONFIG_USERSPACE and CONFIG_THREAD_NAME enabled and has been present since the special-case lookup was introduced around v2.0.0; it is present in v4.4.0 and earlier. The fix changes the guard to check the k_object_find() return value (ko == NULL) before dereferencing it.
🎖@cveNotify
The CONFIG_USERSPACE verification handler for the k_thread_name_copy() system call (z_vrfy_k_thread_name_copy() in kernel/thread.c) calls k_object_find() on the caller-supplied thread pointer and then dereferences the returned struct k_object without checking it for NULL. k_object_find() returns NULL whenever the supplied pointer is not a registered (static or dynamic) kernel object.
The pre-fix guard tested thread == NULL instead of ko == NULL, so an unprivileged user-mode thread that invokes k_thread_name_copy() with any non-NULL but unregistered pointer (e.g. an arbitrary address) passes the NULL test, after which the verifier reads ko->type through a NULL pointer.
Because the syscall verifier runs in supervisor mode, this NULL dereference is a kernel-mode fault that halts or reboots the system, allowing untrusted user code to crash the kernel across the userspace security boundary (denial of service). The marshaller passes the thread argument to the verifier without any prior K_SYSCALL_OBJ validation, so the bad pointer reaches the defect directly.
The flaw affects builds with CONFIG_USERSPACE and CONFIG_THREAD_NAME enabled and has been present since the special-case lookup was introduced around v2.0.0; it is present in v4.4.0 and earlier. The fix changes the guard to check the k_object_find() return value (ko == NULL) before dereferencing it.
🎖@cveNotify
GitHub
kernel: add kobj NULL check in k_thread_name_copy() · zephyrproject-rtos/zephyr@4915839
Inside k_thread_name_copy(), we call k_object_find() to find
the associated thread object of the incoming thread. However,
the finder can return NULL if incoming pointer address has
no kobj associa...
the associated thread object of the incoming thread. However,
the finder can return NULL if incoming pointer address has
no kobj associa...
🚨 CVE-2026-10671
In Zephyr's kernel pipe implementation, the userspace syscall verifier z_vrfy_k_pipe_init() in kernel/pipe.c used K_SYSCALL_OBJ() (which requires the kernel object to already be initialized) instead of K_SYSCALL_OBJ_NEVER_INIT() (which rejects an already-initialized object). As a result, on CONFIG_USERSPACE builds an unprivileged user thread that has been granted access to a k_pipe object can invoke the k_pipe_init syscall to re-initialize a pipe that is already in use.
z_impl_k_pipe_init() unconditionally resets the ring buffer, sets pipe->waiting to 0, and re-initializes both wait queues (z_waitq_init on pipe->data and pipe->space) without waking or accounting for threads currently blocked on the pipe. Any thread already pended in k_pipe_read()/k_pipe_write() is left orphaned: still marked pending with pended_on pointing at the cleared wait queue and with stale qnode_dlist links into the (now re-initialized) embedded list head.
When such an orphaned waiter is later timed out or woken, the scheduler calls sys_dlist_remove() on its stale node, writing through dangling prev/next pointers into kernel wait-queue/scheduler structures, causing list corruption (an attacker-driven invalid kernel write), lost wakeups, indefinitely blocked threads, and silent data loss. The flaw lets a deprivileged user thread corrupt the state of a kernel object shared with other threads/partitions.
The fix switches the verifier to K_SYSCALL_OBJ_NEVER_INIT(), matching the existing k_msgq_init verifier, so a user thread can no longer re-initialize a live pipe. The vulnerable code shipped in v4.1.0 and remained through v4.4.0.
🎖@cveNotify
In Zephyr's kernel pipe implementation, the userspace syscall verifier z_vrfy_k_pipe_init() in kernel/pipe.c used K_SYSCALL_OBJ() (which requires the kernel object to already be initialized) instead of K_SYSCALL_OBJ_NEVER_INIT() (which rejects an already-initialized object). As a result, on CONFIG_USERSPACE builds an unprivileged user thread that has been granted access to a k_pipe object can invoke the k_pipe_init syscall to re-initialize a pipe that is already in use.
z_impl_k_pipe_init() unconditionally resets the ring buffer, sets pipe->waiting to 0, and re-initializes both wait queues (z_waitq_init on pipe->data and pipe->space) without waking or accounting for threads currently blocked on the pipe. Any thread already pended in k_pipe_read()/k_pipe_write() is left orphaned: still marked pending with pended_on pointing at the cleared wait queue and with stale qnode_dlist links into the (now re-initialized) embedded list head.
When such an orphaned waiter is later timed out or woken, the scheduler calls sys_dlist_remove() on its stale node, writing through dangling prev/next pointers into kernel wait-queue/scheduler structures, causing list corruption (an attacker-driven invalid kernel write), lost wakeups, indefinitely blocked threads, and silent data loss. The flaw lets a deprivileged user thread corrupt the state of a kernel object shared with other threads/partitions.
The fix switches the verifier to K_SYSCALL_OBJ_NEVER_INIT(), matching the existing k_msgq_init verifier, so a user thread can no longer re-initialize a live pipe. The vulnerable code shipped in v4.1.0 and remained through v4.4.0.
🎖@cveNotify
GitHub
kernel: pipe: user threads may not re-init pipe · zephyrproject-rtos/zephyr@4424aa6
Updates z_vrfy_k_pipe_init() to use K_SYSCALL_OBJ_NEVER_INIT()
instead of K_SYSCALL_OBJ() to prevent a user thread from
re-initializing a pipe. This aligns the pipe initialization
behavior to that ...
instead of K_SYSCALL_OBJ() to prevent a user thread from
re-initializing a pipe. This aligns the pipe initialization
behavior to that ...
🚨 CVE-2026-10672
subsys/net/lib/lwm2m/lwm2m_pull_context.c copied the firmware-update Package URI into a fixed static buffer (context.uri, size CONFIG_LWM2M_SWMGMT_PACKAGE_URI_LEN, default 128) with memcpy(context.uri, uri, LWM2M_PACKAGE_URI_LEN), copying exactly the destination size with no length validation. The Firmware-Update object stores the server-supplied Package URI (/5/0/1) in a 255-byte buffer, so a LwM2M management server (or an on-path attacker on a session lacking strong DTLS) can WRITE a URI of 128-254 characters; only the first 128 bytes are then copied into context.uri with no NUL terminator. That buffer is subsequently consumed as a C string by http_parser_parse_url(context.uri, strlen(context.uri), ...), strlen-based CoAP URI-path/PROXY-URI option appends, and lwm2m_parse_peerinfo(), causing an out-of-bounds read of adjacent static memory. The over-read bytes are appended to outbound CoAP requests (information disclosure of adjacent device memory to the server/proxy) and can crash the device (denial of service). The vulnerable copy was introduced by the pull-context refactor (first released in v3.0.0) and is present through v4.4.0; the default-on CONFIG_LWM2M_FIRMWARE_UPDATE_PULL_SUPPORT path is affected. The fix adds a strlen(uri) >= sizeof(context.uri) check returning -ENOMEM and switches to strcpy(), guaranteeing a bounded, NUL-terminated buffer.
🎖@cveNotify
subsys/net/lib/lwm2m/lwm2m_pull_context.c copied the firmware-update Package URI into a fixed static buffer (context.uri, size CONFIG_LWM2M_SWMGMT_PACKAGE_URI_LEN, default 128) with memcpy(context.uri, uri, LWM2M_PACKAGE_URI_LEN), copying exactly the destination size with no length validation. The Firmware-Update object stores the server-supplied Package URI (/5/0/1) in a 255-byte buffer, so a LwM2M management server (or an on-path attacker on a session lacking strong DTLS) can WRITE a URI of 128-254 characters; only the first 128 bytes are then copied into context.uri with no NUL terminator. That buffer is subsequently consumed as a C string by http_parser_parse_url(context.uri, strlen(context.uri), ...), strlen-based CoAP URI-path/PROXY-URI option appends, and lwm2m_parse_peerinfo(), causing an out-of-bounds read of adjacent static memory. The over-read bytes are appended to outbound CoAP requests (information disclosure of adjacent device memory to the server/proxy) and can crash the device (denial of service). The vulnerable copy was introduced by the pull-context refactor (first released in v3.0.0) and is present through v4.4.0; the default-on CONFIG_LWM2M_FIRMWARE_UPDATE_PULL_SUPPORT path is affected. The fix adds a strlen(uri) >= sizeof(context.uri) check returning -ENOMEM and switches to strcpy(), guaranteeing a bounded, NUL-terminated buffer.
🎖@cveNotify
GitHub
net: lwm2m: Verify URI string length before use in FW pull mode · zephyrproject-rtos/zephyr@99a164d
Verify the URI length provided to lwm2m_pull_context_start_transfer()
before use, otherwise in case the URI string is longer than the buffer,
only part of it was copied w/o NULL terminator, which c...
before use, otherwise in case the URI string is longer than the buffer,
only part of it was copied w/o NULL terminator, which c...
🚨 CVE-2026-13181
In Progress® Telerik® UI for AJAX prior to v2026.2.708, forged upload metadata can influence AsyncUploadTypeName processing and trigger unsafe attacker-controlled type resolution, enabling remote code execution in affected deployments.
🎖@cveNotify
In Progress® Telerik® UI for AJAX prior to v2026.2.708, forged upload metadata can influence AsyncUploadTypeName processing and trigger unsafe attacker-controlled type resolution, enabling remote code execution in affected deployments.
🎖@cveNotify
Telerik
Telerik Web Forms RadAsyncUpload AsyncUploadTypeName Type Resolution Vulnerability (CVE-2026-13181) - Telerik UI for ASP.NET AJAX
Security notification CVE-2026-13181, RadAsyncUpload AsyncUploadTypeName type resolution vulnerability.
🚨 CVE-2026-13182
In Progress® Telerik® UI for AJAX prior to v2026.2.708, RadAsyncUpload client-state processing can distinguish decrypt failures from invalid-JSON parse failures, creating an oracle that reveals protected metadata values to remote attackers.
🎖@cveNotify
In Progress® Telerik® UI for AJAX prior to v2026.2.708, RadAsyncUpload client-state processing can distinguish decrypt failures from invalid-JSON parse failures, creating an oracle that reveals protected metadata values to remote attackers.
🎖@cveNotify
Telerik
Telerik Web Forms RadAsyncUpload Client-State Decrypt-vs-Parse Oracle Vulnerability (CVE-2026-13182) - Telerik UI for ASP.NET AJAX
Security notification CVE-2026-13182, RadAsyncUpload client-state decrypt-vs-parse oracle vulnerability.
🚨 CVE-2026-13183
In Progress® Telerik® UI for AJAX prior to v2026.2.708, RadAsyncUpload upload metadata processing may leak cryptographic validity through measurable timing differences, enabling remote attackers to recover protected metadata values.
🎖@cveNotify
In Progress® Telerik® UI for AJAX prior to v2026.2.708, RadAsyncUpload upload metadata processing may leak cryptographic validity through measurable timing differences, enabling remote attackers to recover protected metadata values.
🎖@cveNotify
Telerik
Telerik Web Forms RadAsyncUpload Upload Metadata Timing Oracle Vulnerability (CVE-2026-13183) - Telerik UI for ASP.NET AJAX
Security notification CVE-2026-13183, RadAsyncUpload upload metadata timing oracle vulnerability.
🚨 CVE-2026-13184
In Progress® Telerik® UI for AJAX prior to v2026.2.708, when Telerik.Upload.ConfigurationHashKey is absent and machineKey is not explicitly configured, upload metadata integrity protection may fall back to a predictable default key, enabling attackers to forge protected upload metadata and unlock further exploit chains.
🎖@cveNotify
In Progress® Telerik® UI for AJAX prior to v2026.2.708, when Telerik.Upload.ConfigurationHashKey is absent and machineKey is not explicitly configured, upload metadata integrity protection may fall back to a predictable default key, enabling attackers to forge protected upload metadata and unlock further exploit chains.
🎖@cveNotify
Telerik
Telerik Web Forms RadAsyncUpload Default HMAC Key Fallback Vulnerability (CVE-2026-13184) - Telerik UI for ASP.NET AJAX
Security notification CVE-2026-13184, RadAsyncUpload default HMAC key fallback vulnerability.
🚨 CVE-2026-13185
In Progress® Telerik® UI for AJAX prior to v2026.2.708, applications using cookie-based storage in RadPersistenceManager or RadDockLayout deserialize attacker-controlled cookie content, allowing unauthenticated remote code execution.
🎖@cveNotify
In Progress® Telerik® UI for AJAX prior to v2026.2.708, applications using cookie-based storage in RadPersistenceManager or RadDockLayout deserialize attacker-controlled cookie content, allowing unauthenticated remote code execution.
🎖@cveNotify
Telerik
Telerik Web Forms PersistenceFramework Cookie Deserialization Vulnerability (CVE-2026-13185) - Telerik UI for ASP.NET AJAX
Security notification CVE-2026-13185, PersistenceFramework cookie deserialization vulnerability.
🚨 CVE-2026-13186
In Progress® Telerik® UI for AJAX prior to v2026.2.708, a path traversal vulnerability in the file-based persistence storage provider can be exploited when the storage key is derived from user-controlled input, enabling attacker-controlled deserialization and remote code execution.
🎖@cveNotify
In Progress® Telerik® UI for AJAX prior to v2026.2.708, a path traversal vulnerability in the file-based persistence storage provider can be exploited when the storage key is derived from user-controlled input, enabling attacker-controlled deserialization and remote code execution.
🎖@cveNotify
Telerik
Telerik Web Forms AppDataStorageProvider Path Traversal Deserialization Vulnerability (CVE-2026-13186) - Telerik UI for ASP.NET…
Security notification CVE-2026-13186, AppDataStorageProvider path traversal deserialization vulnerability.
🚨 CVE-2026-13187
In Progress® Telerik® UI for AJAX prior to v2026.2.708, DialogHandler provider type input may be tampered with, potentially altering dialog processing and enabling chained exploitation.
🎖@cveNotify
In Progress® Telerik® UI for AJAX prior to v2026.2.708, DialogHandler provider type input may be tampered with, potentially altering dialog processing and enabling chained exploitation.
🎖@cveNotify
Telerik
Telerik Web Forms DialogHandler Provider Type Tampering Vulnerability (CVE-2026-13187) - Telerik UI for ASP.NET AJAX
Security notification CVE-2026-13187, DialogHandler provider type tampering vulnerability.
🚨 CVE-2026-13188
In Progress® Telerik® UI for AJAX prior to v2026.2.708, DialogHandler request parameters may be tampered with, potentially altering dialog server-side behavior and enabling chained exploitation.
🎖@cveNotify
In Progress® Telerik® UI for AJAX prior to v2026.2.708, DialogHandler request parameters may be tampered with, potentially altering dialog server-side behavior and enabling chained exploitation.
🎖@cveNotify
Telerik
Telerik Web Forms DialogHandler Parameters Tampering Vulnerability (CVE-2026-13188) - Telerik UI for ASP.NET AJAX
Security notification CVE-2026-13188, DialogHandler parameters tampering vulnerability.
🚨 CVE-2026-13189
In Progress® Telerik® UI for AJAX prior to v2026.2.708, insufficient validation of the language parameter in the spell check handler may allow an attacker to influence server-side file path resolution and trigger unintended server-side requests.
🎖@cveNotify
In Progress® Telerik® UI for AJAX prior to v2026.2.708, insufficient validation of the language parameter in the spell check handler may allow an attacker to influence server-side file path resolution and trigger unintended server-side requests.
🎖@cveNotify
Telerik
Telerik Web Forms SpellChecker DictionaryLanguage Path Traversal Vulnerability (CVE-2026-13189) - Telerik UI for ASP.NET AJAX
Security notification CVE-2026-13189, SpellChecker DictionaryLanguage path traversal vulnerability.
🚨 CVE-2026-13190
In Progress® Telerik® UI for AJAX prior to v2026.2.708, a deserialization vulnerability in the persistence utilities allows unsafe type instantiation from attacker-influenced persisted state, which can lead to remote code execution.
🎖@cveNotify
In Progress® Telerik® UI for AJAX prior to v2026.2.708, a deserialization vulnerability in the persistence utilities allows unsafe type instantiation from attacker-influenced persisted state, which can lead to remote code execution.
🎖@cveNotify
Telerik
Telerik Web Forms PersistenceFramework Unsafe Type Resolution Vulnerability (CVE-2026-13190) - Telerik UI for ASP.NET AJAX
Security notification CVE-2026-13190, PersistenceFramework unsafe type resolution vulnerability.
🚨 CVE-2026-13192
In Progress® Telerik® UI for AJAX prior to v2026.2.708, insufficient validation of content submitted to the RadEditor PDF export feature may allow an authenticated attacker to trigger server-side requests to arbitrary hosts, resulting in outbound network connections and potential exposure of Windows authentication credentials.
🎖@cveNotify
In Progress® Telerik® UI for AJAX prior to v2026.2.708, insufficient validation of content submitted to the RadEditor PDF export feature may allow an authenticated attacker to trigger server-side requests to arbitrary hosts, resulting in outbound network connections and potential exposure of Windows authentication credentials.
🎖@cveNotify
Telerik
Telerik Web Forms RadEditor PDF Export SSRF Vulnerability (CVE-2026-13192) - Telerik UI for ASP.NET AJAX
Security notification CVE-2026-13192, RadEditor PDF export SSRF vulnerability.
🚨 CVE-2026-14865
In Progress® Telerik® UI for AJAX prior to v2026.2.708, the internal LayoutBuilder control processes client-state XML without disabling DTD processing, allowing unauthenticated denial of service via recursive XML entity expansion.
🎖@cveNotify
In Progress® Telerik® UI for AJAX prior to v2026.2.708, the internal LayoutBuilder control processes client-state XML without disabling DTD processing, allowing unauthenticated denial of service via recursive XML entity expansion.
🎖@cveNotify
Telerik
Telerik Web Forms XXE Denial of Service via RadLayoutBuilder Client State (CVE-2026-14865) - Telerik UI for ASP.NET AJAX
Security notification CVE-2026-14865, XXE injection via RadLayoutBuilder client state leading to denial of service.
🚨 CVE-2026-48782
Pydantic AI is a Python agent framework for building applications and workflows with Generative AI. In versions 1.56.0 through 1.101.0, 2.0.0b1, and 2.0.0b2, the cloud-metadata blocklist could be bypassed by encoding the metadata IP in an IPv6 transition form that the previous fix, CVE-2026-46678, did not decode, exposing cloud IAM short-term credentials. The previous remediation decoded only IPv4-mapped IPv6, 6to4, and the NAT64 well-known prefix, so the metadata guarantee did not hold for the remaining transition forms: IPv4-compatible IPv6 (::a.b.c.d), the NAT64 RFC 8215 local-use prefix (64:ff9b:1::/48), operator-chosen NAT64 prefixes, and ISATAP. The IPv6 wrapper is then delivered to the underlying IPv4 metadata endpoint. This occurs when an application using Pydantic AI opts a URL into force_download='allow-local' (which disables the default block on private/internal IPs) and runs on a network that actually routes the affected IPv6 transition forms: NAT64-configured networks (IPv6-only or dual-stack-with-NAT64 deployments, including some Kubernetes setups) for the NAT64 variants, or networks with an ISATAP tunnel for ISATAP. A standard dual-stack cloud VM or container does not route these forms and is not affected in practice. The IPv4-compatible and Teredo variants are deprecated and addressed as defense-in-depth. This is an incomplete fix of GHSA-cqp8-fcvh-x7r3 / CVE-2026-46678 (itself a follow-up to CVE-2026-25580). This issue has been fixed in version 2.0.0b3.
🎖@cveNotify
Pydantic AI is a Python agent framework for building applications and workflows with Generative AI. In versions 1.56.0 through 1.101.0, 2.0.0b1, and 2.0.0b2, the cloud-metadata blocklist could be bypassed by encoding the metadata IP in an IPv6 transition form that the previous fix, CVE-2026-46678, did not decode, exposing cloud IAM short-term credentials. The previous remediation decoded only IPv4-mapped IPv6, 6to4, and the NAT64 well-known prefix, so the metadata guarantee did not hold for the remaining transition forms: IPv4-compatible IPv6 (::a.b.c.d), the NAT64 RFC 8215 local-use prefix (64:ff9b:1::/48), operator-chosen NAT64 prefixes, and ISATAP. The IPv6 wrapper is then delivered to the underlying IPv4 metadata endpoint. This occurs when an application using Pydantic AI opts a URL into force_download='allow-local' (which disables the default block on private/internal IPs) and runs on a network that actually routes the affected IPv6 transition forms: NAT64-configured networks (IPv6-only or dual-stack-with-NAT64 deployments, including some Kubernetes setups) for the NAT64 variants, or networks with an ISATAP tunnel for ISATAP. A standard dual-stack cloud VM or container does not route these forms and is not affected in practice. The IPv4-compatible and Teredo variants are deprecated and addressed as defense-in-depth. This is an incomplete fix of GHSA-cqp8-fcvh-x7r3 / CVE-2026-46678 (itself a follow-up to CVE-2026-25580). This issue has been fixed in version 2.0.0b3.
🎖@cveNotify
GitHub
fix: expand IPv6 transition-form handling in URL validation (#5596) · pydantic/pydantic-ai@1add061
AI Agent Framework, the Pydantic way. Contribute to pydantic/pydantic-ai development by creating an account on GitHub.
🚨 CVE-2026-9726
Improperly Controlled Modification of Dynamically-Determined Object Attributes vulnerability in Drupal Drupal AlternativeCommerce (Basket) allows Object Injection. This issue affects Drupal AlternativeCommerce (Basket) versions: from 0.0.0 to 2.1.17.
🎖@cveNotify
Improperly Controlled Modification of Dynamically-Determined Object Attributes vulnerability in Drupal Drupal AlternativeCommerce (Basket) allows Object Injection. This issue affects Drupal AlternativeCommerce (Basket) versions: from 0.0.0 to 2.1.17.
🎖@cveNotify
Drupal.org
Drupal AlternativeCommerce (Basket) - Highly critical - Arbitrary PHP code execution - SA-CONTRIB-2026-038
The Basket module enables e-commerce and checkout functionality for Drupal sites. The module does not sufficiently sanitize user-supplied data before passing it to PHP's unserialize(). An attacker can supply a crafted payload and trigger PHP Object Injection.…