AI security covers more than just data theft prevention, restricting rogue AI agents, or stopping assistants from giving harmful advice. A relatively simple but rapidly scaling threat has emerged: attempts to hijack computational power and exploit someone else’s neural network for personal gain. This is known as LLMjacking. With AI compute costs widely predicted to surge dramatically, the number of attackers driven by these motives is poised to grow. Consequently, when deploying proprietary AI servers and their supporting ecosystems like RAG or MCP, it’s critical to establish rigorous security measures from day one.

Statistics from a honeypot

The speed and scale of these resource-hijacking attempts are best illustrated by an experiment documented in detail in April 2026. The investigator configured a Raspberry Pi to masquerade as a high-performance private AI server, and made it accessible from the internet. When queried, it reported the availability of Ollama, LM Studio, AutoGPT, LangServe, and text-gen-webui servers — all tools commonly used as wrappers for locally hosted AI models. The server also appeared ready to accept API requests in the OpenAI format, which has become the industry standard.

All these services were seemingly powered by a local instance of Qwen3-Coder 30B Heretic, one of the most powerful open-source models, with its safety alignment removed. To throw in a sweetener, the honeypot reported the presence of various RAG databases and an MCP server with tempting capabilities like get_credentials on board.

In reality, the Raspberry Pi was simply hosting 500 pre-saved responses from an actual Qwen3 model, with a lightweight script selecting the most relevant answer for each incoming query. This setup was enough to pass a superficial check while allowing the researcher to probe the attackers’ intentions.

According to the author, Shodan, a popular internet scanning service, discovered the server within three hours of its going live. Just one hour later, requests resembling capability reconnaissance began pouring in. Over the following month, the server handled more than 113 000 requests from thousands of unique IPs, with 23% of that traffic specifically targeted at discovering AI capabilities and exploiting local LLMs and AI agents.

Requests to endpoints like /api/tags and /v1/models allow attackers to fingerprint which models are hosted on a server, while scanning for /.cursor/rules typically precedes an attempt to exploit an AI agent. Similarly, checking /.well-known/mcp.json serves as an inventory of the victim’s MCP servers. While the author makes no mention of the total number of attacks that progressed beyond simple scanning, there were 175 active attempts to hijack the LLM during the final week of the experiment alone.

What are the attackers after?

Based on the researcher’s observations, none of those targeting the decoy server attempted to execute arbitrary code or gain root access. (Editorial note: this is surprising and may point to gaps in logging.) Almost all attacks were aimed at siphoning resources. For example, the following activities were logged during the experiment:

• A well-structured attempt to parse technical documentation for a microprocessor
• A prompt to write an erotic novel
• Requests to parse and structure social media text data regarding new vulnerabilities
• An attempt to call Anthropic models using the compromised server as an API proxy

It’s worth noting that the reconnaissance of AI resources uses standardized and rapidly evolving tools. Requests from an application named LLM-Scanner originated from the infrastructure of seven different cloud providers across eight countries, suggesting that the raiders have put established methodologies in place, as well as specialized platforms for sharing techniques. By the third week of the experiment, the scanner had been updated with an additional check: it now used simple abstract questions to determine whether it’s interacting with live AI or a honeypot returning canned responses.

Among the non-specific attacks, the experiment recorded numerous attempts to exfiltrate credentials from the .env file. Attackers systematically hunted for this file across every conceivable directory on the server. Leaving an .env file publicly accessible is one of the most elementary mistakes when deploying projects on Laravel, Node.js, and other frameworks, yet it remains a common oversight — particularly among beginners and vibe coders. Consequently, attackers have every reason to expect their efforts to pay off.

Conclusions and defense tips

Scanning publicly accessible servers and attempting to exploit them is nothing new, but the rise of LLMs gives attackers another way to monetize their efforts — one that’s both highly lucrative for them and devastating for their victims. To understand how massive these attacks could become, look at their closest counterpart: the cryptojacking market — where criminals mine cryptocurrency using stolen computational resources. That market grew by 20% in 2025 alone. As AI-powered solutions proliferate, and as major providers hike subscription costs while local AI chips remain in short supply, we should expect LLMjacking to become an industrial-scale phenomenon.

Key defensive measures for private AI infrastructure

