How a Canteen App Gave Me Admin Access to Everything

A little story about curiosity, timing, and responsible disclosure.

A New Semester, A New Cafeteria

It was the first day of intersession at Ateneo. Along with the start of classes, a newly renovated cafeteria opened, and with it, a new web-based loyalty and rewards system for students.

Being a Computer Science student and an occasional security enthusiast, I was naturally curious. Out of pure habit (and a bit of fun), I started poking around the app to see how it was built. I was not trying to break anything maliciously, just trying to understand how the system worked under the hood.

The Curiosity Kicks In

At first glance, everything seemed well-implemented. No obvious client-side vulnerabilities. No exposed sensitive information. So I dug a little deeper, following my usual process. I inspected network traffic, checked API endpoints, looked at exposed routes, and searched for any associated domains.

While exploring associated domains and assets, I stumbled upon a different web app that appeared to be a separate internal system, likely used for managing inventory and operations.

The Vulnerability

While analyzing the internal system’s API behavior, I noticed that certain endpoints were publicly accessible even without authentication. In particular, one caught my attention. It was an endpoint responsible for user registration.

Out of respect for responsible disclosure, I won’t share the exact endpoint, but I discovered that the backend allowed anyone to register new accounts. Crucially, it allowed users to specify their role during registration, whether regular user, staff, or admin. There was no server-side validation preventing someone from simply assigning themselves an admin role during sign-up.

Out of curiosity and caution, I submitted a test request where I created a new user account and set the role parameter to admin. The backend happily accepted it and created a fully privileged admin account.

I then logged into the system using these credentials and confirmed that I now had full administrative access. This included sensitive inventory data, user management functionality, and more.

At this point, I immediately stopped any further interaction with the system and prepared my disclosure report.

The Disclosure

I promptly reported the vulnerability to the system’s technical lead, outlining the nature of the vulnerability, the potential impact of unauthenticated privilege escalation and full system compromise, and the exact conditions that allowed the issue.

He was very responsive and handled the disclosure professionally. Shortly after my report, the vulnerable endpoint was taken down and the issue was resolved.

Lessons Learned

This experience reinforced a few key takeaways.

Never trust client input. Role assignments should always be controlled and validated strictly on the server side.

Hidden routes are not secure routes. Just because a form or feature is not exposed in the UI does not mean attackers will not find the underlying API.

Open-source exposure increases your attack surface. When source code is public, vulnerabilities can be easier to spot, but also easier to fix once reported.

Responsible disclosure works. Security research can benefit both parties when handled respectfully.

Responsible Disclosure Notes

No customer data was accessed, modified, or exfiltrated during testing.

All testing was performed with the sole intent of identifying and reporting security weaknesses.

The vulnerability has been fully resolved prior to this write-up being published.

This post was shared for review prior to publication and approved.

Big thanks again to Christian for patching the issue quickly (and for offering to keep an eye out for those canteen vouchers).