let header: V1MessageHeader = deserialize_partial(&data)?.0;
data.resize(24 + header.length as usize, 0);
reader.read_exact(&mut data[24..]).await?;
The other vulnerability is regarding the rate-limiting mechanism implemented in Floresta. It checks if a peer is sending more than 10 messages per second; if so, the peer is disconnected. However, the counter (messages) was never incremented, so it was always zero, and the mechanism had no effect.
// divide the number of messages by the number of seconds we've been connected,
// if it's more than 10 msg/sec, this peer is sending us too many messages, and we should
// disconnect.
let msg_sec = self
.messages
.checked_div(Instant::now().duration_since(self.start_time).as_secs())
.unwrap_or(0);
if msg_sec > 10 {
error!(
"Peer {} is sending us too many messages, disconnecting",
self.id
);
return Err(PeerError::TooManyMessages);
Both vulnerabilities are fixed in https://github.com/getfloresta/Floresta/pull/880.
]]>VerifyTxScript function against Bitcoin Core’s VerifyScript. These functions are consensus critical and they are responsible for verifying scriptPubKey and scriptSig.
During the execution, we got a crash with the following scripts:
scriptSig: 5b00
scriptPubKey: 00004c020f600100009f9a000102020202004e000064a2a2a2a2a2000000a2a2a2a2a2a2a2a2
The error returned by Bitcoin Core is SCRIPT_ERR_BAD_OPCODE that was being returned due to OP_PUSHDATA4 claiming more bytes than are available.
GetOp() attempts to advance pc by 100 bytes, overshoots the end of the script buffer, and then, returns false. Looking at gocoin’s code, the similar function to Core’s GetOpcode is GetOp:
func GetOpcode(b []byte) (opcode int, ret []byte, pc int, e error) {
// Read instruction
if pc+1 > len(b) {
e = errors.New("GetOpcode error 1")
return
}
opcode = int(b[pc])
pc++
if opcode <= OP_PUSHDATA4 {
size := 0
if opcode < OP_PUSHDATA1 {
size = opcode
}
if opcode == OP_PUSHDATA1 {
if pc+1 > len(b) {
e = errors.New("GetOpcode error 2")
return
}
size = int(b[pc])
pc++
} else if opcode == OP_PUSHDATA2 {
if pc+2 > len(b) {
e = errors.New("GetOpcode error 3")
return
}
size = int(binary.LittleEndian.Uint16(b[pc : pc+2]))
pc += 2
} else if opcode == OP_PUSHDATA4 {
if pc+4 > len(b) {
e = errors.New("GetOpcode error 4")
return
}
size = int(binary.LittleEndian.Uint16(b[pc : pc+4]))
pc += 4
}
if pc+size > len(b) {
e = errors.New(fmt.Sprint("GetOpcode size to fetch exceeds remainig data left: ", pc+size, "/", len(b)))
return
}
ret = b[pc : pc+size]
pc += size
}
return
}
The issue is that gocoin was using Uint16 in the context of OP_PUSHDATA4 instead of using Uint32. The size field is explicitly defined as a 4-byte little-endian unsigned integer.
Thanks Piotr Narewski for responding to my report and fixing the bug so quickly. Also, he told me to go ahead and disclosure it.
]]>bitcoinfuzz, especially for the target that evaluates Bitcoin scripts.
Abhiramjampani worked on it and opened a PR recently. It is missing addressing some key concerns, brought by Erick, which is why the PR has not been merged yet. However, as part of the review, we left this target running for some time, and it quickly crashed with the following script, which gocoin returned success and Bitcoin Core false:
-1 OP_HASH256 OP_0NOTEQUAL
I first checked that the target was properly implemented and then jumped to understand where the bug was happening. Conceptually, I understand that this is script is not valid, because the hash generated by the opcode OP_HASH256 does not fit in the 4 bytes required by the arithmetic opcodes (OP_0NOTEQUAL, in this case). The gocoin’s code - at that moment - to parse this opcode was:
d := stack.pop()
if checkMinVals && len(d) > 1 {
if DBG_ERR {
fmt.Println("Not minimal bool value", hex.EncodeToString(d))
}
return false
}
As can be seen, it was using pop to get the element instead of using popInt, which makes it not fail for values longer than 4 bytes. The fix was addressed here by Piotr and can be seen in the following diff:
- d := stack.pop()
- if checkMinVals && len(d) > 1 {
- if DBG_ERR {
- fmt.Println("Not minimal bool value", hex.EncodeToString(d))
- }
- return false
- }
- stack.pushBool(bts2bool(d))
+ stack.pushBool(stack.popInt(checkMinVals) != 0)
Thanks Piotr Narewski for responding to my report and fixing the bug so quickly. Also, he told me to go ahead and disclosure it.
]]>First of all, I noticed that Floresta, when sending addresses to other peers, was not respecting the rule of sending at most 1’000 addresses per message. This number is specified in BIP 155, where the addrv2 message is defined. The BIP says:
One message can contain up to 1,000 addresses. Client SHOULD reject messages with more addresses.
Violating this limit could cause Floresta nodes to be disconnected and even banned from other full-node implementations such as Bitcoin Core. Also, at the same time, Floresta was not respecting this number when sending addresses, and it was also not verifying it when receiving addresses, resulting in the acceptance of a large number of addresses per message.
Another issue identified in Floresta’s handling of incoming addrv2 messages is the storage and propagation of addresses belonging to networks that Floresta neither supports nor can reach. As a result, Floresta may store and relay addresses that it has no ability to validate.
This behavior directly contradicts the guidance provided in BIP155, which states:
Clients SHOULD NOT gossip addresses from unknown networks because they have no means to validate those addresses and so can be tricked to gossip invalid addresses.
Relaying such addresses increases the risk of polluting the address gossip network with invalid or malicious entries.
Finally, Floresta relies on Rust’s standard library to determine whether an IP address is private. However, the standard library does not classify the 0.255.255.255 address range as private. As a consequence, Floresta currently accepts and processes addresses within this range, despite them being non-routable and invalid for peer-to-peer communication.
Shortly after starting the fuzzing campaign — thanks to an already good corpus — we encountered a crash with the following script:
Hex: 000360670000005b770100000000005b770100000000000008777760779f00000877776077
Asm: 0 26464 0 0 11 OP_NIP 0 0 0 0 0 11 OP_NIP 0 0 0 0 0 0 777760779f000008 OP_NIP OP_NIP 16 OP_NIP
When debugging the run output, we observed that NBitcoin returned false while Bitcoin Core returned true. Since this represented a clear consensus discrepancy, we manually reviewed the script to verify whether it was valid. The analysis confirmed that the script is valid, meaning that Bitcoin Core’s behavior is correct — and that the discrepancy originated from a bug in NBitcoin.
Initially, this was surprising, since the only opcode in the script is OP_NIP, which removes the second item from the top of the stack — a relatively simple operation. NBitcoin’s implementation of this opcode is shown below:
case OpcodeType.OP_NIP:
{
// (x1 x2 -- x2)
if (_stack.Count < 2)
return SetError(ScriptError.InvalidStackOperation);
_stack.Remove(-2);
break;
}
To better understand the issue, we created a test case and stepped through EvalScript. During execution, an IndexOutOfRangeException was thrown when processing the third OP_NIP.
Further investigation revealed the following:
When the underlying array is at full capacity (e.g., 16 elements), and
_stack.Remove(-2)is called, the Remove operation must delete the item at index 14 and shift the subsequent elements down. During this shift, the implementation may attempt to access _array[16], which does not exist, leading to the IndexOutOfRangeException.
Interestingly, this bug was only discovered through differential fuzzing, because the discrepancy in return values between Bitcoin Core and NBitcoin highlighted the problem. Since the exception occurs within a try/catch block (preventing a full crash), fuzzing by itself might not catch it.
Timeline:
2025-10-23 - Bruno Garcia reports the issue to Nicolas Dorier
2025-10-23 - Nicolas Dorier confirmed the issue
2025-10-23 - Nicolas Dorier opens #1288 to fix it
2025-10-23 - NBitcoin 9.0.3 is released
Note: There is no known node implementation using NBitcoin, so there is no risk of chain split. That’s why we’re making it public.
]]>The first targets that I wrote were descriptor and miniscript parsers, where we found many bugs. The first one we reported was in sipa’s miniscript implementation, which incorrectly considered pk()() as a valid policy because it identifies )( as the name. Currently, we have many other targets like: script evaluation, descriptor parse, miniscript parse, addrv2, psbt, address parse, and others. We plan to expand and work on additional targets in the near future.
So far, we discovered and reported over 35 bugs in projects such as btcd, rust-bitcoin, rust-miniscript, Embit, Bitcoin Core, Core Lightning, LND, etc. Examples include: many implementations using the incorrect type for the key’s type value for PSBTs, the CVE-2024-44073 of rust-miniscript, panic on btcd’s PSBT parser (https://github.com/btcsuite/btcd/issues/2351), Embit incorrectly pointing a miniscript as valid (https://github.com/bitcoinfuzz/bitcoinfuzz/issues/113), Core Lightning accepting invoices with non-standard witness address fallbacks that other implementations correctly reject (https://github.com/ElementsProject/lightning/pull/8219).
We currently integrate and support the following projects:
There is a PR (under review) that integrates libbitcoin. We welcome any PR that integrates more projects into bitcoinfuzz. However, we intend to review the support of some implementations since an immature implementation can hinder differential fuzzing with simple issues. For example, Embit’s miniscript/descriptor implementation is still incomplete, with many fragments not supported. We also experimented with Mako support, but decided to remove it because the project is not currently being maintained.
Differential fuzzing of Lightning implementations is proving to be highly valuable.. To advance this effort Erick Cestari and Morehouse have joined the project. Erick began working on it as a Vinteum fellow, mentored by Bruno and Morehouse, and more recently received a full grant from Vinteum. So far, bitcoinfuzz includes targets for BOLT11 invoice decoding and BOLT12 offer decoding. There are also open pull requests adding lightning-kmp module for invoice deserialization, BOLT12 invoice request decoding, adding Eclair module for invoice deserialization, and more.
One advantage of applying differential fuzzing to Lightning implementations is that the Lightning Network has a well maintained specification. It means that when we find any discrepancy, we can reference the spec to determine the correct behavior. This is not the case for Bitcoin protocol implementations, where we mostly rely on Bitcoin Core as the reference. However, we have seen that differential fuzzing is also a good tool to improve the Lightning spec itself. From our experience, the specification is not always clear and often leaves room for improvement. As an example, one of the bitcoinfuzz trophies is a fix on the bolt12 specification, where a currency UTF-8 test vector lacked the required 3-byte length. As a result, many implementations were treating it as a case of malformed currency length instead of properly validating the UTF-8 encoding.
Also, bitcoinfuzz found bugs in virtually every implementation we support. E.g.
Some projects either lack support for fuzzing altogether or do not run their fuzz targets continuously. In these cases, we sometimes find bugs not because of the
“differential” aspect, but simply because the project has not been fuzzed at all. As an example, we found and reported a panic on btcd when parsing a PSBT due to a bug on the ReadTaprootBip32Derivation functions. This type of bug could have been easily caught by a basic fuzz target and a few minutes of execution. Similar cases occurred with rust-miniscript and lightning-kmp.
When we find a discrepancy between two implementations, it doesn’t always mean there is a bug in one of them. Sometimes small differences in behavior lead to interesting cases. For example, Bitcoin Core accepted miniscripts and descriptors with integer values containing trailing zeros or a positive sign (+) - e.g. older(+1) or older(000001), we believe that no one uses it in practice, however, since rust-miniscript rejects these cases, it would cause a discrepancy between them. That said, Bitcoin Core addressed it in https://github.com/bitcoin/bitcoin/pull/30577 by using ToIntegral instead of ParseInt64.
We recently opened a PR to integrate bitcoinfuzz into OSS-Fuzz, Google’s continuous fuzzing infrastructure for open‑source software. We believe that it would benefit our project a lot since we currently have a limited fuzzing infrastructure.
We created a repository where we share some corpora for our fuzzing targets, similar to Bitcoin Core’s qa-assets. However, we might keep two folders per target. One folder with all the inputs (maximizing coverage) and another excluding inputs that we know would trigger crashes - e.g. when we’re waiting for an implementation to fix a reported bug. The goal of the second folder is to make it possible to run bitcoinfuzz in CI/CD pipelines.
We have several directions we’re eager to explore. In the short term, our focus is on expanding bitcoinfuzz to be fully agnostic and compatible with multiple fuzzing engines beyond libFuzzer. We also plan to introduce new fuzzing targets—such as BOLT8, BOLT7, BOLT4 and ElligatorSwift/V2 Transport — and to strengthen our build system, with a particular emphasis on resolving linking issues.
]]>MAX_RECURSION_DEPTH was not being applied to prefix combinators like n:. It means the parser would take these “large” miniscripts and (iteratively) construct a tree with a very high depth. Then, this will stack overflow when doing any recursive operation. All the miniscript websites that help visualize/parse miniscript using rust-miniscript could crash with this input.
Affects: rust-miniscript 9, 10, 11 and 12.
TL;DR: Fuzzing
Bitcoinfuzz is a project that applies differential fuzzing in Bitcoin implementations and libraries. One of the targets does differential fuzzing with rust-miniscript and Bitcoin Core for parsing a miniscript from a string. So far, it found some bugs and has been helpful.
However, bitcoinfuzz had only support for libfuzzer and, at some point, Kartik suggested using some structures from Bitcoin Core to add support for more fuzzers in bitcoinfuzz. So, we started using bitcoinfuzz with AFL and, even fuzzing for a long time with libfuzzer, this bug was found in a few minutes with AFL. Just luck? We don’t know haha.
Both rust-bitcoin and rust-miniscript support fuzzing. Also, rust-miniscript has two targets called roundtrip_miniscript_str and roundtrip_miniscript_script which should be able to find this. However, the effectiveness of fuzzing depends on large campaigns, that is why it is important that both projects are continually fuzzed.
07/02/2024 - Reported the issue to Andrew Poelstra via e-mail.
07/02/2024 - Andrew confirmed the issue and cc’ed Sanket.
07/08/2024 - Sanket reproduced the issue and opened a PR addressing it.
07/08/2024 - I tested and confirmed the fix.
07/18/2024 - Andrew discovered that the issue could also affect parsing Miniscripts from Script.
07/18/2024 - Sanket started working on a fix for it.
07/20/2024 - Sanket opened a PR addressing it.
08/06/2024 - I verified that all fixes were backported. Andrew and Sanket confirmed this, and we proceeded to have a CVE.
We have found MANY bugs with bitcoinfuzz, and we have carefully analyzed all of them to know what is just a simple bug and what could be something more critical. Critical bugs/vulnerabilities have been reported to the according project team.
I would like to first thank Kartik Agarwala for working with me on this project. Kartik is a Summer of Bitcoin intern and he has done a brillant work. Also, thanks Andrew and Sanket for the cooperation on it and other cases.
]]>