How to Find Classic Bugs Hiding Inside AI Features | by Samadhan Shimple

AI is changing how we interact with applications. Today, we can ask a chatbot to summarize documents, search company data, analyze files, generate reports, or perform tasks that previously required several manual steps.

But there is something important that many developers and security teams might overlook: AI features can still contain the same old security vulnerabilities we have been finding for years.

SQL injection, broken access control, cross-site scripting (XSS), server-side request forgery (SSRF), and path traversal have not disappeared. They can show up in AI-powered applications, sometimes in places where traditional security testing might not look first.

As bug hunters, this creates an interesting opportunity. Instead of focusing only on prompt injection and model jailbreaking, we also need to understand how AI features interact with the underlying application.

Because sometimes, the biggest problem is not the AI model itself. It is the code behind it.

Why AI Features Create New Opportunities for Classic Bugs

Think about a typical AI assistant inside a web application.

A user sends a prompt. The application passes it to an AI model. The model generates a response or requests an action through a tool. The backend then processes that action and returns the result.

That sounds simple, but several security-sensitive operations can happen along the way.

The application might query a database, access a file, fetch a URL, call an internal API, or retrieve information belonging to a particular user.

Every one of these operations introduces potential security risks.

The important thing to understand is that adding an AI model does not automatically make an application more secure or less secure. The risk depends on how the surrounding system is designed and implemented.

Let's look at the classic vulnerabilities that bug hunters should pay attention to.

1. SQL Injection: When AI Connects to a Database

Many AI applications allow users to ask questions about database records using natural language.

For example, an employee might ask an AI assistant to find sales reports for a particular month. The application translates that request into a database query and returns the relevant information.

The problem starts when developers construct SQL queries by directly concatenating user-controlled input or model-generated text.

An attacker may then be able to influence the query beyond what the application intended.

However, there is an important distinction here: prompt injection and SQL injection are different vulnerabilities.

Prompt injection attempts to manipulate an AI system's instructions or behavior. SQL injection occurs when untrusted input is interpreted as part of an SQL statement.

An AI model does not automatically create SQL injection. The vulnerability exists when the application's database interaction is implemented unsafely.

What should bug hunters look for?

During an authorized assessment, identify AI features that search, filter, or retrieve database records.

Review how the application translates user requests into database operations. If you have access to the source code, check whether it uses parameterized queries rather than constructing SQL statements from strings.

Also, verify whether the backend restricts which tables, records, and operations the AI feature can access.

How developers can fix it

Use parameterized queries, validate inputs according to their expected types, and avoid giving AI components unrestricted database access.

Where possible, expose a limited set of predefined database operations instead of allowing model output to determine arbitrary SQL statements.

2. IDOR and Broken Access Control: Can AI Access Another User's Data?

Broken access control is one of the most important areas to test in AI-powered applications.

Imagine an application where users can ask an AI assistant to summarize their uploaded documents, retrieve previous conversations, or explain information stored in their accounts.

Everything appears to work correctly when a user accesses their own data.

But what happens if the backend retrieves a document using its identifier without checking whether the current user is allowed to access it?

That is where an insecure direct object reference (IDOR) or another broken access-control vulnerability may appear.

The AI interface can make this problem harder to notice because users interact through natural language instead of directly navigating traditional application pages.

For example, an AI assistant might call a backend function that retrieves a document by ID. If that function checks whether the document exists but fails to verify ownership, one user could potentially access another user's information.

The underlying problem is not the language model. It is the missing authorization check.

What should bug hunters look for?

Focus on features that retrieve user-specific information, including:

• AI-generated summaries of private documents.
• Conversation history and saved prompts.
• Reports, invoices, and account information.
• AI agents that call internal APIs.
• Shared workspaces and team resources.

In an authorized test environment, use accounts and records you control to verify whether access restrictions are consistently enforced.

Do not assume that hiding a record ID or instructing the model not to reveal private information provides meaningful access control.

How developers can fix it

Enforce authorization on the server for every sensitive operation.

The backend should determine the user's identity and permissions independently of the model's response. Access checks must happen before private data is retrieved or an action is executed.

An AI assistant should never be the security boundary protecting sensitive information.

3. Cross-Site Scripting: When AI Output Reaches the Browser

AI-generated responses often contain formatted text, Markdown, links, or even HTML.

Developers may render this content inside a chat interface to make the experience more interactive. Problems can arise when the application treats generated content as trusted HTML.

For example, an AI response might include content originating from an uploaded document, a web page, or another user-controlled source. If the application inserts that content into the page without appropriate handling, it may create a cross-site scripting risk.

The important point is that AI-generated content can contain untrusted data, even when the model itself is operating as intended.

Not every unusual HTML element or suspicious-looking response represents exploitable XSS. The application must actually interpret the content in an unsafe way for the vulnerability to exist.

