Security Concern: Unbounded Search Input Leading to Large SQL and Session Growthh problem

1

Environment:

Request Tracker 6 (RT 6) with FullTextSearch enabled

Summary:

In production, we have observed that DBIx can generate extremely large SQL statements (over 100 MB with 2,000+ bound parameters). At the same time, the sessions table may contain entries where a_session exceeds 100 MB.

Root Cause:

When a user pastes or enters a very long string (for example, an entire email subject or full ticket content) into the quick-search or full-search input, RT attempts to build a complex RT::Tickets search.

This results in a massive SQL query containing repeated INTERSECT clauses, to_tsvector calls, and multiple joins (Groups, CachedGroupMembers, AttachmentsIndex, etc.).

The problem is amplified when:

  • The input is non-English text (especially CJK) or includes symbols / punctuation, which produces many search tokens.

  • The Search Builder keeps these objects serialized in a_session, causing enormous session rows and potential memory exhaustion (OOM) both in RT and at the database layer.

Impact:

  • RT web process may run out of memory.

  • PostgreSQL may experience slow queries or OOM due to oversized SQL and parameter sets.

  • The sessions table can bloat and degrade performance.

Current My Workaround :

  • Add guard logic in /Search/Simple.html and /Search/Build.html to reject queries exceeding reasonable length

  • And I disabled the FullTextSearch for now.

2 Likes