API Security Flaw Exposes Internal Invite UUIDs in Duplicate Invite Error Responses

A low-severity security vulnerability in the organization's invitation API allows internal invite identifiers to be exposed through error responses. When the system detects a duplicate invite attempt for an email address that already carries a pending invite within the same organization, the API returns the existing invite's UUID in the error payload. This UUID functions as the primary key in the org_invites database table, making it an internal identifier that callers should not normally access at this stage of the invite lifecycle. The intended channel for invitees to receive this identifier is through the email invitation link, not via programmatic error messages.

The affected endpoint handles invite creation across the platform. Its current implementation responds to duplicate invite attempts with a structured error that includes the `invite_id` field, exposing a resource identifier that was not designed for public disclosure at this point in the workflow. While admin-scoped invite management endpoints such as revoke and resend legitimately use this ID as an operational parameter, its premature exposure in error responses circumvents the intended access control boundary. The vulnerability raises the risk of resource enumeration, as a caller can learn valid internal invite identifiers through repeated API interactions, potentially enabling cross-referencing with other system endpoints.

Security reviewers note that combining the exposed UUID with other API functions could allow an attacker to correlate invite data across the platform. The issue carries a low severity rating, but it highlights a pattern where internal resource identifiers leak through error handling that assumes a trusted caller context. Fixing the response to omit the `invite_id` field or anonymizing it before transmission would align the API behavior with the principle of least privilege.