Php Fts
Monthly
Filter bypass in PHP-FTS (olivier-ls/php-fts) through version 1.1.3 allows an authenticated remote attacker to defeat document-scoping filters used by consuming applications for ownership or multi-tenant isolation, exposing search results the application intended to hide. The flaw resides in SearchEngine::matchesSingleFilter in src/SearchEngine.php, where filter values were compared with loose `==` and non-strict `in_array()`; because PHP treats any non-empty string as equal to boolean true, a filter value of true matched every document with a non-empty value in that field, and the string '42' matched the integer 42, enabling retrieval of other users' or tenants' records. Publicly available exploit code exists (a proof-of-concept write-up is referenced alongside the CVE from VulDB and a GitHub PoC repository), and the issue is not listed in CISA KEV, so no confirmed active exploitation is known; the risk is context-dependent and moderate, materializing only where the application relies on PHP-FTS filters as an access-control boundary and passes untyped request input directly into filter construction.
Stored cross-site scripting in the PHP-FTS full-text search library (olivier-ls/php-fts) through version 1.1.2 lets an attacker who can introduce content into the search index inject markup that executes in a victim's browser when the application renders the returned search highlights as HTML. The flaw sits in SearchEngine::buildHighlights in src/SearchEngine.php, which concatenates stored field text with opening and closing highlight tags without escaping it; per the vendor's own CVSS:4.0 vector the attacker is an authenticated remote user (PR:L) and exploitation requires the victim to interact (UI:P), with impact limited to manipulated content (VI:L) and no confidentiality or availability loss. The vendor shipped a fix in 1.1.3 (commit 0b2fae333d6b022da7ed4c43e2d41aa03f91dff3) and publicly available exploit code exists for this issue, but there is no indication of confirmed active exploitation in the wild.
Filter bypass in PHP-FTS (olivier-ls/php-fts) through version 1.1.3 allows an authenticated remote attacker to defeat document-scoping filters used by consuming applications for ownership or multi-tenant isolation, exposing search results the application intended to hide. The flaw resides in SearchEngine::matchesSingleFilter in src/SearchEngine.php, where filter values were compared with loose `==` and non-strict `in_array()`; because PHP treats any non-empty string as equal to boolean true, a filter value of true matched every document with a non-empty value in that field, and the string '42' matched the integer 42, enabling retrieval of other users' or tenants' records. Publicly available exploit code exists (a proof-of-concept write-up is referenced alongside the CVE from VulDB and a GitHub PoC repository), and the issue is not listed in CISA KEV, so no confirmed active exploitation is known; the risk is context-dependent and moderate, materializing only where the application relies on PHP-FTS filters as an access-control boundary and passes untyped request input directly into filter construction.
Stored cross-site scripting in the PHP-FTS full-text search library (olivier-ls/php-fts) through version 1.1.2 lets an attacker who can introduce content into the search index inject markup that executes in a victim's browser when the application renders the returned search highlights as HTML. The flaw sits in SearchEngine::buildHighlights in src/SearchEngine.php, which concatenates stored field text with opening and closing highlight tags without escaping it; per the vendor's own CVSS:4.0 vector the attacker is an authenticated remote user (PR:L) and exploitation requires the victim to interact (UI:P), with impact limited to manipulated content (VI:L) and no confidentiality or availability loss. The vendor shipped a fix in 1.1.3 (commit 0b2fae333d6b022da7ed4c43e2d41aa03f91dff3) and publicly available exploit code exists for this issue, but there is no indication of confirmed active exploitation in the wild.