• For AI systems running locally on a single machine, ensure that servers like LM Studio, Ollama, or similar are configured to accept connections only on the local interface (localhost), rather than all available network interfaces. This restricts LLM access to the host machine itself, and prevents the AI from being reachable over the internet.
• For servers handling remote requests — even if the server only operates within a local corporate network — implement robust authentication and authorization rather than relying solely on API key validation. Solutions based on OIDC or OAuth2 with short-lived tokens are the most effective. This not only defends against LLMjacking, but also allows for more granular tracking of user activity, and prevents API key abuse. Furthermore, keys must be protected from more than just external attackers; a growing risk is the misuse of keys by AI agents themselves. This applies to LLM interfaces as well as MCP, RAG, and others.
• Use network segmentation and IP allowlists to give AI server access only to the departments, employees, and services that require it.
• Ensure that all client-server connections are secured with a current version of TLS.
• Apply the principle of least privilege by separating access to specific services; for instance, MCP and LLM components should have their own distinct access tokens.
• Ensure an EDR security agent is installed on all workstations and servers, including those hosting AI models.
• Monitor AI resource consumption, establish usage quotas for different employee roles, and set up alerts for anomalous activity spikes.
• Maintain detailed logs of LLM responses and requests made to the model and its supporting tools. Integrate these data sources with your SIEM. Ensure logs are resilient against tampering or deletion.

Education technology giant Instructure has confirmed that a security vulnerability allowed hackers to modify Canvas login portals and leave an extortion message. [...]

UPDATED BWH Hotels is informing customers about a third-party data breach that gave cybercriminals access to six months' worth of data. The notification email stated that BWH Hotels, which owns the WorldHotels, Best Western Hotels & Resorts, and Sure Hotels brands, identified the intrusion on April 22, but the affected data goes back to October 14, 2025. BWH Hotels CTO Bill Ryan, who penned the notification email, said names, email addresses, telephone numbers, and/or home addresses belonging to "certain guests" were accessed by an unauthorized third party. The intruders also accessed reservation details, such as reservation numbers, dates of stay, and any special requests. It confirmed that the attack targeted one of its "web applications that houses certain guest reservation data." No payment or bank details were involved. The Register asked BWH Hotels whether the intrusion began in October and went undetected until April, or whether a later breach exposed data dating back to October. We also asked if this was related to information we were sent in March about BWH Hotel customer booking data being stolen and used for phishing campaigns. At the time, the company neither confirmed nor denied the information seen by The Register. BWH Hotels did not immediately respond to our request for comment on Monday. "Upon discovering the incident, we immediately took the application offline and revoked the unauthorized access," said Ryan. "We have engaged leading external cybersecurity experts to support our incident response efforts and to assist with the further strengthening of existing safeguards." "We advise guests to be extra vigilant when viewing any unexpected or suspicious communications about hotel stays. If you receive a suspicious communication such as an unexpected email, text, WhatsApp message, or telephone call that asks for payment, codes, logins, or 'verification,' even if they reference a BWH Hotels property or an upcoming reservation, do not engage. Navigate to sites directly rather than clicking links." ® Updated to add at 1542 UTC, May 12 BWH Hotels ignored all The Register's questions, but provided the following statement: "BWH® Hotels recently notified certain guests of unauthorized activity involving one of its guest reservation applications that contains limited guest contact information and reservation details. Importantly, payment or financial information was not stored in the affected system and therefore was not affected in this incident. Once the unauthorized activity was discovered, we immediately took the application offline and revoked the unauthorized access. We have also taken and will continue to take technical and organizational safeguards to further protect guest information. We have notified the appropriate regulatory agencies. BWH Hotels takes the security and privacy of guest information very seriously and apologizes for any inconvenience or concern this incident may have caused."

Rather than scanning code alone, Build Application Firewalls inspect runtime behavior inside the software build pipeline.

The post Build Application Firewalls Aim to Stop the Next Supply Chain Attack appeared first on SecurityWeek.

Resetting a password doesn't always remove attackers from Active Directory. Specops Software explains how cached credentials and Kerberos tickets can keep attackers authenticated after a reset. [...]

Researchers at Google Threat Intelligence Group (GTIG) say that a zero-day exploit targeting a popular open-source web administration tool was likely generated using AI. [...]

This upcoming webinar explores how organizations need to combine security, backups, and recovery planning to reduce the impact of modern cyberattacks. [...]

Health service has given US tech firm ‘unlimited access’ to certain data to build integrated platform, according to reports

• UK politics live – latest updates

MPs have warned that an NHS decision to grant Palantir access to identifiable patient information in its plan to use AI to improve the health service is “dangerous” and will fuel public fears that data privacy is not being prioritised.

