In blockchain technology, even small mistakes can cause big problems. Imagine if sending an empty request to a node’s API could crash the entire node. Hard to believe? That’s exactly what we found in the Astria-geth node. In this article, we’ll explain how we discovered this bug, how it happened, and how it was fixed. We’ll also discuss why it’s so important to check for errors in blockchain systems.
The problem was in the BatchGetBlocks method of Astria-geth’s gRPC API. This method is supposed to handle requests for multiple blocks using an array of identifiers. However, it assumed that this array, Identifiers, would always have at least one item. Without checking, the method tried to access the first item in the array:
But what happens if the array is empty? Since Identifiers is a dynamic array, it can have zero items. If we send an empty array, the method tries to access an item that doesn’t exist. This causes a runtime error and crashes the node. In simple terms, sending an empty message to this method can shut down the node.
We were working with a local rollup node, set up according to the Astria documentation. To test the node’s API, we used a technique called fuzzing. This means we sent a lot of unexpected inputs to see how the system would react.
During our testing with one of our internal fuzzers, we sent an empty BatchGetBlocksRequest to the node. Right away, the node crashed and gave us an error message that pointed to the issue:
This error shows that the node tried to access an item at index 0 in an array that has zero items. In other words, it tried to get something that wasn’t there.
In the server.go file (GitHub link), the method logs the incoming request like this:
But in the .proto file that defines the request (execution.proto), the Identifiers field is a repeated field. This means it’s a dynamic array that can have zero or more items:
Since it’s possible for Identifiers to be empty, the method should check if the array has any items before trying to access them. Not doing this leads to an out-of-bounds error, crashing the node.
Even though the gRPC endpoint is usually only accessible from the local machine (loopback interface) and meant to be used by trusted services, this bug is still a concern. If the endpoint is misconfigured or exposed in certain ways, someone could exploit this bug to crash the node by sending empty requests.
This shows why it’s so important to write code that can handle unexpected inputs. In systems like blockchain nodes, where reliability is crucial, unhandled errors can cause serious issues.
After we reported the bug, the Astria team quickly addressed it. The fix was implemented in Pull Request #40. In addition to fixing the specific issue in the BatchGetBlocks method, they introduced multiple validation functions in the rest of the code. These functions are designed to validate inputs across different methods, helping to prevent this kind of bug from being reintroduced in the future.
This bug shows how a small mistake—like not checking if an array is empty—can have big consequences. In blockchain nodes, where uptime and reliability are critical, such errors can undermine trust in the network.
The Astria team responded quickly to fix the issue, demonstrating their commitment to security and stability. However, they considered the bug to be non-critical, since the gRPC API is intended for trusted services and not meant to be exposed publicly. This incident serves as a reminder to all developers of the importance of validating inputs and handling errors properly. By following best practices and thoroughly testing our systems, we can build applications that are more reliable and secure.
Finding this bug was a valuable experience that highlights the importance of community involvement in the blockchain world. Security is something we all share responsibility for, and sharing discoveries like this helps make the entire ecosystem stronger.
We encourage other developers and researchers to report vulnerabilities responsibly when they find them. Working together, developers and security researchers can not only fix individual bugs but also promote a culture of security awareness and continuous improvement.
By learning from situations like this, we can all help build more secure and reliable blockchain networks that can stand up to both accidental errors and malicious attacks.
Patrick Ventuzelo / @Pat_Ventuzelo
Salim Dardouchi
Founded in 2021 and headquartered in Paris, FuzzingLabs is a cybersecurity startup specializing in vulnerability research, fuzzing, and blockchain security. We combine cutting-edge research with hands-on expertise to secure some of the most critical components in the blockchain ecosystem.
Contact us for an audit or long term partnership!
Learn which kind of security vulnerabilities/bugs can be found inside Go code, how to detect them statically and automatically using fuzzing techniques.
🎞️ 90+ videos / ⏱️ 7.5+ hours / 👨💻 25+ exercises
Cookie | Duration | Description |
---|---|---|
cookielawinfo-checkbox-analytics | 11 months | This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics". |
cookielawinfo-checkbox-functional | 11 months | The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional". |
cookielawinfo-checkbox-necessary | 11 months | This cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary". |
cookielawinfo-checkbox-others | 11 months | This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other. |
cookielawinfo-checkbox-performance | 11 months | This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance". |
viewed_cookie_policy | 11 months | The cookie is set by the GDPR Cookie Consent plugin and is used to store whether or not user has consented to the use of cookies. It does not store any personal data. |