MCP server

io.github.ugurcl/dbridge-mcp

mcp:ugurcl/dbridge-mcp

Query SQLite, PostgreSQL, and MySQL in plain language - read-only, with column masking and limits.

awesome-mcp-servers Glama MCP Registry

Verdict

Suspicious

Risky behavior the analysis could not rule out.

Analyzed Oct 26, 2026, 12:52 UTC at f2a8779

findings

high

highest severity

threat classes

files scanned

357/357

checks satisfied

package advisories

Why this verdict

suspicious: finding mcp-server:.:src/guard.ts:37:DESTRUCT

Security findings 1

Destructive action

highContextual risklow confidence

The shared read-only guard is a keyword blocklist that does not block SELECT ... INTO OUTFILE/DUMPFILE, so on MySQL a privileged user could write server-side files despite the read-only transaction.

src/guard.ts:37

/\b(insert|update|delete|drop|alter|create|replace|attach|detach|vacuum|pragma|reindex|truncate|grant|revoke|copy|merge|call|lock)\b/i

vector:code

Counter-argument considered

The blocklist has no outfile, dumpfile or load_file term. sanitizeQuery only requires the query to start with select or with, and the MySQL driver sends it unchanged inside START TRANSACTION READ ONLY, which does not stop SELECT ... INTO OUTFILE. A form like `SELECT a INTO OUTFILE 'x' FROM t` survives the appended LIMIT. Exploitation needs the FILE privilege and a permissive secure_file_priv, so the risk is contextual and low, but no mitigation refutes it.

Open questions 1

What the analysis could not settle from the code alone.

The regex read-only guard (FORBIDDEN) does not block constructs such as SELECT ... INTO OUTFILE/DUMPFILE or server-side file functions. Whether the DB role and engine prevent these (MySQL FILE privilege, Postgres superuser functions) cannot be determined from the shown units. This is a robustness gap in the guard, not malicious behavior.

Data exfiltration