CVE-2026-117028: BOLA in Skuul School Management System

CVE-2026-117028 — Broken Object-Level Authorization in Skuul School Management System

Affected component: app/Livewire/ResultChecker.php — checkResult()
Affected versions: Skuul School Management System through version 2.6.5 (as reported; confirm against the upstream release history)
Vulnerability class: Broken Object-Level Authorization (BOLA) / Insecure Direct Object Reference (IDOR)
Impact: Unauthorized disclosure of another student’s examination results
Researcher: Sushil Poudel (dollarboysushil)

Summary

Skuul School Management System through version 2.6.5 is reported to contain a broken object-level authorization vulnerability in the Livewire ResultChecker::checkResult() action.

An authenticated user with a low-privilege student or parent role may be able to supply another student’s identifier and retrieve that student’s examination results, including marks. The action does not adequately verify that the requested student belongs to the authenticated student’s identity, is linked to the authenticated parent, or belongs to the appropriate school.

The issue was reproduced on a local, seeded test instance using test accounts and synthetic examination data.

Security impact

A successful exploit may disclose confidential student information, including examination marks and associated result details. Because the exposed information concerns students, including potentially minors, it should be handled carefully.

• Attacker requirements: An authenticated account with access to the result-checking functionality.
• User interaction: None from the victim.
• Demonstrated impact: Unauthorized read access to another student’s result table.
• Not demonstrated: Modification of results, privilege escalation beyond the demonstrated read access, or availability impact.

Affected component and suspected root cause

• Component: app/Livewire/ResultChecker.php
• Method: checkResult()
• Reported location: Around line 122; line numbers may vary by revision.

The method reportedly accepts a student model resolved from a client-supplied identifier but does not enforce sufficient object-level authorization before retrieving and rendering results. The page-level permission check appears to establish only that the user has the general check result permission; that permission alone does not establish entitlement to view the specific student’s results.

The report also identifies updatedClass / updatedSection actions as potentially exposing user records without adequate role- or school-scoped filtering. This should be reviewed as a related access-control concern.

These root-cause details are based on the researcher’s analysis and should be checked against the exact upstream commit being assessed.

Proof of concept

Test environment

The finding was reproduced in a local development instance using seeded test accounts. The example data below is synthetic and is provided to make the test scenario understandable.

• Attacker account: Student test account, user ID 4
• Victim account: Separate test student, user ID 8
• Academic year ID: 1
• Semester ID: 1
• Test result: 87 marks
• Endpoint/page: /dashboard/exams/result-checker
• Livewire action: checkResult

Do not use these example credentials or identifiers against a public or third-party deployment. Run the reproduction only on an instance you own or are explicitly authorized to test.

Test data setup

On a disposable local test database, create an examination record for the second test student and ensure the test student’s academic-year enrollment is configured so the result is eligible to appear. For example, the reported test record was equivalent to:

ExamRecord::create([
    'user_id' => 8,
    'section_id' => 1,
    'subject_id' => 1,
    'exam_slot_id' => 7,
    'student_marks' => 87,
]);

This is illustrative setup code, not a migration or a complete seed procedure. Confirm that the referenced user, section, subject, exam slot, exam, and academic-year records exist and are consistent in your local test database. Back up the database first and remove test records after testing if they are no longer needed.

Reproduction steps

1. Start a local Skuul instance populated with test data and two test student accounts.
2. Sign in as the first student (user ID 4).
3. Open /dashboard/exams/result-checker and confirm that the account can access the result-checking page.
4. Using the browser’s developer tools on this local test instance, inspect the Livewire component named result-checker.
5. Invoke its checkResult action with the test academic year, semester, and the other test student’s ID (8), rather than the signed-in student’s ID.
6. Inspect the Livewire update response and the re-rendered result table.
7. Vulnerable behavior: The response includes the second test student’s result heading and the synthetic 87 mark, even though the request was made by the first student’s account.
8. Repeat the test after applying a fix. The unauthorized request should be denied, and no victim result data should be returned.

The key test condition is whether a student can retrieve another student’s result by changing the object identifier. The result should be denied server-side, regardless of whether the request is made through the browser UI or a direct component request.

Expected versus observed behavior

Condition	Expected behavior	Observed in the reported local test
Student requests their own result	Return only their authorized results	Result-checking page was accessible
Student requests another student’s result by changing the ID	Deny the request and disclose no result data	The other test student’s name and 87 mark were returned
Parent requests a student result	Return results only for a verified linked child in the correct school	Reported as potentially affected; validate with a dedicated parent-account test
User requests records outside their school	Deny access	Requires explicit regression testing

Evidence

The researcher reports observing the victim test student’s name and the synthetic mark 87 in the Livewire effects.html response. Preserve the original request and response privately for verification, but redact session cookies, CSRF tokens, Livewire snapshots, real personal information, and other secrets before sharing any evidence publicly.

No raw session-bearing HTTP request or response is included in this public write-up. The browser-based steps above describe the essential authorization test without exposing reusable session material.

CVSS assessment

Provisional CVSS v3.1 vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
Provisional score: 6.5 (Medium)

This assessment assumes the issue is remotely exploitable by an authenticated low-privilege account, requires no victim interaction, and primarily affects confidentiality. The final score should be independently validated against the deployed application’s access requirements and the scope and sensitivity of the data exposed.

Researcher

Sushil Poudel
Handle: @dollarboysushil

---