With so many AI tools out there, it’s getting harder to find the ones actually worth your time. A lot of projects look alike and the differences between them can come down to minor UI tweaks. But it’s still worth digging, because every now and then you find something good.
One of the interesting projects we came across recently is Cybermes. It’s an offensive security assistant and automation framework built for bug bounty hunting, recon and reporting. It has more than 200 security playbooks and full Model Context Protocol (MCP) support. The most notable thing here is the reporting structure. The framework handles reporting really well, it has a scope.yaml file you can modify and the TUI interface looks clean.
We’ll show what the assistant can do and how well it handles the tasks.
Setting Up
Unlike PentestCode, there’s some work to do before you can start using the tool.
First, make sure you have Go installed on your Kali. The framework needs to compile tools and without Go your installation will be incomplete.
kali > sudo apt update
kali > sudo apt install go-lang
Then download the repository and run the setup script.
kali > git clone https://github.com/Zyrexnn/Cybermes.git
kali > cd Cybermes
kali > python3 -m venv venv; source venv/bin/activate
kali > chmod 777 setup.sh
kali > ./setup.sh
It’ll take a few minutes. When it’s done, run the doctor script to make sure everything is in order.
kali > python3 tools/doctor.py
After that, add your OpenRouter API key to two env files before you can start working with the tool.
kali > vim .env
kali > vim hermes/.env
Make sure you add the API key to both files, otherwise it won’t work.
kali > ./cybermes model
Finally, specify the scope in scope.yaml. We’ve got OWASP Juice Shop for the test, listening on port 3000.
Now we’re all set.
IDOR/BOLA – Terminal User Interface
The Terminal User Interface is clean and easy to work with, so we’ll start there. You might end up preferring it over the CLI version.
kali > TARGET=127_0_0_1_3000
kali > ./cybermes –tui
Our first prompt in TUI is hunting for IDOR using Nemotron 3.5 Lightning. As the model tests the target, you’ll see entries populating the screen with the commands the tool runs.
Fifteen minutes later we got our results and BOLA was confirmed.
Reporting is really the strongest side of this framework. It created a couple of files with reports and sorted them properly. As you keep hunting for bugs on the same target, all your findings get brought together in one file.
Findings are always stored in Markdown format and keep almost the same structure every time, which makes them look professional.
JWT & SQLi – Command-line Interface
Now let’s look at the CLI version and try to find more bugs.
kali > ./cybermes --cli
Our first prompt will be testing JWT:
Authorized lab only. Target http://127.0.0.1:3000/rest/user/login.
Audit authentication and JWT handling with non-destructive requests. Try the publicly documented Juice Shop demo accounts if needed (admin@juice-sh.op / admin123 and a normal user you register).
Check token claims, privilege flags, and whether a standard user can hit admin-ish REST routes.
Record only confirmed issues under reports/127_0_0_1_3000/findings/.
It took some time to reason through and test the app, then gave the results.
The same files were produced again, with PoCs and an explanation of each bug and the risks tied to it.
We also tested SQLi on search:
Authorized lab only. Audit http://127.0.0.1:3000/rest/products/search?q= for SQL injection using safe syntax and error/timing evidence. Do not dump the full database into the terminal. If confirmed, write reports/127_0_0_1_3000/findings/high_sqli_product_search.md and a minimal PoC in pocs/.
Here’s the report on our SQLi finding, looking just as good as the previous ones.
The tool passed all our tests against the Juice Shop and brought the findings together in the final report. The skills it ships with work well. You might want to go through them and add some of the ones we covered recently. We covered a repository with 83 skills and almost half of those were built by studying 681 real bug reports that people actually got paid for on HackerOne.
Summary
Cybermes has clear strengths. It’s good at reporting, it has a clean TUI and a big library of built in skills. The framework sets up quickly if you have Go installed on your Kali and it already knows which tools to work with based on those skills. That’s handy. We used OpenRouter for this test, but you can also point it at your local Ollama models. For that you’ll need a tool calling model (qwen2.5:14b). Chat only 3B models won’t cut it here.
We also invite you to join our AI for Cybersecurity training. During the training, we’ll show you different ways of using AI in cybersecurity, set up local models and solve labs. The field is evolving rapidly and the sooner you learn things, the greater the advantage you’ll have.
Some things just lie on the surface, while others take time to find. In OSINT, finding the right data often means digging deep. Before you reach a conclusion, there must be solid evidence to support it, and data acquisition is always the most time consuming part of this process. The success of your investigation depends on how well you can find information and connect the dots.
OpenPlanter can automate part of this process.
OpenPlanter
Essentially, OpenPlanter is a recursive language model investigation agent. It ingests different kinds of data, which can be corporate registries, campaign finance records, government contracts and more. It then resolves entities across them and surfaces connections through evidence-based analysis. You can also use it to build profiles of individuals based on publicly available information.
OpenPlanter has both a desktop GUI and a terminal interface. The second one is more convenient.
Setting Up
The setup process is quick. We just need to create a Python environment that will host the needed libraries.
kali > git clone https://github.com/ShinMegamiBoson/OpenPlanter.git
kali > cd OpenPlanter
kali > python3 -m venv venv; source venv/bin/activate
kali > pip install -e .
Once it’s done, we need to give it our API keys.
To make web searches, OpenPlanter needs the Exa API. Exa is cheap to use and gives free credits for new accounts, so you don’t have to pay upfront. OpenRouter API is also needed to run the tool. OpenRouter has free AI models, but there is a daily usage limit. Make an account there and get your free API key.
To configure keys, run this command and paste them:
kali > openplanter-agent --configure-keys
At this point, you can use the tool.
Using OpenPlanter with OpenRouter
The daily API usage limit is enough to run a couple of basic tests, like the one below.
OpenPlanter will use Exa API key to find information. Without Exa, it burns tokens faster and gives incomplete results.
Normally, the tool saves the results in a text file in the current directory, but it doesn’t always happen. Be careful and make sure you don’t lose anything.
Here is our first report.
To make things more interesting, we asked it to find a complete list of Tatneft executives. Tatneft is one of the largest oil and gas companies in Russia.
The report was well organized, but all this information is readily available on the internet, due to the size of the Russian company.
When it was asked to find more information on a specific person from the list above, it struggled to find much and ended up with some generic data and a wrong social media account. Well, maybe that person is hard to find, so we gave it a second chance and picked a unique name from the same list: Nail Ulfatovich Maganov.
kali > openplanter-agent --task "Find as much information as you can on Nail Ulfatovich Maganov who works at Tatneft. If possible, find his Vkontakte, phone number, address, email and check if his email has been in data leaks. Save the results in a text file" --provider openrouter --model openrouter/free
The results can be seen below. OpenPlanter did find his LinkedIn account and extracted information from various places.
It also found OpenSanctions records associated with Nail Maganov.
But he is a well known figure in Russia. What about regular employees at a large Russian company? We will use Sibur for this example. Founded in 1995, it’s Russia’s largest petrochemical company.
We tried two individuals. During the first attempt, the tool didn’t find the correct person. After the second attempt with a different employee, it gave the results.
It found Svetlana’s position (Head of HR). This information was in her LinkedIn account. The rest of the information deserves further validation. Keep in mind, Russia has undergone a massive data blackout, systematically dismantling its open data and public statistics infrastructure. No wonder it’s hard to find things there.
Using OpenPlanter with Ollama – Locally
OpenPlanter’s own docs push toward frontier models (GPT-5.2, Claude Opus 4.6, Cerebras Qwen3-235B), because the whole process is quite demanding. Small local models will be noticeably weaker. But we still gave it a try. The first model was Qwen3:0.6B and its first attempt didn’t produce any results. After the second attempt, it found recent vulnerabilities that Windows had.
We also tried it with Qwen3:4b, but it produced absolutely irrelevant data in its response.
We didn’t stop here and tried it again. The results were still irrelevant. Instead of making a report on Mikhail Karisalov (CEO of Sibur) it spoke about something else.
Using OpenPlanter with Ollama – Remote Servers
If you decide to rent a server with good hardware to test other models, don’t waste your time on it. We tried various models, but none of them worked well. OpenPlanter calls a model, the model replies and then it fails. The output can be seen on the screen.
Here is an example with Qwen3.6:27b. Qwen3.6:35b had the same issue.
We also tried Ornith:35B.
These models support thinking and tooling, but they can’t really do much in this case.
Terminal Interface
It’s also important to mention that there are two ways you can use OpenPlanter in the terminal. So far, you’ve seen only one. If you’re more comfortable with a chat interface, you can use the second option.
kali > openplanter-agent --provider openrouter --model openrouter/free
Here you run your prompts and tweak the tool using the available commands.
Summary
After testing the tool in various ways, we came to the conclusion that it works reliably only with OpenRouter. That’s what gave us the best results. The developers also push towards frontier models or OpenRouter. The whole process of investigation relies heavily on the Exa API. Using it with Ollama models hosted externally (VPS) will not work, as it fails silently even if you select a supported AI model.
The tool might confuse people, especially if their names are common and their social media profiles are empty. Everything it finds deserves validation. Occasionally, it may check the results, marking them HIGH, MEDIUM or LOW depending on its confidence. It doesn’t always do it, but this can be fixed if the prompt explicitly asks for it. Most importantly, OpenPlanter can still save you time.
Learn more with our AI for Cybersecurity training. During the training, we’ll show you different ways of using AI in cybersecurity, set up local models and solve tasks with it.
Many aspiring cyberwarriors write to me asking where they should start in artificial intelligence for cybersecurity and the answer is simple, Hackers-Arise! We have dozens of tutorials–and now classes– on how to apply AI to cybersecurity. In addition, we are the sponsor of the upcoming Wittgenstein Award for the best AI cybersecurity agents. This will give our students an inside look at the development of the best of the best in AI cybersecurity as our students will have an opportunity participate and use the models and agents we develop.
Beyond learning AI for cybersecurity, there is another issue. There are many platforms, models, and hardware to choose from. Comparable to Cisco at the advent of internet in the 1990’s, those who hitched their wagon to Cisco found themselves in an advantageous position regarding jobs and promotions. I want to make the case that NVIDIA is the company you should be hitching your wagon to in this new era.
As you know, NVIDIA is the most valuable company in the world! It is rapidly growing an eco-system that will exceed that of Apple and Cisco. They have quietly built an eco-system of AI that will make it very hard to dislodge them from this dominant position. Jensen Huang and NVIDIA are building an almost impenetrable wall around their eco-system assuring it will be here for years to come.
NVIDIA began as a start-up 1993 building graphics processing units (GPU) for PC gamers. Processing pixels for any graphics intensive product is very compute intensive and NVIDIA made those games come alive. Graphics processing is compute intensive as every image is made of millions of tiny polygons that the GPU must compute it’s size, color, and movement. This means crunching a vast amount of data and Jensen Huang and his colleagues developed a graphics card capable of doing all those calculations very fast through massive parallelism. GPU’s have thousands of cores capable of doing these calculations serially and simultaneously. That is the magic of NVIDIA GPU’s and it is what makes NVIDIA GPU’s the preferred chip for AI. Neural networks–the foundation of our LLM’s at this moment– are built almost entirely from matrix multiplications. This means that the same calculation needs to run over and over on different data. The NVIDIA GPU is uniquely designed for this.
Now let’s take a look at the NVIDIA eco-system that Jensen Huang is building in AI.
Major Equity Investments / Strategic Partnerships
Jensen Huang has made numerous investments in companies positioned to benefit from the coming age of AI, including:
Mellonox –in 2019 NVIDIA agrred to buy Mellanox, an Israeli maker of high-speed Infiniband and Ethernet interconnects for $6.9 billion. NVIDIA needed faster interconnects between to communicate to and from it’s super fast GPU’s and other hardware and Mellanox provided that.
ARM— the British chip designer was the next firm in NVIDIA’s cross-hairs. Jensen Huand recognized that needed powerful and efficient CPU’s to manage his systems. ARM designs RISC-based CPU’s that power the mobile world due to their unique combination of speed and efficiency. NVIDIA offered $40 billion to purchase ARM for what Huang called “the world’s premier computing company for the age of AI.” The US FTC sued to block the acquisition and NVIDIA dropped it’s pursuit of owning ARM. Instead, it holds ARM and it’s CPU’s in close partnership integrating their CPU’s in a multitude of products. Interestingly, ARM is now worth about $250 billion, 6x what Huang offered for it just 6 years ago.
OpenAI — NVIDIA and OpenAI announced a letter of intent to deploy at least 10 gigawatts of NVIDIA systems, with NVIDIA intending to invest up to $100 billion in OpenAI progressively as each gigawatt is deployed. Earlier in 2026, OpenAI raised $110 billion at a $730 billion pre-money valuation, with NVIDIA and SoftBank each investing $30 billion and Amazon investing $50 billion. NVIDIA also noted in its 10-K ( a type of disclosure required by US regulators at the SEC) that it’s finalizing an investment and partnership agreement with OpenAI, though there’s no assurance the transaction will be completed.
Anthropic — NVIDIA and Anthropic announced a deep technology partnership to optimize Claude models for NVIDIA architecture and vice versa; Anthropic’s Series H in May 2026 raised $65 billion at a $965 billion post-money valuation, making it one of NVIDIA’s two largest single-company bets alongside OpenAI.
CoreWeave — NVIDIA holds a stake with an original 7% stake (24.2 million shares) worth roughly $2 billion at IPO, plus an additional $2 billion investment in early 2026, on top of a prior $6.3 billion agreement to purchase CoreWeave’s unused computing capacity through 2032.
xAI — A structure of $7.5 billion in equity plus $12.5 billion in debt, largely through a special purpose vehicle for GPU purchases, supporting xAI’s Colossus 2 data center in Memphis.
Hugging Face — A pending acquisition-related investment of $12.9 billion.
Mistral AI — NVIDIA remains an investor alongside lead backer ASML, with Mistral valued at €11.7 billion (about $13.8 billion).
AI Infrastructure Financing
In August of this year (2026), NVIDIA announced a partnership with some of the largest financial firms in the world including Apollo, BlackRock, Brookfield, Goldman Sachs, and KKR. This partnership was designed to facilitate financing of AI infrastructure and, of course, NVIDIA GPU’s.
Venture / Ecosystem Programs
A roughly £2 billion (~$2.6 billion) UK commitment flowing through partner VCs — Accel, Air Street Capital, Balderton, Hoxton Ventures, and Phoenix Court — into startups in London, Oxford, Cambridge, and Manchester.
Similar “VC Alliance” partnerships extended to European firms including Accel, Elaia, Partech, and Sofinnova, offering DGX Cloud Lepton marketplace credits to portfolio companies.
Scale
NVIDIA has committed over $50 billion across AI labs, cloud services, data centers, and optical communications, with private company assets reaching $47.9 billion by July 2026 and about $18 billion in equity commitments still to be executed.
This list isn’t exhaustive — NVIDIA also has long-standing commercial partnerships with cloud providers (AWS, Microsoft Azure, Google Cloud, Oracle), automakers, and chip/hardware partners that function differently from these financial stakes. Let me know if you’d like me to dig into any particular category.
Summary
NVIDIA and Jensen Huang have quietly built an almost impenetrable eco-system of artificial intelligence systems through acquisitions, partnerships, and financing. Similar to the eco-system CISCO built with networking equipment at the advent of the Internet, it will be advantageous to become part of this eco-system as it will likely be dominant for the foreseeable future.
Sometimes you might run the same model twice and get different results. That often happens when you’ve upgraded it with skills. Skills are detailed text documents that lay out the tools the model should use, the approach it should take and how it should analyze the results. Good skills are practical, pulled from actual reports on HackerOne and other bug bounty platforms. A model can still lean on its own knowledge, but that’s just less efficient.
There are plenty of skills out there you might come across, but not everything can be trusted. Some skills can simply be dangerous and infect your system. To make sure they are safe, you can check them with SkillSpector by NVIDIA, so you don’t end up with anything malicious on your system.
Bug Bounty Skills
Both of these repositories do bug bounty hunting end to end, but they go about it in almost opposite ways.
The first is called Bountyforge. It’s actually just one single skill file, but it’s smart enough to split itself into eight different mini agents that all work at the same time. One looks at websites and apps, another at crypto and blockchain, others go after different angles hackers can exploit. It also checks each finding with four different tests to make sure it’s not a false alarm. Then you get a report in whatever format the bug bounty program wants.
You don’t even need Claude Code or any other coding tool for this, you can just run it right inside the regular Claude website in your browser.
The second bug bounty repository is Claude-BugHunter. It takes the opposite approach. The repo has 83 skills and almost half of those were built by studying 681 real bug reports that people actually got paid for on HackerOne. These skills aren’t locked to Claude Code either, you can use OpenCode, Codex or Hermes Agents with them.
Here are a few examples of the results we got with these skills.
API endpoints are often vulnerable and this is worth trying your luck on to see how it goes.
Another approach can be APK reverse engineering. Here we found a hardcoded RSA-2048 signing private key baked into the published APK. With that key, hackers can push a new app to the app store and infect every employee phone, getting access not just to the WiFi network at the workplace but to their personal life too. Quite dangerous.
We found an API endpoint vulnerable to an SQL injection and managed to pull the entire database.
Having skills built on real attacks keeps the model from wandering off into its own weird approaches and missing a lot of good findings.
Active Directory Skills
Claude-AD was made by ADScanPro for testing a company’s internal network. It gives your model a playbook with skills and agents built for an Active Directory assessment. The developers are upfront that it’s not an auto pwn tool. It’s meant to guide you through the assessment. Every finding can get mapped to a compliance control (DORA, NIS2 and ENS).
Claude-AD is very careful about getting caught too. It explains what a security team would actually see on their end if that technique got used. And any time it’s about to do something that would actually change things on the company’s network, it stops and asks for confirmation first.
General Cybersecurity Skills
Antropic-Cybersecurity-Skills is basically a giant reference book. It has 817 skills covering 29 areas of security work, cloud security, malware analysis, all the way down to hardware and firmware. Each skill is its own small file, so your agent will quickly pull out the two or three it actually needs for its task.
Every skill ties back to real security frameworks that companies and auditors already use (NIST CSF, MITRE ATT&CK and so on). So if your model finds a problem using one of these skills, it can also tell you exactly which official standard it violates. You can use it to justify findings to a compliance team.
SCADA Skills
On an industrial network, a clumsy scan can shut down a production line or damage physical equipment, since a lot of this gear is old and wasn’t built to handle unexpected traffic. That’s why the ICS skill by Masriyan is built to never actively touch a live industrial network. Instead, it works off network captures someone already took. It reads the file, recognizes industrial protocols by the ports they normally run on (Modbus, DNP3, Siemens S7, EtherNet/IP, OPC-UA, and more) and counts which devices are talking to each other. It then shows you write commands, these are the ones that change a value on an industrial device. That’s the traffic you want to see first.
The second mode skips network captures and instead searches for exposed industrial equipment using Shodan and Censys. The skill can also help your model reason about how an industrial network is laid out and check findings against MITRE’s ICS specific attack framework and the IEC 62443 security standard.
Science Skills
Although science isn’t really what we want to focus on here, in one of our SCADA articles we mentioned that to carry out a successful attack requires hackers to understand the technical process of the plant. That means understanding how the chemicals are produced and which units are used along the way. We also showed how vinyl acetate is produced and talked about paracetamol production.
1 kg of paracetamol at 100% purity was reported to cost €8,205, while 1 kg at 99% purity cost just €5. So even a single day of sabotage could cause serious financial damage to an enterprise.
Finding a scientist among hackers is quite a challenge, which is why Stuxnet needed a group of people from different backgrounds working toward one objective. But now hackers can just import different skills to make their attacks more devastating. K-Dense published 140 skills with access to different scientific databases and Python tools.
The real concern here isn’t ICS exploits inside the repository, there aren’t any. It’s the access to sensitive scientific data paired with an AI agent that can actually understand that data and change it.
Summary
AI skills can be a gamechanger, especially when they’re based on actual reports hackers got paid for. These skills show your model how to approach things and what tools to use during the test, so it doesn’t wander off hallucinating and inventing its own ways of testing things. That can wreck your bug bounty flow, since you’ll end up overlooking plenty of potential targets.
Simply relying on the AI to find things isn’t enough, hunters that do it keep getting a lot of dupes. You need to test things manually too. For this reason we created our Bug Bounty training to show you how to find bugs and work with the AI more efficiently.
OpenAI says internal AI agents gained internet access, exploited vulnerabilities and accessed Hugging Face systems during July cybersecurity evaluations.
AI agent security depends on controlling identities, permissions, credentials and tool access so automated actions stay limited, traceable and also accountable.
The vulnerability landscape shifted significantly in Q2 2026. First, the number of registered CVEs reached an unprecedented level. This is driven primarily by the widespread adoption of AI, both for application development and search for security flaws. This resulted in entire new classes of vulnerabilities emerging, particularly in the Linux networking subsystem.
Second, security researchers have been publishing exploits for unpatched vulnerabilities more frequently. Publications like these can generate significant fallout, since they potentially open the door for attackers to target unprotected systems.
Statistics on registered vulnerabilities
This section provides statistical data on registered vulnerabilities. The data comes from Kaspersky’s vulnerability knowledge base, which draws on the CVE database as well as the Russian BDU database and GitHub Advisory (GHSA). As a result, the figures for previous reporting periods may differ from those published in earlier reports.
We examine the number of registered vulnerabilities for each month over the last five years. As the chart below shows, this number continues to surge, a trend reflected across all the databases we track. It’s driven primarily by the widespread adoption of AI tools: as we predicted in our previous report, these tools have played a major role in the discovery of vulnerabilities in third-party software. Meanwhile, these tools often contain security issues of their own. For example, OpenClaw, a popular AI project, ranked 12th among those with the highest number of vulnerabilities discovered and published in Q2, with over 200 CVEs registered during the reporting period. Finally, AI development tools are also contributing to the vulnerability landscape, since the quality of the code they produce can vary widely. Therefore, the rate at which new vulnerabilities are discovered will inevitably keep growing.
Total published vulnerabilities per month from 2022 through 2026 (download)
Next, we analyze the number of new critical vulnerabilities (CVSS > 9.0) over the same period.
Total critical vulnerabilities published per month from 2022 through 2026 (download)
As the chart shows, the number of published critical vulnerabilities jumped sharply in Q2. This is because using AI for vulnerability research makes it possible to analyze massive amounts of previously unexamined code, uncover new attack surfaces, and identify entire classes of vulnerabilities that have gone unnoticed for decades. In particular, AI was used to find a series of Dirty Frag vulnerabilities in the Linux kernel.
Exploitation statistics
This section presents statistics on vulnerability exploitation for Q2 2026. The data draws on open sources and our telemetry.
Windows and Linux vulnerability exploitation
Q2 2026 saw a new precedent in the publication of vulnerabilities in Windows components and exploits for these: researchers no longer waiting for CVE registration, let alone patches. A case in point: a researcher who goes by Nightmare Eclipse (also known as Chaotic Eclipse) published a list of new “named” vulnerabilities across various Windows subsystems. At the time the technical details were published, none of the vulnerabilities had been assigned a CVE identifier:
BlueHammer: a local privilege escalation vulnerability in Windows Defender. During signature database updates, a time-of-check to time-of-use (TOCTOU) race condition occurs, allowing an attacker to substitute the directory where temporary update files are written. The researcher published a fully functional exploit for the vulnerability.
RedSun: another logical vulnerability in Windows Defender with a working exploit. Suspicious and malicious files marked as “cloud” can be overwritten or restored to their original directory with elevated privileges. The exploit incorporates fragments of algorithms that make it possible to leverage various logical vulnerabilities in Windows, effectively combining a large number of popular exploitation techniques.
YellowKey: a vulnerability that lets the user bypass BitLocker full-disk encryption and access system data through the Windows Recovery Environment (WinRE). A fully functional exploit was also published.
GreenPlasma: a vulnerability that enables system object injection via the CTF loader for the Collaborative Translation Framework (CTFMON) service in Windows. The original publication included an exploit with limited functionality.
RoguePlanet: yet another Windows Defender vulnerability that, like BlueHammer, stems from a TOCTOU issue, this time in the engine responsible for real-time system scanning. The published exploit uses the vulnerability to overwrite the system file wermgr.exe with a malicious one.
UnDefend: another vulnerability in the Windows Defender service. This time, the exploit causes a denial of service and blocks updates.
Even though such cases remain isolated for now, we believe they’ll grow into a full-fledged trend. Early publication of exploits gives attackers an advantage over software developers, who are left with no time to fix the issues.
Veteran vulnerabilities in Windows software also remain relevant. These are the ones our solutions most frequently detect exploits for:
CVE-2018-0802: a remote code execution (RCE) vulnerability in the Equation Editor component
CVE-2017-11882: another RCE vulnerability also affecting Equation Editor
CVE-2017-0199: a vulnerability in Microsoft Office and WordPad that allows an attacker to gain control over the system
CVE-2023-38831: a vulnerability in WinRAR that involves improper handling of objects within an archive
CVE-2025-6218 (formerly ZDI-CAN-27198): another WinRAR vulnerability allowing the specification of relative paths to extract files into arbitrary directories, potentially leading to malicious command execution
CVE-2025-8088: a vulnerability similar in exploitation method to CVE-2025-6218. The attackers used NTFS Streams to circumvent controls on the directory into which files are being unpacked
The vulnerabilities listed here can be leveraged to gain initial access to a vulnerable system and for privilege escalation. This underscores the critical importance of timely software updates.
That said, the number of Windows users who encountered exploits declined slightly in Q2, hitting an 18-month low.
Dynamics of the number of Windows users encountering exploits, Q1 2025 – Q2 2026. The number of users who encountered exploits in Q1 2025 is taken as 100% (download)
Linux also hit a rough patch in Q2 2026. Specifically, the period saw the disclosure of the Dirty Frag family of vulnerabilities, which lets an attacker reliably escalate privileges within the operating system.
All the vulnerabilities published in Q2 2026 were, in one way or another, related to the Linux caching subsystem. Here are the ones being most actively exploited:
CVE-2026-31431 (Copy Fail): a local privilege escalation vulnerability in the Linux kernel that lets an unprivileged user modify the page cache and gain root privileges. Especially dangerous for cloud and containerized environments
CVE-2026-43284, CVE-2026-43500 (Dirty Frag): a family of vulnerabilities in the Linux networking subsystem (IPsec ESP and RxRPC) that lets a local user overwrite the page cache and escalate privileges to root
CVE-2026-46300 (Fragnesia): a local privilege escalation vulnerability in the Linux kernel related to packet fragment handling and the page cache mechanism. It lets an unprivileged user gain root privileges and is also classified as part of the Dirty Frag family
CVE-2026-31635 (DirtyDecrypt): a Linux kernel vulnerability that lets a local attacker escalate privileges due to improper handling of decryption operations and page cache data modification
CVE-2026-43494 (PinTheft): a Linux kernel vulnerability that lets a local user gain elevated privileges due to errors in the memory page pinning mechanism
CVE-2026-46331 (pedit COW): a vulnerability in the Linux kernel’s traffic control subsystem (tc-pedit) that exploits a flaw in copy-on-write to modify the page cache and subsequently escalate privileges to root
The vulnerabilities described above were quickly embraced by attackers. At the same time, our solutions continue to detect exploitation attempts targeting older vulnerabilities as well:
CVE-2022-0847: a vulnerability known as Dirty Pipe, which enables privilege escalation and the hijacking of running applications
CVE-2019-13272: a vulnerability caused by improper handling of privilege inheritance, which can be exploited to achieve privilege escalation
CVE-2021-22555: a heap out-of-bounds write vulnerability in the Netfilter kernel subsystem
CVE-2023-32233: another Netfilter subsystem vulnerability that allows for Use-After-Free conditions and privilege escalation through improper processing of network requests
Dynamics of the number of Linux users encountering exploits, Q1 2025 – Q2 2026. The number of users who encountered exploits in Q1 2025 is taken as 100% (download)
In Q2 2026, the number of Linux users who encountered exploits declined slightly compared to Q1. Given that a significant share of new vulnerabilities are tied to the operating system’s caching subsystem, we recommend installing patches as quickly as possible, or disabling vulnerable kernel modules if patching isn’t an option.
Most common published exploits
The distribution of published exploits by software type in Q2 2026 includes categories that haven’t appeared in the sample for a long time. For instance, we’re once again seeing exploits targeting SharePoint. It’s worth noting that while several vulnerability write-ups for Exchange and SharePoint were published during the quarter, most turned out to be fake, AI-generated research. While the articles and exploit source code themselves look fairly polished, they describe nonexistent problems in the software or its components — often close to genuinely vulnerable mechanisms — in order to mislead researchers. This type of attack is aimed at increasing the time it takes to detect real vulnerabilities. In some cases, the description of a nonexistent vulnerability came bundled with completely unrelated malware.
Distribution of published exploits by platform, Q1 2026 (download)
Distribution of published exploits by platform, Q2 2026 (download)
Vulnerability exploitation in APT attacks
We analyzed which vulnerabilities were exploited in APT attacks during Q2 2026. The rankings provided below include data based on our telemetry, research, and open sources.
TOP 10 vulnerabilities exploited in APT attacks, Q2 2026 (download)
In Q2 2026, a trend emerged in APT attacks toward exploiting new vulnerabilities right from the moment they’re published. As before, we’re also seeing a large number of zero-day vulnerabilities. The Langflow vulnerability deserves particular attention: it’s one of the first cases of an APT group exploiting AI technology, which many organizations are only just beginning to integrate. Because most of this tech is proprietary, it has a considerable number of security blind spots. Therefore, given the growing number of AI-based automation tools, we strongly recommend going beyond the usual patching and developing secure procedures for credential use and sensitive data handling in systems that rely on agents and LLMs.
C2 frameworks
In this section, we examine the most popular C2 frameworks used by APT groups and analyze the vulnerabilities targeted by the exploits that interacted with C2 agents in APT attacks.
The chart below shows the frequency of known C2 framework usage in attacks during Q2 2026, according to open sources.
TOP 10 C2 frameworks used by APTs to compromise user systems, Q2 2026 (download)
Sliver, Havoc, AdaptixC2, and Metasploit remain the most widely used C2 frameworks. After studying open sources and analyzing samples of malicious C2 agents that contained exploits, we determined that the following vulnerabilities were utilized in APT attacks involving the C2 frameworks mentioned above:
CVE-2026-35273: a vulnerability in Oracle PeopleSoft PeopleTools that security vendors classify as server-side request forgery (SSRF). The details of the vulnerability have never been disclosed, although some research covers the post-exploitation steps
CVE-2023-46604: an insecure deserialization vulnerability in Apache ActiveMQ that allows arbitrary code execution in the context of the service process
CVE-2024-12356 and CVE-2026-1731: command injection vulnerabilities in BeyondTrust software that allow an attacker to send malicious commands even without system authentication
CVE-2023-36884: a vulnerability in the Windows Search component that allows commands to be run on the system, bypassing the mark-of-the-web (MoTW) mechanism
CVE-2025-53770: an insecure deserialization vulnerability in Microsoft SharePoint that allows for unauthenticated command execution on the server
CVE-2025-8088 and CVE-2025-6218: similar directory traversal vulnerabilities in WinRAR that allow files to be extracted from an archive to a predetermined path, potentially without the archiving utility displaying any alerts to the user
These vulnerabilities show that attackers used them for initial access and privilege escalation on vulnerable systems, setting the stage for launching a C2 agent. They include both zero-day vulnerabilities and fairly well-known security issues.
LLM/AI tool vulnerabilities
This section analyzes data published in Kaspersky’s vulnerability knowledge base. We reviewed the Q2 2026 version of the knowledge base.
As mentioned above, AI tools, plugins, and technologies have proven fairly effective at automating the search for problematic code and anomalous behavior. The high speed at which new vulnerabilities are being discovered has naturally created a need to fix them just as quickly. AI is often used for this too, which increases the volume of code being generated. However, neither code written without human involvement nor AI-generated advice is always correct.
The chart below covers registered vulnerabilities in AI tools for 2025–2026.
Number of published vulnerabilities in LLMs, AI tools, and plugins with similar functionality, 2025–2026 (download)
As the charts show, AI tools are racking up a substantial number of registered vulnerabilities, and that number keeps growing quarter over quarter. It’s also worth looking at how AI tool vulnerabilities break down by type, according to the CWE system:
TOP 6 vulnerability types in products that implement or use AI/LLM logic, 2025–2026
Interestingly, vulnerabilities of an undetermined type have ranked first in every quarter since the start of 2025. Traditionally-made software has the same issue, and it doesn’t look like the growing number of AI tools will fix it. It’s also notable that the list includes classes CWE developers themselves don’t recommend using for vulnerability classification, since they lump together a whole range of more specific types. CWE-284 is an example of this.
Looking at the most common classes, the key issues found in AI-related software can be summed up as follows:
Inadequate access control over critical system objects
Improper implementation of authentication and authorization mechanisms
Injections
It’s worth noting that injection-related vulnerabilities were relatively rare before AI agents took off (previously, they mostly affected web apps). Recently, though, these security issues have become relevant again.
Looking back at a year and a half of the AI boom, one conclusion stands out regarding registered vulnerabilities: AI tool developers are more focused on expanding functionality than on security. This is worth keeping in mind when using these tools. Let’s look at the projects and applications that either integrated AI tools or offered them as the core product. Below is a list of the those with the highest number of registered vulnerabilities for 2025–2026.
TOP AI/LLM-related projects by number of published vulnerabilities, 2025–2026 (download)
Notable vulnerabilities
This section highlights the most significant vulnerabilities published in Q2 2026 that have publicly available descriptions. Since the above already covers several significant vulnerabilities published during the reporting period, this section consists mainly of LLM/AI tool vulnerabilities.
CVE-2026-25253: a gatewayUrl vulnerability in OpenClaw
The issue stems from the fact that the OpenClaw user interface trusts the value of the gatewayUrl parameter passed in the URL and automatically establishes a WebSocket connection to the specified address. During this connection process, it sends an authentication token without any additional user confirmation.
The attack algorithm exploiting this vulnerability works as follows:
The application obtains a critical connection address from an external source (the gatewayUrl URL parameter), which is controlled by the attacker.
There is no validation before use.
The client automatically initiates a connection to the address specified in the parameter, which belongs to the attacker.
While connected, the application sends credentials (an access token) to the specified address.
If the attacker obtains a valid token, the consequences depend on that token’s level of access within the system. In general, this could lead to:
User session compromise
Execution of operations on the user’s behalf
Modification of the AI agent configuration
Unauthorized access to tools and resources connected to the agent
Under certain OpenClaw configurations, further compromise of the host running the agent
It’s worth noting that the risk of exploitation arises from a combination of several factors: the automatic connection and token transmission, the lack of address trust verification, and the high privileges granted to the local AI agent.
CVE-2026-41948: a path traversal vulnerability in the Dify AI platform
The vulnerability lets an authenticated user craft a request that enables the application to escape its permitted tenant and gain access to internal REST APIs that weren’t meant for that user. The root cause is insufficient normalization and validation of the URL path before it’s passed to the internal service.
Depending on the Dify configuration, the consequences can include:
Unauthorized access to internal service interfaces
Breach of isolation between workspaces
Exposure of internal service information
Conditions favorable to further attacks when combined with other vulnerabilities
The use of Dify in enterprise AI platforms is particularly risky, since internal services there tend to hold elevated privileges.
CVE-2026-45386: an improper access control vulnerability in Open WebUI
In Open WebUI, pin/unpin operations on messages are write operations, since they modify that message’s metadata (is_pinned, pinned_by, pinned_at). In vulnerable versions, however, before performing these actions, the API only checked for read access to the channel (a chat between a user or group and the AI) containing the message, not permission to modify its content. As a result, a user with a role limited to viewing messages could still change a message’s pinned status.
The vulnerability’s mechanism works as follows:
The user initiates an action that changes the state of an object.
The application treats this action as a regular read request.
Only channel view permission is checked.
The application performs a write without verifying the required user authorization.
This violates one of the fundamental principles of access control models — namely, that any operation that changes the state of data must be checked for the appropriate write or moderation permissions, regardless of whether the object itself is readable.
Although the vulnerability doesn’t lead to arbitrary code execution or compromise of sensitive data, it can affect data integrity and collaborative workflows. Potential consequences of exploitation include unauthorized pinning or unpinning of messages, disruption of channel moderators’ and administrators’ activities, changes to the display order of important information, and even the potential spread of false or misleading information by altering the channel containing a pinned message.
Open WebUI is widely used as an interface for interacting with local and enterprise LLMs. In these systems, pinned messages often contain important instructions, announcements, or tips for users. The ability to modify them with minimal privileges can disrupt collaborative workflows, cause confusion, and undermine trust in information published by administrators and moderators.
CVE-2026-45501: a vulnerability in Microsoft Exchange
The vulnerability stems from improper neutralization of user input when generating Exchange web pages. As a result, the browser may interpret specially crafted data as active content instead of plain text.
Although Microsoft categorizes the potential impact of exploiting this vulnerability as spoofing, flaws like this can lead to alteration of displayed content, imitation of trusted interfaces, actions on behalf of the user within an active session, and abuse of user trust.
It’s worth noting that issues like this are still relevant in modern software, given that mechanisms like Content Security Policy and various parsers were specifically created to help developers neutralize dangerous parts of user page content.
Conclusion and advice
Q2 brought the first significant results of AI automation adoption in software development and vulnerability hunting tools. This research shows that beyond traditional patch management, organizations now need real-time monitoring of systems and access controls, since infrastructure and everyday applications now contain far more AI functionality that could lead to compromise.
Accordingly, besides quickly detecting infrastructure vulnerabilities and managing security patches, modern enterprise-grade security solutions need to provide a broad range of preventive measures for tracking the overall health of systems and workstations. Kaspersky Next meets these requirements by combining proactive mechanisms with the ability to respond promptly to emerging threats.
Every OSINT investigator now has access to a large language model on their desktop. This tool can quickly summarize thousands of pages or organize chaotic names and dates into a clear timeline. And this is widely accepted. But the difference between an investigator who gets useful results and one who gathers unhelpful information lies not in the model they use, but in how they interact with it.
This article explains how to create prompts that improve your OSINT work. It draws on recent academic research about prompting strategies for security tasks and insights from experienced OSINT practitioners. Let’s get rolling!
Prompt Is More Important Than the Model
Recent research on large language models in offensive security tasks highlights an important point. Methods that relied on reasoning, such as few-shot and chain-of-thought prompting, produced better results. These methods generated code that closely matched the reference examples, executed correctly, and handled various situations well.
One surprising finding was that continuously refining a prompt or asking the model to rethink its answer often resulted in worse outcomes. This happened because rephrasing the prompt misinterpreted the original task and lowered the accuracy of the output. So, repeatedly saying “try again” or “are you sure” is not an effective debugging strategy. If your first prompt was unclear, it is better to follow up with a clear and structured prompt rather than trying to steer the model to a better answer afterward.
Focus on crafting clear instructions at the beginning.
Create a Master Prompt Before You Begin
Before discussing a specific OSINT case, it’s a good practice to create a master prompt. This set of rules, though not related to the target, guides how the model should perform during the session.
This approach uses a well-known idea called anchoring. The first instructions you give to a model have a big influence on all the following interactions. If your first message includes a leading assumption, the model will consider that assumption important for the rest of the conversation, even if you didn’t mean for it to be.
A strong master prompt might look something like this.
Act as a neutral OSINT analyst. Do not treat any hypothesis as proven. Separate facts, indicators, assumptions, and conclusions. Look for evidence against a theory as actively as evidence for it. If the available data is insufficient, say so directly instead of filling the gap.
In other words, this is the initial set of instructions that the AI will follow throughout the entire time you’re working on the task. This reduces the number of errors because it explains to the model in advance exactly how to proceed and which rules to follow.
Basically, a master prompt should specify:
the role;
the goal of the task;
neutrality;
verification rules;
the response format;
a prohibition on unconfirmed conclusions and fabrications;
a requirement to distinguish facts from hypotheses;
a requirement to indicate what is missing.
And then you can set a specific task: what you’re looking for, who you’re looking for, what time period you’re covering, what sources you already have, and so on.
Ask Neutrally
One important but often overlooked issue in AI-assisted open-source intelligence is sycophancy. This happens when a model tends to agree with what the user already believes. For example, if you ask, “prove that this person is connected to this company,” the model starts with the answer you want before it even begins its search. It will look for information that confirms your belief simply because that’s what you asked for.
To fix this, you need to change how you phrase your requests. Instead of using words like “prove,” “confirm,” or “expose,” use “check” or “assess.” Don’t present your suspicions as facts. Phrases like “I already know” or “I am certain” lead the model to validate your beliefs rather than question them. Instead, ask it to build arguments for and against your theory, suggest different explanations, and counter your own ideas.
Specific Prompts You Can Use in Your Own Investigations
Theory is useful, but what most investigators actually want is something they can paste into a chat window tonight. Below are working examples for common OSINT tasks.
For digging into a person’s background, a strong prompt reads something like this.
Act as a neutral OSINT analyst. I am researching a public figure named [name], active in [industry or region]. Using only the material I provide below, build a table of confirmed facts with a source for each one. Separate anything that is an inference or a pattern from anything that is a documented fact. Flag contradictions between sources. Do not draw a conclusion about the person's character or intentions, only report what the material actually supports.
For sorting through a pile of scraped social media posts or forum threads, the goal is structure and pattern detection rather than interpretation.
Read the following set of posts and extract every name, date, location, and organization mentioned. Group them into a timeline ordered by date. Note any account that repeats phrasing found in another account, since that may indicate coordinated rather than organic activity, but do not conclude that it is coordinated, only flag it for review.
For checking a corporate or business connection, the earlier example from this article works well as a template, but it is worth repeating in full because it demonstrates every rule at once.
Assess a possible connection between [subject] and [company] between 2020 and 2025. Use only the material provided. Produce a table with columns for fact, source, supporting detail, confidence level, and what still needs verification. Search for evidence against the connection as thoroughly as evidence for it. List the weak points in the theory separately at the end.
For translating and analyzing foreign language material, always ask for the original text alongside the translation, since that preserves your ability to verify tone, sarcasm, and slang later.
Translate the following text into English. Preserve the original text beside the translation. If any phrase relies on slang, sarcasm, or local idiom that may not translate directly, mark it and explain the likely intended meaning separately from the literal translation.
For comparing multiple documents or reports covering the same event, the model’s strength is spotting overlap and divergence quickly, provided you tell it not to resolve the divergence for you.
Compare the following three reports about the same event. List every claim that all three sources agree on, every claim only one source makes, and every direct contradiction between them. Do not decide which source is correct, only present the disagreement clearly.
And for stress testing your own working theory before it goes into a report, a short adversarial prompt catches more mistakes than another hour of reading.
Here is my working theory: [state theory]. Argue against it as convincingly as you can, using only the evidence already provided in this conversation. Then list what additional evidence, if it existed, would be needed to make the theory solid.
Summary
Carefully written prompts that encourage reasoning are more effective than careless, repetitive prompts. Another important point is that a claim from the model is just a suggestion, not a fact, until you check the source yourself. Even as the tool improves, it’s still your job to decide what is a true finding and what is just a coincidence.
We also invite you to join our AI for Cybersecurity training. During the training, we’ll show you different ways of using AI in cybersecurity, set up local models and solve labs. The field is evolving rapidly and the sooner you learn things, the greater the advantage you’ll have. There’s no reason to resist AI. It’s a tool to master.
Welcome back, aspiring cyberwarriors and AI enthusiasts!
As we know, the world of LLMs is constantly shifting. LLMs that shine today may become slower or be surpassed as quickly as the next day or month. To help simplify the process of navigating these changes over time, you can turn to OpenRouter.
OpenRouter offers a unified API that allows seamless access and routing among hundreds of LLMs. It also features tools for cost management and fallback options, allowing you to control your LLM spending and optimize performance effectively.
In this article, we will delve into how OpenRouter operates, weigh its pros and cons, and guide you on how to get started. Let’s get rolling!
OpenRouter Architecture: How It Works
When you use OpenRouter, your request never talks to OpenAI or Anthropic directly. It talks to OpenRouter first. OpenRouter acts as a proxy and decides where your request should go, applies your preferences, and hands back one clean response. Let’s walk through how that actually happens, step by step.
It all starts on your end. You make one API call, send your prompt, pick a model (or just let OpenRouter handle that decision), and set whatever parameters you’d normally use.
From there, the request hits OpenRouter’s routing layer, and this thing has to think fast, we’re talking milliseconds. First it checks whether you asked for a specific model or told OpenRouter to optimize on your behalf. Then it starts comparing notes: which provider has the best price right now, which endpoint is fastest at this exact moment, whether your preferred model is even available. If it’s not, routing already has a backup lined up. It also looks at what’s worked well before, so a provider with a strong track record on similar requests tends to get picked more often.
Once that decision is made, your request goes out to an actual provider, maybe OpenAI, maybe Anthropic, maybe Mistral, or really any of the 400-plus models sitting in OpenRouter’s catalog. And here’s what I find genuinely clever about the whole setup: the provider has no idea anything unusual is going on. As far as they’re concerned, it’s just a normal request. They process it, send back a response, done.
That response then makes its way back to OpenRouter, gets cleaned up and put into a consistent format, and lands in your application, no matter which provider actually did the work behind the scenes.
Get Started with OpenRouter
To send requests, you first need to create an account on OpenRouter and obtain your API key. Head over to the official OpenRouter website to sign up.
OpenRouter gives you two ways to start using it. There’s a free tier that grants access to a range of models, so you can start experimenting without spending anything. If you need paid models or services, you simply add pay-as-you-go credits and only pay for what you use.
Once you’ve decided how you’ll use it, the next step is getting your API key. Head to the dashboard, find the “API keys” option, and click “New Key.” A dialog box will pop up showing your new key. Copy it right away and store it somewhere safe.
Making Your First API Call in OpenRouter
To make your first API call to OpenRouter, we’ll utilize the Python programming language. I assume you have some familiarity with it; if not, we offer a series of articles and courses to help you get up to speed. You don’t need to be an expert, but it’s important to grasp concepts such as making HTTP requests and working with JSON responses.
We’ll be using the openai Python package to connect with OpenRouter’s API, and we’ll also incorporate python-dotenv to manage environment variables securely. Additionally, I suggest setting up a Python virtual environment for a smoother experience.
kali> python3 -m venv myenv
kali> source myenv/bin/activate
kali> pip install requests openai python-dotenv
Create an .env file in your project directory and add your OpenRouter key like this:
OPENROUTER_API_KEY=your_api_key
After that, we’re ready to start testing. To do so, we can create a simple script like the one below.
Once you run this script as you typically would with any Python script, you’ll receive a response similar to the one below.
I hope this gives you an idea. OpenRouter features good documentation that covers a lot, and your potential outcomes are only limited by your imagination.
Previously, we discussed how to utilize OpenRouter to create an autonomous AI agent that employs a reasoning loop to streamline OSquery threat hunting. This process transforms raw system data into forensic conclusions at machine speed. You can find more details on this topic here. The process is generally quite straightforward. Additionally, take some time to explore other applications of OpenRouter in the article titled “Targeting LLM Supply Chains with Router-in-the-Middle Attacks.”
What Specific Models Does the OpenRouter API Offer?
OpenRouter provides access to an extensive catalog, featuring over 400 models sourced from various providers. In addition to the well-known chat models, OpenRouter organizes its offerings into collections based on specific use cases. You can explore dedicated sections for vision and multimodal models that analyze images and interpret charts, as well as embedding models designed for semantic search and RAG pipelines. There are also models for video and audio generation, along with text-to-speech and transcription capabilities.
However, figuring out which model to choose and estimating your monthly costs can still be a challenge. To address this, OpenRouter has released its own benchmarks. They maintain five leaderboards that operate on production endpoints, four of which focus on fixed models, allowing you to compare the configurations you actually control.
Another useful feature is the model comparison tool, which lets you select models that interest you and find the best fit for your needs.
How Does OpenRouter Manage Data Privacy and Security While Routing Requests?
When your data reaches OpenRouter, it first hits their servers before being forwarded to the provider that handles the actual inference, such as Anthropic or OpenAI. OpenRouter processes the prompt to route it correctly and log usage, then sends that same prompt to the downstream provider to generate a response. It is important to note that the retention and training policies that apply to your data are a blend of both OpenRouter’s and the provider’s practices, meaning OpenRouter’s privacy settings tell only part of the story.
By default, OpenRouter does not retain your prompts. They only store your prompts or responses if you specifically choose to opt in for logging. There are two distinct opt-in options available. One allows you to view your own prompts and completions in your logs for debugging, while the other gives OpenRouter permission to use your prompt and completion data to enhance the product. This latter option is turned off by default but offers a small usage discount if you enable it. Neither of these options is activated unless you decide to do so.
Additionally, there is a feature called Anonymous Input Categorization. With this feature, OpenRouter samples a small number of prompts for categorization, which helps in reporting and model ranking. If you have not opted in for OpenRouter to use your inputs and outputs, any categorization of your prompts should be stored anonymously and should never be linked to your account or user ID. This categorization is conducted by the model with a strict zero-data-retention policy.
Zero Data Retention, or ZDR, means that OpenRouter will only route your requests to endpoints from providers that do not store your data, and these providers also cannot use your data for training purposes.
Pros and Cons of OpenRouter
The greatest advantage of OpenRouter lies in its convenience. With just one API, you gain access to a multitude of models from OpenAI, Anthropic, Google, and more, eliminating the hassle of managing multiple integrations. It automatically handles failovers, rerouting requests if a provider goes down, and simplifies cost optimization by allowing you to easily compare prices and choose options that fit within your budget.
On the flip side, the main concerns revolve around trust and control. Each request now passes through an additional layer before reaching the actual provider, which introduces another party into your privacy framework.
Summary
OpenRouter has several important benefits for cybersecurity work. By not relying on just one provider, you lower your risk if that provider is breached or goes down. The automatic failover feature keeps your tools running even if a model provider has an outage.
It’s also useful for testing. You can run the same security task on different models without having to rebuild anything each time.
I recommend trying this tool; it might be a great fit for your cybersecurity toolkit.
This article could also have title: how we discovered automation for the fifteenth time, renamed it AI, panicked, bought six dashboards and forgot about the Windows 2008 server in the basement.
I’ve been running this blog for quite a while, and most of what I publish here is technical: guides, projects, reviews, vulnerabilities, things I
At Black Hat USA 2026, Novee found GitHub workflow flaws in Claude Code, Gemini CLI and Codex that enabled RCE, credential theft and agent control in pipelines.
Compare AI detection & response platforms for 2026, including Dash, Lakera, Operant AI, HiddenLayer and Prisma AIRS, for runtime threat protection and response.
Cisco Talos found hackers using simple authorization claims to bypass AI guardrails, build DDoS attack tools, steal credentials and access live camera services.
Lately, the constrained AI models that companies keep shipping are becoming less and less useful for cybersecurity. We keep hearing a lot of complaints about Claude in this regard. What they are doing doesn’t really fix the problem, as hackers are not sitting around waiting for the guardrails to be lifted. The barrier to entry for hacking has dropped hard. AI can already automate huge chunks of this cybercrime work. Many of these latest models can even find zero days during engagements.
Source: The Hacker News
So poking around your infrastructure looks completely irrelevant. A more meaningful approach is to actually emulate these real attacks with AI, but for that we need a model with no guardrails. Today we are going to show you how to jailbreak a model and self host it for your pentesting work.
What is Obliteratus
Obliteratus is built to strip refusal behavior out of LLMs using abliteration. You’ll see it called abliteration or obliteration, same thing. It targets the internal representations causing the model to refuse in the first place and knocks them out. The model keeps all its core capability, it just stops throwing up artificial walls when you ask it something. It runs on CPU for smaller models, and it’s already been used to abliterate Kimi-K3 along with a bunch of others.
Setting Up
Setting up this tool will take some time, just like the jailbreak process itself. How long depends on your hardware and your internet speed.
kali > sudo apt update
kali > sudo apt install -y python3 python3-pip python3-venv git
kali > git clone https://github.com/elder-plinius/OBLITERATUS.git
kali > cd OBLITERATUS
kali > python3 -m venv venv
kali > source venv/bin/activate
kali > pip install --upgrade pip
kali > pip install -e .
Once it finishes, see if it works:
kali > obliteratus --help
If you don’t have a GPU, don’t worry. You can absolutely make this work with small models using just CPU power. Our Kali VM ran on 12 gigs of RAM and 7 processors, and that setup worked really well.
We went with Qwen 2.5-0.5B-Instruct for this test. You don’t need to have it downloaded beforehand. The tool will fetch it for you automatically. There are different methods available for the jailbreaking process, but advanced and nuclear are the most common. The advanced method is usually enough for most use cases, but if you see the model misbehaving you can escalate to nuclear.
kali > obliteratus obliterate Qwen/Qwen2.5-0.5B-Instruct --device cpu --method advanced --output-dir ./abliterated-qwen-0.5b
Once the model downloads, the tool starts running prompts designed to lift the guardrails.
You can find the full list of prompts in obliteratus/prompts.py. Right before it finishes, it runs a series of refusal tests to check whether the model actually complies with requests. Behavior varies a lot depending on which model you’re working with and which method you picked.
In our testing, the advanced method gave us approximately 75% of compliant answers.
At this point, everything is prepared and you can push your model to HuggingFace to share it. But if you want to run it locally, the next step is getting it working with Ollama.
Running Models with Ollama
Aircorridor previously made an article on running Ollama models locally and showed how to do it on a MacBook. If you don’t have it, you can still make this work on a Kali VM using your CPU. We need to convert our new model into a format that Ollama actually understands.
kali > git clone https://github.com/ggerganov/llama.cpp
kali > cd llama.cpp; python3 -m venv venv; source venv/bin/activate
kali > pip install -r requirements.txt
kali > python convert_hf_to_gguf.py /home/kali/OBLITERATUS/abliterated-qwen-0.5b --outfile qwen2.5-0.5b-abliterated-f16.gguf --outtype f16
Next, we create a Modelfile that points to the model:
kali > cat > Modelfile << EOF
FROM ./qwen2.5-0.5b-abliterated-f16.gguf
EOF
Then we create the model using Ollama:
kali > ollama create qwen05b-abliterated -f Modelfile
At this point, everything is ready and you can start testing it. The better the model you start with, the better your results will be.
kali > ollama run qwen05-abliterated
But even with a small model like this, you’ll see it do things that normally it wouldn’t.
Abliterated Models
This tool is helpful for doing the work yourself and understanding the logic behind the whole process. But if you’re working at scale and don’t have time to spend on each model individually, just keep in mind that many abliterated models are available on HuggingFace uploaded by huihui.ai. They’ve already done the heavy lifting for a lot of popular models.
If you can’t find exactly what you need in their collection, you now know how to do it yourself.
Summary
The landscape of offensive security has shifted because AI got so good at automation. Simple pentests with constrained models don’t prepare you for the reality out there anymore. As you can see, there’s no reason to work with constrained models in cybersecurity, when the people you’re up against are exploiting the full capability of a model with nothing holding them back. So test your environment with abliterated models before someone else does it. The tool is great for staying ahead of the actual threats.
Many software-as-a-service (SaaS) platforms are adding AI chatbots to their products. But these bots do more than just chat; they can access internal tools and perform tasks for users. Each of these actions creates a potential security risk, and developers are releasing these features faster than they can secure them.
In this article, I want to share a type of vulnerability I found while testing an AI chatbot – LLM02:2025 Sensitive Information Disclosure – which allowed me to obtain users’ first and last names and email addresses just by interacting with the chatbot. Let’s get rolling!
What is LLM02:2025 Sensitive Information Disclosure?
LLM02:2025 Sensitive Information Disclosure is a critical security issue listed in the OWASP Top 10 for LLM Applications 2025. This problem occurs when a Large Language Model (LLM) application accidentally reveals confidential or personal information in its responses.
This vulnerability happens because LLMs are designed to be helpful and use all available context, such as training data, system prompts, and runtime inputs, to create replies. If sensitive information is included in these sources without proper protections, the model may accidentally disclose information it should keep private.
Step 1: Find the Hidden Feature Behind the Feature
Our target had a chat feature that looked, on its face, completely trivial: type an arithmetic expression wrapped in double curly braces, and the bot evaluates it and replies with the answer.
{{5-5+0}} = 0
{{5*5+0}} = 25
Just like a calculator. But the interesting bugs live in the features nobody thought to test twice. So I started varying the input systematically, the way you’d fuzz any parameter in a pentest. And the calculator started talking back with things that were most definitely not numbers:
This shows that the “calculator” is really a thin cover for a much riskier part of the code, which allows direct access to the platform’s internal system without any authentication.
Step 2: Isolate the Real Trigger
When you notice a leak like this, do not just note it down. Understand what is causing it.
My first guess was that the final answer of the expression is used as a lookup index. This is easy to test. Try expressions that all result in the same number through different math operations:
{{2+2}} = 4 (plain number)
{{2+2+0}} = 4 (plain number)
{{2-2+0}} = user://UUID ← NOT a plain number!
That last result contradicted my guess. The expression 2-2+0 simplifies to 0, but the result came back as an object reference instead of a plain number, similar to when the expression equals 2. This was a clue. I ran a few similar tests to confirm:
{{4-2}} (=2) → collectionProperty:// reference (type 4, not type 2)
{{5-2+0}} (=3) → collectionPropertyOption:// reference (type 5, not type 3)
{{0+2-2}} (=0) → plain number (type 0)
In conclusion, the lookup key is based on the first operand’s type, not the final arithmetic result. The developer’s evaluator takes the first number from the input and puts it directly into an internal array, sorted by object type, completely separate from what the expression calculates. I confirmed this by testing the limits:
{{99-2+0}} = 97 (plain math, outside the enum)
{{99999999999-0+0}} = 99999999999 (same, safely out of range)
Step 3: Turn the Reference Into a Record
The next question is obvious: will the system actually resolve that reference if I hand it back to it?
Yes. It will.
{{user://<uuid>}} → returns first name, last name, and email address of that user.
This AI chatbot successfully provided information about any user by knowing his UUID.
Summary
Finding an issue like this, such as index leak, reference resolution, and PII disclosure, is not just luck; it is a systematic approach. This is the practical skill we teach at Hackers-Arise. As AI systems become part of every platform you will test, hackers who understand these new areas of attack will have the best tools and the highest salaries. Check out our Subscriber training package to start building these skills effectively and methodically.
Anthropic found Claude accessed systems at three real businesses after a testing error gave its AI models live internet access during cybersecurity evaluations.
In one of our previous articles, Aircorridor showed you how to do recon on exposed Ollama servers. There are a surprising number of them scattered across countries all over the world, and unfortunately, most of them are left completely unprotected. That means hackers can use the CPU and GPU power of those servers to run their own tools. It’s not just that they can generate answers to random questions using your exposed models. These models can also be pushed into generating malware, rewriting scripts and exploits to slip past antivirus software, and helping someone hack into other systems entirely. All of it running on your hardware, at your expense, while you have no idea it’s happening. Our goal here is to raise awareness about this problem so you understand what can happen when a model gets left exposed.
Ollama
It all starts with a simple Shodan query, and right now that query turns up 4,222 exposed hosts. That number keeps shifting as more people jump into the AI space, and most of these hosts are sitting there vulnerable to the kinds of attacks we’re about to walk through.
Following Aircorridor’s example, you can list the models running on one of these servers. As you’ll quickly notice, there’s often a long list, sometimes more than 40 models on a single host.
The ones that matter most here are the local models, not the cloud. They don’t require an API key to reach. Of course, not every listed model is actually active, so a quick curl request is usually enough to check whether one is really responding.
When a model does respond, that confirms it’s live and usable, which means it can be put to work for all sorts of purposes, good or bad. Let’s walk through a few of the ways that tend to play out.
Coding
Because these exposed models have no guardrails, they’re an attractive resource for coding tasks, including rewriting malware or generating backdoors. To pull this off, hackers often bring the model straight into VS Code using a plugin called Continue, which lets them integrate an external model directly into their coding workflow.
Once installed, they’ll edit the config file to point at the exposed server’s IP address along with the model’s name. This config can hold multiple models at once, so a hacker can switch between them right there in the chat window.
With that setup in place, the model shows up ready to work and it often has no issue generating malicious code that could cause real damage to systems out on the internet.
The same pattern shows up with exploit development and antivirus evasion, where a model can take old exploits and rewrite them so they slip past AV detection.
Hacking
Once an exploit has been generated, the next step for a hacker is putting it to use against real systems. We covered a tool called PentestCode in an earlier article, and while it normally relies on free AI models through OpenCode Zen, it can just as easily be pointed at someone else’s exposed local model instead. This is just one example among many. Plenty of other tools work the exact same way, running on borrowed compute that belongs to somebody who has no idea it’s being used.
To connect PentestCode to an exposed model, a config file gets created at ~/.config/pentestcode/pentestcode.json.
Once that’s in place, the tool automatically lists the available models. It’s worth noting that not every model supports tool use. DeepSeek R1, for example, doesn’t support it, and neither do a handful of others. So if a given exposed model doesn’t support tools, it’s simply not useful to a hacker in this particular scenario.
Chat Assistant
Finally, exposed local models can also be accessed through a full chat interface using Open WebUI, which looks a lot cleaner than working from the command line. It has the kind of layout people are used to by now, with folders, chat history, channels, and separate workspaces. It takes a bit of disk space and a little patience to install, but once it’s running, it’s a solid and polished experience.
Summary
Running Ollama is not inherently dangerous. Simply exposing a model doesn’t automatically put you at risk of a data breach or account compromise. What it does do is hand hackers free access to your CPU and GPU, letting them run their own workloads on your dime without your knowledge or consent. That alone is a real cost, even if nothing else goes wrong.
The bigger danger shows up with older, outdated Ollama instances. Older versions are more likely to carry known vulnerabilities, and there are documented CVEs out there that can lead to full API exposure. When that happens, hackers aren’t just borrowing your compute anymore. They can steal your API keys outright and use them for whatever purpose they like. Keeping Ollama updated and making sure it isn’t sitting exposed to the open internet goes a long way toward avoiding both problems entirely.
We also invite you to join our AI for Cybersecurity training, available to our Subscriber Pro members. During the training, we’ll cover practical ways to use AI in cybersecurity, show you how to install and run local models, and much more. The field is evolving rapidly, and the sooner you learn to use these tools, the greater your advantage will be.
Login
