Summary
fsspec's ReferenceFileSystem can evaluate attacker-controlled Jinja template expressions embedded in Kerchunk reference documents. When such a document is opened, the unrestricted rendering behavior may execute Python code before referenced data is accessed.
Affected context
The issue occurs in fsspec ReferenceFileSystem deployments that process Kerchunk reference JSON documents containing template-related content. Risk is present when a document is supplied inline or retrieved from an attacker-controlled location and is opened by fsspec directly or through a consumer such as xarray.
Exploit preconditions
- Attack surface: Reference document processing in
fsspec.implementations.reference.ReferenceFileSystem - Required access: Ability to provide, modify, or control a reference document or its retrieval source
- Trigger point: Opening the reference filesystem and processing templated fields
- Relevant paths: Documents containing a
genarray can reach generation processing; other paths depend on template-related options and values - Why exploitation is possible: Unrestricted Jinja rendering evaluates template content as executable Python-related logic rather than treating it as inert data
Why this happens
The vulnerability results from passing reference-document values to unrestricted jinja2.Template(...).render(...) calls. This allows data that should be treated as configuration or metadata to be interpreted as server-side template logic, mapping to CWE-94: Improper Control of Generation of Code and CWE-1336: Improper Neutralization of Special Elements Used in a Template Engine. The insecure pattern is trusting document-controlled template expressions without a restricted evaluation environment or an explicit allowlist of permitted operations.
Potential impact
- An attacker may execute arbitrary Python code in the process handling the reference document.
- The application or data-processing worker could be compromised.
- Credentials, environment variables, or locally accessible data could be exposed.
- Downstream consumers such as xarray may inherit the compromise when opening untrusted references.
- The compromised process could be used for data tampering, persistence, or lateral movement.
General mitigation guidance
Mitigation generally focuses on removing code execution from reference-document rendering and reducing trust in external documents.
Common defensive patterns include:
- Treating reference fields as data and avoiding template evaluation wherever possible.
- Using a restricted, declarative templating mechanism with a narrowly defined allowlist when templating is required.
- Disabling template and generation features for untrusted documents unless explicitly needed.
- Validating documents against a strict schema before processing and rejecting unexpected template-related fields.
- Restricting outbound document retrieval to trusted sources and enforcing integrity or authenticity checks.
- Running data-processing components with least privilege, isolated credentials, and limited filesystem and network access.
How teams detect issues like this
Organizations can look for this issue through:
- Static analysis rules identifying unrestricted Jinja template construction and rendering in code paths that consume external data.
- Code review checks for template evaluation of JSON, configuration, metadata, or URL-fetched content.
- Dependency and policy scans that flag server-side template engines used without sandboxing or operation allowlists.
- Runtime monitoring for unexpected reference-document sources, template-related fields, process-spawn activity, or anomalous outbound connections.
- CI policies requiring schema validation and trust-boundary review for reference filesystem inputs.
Automated code-review and software-composition tools may help identify unsafe rendering patterns, but findings should be validated against actual data flows.
