Full Customer DB dump in Service Now and they called it “Medium Risk” — what a joke

If you haven’t connected with me on LinkedIn send me a request!

📌Here’s what I’ll cover:

1. Quick summary about the target and my recon methodology.
2. How I found the vulnerable site.
3. Exploiting the target
4. Findings, reports, and interaction with Service Now through HackerOne.

My automated recon:

1. Using my Subdomain Finder (Github) I created domains.txt and added the domains in scope:

2. I ran python3 mark.py and collected 6421 domains

With that attack surface, I decided to run a quick httpx scan using my automation of httpx ReconX, which simply does the following:

• HTTP Scanning: Uses httpx to probe domains and saves full output to httpx.dom.txt.
• Response Categorization: Extracts alive URLs (200), redirects (301/302), client errors (400s), and server errors (500s).
• Unique IPs: Extracts deduplicated IPs from httpx output.
• Port Scanning: Runs masscan on IPs for the top 100 ports and cleans results into an IP:PORT list.
• Vulnerability Detection: Scans alive URLs and IPs with nuclei for CVEs.
• Telegram Notifications: Sends a summary of results to a Telegram chat.

Want to try it out? check out the GitHub repo.

Alternatively, you can achieve the same results manually by running:

cat all_domains.txt | httpx -sc -ip -server -title -wc -o httpx.dom.txt

This generated a ton of data — time to dig in.

results from httpx

Finding the Vulnerable Site

While manually checking every url alive I stumbled upon an interesting URL that I will call:

ai_agent-servicenow.com

At first glance, I knew this shouldn’t have been public-facing. This was clearly an internal application, but for some reason, it was exposed to the internet.

After awhile, I realized it was a custom AI-Agent chatbot designed to interact with ServiceNow’s customer database — meaning real client data was at risk.

Step 1: Testing the Chatbot

On Monday, I attempted to interact with the chatbot and got a “Not Authorized” error, pretty weird…
By Wednesday, something had changed. Instead of the same error, I now saw:

1. A “Not Authorized User” popup.
2. A hardcoded SQL compilation error.

The SQL error was particularly interesting because it exposed internal database details, including:

• Table Name: Prod_All_DB.SMART_SEARCH_ACCOUNT_INDEX_ALL
• Column Name: ACCTNAME

Step 2: Exploiting the Chatbot

Even without authentication, I could interact with the chatbot and input queries. Most queries failed due to authentication restrictions, but every request still generated an actual SQL query in the backend.

The most concerning part?
The chatbot had a Modify Query option, allowing users to directly tweak the SQL queries it executed.

Full Database Dump — Prompt Injection Attack

After testing various queries and experimenting with prompt injections, I managed to dump the entire customer database.

I won’t disclose all the database columns here, but I was able to retrieve:

• Point of contact information
• Annual sales data
• Internal account scores
• Various operational metrics

What made this even funnier? I found all the information related to my own university — turns out, they use ServiceNow.

Now, here’s what’s really interesting:

• This application was designed to provide database content only to authenticated users.
• Through a prompt injection attack, I bypassed those safeguards and retrieved direct database queries.
• The vulnerability was trivially easy to exploit with minimal technical effort.
• A malicious actor could have enumerated additional data fields, potentially exposing PII (Personally Identifiable Information) and other sensitive data beyond what I tested.

Service Now’s Severity Rating: 5.3 (Medium)?!

After responsibly reporting this issue to Service Now, I was shocked to see them categorize it as a Medium (5.3) severity.

Let’s break this down:
✅ Accessing a confidential application without authentication — that alone is high severity.
✅ Extracting raw database content — that’s an information disclosure risk at the highest level.
✅ Potential exposure of PII and financial records — depending on the dataset, that could lead to GDPR or CCPA violations.
✅ Ease of exploitation — No complex exploitation was needed. A simple prompt injection led to a full database dump.

After a few back and forths with the program, they elevated the severity to a high (7.5)

At the end of the day, the fix matters more than the label. Whether they call it medium, high, or critical, the vulnerability existed, the data was exposed, and the system was at risk.

But let’s be honest, companies like ServiceNow rake in billions and still struggle to acknowledge critical flaws when reported by independent researchers. This isn’t the first time I’ve submitted a report to them they take it lightly. There’s a frustrating pattern with these massive corporations: they profit off security and compliance but often downplay real risks when they’re inconvenient.

A billion-dollar company should have no excuse for hesitating to classify an unauthenticated database dump as a severe issue. Yet, here we are, playing the same game, arguing over severity ratings while the next vulnerability waits in the shadows.

Jan 4th — Report submitted

Jan 15th — Status triaged and assigned severity medium (5.3)

Jan 28th — ServiceNow Disclosure Staff updated the severity from medium (5.3) to high (7.5)

Feb 26th — Issue seems fixed but the report is still open.

What’s the Takeaway?

• Simple Recon is King.
• Internal applications should never be exposed to the internet.
• AI-powered features interacting with databases need strict[er] access controls.
• Never trust user input, especially in AI-Agent systems!
• BBP and VDP programs still underestimate security risks.

I hope you enjoyed it! If you haven’t connected with me on LinkedIn send me a request!

Stay ethical, don’t do dumb stuff.