When security researchers Viral and Akshay tried to file their income tax returns last month, they stumbled on a serious security flaw in the Income Tax (IT) Department’s e-filing portal—one that could have exposed sensitive financial data of millions of taxpayers.
The first hint something was wrong came from a small, technical habit of the site: whenever the portal communicated with its servers to fetch data pertaining to the user, it was designed to include the user’s PAN (Permanent Account Number)—the unique ID used for all tax work—in the background, even in requests where it shouldn’t be needed. Normally, the PAN is only required during the login phase, so seeing it included by the application in most other requests was unusual.
Most people would never notice this, but anyone looking through developer tools—a built-in browser feature that lets you see all the hidden requests and responses between your computer and a website—would spot it immediately.
To someone who understands how secure websites should behave, it was a red flag.
Using these tools, the researchers edited one of the server requests and replaced their own PAN with a friend’s PAN. The portal obediently returned the friend’s full tax record—income, tax liabilities, employer details, and bank accounts—without asking for any fresh verification.
No OTP was sent to the friend. No notification. That’s because the portal used OTPs only to confirm someone during login: you sign up or log in by entering your PAN and basic details, the site sends a one-time password to the phone or email linked to that PAN, you enter the OTP, and the portal marks you as “authenticated”. But after that initial step, the system should have enforced authorisation checks on the server every time a record was requested—asking, in effect, “Does this logged-in user have the right to see PAN X?” It didn’t.
A secure system does two things: it confirms who you are when you log in, and then it checks, on the server, whether that logged-in person is allowed to see any particular piece of data. Here, the portal appeared to be trusting whatever PAN the browser sent and using it as the only key to fetch records. That’s not how secure systems normally work.
For the same duo, who earlier found the massive data leak in Apollo Hospitals, the vulnerability on the IT portal was “easy to identify”. But despite its simplicity, the consequences were enormous. The endpoint returned every piece of Sensitive Personally identifiable Information (SPII) and financial information associated with a PAN, meaning that an attacker could potentially access the full profile and tax history of anyone who had a registered account.
Both Decode and the researchers immediately reported the flaw to the Income Tax Department and CERT-In in late September. CERT-In confirmed that it had informed the relevant department. According to the researchers, by October 1, the vulnerability had been patched and was no longer exploitable.
What Are Developer Tools?
Developer tools are like a microscope for web pages: developers use them to inspect code, watch what files load, and see each request the browser sends to the server. Some features even let you change a request and send it again. This helps developers see how a website or app reacts to different inputs, which is useful for testing bugs or checking if a fix works.
Who might misuse this? Bad actors can intentionally misuse the tools to gain unauthorised access, steal data, or manipulate web behaviour. Like, intercepting requests to view hidden data, sending fake requests to trick a system, or deliberately trying to bypass security controls.
For example, altering a “discount” or “price” field in an online form to try to get a better deal. Such exploits succeed if a website trusts what’s sent from the user’s side instead of double-checking it safely on the server.
In fact, such risks aren’t just theoretical. In Karnataka, a 32-year-old engineer was arrested for allegedly hacking into the Income Tax Department’s e-filing portal and siphoning off crores in refunds. Investigators say he manipulated bank account and refund details by exploiting vulnerabilities in the portal’s back end, targeting multiple taxpayers and stealing funds totalling around Rs 3.6 crores.
The key problem is not the developer tools themselves—those are legitimate and essential for building the web—but the portal’s decision to trust the input without proper server‑side authorisation. It’s like letting someone open a safe simply by whispering an account number, without checking their ID.
How the Vulnerability Worked
The flaw, known as an Insecure Direct Object Reference (IDOR), is essentially a trust problem. Imagine a website where entering your membership number lets you see your profile. If the system automatically shows whatever profile matches the number you type, without checking if it’s really yours, anyone could type someone else’s number and see their information. That’s exactly what happened here: the portal used the PAN sent by the browser to fetch data, without confirming it belonged to the logged-in user.
Normally, the system should only fetch the profile of the authenticated user, including income, tax liabilities, bank details, and more, directly from the authenticated session, instead of trusting user-supplied data. Instead, the researchers discovered that by simply changing the PAN number in the background request, anyone could trick the system into revealing someone else’s complete financial information—without hacking the portal or filling out a form.
Anyone with a PAN could become an “authenticated” user—all it takes is signing up on the Income Tax Department’s website with basic details and an OTP sent to the linked phone or email. Once logged in, that user could access anyone’s data simply by changing the PAN in the background request.
Every registered taxpayer was potentially at risk—individuals, companies, trusts, charitable organisations, foreign entities, and other legal entities that file taxes in India. An attacker who knew—or could guess—a PAN, which isn’t difficult given its predictable format, could potentially access the full records.
Adding to the irony, the IT portal itself lists the total number of registered users in a section called “Success Enablers”. On the day the flaw was discovered, this page showed 13,50,27,928 PAN-linked accounts nationwide—all of which could have been exposed.
The researchers showed that an attacker could make the portal display someone else’s tax records just as they would appear on the website for them—clearly formatted and easy to read right within the website. They also shared a screenshot from their proof of concept, revealing that data related to a well-known company involved in developing the IT portal, was appearing in the leaked information.
Screenshot showing leaked data tied to the IT portal’s developer
To demonstrate the risk, the researchers shared with Decode a harmless demo app, built using a dummy PAN. It showed how easily an endpoint like that could return a complete profile. They warned that a malicious actor could have automated the process to scrape private financial data at scale.
According to their demonstration, the portal returned an astonishing amount of information. It showed the taxpayer’s name, father’s name, date of birth, Aadhaar (where linked), and residential address. It included employer details, salary, and TDS information, as well as all bank accounts linked to the PAN. The portal even revealed income from all sources, pre-computed tax liabilities, and details such as the tax regime, filing status, deductions, and forms like 24Q.
Beyond this, it displayed disclosures of movable and immovable assets (where declared), along with other attachments. Essentially, anyone who could exploit this flaw could access nearly every detail of a person’s financial and personal life.
Data was accessible by merely altering the PAN in the request
The vulnerability didn’t just expose current financial details, it also gave access to past tax records. The portal stores and displays past tax returns, typically for up to the last five years, so this flaw would have also exposed an entity’s historical filings, including income details, deductions, and refunds for those years.
According to the researchers, their observations suggest that the vulnerability could have already been exploited in the past.
Could Advanced Security Features Prevent this?
According to the researchers, no account-level security features offered by the IT Portal could have stopped this vulnerability. Even users who have turned on high security features—including a second step verification via Aadhaar or SMS-based one-time passwords — were at risk. “It’s as simple as changing a number in a request to get anyone’s complete information,” they explained.
They also highlighted a weakness in session management. On the portal, the session expiry is handled client-side, meaning the server doesn’t actively enforce logouts. In practical terms, an attacker could maintain access longer, bypassing automatic protections that normally limit exposure.
This type of flaw, known as an IDOR, is common enough to appear in the OWASP Top 10 security risks. In fact, the Indian Computer Emergency Response Team (CERT-In) has, in the past, published an high-severity advisory, warning that “there is an increase in exploitation of insecure direct object reference (IDOR) vulnerability in Indian cyberspace” and that the exploitation of IDOR vulnerability “may lead to unauthorized access to data and hence may result in potential data breach”.
The researchers noted how quickly it could be found: one of them independently discovered the vulnerability in around six minutes, just by knowing the portal had a leak.
The severity of the flaw also echoes past vulnerabilities in India’s tax infrastructure. In 2020, cybersecurity firm CloudSEK reported that a hacker listed roughly 800 GB of sensitive data from a state tax office on a Russian forum, claiming administrative access to the network.
Separately, the Income Tax Department quietly patched another bug in 2020 that could have let attackers run code on a part of its website. A security researcher reported the flaw to CERT-In, and though no data was lost, the vulnerability could have exposed employee logins or allowed attackers to deface the site or gain full remote access.