🚨 CVE-2026-7656
The IPv6 Neighbor Discovery handlers in subsys/net/ip/ipv6_nbr.c (handle_ra_input, handle_ns_input, handle_na_input) used an incorrect boolean expression that combined the RFC 4861 validity checks with the ICMPv6 code check using the wrong operator precedence: the form was ((length/hop/source/target checks) && (icmp_hdr->code != 0)). Because every legitimate ND message carries ICMPv6 code 0, an attacker setting code == 0 (the normal value) caused the entire predicate to evaluate false, so the packet was never dropped and all of the other checks were silently skipped. The bypassed checks include the mandatory Hop Limit == 255 verification (which proves an ND packet originated on-link and was not forwarded) and, for Router Advertisements, the requirement that the source be a link-local address, as well as multicast-target sanity checks. As a result, an adjacent on-link attacker — and, because the Hop-Limit-255 guard is bypassed, potentially a remote/off-link attacker whose packets would otherwise be rejected — can have forged Router Advertisement, Neighbor Solicitation, and Neighbor Advertisement messages accepted. A forged RA lets the attacker reconfigure the victim's default router, on-link prefixes (SLAAC), MTU, reachable/retransmit timers, and (with CONFIG_NET_IPV6_RA_RDNSS) DNS servers, while forged NS/NA enable neighbor-cache poisoning, enabling man-in-the-middle, traffic redirection, and denial of service. The flaw is an input-validation/authentication weakness rather than a memory-safety issue: the underlying packet-parsing primitives (net_pkt_get_data, net_pkt_read, net_pkt_skip) are independently bounds-safe and the validated length is the true buffer length, so skipping the length check causes no out-of-bounds access. The defect has existed since the logic was introduced in 2018 and shipped in all releases through v4.4.0; it is fixed by splitting the condition so any failing check drops the packet.
🎖@cveNotify
The IPv6 Neighbor Discovery handlers in subsys/net/ip/ipv6_nbr.c (handle_ra_input, handle_ns_input, handle_na_input) used an incorrect boolean expression that combined the RFC 4861 validity checks with the ICMPv6 code check using the wrong operator precedence: the form was ((length/hop/source/target checks) && (icmp_hdr->code != 0)). Because every legitimate ND message carries ICMPv6 code 0, an attacker setting code == 0 (the normal value) caused the entire predicate to evaluate false, so the packet was never dropped and all of the other checks were silently skipped. The bypassed checks include the mandatory Hop Limit == 255 verification (which proves an ND packet originated on-link and was not forwarded) and, for Router Advertisements, the requirement that the source be a link-local address, as well as multicast-target sanity checks. As a result, an adjacent on-link attacker — and, because the Hop-Limit-255 guard is bypassed, potentially a remote/off-link attacker whose packets would otherwise be rejected — can have forged Router Advertisement, Neighbor Solicitation, and Neighbor Advertisement messages accepted. A forged RA lets the attacker reconfigure the victim's default router, on-link prefixes (SLAAC), MTU, reachable/retransmit timers, and (with CONFIG_NET_IPV6_RA_RDNSS) DNS servers, while forged NS/NA enable neighbor-cache poisoning, enabling man-in-the-middle, traffic redirection, and denial of service. The flaw is an input-validation/authentication weakness rather than a memory-safety issue: the underlying packet-parsing primitives (net_pkt_get_data, net_pkt_read, net_pkt_skip) are independently bounds-safe and the validated length is the true buffer length, so skipping the length check causes no out-of-bounds access. The defect has existed since the logic was introduced in 2018 and shipped in all releases through v4.4.0; it is fixed by splitting the condition so any failing check drops the packet.
🎖@cveNotify
GitHub
net: ipv6: Fix ND packets validation on input · zephyrproject-rtos/zephyr@095f064
The checks validating RA, NS and NA packets content on input were not
correct - packets should be dropped in case any of those checks failed,
however current logic was invalid, causing other checks...
correct - packets should be dropped in case any of those checks failed,
however current logic was invalid, causing other checks...
🚨 CVE-2026-58016
A flaw was found in GLib. A state confusion issue exists in g_dbus_node_info_new_for_xml() in the gio/gdbusintrospection.c file when processing malformed D-Bus introspection XML, specifically with a `node` element nested within other elements like `method`, `signal`, `property` or `arg`. This issue can cause an unsigned integer overflow and lead to an out-of-bounds read, resulting in a denial of service.
🎖@cveNotify
A flaw was found in GLib. A state confusion issue exists in g_dbus_node_info_new_for_xml() in the gio/gdbusintrospection.c file when processing malformed D-Bus introspection XML, specifically with a `node` element nested within other elements like `method`, `signal`, `property` or `arg`. This issue can cause an unsigned integer overflow and lead to an out-of-bounds read, resulting in a denial of service.
🎖@cveNotify
🚨 CVE-2026-10652
Zephyr's DNS resolver (subsys/net/lib/dns) parses resource records from DNS responses in dns_unpack_answer(), which validated only the fixed RR header (type, class, TTL, rdlength) and accepted any attacker-declared rdlength, including one extending past the end of the received datagram. The TXT and SRV consumers in dns_validate_record() (resolve.c) then read up to rdlength bytes (clamped only to a record-type maximum such as DNS_MAX_TEXT_SIZE, default 64, not to the packet) from the receive buffer via memcpy without their own bounds check, and pass the result to the application's resolve callback. A malicious or spoofed DNS server, an on-path attacker forging UDP DNS replies, or (with mDNS/LLMNR enabled) any LAN node can craft a truncated TXT or SRV response that causes an out-of-bounds read of adjacent receive-pool memory; the disclosed stale bytes (residual contents of prior DNS packets / uninitialized pool memory) are returned to the application as TXT/SRV record contents, an information leak, and may in some configurations cross the allocation boundary and fault, causing a denial of service. The read is bounded (~64 bytes for TXT, ~6 for SRV) and read-only (no write). The fix rejects any record whose declared rdata extends past dns_msg->msg_size at the single chokepoint in dns_unpack_answer(). Affected: v4.3.0 and v4.4.0.
🎖@cveNotify
Zephyr's DNS resolver (subsys/net/lib/dns) parses resource records from DNS responses in dns_unpack_answer(), which validated only the fixed RR header (type, class, TTL, rdlength) and accepted any attacker-declared rdlength, including one extending past the end of the received datagram. The TXT and SRV consumers in dns_validate_record() (resolve.c) then read up to rdlength bytes (clamped only to a record-type maximum such as DNS_MAX_TEXT_SIZE, default 64, not to the packet) from the receive buffer via memcpy without their own bounds check, and pass the result to the application's resolve callback. A malicious or spoofed DNS server, an on-path attacker forging UDP DNS replies, or (with mDNS/LLMNR enabled) any LAN node can craft a truncated TXT or SRV response that causes an out-of-bounds read of adjacent receive-pool memory; the disclosed stale bytes (residual contents of prior DNS packets / uninitialized pool memory) are returned to the application as TXT/SRV record contents, an information leak, and may in some configurations cross the allocation boundary and fault, causing a denial of service. The read is bounded (~64 bytes for TXT, ~6 for SRV) and read-only (no write). The fix rejects any record whose declared rdata extends past dns_msg->msg_size at the single chokepoint in dns_unpack_answer(). Affected: v4.3.0 and v4.4.0.
🎖@cveNotify
GitHub
net: dns: validate rdata length in dns_unpack_answer · zephyrproject-rtos/zephyr@58b46c8
dns_unpack_answer() validated only the fixed RR header size and
accepted any rdlength, even one extending past the end of the packet.
TXT and SRV consumers in resolve.c then read up to rdlength byt...
accepted any rdlength, even one extending past the end of the packet.
TXT and SRV consumers in resolve.c then read up to rdlength byt...
🚨 CVE-2026-10653
The Zephyr net_buf library (lib/net_buf/buf.c) manipulated both of its reference counts -- the per-header buf->ref and the per-data-block ref_count at the start of each variable/heap data allocation -- with plain non-atomic C operators (buf->ref++, if (--buf->ref > 0), if (--(*ref_count))).
The API is documented as self-synchronizing: callers may share one buffer across threads (e.g. via k_fifo) and each holder independently calls net_buf_unref() with no surrounding lock. Under true concurrency (SMP, or single-core preemption between the non-atomic load and store while another context unrefs the same buffer), two holders can both observe the same prior reference value and both conclude they are the last reference.
For heap/variable-data pools (mem_pool_data_unref/heap_data_unref, used by zbus message subscribers, the IP stack RX/TX buffers when CONFIG_NET_BUF_FIXED_DATA_SIZE=n, capture, wireguard, ISO-TP and usbip) this produces a double k_heap_free()/k_free() of the same block -- heap-metadata corruption and a use-after-free on the heap-hardening poison pattern.
For the per-header refcount the buffer is returned to the pool free LIFO twice for any pool type (including fixed-data pools used by Bluetooth and networking), corrupting the free list so a later allocation hands the same buffer to two owners.
The fix converts both refcounts to atomic_inc/atomic_dec (overlaying buf->ref in an atomic_t-sized union and changing the data-block refcount from uint8_t to atomic_t).
Impact is gated on genuine concurrency and on an application architecture that shares one buffer among multiple independent unref'ers; the trigger is a refcount/timing race rather than packet content, so an external attacker has at most weak indirect influence over the race window. Affects all Zephyr releases through v4.4.0.
This fix is not being backported to v3.7-branch (LTS). The backport was attempted and closed unmerged (#111181): the v3.7 networking tree has diverged from main, and the new atomic word-packing -- together with the assertions it adds -- turns pre-existing v3.7-only reference-counting defects elsewhere in the stack into hard faults, so landing the change faithfully would mean pulling an open-ended set of additional v3.7-only fixes into an LTS branch. v3.7 remains affected. Applications on v3.7 that share one net_buf across threads should serialize their own net_buf_unref() calls rather than rely on the documented self-synchronizing behaviour. The fix is on main and has been backported to v4.3-branch (#110852) and v4.4-branch (#110853).
🎖@cveNotify
The Zephyr net_buf library (lib/net_buf/buf.c) manipulated both of its reference counts -- the per-header buf->ref and the per-data-block ref_count at the start of each variable/heap data allocation -- with plain non-atomic C operators (buf->ref++, if (--buf->ref > 0), if (--(*ref_count))).
The API is documented as self-synchronizing: callers may share one buffer across threads (e.g. via k_fifo) and each holder independently calls net_buf_unref() with no surrounding lock. Under true concurrency (SMP, or single-core preemption between the non-atomic load and store while another context unrefs the same buffer), two holders can both observe the same prior reference value and both conclude they are the last reference.
For heap/variable-data pools (mem_pool_data_unref/heap_data_unref, used by zbus message subscribers, the IP stack RX/TX buffers when CONFIG_NET_BUF_FIXED_DATA_SIZE=n, capture, wireguard, ISO-TP and usbip) this produces a double k_heap_free()/k_free() of the same block -- heap-metadata corruption and a use-after-free on the heap-hardening poison pattern.
For the per-header refcount the buffer is returned to the pool free LIFO twice for any pool type (including fixed-data pools used by Bluetooth and networking), corrupting the free list so a later allocation hands the same buffer to two owners.
The fix converts both refcounts to atomic_inc/atomic_dec (overlaying buf->ref in an atomic_t-sized union and changing the data-block refcount from uint8_t to atomic_t).
Impact is gated on genuine concurrency and on an application architecture that shares one buffer among multiple independent unref'ers; the trigger is a refcount/timing race rather than packet content, so an external attacker has at most weak indirect influence over the race window. Affects all Zephyr releases through v4.4.0.
This fix is not being backported to v3.7-branch (LTS). The backport was attempted and closed unmerged (#111181): the v3.7 networking tree has diverged from main, and the new atomic word-packing -- together with the assertions it adds -- turns pre-existing v3.7-only reference-counting defects elsewhere in the stack into hard faults, so landing the change faithfully would mean pulling an open-ended set of additional v3.7-only fixes into an LTS branch. v3.7 remains affected. Applications on v3.7 that share one net_buf across threads should serialize their own net_buf_unref() calls rather than rely on the documented self-synchronizing behaviour. The fix is on main and has been backported to v4.3-branch (#110852) and v4.4-branch (#110853).
🎖@cveNotify
GitHub
net_buf: make reference counts atomic · zephyrproject-rtos/zephyr@9bb2878
The two reference counts in the net_buf library -- the per-header
`buf->ref` and the per-data-block `*ref_count` byte at the start of
each variable-data allocation -- were manipulated with p...
`buf->ref` and the per-data-block `*ref_count` byte at the start of
each variable-data allocation -- were manipulated with p...
🚨 CVE-2026-11714
IBM WebSphere Application Server Liberty is affected by a server-side request forgery vulnerability with the apiDiscovery-1.0 feature enabled.
🎖@cveNotify
IBM WebSphere Application Server Liberty is affected by a server-side request forgery vulnerability with the apiDiscovery-1.0 feature enabled.
🎖@cveNotify
Ibm
Security Bulletin: IBM WebSphere Application Server Liberty is affected by an authorization bypass vulnerability (CVE-2026-11714)
IBM WebSphere Application Server Liberty is affected by an authorization bypass vulnerability with the apiDiscovery-1.0 feature enabled.
🚨 CVE-2026-55688
The AsyncHttpClient (AHC) library allows Java applications to easily execute HTTP requests and asynchronously process HTTP responses. In versions from 2.0.0 prior to 2.16.0 and from 3.0.0.Beta1 prior to 3.0.11, ThreadSafeCookieStore stored a cookie under the value of its Domain attribute without verifying that the responding host is allowed to set a cookie for that domain, leading to a cookie tossing / cookie injection issue. A host the client connects to can therefore plant a cookie scoped to an unrelated domain, and the client will then send that cookie on later requests to that domain. Applications that use a single AsyncHttpClient instance - and thus the default, shared CookieStore - to reach both an attacker-influenced host and a trusted host are impacted. This issue has been fixed in versions 2.16.0 and 3.0.11.
🎖@cveNotify
The AsyncHttpClient (AHC) library allows Java applications to easily execute HTTP requests and asynchronously process HTTP responses. In versions from 2.0.0 prior to 2.16.0 and from 3.0.0.Beta1 prior to 3.0.11, ThreadSafeCookieStore stored a cookie under the value of its Domain attribute without verifying that the responding host is allowed to set a cookie for that domain, leading to a cookie tossing / cookie injection issue. A host the client connects to can therefore plant a cookie scoped to an unrelated domain, and the client will then send that cookie on later requests to that domain. Applications that use a single AsyncHttpClient instance - and thus the default, shared CookieStore - to reach both an attacker-influenced host and a trusted host are impacted. This issue has been fixed in versions 2.16.0 and 3.0.11.
🎖@cveNotify
GitHub
reject set-cookie domain that doesn't match the request host by jmestwa-coder · Pull Request #2196 · AsyncHttpClient/async-http…
ThreadSafeCookieStore stores a cookie under its Domain attribute without checking the response host is allowed to set it (rfc6265 5.3 step 6), so a host can plant cookies for unrelated domains:
a ...
a ...
🚨 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-48000
Adobe Commerce is affected by an Improper Redirect (Open Redirect) vulnerability that could result in a Security feature bypass. An attacker could construct a malicious URL that redirects a victim to an attacker-controlled site. Exploitation of this issue requires user interaction in that a victim must click on a malicious link. Scope is changed.
🎖@cveNotify
Adobe Commerce is affected by an Improper Redirect (Open Redirect) vulnerability that could result in a Security feature bypass. An attacker could construct a malicious URL that redirects a victim to an attacker-controlled site. Exploitation of this issue requires user interaction in that a victim must click on a malicious link. Scope is changed.
🎖@cveNotify
Adobe
Adobe Security Bulletin
Security Updates Available for Adobe Commerce | APSB26-73
🚨 CVE-2026-5674
A flaw was found in PipeWire, a multimedia server. This vulnerability allows an attacker to escape sandboxed applications, such as Flatpak, by exploiting PipeWire's PulseAudio compatibility layer. An attacker with minimal permissions within a sandboxed environment can load a malicious library, leading to arbitrary code execution outside the sandbox and potential compromise of the user's system.
🎖@cveNotify
A flaw was found in PipeWire, a multimedia server. This vulnerability allows an attacker to escape sandboxed applications, such as Flatpak, by exploiting PipeWire's PulseAudio compatibility layer. An attacker with minimal permissions within a sandboxed environment can load a malicious library, leading to arbitrary code execution outside the sandbox and potential compromise of the user's system.
🎖@cveNotify
🚨 CVE-2026-21655
Deserialization of untrusted data vulnerability in Johnson Control victor on Windows, Johnson Controls CCure 9000, and Johnson Controls Victor Application Server allows capec-586.
This issue affects victor: before 8.0; CCure 9000: before 3.2; Victor Application Server: before 4.1.
🎖@cveNotify
Deserialization of untrusted data vulnerability in Johnson Control victor on Windows, Johnson Controls CCure 9000, and Johnson Controls Victor Application Server allows capec-586.
This issue affects victor: before 8.0; CCure 9000: before 3.2; Victor Application Server: before 4.1.
🎖@cveNotify
Johnsoncontrols
Security Advisories
Check out the listed Security Advisories (SA) about identified security vulnerabilities in Johnson Controls' products and the mitigation measures taken.
🚨 CVE-2026-15325
IBM WebSphere Application Server and IBM WebSphere Application Server - Liberty is vulnerable to HTTP request smuggling due to improper handling of TRACE requests.
🎖@cveNotify
IBM WebSphere Application Server and IBM WebSphere Application Server - Liberty is vulnerable to HTTP request smuggling due to improper handling of TRACE requests.
🎖@cveNotify
Ibm
Security Bulletin: IBM WebSphere Application Server and WebSphere Application Server Liberty are affected by multiple vulnerabilities
IBM WebSphere Application Server and WebSphere Application Server Liberty are affected by a denial of service, HTTP Response and Request Smuggling vulnerabilities when servlet-3.0, servlet-3.1, servlet-4.0, servlet-5.0, servlet-6.0, or servlet-6.1 is enabled.
🚨 CVE-2026-65321
PyAthena prior to 3.35.4 contains a sql injection vulnerability that allows unauthenticated attackers to inject arbitrary SQL by exploiting improper quote-escaping in DefaultParameterFormatter.format(), which routes DELETE and CTAS statements to the _escape_hive function that backslash-escapes single quotes rather than doubling them. Because Athena and Trino do not treat backslashes as escape characters inside string literals, attacker-supplied input such as a single quote followed by SQL syntax causes the parser to terminate the string literal prematurely, enabling data exfiltration via UNION SELECT, execution of destructive statements, and attacker-controlled CTAS destination and content.
🎖@cveNotify
PyAthena prior to 3.35.4 contains a sql injection vulnerability that allows unauthenticated attackers to inject arbitrary SQL by exploiting improper quote-escaping in DefaultParameterFormatter.format(), which routes DELETE and CTAS statements to the _escape_hive function that backslash-escapes single quotes rather than doubling them. Because Athena and Trino do not treat backslashes as escape characters inside string literals, attacker-supplied input such as a single quote followed by SQL syntax causes the parser to terminate the string literal prematurely, enabling data exfiltration via UNION SELECT, execution of destructive statements, and attacker-controlled CTAS destination and content.
🎖@cveNotify
GitHub
GitHub - pyathena-dev/PyAthena: PyAthena is a Python DB API 2.0 (PEP 249) client for Amazon Athena.
PyAthena is a Python DB API 2.0 (PEP 249) client for Amazon Athena. - pyathena-dev/PyAthena
🚨 CVE-2026-51190
The "s init" command in Serverless-Devs @serverless-devs/s <= 3.1.11 passes unsanitized user input to child_process.spawn() with shell: true. A URL ending in ".git" bypasses the only input check, allowing OS command injection when a user runs "s init" with an attacker-controlled argument.
🎖@cveNotify
The "s init" command in Serverless-Devs @serverless-devs/s <= 3.1.11 passes unsanitized user input to child_process.spawn() with shell: true. A URL ending in ".git" bypasses the only input check, allowing OS command injection when a user runs "s init" with an attacker-controlled argument.
🎖@cveNotify
Gist
Vulnerability Report for Command Injection in `s init` via `shell: true` in spawn
Vulnerability Report for Command Injection in `s init` via `shell: true` in spawn - vul-report.md
🚨 CVE-2026-51775
SQL injection vulnerability in Fastadmin v.1.6.1.20250430 allows an attacker to exectue arbitrary code via the application/common/controller/Backend.php component
🎖@cveNotify
SQL injection vulnerability in Fastadmin v.1.6.1.20250430 allows an attacker to exectue arbitrary code via the application/common/controller/Backend.php component
🎖@cveNotify
Gitee
Tor/security-advisory:
🚨 CVE-2026-52102
An OS command injection vulnerability in the openmediavault-md plugin of OpenMediaVault v8.0.4-1 allows attackers to execute arbitrary commands as root via injecting shell metacharacters.
🎖@cveNotify
An OS command injection vulnerability in the openmediavault-md plugin of OpenMediaVault v8.0.4-1 allows attackers to execute arbitrary commands as root via injecting shell metacharacters.
🎖@cveNotify
Gist
CVE-2026-52102 Advisory
CVE-2026-52102 Advisory. GitHub Gist: instantly share code, notes, and snippets.
🚨 CVE-2026-67969
An issue in the HS_MonitorApplications() component of NASA cFS v7.0.1 allows attackers to force the processor to reset via supplying a crafted HS.AppMon_Tbl entry.
🎖@cveNotify
An issue in the HS_MonitorApplications() component of NASA cFS v7.0.1 allows attackers to force the processor to reset via supplying a crafted HS.AppMon_Tbl entry.
🎖@cveNotify
GitHub
GitHub - nasa/cFS: The Core Flight System (cFS)
The Core Flight System (cFS). Contribute to nasa/cFS development by creating an account on GitHub.
🚨 CVE-2026-67970
Incorrect access control in the DS_SetDestPathCmd() component of NASA cFS v7.0.1 allows attackers to access sensitive components via a path traversal.
🎖@cveNotify
Incorrect access control in the DS_SetDestPathCmd() component of NASA cFS v7.0.1 allows attackers to access sensitive components via a path traversal.
🎖@cveNotify
GitHub
[SECURITY] DS basename field allows path traversal without modifying pathname · Issue #1072 · nasa/cFS
Checklist (Please check before submitting) I reviewed the Contributing Guide. I performed a cursory search to see if the bug report is relevant, not redundant, nor in conflict with other tickets. D...
🚨 CVE-2026-67974
A parser boundary flaw in the Software Bus Network (SBN) application's peer subscription message handling in NASA cFS v7.0.1 allows attackers to cause a Denial of Service (DoS) via sending a crafted packet.
🎖@cveNotify
A parser boundary flaw in the Software Bus Network (SBN) application's peer subscription message handling in NASA cFS v7.0.1 allows attackers to cause a Denial of Service (DoS) via sending a crafted packet.
🎖@cveNotify
GitHub
GitHub - nasa/cFS: The Core Flight System (cFS)
The Core Flight System (cFS). Contribute to nasa/cFS development by creating an account on GitHub.
🚨 CVE-2026-67975
Incorrect access control in NASA cFS v7.0.1 allows attackers to arbitrarily remove low-index subscriptions and add new streams via sending TO_LAB add/remove subscription commands.
🎖@cveNotify
Incorrect access control in NASA cFS v7.0.1 allows attackers to arbitrarily remove low-index subscriptions and add new streams via sending TO_LAB add/remove subscription commands.
🎖@cveNotify
GitHub
GitHub - nasa/cFS: The Core Flight System (cFS)
The Core Flight System (cFS). Contribute to nasa/cFS development by creating an account on GitHub.
🚨 CVE-2026-64564
In the Linux kernel, the following vulnerability has been resolved:
sctp: don't free the ASCONF's own transport in DEL-IP processing
sctp_process_asconf() caches the transport the ASCONF chunk is processed
against in asconf->transport (== chunk->transport, set once in sctp_rcv()).
For an ASCONF located through its Address Parameter by
__sctp_rcv_asconf_lookup(), that cached transport corresponds to the
Address Parameter, which need not be the packet's source address.
sctp_process_asconf_param() rejects a DEL-IP for the packet source address
(ADDIP D8, SCTP_ERROR_DEL_SRC_IP), but nothing protects asconf->transport.
A single ASCONF can therefore carry, in order:
[Address Parameter L] [DEL-IP L] [DEL-IP 0.0.0.0]
where L differs from the source. The DEL-IP for L passes the D8 check and
calls sctp_assoc_rm_peer() on the transport that asconf->transport still
points at, freeing it (RCU-deferred). The following wildcard DEL-IP then
reuses the now-dangling asconf->transport in sctp_assoc_set_primary() and
sctp_assoc_del_nonprimary_peers(): set_primary() dereferences the freed
transport (->ipaddr, ->state) and plants the dangling pointer into
asoc->peer.primary_path / active_path, and del_nonprimary_peers(), keeping
only the pointer that is no longer on the list, removes every real
transport, leaving the association with a transport_count of 0 and
primary_path/active_path pointing at freed memory.
Reject a DEL-IP that targets the transport the ASCONF is being processed
against, mirroring the existing source-address guard, so the wildcard
branch can never reuse a freed transport.
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
sctp: don't free the ASCONF's own transport in DEL-IP processing
sctp_process_asconf() caches the transport the ASCONF chunk is processed
against in asconf->transport (== chunk->transport, set once in sctp_rcv()).
For an ASCONF located through its Address Parameter by
__sctp_rcv_asconf_lookup(), that cached transport corresponds to the
Address Parameter, which need not be the packet's source address.
sctp_process_asconf_param() rejects a DEL-IP for the packet source address
(ADDIP D8, SCTP_ERROR_DEL_SRC_IP), but nothing protects asconf->transport.
A single ASCONF can therefore carry, in order:
[Address Parameter L] [DEL-IP L] [DEL-IP 0.0.0.0]
where L differs from the source. The DEL-IP for L passes the D8 check and
calls sctp_assoc_rm_peer() on the transport that asconf->transport still
points at, freeing it (RCU-deferred). The following wildcard DEL-IP then
reuses the now-dangling asconf->transport in sctp_assoc_set_primary() and
sctp_assoc_del_nonprimary_peers(): set_primary() dereferences the freed
transport (->ipaddr, ->state) and plants the dangling pointer into
asoc->peer.primary_path / active_path, and del_nonprimary_peers(), keeping
only the pointer that is no longer on the list, removes every real
transport, leaving the association with a transport_count of 0 and
primary_path/active_path pointing at freed memory.
Reject a DEL-IP that targets the transport the ASCONF is being processed
against, mirroring the existing source-address guard, so the wildcard
branch can never reuse a freed transport.
🎖@cveNotify
🚨 CVE-2026-67551
pre-authentication attacker could leverage type size/count handling to cause excessive allocation leading to potential denial of service.
This issue affects Apache Qpid Proton-Dotnet: through 1.0.0.
Users are recommended to upgrade to version 1.1.0, which fixes the issue.
🎖@cveNotify
pre-authentication attacker could leverage type size/count handling to cause excessive allocation leading to potential denial of service.
This issue affects Apache Qpid Proton-Dotnet: through 1.0.0.
Users are recommended to upgrade to version 1.1.0, which fixes the issue.
🎖@cveNotify