Summary # I found a broken access control issue in the CoreEvent GraphQL API. Querying getOrder and getEvent exposes: Buyer PII (name, email, address) Ticket data (QR codes and barcodes) Full event accreditation datasets (10,000+ records) The server trusts any user-supplied ID without checking ownership or permissions. Impact # An attacker can: Access other users’ personal information Retrieve valid ticket QR codes and barcodes Dump entire event attendee datasets Enumerate orders and events at scale Example # In a single request, I retrieved ~10,968 accreditations, each containing: Barcode and QR code Seat/location info Ticket status Internal identifiers Ticket fraud, unauthorized entry, mass data scraping — all trivially possible from one request. Severity # Critical Classic API1: Broken Object Level Authorization (OWASP API Top 10). No per-resource authorization Sensitive data exposed (PII + ticketing) Single-request exploit 10,000+ records affected Technical Details # 1. IDOR via getOrder # This query returns order details for any user: query { getOrder (orderId: XXXXXX ) { id status buyer purchases { attendeeId accreditation { barcode qrcode status } } } } Response (redacted) # { "buyer" : { "fields" : { "email" : "..." , "firstName" : "..." , "lastName" : "..." , "Address" : "..." } }, "purchases" : [ { "attendeeId" : "..." , "accreditation" : { "barcode" : "..." , "qrcode" : "..." , "status" : "ALLOWED" } } ] } No ownership check. Any orderId works. Full PII and ticket data returned. 2. Mass data exposure via getEvent # query { getEvent (id: XXXX ) { accreditations { id status ticketLocation barcode } } } Full dataset — 10,000+ records — in a single unauthenticated request. 3. QR / barcode exposure # Ticket validation relies on barcode and qrcode . Both are returned in plaintext. Grab them, clone a ticket, walk in. 4. Enumeration # orderId and eventId appear sequential. Iterating through them is enough to collect data at scale. Root Cause # No server-side authorization on resolvers User-controlled input trusted without validation No ownership layer Schema too exposed Exploitation # Difficulty: low. Basic GraphQL knowledge and endpoint access is enough. No auth bypass, no special tooling. Proof of Concept # Option 1 – Event dump # Call getEvent(id) Extract accreditations Collect barcodes, seat info, status Option 2 – Order access # Call getOrder(orderId) Extract buyer PII and ticket QR codes Business Impact # Data exposure # Customer PII (GDPR relevant) Event attendance data Ticket validation data Financial # Ticket fraud via QR reuse Revenue loss Refund/support overhead Reputation # User trust loss Impact on event organizers Regulatory # GDPR exposure due to leaked personal data Mitigation # Required # Authorization checks on all resolvers Ownership verification on orders Role-based access for event data Remove or protect QR/barcode fields Rate limiting Recommended # Centralized access control layer for GraphQL Least privilege Schema exposure audit Timeline # Discovered: 2026-04-13 Reported: Yes Status: Initial response received, no follow-up Communication with CoreEvent # Reported through their official support channel. The initial report (translated from Croatian): Dear CoreEvent team, While using your platform, I identified a security vulnerability in the GraphQL API, specifically through queries like getOrder(orderId: ...) and getEvent(id: ...) . The issue is a missing authorization check, which allows fetching order and accreditation data without verifying ownership or access rights. For example, the following query: query { getOrder (orderId: XXXXXX ) { id status buyer purchases { attendeeId accreditation { barcode qrcode status } } } } returns data including the buyer’s personal information and ticket QR/barcode values. This allows: unauthorized access to user personal data (PII), retrieval and potential cloning of valid tickets (QR/barcode), mass collection of event attendee data through ID enumeration. Additionally, through getEvent(id: ...) it’s possible to retrieve a larger set of accreditations, potentially exposing a large number of records tied to a single event. I did not abuse the data or conduct mass testing — I focused solely on confirming the issue exists. I’m 19 years old and have been working in programming and web application security research for some time. I found this vulnerability out of curiosity while using the system, but further analysis confirmed it’s a serious access control issue (IDOR / Broken Access Control) that allows unauthorized access to other users’ data. I believe it’s important to report these things responsibly so they can be fixed in time. If helpful, I can describe the reproduction steps in more detail or provide additional technical examples. I’m reporting this in good faith without any expectations, but I would appreciate some form of acknowledgment for the time and effort invested — whether through feedback, collaboration, or another form of recognition...
The CoreEvent GraphQL API contains a critical Broken Object Level Authorization (BOLA/IDOR) vulnerability where unauthenticated queries to the `getOrder` and `getEvent` endpoints expose PII, ticket QR codes, and entire event datasets by trusting user-supplied IDs without ownership checks. An attacker can trivially enumerate sequential IDs to retrieve over 10,000 records per request, enabling data scraping, ticket fraud, and unauthorized event entry. The article recommends implementing authorization checks on all resolvers, adding ownership verification, and removing sensitive fields from unprotected responses, but it does not specify affected software versions or a CVSS score.