<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Django-Haystack - CraftedSignal Threat Feed</title><link>https://feed.craftedsignal.io/vendors/django-haystack/</link><description>Trending threats, MITRE ATT&amp;CK coverage, and detection metadata. Fed continuously.</description><generator>Hugo</generator><language>en</language><managingEditor>hello@craftedsignal.io</managingEditor><webMaster>hello@craftedsignal.io</webMaster><lastBuildDate>Wed, 15 Jul 2026 22:43:44 +0000</lastBuildDate><atom:link href="https://feed.craftedsignal.io/vendors/django-haystack/feed.xml" rel="self" type="application/rss+xml"/><item><title>Remote Code Execution via eval() in django-haystack Elasticsearch Deserialization</title><link>https://feed.craftedsignal.io/briefs/2026-07-django-haystack-rce/</link><pubDate>Wed, 15 Jul 2026 22:43:44 +0000</pubDate><author>hello@craftedsignal.io</author><guid isPermaLink="true">https://feed.craftedsignal.io/briefs/2026-07-django-haystack-rce/</guid><description>A critical remote code execution (RCE) vulnerability in the Elasticsearch backend of django-haystack allows attackers to execute arbitrary Python commands by manipulating `SearchField` aliases and indexed content, leading to full compromise of the Django application.</description><content:encoded><![CDATA[<p>A critical remote code execution (RCE) vulnerability (CVSS 8.5 High) has been identified in the Elasticsearch backend of the <code>django-haystack</code> library. This flaw arises when a <code>SearchField</code> is configured with an <code>index_fieldname</code> alias that differs from the logical field name. During the processing of search results, the backend attempts to look up fields by their logical name, but the data is stored under the alias. This lookup failure causes the raw field value to be passed directly to <code>_to_python()</code> which subsequently calls <code>eval()</code> without proper type-safety checks. An attacker who can control content indexed into Elasticsearch, and then trigger a search that returns this malicious content, can inject arbitrary Python expressions such as <code>__import__('os').system(...)</code>. This allows for the execution of arbitrary Python and shell commands within the Django application process, potentially leading to full compromise of the server. This vulnerability affects all Django applications utilizing the Elasticsearch backend with <code>index_fieldname</code> aliasing, regardless of the application's authentication mechanisms.</p>
<h2 id="attack-chain">Attack Chain</h2>
<ol>
<li>An attacker gains control over content that is subsequently indexed into Elasticsearch by the vulnerable Django application.</li>
<li>The application's <code>SearchIndex</code> contains a <code>SearchField</code> declared with an <code>index_fieldname</code> (e.g., <code>&quot;name_s&quot;</code>) that differs from its logical attribute name (e.g., <code>&quot;name&quot;</code>).</li>
<li>The attacker-controlled data, specifically a crafted Python expression, is stored in Elasticsearch under the <code>index_fieldname</code> alias.</li>
<li>A search operation is performed, retrieving the malicious document from Elasticsearch, including the attacker-controlled <code>_source</code> data.</li>
<li>During result processing by <code>ElasticsearchSearchBackend._process_results()</code>, the backend attempts to map Elasticsearch fields to logical field names.</li>
<li>The lookup for the <code>index_fieldname</code> (e.g., <code>&quot;name_s&quot;</code>) fails because <code>index.fields</code> is keyed by logical names (e.g., <code>&quot;name&quot;</code>).</li>
<li>Due to the failed lookup, the raw, attacker-controlled value from Elasticsearch is passed to <code>_to_python(value)</code>.</li>
<li>The <code>_to_python()</code> function then unconditionally calls <code>eval(value)</code>, executing the attacker's injected Python expression with the privileges of the Django application.</li>
</ol>
<h2 id="impact">Impact</h2>
<p>This vulnerability results in Remote Code Execution (RCE), allowing an attacker to execute arbitrary Python and shell commands on the affected server. Successful exploitation grants the attacker the same privileges as the running Django application, leading to a complete compromise of the server's confidentiality, integrity, and availability. The impact extends to all Django applications that use the <code>django-haystack</code> Elasticsearch backend and declare <code>SearchField</code> instances with <code>index_fieldname</code> aliases, irrespective of their authentication configurations. The severity is high, as demonstrated by the CVSS 3.1 Base Score of 8.5.</p>
<h2 id="recommendation">Recommendation</h2>
<ul>
<li>Patch the <code>django-haystack</code> library immediately to apply the provided fix that introduces <code>index.field_map</code> remapping and uses <code>ast.literal_eval</code> instead of <code>eval()</code>.</li>
<li>Deploy the provided Sigma rule to your SIEM to detect the creation of the RCE marker file <code>/tmp/django_haystack_eval_rce_proof</code>.</li>
<li>Enable process creation logging on Linux servers to ensure visibility into executed commands, which is required for the provided Sigma rule.</li>
<li>Review all <code>SearchIndex</code> configurations within your Django applications to identify and assess any <code>SearchField</code> declarations using <code>index_fieldname</code> aliases, especially those handling user-controlled input.</li>
</ul>
]]></content:encoded><category domain="severity">high</category><category domain="type">advisory</category><category>rce</category><category>python</category><category>django</category><category>elasticsearch</category><category>deserialization</category><category>supply-chain</category></item></channel></rss>