What should bug hunters look for?

Examine AI chat interfaces, generated reports, document previews, and other places where responses appear in the browser.

Determine whether the application renders model output as plain text, sanitized Markdown, or executable HTML.

During authorized testing, use harmless test content to understand how the application handles HTML-like input. Verify whether any unexpected content is interpreted by the browser rather than displayed as text.

How developers can fix it

Prefer safe text-rendering methods and use a well-maintained HTML sanitizer when rich content is necessary.

Avoid inserting AI output directly into dangerous DOM APIs. Apply context-appropriate output encoding and use a restrictive Content Security Policy as an additional layer of protection.

Remember that a model's response should not automatically be trusted simply because it was generated by an AI system.

4. SSRF: When an AI Feature Fetches URLs

Some AI assistants can summarize web pages, analyze URLs, retrieve external documents, or connect to other services.

To perform these tasks, the backend may make HTTP requests on behalf of the user.

This introduces a familiar security risk: server-side request forgery, commonly known as SSRF.

Suppose an AI feature accepts a URL and retrieves its content. If the application does not properly restrict outbound requests, an attacker may be able to influence which resources the server contacts.

Depending on the environment and the protections in place, this could expose internal services or sensitive infrastructure information.

The AI model may be part of the request flow, but the vulnerability exists because the backend makes unsafe requests to attacker-influenced destinations.

What should bug hunters look for?

Look for AI features that:

• Summarize user-submitted URLs.
• Import remote documents.
• Retrieve information from external websites.
• Use browsing or fetching tools.
• Connect to internal services or APIs.

In an authorized environment, examine how the application validates destinations and handles redirects. A URL that appears safe initially may redirect to a destination that should not be accessible.

How developers can fix it

Use strict destination allowlists where practical. Validate resolved IP addresses, restrict access to internal and link-local networks, and revalidate destinations after redirects.

Network-level egress controls should prevent AI services from reaching sensitive internal resources unless those connections are explicitly required.

Do not rely only on a URL string check to prevent SSRF.

5. Command Injection and Insecure Deserialization

AI agents are becoming more capable of interacting with external tools. Depending on their permissions, they might execute scripts, process files, call system utilities, or pass structured data to other components.

This creates another opportunity for traditional vulnerabilities.

Imagine an application that takes an AI-generated argument and inserts it directly into a shell command. If the command is constructed unsafely, attacker-controlled content might alter how the command is interpreted.

Similarly, an application that deserializes untrusted data into executable objects without appropriate safeguards may expose itself to insecure deserialization vulnerabilities.

These are separate vulnerability classes, but both can become relevant when AI-generated content is passed into sensitive backend operations.

It is important not to confuse an unsafe tool design with prompt injection alone. A prompt might influence the model, but the underlying vulnerability depends on what the application permits that model to do.

What should bug hunters look for?

Identify AI tools that interact with operating-system commands, code interpreters, file processors, or object deserialization mechanisms.

When source code is available, trace how tool arguments are validated and passed to the underlying operation.

Check whether the application uses safe APIs or instead builds commands by concatenating strings. Also examine whether structured input is parsed using secure, well-defined formats.

How developers can fix it

Avoid shell execution when a safer library or API can perform the same task.

If a system utility is necessary, pass arguments separately through safe process-execution APIs, validate each argument, and run the process with minimal privileges.

For serialized data, use safe parsing formats and avoid deserializing untrusted input into objects capable of executing code.

AI agents should receive only the permissions needed for their intended tasks.

6. Path Traversal: When AI Agents Work With Files

Many AI tools allow users to upload documents, summarize files, search directories, or generate downloadable reports.

These features may require the application to read or write files on the server.

If file paths are constructed using untrusted input without proper validation, an attacker may be able to influence which files the application accesses.

For example, a document-processing feature might accept a filename and assume it always points to a file inside the intended upload directory.

If the application does not enforce that restriction, path traversal may become possible.

The presence of an AI assistant does not change the underlying rule: file access must remain within the boundaries established by the application.

What should bug hunters look for?

Examine document upload and download workflows, AI-powered file analysis, report generation, and features that let agents select files.

Pay attention to how filenames, directory paths, and file identifiers are handled.

In a test environment, verify that the application cannot access files outside the permitted directory and that users cannot read or overwrite files belonging to other users.

How developers can fix it

Use server-generated file identifiers rather than trusting user-supplied paths.

Resolve file paths against an explicitly permitted directory and verify that the final resolved path remains within that directory. Apply appropriate filesystem permissions and isolate file-processing components when possible.

Access to files should be determined by server-side authorization, not by instructions given to an AI model.

A Practical Methodology for Finding These Bugs

Finding classic vulnerabilities in AI-powered applications does not require abandoning traditional bug bounty methodology.

