Welcome back, investigators!

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.

kali > openplanter-agent --task “Find recent security breaches affecting Apple” --provider openrouter --model openrouter/free

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.

The post Artificial Intelligence in Cybersecurity, Part 26: OpenPlanter for OSINT Investigations first appeared on Hackers Arise.

Welcome back, aspiring cyberwarriors!

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.

The post Artificial Intelligence (AI) in Cybersecurity, Part 24: Prompts That Will Supercharge Your OSINT Research first appeared on Hackers Arise.

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.

The post OpenRouter: One Gateway to Every LLM first appeared on Hackers Arise.

Welcome back, aspiring cyberwarriors!

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.

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.

The post Artificial Intelligence in Cybersecurity, Part 25: Jailbreaking AI Models with Obliteratus first appeared on Hackers Arise.

Welcome back, aspiring cyberwarriors!

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:

{{5-0+0}} → collectionPropertyOption://CollectionName
{{1-0+0}} → https://domain/p/CollectionName
{{2-0+0}} → user://UUID

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.

The post Hacking: How a “Calculator” Feature Can Leak Internal Object References (and Real User PII) in AI Chatbots first appeared on Hackers Arise.