oneuptime-clickhouse-telemetry-sql-injection-rce

OneUptime ClickHouse SQL injection in telemetry aggregation API creates immediate data breach and RCE risk

What happened

The sticky bit here is ClickHouse and OneUptime’s telemetry aggregation API, specifically the user-controlled parameters aggregationType, aggregateColumnName and aggregationTimestampColumnName being concatenated into queries.

Reported within the last 24 hours, OneUptime’s telemetry aggregation endpoint accepted those parameters and used .append() to build ClickHouse SQL with no allowlist, no parameter binding and no input validation. An authenticated user can inject arbitrary SQL, which the advisory says allows full database read, data modification and even potential remote code execution via ClickHouse table functions. The issue is fixed in OneUptime 10.0.23.

Who was affected and how, exactly, has not been disclosed beyond the product and the vulnerable API. The advisory states the vulnerability impacts telemetry data across tenants, and that authentication is required to exploit it.

Why this matters to businesses

If you buy monitoring or uptime tooling, this matters because telemetry is often sensitive and central to customer trust. Since OneUptime stores telemetry for multiple tenants, a successful exploit could expose monitoring data for other customers and let an attacker change or delete records.

That can mean regulatory headaches, cancelled contracts and boards asking awkward questions while ops scramble. Given how quietly internal service data can leak, suppliers like OneUptime are a third party risk you can’t ignore. If you assume authenticated equals trusted, that’s a bad habit; don’t.

If you’ve got the same weakness, here’s what happens next

First, an attacker with valid credentials runs crafted values for aggregationType or aggregateColumnName and pulls back tables, rows or entire datasets. Then they can modify telemetry to hide incidents or inject queries that call ClickHouse table functions to execute code on the ClickHouse host, which may let them pivot further.

Following that, recovery is messy: long forensic windows, cross-tenant disclosure obligations, expensive remediation and loss of service confidence. It does not need to be cinematic to be costly; subtle data corruption or stealthy reads are enough to ruin customer trust and trigger breach reporting.

What to do on Monday morning

• Apply the vendor fix to OneUptime 10.0.23 immediately where possible.
• If you cannot patch right away, restrict access to the telemetry aggregation API to a minimal set of authenticated roles and trusted IP ranges.
• Audit and tighten application permissions, enforce least privilege for any account that can call aggregation endpoints.
• Review the code path: replace string concatenation with parameterised queries or allowlists for aggregationType and column names, and validate inputs server side.
• Harden ClickHouse network exposure, isolate it on internal networks and remove direct public access where present.
• Enable and review query and audit logs for anomalous aggregation queries and sudden large result sets, and add alerts for unusual schema or function usage.
• Test incident response and data recovery plans, and ensure backups cover telemetry stores and are immutable during investigation.

Where ISO standards fit, without the sales pitch

An ISO 27001 aligned management system helps here by forcing supplier risk reviews, secure development practices and clear access controls, so you’d more likely find this class of injection during design or testing rather than in production; see ISO 27001 for the sort of controls that reduce this risk.

When continuity and recovery matter, ISO 22301 gives you tested playbooks to keep customers reassured while you investigate; a mature BCMS shortens the time executives spend on crisis calls, see ISO 22301.

For baseline certification and practical security hygiene that catches avoidable faults like missing input validation and poor segregation, consider IASME aligned controls, see IASME.

None of those standards prevents every bug, but they change how teams design, test and accept code, which is exactly what would have stopped this concatenated-query problem.

Fix it fast, learn from it, and don’t pretend authentication is a moat.