How Open AI Models Help Hackers Find Vulnerabilities in Code

An open artificial intelligence model can run on a privately operated server and connect to software analysis tools. It can read code, look for errors, suggest checks and interpret their results. If an attacker uses such a system, they gain an assistant for vulnerability research whose work is not controlled by a cloud AI provider.

For crypto exchanges, wallets and payment platforms, this is a concrete threat. An error in permission checks, withdrawal processing or interactions between services can become the starting point of an attack. AI helps investigate such errors and test more hypotheses. Its effectiveness nevertheless depends on the quality of the model, the code available and the tools used to verify its conclusions.

Informational disclaimer. This article is informational and analytical. Its purpose is to explain threats and defensive measures. The descriptions are not instructions for conducting attacks. Security testing should only be performed with the owner's permission. Examples involving crypto services illustrate possible risks; research test results do not equal the probability of compromising an operating company.

Why hackers run AI models on their own servers

A conventional cloud chatbot has an operator: a company that runs the model, sets rules and can restrict access. A downloaded model works differently. Its owner chooses where it runs, what data it receives and which programs it can access.

More precisely, these are called open-weight models. Weights are the parameters a model acquires during training. Access to them allows the model to be run independently, even if the training data and full details of its creation remain closed. Legitimate systems also work this way, including tools for checking confidential corporate code.

For an attacker, self-hosting is valuable because the model developer loses control over how that particular copy is used. The developer cannot see every request or stop its operation by blocking an account. The UK's AI Security Institute specifically identifies this risk: once weights are released, cloud service controls cannot be extended to all independent deployments.

An open model does not necessarily lack safeguards. However, its operator can modify the software environment and the model itself, weakening those safeguards. In that case, acquiring a dangerous tool does not require compromising the company that created the AI.

An important distinction is that the absence of restrictions does not itself improve the ability to find bugs. Effectiveness comes from the combination of good code analysis, suitable tools and feedback. Removing safeguards allows those capabilities to be used for malicious tasks.

How AI looks for vulnerabilities in a service's code

Imagine a payment service with several thousand files. Permission checks are in one module, account handling in another and withdrawal processing in a third. Identifying a dangerous flaw requires understanding how those parts interact.

AI can help reconstruct that connection: where a value comes from, which checks it passes and which operation ultimately uses it. For example, a model notices that a handler verifies that a user is logged in, but does not check whether the requested account belongs to that user. This is a known class of authorization errors that OWASP describes as Broken Object Level Authorization. Simply put, the service recognized the user but did not establish whether they were allowed to act on a particular object.

A convincing explanation alone is not enough. The model may have missed a check in another file or misunderstood a function's purpose. It is therefore connected to a software harness that supplies the relevant code, runs tests and returns results. The model proposes a hypothesis, receives the program's response and refines its conclusion. This is how a code analysis AI agent works: it can continue investigating after its first answer.

On an isolated copy of the application, such a system checks whether the error actually occurs. If a test fails, the agent analyzes why. If the supposed vulnerability is also detected in the patched version, that is a reason to question the test. The authors of Semgrep's research use checks of this kind to distinguish understanding a bug from reacting to familiar names and code fragments.

Repetition changes AI's practical value. A person does not have to examine every intermediate result manually: some of that work is delegated to the agent. However, configuring the environment, verifying findings and assessing consequences still require resources and expertise.

Source code does not become available to the model automatically either. It can examine public repositories, published smart contract code and a website's client-side code. Private server-side code only becomes available through a separate leak or a grant of access. Without it, the model is left with documentation and observable service behavior, which provide a considerably less complete picture.

What open models can already do in practice

To assess the threat, we compared published model tests and analyses of attacker activity. We examined what data AI received, how many attempts it was allowed and what researchers counted as success. This helps distinguish spotting suspicious code, confirming a bug and actually penetrating infrastructure.

Aikido published an illustrative result in August 2026. Researchers tested models on 32 recently disclosed vulnerabilities in real projects. The models received source code; internet access was disabled. The comparison covered the primary analysis stage within a shared system, not each model working independently without additional tools.

DeepSeek V4 Pro 0813 found 17 vulnerabilities on its first pass. Pooling findings from three passes brought the total to 28 out of 32. Yet the model consistently found only 10 across all three passes.

