The engagement

A SQL file reachable from the internet, and inside it a plain-text administrator token that opened a door into another entity of the same group.

From a directory sweep to full access without credentials

The work started by mapping the application with ffuf, a tool that walks a site trying names from a list in order to discover pages and folders that are not linked from anywhere. Among the results was a directory that had no business being there: http://client.example.com/database.

A publicly reachable folder called "database" is an alarm on its own, and inside it there was another one: /database/migrations/. Migration folders hold the files that create or update a database schema, which is internal project machinery. Finding them served by the web server means something that should only have existed on the developers’ side had ended up published on the internet.

The next step was to look for sensitive files inside that folder with an extension-driven sweep, using a custom wordlist and trying .sql, .txt and .zip. The useful answer was initsql.sql. An initialisation SQL file exists to create and populate a database, so it is among the files most likely to carry bootstrap data, service accounts or keys.

Inside initsql.sql there was a security token written in plain text. What made the finding serious was not only that it was there, but whose it was: it did not belong to the application under test but to another entity in the same corporate group. A secret stored in the clear inside an application file is CWE-798, "Use of Hard-coded Credentials"; that file served to the internet is CWE-552, "Files or Directories Accessible to External Parties"; and the carelessly published folder is what the OWASP Top 10:2025 calls A02, "Security Misconfiguration", which lists among its conditions having unnecessary features enabled or installed: ports, services, pages, accounts, testing frameworks or privileges that nobody needs.

The team identified which API the token belonged to and tested it against that API. It was still valid and it mapped to an administrator account, which means full access: not to the application under test, but to a system belonging to another entity in the group that was not even inside the scope of the engagement.

RECONSTRUCTION · NO CLIENT DATA

How a name from a wordlist reached an administrator account in another company

CWE-552
CWE-798

The directory sweep
WORDLIST · ffuf
1. admin
2. assets
3. backup
4. config
5. database
FOUND
```
GET /database HTTP/1.1
Host: client.example.com
```
A tool that tries names in order, to find what nothing links to.
What was inside it
WEB SERVER PUBLIC ROOT
```
client.example.com/
└── database/
    └── migrations/
```
DEVELOPER-SIDE ONLY (CWE-552)
Migration folders build the database schema. They are internal project machinery, published by accident.
The extension sweep

CUSTOM WORDLIST
- .sql
- .txt
- .zip
```
/database/migrations/initsql.sql
```
An initialisation SQL file exists to create and populate a database, so it is among the files most likely to carry bootstrap data, service accounts or keys.
The secret, and whose it was
PLAIN TEXT (CWE-798)
```
initsql.sql
  ...
  'EXAMPLE-TOKEN-Z9Y8X7W6'
  ...
```
Application under test

Another entity, same group
ENGAGEMENT SCOPE

The case publishes that the token was in plain text inside the file. It does not publish the database schema, so this figure does not draw one.

Still valid. Administrator. On a system outside the scope.

Rated critical. The same automated sweep that found it here would find it for anyone.

What we recommended

/var/www/html/database/migrations/initsql.sql

/srv/app/db/migrations/initsql.sql

outside the web root

'EXAMPLE-TOKEN-Z9Y8X7W6'

${API_TOKEN}

secrets manager or environment

A secret does not belong in source code or in database files. Any token that has ever been published is treated as compromised and invalidated.

Reconstruction of the finding, not a screenshot. A directory sweep reached a migrations folder served from the web root (CWE-552); the initialisation SQL file inside it held a plain-text administrator token (CWE-798) belonging to a different entity in the same group. Hosts, paths and tokens shown are fictitious.

The impact was rated critical. Anyone who came across that exposed SQL file, and the same automated sweep that found it here was enough to come across it, could get in with no credentials and with administrator privileges: to view, modify or delete sensitive data; add or remove user accounts; reach private analytics and logs; and cause serious damage to the operation.

The root cause is leaving sensitive files in a directory that can be reached from the internet. Those files should never be accessible from outside, and a token must not be stored in plain text inside source code or inside database files. What we recommended was to move the migrations directory out of the web server’s public root, move secrets into a secrets manager or into environment variables that do not travel with the deployment, and treat as compromised and invalidate any token that has ever been published.

An exposed migrations directory and the administrator token inside it

A SQL file reachable from the internet, and inside it a plain-text administrator token that opened a door into another entity of the same group.

From a directory sweep to full access without credentials

Your company could be next.

A SQL file reachable from the internet, and inside it a plain-text administrator token that opened a door into another entity of the same group.

From a directory sweep to full access without credentials

Related case studies

An administrator token in the URL, archived by a crawler and still valid

Your company could be next.