IRCTC Vulnerability: How One Parameter Exposed IRCTC User Data

IRCTC Vulnerability: Introduction

Note – A big shoutout to Rohan Kar, one of our security researchers at Seconize, for identifying a critical flaw in the IRCTC platform

In June 2025, while booking a train ticket via the official IRCTC platform, I came across a critical security flaw affecting users who opt for travel insurance through United India Insurance Company (UIIC). This IRCTC vulnerability, an Insecure Direct Object Reference (IDOR), could allow unauthorized access to insurance certificates of other passengers.

This article documents the full discovery process, technical proof of concept, and the impact of the vulnerability — responsibly reported to CERT-In and relevant stakeholders.

🔍 IRCTC Vulnerability Summary

  • Type: Insecure Direct Object Reference (IDOR)
  • Affected Platforms:
  • IRCTC Web Application
  • Integrated travel insurance API from United India Insurance Company (UIIC)
  • Impact: Unauthorized access to personal insurance certificates of IRCTC users via predictable and modifiable API parameters.

📌 Affected Endpoint

https://example.in/IrctcRestService/IrctcPaCert?pnrNo=MTc1MzI3NzEyMg==
All a hacker needs is a hint… and a padded string.

The pnrNo parameter is a Base64-encoded PNR number.

Example:

GET /IrctcRestService/IrctcPaCert?pnrNo=MTc1MzI3NzEyMg==  # Decodes to: 1753277122

By altering this Base64 value, I could access the insurance certificate of any valid PNR number without any form of authentication or authorization.

Guess I’m the insurance agent now. 😎

🧪 Proof of Concept (PoC)

  1. Book a Ticket via IRCTC with travel insurance selected.
  2. After booking, a message is sent to the passenger containing a link to fill nominee details.
  3. Once the nominee information is submitted, a “Download Certificate” option becomes available.
  4. At this stage, we intercept the download request using Burp Suite.
  5. The insurance certificate is generated and retrieved via a UIIC API endpoint.
  6. The browser makes a GET request to the following URL:
  • https://example.in/IrctcRestService/IrctcPaCert?pnrNo=<Base64EncodedPNR>
  • By changing the pnrNo parameter to another valid encoded PNR (e.g., MTc1MzI3NzEyMg==), the API returns another user’s insurance certificate.

Quick Test with curl:

curl "https://example.in/IrctcRestService/IrctcPaCert?pnrNo=MTc1MzI3NzEyMg=="

⚠️ Note: Testing was strictly limited to self-booked PNRs to avoid violating user privacy or legal boundaries.

💡 In a test environment, I created a Python POC to automate requests. With minimal effort, it was possible to access certificate data for 50+ valid PNRs, highlighting the potential scale of abuse.

🔐 Impact

  • Privacy Violation: Any user could access other passengers’ insurance documents.
  • Data Exposure: Includes full name, email, mobile, travel details, insurance coverage, and policy number.
  • Business Risk: Loss of user trust in IRCTC’s handling of sensitive data.

📬 Disclosure Timeline

End of June 2025 IRCTC Vulnerability discovered during booking flow

Early July 2025. Reported to CERT-In and IRCTC

CERT-In confirmed receipt of the report and assigned a reference ID for further action.

The vulnerability was silently fixed in mid-June 2025.

The CERT-In team confirmed that the reported IDOR vulnerability has been addressed and requested verification from my end.

🛠️ Fix Verification:

After responsible disclosure, the affected endpoint no longer allows unauthorized access to insurance documents. As part of the fix, the “Download Certificate” option has been removed from the user interface after nominee submission.

Below is a comparison of the interface:

The IRCTC flow showing the Download Certificate button, which triggered the exposed API without authentication.
Download Certificate” option is now removed from the UI, mitigating the IDOR vulnerability.

Lessons & Recommendations

  1. Always authorize API access based on session or token.
  2. Avoid exposing sensitive endpoints publicly.
  3. Implement rate-limiting and audit logging.
  4. Test third-party integrations rigorously.
  5. Encourage security researchers by acknowledging their efforts.

🤝 Closing Thoughts

This discovery highlights how seemingly minor flaws — like missing authentication on a third-party API — can lead to major privacy risks. I appreciate that the issue was resolved quickly, but a formal acknowledgment or bug bounty program would go a long way in building a security-first culture.

Stay secure. Hack responsibly. 🔐

Related

Schedule a Demo​
Book a session with one of our senior Customer Success Specialists.​

Use Cases

Ofofo Cyber Security Marketplace

Copyright © 2024 Seconize Technologies Pvt Ltd. All rights reserved.