How an exposed eXist-db REST interface revealed application collections, configuration files, and…

How an exposed eXist-db REST interface revealed application collections, configuration files, and arbitrary XQuery execution without requiring authentication.

Introduction

One of the most rewarding aspects of bug bounty hunting is discovering technologies that developers often forget to secure.

During a Vulnerability Disclosure Program (VDP) assessment, I came across an application powered by eXist-db, an open-source native XML database widely used for digital archives, research platforms, and XML-based web applications.

Instead of finding a traditional web vulnerability, I discovered that the REST interface itself was exposed to the internet without authentication.

What initially appeared to be a simple directory listing quickly evolved into a much more serious issue involving:

Unauthenticated database enumeration
Source code disclosure
Configuration file exposure
Arbitrary XQuery execution

Although this report was ultimately marked as a duplicate because another researcher had submitted it first, the vulnerability itself was classified with Exceptional severity, highlighting its potential impact.

Discovery

During reconnaissance, I noticed that the application exposed an eXist-db REST endpoint.

The endpoint looked similar to:

/exist/rest/db/

/exist/rest/db/

Rather than returning an authentication challenge, it immediately exposed the root database collection.

Seeing a database respond without any authentication is always worth investigating further.

Enumerating the Database

The REST interface allowed unrestricted browsing of database collections.

Instead of exposing only public resources, the server revealed multiple application collections containing deployed projects and application components.

Each collection could be explored recursively, making it possible to understand the application's internal architecture without logging in.

For an attacker, this level of visibility dramatically reduces the effort required to identify sensitive files and potential attack paths.

Source Code and Configuration Exposure

As I continued exploring the collections, I found that application resources were readable directly through the REST API.

Among the exposed content were:

Application source code
XML configuration files
Installation resources
Deployment scripts
Docker-related files
Environment configuration files

Configuration files are particularly valuable during security assessments because they often reveal how an application communicates with databases, authentication services, and internal infrastructure.

Even when passwords are absent, usernames, internal hosts, and deployment details provide useful intelligence for an attacker.

Discovering Arbitrary XQuery Execution

The most significant finding came when I tested the REST API's built-in query functionality.

The endpoint accepted an XQuery expression through a query parameter and executed it directly on the server.

This confirmed that arbitrary XQuery expressions could be evaluated without authentication.

Unlike SQL Injection, this functionality was part of the application's intended feature set — it simply wasn't protected.

Once confirmed, it became possible to query accessible XML collections directly through the REST interface.

Large-Scale Database Enumeration

Using XQuery, I verified that accessible collections could be queried and traversed programmatically.

The exposed database contained an extensive amount of XML data distributed across numerous application collections.

This transformed what initially appeared to be an information disclosure issue into a full database enumeration vulnerability.

An attacker would not need to manually browse files one at a time — they could query the available XML documents directly.

Security Impact

The exposed REST interface significantly increased the application's attack surface.

An unauthenticated attacker could potentially:

Enumerate database collections
Read application source code
Access configuration files
Extract application data
Execute arbitrary XQuery expressions
Map the application's internal structure
Gather intelligence for follow-up attacks

Although some administrative collections remained protected, the accessible application collections still exposed a substantial amount of sensitive information.

Root Cause

The vulnerability existed because the eXist-db REST interface was publicly accessible without enforcing authentication.

Features intended for administrators and developers — including query execution and collection browsing — were available to any remote user.

When powerful administrative functionality is exposed without access control, even legitimate features become security vulnerabilities.

Responsible Disclosure

After documenting the affected endpoint, captured responses, and demonstrated impact, I submitted the issue through the organization's Vulnerability Disclosure Program.

The triage team reviewed the report and confirmed that the vulnerability had already been reported by another researcher.

Although my submission was marked as a duplicate, the original issue had already been classified with Exceptional severity, confirming the seriousness of the exposure.

Duplicate reports are a normal part of bug bounty hunting and serve as a reminder that discovering valuable vulnerabilities often means other researchers may be investigating the same targets.

Lessons Learned

This research reinforced an important lesson:

Not every critical vulnerability is a software bug.

Sometimes the greatest risk comes from powerful features that are deployed without proper authentication.

Developer interfaces, database APIs, search consoles, and administrative services are frequently overlooked during deployment and can expose an enormous amount of sensitive information when left publicly accessible.

For security researchers, identifying exposed management interfaces should always be part of the reconnaissance process.

For developers and administrators, every administrative endpoint should be treated as sensitive and protected accordingly.

Recommendations

Organizations using eXist-db or similar database platforms should consider the following security measures:

Require authentication for all REST API endpoints.
Restrict database management interfaces to trusted internal networks.
Disable public query execution functionality unless absolutely necessary.
Remove sensitive configuration files from accessible database collections.
Follow vendor hardening guidance before deploying production systems.
Periodically audit exposed services to ensure administrative functionality is not publicly reachable.

Final Thoughts

This finding demonstrates how a single exposed REST interface can reveal far more than intended.

Without exploiting a traditional injection vulnerability, the application exposed its internal structure, application resources, and server-side query functionality simply because access controls were missing.

As bug bounty hunters, discoveries like these reinforce the importance of thorough reconnaissance. Sometimes the most impactful findings are not hidden deep within an application — they are exposed in plain sight.

About the Author

Netclouts is an independent cybersecurity researcher specializing in web application security, bug bounty hunting, API security, and responsible vulnerability disclosure. He enjoys uncovering overlooked attack surfaces and helping organizations strengthen their security through coordinated disclosure.

Contents