NHS England has allowed staff from the US tech firm and other contractors to access patient data before it has been pseudonymised, despite internal fears of a “risk of loss of public confidence”, the Financial Times reported.

Continue reading...

© Photograph: David Levene/The Guardian

© Photograph: David Levene/The Guardian

© Photograph: David Levene/The Guardian

Ransomware activity remained elevated in Q1 2026, continuing the trend established over the past year. According to the State of Ransomware Q1 2026 report from Check Point Research, overall attack volume stayed near historic highs. At the same time, the structure of the ransomware ecosystem changed materially. After two years of increasing fragmentation, activity is consolidating around a smaller number of dominant groups. For organizations, this shift reduces the number of active actors but increases the potential impact of individual incidents.  Key Findings: 2,122 organizations were listed on ransomware data leak sites in Q1 2026, making it the second-highest Q1 on record The top […]

The post Q1 2026 Ransomware Report: Fewer Groups, Higher Impact appeared first on Check Point Blog.

A malicious version of the plugin was published to the Jenkins Marketplace late last week.

The post Checkmarx Jenkins AST Plugin Compromised in Supply Chain Attack appeared first on SecurityWeek.

A new variant of the TrickMo Android banking malware, delivered in campaigns targeting users across Europe, introduces new commands and uses The Open Network (TON) for stealthy command-and-control communications. [...]

OPINION There are three little words to make the heart beat faster in anyone who knows what they mean: critical infrastructure resilience. If you run that infrastructure or a country dependent on it, you need energy, communication and transport to be impregnable to cyber attacks. This is doubly so if that country is five minutes by incoming missile from an implacable hyper-competent enemy sworn to invade you. One that is building and equipping its military as fast as it can with this one thing in mind. One with the most invasive and brazen state hacking machinery on the planet. Thus it was a very bad day indeed when Taiwan’s entire bullet train system was disabled for nearly an hour by an unknown attacker. It got even worse when that attacker turned out not to be the implacable and hyper-resourced state actor over the Taiwan Strait, but a university student with a yen for radio and some kit he bought online. On the one hand, it’s good to see the good repair of the grand tradition of young hackers causing havoc from their bedrooms. On the other, WTRF? The information released by the Taiwanese authorities is scant on details, but enough to be pretty sure what actually happened. It’s bad news not just for Taiwan but for more than 100 countries that also use the TETRA two-way radio standard involved, often for emergency services. In many cases, it was the default replacement for unencrypted FM two-way radios, adding encryption, flexibility and network security. These were state of the art when TETRA was developed in the 1980s and 1990s — and work as well in 2026 as you might expect. Oops. There have been upgrades and, especially after the 2023 vulnerability disclosures, an accelerated program of making things better. A lot of the installed base globally is old, lacks over-the-air updates for security, and in any case spending money on new radios is normally at the bottom of the list for any state or public service organizations. Things have to get really bad first. Perhaps they just have. (North America is the only region where TETRA is uncommon, as it isn’t approved for public service use. This was either acute foresight or the fact that the TE in TETRA, now officially TErrestrial, used to stand for Trans-Europe. The American system, P.25, has never, however, been renamed Freedom Frequencies. Now on with the show) The network vulnerabilities are one side of the story. Our doughty hacker is the other. Reportedly, he didn’t have any TETRA hardware, but a laptop connected to a radio and an ‘SDR filter’. The latter makes little sense, it is far more likely that he had a software defined radio (SDR) called a HackRF. There are plenty of other devices that could have been used, but the HackRF is the weapon of choice for the gung-ho radio nut. SDR is a technique that has completely changed the rules of how to radio. All radios before it had to be entirely or mostly analog, with precision hardware dedicated to whatever job each radio had to do. This hardware could also be looked at as an analog computer, as it can be modelled as a set of mathematical transformations on the received signal. Analog computers have their place, just not in the 21st century. SDR is radio as digital computer. At heart, it has three components: an analog to digital converter to turn the incoming signal to a stream of numbers, very fast processing to do the radio math, and a digital to analogue converter to play the results. What you get is triply terrific. Digital processing is perfect, analog processing adds noise and distortion. Nothing is fixed, everything can be re-engineered with new code. And it can be hog-whimperingly cheap. HackRF is all those things and more. It can be configured as a portable touch-screen device. It transmits and receives from DC to daylight. You can pick one up for less than the price of a mid-range mobile. It is open source. It works with all manner of SDR creation tools, utilities and radio packages. There are infinite legitimate uses. Most excitingly, you can download apps for it that do everything, most especially the kind of thing that will introduce you with surprisingly rapidity to a wide range of new friends with no sense of humor and love letters that look suspiciously like arrest warrants. Think of it as speed dating but with more guns and less no thank yous, GPS spoofing, aviation and marine location transponders, satellite comms, data eavesdropping and injection - take your pick. You’ll need it to unlock the cell door. It is the data detection and injection that seems to have been the downfall of all concerned. A handset had its transmission decoded, and the result was retransmitted into the system as if it were that original radio. Whether the decoded data already had the General Alarm set, or whether the data had to be modified before retransmission, is not yet known. Doesn’t matter. It’s called a replay attack, and it has and is mostly used in stand-alone devices called code grabbers to unlock and steal expensive cars with wireless keys. Some countries, including Canada and the UK, have banned code grabbers, but this has failed on two counts. Code grabbers are small gadgets that can be bought online from China, and good luck policing that. Also, thieves are notably indifferent to laws. That notwithstanding, the UK is thinking of extending the ban to other classes of naughty wireless, and would doubtless like to do the same with HackRF, at least as of last week. Of course, they can’t be banned. SDRs can’t be banned as a class, especially open source ones made out of standard chips and open code. They are general purpose computers, albeit with specialisms. It doesn’t matter if you’re dismayed or delighted that things like HackRF exist, that genie is out of the bottle. What is truly dismaying is that replay attacks are a solved problem, trivially so. Choose a big keyspace, randomize and never repeat keys. That one is on lazy car makers and, apparently, the world of TETRA. Fixing that class of lazy, outdated security vulnerability will be very expensive. Embedded systems are like that, especially old ones. Not fixing this will be a gamble with infinite downside, in a world where electronic warfare systems that used to cost hundreds of millions now pour out of Ali Express for a few bucks. HackRF is to Tetra like Crocodile Dundee’s knife is to the mugger’s. Critical infrastructure resilience. Just three little words, but if you say them you better mean it. And it won’t be cheap. ®

