Critical Security: SQL Injection in /api/metrics/database Endpoint Bypasses Table Validation

A critical SQL injection vulnerability has been reported in OpenClaw's database metrics endpoint. If you're running a version with this endpoint exposed, you'll want to patch immediately or restrict access.

The Vulnerability

The /api/metrics/database endpoint accepts a minutes query parameter to filter records by timestamp. While the code validates the table parameter using pattern matching, the minutes parameter gets interpolated directly into the SQL query using an f-string:

cursor = conn.execute(
    f"SELECT * FROM {table} WHERE timestamp > datetime('now', '-{minutes} minutes') ORDER BY timestamp DESC LIMIT 1000"
)

This means an attacker can craft a malicious minutes value to break out of the intended query structure and execute arbitrary SQL commands.

Why This Is Dangerous

Even though the table parameter is validated, the minutes parameter isn't. An attacker could potentially:

• Extract sensitive data by injecting UNION SELECT statements
• Modify or delete records if the database connection has write permissions
• Enumerate database structure by probing for table and column names
• Bypass authentication depending on what else is stored in the database

The impact is especially severe because metrics endpoints are often overlooked in security audits—they're "just diagnostics," right? Wrong.

The Fix

The solution is straightforward: use parameterized queries instead of string interpolation.

cursor = conn.execute(
    "SELECT * FROM metrics WHERE timestamp > datetime('now', ? || ' minutes') ORDER BY timestamp DESC LIMIT 1000",
    (f'-{int(minutes)}',)
)

Or even better, validate and cast minutes to an integer before using it:

try:
    minutes_int = int(minutes)
    if minutes_int < 0 or minutes_int > 10080:  # max 1 week
        raise ValueError
except ValueError:
    return error_response("Invalid minutes parameter")

What You Should Do Now

1. Check if you're affected — is /api/metrics/database exposed on your instance?
2. Restrict access — put the endpoint behind authentication or firewall rules
3. Watch for the patch — a fix should land soon in the main branch
4. Audit your logs — look for suspicious requests to this endpoint

This is a good reminder that every user-controlled input needs validation, even the ones that "obviously" should be numbers. SQL injection is one of the oldest vulnerabilities in the book, but it keeps showing up because developers trust input that looks harmless.

Track the issue: #29951