PULSE
EN VIVO14señales / 24h
EN
FEED
ransomspacebears reclama a StellarRAD Systems · US · Technologyransomaurora reclama a Bretford Manufacturing · US · Manufacturingransomgunra reclama a Weilhotel · MY · Hospitalityransomdeadlock reclama a AHENK lab · TR · Technologyransomqilin reclama a Hoc · GB · Not Foundransomblacknevas reclama a Speed Group · Transportationransomthegentlemen reclama a Buck Knives · US · Manufacturingransomcoinbasecartel reclama a Accesso · GB · Technologyransomchaos reclama a thecranewaregroup.com · GB · Technologyransomcmdorganization reclama a B-K Tool & Design · US · Manufacturingransomdeadlock reclama a DIATER · ES · Manufacturingransomdeadlock reclama a Pasello · Technologyransombooba project reclama a Oklahoma Manufacturing Alliance · US · Manufacturingransomakira reclama a Franz Krause artworksgroup · Otherransomspacebears reclama a StellarRAD Systems · US · Technologyransomaurora reclama a Bretford Manufacturing · US · Manufacturingransomgunra reclama a Weilhotel · MY · Hospitalityransomdeadlock reclama a AHENK lab · TR · Technologyransomqilin reclama a Hoc · GB · Not Foundransomblacknevas reclama a Speed Group · Transportationransomthegentlemen reclama a Buck Knives · US · Manufacturingransomcoinbasecartel reclama a Accesso · GB · Technologyransomchaos reclama a thecranewaregroup.com · GB · Technologyransomcmdorganization reclama a B-K Tool & Design · US · Manufacturingransomdeadlock reclama a DIATER · ES · Manufacturingransomdeadlock reclama a Pasello · Technologyransombooba project reclama a Oklahoma Manufacturing Alliance · US · Manufacturingransomakira reclama a Franz Krause artworksgroup · Other
← Todos los CVEs
CVE Watch22 jul 2026

CVE-2026-9831

A race condition in the shared Extreme Platform ONE IAM Gateway API-key authentication path could, under specific high-concurrency traffic c

CVSS

6.3

Medio

EPSS

0.2%

p7

KEV

—

Exploit Today

2

0-100

Publicado: 29 may 2026 · Última mod.: 22 jul 2026 · CWE-362 · CWE-488

EPSS · 30d
0.2%EPSS · 30 días0.2%
2026-06-302026-07-28
Descripción técnica

A race condition in the shared Extreme Platform ONE IAM Gateway API-key authentication path could, under specific high-concurrency traffic conditions, intermittently allow requests authenticated with an Extreme Platform ONE /IAM-issued API key to receive response data for another tenant. The issue was observed through ExtremeCloud IQ/XIQ API endpoints and validated against both XIQ/XAPI and Extreme Platform ONE /Common Services API paths. XIQ-native tokens and standard OAuth/Bearer JWT authentication were not affected.

Referencias oficiales
CVEs relacionados
CVECVSSEPSSKEVRExplotTítuloVis.
CVE-2026-1649810.0 CRÍ
—
——0The terraform-mcp-server before version 1.1.0 is vulnerable to a cross-tenant credential reuse issue in the streamable-HTTP stateless transport mode that may allow one user's Terraform token to be used to execute tool calls on behalf of subsequent users. This vulnerability, CVE-2026-16498, is fixed in terraform-mcp-server 1.1.0.18hCVE-2026-624366.5 MED
—
——0[This CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] With the introduction of Grant Table v2 came the requirement to be able to switch between versions. Switching from v1 to v2 reduces the number of valid grant references, as a bigger shared entry structure is then needed while the shared table doesn't change size. Switching from v2 back to v1 the status frames, which are separate in v2, go away. Code holding, but intermediately dropping and then re-acquiring the grant table lock, sometimes wrongly assumes that said properties wouldn't change across the window in time where the lock is not being held. The v1 -> v2 issue is CVE-2026-62435. The v2 -> v1 issue is CVE-2026-62436.21hCVE-2026-624356.5 MED
—
——0[This CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] With the introduction of Grant Table v2 came the requirement to be able to switch between versions. Switching from v1 to v2 reduces the number of valid grant references, as a bigger shared entry structure is then needed while the shared table doesn't change size. Switching from v2 back to v1 the status frames, which are separate in v2, go away. Code holding, but intermediately dropping and then re-acquiring the grant table lock, sometimes wrongly assumes that said properties wouldn't change across the window in time where the lock is not being held. The v1 -> v2 issue is CVE-2026-62435. The v2 -> v1 issue is CVE-2026-62436.21hCVE-2026-624327.3 ALT
—
——0The EVTCHNOP_expand_array hypercall checks for whether FIFO event channels are enabled, but without holding the correct lock. It can race with EVTCHNOP_reset, resulting in dereferencing a NULL pointer.21hCVE-2026-624307.5 ALT
—
——0Accesses to the CMOS memory contents are done using an indirect IO port pair. Therefore Xen needs to cache the guest chosen index, and one of the usages of the index didn't take the necessary locking to avoid concurrent changes. As a result, a guest could change the index after it being checked, causing a subsequent out-of-bound read access to the contents of an array.21hCVE-2026-624296.5 MED
—
——0Accessing the vNUMA configuration data of a guest is still possible when domain destruction has already started. The cleaning up of that configuration information is not synchronized with its retrieval by a device model controlling the guest.21h