IXP Manager CVE-2026-63338

Requires a valid authenticated IXP Manager account (CVSS PR:L); the attacker must be a logged-in user of the instance. No special feature flag or non-default configuration is needed - the vulnerable API-key edit/update path in ApiKeyController selects records by identifier without an ownership (user_id) check, so it is exploitable against default deployments of IXP Manager prior to v7.3.0. Exploitation is limited to instances that host more than one user account (i.e. where another user's API-key record exists to target) and by the need to know or enumerate the target record's identifier; a single-user or tightly controlled instance has little exposure. There is no fix other than upgrading to v7.3.0, which the vendor states should be applied as soon as possible.

This is a credible but not emergency-grade priority. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N) describes a network-reachable, low-complexity flaw requiring only a valid authenticated account (PR:L), with no user interaction - consistent with a broken object-level authorization (CWE-863) bug that any logged-in user can trigger. The vuln.today decision label is 'this_week' (not act_now/emergency), aligning with a serious-but-not-actively-exploited posture. There is no KEV listing, no EPSS score was supplied, and the three references are a GitHub Security Advisory, the fix commit, and the v7.3.0 release - none of which is working exploit code, so there is no public exploit identified at time of analysis. The flaw was found through INEX's own internal audit rather than observed attacks, reinforcing a targeted-insider risk profile rather than mass exploitation. One signal conflicts with the mechanism: the supplied vector rates A:H, but the advisory describes only unauthorized view/edit of another user's API-key record, which more naturally maps to credential disclosure and integrity impact than to high availability loss - verify the availability rating with the vendor. Net: patch to v7.3.0 this week, especially on multi-tenant instances with untrusted or numerous user accounts, but this is not a drop-everything network-unauthenticated RCE.

An authenticated low-privileged IXP Manager user invokes the API-key edit/update path in ApiKeyController, supplying the record identifier belonging to a different user; because the controller selects the record without confirming user_id matches the caller, the attacker can read and modify the victim's API-key record. Obtaining another user's API key enables impersonation of that user against the IXP Manager API. No public exploit is identified at time of analysis; the fix commit shows where the ownership check was added.