Instead, the goal is to understand where AI connects to existing application functionality and then test those connections carefully.

Here is a practical workflow to follow during an authorized assessment.

Step 1: Map the AI Attack Surface

Start by identifying the application's AI-powered features.

Look for chat assistants, document summarizers, AI search, report generators, autonomous agents, and integrations with external tools.

Use normal application functionality and available documentation to understand which features interact with sensitive data or backend operations.

Step 2: Understand the Data Flow

Determine how information travels through the application.

A typical flow might look like this:

User input → Application backend → AI model → Tool call → Backend operation → Response to user

Not every application follows this exact architecture, but the principle is the same.

Identify where user-controlled information enters the system, where the model can influence decisions, and where the application performs sensitive operations.

Step 3: Identify the Security-Sensitive Operations

Once the data flow is clear, focus on the operations that could have security consequences.

These include database queries, file access, external HTTP requests, HTML rendering, and API calls that retrieve or modify user data.

The question to ask is simple: what security checks happen before this operation is performed?

Step 4: Test Authorization Boundaries

Use accounts and test data that you are authorized to access.

Verify that users cannot retrieve another user's private documents, access restricted conversations, or perform administrative actions without the required permissions.

Test both the normal application interface and the AI-powered workflows, because they may use different backend functions.

Step 5: Review Input and Output Handling

Examine how user input and model output are handled at each stage.

Look for unsafe SQL construction, dangerous HTML rendering, unrestricted URL fetching, shell command construction, and unvalidated file paths.

Do not assume that an AI model sanitizes input correctly. Security controls should be implemented in the application and enforced independently of model behavior.

Step 6: Prove the Impact Safely

A useful security report needs evidence that a real security boundary can be crossed.

Use harmless test data and controlled environments whenever possible. Avoid accessing unrelated users' information, changing production data, or executing destructive actions.

Document the affected feature, the conditions required to reproduce the issue, the security control that failed, and the potential impact.

A clear, minimal proof of concept is usually more valuable than an aggressive test that creates unnecessary risk.

Classic Application Security vs. AI-Specific Security

It is tempting to treat every AI security issue as a prompt injection problem. That approach misses an important part of the picture.

AI-specific vulnerabilities can involve instruction manipulation, unsafe tool use, and unintended disclosure through model behavior. Traditional vulnerabilities arise from weaknesses in application code, authorization, data handling, and infrastructure.

These categories can overlap.

For example, prompt injection might influence an AI agent to request an operation it should not perform. If the backend then executes that operation without checking authorization, the system has both an AI-related attack path and a traditional access-control failure.

Fixing the prompt alone may not solve the underlying problem.

A stronger design ensures that even if the model is manipulated, the backend still enforces permissions and rejects unsafe operations.

The goal is not to choose between AI security and application security. It is to apply both.

How Developers Can Build Safer AI Features

Security needs to be part of the design process, not something added after a vulnerability is discovered.

Here are some important practices:

• Enforce authorization server-side. Check permissions for every sensitive data access and action.
• Use parameterized database queries. Never trust model-generated text to produce safe SQL.
• Treat model output as untrusted. Apply appropriate validation, encoding, and sanitization before using it elsewhere.
• Restrict tool permissions. Give AI agents only the capabilities they actually need.
• Control outbound network access. Prevent unnecessary access to internal services and sensitive infrastructure.
• Protect file operations. Restrict paths, validate file access, and isolate processing environments.
• Test complete workflows. Include AI-driven operations in existing security reviews, automated tests, and penetration tests.
• Monitor sensitive actions. Log relevant tool calls and backend operations while avoiding unnecessary collection of private information.

These measures will not eliminate every AI-related security risk, but they can prevent many familiar vulnerabilities from becoming serious problems in AI-powered systems.

Final Thoughts

AI is introducing new ways for users to interact with software, but the fundamentals of application security remain the same.

A chatbot can retrieve private documents. An AI agent can call an API. A model can generate content that appears in a browser. Each of these actions depends on traditional software components that still need proper security controls.

For bug bounty hunters, this means there is more to investigate than prompts and model responses.

Look at the APIs behind the chatbot. Understand how permissions are enforced. Follow data from user input to database queries, file operations, external requests, and browser rendering.

Sometimes, the most interesting finding will not be an entirely new AI vulnerability. It will be a familiar security flaw hiding behind a new interface.

The AI feature may be new, but the security mistake behind it might be decades old.

AI assistance:_ I used an AI-powered grammar and spelling checker to review this article. The ideas, research, technical analysis, and final content are my own._

Have questions or want to share your own workflow? Drop a comment below or connect with me on :

🔗Linkdin: https://www.linkedin.com/company/sam-shield/

🔗Youtube: https://www.youtube.com/@sam_shield-w7l

🔗Medium: https://medium.com/@samadhanshimple