On October 11th, 2022, @ajtowns publicly disclosed a zero-day consensus fault in btcd in a github issue. The issue was posted on a public repo viewable by anyone.
According to gharchive.org logs, the github issue remained up for at least 10 hours before being deleted. The original github issue resided at https://github.com/Roasbeef/btcd/issues/35
The issue and comment can be found and reconstructed from the following JSON dumps:
The Issue (https://data.gharchive.org/2022-10-11-3.json.gz)
I think this entry is wrong? If you're limited to bip141 or bip342 tapscript, then the number of witness entries is constrained by the stack size limit (1000 entries, plus 3 for the tapscript itself, control block and annex); but if you're not using tapscript, or the tapscript has an OP_SUCCESS opcode, that doesn't apply, and you could have almost 4M 0-byte witness entries (encoded as 5-byte varint counting the witnesses, 3.9M 0 bytes to say each witness has length zero, then the script, then the control block).
Such a transaction would be non-standard in two ways though: 500k entries is more than 400k witness bytes, and 100kvb=400kb is the standardness limit; and using an OP_SUCCESS or non-tapscript script in a taproot output would also be non-standard anyway. So violating this assumption would require a miner's cooperation.
His next comment (https://data.gharchive.org/2022-10-11-13.json.gz)
Here's a signet blockchain that demonstrates the bug; signetchallenge=00143098516d466b4bd3166ad5259bc8ca8f7682b8a2, should be able to use zcat DEMO-btcd-34.gz | while read a; do echo \"$a\" | bitcoin-cli -signet -stdin submitblock; done and a connected btcd will then error with [ERR] PEER: Can't read message from X.X.X.X:XXXXX (outbound): MsgTx.BtcDecode: too many witness items to fit into max message size [count 1000005, max 500000].