CVE-2026-52952
Is CVE-2026-52952 real, exploitable, or a false positive? Here's the community verdict.
signals
public sources
High CVSS base score, but low real-world exploitation probability (EPSS). Likely less urgent than the score implies.
baseline read
auto · not a community verdict
Officially disputed
The CVE record itself is disputed or rejected upstream — a strong candidate for a false positive in scanners. Confirm with a verdict.
Based on NVD record status
Confirm or dispute →CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
In the Linux kernel, the following vulnerability has been resolved: iommu: Fix WARN_ON in __iommu_group_set_domain_nofail() due to reset In __iommu_group_set_domain_internal(), concurrent domain attachments are rejected when any device in the group is recovering. This is necessary to fence concurrent attachments to a multi-device group where devices might share the same RID due to PCI DMA alias quirks, but triggers the WARN_ON in __iommu_group_set_domain_nofail(). Other IOMMU_SET_DOMAIN_MUST_SUCCEED callers in detach/teardown paths, such as __iommu_group_set_core_domain and __iommu_release_dma_ownership, should not be rejected, as the domain would be freed anyway in these nofail paths while group->domain is still pointing to it. So pci_dev_reset_iommu_done() could trigger a UAF when re-attaching group->domain. Honor the IOMMU_SET_DOMAIN_MUST_SUCCEED flag, allowing the callers through the group->recovery_cnt fence, so as to update the group->domain pointer. Instead add a gdev->blocked check in the device iteration loop, to prevent any concurrent per-device detachment.
References
Published
Embed this verdict
[](https://www.truepositive.app/cve/CVE-2026-52952)<a href="https://www.truepositive.app/cve/CVE-2026-52952"><img src="https://www.truepositive.app/cve/CVE-2026-52952/badge.svg" alt="TruePositive verdict for CVE-2026-52952"></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-617.
- CVE-2026-12617HIGH 7.5
The issue is unexpected program termination based on ordering and/or specific content in responses to queries for CNAME or DNAME, and A records. Specifically, if a client queries for a DNAME and A record below the DNAME to the resolver, and the authoritative server responds positively to the A query but delays the DNAME response and later responds negatively, `named` may quit unexpectedly. Or, if a client queries for a CNAME and A record for the same name to the resolver, and the authoritative server responds positively to the A query but delays the CNAME response and later responds with a self-referential CNAME, the same failure may occur. This issue affects BIND 9 versions 9.18.0 through 9.18.50, 9.20.0 through 9.20.24, 9.18.11-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.24-S1.
- CVE-2026-37233HIGH 7.5
FlexRIC v2.0.0 contains an authorization bypass in the iApp's xApp isolation mechanism. The equality function eq_xapp_ric_gen_id() in src/ric/iApp/xapp_ric_id.c compares m0->xapp_id against itself (m0->xapp_id) instead of the other argument (m1->xapp_id), effectively ignoring the xApp identity dimension. A malicious xApp connected to the iApp (port 36422) can delete any other xApp's subscriptions by sending an E42_RIC_SUBSCRIPTION_DELETE_REQUEST with a matching ric_gen_id. This breaks multi-tenant isolation in any deployment with multiple xApps sharing the same RIC.
- CVE-2026-37229HIGH 7.5
FlexRIC v2.0.0 contains a reachable assertion in e2ap_create_pdu() triggered when ASN.1 PER decoding fails. A remote unauthenticated attacker can send any non-PER byte sequence (e.g., a single 0x00 byte) over SCTP to the near-RT RIC (port 36421) or iApp (port 36422) to crash the process via SIGABRT. The assertion is reached before any protocol-level validation occurs. All three E2AP protocol versions (v1.01, v2.03, v3.01) are affected.
- CVE-2026-37228HIGH 7.5
FlexRIC v2.0.0 contains a reachable assertion in e2ap_recv_sctp_msg() (src/lib/ep/e2ap_ep.c). The function allocates a fixed 32KB receive buffer and enforces assert(rc < len) on the sctp_recvmsg() return value. A remote unauthenticated attacker can send a single SCTP message with payload >= 32,768 bytes to crash the near-RT RIC, iApp, E2 Agent, or xApp process via SIGABRT. No valid E2AP PDU is required. All four SCTP endpoint types (ports 36421 and 36422) share this vulnerable code path. In Release builds (NDEBUG), the stripped assertion leads to a signed-to-unsigned integer overflow and potential out-of-bounds read.
- CVE-2026-45815HIGH 7.5
Reachable Assertion vulnerability in Apache NimBLE. A specially crafted ATT Read Multiple Variable Response (BLE_ATT_OP_READ_MULT_VAR_RSP) may trigger assert in ATT parser. Severity is medium as this requires DUT to first send ATT Read Multiple Variable Request. This issue affects Apache NimBLE: through 1.9.0. Users are recommended to upgrade to version 1.10.0, which fixes the issue.
- CVE-2026-13204HIGH 7.5
If a provably insecure domain is covered by both an NSEC and NSEC3 record at the parent, and there exist an RRSIG for only one of these types, then BIND may exit unexpectedly with an assertion while validating this proof. This issue affects BIND 9 versions 9.11.0 through 9.18.50, 9.20.0 through 9.20.24, 9.21.0 through 9.21.23, 9.11.3-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.24-S1.