Finding Exposed Student Data on a Nursing College Portal

Disclaimer

This writeup documents a vulnerability identified through observation of publicly accessible resources during security research. No authentication was bypassed, no vulnerabilities were exploited beyond confirming the exposure, and no sensitive data was downloaded, retained, or shared.

The vulnerability was reported responsibly to the affected organization prior to publication and has since been remediated. Any identifying information has been redacted where appropriate.

This writeup is provided for educational and defensive security purposes only.

How It Started

I wasn't targeting this site specifically. I was doing general recon practice and browsing public-facing web apps, as well as checking for common misconfigurations.

I ended up on [redacted]/portal/login, the student portal for a nursing college in Ghana.

I started reconnaissance on the application using browser developer tools and noticed the logo tag:

<img src="public/img/yamfo/crest.jpg" style="width:200px;height:auto">

That relative path was interesting because it revealed part of the application's directory structure. I started looking into how the application was loading its resources and used the network tab to map out publicly accessible files. While reviewing the requests being made by the application, one GET request stood out:

GET /portal/public/gadwork/js/modules/materialadmin/libs/jquery/jquery-1.11.2.min.js

That gave me a full path to work with. I started reviewing the application's structure from /portal/public/, which led to the discovery that directory listing was enabled.

Finding 1 - Directory Listing Enabled

/portal/public/gadwork/js/modules/materialadmin/

The server was exposing a browsable file tree without any access restrictions, allowing anyone to view the application's internal JavaScript module structure.

Index of /portal/public/gadwork/js/modules/materialadmin/
├── core/
└── libs/

This is a classic web server misconfiguration. When directory listing is enabled, the application's file structure can be viewed without authentication.

From a reconnaissance perspective, this reveals details about the technologies in use, the organization of application resources, and provides additional insight into the application's exposed surface.

The JavaScript assets themselves are not inherently sensitive. The issue is the directory listing, which exposes the application's file structure and provides unnecessary insight into its internal organization.

Since the server is running LiteSpeed, directory indexing should be disabled at the web server level and verified to ensure internal application directories are not publicly accessible.

Finding 2 - Public Laravel Log Files

/portal/storage/logs/

While reviewing additional exposed directories, I discovered a far more significant issue.

The /storage/logs/ directory should never be publicly accessible in a Laravel application. In this case, it was. Directory listing was enabled here as well, revealing a collection of daily log files.

laravel-2026-05-13.log
laravel-2026-05-14.log
laravel-2026-05-15.log
...

I opened one of the log files to confirm the exposure. A typical entry looked like this:

[2026-05-15 07:35:08] local.INFO: Student Logged_in (by user_id xxxx)
Array
(
    [ipAddress] => xxx.xxx.xxx.xxx
)

The logs recorded student activity such as logins, with each entry containing the student's user ID and IP address. Additional entries showed activity across different areas of the portal, including account actions and other student-facing features, with records spanning multiple days of log files.

What was exposed:

• User IDs — Sequential identifiers associated with student accounts, potentially allowing the range of accounts to be inferred from exposed logs.
• IP addresses — Recorded alongside user activity, linking network information to specific sessions.
• Activity history — Portal actions recorded in the logs, including account activity, timestamps, and accessed features.
• Endpoint information — Portal routes and features referenced within log entries, providing additional insight into the application's structure.

This was sensitive student information belonging to real people. Their data should not be accessible through a public URL with no access control.

Why This Happens in Laravel

Laravel by default stores its logs in /storage/logs/. The framework assumes the web server is configured to only serve files from the
/public/ directory, which is the only directory intended to be directly accessible from the web.

If the document root is incorrectly pointed at the project root instead of /public/, internal application directories such as storage, config, and vendor may become publicly accessible. This can expose sensitive files that were never intended to be served by the web server.

In this case, that misconfiguration allowed the application's log files to be accessed directly through a public URL.

This is a deployment misconfiguration, not a Laravel flaw. Recommended remediation:

• Set the web server document root to /portal/public/, not /portal/.
• Restrict direct access to /storage/ through web server configuration as an additional safeguard.
• Disable directory listing where it is not required.

What I Did

• Recon — Reviewed publicly accessible resources. No authentication was bypassed and no automated tools were used.
• Confirmed — Opened a single log file to verify the severity of the exposure.
• No Data — Did not download, retain, or share any student information.
• No Abuse — Did not attempt to access accounts or use exposed identifiers for unauthorized actions.
• Disclosed — Sent a responsible disclosure report to the institution containing technical details and remediation recommendations, with a 30-day disclosure window.

Takeaways

Directory listing is easy to dismiss as low severity. "It's just JS files" is a common thought, but this is a good example of why small misconfigurations are worth investigating. The same issue that exposed a JS module folder also exposed the application's log directory, which contained much more sensitive information.

If you're deploying a Laravel app, make sure your document root points to /public/. Everything outside of that directory should stay private, and it is worth checking your deployment settings before going live.

Home