After following responsible disclosure practices and providing multiple extensions beyond the standard disclosure timeframe, I am publishing details about a Remote Code Execution (RCE) vulnerability in Hive Engine's smart contract implementation. The issue was initially disclosed to the Hive-Engine team on October 6, 2024 over 4 months ago, but this issue has been known within the community for a longer period of time. Multiple extensions to the initial disclosure date of January 6 2025 were given.
The core issue lies in Hive Engine's use of the VM2 package for smart contract execution. This package has been deprecated by its maintainers due to multiple unresolvable security vulnerabilities that allow sandbox escape and remote code execution. Read more about the vulnerability here: https://security.snyk.io/vuln/SNYK-JS-VM2-5772823 and https://github.com/patriksimek/vm2/issues/533.
From the npm page for the package
There are two potential paths for exploitation:
Compromise of the deployment key - If an attacker gains access to the smart contract deployment key, they could deploy malicious code that breaks out of the VM2 sandbox.
Malicious node injection - Since the system pulls contract deployment data from the chain, a malicious Hive node could potentially inject unauthorized deployments
The Hive Engine team is working on migrating to isolated-vm as a replacement for VM2. While they have developed an implementation and merged it into the main branch(https://github.com/hive-engine/hivesmartcontracts/pull/83), it was later reverted for unknown reasons. I was initially told that the implementation was slow, but was not provided any communication regarding this after the merge was reverted.
Until the migration to isolated-vm is complete, node operators should:
The hive engine team should:
It looks like between the writing of this post and the publishing of it, there was a release made that switches vm2 out for isolated-vm made on hive-engine: https://github.com/hive-engine/hivesmartcontracts/releases/tag/ivm_v1.0.0.
I would highly recommend all node operators to upgrade to it, if it is deemed stable by the developers.
From 
There’s a potential RCE in hivesmartcontracts(https://github.com/hive-engine/hivesmartcontracts). The VM2 package has multiple publicly released exploits which can be utilized to break out of the VM and execute code on the host system and as such the package has been deprecated by it’s maintainers(https://www.npmjs.com/package/vm2). Anyone with the keys to deploy a smart contract(including malicious actors who get the key) can deploy code to run code on the host system.
Alongside that, since hivesmartcontracts gets data for new contracts via the chain, a malicious node can inject a malicious deploy and get access to the system without the deploy key needing to be exposed.
Some potential solutions are:
Migrating to isolated-vm which doesn’t have any known VM breaks at the latest version.
Changing the smart contract deployment process to not go off the chain, but require code changes whenever a new version of a contract is deployed.
From 
This is in reply to your e-mail that reads: "There’s a potential RCE in hivesmartcontracts(https://github.com/hive-engine/hivesmartcontracts). The VM2 package has multiple publicly released exploits which can be utilized to break out of the VM and execute code on the host system and as such the package has been deprecated by it’s maintainers(https://www.npmjs.com/package/vm2). Anyone with the keys to deploy a smart contract(including malicious actors who get the key) can deploy code to run code on the host system.
Alongside that, since hivesmartcontracts gets data for new contracts via the chain, a malicious node can inject a malicious deploy and get access to the system without the deploy key needing to be exposed.
Some potential solutions are:
Migrating to isolated-vm which doesn’t have any known VM breaks at the latest version.
Changing the smart contract deployment process to not go off the chain, but require code changes whenever a new version of a contract is deployed."
-----------------------------------------------
We have received your e-mail to the security address. Thanks for reporting it, and we will definitely keep it in mind for the future, but as I mentioned previously via Discord DM, such an extensive redesign is beyond the capabilities of our present team. We simply don’t have the resources for that kind of effort, and will not be able to undertake such a project until / unless the team grows and we are able to expand again to a point where it becomes feasible. As I also mentioned previously, we would like to further decentralize smart contract deployment procedures, but that is also not feasible right now.
We consider the risk to be minimal, as there are code checks to prevent any accounts besides hive-engine from attempting to deploy a smart contract. If any third party tried, the deploy request would simply be ignored as it wouldn’t be broadcast from an allowed account.
From,
Cryptomancer
Hive Engine Dev Team
From
Hi,
As stated in the initial report, “since hivesmartcontracts gets data for new contracts via the chain, a malicious node can inject a malicious deploy”, the cause for concern here isn’t a random account making a broadcast, but a malicious hive node returning back fake data with an authorized account. If the deployment key does get leaked(single key here as multi sig is not used) then that’s another way that a malicious attacker can run any code they want.
Some more things to potentially help out:
Add multi sig to the deployment account.
Change guidance to only stream off hive nodes controlled by the user running the hive-engine node.
From
What you describe when you say "the cause for concern here isn’t a random account making a broadcast, but a malicious hive node returning back fake data with an authorized account", is essentially a hypothetical weakness of pretty much any blockchain. This is not Hive Engine specific, it could be applied to any program that performs actions based on blockchain transactional data. Of course node operators should only be querying Hive blockchain data from trusted Hive nodes. And if any top witness were to behave badly, they would quickly be unvoted from their witness position & shunned by the community.
If such a hypothetical attack did occur, it is likely that not all HE node operators would be streaming data from the same Hive node anyway, so the action would result in a consensus breaking minority fork while majority consensus continues to be maintained. This also starts to get into the realm of how secure the blockchain is from hypothetical so-called "51% attacks", which is more of an academic matter for debate related to DPoS algorithms in general.
If you would like, I can add a couple sentences to our wiki documentation urging HE node operators to only stream Hive blockchain data from top nodes that they trust, or for maximum security only from a Hive node that they themselves operate.
From
The issue here isn’t with actions happening on the chain. VM2 has VM breaks(please see the link in my original email), which a malicious node operator(it might not even be the operator, hacks do happen) and with the vm break, code can be run at the system level, exposing whatever is on the system to being attacked. Breaking the chain is fine, and as you said it’s self correcting as the node wouldn’t be in consensus. But the chain isn’t the concern here, it’s the host machine.
From
Following up to see if your stance is still that this isn’t an issue? Exploit will be publicly released on Jan 6th 2025 as previously discussed if that is still the case. I’ll follow up again late December to see if there’s any changes.
From 
We maintain that the possibility of this happening is low risk and does not warrant emergency mitigation efforts. Witnesses are encouraged to follow the usual best practices such as using a dedicated Hive account for witnessing and not storing any other sensitive data on publicly available nodes. That said, the continued use of VM2 obviously isn't ideal. One of our developers will explore the feasibility of upgrading to isolated-vm, time permitting. However, we are unable to provide any timeline regarding when, or if, such an upgrade will be undertaken.
From
Forgot to CC Aggroed on previous reply...
From
Following up again as today is the public disclose date, is there any updates?
From 
eon has a fix, but block processing is too slow at the moment to push it to production
From
I’ll hold off on public disclose for 1 more month then. The RCE will be released to the public on February 6th 2025. If your solution doesn’t work, please consider using one of the other recommended solutions in the meantime.
From
Has there been any progress made towards this?