Crypto theft reached $1.18 billion across 107 incidents in the third quarter, according to security firm Hacken, whose latest study shows that vulnerabilities in contract code and failures in access controls both remained major sources of losses.
The firm's October report covers July through September and puts the total 55% above the preceding quarter. Smart-contract exploits accounted for 48% of losses in its dataset, while access-control and operational failures represented 40%.
The findings challenge a narrow view of crypto security that treats a completed code review as sufficient protection for an entire service. Hacken highlights compromised suppliers, signing infrastructure and withdrawal systems alongside recurring software vulnerabilities.
Contract review covers only part of an operating system
A smart contract is one component of a service. Assets can also depend on who controls administrator permissions, how transaction approvals are produced and which outside systems supply information or software.
That creates a practical distinction between a flaw in the rules and a compromise of the authority allowed to use them. A program can execute as written while accepting a transaction from a stolen key. Conversely, carefully protected keys cannot prevent a contract from making a mistaken decision that its code permits.
The loss shares describe categories in Hacken's research, rather than a probability that any particular application will be attacked. They also concern the value lost, not necessarily the number of incidents in each category. A few large failures can therefore shape the financial total disproportionately.
Fixing a flaw and deploying a fix are different steps
Hacken says public security fixes preceded several high-profile exploits and that familiar exploit classes continued appearing across different codebases and programming languages.
The operational implication is that identifying a weakness does not complete remediation. A service still needs to determine which deployed components are affected, update them and confirm that the live system is running the corrected version. Reviewing an earlier version does not independently establish the condition of today's deployment.
Bridges make the dependence on the wider system particularly visible. A destination contract may act on a message accepted elsewhere, bringing verification processes, permissions and operational services into the security boundary. Our explanation of bridge verification and exit risk separates those dependencies from the blockchain's record of a completed transaction.
A vendor dataset, with a broader lesson for due diligence
The figures are Hacken's tracked losses, not an independently complete census of every theft. They should remain attributed to the security firm, with the quarter and classification basis attached. Nor do they establish that every audited project failed or that audits have no value.
The more useful question is what was reviewed and what sits outside that scope. Contract code, production deployment, signing arrangements and supplier access can require different checks. A single badge cannot explain all of them.
For operators, the report points toward keeping permissions, software changes and incident response under continuous review. For users evaluating a service, it reinforces the importance of understanding which component can actually authorize a transfer and what happens if that component is compromised. The quarter's losses show why code assurance and operational controls need to be assessed together.