P-Net before 1.0.4 does not check the number of MCR request blocks in a Connect request against the number of multicast communication relations that an Application Relationship has room for (PNET_MAX_MC_CR, 1 by default). Each further block is written past the end of the array, into the rest of the Application Relationship and, with more blocks, into the following one. The written data comes from the request. No established Application Relationship is needed, and the attacker requires ADJACENT network access. Builds with PNET_OPTION_MC_CR disabled are not affected.
Exploitation: none · Automatable: no · Technical impact: partial, assessed 2026-11-13. From CISA's Vulnrichment in the CVE List: whether it is exploited, whether exploiting it can be automated, and how much control it gives.
Show the promptExplain CVE-2026-127122 for an engineer deciding whether to act. Use https://cve.bz/api/public/cves/CVE-2026-127122?via=ask-ai-copy and https://cve.bz/cve/CVE-2026-127122?via=ask-ai-copy as the source of truth: what is affected and which versions fix it, whether it is in CISA KEV, public exploits, and its EPSS (an internet-wide 30-day estimate of exploitation activity, not a forecast for my systems). If they give no fixed versions, use the CVE record https://cveawg.mitre.org/api/cve/CVE-2026-127122 or the vendor advisory, not third-party mirrors. Tell me how to check whether I am affected and how to verify a fix. Cite the sources and say where they are uncertain.
Opens a third-party assistant; its answer is its own, not cve.bz's. The prompt holds only this CVE's id and public links.
Badge for a README or a site
An image that stays current: it is drawn from the data each time it is fetched (a host that proxies images, as GitHub does, may show its copy for a while). Markdown: