API keys are often described as machine credentials. That description hides the important question: what roles can the key assume, and who decides those roles? alf.io's release notes list CVE-2026-70663 as an API key role assignment issue in which key roles were not constrained to API-key roles.
The vendor note is brief, and the available primary material does not publish a full exploit chain, a CVSS vector, or a fixed version in the release summary. That is a reason to state the boundary precisely. The issue is an authorization-model defect in which a credential intended for API use could be assigned a role outside the set intended for API keys. The consequence depends on the roles available in the instance and the permissions attached to them.
alf.io is a ticket reservation and event-management system. Its administration surface can hold organizer accounts, event configuration, payment settings, attendee data, check-in workflows, and API integrations. An API key with an unintended role may therefore do more than create or read a ticket. It may reach the same objects and actions as the higher-privileged role it was assigned.
Why role ceilings matter
A role is usually a bundle of permissions. An API-key role should be a deliberate subset of the application's human roles, not an alias that can point to any administrator role. The key needs an explicit ceiling: event scope, organizer scope, read or write capability, check-in authority, and administrative functions.
When a key can be assigned an arbitrary role, the review problem moves from the key owner to the role editor. A user who cannot become an administrator through the normal UI may still create a key whose effective permissions exceed the user's own. The control should compare the requested role with both the caller's authority and the maximum allowed for the key type.
The same pattern appears in many ticketing systems. Organizers need broad control over their event, but they should not be able to create a key that manages every organizer or changes instance-wide payment settings. A key intended for a scanner should be able to validate a ticket without exporting attendee records.
Response for alf.io operators
Identify the alf.io release that contains the fix and upgrade to the vendor's current supported build. Do not infer a safe version from the CVE number. Review the release notes and repository advisory for the exact patched release, then verify the running container or package digest.
Inventory API keys by owner, event or organizer scope, role, creation date, last use, and purpose. Revoke keys that have no owner or no documented integration. Reissue keys after the upgrade where the old role was not clearly bounded. A key that was created before the fix should not remain trusted merely because the application is now patched.
Review the roles attached to API keys and compare them with the permissions available to human users. Look for keys with administrative roles, global scope, payment access, or export capabilities. Check the audit trail for role changes, event exports, refunds, and check-in events around the key's use.
Detection and ongoing controls
Log the key identifier, role, operation, event, source address, and result for every API call. Do not log the secret. Alert on a key using an operation outside its documented purpose, a role change followed by privilege expansion, or a key used from a new network at an unusual rate.
Build an approval path for new API keys. The requester should name the business integration, the event scope, the role ceiling, and the expected lifetime. The approver should verify that the role is exposed for API use and that the key cannot exceed the requester's own authority. Store the approval with the key metadata, not in a separate spreadsheet with no lifecycle.
The vendor's release notes also list CVE-2026-70664, an SSRF issue involving an unvalidated image URL in an admin event or subscription API. Do not merge the two findings into one mechanism. They do show why API administration needs more than a valid token: every field that causes a server-side fetch or role lookup must be checked against the intended authority.
The practical objective is not a broad promise that API keys are safe. It is a narrow, testable claim: this key can perform these actions on this event, and a role-editor bug cannot widen that set without a new approval.