Django Haystack CVE-2026-105315

Requires the django-haystack Elasticsearch backend (not Solr/Whoosh/Simple) on a version below 3.4.0, AND at least one SearchField declared with an index_fieldname alias that differs from its logical field name - this alias mismatch is what makes the lookup fall through to _to_python()→eval(). The attacker must be able to get a malicious string indexed into that aliased field (e.g. via user-controlled content the application indexes) and must cause or wait for a search that returns the document. Limiting factors: it is a second-order/stored injection (payload only fires on result deserialization, not at index time), it does not apply to default installations lacking the alias configuration or using non-Elasticsearch backends, and the ability to inject indexed content typically presupposes some application-level access. Input CVSS marks PR:H, so under the provided vector exploitation is treated as authenticated.

Signals conflict sharply and must be weighed carefully. CWE-95 (eval injection) and the vendor GHSA advisory (GHSA-r3hx-x5rh-p9vv) describe unauthenticated-to-authenticated remote code execution via eval() in the Elasticsearch result deserializer, and GHSA self-assigns CVSS 3.1 of 8.5 (High). The input CVSS, however, is a VulDB-assigned CVSS 4.0 vector scoring only 2.0, with PR:H and VC:L/VI:L/VA:L - which materially UNDERSTATES a confirmed RCE sink; this is a clear severity/impact disagreement that defenders should resolve in favor of the vendor advisory. A public exploit exists (GHSA marked as exploit, POC=YES), but there is no CISA KEV listing and no EPSS score was provided, so exploitation status is 'publicly available exploit code exists' - NOT active exploitation. Crucially, exploitation is second-order and config-dependent (see exploitation_conditions), so despite RCE potential this is not a drop-everything internet-wide bug; prioritize it where the Elasticsearch backend is used with field aliases and attacker-influenced indexed content. Net: real and patch-worthy, but the raw VulDB 2.0 score is misleading and the GHSA 8.5 is the more credible impact anchor.

An attacker submits user-generated content (e.g. a profile name or comment) containing a Python expression such as __import__('os').system(...), which the application indexes into Elasticsearch under a SearchField whose index_fieldname alias differs from its logical name. When any subsequent search returns that document, the backend's field lookup misses the alias key and passes the raw value to _to_python()→eval(), executing the payload in the Django process. A public POC/advisory exists, and because the CVSS shows AV:N the delivery and trigger are both achievable remotely.