๐จ CVE-2019-1010296
Linaro/OP-TEE OP-TEE 3.3.0 and earlier is affected by: Buffer Overflow. The impact is: Code execution in context of TEE core (kernel). The component is: optee_os. The fixed version is: 3.4.0 and later.
๐@cveNotify
Linaro/OP-TEE OP-TEE 3.3.0 and earlier is affected by: Buffer Overflow. The impact is: Code execution in context of TEE core (kernel). The component is: optee_os. The fixed version is: 3.4.0 and later.
๐@cveNotify
GitHub
svc: check for allocation overflow in syscall_cryp_obj_populate ยท OP-TEE/optee_os@b60e1ce
Without checking for overflow there is a risk of allocating a buffer
with size smaller than anticipated and as a consequence of that it might
lead to a heap based overflow with attacker controlled ...
with size smaller than anticipated and as a consequence of that it might
lead to a heap based overflow with attacker controlled ...
๐จ CVE-2019-1010297
Linaro/OP-TEE OP-TEE 3.3.0 and earlier is affected by: Buffer Overflow. The impact is: Execution of code in TEE core (kernel) context. The component is: optee_os. The fixed version is: 3.4.0 and later.
๐@cveNotify
Linaro/OP-TEE OP-TEE 3.3.0 and earlier is affected by: Buffer Overflow. The impact is: Execution of code in TEE core (kernel) context. The component is: optee_os. The fixed version is: 3.4.0 and later.
๐@cveNotify
GitHub
svc: check for allocation overflow in crypto calls ยท OP-TEE/optee_os@a637243
Without checking for overflow there is a risk of allocating a buffer
with size smaller than anticipated and as a consequence of that it might
lead to a heap based overflow with attacker controlled ...
with size smaller than anticipated and as a consequence of that it might
lead to a heap based overflow with attacker controlled ...
๐จ CVE-2019-1010298
Linaro/OP-TEE OP-TEE 3.3.0 and earlier is affected by: Buffer Overflow. The impact is: Code execution in the context of TEE core (kernel). The component is: optee_os. The fixed version is: 3.4.0 and later.
๐@cveNotify
Linaro/OP-TEE OP-TEE 3.3.0 and earlier is affected by: Buffer Overflow. The impact is: Code execution in the context of TEE core (kernel). The component is: optee_os. The fixed version is: 3.4.0 and later.
๐@cveNotify
GitHub
svc: check for allocation overflow in crypto calls part 2 ยท OP-TEE/optee_os@70697bf
Without checking for overflow there is a risk of allocating a buffer
with size smaller than anticipated and as a consequence of that it might
lead to a heap based overflow with attacker controlled ...
with size smaller than anticipated and as a consequence of that it might
lead to a heap based overflow with attacker controlled ...
๐จ CVE-2019-1010292
Linaro/OP-TEE OP-TEE Prior to version v3.4.0 is affected by: Boundary checks. The impact is: This could lead to corruption of any memory which the TA can access. The component is: optee_os. The fixed version is: v3.4.0.
๐@cveNotify
Linaro/OP-TEE OP-TEE Prior to version v3.4.0 is affected by: Boundary checks. The impact is: This could lead to corruption of any memory which the TA can access. The component is: optee_os. The fixed version is: v3.4.0.
๐@cveNotify
GitHub
core: ensure that supplied range matches MOBJ ยท OP-TEE/optee_os@e3adcf5
In set_rmem_param() if the MOBJ is found by the cookie it's verified to
represent non-secure shared memory. Prior to this patch the supplied
sub-range to be used of the MOBJ was not checked...
represent non-secure shared memory. Prior to this patch the supplied
sub-range to be used of the MOBJ was not checked...
๐จ CVE-2020-13799
Western Digital has identified a security vulnerability in the Replay Protected Memory Block (RPMB) protocol as specified in multiple standards for storage device interfaces, including all versions of eMMC, UFS, and NVMe. The RPMB protocol is specified by industry standards bodies and is implemented by storage devices from multiple vendors to assist host systems in securing trusted firmware. Several scenarios have been identified in which the RPMB state may be affected by an attacker without the knowledge of the trusted component that uses the RPMB feature.
๐@cveNotify
Western Digital has identified a security vulnerability in the Replay Protected Memory Block (RPMB) protocol as specified in multiple standards for storage device interfaces, including all versions of eMMC, UFS, and NVMe. The RPMB protocol is specified by industry standards bodies and is implemented by storage devices from multiple vendors to assist host systems in securing trusted firmware. Several scenarios have been identified in which the RPMB state may be affected by an attacker without the knowledge of the trusted component that uses the RPMB feature.
๐@cveNotify
www.kb.cert.org
CERT/CC Vulnerability Note VU#231329
Replay Protected Memory Block (RPMB) protocol does not adequately defend against replay attacks
๐จ CVE-2019-25052
In Linaro OP-TEE before 3.7.0, by using inconsistent or malformed data, it is possible to call update and final cryptographic functions directly, causing a crash that could leak sensitive information.
๐@cveNotify
In Linaro OP-TEE before 3.7.0, by using inconsistent or malformed data, it is possible to call update and final cryptographic functions directly, causing a crash that could leak sensitive information.
๐@cveNotify
GitHub
cryp: prevent direct calls to update and final functions ยท OP-TEE/optee_os@34a08be
With inconsistent or malformed data it has been possible to call
"update" and "final" crypto functions directly. Using a fuzzer tool [1]
we have seen that this r...
"update" and "final" crypto functions directly. Using a fuzzer tool [1]
we have seen that this r...
๐จ CVE-2026-37234
FlexRIC v2.0.0 allows a single SCTP connection to bind multiple xapp_ids by sending multiple E42_SETUP_REQUESTs. On disconnect, only the first registered xapp_id's resources are cleaned up; subsequent xapp_ids and their subscriptions remain as stale entries. A remote attacker can exploit this to leak subscription state in the iApp, potentially causing resource exhaustion or state corruption over time.
๐@cveNotify
FlexRIC v2.0.0 allows a single SCTP connection to bind multiple xapp_ids by sending multiple E42_SETUP_REQUESTs. On disconnect, only the first registered xapp_id's resources are cleaned up; subsequent xapp_ids and their subscriptions remain as stale entries. A remote attacker can exploit this to leak subscription state in the iApp, potentially causing resource exhaustion or state corruption over time.
๐@cveNotify
GitHub
oran-security-advisories-zhongnan-luo/advisories/CVE-2026-37234.md at main ยท MinamiKotor1/oran-security-advisories-zhongnan-luo
Contribute to MinamiKotor1/oran-security-advisories-zhongnan-luo development by creating an account on GitHub.
๐จ CVE-2025-71313
In the Linux kernel, the following vulnerability has been resolved:
PCI: endpoint: Add missing NULL check for alloc_workqueue()
alloc_workqueue() can return NULL on memory allocation failure. Without
proper error checking, this may lead to a NULL pointer dereference when
queue_work() is later called with the NULL workqueue pointer in
epf_ntb_epc_init().
Add a NULL check immediately after alloc_workqueue() and return -ENOMEM on
failure to prevent the driver from loading with an invalid workqueue
pointer.
๐@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
PCI: endpoint: Add missing NULL check for alloc_workqueue()
alloc_workqueue() can return NULL on memory allocation failure. Without
proper error checking, this may lead to a NULL pointer dereference when
queue_work() is later called with the NULL workqueue pointer in
epf_ntb_epc_init().
Add a NULL check immediately after alloc_workqueue() and return -ENOMEM on
failure to prevent the driver from loading with an invalid workqueue
pointer.
๐@cveNotify
๐จ CVE-2025-71314
In the Linux kernel, the following vulnerability has been resolved:
drm/panthor: Recover from panthor_gpu_flush_caches() failures
We have seen a few cases where the whole memory subsystem is blocked
and flush operations never complete. When that happens, we want to:
- schedule a reset, so we can recover from this situation
- in the reset path, we need to reset the pending_reqs so we can send
new commands after the reset
- if more panthor_gpu_flush_caches() operations are queued after
the timeout, we skip them and return -EIO directly to avoid needless
waits (the memory block won't miraculously work again)
Note that we drop the WARN_ON()s because these hangs can be triggered
with buggy GPU jobs created by the UMD, and there's no way we can
prevent it. We do keep the error messages though.
v2:
- New patch
v3:
- Collect R-b
- Explicitly mention the fact we dropped the WARN_ON()s in the commit
message
v4:
- No changes
๐@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
drm/panthor: Recover from panthor_gpu_flush_caches() failures
We have seen a few cases where the whole memory subsystem is blocked
and flush operations never complete. When that happens, we want to:
- schedule a reset, so we can recover from this situation
- in the reset path, we need to reset the pending_reqs so we can send
new commands after the reset
- if more panthor_gpu_flush_caches() operations are queued after
the timeout, we skip them and return -EIO directly to avoid needless
waits (the memory block won't miraculously work again)
Note that we drop the WARN_ON()s because these hangs can be triggered
with buggy GPU jobs created by the UMD, and there's no way we can
prevent it. We do keep the error messages though.
v2:
- New patch
v3:
- Collect R-b
- Explicitly mention the fact we dropped the WARN_ON()s in the commit
message
v4:
- No changes
๐@cveNotify
๐จ CVE-2026-46244
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nft_inner: Fix IPv6 inner_thoff desync
In nft_inner_parse_l2l3(), when processing inner IPv6 packets,
ipv6_find_hdr() correctly computes the transport header offset
traversing all extension headers, but the result is immediately
overwritten with nhoff + sizeof(_ip6h) (40 bytes), which only
accounts for the IPv6 base header. This creates a desync between
inner_thoff (wrong โ points to extension header start) and l4proto
(correct โ e.g., IPPROTO_TCP), enabling transport header forgery
and potential firewall bypass. This issue affects stable versions
from Linux 6.2.
For comparison, the normal (non-inner) IPv6 path correctly
preserves ipv6_find_hdr()'s result. Removing the incorrect overwrite
ensures that ipv6_find_hdr()'s calculated transport header offset is
preserved, thereby fixing the desynchronization.
๐@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nft_inner: Fix IPv6 inner_thoff desync
In nft_inner_parse_l2l3(), when processing inner IPv6 packets,
ipv6_find_hdr() correctly computes the transport header offset
traversing all extension headers, but the result is immediately
overwritten with nhoff + sizeof(_ip6h) (40 bytes), which only
accounts for the IPv6 base header. This creates a desync between
inner_thoff (wrong โ points to extension header start) and l4proto
(correct โ e.g., IPPROTO_TCP), enabling transport header forgery
and potential firewall bypass. This issue affects stable versions
from Linux 6.2.
For comparison, the normal (non-inner) IPv6 path correctly
preserves ipv6_find_hdr()'s result. Removing the incorrect overwrite
ensures that ipv6_find_hdr()'s calculated transport header offset is
preserved, thereby fixing the desynchronization.
๐@cveNotify
๐จ CVE-2026-46245
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix dc_link NULL handling in HPD init
amdgpu_dm_hpd_init() may see connectors without a valid dc_link.
The code already checks dc_link for the polling decision, but later
unconditionally dereferences it when setting up HPD interrupts.
Assign dc_link early and skip connectors where it is NULL.
Fixes the below:
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_irq.c:940 amdgpu_dm_hpd_init()
error: we previously assumed 'dc_link' could be null (see line 931)
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_irq.c
923 /*
924 * Analog connectors may be hot-plugged unlike other connector
925 * types that don't support HPD. Only poll analog connectors.
926 */
927 use_polling |=
928 amdgpu_dm_connector->dc_link &&
^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The patch adds this NULL check but hopefully it can be removed
929 dc_connector_supports_analog(amdgpu_dm_connector->dc_link->link_id.id);
930
931 dc_link = amdgpu_dm_connector->dc_link;
dc_link assigned here.
932
933 /*
934 * Get a base driver irq reference for hpd ints for the lifetime
935 * of dm. Note that only hpd interrupt types are registered with
936 * base driver; hpd_rx types aren't. IOW, amdgpu_irq_get/put on
937 * hpd_rx isn't available. DM currently controls hpd_rx
938 * explicitly with dc_interrupt_set()
939 */
--> 940 if (dc_link->irq_source_hpd != DC_IRQ_SOURCE_INVALID) {
^^^^^^^^^^^^^^^^^^^^^^^ If it's NULL then we are trouble because we dereference it here.
941 irq_type = dc_link->irq_source_hpd - DC_IRQ_SOURCE_HPD1;
942 /*
943 * TODO: There's a mismatch between mode_info.num_hpd
944 * and what bios reports as the # of connectors with hpd
๐@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix dc_link NULL handling in HPD init
amdgpu_dm_hpd_init() may see connectors without a valid dc_link.
The code already checks dc_link for the polling decision, but later
unconditionally dereferences it when setting up HPD interrupts.
Assign dc_link early and skip connectors where it is NULL.
Fixes the below:
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_irq.c:940 amdgpu_dm_hpd_init()
error: we previously assumed 'dc_link' could be null (see line 931)
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_irq.c
923 /*
924 * Analog connectors may be hot-plugged unlike other connector
925 * types that don't support HPD. Only poll analog connectors.
926 */
927 use_polling |=
928 amdgpu_dm_connector->dc_link &&
^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The patch adds this NULL check but hopefully it can be removed
929 dc_connector_supports_analog(amdgpu_dm_connector->dc_link->link_id.id);
930
931 dc_link = amdgpu_dm_connector->dc_link;
dc_link assigned here.
932
933 /*
934 * Get a base driver irq reference for hpd ints for the lifetime
935 * of dm. Note that only hpd interrupt types are registered with
936 * base driver; hpd_rx types aren't. IOW, amdgpu_irq_get/put on
937 * hpd_rx isn't available. DM currently controls hpd_rx
938 * explicitly with dc_interrupt_set()
939 */
--> 940 if (dc_link->irq_source_hpd != DC_IRQ_SOURCE_INVALID) {
^^^^^^^^^^^^^^^^^^^^^^^ If it's NULL then we are trouble because we dereference it here.
941 irq_type = dc_link->irq_source_hpd - DC_IRQ_SOURCE_HPD1;
942 /*
943 * TODO: There's a mismatch between mode_info.num_hpd
944 * and what bios reports as the # of connectors with hpd
๐@cveNotify
๐จ CVE-2026-46246
In the Linux kernel, the following vulnerability has been resolved:
power: supply: pm8916_lbc: Fix use-after-free for extcon in IRQ handler
Using the `devm_` variant for requesting IRQ _before_ the `devm_`
variant for allocating/registering the `extcon` handle, means that the
`extcon` handle will be deallocated/unregistered _before_ the interrupt
handler (since `devm_` naturally deallocates in reverse allocation
order). This means that during removal, there is a race condition where
an interrupt can fire just _after_ the `extcon` handle has been
freed, *but* just _before_ the corresponding unregistration of the IRQ
handler has run.
This will lead to the IRQ handler calling `extcon_set_state_sync()` with
a freed `extcon` handle. Which usually crashes the system or otherwise
silently corrupts the memory...
Fix this racy use-after-free by making sure the IRQ is requested _after_
the registration of the `extcon` handle.
๐@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
power: supply: pm8916_lbc: Fix use-after-free for extcon in IRQ handler
Using the `devm_` variant for requesting IRQ _before_ the `devm_`
variant for allocating/registering the `extcon` handle, means that the
`extcon` handle will be deallocated/unregistered _before_ the interrupt
handler (since `devm_` naturally deallocates in reverse allocation
order). This means that during removal, there is a race condition where
an interrupt can fire just _after_ the `extcon` handle has been
freed, *but* just _before_ the corresponding unregistration of the IRQ
handler has run.
This will lead to the IRQ handler calling `extcon_set_state_sync()` with
a freed `extcon` handle. Which usually crashes the system or otherwise
silently corrupts the memory...
Fix this racy use-after-free by making sure the IRQ is requested _after_
the registration of the `extcon` handle.
๐@cveNotify
๐จ CVE-2025-70100
A divide-by-zero vulnerability in the ext4_block_set_lb_size function in src/ext4_blockdev.c of the lwext4 1.0.0 library allows attackers to cause a denial of service by providing a malformed ext4 filesystem image that results in a zero logical block size. The vulnerability is triggered during mount or image processing and leads to a Floating-Point Exception (FPE) under sanitizers or a runtime crash in standard builds due to missing validation of lb_size.
๐@cveNotify
A divide-by-zero vulnerability in the ext4_block_set_lb_size function in src/ext4_blockdev.c of the lwext4 1.0.0 library allows attackers to cause a denial of service by providing a malformed ext4 filesystem image that results in a zero logical block size. The vulnerability is triggered during mount or image processing and leads to a Floating-Point Exception (FPE) under sanitizers or a runtime crash in standard builds due to missing validation of lb_size.
๐@cveNotify
GitHub
[security] lwext4/src/ext4_blockdev.c FPE in ext4_block_set_lb_size ยท Issue #90 ยท gkostka/lwext4
lwext4/src/ext4_blockdev.c FPE in ext4_block_set_lb_size Description: When processing a crafted ext4-image, "ext4_mount()" may pass an invalid logical block size (lb_size == 0) into "...
๐จ CVE-2025-70101
An out-of-bounds read in the ext4_ext_binsearch_idx function in src/ext4_extent.c of the lwext4 1.0.0 library allows attackers to cause a denial of service by supplying a specially crafted ext4 filesystem image. The vulnerability occurs due to insufficient validation of extent header fields before performing a binary search over extent index entries, which can result in invalid pointer calculations and an out-of-bounds memory read during extent tree traversal.
๐@cveNotify
An out-of-bounds read in the ext4_ext_binsearch_idx function in src/ext4_extent.c of the lwext4 1.0.0 library allows attackers to cause a denial of service by supplying a specially crafted ext4 filesystem image. The vulnerability occurs due to insufficient validation of extent header fields before performing a binary search over extent index entries, which can result in invalid pointer calculations and an out-of-bounds memory read during extent tree traversal.
๐@cveNotify
GitHub
[security] lwext4/include/ext4_dir.h Out-of-Bounds Read in ext4_ext_binsearch_idx ยท Issue #91 ยท gkostka/lwext4
lwext4/include/ext4_dir.h Out-of-Bounds Read in ext4_ext_binsearch_idx Description: Probably, when traversing an inodeโs extent tree, the function "ext4_ext_binsearch_idx()" assumes that ...
๐จ CVE-2026-40898
quic-go is an implementation of the QUIC protocol in Go. Prior to version 0.59.1, an attacker can cause excessive memory allocation in quic-go's HTTP/3 client and server implementations by sending a QPACK-encoded HEADERS frame that decodes into a large trailer field section with many unique field names and/or large values. The implementation builds an `http.Header` for the corresponding `http.Request` or `http.Response`, while only enforcing limits on the size of the QPACK-compressed HEADERS frame, not on the decoded field section. This can lead to memory exhaustion. This is very similar to CVE-2025-64702. The difference is that this issue uses HTTP trailers, rather than HTTP headers, as the attack vector. A misbehaving or malicious peer can cause a denial-of-service (DoS) attack against quic-go's HTTP/3 servers or clients by triggering excessive memory allocation, potentially leading to crashes or resource exhaustion. This affects both servers and clients due to symmetric header construction. Version 0.59.1 enforces RFC 9114 decoded field section size limits for trailers as well. It incrementally decodes QPACK entries and checks the field section size after each entry, aborting the stream if an entry causes the limit to be exceeded.
๐@cveNotify
quic-go is an implementation of the QUIC protocol in Go. Prior to version 0.59.1, an attacker can cause excessive memory allocation in quic-go's HTTP/3 client and server implementations by sending a QPACK-encoded HEADERS frame that decodes into a large trailer field section with many unique field names and/or large values. The implementation builds an `http.Header` for the corresponding `http.Request` or `http.Response`, while only enforcing limits on the size of the QPACK-compressed HEADERS frame, not on the decoded field section. This can lead to memory exhaustion. This is very similar to CVE-2025-64702. The difference is that this issue uses HTTP trailers, rather than HTTP headers, as the attack vector. A misbehaving or malicious peer can cause a denial-of-service (DoS) attack against quic-go's HTTP/3 servers or clients by triggering excessive memory allocation, potentially leading to crashes or resource exhaustion. This affects both servers and clients due to symmetric header construction. Version 0.59.1 enforces RFC 9114 decoded field section size limits for trailers as well. It incrementally decodes QPACK entries and checks the field section size after each entry, aborting the stream if an entry causes the limit to be exceeded.
๐@cveNotify
GitHub
Release v0.59.1 ยท quic-go/quic-go
This patch release backports #5642, which adds validation for HTTP/3 trailers.
๐จ CVE-2024-6858
In Aristaโs EOS when in 802.1X mode, multi-auth unauthenticated hosts might be allowed access to a switch port if there exists an EAPOL capable device in the fallback VLAN.
๐@cveNotify
In Aristaโs EOS when in 802.1X mode, multi-auth unauthenticated hosts might be allowed access to a switch port if there exists an EAPOL capable device in the fallback VLAN.
๐@cveNotify
๐จ CVE-2026-7762
A heap-based buffer overflow vulnerability in the dot11ah.ko HaLow Wi-Fi kernel driver in Morse Micro HaLowLink 2 software versions prior to 2.11.13 allows an unauthenticated attacker within radio range to cause a Denial of Service (kernel panic) or potentially achieve Remote Code Execution via a crafted 802.11ah beacon or probe response frame containing a malformed S1G Capabilities Information Element (IE element ID 0xD9). The function morse_dot11ah_find_s1g_caps_for_bssid() uses the IE length field directly as the size argument to memcpy without validating it against the 15-byte destination buffer. An attacker can supply up to 255 bytes, causing an overflow of up to 240 bytes of attacker-controlled data into adjacent kernel heap memory. The vulnerability is triggerable during normal scanning without authentication, association, or user interaction.
๐@cveNotify
A heap-based buffer overflow vulnerability in the dot11ah.ko HaLow Wi-Fi kernel driver in Morse Micro HaLowLink 2 software versions prior to 2.11.13 allows an unauthenticated attacker within radio range to cause a Denial of Service (kernel panic) or potentially achieve Remote Code Execution via a crafted 802.11ah beacon or probe response frame containing a malformed S1G Capabilities Information Element (IE element ID 0xD9). The function morse_dot11ah_find_s1g_caps_for_bssid() uses the IE length field directly as the size argument to memcpy without validating it against the 15-byte destination buffer. An attacker can supply up to 255 bytes, causing an overflow of up to 240 bytes of attacker-controlled data into adjacent kernel heap memory. The vulnerability is triggerable during normal scanning without authentication, association, or user interaction.
๐@cveNotify
Morse Micro
MM-SA-2026-002
MM-SA-2026-002 Security Advisory Heap buffer overflow in dot11ah.ko S1G Capabilities IE processing CVE CVE-2026-7762 Severity High (CVSS v3.1 8.8) Fixed
๐จ CVE-2026-7763
A heap-based buffer overflow vulnerability in the morse.ko HaLow Wi-Fi kernel driver in Morse Micro HaLowLink 2 software versions prior to 2.11.13 allows an unauthenticated attacker within radio range to cause a Denial of Service (kernel panic) or potentially achieve Remote Code Execution via a crafted 802.11ah beacon frame containing a malformed Traffic Indication Map (TIM) Information Element. The function morse_page_slicing_process_tim_element() in page_slicing.c derives the TIM bitmap length directly from a received IE field without validating it against the fixed-size destination buffer before passing it to memset and memcpy operations, allowing up to 252 bytes of attacker-controlled data to be written beyond the buffer boundary. Because beacons are broadcast frames processed during passive scanning, no authentication, association, or user interaction is required.
๐@cveNotify
A heap-based buffer overflow vulnerability in the morse.ko HaLow Wi-Fi kernel driver in Morse Micro HaLowLink 2 software versions prior to 2.11.13 allows an unauthenticated attacker within radio range to cause a Denial of Service (kernel panic) or potentially achieve Remote Code Execution via a crafted 802.11ah beacon frame containing a malformed Traffic Indication Map (TIM) Information Element. The function morse_page_slicing_process_tim_element() in page_slicing.c derives the TIM bitmap length directly from a received IE field without validating it against the fixed-size destination buffer before passing it to memset and memcpy operations, allowing up to 252 bytes of attacker-controlled data to be written beyond the buffer boundary. Because beacons are broadcast frames processed during passive scanning, no authentication, association, or user interaction is required.
๐@cveNotify
Morse Micro
MM-SA-2026-001
MM-SA-2026-001 Security Advisory Heap buffer overflow in morse.ko TIM IE processing CVE CVE-2026-7763 Severity High (CVSS v3.1 8.8) Fixed in HaLowLink 2
๐จ CVE-2026-11416
MoviePilot contains a path traversal vulnerability in the AliPan, U115, and Rclone cloud storage download handlers where the local destination path is constructed by concatenating the configured download directory with a filename taken directly from remote cloud API metadata without basename normalization or path validation. An attacker who controls a filename returned by a remote cloud storage API can include traversal sequences ../ in the filename to cause downloaded content to be written outside the configured download directory, potentially overwriting arbitrary files including configuration or plugin files reachable by the application process.
๐@cveNotify
MoviePilot contains a path traversal vulnerability in the AliPan, U115, and Rclone cloud storage download handlers where the local destination path is constructed by concatenating the configured download directory with a filename taken directly from remote cloud API metadata without basename normalization or path validation. An attacker who controls a filename returned by a remote cloud storage API can include traversal sequences ../ in the filename to cause downloaded content to be written outside the configured download directory, potentially overwriting arbitrary files including configuration or plugin files reachable by the application process.
๐@cveNotify
GitHub
GitHub - jxxghp/MoviePilot: NASๅชไฝๅบ่ชๅจๅ็ฎก็ๅทฅๅ
ท
NASๅชไฝๅบ่ชๅจๅ็ฎก็ๅทฅๅ
ท. Contribute to jxxghp/MoviePilot development by creating an account on GitHub.
๐จ CVE-2026-11424
A server-side request forgery (SSRF) vulnerability exists in a GraphQL service component shared by Altium Enterprise Server and Altium 365. An authenticated user can submit a request whose input is treated as a URL by the server and used to issue an outbound HTTP GET request without URL validation or destination filtering. The response body is then returned to the user.
This allows an authenticated attacker to reach internal services and metadata endpoints that would not otherwise be accessible from the public network, and to retrieve their contents. The impact is information disclosure and internal infrastructure reconnaissance; the request primitive is limited to HTTP GET with no custom headers. Altium Enterprise Server is fixed in 8.1.1; the issue has been remediated in Altium 365 at the service level.
๐@cveNotify
A server-side request forgery (SSRF) vulnerability exists in a GraphQL service component shared by Altium Enterprise Server and Altium 365. An authenticated user can submit a request whose input is treated as a URL by the server and used to issue an outbound HTTP GET request without URL validation or destination filtering. The response body is then returned to the user.
This allows an authenticated attacker to reach internal services and metadata endpoints that would not otherwise be accessible from the public network, and to retrieve their contents. The impact is information disclosure and internal infrastructure reconnaissance; the request primitive is limited to HTTP GET with no custom headers. Altium Enterprise Server is fixed in 8.1.1; the issue has been remediated in Altium 365 at the service level.
๐@cveNotify
Altium
Security Advisories | Altium
This page contains important information regarding security vulnerabilitiesthat could affect specific versions of Altium 365 products or services.
๐จ CVE-2026-11429
A path traversal vulnerability exists in the Git Service component shared by Altium Enterprise Server and Altium 365. The service accepts a sequence of post-clone file-manipulation operations that use user-supplied paths without validation, allowing an authenticated user with basic git access to move arbitrary files outside the intended repository area.
This file-move primitive can be used to place attacker-controlled script content into directories where it is later executed by the service, resulting in remote code execution under the Git Service account. On multi-tenant Altium 365 deployments, this could have allowed access to data belonging to other tenants on the same infrastructure node. Altium Enterprise Server is fixed in 8.1.1; the issue has been remediated in Altium 365 at the service level.
๐@cveNotify
A path traversal vulnerability exists in the Git Service component shared by Altium Enterprise Server and Altium 365. The service accepts a sequence of post-clone file-manipulation operations that use user-supplied paths without validation, allowing an authenticated user with basic git access to move arbitrary files outside the intended repository area.
This file-move primitive can be used to place attacker-controlled script content into directories where it is later executed by the service, resulting in remote code execution under the Git Service account. On multi-tenant Altium 365 deployments, this could have allowed access to data belonging to other tenants on the same infrastructure node. Altium Enterprise Server is fixed in 8.1.1; the issue has been remediated in Altium 365 at the service level.
๐@cveNotify
Altium
Security Advisories | Altium
This page contains important information regarding security vulnerabilitiesthat could affect specific versions of Altium 365 products or services.