That translates to 87.5% of vulnerabilities found in at least one attempt and 31.3% found in all three. We calculated these percentages from the published counts. The difference explains why a single answer poorly represents a system's capabilities: repeated checks broaden coverage, but results remain inconsistent. This is a test of rediscovering known flaws, not a measure of success in hacking crypto exchanges.

An assessment by the AI Security Institute provides a broader picture. In its tasks, leading open models matched the level of closed models released four to seven months earlier. This is an assessment of specific tests, including artificially prepared networks, not a universal ranking. For defenders, it means that substantial analytical capabilities are becoming available outside controlled cloud services.

What real incidents show

In May 2026, Sysdig researchers described an attack through a vulnerability in marimo, a tool for working with Python. After gaining initial access, the attacker used discovered credentials to move further and reach an internal PostgreSQL database. Based on a combination of indicators in the recorded session, the authors associated the post-compromise actions with an AI agent that accounted for intermediate results. The model used and where it ran were not established. The report also does not prove that AI found the initial vulnerability.

A June Sysdig analysis of the abuse of other people's computing resources reveals another part of the picture. An operator connected an Ollama server that was accessible without authentication to an automated security testing tool. Ollama is software for running models on one's own infrastructure. Researchers observed the tool changing and gaining new stages of operation.

In that case, the server belonged to someone else and the targets were in private training networks. It demonstrates the technical architecture and abuse of computing resources, but does not establish a successful attack using such a tool against a public company.

These cases help explain which parts of the process already exist. They do not justify attributing a particular cryptoasset theft to an open model on a hacker's server. Such a conclusion requires additional evidence, such as model request logs and traces of the connected program's activity. Fast or unusual attacker actions alone do not prove it.

Which flaws are especially dangerous for crypto services

For a crypto company, the consequences depend on where a discovered flaw leads. Access to an ordinary page and the ability to influence withdrawals carry different weight. In risk analysis, we therefore connect a code defect to the service's permissions and the financial operation it can alter.

One sensitive area is the API, the interface through which programs exchange data. Applications use it to request balances, create operations and retrieve their status. If the server incorrectly associates a user with an account or organization, a valid session may grant excessive permissions. In these areas, authorization needs to be checked for every server-side action, including less visible service and batch operations.

Another example is processing the same event more than once. A payment system must correctly handle repeated notification delivery or concurrent requests. If different parts of the program disagree on whether an operation has been completed, accounting errors can occur. For AI, this is a task involving relationships between files and states: where the operation was created, when it was marked complete and what prevents it from being processed again. This illustrates a class of risk, not a vulnerability discovered in a particular platform.

For decentralized services, published smart contract code provides additional material for analysis. A model can help investigate access and asset movement rules. However, a security conclusion also depends on the deployed contract's configuration, related contracts and economic conditions. Even a correctly identified software flaw does not always translate into an opportunity to steal funds.

Finally, boundaries between services matter. A component processing external data should not automatically gain transaction-signing authority or access to all company secrets. The broader its permissions, the more opportunities a single vulnerability creates.

How to defend against AI-assisted attacks

Defense begins with examining the same code an attacker can study. Priority should go to authorization, financial event processing and the connections between external interfaces and privileged services. For every discovered flaw, establish whether it is externally reachable and what actions it enables.

AI is also useful to defenders. A company can analyze private code on its own infrastructure, complementing engineers' work. Findings must nevertheless be confirmed by a reproducible test: a condition is violated in the vulnerable version and no longer violated after the fix. The result of one pass should not be treated as a complete audit.

The next level is limiting consequences. Separate service permissions, restricted access to secrets and independent verification of withdrawal parameters reduce the likelihood that an error in one component will enable control over assets. Updating vulnerable dependencies remains essential: AI can help attackers exploit already known flaws.

An investigation needs to connect application events with infrastructure activity and blockchain transactions. Transfer history shows asset movements, but usually does not explain which flaw provided initial access. That requires logs of requests, operations and permission changes. We therefore recommend preserving in advance the data needed to reconstruct the path from a request to the service through to its financial outcome.

Open models make systematic code investigation more accessible. For a crypto service, the practical response is to regularly test critical operations and design the system so that a single flaw does not provide access to all assets.