Also called Copy Fail 2 and tracked as CVE-2026-43284 and CVE-2026-43500, the exploit was disclosed before a patch was released.

The post New ‘Dirty Frag’ Linux Vulnerability Possibly Exploited in Attacks appeared first on SecurityWeek.

Attackers are abusing Google Ads and legitimate Claude.ai shared chats in an active malvertising campaign. Users searching for "Claude mac download" may come across sponsored search results that list claude.ai as the target website, but lead to instructions that install malware on their Mac. [...]

German authorities have shut down a relaunch version of the criminal marketplace 'Crimenetwork' that generated more than 3.6 million euros, and arrested its operator. [...]

AI agents are not a future concern. They are already changing how enterprise systems are accessed, automated, and abused.

And the security implication is clear: the more autonomous systems rely on APIs, the more important it becomes to know exactly which APIs exist, how they are being used, and whether they are being misused.

If your organization cannot answer those questions, you have a visibility problem. And in an environment where AI can accelerate both legitimate automation and malicious abuse, visibility is the first step to control.

Risk accelerating

APIs have always been a target because they expose data and business logic. What has changed is pace.

AI can now help attackers discover endpoints faster, test more abuse paths, and automate attacks that once took much more effort. Meanwhile, AI agents inside the enterprise are generating more API traffic, often with broader privileges than anyone intended.

That means security teams are facing a harder problem: not just more traffic, but more uncertainty and adversaries with improved tools.

What CISOs should be worried about

The biggest risks are not always the loudest ones.

Whether it’s an over-permissioned agent, a forgotten or shadow API, or a “legitimate” request abused to enumerate data or chain unauthorized actions, the risk is real. It’s often compounded by API tokens with broad access and long expiration times.

These are the kinds of issues that can lead to evasive data exfiltration, unauthorized payments, compliance violations, and operational surprises that go undetected far too long.

If your API security program cannot spot abnormal behavior early, the business is exposed.

What good looks like

CISOs need a practical model, not more noise.

That model should:

• Continuously discover APIs across the environment.
• Classify which ones are sensitive.
• Establish baselines for normal behavior.
• Detect abnormal or suspicious API activity.
• Support least-privilege access for AI agents.
• Help revoke risky permissions quickly.

This is how security leaders turn AI agent activity from a blind spot into something measurable and governable.

The board conversation has changed

This is no longer just a technical issue for engineering or operations.

