🚨 CVE-2026-66318
Origin validation error in Microsoft Edge (Chromium-based) allows an unauthorized attacker to disclose information over a network.
🎖@cveNotify
Origin validation error in Microsoft Edge (Chromium-based) allows an unauthorized attacker to disclose information over a network.
🎖@cveNotify
🚨 CVE-2026-66321
Access of resource using incompatible type ('type confusion') in Microsoft Edge (Chromium-based) allows an unauthorized attacker to execute code over a network.
🎖@cveNotify
Access of resource using incompatible type ('type confusion') in Microsoft Edge (Chromium-based) allows an unauthorized attacker to execute code over a network.
🎖@cveNotify
🚨 CVE-2026-66322
Origin validation error in Microsoft Edge (Chromium-based) allows an unauthorized attacker to perform spoofing over a network.
🎖@cveNotify
Origin validation error in Microsoft Edge (Chromium-based) allows an unauthorized attacker to perform spoofing over a network.
🎖@cveNotify
🚨 CVE-2026-66325
Server-side request forgery (ssrf) in Microsoft Edge (Chromium-based) allows an unauthorized attacker to perform spoofing over a network.
🎖@cveNotify
Server-side request forgery (ssrf) in Microsoft Edge (Chromium-based) allows an unauthorized attacker to perform spoofing over a network.
🎖@cveNotify
🚨 CVE-2026-66326
Missing authorization in Microsoft Edge (Chromium-based) allows an unauthorized attacker to execute code over a network.
🎖@cveNotify
Missing authorization in Microsoft Edge (Chromium-based) allows an unauthorized attacker to execute code over a network.
🎖@cveNotify
🚨 CVE-2026-14902
An open redirect in Ivanti Xtraction before version 2026.2.1 allows a remote unauthenticated attacker to redirect users to arbitrary external URLs.
🎖@cveNotify
An open redirect in Ivanti Xtraction before version 2026.2.1 allows a remote unauthenticated attacker to redirect users to arbitrary external URLs.
🎖@cveNotify
🚨 CVE-2026-14903
Path traversal in Ivanti Xtraction before version 2026.2.1 allows a remote authenticated attacker to read arbitrary files outside the web root.
🎖@cveNotify
Path traversal in Ivanti Xtraction before version 2026.2.1 allows a remote authenticated attacker to read arbitrary files outside the web root.
🎖@cveNotify
🚨 CVE-2026-12523
Summary
Cloudflare quiche's HTTP/3 layer was discovered to be vulnerable to resource exhaustion (i.e., memory) by means of specially crafted HTTP/3 frames.
Impact
HTTP/3 defines multiple frame types to support HTTP message exchanges and connection management. Each frame has a length and a payload whose length depends on the frame type. quiche was found to be vulnerable when parsing some frame types to pre-allocating memory based on the declared length. An attacker would not need to send the number of declared bytes to trigger this issue.
In addition, quiche was found to not apply QPACK decompression limits correctly. This could allow an attacker to send specially crafted HEADERS frames that would cause more memory commitment than otherwise advertised by MAX_FIELD_SECTION_SIZE (configured by set_max_field_section_size()).
Mitigation:
*
Users are requested to upgrade to quiche 0.29.3 which is the earliest version containing the fix for this issue.
Credits: Disclosed responsibly by Sébastien Féry
🎖@cveNotify
Summary
Cloudflare quiche's HTTP/3 layer was discovered to be vulnerable to resource exhaustion (i.e., memory) by means of specially crafted HTTP/3 frames.
Impact
HTTP/3 defines multiple frame types to support HTTP message exchanges and connection management. Each frame has a length and a payload whose length depends on the frame type. quiche was found to be vulnerable when parsing some frame types to pre-allocating memory based on the declared length. An attacker would not need to send the number of declared bytes to trigger this issue.
In addition, quiche was found to not apply QPACK decompression limits correctly. This could allow an attacker to send specially crafted HEADERS frames that would cause more memory commitment than otherwise advertised by MAX_FIELD_SECTION_SIZE (configured by set_max_field_section_size()).
Mitigation:
*
Users are requested to upgrade to quiche 0.29.3 which is the earliest version containing the fix for this issue.
Credits: Disclosed responsibly by Sébastien Féry
🎖@cveNotify
GitHub
Resource exhaustion in HTTP/3 and QPACK
Cloudflare quiche's HTTP/3 layer was discovered to be vulnerable to resource exhaustion (i.e. memory) by means of specially crafted HTTP/3 frames.
HTTP/3 defines multiple frame types to supp...
HTTP/3 defines multiple frame types to supp...
🚨 CVE-2026-58659
PyTorch Lightning through 2.6.5, fixed in commit d710d68, contains a remote code execution vulnerability in the _load_state function that imports and executes attacker-controlled module names from checkpoint _instantiator hyperparameters. Attackers can craft malicious checkpoint files that bypass weights_only=True protections to execute arbitrary code when LightningModule.load_from_checkpoint is called.
🎖@cveNotify
PyTorch Lightning through 2.6.5, fixed in commit d710d68, contains a remote code execution vulnerability in the _load_state function that imports and executes attacker-controlled module names from checkpoint _instantiator hyperparameters. Attackers can craft malicious checkpoint files that bypass weights_only=True protections to execute arbitrary code when LightningModule.load_from_checkpoint is called.
🎖@cveNotify
GitHub
fix(checkpoint): prevent arbitrary code execution via `_instantiator`… · Lightning-AI/pytorch-lightning@d710d68
… in `load_from_checkpoint` (#21832)
Prevent arbitrary code execution via _instantiator in load_from_checkpoint
Restrict the checkpoint _instantiator hyperparameter to an allowlist of
trusted ins...
Prevent arbitrary code execution via _instantiator in load_from_checkpoint
Restrict the checkpoint _instantiator hyperparameter to an allowlist of
trusted ins...
🚨 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.