Summary
rustchain_export.py writes API and SQLite-sourced values directly into CSV files without neutralizing spreadsheet formulas. A malicious or compromised node response, or an imported local database row, can place values beginning with =, +, -, @, or tab/control-prefixed variants into fields such as miner_id, device_arch, hardware_type, or ledger reason. When an operator opens the exported CSV in Excel, LibreOffice, or a compatible spreadsheet, those cells may be interpreted as formulas.
Affected code
miners_from_api() copies public API fields into export rows.db_exports() copies local DB fields such as miners, attestations, rewards, balances, and ledger rows into export rows.write_csv() passes rows directly to csv.DictWriter.writerows(rows) without escaping formula-leading cell values.
Why this is security relevant
The export tool is designed to create portable snapshots for offline analysis. CSV files are commonly opened in spreadsheet tools. If attacker-controlled miner/device/ledger text starts with a formula marker, spreadsheet execution can trigger external data fetches, local formula actions, or operator deception when the file is opened.
JSON and JSONL exports should preserve raw values, but CSV output should be safe for spreadsheet consumers by default.
Expected behavior
CSV writer output should neutralize formula-leading text values while preserving ordinary values and preserving JSON/JSONL behavior. A common mitigation is to prefix dangerous string cells with a single quote when the first non-empty character after leading whitespace/control prefixes is one of =, +, -, or @.
Validation planned
I am preparing a focused regression test for write_csv() proving dangerous miner/device/export values are neutralized in CSV output while JSON output remains unchanged.
Summary
rustchain_export.pywrites API and SQLite-sourced values directly into CSV files without neutralizing spreadsheet formulas. A malicious or compromised node response, or an imported local database row, can place values beginning with=,+,-,@, or tab/control-prefixed variants into fields such asminer_id,device_arch,hardware_type, or ledgerreason. When an operator opens the exported CSV in Excel, LibreOffice, or a compatible spreadsheet, those cells may be interpreted as formulas.Affected code
miners_from_api()copies public API fields into export rows.db_exports()copies local DB fields such as miners, attestations, rewards, balances, and ledger rows into export rows.write_csv()passes rows directly tocsv.DictWriter.writerows(rows)without escaping formula-leading cell values.Why this is security relevant
The export tool is designed to create portable snapshots for offline analysis. CSV files are commonly opened in spreadsheet tools. If attacker-controlled miner/device/ledger text starts with a formula marker, spreadsheet execution can trigger external data fetches, local formula actions, or operator deception when the file is opened.
JSON and JSONL exports should preserve raw values, but CSV output should be safe for spreadsheet consumers by default.
Expected behavior
CSV writer output should neutralize formula-leading text values while preserving ordinary values and preserving JSON/JSONL behavior. A common mitigation is to prefix dangerous string cells with a single quote when the first non-empty character after leading whitespace/control prefixes is one of
=,+,-, or@.Validation planned
I am preparing a focused regression test for
write_csv()proving dangerous miner/device/export values are neutralized in CSV output while JSON output remains unchanged.