aelf's production network has not yet formally returned to normal operation following a security incident first disclosed on August 18, 2026.
The project initially described unauthorized anomalous smart-contract activity and instructed Block Producer nodes to pause. Its August 26 incident update provided a much clearer technical picture: malicious contract activity could deliver encoded .NET assemblies into the node contract-execution path, creating capabilities that reached beyond ordinary smart-contract behavior and into the node environment.
As of the latest official update available early on August 27, the AELF MainChain and tDVV remained in controlled recovery. Public transaction submission was still disabled, and aelf had not formally reopened block production or ecosystem services.
This was more than a normal smart-contract exploit
The incident is notable because the suspected attack path crossed a critical security boundary.
aelf says an unauthorized smart contract could use blockchain transaction parameters to deliver encoded .NET assemblies and instructions into the node execution path.
The analyzed payloads included capabilities associated with:
- host command execution;
- collection of command results;
- attempted outbound communication;
- access to node-related key and configuration objects; and
- infrastructure reconnaissance.
A smart contract should ordinarily execute inside a tightly controlled environment. If contract-controlled input can reach host-level functionality or sensitive infrastructure, the risk expands from a single application to the validator or block-production layer.
That is why aelf's response has required a network-wide recovery process rather than simply disabling one contract.
What has been confirmed?
aelf says it has identified 155 transactions associated with the malicious activity.
Of those:
- 127 were on AELF;
- 28 were on tDVV.
The team also says it analyzed five unique .NET payload assemblies after removing duplicates.
At the same time, aelf has been careful not to overstate what the payload capabilities prove.
The existence of code capable of accessing keys, executing host commands or communicating externally does not prove that every targeted node executed every capability or that every credential was successfully exfiltrated.
Those questions remain part of the forensic investigation.
Were ordinary user wallets compromised?
aelf says it has not identified evidence that the incident caused unauthorized transfers of ordinary users' assets or exposed ordinary user wallet keys.
That is an important finding, but it comes with a limitation.
Node signing keys, keystore credentials and infrastructure credentials accessible from relevant node environments are being treated as potentially exposed. The project is rotating or revoking them as a precaution.
The distinction is therefore:
- ordinary-user wallet compromise has not been identified;
- node and infrastructure credential exposure remains an active concern.
Why is block production still paused?
Because patching the immediate code path is only one part of recovery.
aelf says it will not treat a reachable endpoint, a single node producing blocks or the existence of a patch as evidence that recovery is complete.
Before reopening affected services, the project is working through several recovery gates.
Block Producer key rotation
Signing keys and other credentials associated with participating Block Producers must be rotated or revoked where necessary.
Clean environment rebuilds
Relevant node and infrastructure environments are being rebuilt from trusted sources rather than simply returned to service in their prior state.
Ledger-continuity validation
aelf is performing deterministic replay and continuity checks across participating BPs.
That includes comparing transaction outcomes, balances, fees, logs and state commitments to ensure that the recovered network continues from a trusted state.
Permanent execution hardening
The project says it is working on permanent CodeOps and runtime-isolation changes, including tests against the known malicious payloads and equivalent variants.
Independent security review
Blocking findings from external review need to be closed before affected services reopen.
This explains why the recovery is taking longer than a normal maintenance window.
Public endpoints are not proof of recovery
One of the most useful parts of aelf's August 26 update is its warning about status signals.
Some public read-only or status endpoints may be reachable during recovery.
That does not mean:
- block production has formally resumed;
- transaction submission is open;
- cross-chain operations are safe;
- exchange deposits and withdrawals should restart; or
- ecosystem services have returned to normal.
Exchanges, bridges, custodians and infrastructure partners therefore need a separate official reopening notice rather than relying on a reachable RPC endpoint.
When will aelf restart?
There is no confirmed restart time yet.
aelf said it would publish another progress update on August 27 UTC even if there were no material changes.
At the time of this article's preparation, the August 26 statement remained the latest official incident update located by CEXVia.
The network should be considered in recovery until the project explicitly confirms that the relevant recovery gates have been met and identifies which services are reopening.
Why this incident matters beyond aelf
Most blockchain exploit reporting focuses on lost token amounts.
This event is different because the key risk concerns trust boundaries between contract code and node infrastructure.
Even if ordinary user balances ultimately remain intact, a vulnerability that can expose validator or node environments is operationally serious. It can affect consensus participation, signing credentials, infrastructure integrity and confidence in the execution sandbox.
For security analysis, that makes the event closer to a node-runtime compromise than a conventional dApp exploit.
CEXVia assessment
Risk level: High
No ordinary-user asset theft has been confirmed in the latest aelf update, which prevents a Critical classification based purely on losses.
However, the combination of halted production services, potentially exposed node credentials and host-level payload capabilities warrants a High rating.
The event remains unresolved until block production, transaction submission and ecosystem integrations are formally reopened after validated remediation.
FAQ
Is the aelf network back online?
Not formally. As of the latest August 26 update, the production networks remained in controlled recovery and public transaction submission was disabled.
Were aelf users' funds stolen?
aelf says it has not identified evidence of unauthorized transfers of ordinary users' assets from this incident.
Why did aelf stop Block Producers?
The network was paused after malicious smart-contract activity exposed risks involving the node execution environment and potentially sensitive infrastructure credentials.
When will aelf resume block production?
No confirmed restart time has been announced. The project says services will reopen in stages after key rotation, clean rebuilds, ledger validation, permanent fixes and independent security review.
*This article is for informational purposes only and does not constitute financial, legal or investment advice.*