25 May 2026
Finding My First Critical Real-World Vulnerabilities
Findings
A few weeks ago, my routine work led me to something I didn't expect: a chain of vulnerabilities in a third-party service, some of them critical, that had almost certainly been sitting in production for years.
This is a writeup of what I found, how I found it, and what it means.
How it started
Through my day-to-day work, I came across a third-party service that a partner was using in production. I started looking at the integration. The vendor had provided a technical document with the API details.
The production endpoint was in it. Publicly accessible. No authentication.
I opened the WSDL - the full API specification, listing every available method, every parameter, every return type. Also public. No auth.
That was enough to make me keep going.
What I found
WSDL and full API documentation publicly exposed
Both the development and production endpoints were accessible to anyone on the internet, with the full WSDL spec exposed. No credentials needed to read the complete technical documentation of the service.
The service also used tempuri.org as its XML namespace - Microsoft's default placeholder for .NET services during development. It was never changed for production. A small thing, but a clear signal the service was never hardened.
Note: To be fair, exposed API documentation isn't a vulnerability in itself, of course - for an open-source or developer-first company, publishing the full spec can be a deliberate and reasonable choice. What makes it count here is the context: combined with everything below, it's clear the exposure was accidental, not by design.
Partner impersonation with a company name in plain text
Every API call required a field identifying the calling partner. The expected value was the partner's name. Literally just the name, in plain text. No token, no signature, nothing to verify identity.
Anyone who knew, or guessed, a valid partner name could make API calls on their behalf.
IDOR on purchase carts
The endpoint for retrieving purchase cart data accepted a cart ID. These IDs were sequential.
With no authentication and predictable IDs, the carts were trivially enumerable: a simple loop over sequential values would return cart data from transactions other than one's own, including event IDs and other metadata belonging to real users.
Cancel any reservation without authentication
There was an endpoint to cancel reservations. It took a transaction ID. No authentication, no ownership check.
That meant any open reservation could be cancelled by anyone holding its ID.
Personal and billing data exposed without authentication
Another endpoint returned full billing records for any transaction ID:
- Legal name
- Physical address
- National tax ID
- Fiscal document identifiers
- Full itemised payment breakdown
No authentication. Sequential IDs. Fully enumerable.
Free tickets via unauthenticated payment confirmation
This was the most serious finding.
There was an endpoint to confirm a payment. Once called, it returned a valid ticket. It required two things: the partner name (covered above) and a transaction ID.
No payment token. No callback from a payment gateway. No cryptographic proof that any money had changed hands.
Against more than one event, the endpoint returned a successful response and a valid, redeemable ticket with no financial transaction behind it - for tickets worth 40, 80, 100, or even more euros.
How long had this been there?
I don't know exactly. But based on the structure of the service, the API versioning, and the nature of the misconfigurations, these weren't recent mistakes. This had almost certainly been running like this for years.
Disclosure
I documented the findings and reported them through my company's channels. The vendor was notified and has since remediated the issues.
A personal note
This is my first time finding and documenting truly critical real-world vulnerabilities with real business impact. The kind where someone could have gotten free tickets to any event, or accessed the personal data of thousands of users, or silently cancelled reservations at scale.
I'm grateful I caught them. And I'm aware that in a different context - with different intent - the impact could have been significant.
This is what security work actually looks like sometimes. Not a CTF, not a lab. Just paying attention to something that most people would have waved through.