Boards care about risk, control, and business impact. They need to know how many AI agent-facing APIs are being monitored, how many anomalous calls have been detected, and how quickly the business can respond when something looks wrong.

That is the real opportunity for CISOs: to move API security into the center of the AI risk conversation.

Download the guide now

For CISOs, security leaders, and executives, this guide explains the new API security realities emerging with AI agents. We created A CISO’s Guide to API Security in the Age of AI Agents to help you navigate the shift with clarity and confidence.

Inside, you will learn:

• Why AI agents are increasing API risk rather than replacing it.
• How to connect API security to business and board-level concerns.
• What to look for in a practical CISO playbook for discovery, visibility, and control.
• How to govern agent-driven access before it becomes business exposure.

AI agents may change how work gets done. But the organizations that understand their APIs first will be the ones best positioned to stay in control.

Download the CISO guide now

The post Why AI Agents Make API Security a CISO Priority appeared first on Blog.

The website for the popular JDownloader download manager was compromised earlier this week to distribute malicious Windows and Linux installers, with the Windows payload found deploying a Python-based remote access trojan. [...]

A malicious Hugging Face repository that reached the platform's trending list impersonated OpenAI's "Privacy Filter" project to deliver information-stealing malware to Windows users. [...]

There’s a mysterious framework worming its way through exposed cloud instances removing all traces of TeamPCP infections, but it’s not benevolent by a long shot: Whoever is behind this bit of malware may be cleaning up who came before, but only so they can take their place. Discovered by security outfit SentinelOne’s SentinelLabs researchers and dubbed PCPJack for its habit of stealing previously compromised systems from TeamPCP, the worm was first spotted in late April hiding among a Kubernetes-focused VirusTotal hunting rule. It stood out from known cloud hacktools, said SentinelLabs, because the first action it always takes is to eliminate tools associated with TeamPCP attacks. The script didn’t stop there, though. “We initially considered that this toolset could be a researcher removing TeamPCP’s infections,” SentielLabs said. “Analysis of the later-stage payloads indicates otherwise.” “Analyzing this script led us to discover a full framework dedicated to cloud credential harvesting and propagating onto other systems, both internal and external to the victim’s environment,” SentinelLabs continued. In other words, this thing will harvest credentials from everywhere it can get its hands on, and then find new, unsecured cloud environment targets to spread itself to. TeamPCP came onto the scene late last year, and since then has made a name for itself primarily by undertaking a successful compromise of the Trivy vulnerability scanner. That act spread credential-harvesting malware which attackers then used to pivot to more valuable targets, and became one of the most notable supply chain attacks in recent memory. Unlike TeamPCP’s campaign, which relied on the spread of compromised software by human actors, this one spreads on its own accord. Infections start when already-infected systems look for exposed services, including Docker, Kubernetes, Redis, MongoDB, and RayML, as well as exposed web applications. Once it finds a vulnerable environment, it runs a shell script on the target system that sets up an environment to download additional payloads and searches for TeamPCP processes and artifacts to kill. That part of the infection downloads the worm itself, along with modules to enable lateral movement, parse credentials and encrypt them for exfiltration, and for scanning the web for new environments to infect. From there, the worm goes to work with the second module in its kit that conducts the actual credential thefts. This portion of the infection targets environment variables, config files, SSH keys, Docker secrets, Kubernetes tokens, and credentials from a list of finance, enterprise, messaging, and cloud service targets so long that we recommend taking a look at it here, or just assuming whatever you’re using is probably being targeted. SentinelLabs noted that the lack of a cryptominer in the malware package is unusual, and said the particular services it targeted suggests its goal is either conduct its own spam campaigns and financial fraud with the stolen data, or to make the data it harvests available to those planning similar crimes. The worm's practice of removing TeamPCP files could be opportunistic, or could mean there’s drama going on in the cybercrime world. “We have no evidence to suggest whether this toolset represents someone associated with the group or familiar with their activities,” SentinelLabs noted. “However, the first toolset’s focus on disabling and replacing TeamPCP’s services implies a direct focus on the threat actor’s activities rather than pure cloud attack opportunism.” Because this is a worm relying on unsecured cloud and web app instances ripe for targeting, mitigation recommendations are pretty simple: Keep your cloud platforms secure, and ensure authentication is required even for instances of things like Docker and Kubernetes that aren’t exposed to the internet. ®

NVIDIA has confirmed in a statement for BleepingComputer that GeForce NOW user information has been exposed in a data breach. [...]