Recently, while conducting reconnaissance on a school website, our team of security researchers at Avyukt Security found data-exposure vulnerabilities that revealed sensitive admission records containing PII (Personally Identifiable Information) such as names, emails, phone numbers, addresses, profession-related info, etc. The /print-form.php?app_number= endpoint was vulnerable to IDOR (Insecure Direct Object Reference), where upon entering the application number, admission records were exposed without any authorization checks. The same parameter was also vulnerable to SQL Injection and allowed dumping the whole database of records via automated tools.

Additionally, minor low-severity security flaws such as Reflected and Stored XSS, and exposure of XML-RPC and WP-Cron were also discovered.

Note: All the discovered vulnerabilities were responsibly disclosed to the concerned institution via appropriate channels to ensure they could be remediated. No sensitive data was accessed, and no service disruption occurred during the security testing.

The following is a detailed breakdown of the reported findings on the website.

-0x01: Discovery of IDOR on the Admission Registration Form

• The school website was built using WordPress and hosted a submission form for Kindergarten admissions on the /online_form_2025 endpoint.
• After filling the form and completing the submission, the user was redirected to the /online_form_2025/thank-you.php?app_number=[application_id] page which showed the following.

• The application ID fetched from the app_number GET parameter was being reflected on the webpage as shown.
• The parameter could be easily manipulated, and upon clicking the “Print Registration” button, the user was redirected to the /online_form_2025/print-form.php?app_number= endpoint where the registration form of the manipulated ID could be printed.
• The /print-form.php endpoint exposed over 46 columns of data per registration form as the app_number GET parameter was vulnerable to IDOR.
• The webpage exposed critical PII because no authorization checks were implemented to verify that the user was authorized to view the requested registration form data.

-0x02: Discovery of SQL Injection on the Admission Registration Form

• We tested the GET parameter app_number in /online_form_2025/print-form.php?app_number= endpoint for SQL Injection via SQLMap.
• The scan revealed that the parameter was vulnerable to UNION-based SQL Injection.
• We tested the parameter further and were successful in dumping the [school_name]_kg_admission database that stored all the 46 columns of every registration record in thetbl_kg_adm_dataand tbl_kg_secondary_datatables.