CVE-2026-55717
NULL Pointer Dereference: Is CVE-2026-55717 real, exploitable, or a false positive? Here's the community verdict.
signals
public sources
Moderate signals. Triage by your actual exposure and reachability.
baseline read
auto · not a community verdict
Low signal — verdict needed
Few public signals point to active risk. Whether a scanner hit here is a true or false positive depends on your version and config — community verdicts decide.
Based on CVSS
Confirm or dispute →CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
In NLnet Labs Unbound 1.10.0 up to and including 1.25.1, when 'serve-expired: yes' is set together with a 'response-ip: <net> redirect' /'response-ip-data: <net> CNAME <target>' rule (or the RPZ 'rpz-cname-override' equivalent), a remote client who controls any delegated domain can crash the daemon. The serve-expired-client-timeout callback runs a two-pass loop to chase the respip-generated CNAME alias; on the second pass it resets 'alias_rrset' but not 'partial_rep'. Later, this inconsistency leads to a NULL pointer dereference and an eventual crash. A malicious actor can exploit the vulnerability by controlling any zone that replies with an A/AAAA record that falls inside the configured response-ip/rpz subnet. By delaying the answer when the previous record has expired, the vulnerable path of 'serve-expired-client-timeout' is taken leading to denial of service via the server crash.
References
Published
Embed this verdict
[](https://www.truepositive.app/cve/CVE-2026-55717)<a href="https://www.truepositive.app/cve/CVE-2026-55717"><img src="https://www.truepositive.app/cve/CVE-2026-55717/badge.svg" alt="TruePositive verdict for CVE-2026-55717"></a>Live badge that updates automatically as the community verdict changes.
Community ground truth
Be the first practitioner to weigh in
So far this is only TruePositive's editorial baseline from public sources. Add your real-world verdict below — it becomes the signal the next person triaging this relies on.
🥇 The first 50 practitioners to contribute earn a Founding Contributor badge.
In your experience, is this finding real and exploitable?
awaiting field verdictsNo account needed. Anonymous verdicts post as an unverified signal. Log in to make yours verified and earn reputation.
Field notes & remediation
Verdicts are the quick signal. Notes are the evidence and fixes behind them.
No notes yet. Be the first to share what you saw, or a fix that worked.
Add a field note or remediationoptional
Related CVEs
Same weakness: CWE-476 · NULL Pointer Dereference.
- CVE-2026-10678HIGH 8.1Disputed
The MCTP-over-I2C+GPIO target binding in Zephyr (subsys/pmci/mctp/mctp_i2c_gpio_target.c) processes pseudo-register writes from an I2C bus master byte-by-byte in mctp_i2c_gpio_target_write_received() without validating the order or the receive buffer. In the affected versions the MCTP_I2C_GPIO_RX_MSG_ADDR (data) handler dereferences and writes through b->rx_pkt without checking that the receive buffer was allocated: a controller that selects the data register and writes a byte without first sending the length register (which is what allocates the buffer) causes a write of an attacker-chosen byte through a NULL/unallocated mctp_pktbuf pointer (i.e. into a small attacker-advanceable offset above address 0), producing memory corruption or a hard fault. The same handler also performs a write-then-check bounds test, allowing a one-byte heap overflow at data[255] when more than 255 data bytes are sent. Because the I2C target callback is invoked with raw bytes supplied by whatever device is the bus master and the binding performs no authentication, a malicious or malfunctioning controller on the bus can trigger these without any prior protocol state, leading to memory corruption and/or denial of service on the target device. The vulnerable code was introduced when the I2C+GPIO target binding was added and shipped in Zephyr v4.3.0 and v4.4.0. The fix defers allocation to the first data byte with a NULL check, treats a missing length as a zero-sized packet rejected by libmctp, and moves the bounds check before the store.
- CVE-2025-59606HIGH 7.8
Memory Corruption when writing to invalid memory locations occurs due to heap memory exhaustion during secure data initialization.
- CVE-2025-59604HIGH 7.8
Memory Corruption when running a memory copy operation due to invalid writes caused by a null pointer.
- CVE-2026-50315HIGH 7.8
Null pointer dereference in Windows Image Acquisition allows an authorized attacker to elevate privileges locally.
- CVE-2026-37226HIGH 7.5
FlexRIC v2.0.0 crashes when the iApp receives an E42_RIC_SUBSCRIPTION_REQUEST referencing a non-existent E2 Node. The lookup function returns NULL, which is enforced by assert() in Debug builds (SIGABRT) and dereferenced in Release builds (SIGSEGV). A remote unauthenticated attacker can crash the iApp process (port 36422) by sending a subscription request with an arbitrary global_e2_node_id.
- CVE-2026-37230HIGH 7.5
FlexRIC v2.0.0 crashes when the near-RT RIC receives a RIC_INDICATION message with a ran_func_id that does not exist in its registry. The lookup returns NULL, triggering assert() in Debug builds (SIGABRT) or NULL pointer dereference in Release builds (SIGSEGV). A remote unauthenticated attacker can crash the near-RT RIC (port 36421) by sending a crafted RIC_INDICATION with an arbitrary ran_func_id value.