Summary

While testing a public membership checkout, I found SQL injection behavior in the campaign-code field. A limited test also showed that the issue could be used to bypass payment during signup.

I stopped once the finding and its impact were clear. The operator is not named here, and I have left out the payload and reproduction details that would make the issue easier to misuse.

What I found

The checkout accepted campaign-code input that changed the database query behavior. The finding fits SQL injection, classified as CWE-89.

I did not have access to the application source, so I could not verify how the query was built internally. The report described the behavior I could reproduce from the checkout rather than guessing at the vendor's implementation.

Testing boundary

I tested only the campaign-code path needed to confirm the issue. No customer data was accessed or changed. I did not run automated scans, test unrelated endpoints, or attempt destructive database operations.

Once I had a repeatable result and understood the payment impact, more testing would only have added risk. It would not have made the report more useful.

Impact

The confirmed impact was a payment bypass in the membership checkout. That was enough to make the issue financially relevant without testing whether other database operations or data were reachable.

The public version of this case stays with that observed result. Broader attack scenarios were not tested and are not presented as findings.

Disclosure

On 22/05/26, I sent the report to the operator's data protection officer and relevant security contacts. It included a description of the issue, limited reproduction steps, the observed payment impact, and the boundaries of my testing.

The affected path was later patched.