Analysis Summary

Researcher discovered a serious OData injection vulnerability in Microsoft’s Events platform that could expose personal information from two distinct backend databases: the Waitlist and the Event Registration list. The investigator started on the events.microsoft.com subdomain and enumerated API endpoints on msevents.microsoft.com. Early probes (for example, the /api/GetEvents and /api/GetEventCustomRegistrationFields endpoints) returned either only public event data or non-sensitive results and initially appeared to be dead ends, but further testing revealed a far more powerful injection point.

The breakthrough came at a POST endpoint, /api/CheckEventRegistration, which is meant to verify whether a given email is registered for a specific event. By injecting crafted OData payloads into the email and eventId parameters, the researcher discovered the endpoint actually performed two separate backend requests to different databases. With precise payloads they could direct queries at each database independently: one set of injections enumerated the entire Waitlist database and the reversed technique targeted the Event Registration database.

The two databases contained highly sensitive personally identifiable information. The Waitlist table included fullname, telephone1, address1_line1, company and email addresses many from government and corporate domains while the Event Registration list contained first and last names, phone numbers, company names, country and some custom fields such as Partner IDs and Tenant IDs. Because there were no rate limits on the vulnerable endpoint, an attacker could have scripted high-volume extraction of every record from both databases, greatly amplifying the potential impact.

After confirming the data exposure, the Researcher stopped active exploitation and responsibly reported the issue to Microsoft Security Response Center on July 23, 2025. Microsoft acknowledged the report and completed a patch by August 26, 2025. The case highlights three practical lessons: validate and sanitize OData inputs (and any query language inputs), enforce strict access controls and rate limiting on endpoints that touch user data, and monitor API behavior for unexpected multi-database queries.

Impact

• Information Disclosure
• Gain Access

Remediation

• Sanitize and validate all user inputs, especially in parameters like email and eventId, to prevent OData or SQL injection attacks.
• Implement parameterized queries instead of dynamic query construction to eliminate injection vulnerabilities.
• Apply strict access controls on API endpoints, ensuring only authorized requests can query or access sensitive databases.
• Enforce rate limiting and CAPTCHA mechanisms to prevent large-scale data enumeration or automated scraping.
• Segregate sensitive databases (e.g., registration and waitlist) to minimize cross-database exposure risks.
• Use detailed API logging and monitoring to detect abnormal query patterns or repeated failed injection attempts.
• Conduct regular vulnerability assessments and penetration tests on public-facing APIs and event management systems.
• Adopt a centralized API gateway that enforces security policies such as authentication, input validation, and request throttling.
• Review and restrict custom fields (like Partner ID or Tenant ID) to ensure sensitive identifiers aren’t exposed externally.