公式の TYPO3 Apache Solr 拡張機能（EXT:solr / apache-solr-for-typo3/solr）にアーキテクチャ上のセキュリティ脆弱性が発見されました。この問題により、未認証のリモート攻撃者が検索パラメータ tx_solr[q] を介して任意の Solr/Lucene クエリ構文を注入でき、検索インデックスからの不正なブラインドフィールド列挙および完全なメタデータ抽出が可能になります。
EXT:solr（検索パラメータ: tx_solr[q]）CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:NEXT:solr 拡張機能は、tx_solr[q] パラメータを介してユーザー提供の検索語を受け取り、それらを Apache Solr エンジンに転送します。設計上、この拡張機能はワイルドカード（*）、単一文字ワイルドカード（?）、フィールドセレクタ（:）、範囲クエリ（[a TO z]）といった特定のクエリ演算子を許可し、ファセットフィルタリングなどの正規の機能をサポートしています。
これらの文字が、強制力のあるホワイトリストやクエリアブストラクションレイヤーを経由せずにバックエンドのクエリ構築に直接渡されていたため、攻撃者はフィールド固有の構文を供給して意図された検索境界を脱出できます。これにより、未認証ユーザーが内部 Solr フィールドを直接クエリし、ブールベースのブラインドテクニックを用いてインデックスデータを抽出することが可能になります。
field:* によるフィールド列挙任意または推測されたフィールド名にワイルドカードを付加することで、攻撃者はそのフィールドがスキーマ内に存在するかどうかを検証できます:
GET /search?tx_solr[q]=siteHash:* HTTP/1.1
Host: target.example.com
フィールドが存在する場合、Solr は一致するすべてのレコードに対してクエリを処理し（多くの場合、異なるレスポンスコードやボリューム関連の挙動を引き起こします）、自動化されたワードリストベースのフィールド列挙が可能になります。
攻撃者はブール推論を用いて、機密性の高いフィールド値を 1 文字ずつ抽出できます:
GET /search?tx_solr[q]=siteHash:a* HTTP/1.1 --> Returns search hits (Value begins with 'a')
GET /search?tx_solr[q]=siteHash:b* HTTP/1.1 --> "Nothing found" (Value does not begin with 'b')
? 演算子による長さ検出単一文字ワイルドカード演算子（?）は、文字の反復処理を開始する前に、格納された文字列の正確な長さを判定できます:
GET /search?tx_solr[q]=siteHash:????????????* HTTP/1.1 (Checks for 12+ characters)
GET /search?tx_solr[q]=siteHash:?????????????* HTTP/1.1 (Checks for 13+ characters)
[a TO z]）範囲クエリは、先頭文字に対する二分探索抽出を可能にし、文字位置ごとに必要なリクエスト数を 26 回から約 5 回に削減します:
GET /search?tx_solr[q]=siteHash:[a TO m] HTTP/1.1 --> Determines if character falls within 'a'-'m'
GET /search?tx_solr[q]=siteHash:[n TO z] HTTP/1.1 --> Determines if character falls within 'n'-'z'
長さ検出、範囲クエリ、プレフィックスワイルドカードを組み合わせることで、最小限のリクエストフットプリントで完全なフィールド抽出が可能になります。
EXT:solr 検索エンドポイントを利用するすべてのデフォルトインストールに影響しました。* や : といった演算子は意図された検索機能を提供するため、グローバルな文字エスケープでは不十分です。修復にはアプリケーション層のホワイトリストとパースモデルが必要です:
[email protected]）に正式な脆弱性レポートを提出。