The Undiscovered IA: 175,000 instances of Olama exposed on the Internet and the LLMjacking boom

The possibility of running large language models (LLM) on your own computer or in a small cloud machine has been one of the great advances that has democratized the IA. But a new joint investigation by SentinelOne SentinelLABS and Censys has aroused an alarm: this democratization has also created an enormous "unmanaged and publicly accessible layer of compute infrastructure" for IA. The study detects approximately 175,000 unique instances of Olama exposed on the Internet, spread over about 130 countries, many of them outside any business security perimeter and without the protections that platform providers often impose.

The technical mechanism that explains much of the problem is surprisingly simple. Olama, an open source framework that facilitates downloading, running and managing language models in Windows, macOS and Linux, is configured by default to listen in the local direction 127.0.0.1: 11434. However, with a minimum change - for example, linking the service to 0.0.0.0 or a public interface - the same instance is accessible from the Internet. That trivial gesture is all that needs both dissenting administrators and attackers to turn a service designed for local use into a public access point.

The exhibition is not homogeneous: according to the report, most of these instances are located in China (just over 30%), but there is also a significant footprint in the United States, Germany, France, South Korea, India, Russia, Singapore, Brazil and the United Kingdom. In addition to the mere presence of exposed endpoints, the study highlights a factor that substantially increases the risk: almost half of the hosts observed reported in their APIs the capabilities of "tool-calling" or invocation of functions. In practice, this allows the model to interact with external APIs, run code or access additional systems, making a text generator an actor capable of performing actions with real impact.

That leap - from producing text to running operations - completely transforms the threat model. An API that only returns text can produce harmful information, but it is not the same as an API that, if it is fooled or abused, can make calls to internal services, manipulate databases or launch scripts. When these capabilities are combined with insufficient authentication and network exposure, the result according to researchers is one of the largest sources of risk in the ecosystem.

The analysis also identified instances that expand capacities beyond the text, including advanced reasoning and vision, and found specific cases - 201 hosts, according to the report - with uncensored prompt templates that remove security safeguards. This combination of powerful functionalities and lack of controls increases the likelihood of attacks such as the so-called LLMjacking, where the resources of a LLM instance are abducted for the benefit of a third party while the owner pays the cost.

The danger is not purely theoretical. A supplementary report from Pillar Security documents a campaign called Operation Bizarre Bazaar, in which malicious actors systematically scan the Internet in search of exposed instances of Olama, vLLM and APis compatible with OpenAI that have no authentication, validate the quality of the response and then market access. The operation described by Pillar includes a complete process of recognition, validation and resale of access through a unified gateway, which confirms that there is already a criminal economy around these infrastructures. This investigation tracks the operation to an actor known as Hecker (a.k.a. Sakuya / LiveGamer101).

The decentralized nature of this ecosystem - with implementation points distributed between cloud suppliers and residential networks - also creates governance gaps. Many of these bodies are implemented outside the control of corporate security equipment, making it difficult to implement conventional policies. Researchers insist that there is a need to start differentiating between cloud-managed and edge (edge) or household devices and to adopt context-specific controls.

What can managers and users do to reduce risk? The most basic, and at the same time more effective, is to treat any endpoint of LLM exposed as if it were one more public service: impose robust authentication, encryption, event registration and network controls. Forcing the process to link only to localhost unless there is a justified reason to open it, applying firewall rules to limit who can connect, and enabling authentication mechanisms (keys, mTLS, tokens) are immediate measures. At the same time, network segmentation, continuous monitoring and the application of rate limits help to detect and mitigate abuses. For organizations that make up "tool-calling," it is appropriate to review and limit the capabilities available from the model and to thoroughly audit any bridge that allows for code execution or access to critical systems.

If you are looking for references and readings to deepen, the technical analysis of SentinelOne itself is available on your blog and provides more details on the methodology and findings: SentinelOne SentinelLABS. The report on the commercial operation of LLMjacking can be found in the publication of Pillar Security: Operation Bizarre Bazaar - Pillar Security. To understand the software involved, the official page of Olama and its repository provide information about the project and its configuration: Olama and GitHub - Olama. It is also useful to remember good general safety practices for APIs, collected in initiatives such as OWASP: OWASP API Security and risk reference frameworks for IA such as those published by NIST: NIST - AI.

The final balance is clear: open source IA tools have opened up huge opportunities, but they have brought with them a responsibility. If models can translate instructions into actions, they must be subject to the same controls as any other service with network privileges. Ignoring this reality leaves open doors to fraud, abuse and the construction of illicit markets that monetize exposure. The lesson for IT managers, security teams and end-users is that technical flexibility must be accompanied by policies, monitoring and safe design from the start.