Summary
Tianji contains a SQL injection vulnerability in analytics queries because a timezone value is inserted into raw SQL without parameter binding. An authenticated workspace member, including a read-only viewer, may be able to execute arbitrary SQL against the shared PostgreSQL database when the value is supplied through request data or an HTTP header.
Tianji contains a SQL injection vulnerability in analytics queries because a timezone value is inserted into raw SQL without parameter binding. An authenticated workspace member, including a read-only viewer, may be able to execute arbitrary SQL against the shared PostgreSQL database when the value is supplied through request data or an HTTP header.
Affected context
The issue occurs in Tianji deployments using affected analytics query paths where the timezone value reaches getDateQuery() through request data or the timezone HTTP header. Exploitation is relevant when an attacker has authenticated access to a workspace and the application permits that member to invoke the associated procedures.
The issue occurs in Tianji deployments using affected analytics query paths where the timezone value reaches getDateQuery() through request data or the timezone HTTP header. Exploitation is relevant when an attacker has authenticated access to a workspace and the application permits that member to invoke the associated procedures.
Exploit preconditions
- Attack surface: Analytics query endpoints and procedures that process timezone input
- Required access: An authenticated Tianji workspace membership; read-only access may be sufficient
- Trigger point: An analytics request that causes
getDateQuery()to construct raw SQL - Why exploitation is possible: The timezone value is interpolated into a Prisma raw SQL expression rather than safely bound as a parameter
- Attack surface: Analytics query endpoints and procedures that process timezone input
- Required access: An authenticated Tianji workspace membership; read-only access may be sufficient
- Trigger point: An analytics request that causes
getDateQuery()to construct raw SQL - Why exploitation is possible: The timezone value is interpolated into a Prisma raw SQL expression rather than safely bound as a parameter
Why this happens
The vulnerability is caused by constructing SQL with untrusted input embedded directly in a raw query expression. Although Prisma provides parameterized query mechanisms, the affected code interpolates the timezone value into SQL text, allowing input to alter the intended query structure. This behavior maps to CWE-89: Improper Neutralization of Special Elements used in an SQL Command, commonly known as SQL injection.
The vulnerability is caused by constructing SQL with untrusted input embedded directly in a raw query expression. Although Prisma provides parameterized query mechanisms, the affected code interpolates the timezone value into SQL text, allowing input to alter the intended query structure. This behavior maps to CWE-89: Improper Neutralization of Special Elements used in an SQL Command, commonly known as SQL injection.
Potential impact
- An attacker may read credentials, API keys, and tenant data
- Database records could be modified or deleted
- Stored application configuration may be altered
- The service could become unavailable through resource-intensive or destructive queries
- Data belonging to other tenants may be exposed
- An attacker may read credentials, API keys, and tenant data
- Database records could be modified or deleted
- Stored application configuration may be altered
- The service could become unavailable through resource-intensive or destructive queries
- Data belonging to other tenants may be exposed
General mitigation guidance
Mitigation generally focuses on ensuring that externally supplied values never become executable SQL syntax.
Common defensive patterns include:
- Use parameterized queries or trusted query-builder APIs for all dynamic values
- Replace free-form timezone input with a strict allowlist of supported timezone identifiers
- Validate and normalize request data before it reaches database query construction
- Avoid treating HTTP headers as trusted input
- Apply least-privilege database roles and restrict write or administrative capabilities for read-only application paths
- Separate tenant data and enforce authorization checks at both application and database layers
- Use read-only database access for analytics operations where practical
Mitigation generally focuses on ensuring that externally supplied values never become executable SQL syntax.
Common defensive patterns include:
- Use parameterized queries or trusted query-builder APIs for all dynamic values
- Replace free-form timezone input with a strict allowlist of supported timezone identifiers
- Validate and normalize request data before it reaches database query construction
- Avoid treating HTTP headers as trusted input
- Apply least-privilege database roles and restrict write or administrative capabilities for read-only application paths
- Separate tenant data and enforce authorization checks at both application and database layers
- Use read-only database access for analytics operations where practical
How teams detect issues like this
Organizations can detect this class of issue through:
- Static analysis rules that identify string interpolation or concatenation inside raw SQL APIs
- Code review checks for request values, headers, or query parameters flowing into database commands
- Tests that verify generated queries use bound parameters rather than embedded user-controlled text
- Database monitoring for unexpected statements, cross-tenant access patterns, schema changes, or destructive operations
- Policy enforcement requiring parameterized queries and approved database access libraries
Automated code review and application security testing tools may help identify suspicious data flows, but findings should be validated against actual authorization and query behavior.
Organizations can detect this class of issue through:
- Static analysis rules that identify string interpolation or concatenation inside raw SQL APIs
- Code review checks for request values, headers, or query parameters flowing into database commands
- Tests that verify generated queries use bound parameters rather than embedded user-controlled text
- Database monitoring for unexpected statements, cross-tenant access patterns, schema changes, or destructive operations
- Policy enforcement requiring parameterized queries and approved database access libraries
Automated code review and application security testing tools may help identify suspicious data flows, but findings should be validated against actual authorization and query behavior.
