Missing authorization in Nexcess Event Tickets permits unauthorized actions

Missing Authorization vulnerability in Nexcess Event Tickets event-tickets allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Event Tickets: from n/a through <= 5.28.5.

• Nexcess Event Tickets, a WordPress plugin with package name event-tickets: the CNA record marks the custom-version range from n/a, represented in the structured data as 0, through <= 5.28.5 as affected.
• The change record marks 5.28.5.1 as unaffected, and Patchstack identifies that release as the patched version.
• The product's default_status is unaffected, but that default does not override the explicitly stated affected range.
• The record does not enumerate later or parallel release branches separately, so the status of unverified branches should not be inferred.

This is a CWE-862 missing-authorization flaw in which a plugin function does not properly enforce the access checks required for the requested action. Patchstack describes the weakness class as a missing authorization, authentication, or nonce check that can allow an unprivileged user to execute a higher-privileged action. The record identifies network reachability, no required authentication, and no user interaction. The public record does not disclose the affected endpoint, parameter, callback, nonce, or function. The exact action available to an attacker and the affected object scope therefore remain unknown.

• The vulnerable functionality is reachable over the network.
• The structured assessment identifies no required privileges, low attack complexity, and no user interaction.
• CISA enrichment records exploitation as none, and Patchstack describes the issue as unlikely to be exploited.
• The supplied record sets public_exploit to false, so no public exploit is identified in the available data. This does not prove that an unreported exploit cannot exist.

Successful exploitation could allow an unauthenticated remote user to perform an unauthorized action through the plugin. The assessed outcome is primarily an integrity impact with unchanged scope; the record does not indicate disclosure of confidential data or service unavailability. Because the endpoint and operation are not disclosed, it is not possible to determine whether the consequence is limited to plugin-managed data or could affect broader WordPress site state. Organisational consequences may include investigating unauthorized changes, validating affected data, and restoring configuration if an incident occurs.

• An unauthenticated Internet client may be able to perform an action that the plugin's access controls should restrict.
• Depending on the affected function, this could cause unauthorized changes to plugin-managed state, content, or configuration; the specific business object is not disclosed.
• Operational consequences could include untrusted data, recovery work, or investigation of actions that were not authorized.
• The available assessment indicates an integrity impact, but does not indicate a confidentiality or availability impact.

1. Update the plugin to 5.28.5.1, which the CNA record marks as unaffected and Patchstack identifies as the patched version.
2. Patchstack also recommends updating to 5.28.5.1 or later. For release branches not separately enumerated in the affected matrix, verify the status with the vendor rather than assuming that every branch is safe.
3. If updating is not possible, contact the hosting provider or the website developer for assistance, as Patchstack recommends.
4. The supplied record does not document a separate workaround. Do not treat endpoint hiding or broad permission changes as a substitute for the confirmed fix.

1. Inventory all WordPress sites running the plugin with slug event-tickets, including sites managed through hosting providers or centralized deployment platforms.
2. Check the installed plugin version and compare it with the affected and fixed boundaries listed in affected_summary and remediation.
3. Review audit, access, and security logs for unauthenticated requests involving the plugin's functionality, especially where unauthorized changes followed.
4. No endpoint, function name, or IOC is provided, so monitoring for unusual requests is a precaution rather than a confirmed indicator.
5. The absence of suspicious log entries does not establish safety; confirm exposure through inventory and version verification.