Security alert: Embedding Malware signatures using OP_RETURN in Blockchain

Hey everyone, So, I've been messing around with regtest and found something a bit alarming. Turns out, you can actually embed AV-signature-like data (like the EICAR test string) into an OP_RETURN output, which then gets mined into a block and stays in the chain. When I pulled the EICAR payload out (named opreturn.bin), it was detectable. However, my ClamAV didn’t flag the entire block file (block.bin) even with relaxed scanning settings. This raises a serious concern because if we increase the OP_RETURN size, these malware signatures could be permanently stuck in blocks, leading to weird AV alerts or even quarantines. Here’s what I think we should do: we should really think twice about bumping up the OP_RETURN size without considering these risks. Environment details: - Bitcoin Core: v30.0rc1 (regtest) - ClamAV: 1.4.3 (latest at test time) - Running on: Kubuntu VM For anyone wanting to replicate this (it’s safe, using EICAR as the test), here’s how: 1. Create and fund a wallet, then mine (in regtest mode): bitcoin-cli -regtest createwallet test ADDR=$(bitcoin-cli -regtest -rpcwallet=test getnewaddress) bitcoin-cli -regtest generatetoaddress 101 "$ADDR" 2. Create a transaction that only outputs OP_RETURN with EICAR: EICAR='X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*' EICAR_HEX=$(printf '%s' "$EICAR" | xxd -p -c200) RAW=$(bitcoin-cli -regtest createrawtransaction '[]' '[{"data":"'

Nice repro and write-up. Couple of points for context: Arbitrary bytes in blocks aren't new. OP_RETURN is one route (and already big enough for EICAR), but far larger payloads ride today in witness/script data (think inscriptions). So even if OP_RETURN stayed tiny, the "AV signature in the chain" genie is long out of the bottle. The AV behaviour you saw is expected, some engines only flag after extraction/decoding; others might quarantine whole containers. But a block file is just inert bytes--if an AV nukes it, you re-download; no code runs from blocks/*.dat. Protocol-level filtering/blacklists won't scale (easy to evade with tiny mutations, fragmented across inputs, or stuffed in witness), and it drifts into brittle censorship + extra DoS surface in relay. Regarding practical ops: Treat the datadir as untrusted data, not software. Put it on a volume mounted noexec/nosuid/nodev; add AV exclusions for blocks/ and chainstate/. Don't back up blocks, back up wallets/descriptors; blocks can be re-synced. If an AV quarantines a blk file, just reindex/re-download. For enterprises, document the exclusion in your hardening guide and monitor for quarantine events so you don't "mysteriously" stall a node.

Thanks for that reply. Node operators aren't always enterprise and that extra work / knowledge puts friction on running nodes. Bypassing AV tests may have un-foreseen consequences, if a work around is devised e.g. extracting and running malware. I am working on a "test script" to embed a zip version of the malware signature. Many AV soft wares look for zip files in Binaries, so I may be able to get ClamAV to detect the blockchain. Cheers again.

Very nice to see im not the only one that has been thinking of this. My thoughts were also roaming towards known YARA rules and other byte sequences that could be used to flag malicious files. Initially I was thinking this in regards of Video Game Cheats, as anti-cheat tends to scan the device and test again known Array of Bytes (AoB). However, Bitcoin blockchain is saved on disk? its not executable at any point in time? For windows, I know most anti-cheat/anti-malware only scan specific set of files, e.g. files with the .exe, file's that are freshly updated and have PE headers. Or even dynamically when e.g. NtMapViewOfFileEx/AllocVirtualEx+WriteProcessMemory (in windows NT) are being used However, I don't see how arbitrary data in the Bitcoin Blockchain can affect such systems in a meaningful way, as I know most detection systems are heavily optimizing which files the scan exactly. In your case, you force the AV to scan your specific file This is simply unrealistic. Now imagine you do somehow manage to sync a full .db of all known "bad" data chunks, but now -- by your logic -- your blacklist.db gets flagged by AV as that file contains a list of all signatures 🤡

This is neither new nor unique to OP_RETURN. It has been possible to embed virus signatures into the blockchain for a very long time. I'm pretty sure the Eicar string is already in the blockchain, and has been in it, for well over a decade. Here's a reddit thread from 12 years ago talking about how there are viruses and virus signatures embedded in the blockchain: https://www.reddit.com/r/Bitcoin/comments/25otbt/someone_put_a_virus_signature_in_the_bitcoin/ UTXO set obfuscataion exists because of virus signatures in outputs since AVs were quarantining the database files. This was implemented over a decade ago. Blocks obfuscation was recently added as well, for similar reasons, although block files typically were not being quarantined because they are too big.

Thanks everyone for the interesting replies. This isn’t about “malware execution.” It’s about AVs quarantining raw block files due to embedded, recognizable payloads. I’ve shown it’s trivially reproducible today; making OP_RETURN bigger makes it easier and more frequent. Proceeding after disclosure means owning that operational risk. I have created a script that anyone can run to reproduce the findings. In this script a ZIP of the signature is included, because AV engines often carve and scan ZIPs found inside larger binaries. Here are the results: For clarity I will post the script in a separate post. Reply to #2 (context + “just exclude blocks/”) I agree arbitrary bytes in chain data aren’t new and exist outside OP_RETURN (witness/script paths, inscriptions, etc.). The point of my PoC is narrower: a mainstream AV quarantined the raw block file itself when a ZIP’ed signature was embedded in OP_RETURN. No manual extraction step; ClamAV carved the archive and flagged the block. That’s concrete operator disruption. “Just exclude blocks/” shifts the blast radius onto every non-enterprise operator (and their backup/restore tools). Many nodes run on consumer OS defaults or managed EDR with on-access/scheduled scans and network share scanning. Quarantine → node stalls or repeated re-downloads → downtime and tickets. That’s friction and centralizing pressure. I’m not proposing protocol blacklists or censorship. I’m documenting a reproducible operational effect that becomes easier/more frequent if OP_RETURN capacity is raised. If you widen the vector after this is known, you’re assuming the ops risk. Reply to #4 (Ferib: “not executable / scanners optimize; you forced the scan; blacklists unrealistic”) Two clarifications: Executability is irrelevant to AV quarantine. My PoC shows ClamAV flags the block file because it carves a ZIP and matches a signature inside. Lots of AV/EDR products do container carving inside arbitrary binaries; on-access, scheduled, backup, or NAS scans are enough to trip it. I didn’t need to run code — just store bytes and let the scanner do its job. I didn’t “force” anything unusual. clamscan is a stand-in for the many default/scheduled/on-access scans people actually run. Enterprises often scan large binaries and archives by policy; home users have Defender/others doing scheduled passes. One engine firing is all it takes to break someone’s node or backup chain. Re: blacklists — agree, a consensus-level blacklist is brittle and out of scope. I’m not asking Core to curate signatures. My post is a proof that embedding is trivial and block-level quarantine happens. That’s it. Reply to #5 (achow101: “not new; EICAR in chain for a decade; obfuscation exists”) Appreciate the history. I’m not claiming novelty of “bytes in chain data.” What I’m adding is a current, reproducible artifact on v30.0rc1 where a stock AV quarantines the raw block file due to an OP_RETURN that’s a valid ZIP with a known signature. Obfuscation of chainstate helps with past incidents, but blk*.dat remains plaintext and a scan target. Quarantine of a blk file still means node stalls/re-index/re-download and backup headaches. If OP_RETURN capacity is lifted, the ease/frequency of dropping AV-bait increases (especially with recognizable containers that carving engines tend to scan). That’s the only point I’m making here. What this is • A reproducible regtest proof that an AV can quarantine a raw Bitcoin block when signature-bearing bytes are embedded in OP_RETURN.   • The payload is a ZIP containing the standard EICAR test file. No real malware. No code execution.   • Confirms at least one mainstream AV (ClamAV) flags the block file itself.   • This is not a protocol bug; it’s an operational disruption vector that becomes easier and more frequent if OP_RETURN capacity is increased.

Maybe the vulnerability is reproducible on a Windows system. That's what over 90% of cyberattacks target. Perhaps advanced endpoint AV software would be able to flag the EICAR string itself and then lock down access to the file to just Bitcoin Core. But personally I think the outcome will be the same as ClamAV for consumer AV programs. It's more of a DoS risk though. Imagine taking down a bunch of nodes just by embedding a problematic string inside a transaction. Core is fuzz-tested a lot though, so hopefully it can handle such exceptions gracefully.

Thanks — quick clarifications: • This isn’t a Core crash or fuzzing case. It’s an operational DoS via quarantine: the AV/EDR sees signature-bearing bytes (here, a ZIP with EICAR) inside the raw block file and quarantines or locks it. Core then hits IO/missing-file and the node stalls until re-download/reindex. • OS-agnostic. The PoC works because many AVs carve/scan archives found inside larger binaries. That behavior exists on Linux (proved with ClamAV) and also on Windows/macOS in various engines. It’s about how scanners treat containers embedded in arbitrary files, not about executing anything. • “Advanced endpoint software will only allow Bitcoin Core to access blk files” — some products can be tuned that way, but default/scheduled/on-access scans, backup scanners, or NAS-side scanners still quarantine. That’s downtime and operator friction, especially for non-enterprise node runners. • The risk scales with ease/frequency. If OP_RETURN capacity is raised, it becomes easier to drop recognizable payloads (like ZIPs) that many engines scan by default. That’s the whole point of the repro: block-level quarantine happens. TL;DR: Not a protocol vulnerability; a repeatable ops disruption. I’ve posted a regtest script so anyone can verify on their setup. Windows test script : Windows batch (.bat) test script that mirrors the Linux PoC. put it all in a file named BTC-test-win.bat, edit the AV configuration at the top, then double-click or run from cmd. it will: start a regtest node in a temp datadir (does not touch mainnet/testnet) create a ZIP with the EICAR test file (safe) embed that ZIP in OP_RETURN, mine 1 block export the raw block and verify OP_RETURN is a real ZIP scan the block file and the payload ZIP using your AV command notes Edit the AV config at the top: ClamAV example (as prefilled): AV_CMD=C:\Program Files\ClamAV\clamscan.exe AV_ARGS=--infected --no-summary --scan-archive=yes %FILE% Windows Defender example: AV_CMD=C:\Program Files\Windows Defender\MpCmdRun.exe AV_ARGS=-Scan -ScanType 3 -File %FILE% Requires Bitcoin Core (30.0rc) for Windows (bitcoind.exe, bitcoin-cli.exe) in PATH or adjust the BITCOIND / BITCOINCLI variables to full paths. Uses PowerShell to write EICAR, create ZIP, and handle hex/binary conversion and JSON parsing. It runs only on regtest and writes everything under a timestamped btc-av-opreturn-... folder in your current directory. I only have Linux so can't test it myself. TL;DR — Don’t increase OP_RETURN This isn’t about code execution. It’s about AV/EDR quarantining raw blk*.dat when malware signature-like bytes are embedded in transactions. That creates an operational DoS for node runners, backups, and restores. We’ve shown it’s trivially reproducible today. Why this matters Nodes stall: quarantine or lock on blk*.dat → IO errors → reindex/re-download → downtime.Backups break: archive/NAS scanners nuke snapshots, even if live datadir is excluded.Friction centralises: non-enterprise operators won’t hand-tune AV; more false hits = fewer healthy nodes. Real-world precedent when software is flagged as “malware” CCleaner (2017): poisoned update → millions affected → lasting reputation loss and churn.SolarWinds (2020): supply-chain compromise → enterprise/government blacklists and contracts lost.HandBrake (2017): hacked download server → ransomware in “official” installer → user trust cratered. Point Increasing OP_RETURN capacity widens the on-chain delivery path for recognisable payloads (ZIPs, signatures) that mainstream AVs already carve and scan inside large files. More capacity = more incidents. If you push this change after disclosure, you own the ops risk. I’ve shown with the tests, which you can easily reproduce with the scripts I have uploaded, AV detectors will detect malware signature embedded in the op_return. Update sent to Bitcoin Core Security Summary (updated): AV software identified malware signature in blockchain. By enclosing the canonical EICAR test string inside a ZIP and embedding that ZIP in an OP_RETURN output, AV/EDR engines can and do detect “malware” in the raw block file (blk*.dat). In my regtest runs (Core v30.0rc1), ClamAV flagged the exported block file itself (and the extracted payload). This creates an operational DoS risk for node operators: quarantine or lock leads to I/O errors, reindex or re-download, and downtime. Backups are also impacted when archive or NAS scanners hit the same bytes. Why this matters Nodes stall: quarantine of blk*.dat causes I/O failures and reindex or re-download loops.Backups break: offline or NAS scans can nuke snapshots even if the live datadir is excluded.Centralizing pressure: most non-enterprise operators will not hand-tune AV or EDR; more incidents means fewer healthy nodes. Context and precedent When software is flagged as “malware” (false positive or real compromise), the fallout is real. Examples often cited: CCleaner (2017), SolarWinds (2020), HandBrake (2017). Here we show a repeatable on-chain trigger for similar quarantine behaviour. Ask Please do not increase OP_RETURN capacity without explicitly considering this operational risk. Increasing capacity widens the on-chain delivery path for recognizable containers (ZIPs) that engines already carve and scan inside large files. Repro scripts and discussion • Linux regtest scripts to reproduce the ZIP-in-OP_RETURN detection: • Bitcointalk link to this discusion Ha Ha Ha Ha Ha!!!!! I was unable to send security the test script in the email because :

Wouldn't most live AV software stop the block from ever being downloaded? I know I have had some issues with false positives coming in and the EDR stopping it before it even got written to the disk. And since EICAR is 68 bytes you can already fit it in OP_RETURN and nobody cares. Which IMO they should not. -Dave

Thanks, Dave. On EICAR size: A valid ZIP of EICAR is well over 80 bytes, so the ZIP example needs larger capacity or other data paths. The point stands: the block file can be quarantined when engines carve embedded archives and see a known signature. Many engines explicitly look for ZIPs inside large binaries; they are less likely to act on a short partial signature. That is why a larger OP_RETURN increases risk. Agreed, the 68-byte EICAR string already fits in today’s OP_RETURN. My PoC is not “we need a bigger OP_RETURN to embed EICAR”. It is “engines that carve containers from arbitrary binaries will flag the block file itself when a ZIP with a known signature is embedded”. Increasing OP_RETURN does not enable the idea; it increases the ease, size, and frequency (for example larger or nested archives, multiple signatures), which means more engines flag and more nodes get disrupted. On the live-AV point: Whether an engine blocks pre-write (stream/on-write) or post-write (on-access or scheduled or backup or NAS), the node still hits I/O failure and stalls until re-download and reindex. From the operator’s perspective, it is the same operational DoS. What is actually new here: Not “bytes can be put on chain” — that is known. The new part is a current, reproducible artifact where a mainstream AV flags the raw block file due to a ZIP-in-OP_RETURN on v30 regtest, with paste-ready proof. Bottom line: Block-level quarantine is real and reproducible today. Making OP_RETURN bigger would make incidents more common and would enable larger malware signatures, not just the test string. That is the risk I am documenting.

Can you scan it on https://www.virustotal.com/gui/home/upload and share the results link?

Cheers for the idea 1440000bytes :  The point of having the script text  is that someone can just copy it into a file and run it, so anyone else can run the test easily. What I did was :  point them to this discussion thread - in the version of the email without the script, where they can just copy and paste it. However, I didn't think of a screenshot, it's a good idea and I should have done that as well. Wrapper

I think the only reason why we haven't seen such as DoS happen in action is because most people are running their nodes on Linux with no AVs. Maybe a couple of folks use Red Hat or CentOS which contains SELinux, but I think SELinux might be different from AVs in that it doesn't quarantine anything and it's more of an exploit-buster. That's a bit ironic. Maybe you should try putting it inside a Pastebin.

Good points, NotATether — and thanks for the merit. Linux without AV Many home node runners don’t run AV on Linux, agreed. But plenty of environments do have scanners/EDR on Linux (CrowdStrike, SentinelOne, Defender for Endpoint for Linux, Sophos, etc.). More importantly, backup/NAS scanners and email/CI gateways scan artifacts regardless of the OS on the node. That’s why this shows up as an operational issue even if the node host itself has no AV. Gateways prove the point My security email bounced because the gateway scanner detected “malware” in the attachment. That’s exactly the class of disruption I’m documenting: the same bytes that land in blk*.dat trigger quarantine or blocking in downstream systems (mail, backups, artifact repos), not just on-access AV. SELinux vs AV Right — SELinux is policy confinement, not signature quarantine. It won’t quarantine blk*.dat; AV/EDR and content-security gateways do. The DoS here comes from quarantine/lock or delete of files the node or ops pipeline expects to exist. Why OP_RETURN size matters anyway EICAR raw (68 bytes) already fits today, but a valid ZIP with the test string does not fit in 80 bytes. Engines commonly carve/scan ZIPs inside large binaries; they are much more likely to act on a recognizable container than a tiny substring. Increasing OP_RETURN makes it trivial to drop ZIPs/nested archives/multiple signatures that more engines detect by default — leading to more incidents. FWIW, to share the repro without tripping mail filters: the scripts generate the test string at runtime from split/encoded pieces (no literal signature in the email/forum body). And the full Linux/Windows regtest scripts plus paste-ready proof are in the thread: Security disclosure: OP_RETURN embedding of Malware signatures into Blockchain

I was going to ask you yesterday - I feel like this problem can be mitigated by using a watchdog process to detect missing blocks or chain state and then use an RPC command, or even use the ZMQ channel to request for the specific block to be downloaded again. Such a program is not currently written, to my understanding.

Thanks, NotATether - that’s a constructive idea. A watchdog could help detect stalls faster. But this raises a bigger point: Bitcoin Core developers and random node operators are not liable to design, fund, and maintain new monitoring to offset a policy change. If a watchdog is the mitigation, a few questions need clear answers first: • Ownership: Who specifies it, writes it, audits it, and maintains it across Linux/Windows/macOS and different deployments?  • Funding: Who pays for ongoing maintenance, support, and incident response when it breaks?  • Integration: Is it shipped with Core, as a separate daemon, or left to each operator? How is it configured safely by default?  • Blast radius: Who is responsible if it false-positives, misses an event, or triggers a bad reindex and causes downtime or data loss?  • Supportability: Who provides docs, SLAs, and fixes when enterprise EDR, NAS scanners, or gateways behave differently? Until there is a concrete, owned mitigation plan with accountable parties and funding, asking thousands of operators to bolt on a watchdog just externalises the risk. My position remains simple: do not increase OP_RETURN without first owning the operational consequences and the mitigation.

Good points. I don't think Bitcoin Core will ever build this to be honest. It's something that would have to be maintained by a 3rd party and then maybe they can sell commercial support for it so that people don't have manually debug their watchdog configuration.

Emergency: please acknowledge test-fail in Bitcoin Core v30.0rc1 (AV quarantine of blk*.dat via ZIP-in-OP_RETURN) I have: • sent an email to the dev lists and security contacts,  • tried to open a GitHub issue (rejected), and  • posted a detailed thread here on Bitcointalk. Why is a bug affecting the next release not being acknowledged? Silence is not resolution, and ignoring the issue will not make it go away. Summary  This is not code execution. On v30.0rc1 (regtest), enclosing the canonical EICAR test string inside a ZIP and embedding that ZIP in OP_RETURN results in mainstream AV/EDR quarantining the raw block file (blk*.dat). This has been reproduced with public scripts. Impact  • Node stall: quarantine or lock leads to I/O errors and reindex or re-download.  • Backups: archive or NAS scanners nuke snapshots even if the live datadir is excluded.  • Risk increases if OP_RETURN capacity is raised, since recognizable containers are easier to embed. Repro (safe, regtest)  • Bitcoin Core: v30.0rc1  • Results: ClamAV flags the exported block file and the extracted payload  • Scripts: Linux and Windows batch provided in my thread Thread with scripts and paste-ready proof  Security disclosure: OP_RETURN embedding of Malware signatures into Blockchain Ask  • Please confirm receipt and open a tracking reference for v30.0rc1.  • Consider the operational risk in any OP_RETURN changes before release.

@achow101 specifically mentioned block obfuscation feature is exist. But your reply state blk*dat remains plaintext, which isn't true since Bitcoin Core 28.0. Although it seems XOR only applied for new fresh IBD/sync.

Headline: Block XOR does not cure the risk from increasing OP_RETURN size. Even with v28+ XOR on blk*.dat, the quarantine problem remains. The moment block bytes are handled in plaintext anywhere in the workflow, AV/EDR can still flag them. ABCbits - thanks for the correction and the links, appreciated. You are right: since Core v28.0, new IBD stores blk*.dat XOR-obfuscated by default (). My earlier “plaintext” wording was too broad. Why XOR does not remove the risk: • Plaintext appears in normal ops. The PoC scans a plaintext export created by to . Exports, shares, and archives are plaintext and get flagged.  • Per-node only. Each node has its own XOR key. XOR is local at rest, not a network protection. The same bytes become plaintext when exported, backed up, or shared.  • Validation needs plaintext. Core de-XORs to process and serve data. Filters that hook reads can act on plaintext at that point.  • Mixed or non-XOR datasets exist. Nodes upgraded from pre-28 keep older blk files unobfuscated. Some deployments disable XOR or use non-Core tooling that writes plaintext copies.  • External scanners act outside Core. Backup or NAS scanners, email or CI gateways, and artifact repos scan plaintext copies and streams regardless of on-disk XOR. Restating the test and impact: • Test: embed a ZIP with a known signature via OP_RETURN on v30.0rc1 (regtest).  • Result: AV quarantines the raw block content when seen in plaintext (exported block and extracted payload).  • Impact: I/O errors, stalled nodes, reindex or re-download, broken backups and NAS scans.  • Risk scaling: increasing OP_RETURN makes recognizable containers easier and more frequent, which increases incident frequency. I am extremely concerned about the effect of increasing OP_RETURN, particularly after it failed my test immediately. This puts Bitcoin users at risk because the danger is no longer theoretical. I am alarmed at the lack of acknowledgement; this is concerning.  Question: can someone point to where this specific operational risk was discussed in the development process, for example on GitHub issues, PR reviews, or the mailing list?