A €5,000 SQL injection in a SOAP integration

On May 19, 2026, I reported an unauthenticated SQL injection in an externally reachable SOAP integration. Four months later, the case closed with an Exceptional (10.0) rating and a €5,000 total bounty, shared with a collaborator.

The final remediation was to turn off the server. The company explained that it was no longer used, even though my testing had linked it to the main website’s production database.

Between discovery and resolution, one request appeared to stop working while another operation on the same server continued to expose the problem. Following up on those operations kept the investigation moving until the company retired the service.

At a glance

Reconnaissance: from an indexed IP to SOAP services

I started with a hostname search in Shodan, scoped to the company’s domain. That led me to an indexed IP address associated with the organization.

From there, I used shortscan for IIS short-name enumeration.

I followed that with ffuf and the iis.txt wordlist, looking for paths that shared a service-name prefix. This narrowed the search to the integration services that became the focus of the report.

When I visited those directory hits in the browser, they returned 403 Forbidden. I ran shortscan again inside one of the discovered directories, which revealed short-name hints for a service file.

The ASMX service name followed the same naming pattern as its parent directory. Opening that service brought up an operations index, which led me to the documentation for the email-change operation.

The discovery sequence was:

The company domain, IP address, and service-path prefix are redacted in this writeup. The discovery tools identified where to look; the subsequent application responses supplied the evidence for the SQL injection.

An integration service with database access

The ASMX service page listed the supported operations, including the email-change functionality I investigated.

The first finding involved an email-change operation exposed through a SOAP service. It accepted requests without credentials or a logged-in browser session.

SOAP was the transport layer: an XML envelope carried the operation and its input. The security issue appeared further down the request path, where that input influenced a database query.

Unexpected input produced Microsoft SQL Server parsing errors in the response, including an unclosed quotation-mark error. That was a useful signal, but a parsing error alone did not establish the extent of the issue.

I did not have the server-side source code. Unsafe construction of SQL statements was an inference from the responses, rather than something I confirmed by reading the implementation.

Building evidence beyond the first error

The report described several distinct observations: database parsing failures, changes in application behavior, and retrieval of limited database metadata. Together, those supported the SQL injection finding more strongly than an isolated error message.

The important distinction was between influencing a query and proving every possible consequence of that influence.

I reported limiting data collection to database metadata, a record count, and verification involving my own test account. I did not dump customer records.

My test-account check linked the integration to the main website’s production data. The count I reported was 12,904,334 rows—roughly 13 million records. That row count did not establish how many distinct users were represented.

The report discussed broader risks to customer information and possible data modification. Those were impact scenarios. The evidence I am presenting here supports unauthenticated query manipulation and database metadata disclosure; it does not demonstrate arbitrary modification, deletion, or access to every category of payment data.

Triage and follow-up evidence

Intigriti reproduced the finding on May 19 and passed it to the company. My test-account check also linked the exposed integration to data associated with the main website.

The follow-up evidence concerned a product-related operation on another SOAP service on the same server. This was a different operation from the initial email-change finding.

That distinction matters. A request being rejected, or one route no longer behaving as before, does not show that every affected operation on the server has been addressed. It also does not establish why the original request stopped working.

During the June review, triage asked for evidence beyond a syntax error. I supplied further database metadata evidence for the product operation. On June 4, triage confirmed reproduction and passed the evidence to the company. The program record listed the severity as Exceptional (10.0).

That was the program’s recorded rating. My initial assessment was CVSS 3.1 9.1.

The September retest

On September 22, the discussion resumed with the understanding that the issue had previously been solved. My retest notes showed that the product operation still exhibited the reported behavior.

The comparison was clear at the application level. A baseline request returned an empty result with a success status. Other controlled inputs led to a downstream-service exception or SQL Server parsing details, including fragments of the constructed query.

The September 24 notes also recorded that both the baseline and error responses used HTTP 200. The application-level status and response body carried the distinction. Watching the HTTP status alone would have hidden it.

The company then asked for a complete SOAP request to help reproduce the behavior. I supplied the request context alongside the baseline and observed response differences. No credentials or cookies were needed for those recorded tests.

The company accepted the report on September 24 and awarded the €5,000 total bounty.

Resolution: the server was retired

Later that day, the company explained that the server was no longer used and had been turned off. The report moved to Resolved.

That is the documented remediation for this case. I do not have a source-code patch to describe, and the report history does not establish that all of the affected query implementations were rewritten.

The outcome highlighted a service-lifecycle problem: a server could be unnecessary to the business and still remain reachable with a connection to production data. My test-account check and the reported count of roughly 13 million records made that access significant. Retirement removed the reported service from exposure.

Timeline

What I took from it

Make the evidence easy to evaluate. A database error is a starting point. The stronger report explains what changed, what the response establishes, and where the demonstrated impact stops. A complete request context also saves time when the reviewer is less familiar with the protocol.

Track operations individually during retesting. In this case, the original email-change finding and the later product-service evidence belonged to the same investigation, but they were different request paths. Keeping that distinction visible made the remediation discussion more precise.

For an integration that needs to remain in service, the database defense is to bind user values through parameterized queries and restrict the application’s database permissions. Those are established recommendations in the OWASP SQL Injection Prevention Cheat Sheet. Detailed database exceptions should also stay out of public responses, although hiding them alone would not fix unsafe query construction.

For this server, the company chose retirement. Keeping an accurate inventory of exposed integrations—and removing them when they are no longer needed—was the operational lesson behind the final resolution.

Thanks to my collaborator for helping with the case, and to the triage team and the company for working through the report and resolving the exposure.