How We Discovered a Stored HTML Injection in a Chatbot System 🕷️

This write-up has been prepared under the guidance of Amish Patel, Lay Patel at Hacker4Help as part of our learning initiative on cybersecurity awareness.

🔍 Introduction

As budding cybersecurity enthusiasts, we’re always on the lookout for vulnerable systems that can help us learn and sharpen our skills. One casual evening of testing led us — Het Patel and **Kaif Shah — to discover a Stored HTML Injection vulnerability** in the chatbot feature of redacted.co.in, an AI-driven platform that connects users with verified professional experts across various categories.

So Let’s get started 😎

What is Stored HTML Injection? 💥

Before we dive into the juicy details, let’s break down what Stored HTML Injection actually is (because not everyone speaks fluent hacker 🤓):

Think of it like this: Imagine you’re at a restaurant and the waiter takes your order without questioning it. You ask for “spaghetti with a side of surprise ingredients” and the kitchen just… makes it. No questions asked. That’s essentially what happens with stored HTML injection! 🍝

Hence, Stored HTML Injection occurs when user-supplied HTML content is not properly sanitized and is saved in the application’s database. When this data is later rendered on a page, the HTML is executed directly, which could lead to defacements or further security issues such as phishing or XSS (if scripts are allowed).

This can lead to:

• 🎭 Page defacements (making websites look funky)
• 🎣 Phishing attacks (tricking users)
• ⚡ XSS vulnerabilities (if scripts sneak through)

The Setup: Where We Found It 🧪

While exploring the AI chatbot feature of pyng.co.in, we noticed an input field where users could send messages. At first, it seemed harmless — but our curiosity nudged us to test how it handled raw HTML.

Payload and Execution

We entered the following simple HTML tag as our message:

<h1>Hello from Het & Kaif</h1>

To our surprise, when the chat history was loaded on page refresh or revisit, the message was rendered exactly as HTML — not escaped, not sanitized. This confirmed a stored HTML injection — the HTML was being stored server-side and rendered client-side without any filtering.

We also tried several other payloads to confirm the injection:

<b style="color:red">XSS</b>
<i onclick="alert('XSS')">Click me</i>
<div style="background:red;padding:10px">Injected DIV</div>
<b style="color:red">XSS</b>

However, since JavaScript execution was fully disabled, despite attempting multiple payloads and bypass techniques, we were unable to achieve any successful execution.

Screenshot of Payload Execution

📬 Responsible Disclosure

We followed responsible disclosure practices:

• Reported the bug to the redacted.co.in team.
• Shared steps to reproduce and suggestions to mitigate.

We did got the reply from support team:

They were already aware of the vulnerability so they marked our report as “Duplicate Submission” 😭

About the Authors:

• **Het Patel** — Cybersecurity Enthusiast | Bug Hunter | Coffee Addict ☕
• Kaif Shah — Security Researcher | CEHv11 | CRTA | Top 4% THM | Bug Hunter

Happy Hacking! (Ethically, of course) 😉🔒