Django Haystack
Monthly
Remote code execution in Django Haystack's Elasticsearch backend affects versions up to and including 3.3.0, where an attacker-controlled string reaching the result-deserialization path is passed to `eval()` inside `_to_python()` and executed in the Django application process. Exploitation is conditional rather than blanket: it requires the Elasticsearch backend, at least one `SearchField` declared with an `index_fieldname` alias that differs from its logical field name, and the ability to get a malicious payload indexed into that aliased field and returned by a subsequent search - a second-order/stored injection rather than a direct request-driven one. Publicly available exploit code exists (a GHSA advisory with source-level walkthrough was published alongside the fix), and the input CVSS vector marks PR:H, so under that vector exploitation is treated as authenticated; there is no CISA KEV entry indicating confirmed active exploitation. The vulnerability is patched in 3.4.0, and the reporting signals conflict sharply and must be weighed carefully: VulDB's CVSS 4.0 base of 2.0 contrasts with the upstream advisory's CVSS 3.1 base of 8.5, reflecting the gap between the mild vector assumptions and the full RCE impact when the alias configuration is present.
Remote code execution in Django Haystack's Elasticsearch backend affects versions up to and including 3.3.0, where an attacker-controlled string reaching the result-deserialization path is passed to `eval()` inside `_to_python()` and executed in the Django application process. Exploitation is conditional rather than blanket: it requires the Elasticsearch backend, at least one `SearchField` declared with an `index_fieldname` alias that differs from its logical field name, and the ability to get a malicious payload indexed into that aliased field and returned by a subsequent search - a second-order/stored injection rather than a direct request-driven one. Publicly available exploit code exists (a GHSA advisory with source-level walkthrough was published alongside the fix), and the input CVSS vector marks PR:H, so under that vector exploitation is treated as authenticated; there is no CISA KEV entry indicating confirmed active exploitation. The vulnerability is patched in 3.4.0, and the reporting signals conflict sharply and must be weighed carefully: VulDB's CVSS 4.0 base of 2.0 contrasts with the upstream advisory's CVSS 3.1 base of 8.5, reflecting the gap between the mild vector assumptions and the full RCE impact when the alias configuration is present.