I found and responsibly disclosed a vulnerability in one of Stanford's systems which exposed student data of all 23,000+ undergrad and grad students, including exactly where every student lives on campus.

Finals week. For some reason, rather than studying, I always spend my time tinkering with something for fun. Instead of studying up on CS103, I was browsing Stanford Package Center's package tracking website.
Stanford mail is centralized. To ship any package to campus, it has to be shipped to a Stanford Warehouse in Newark, and then embark on a journey across the Dumbarton bridge where it will land in one of the many package lockers on campus.
To alleviate the confusion of "where is my package???" as it's being processed by the Mail and Package Services (MPS) team, Stanford has a website where students can view the status of all of their packages passing through the Stanford Warehouse and figure out which locker they've been delivered to on campus for pickup.
The site is built by logistics contractor FacilityOS, which builds enterprise software, including package tracking and logistics software for companies and universities. They build the software which Stanford's MPS employees use every day to automatically scan labels and route packages to the right locations on campus.
Visiting the site now, you'll see this message:

Becoming Administrator
During finals week, I'd been waiting for a package to get processed by the warehouse for me to pick up. I'd visited the tracking site, and was curious how it worked.
I'd recently been working on authentication schemes for TreeHacks, and wanted to see how they implemented Stanford OAuth into the tracking site. I opened inspect element and looked at the request flow.
After logging in, the frontend of the site sent a request to the backend requesting information on the user.
The request, https://stanford.********.com/account/GetUserIfLoggedIn, is where the web portal gets information about the logged in user for the frontend to use.
I noticed that the request returned a field isAdministrator: false and was curious what the frontend would look like if that returned true instead.
Using a Man-in-the-Middle proxy, I flipped that boolean in the response.

This made the frontend believe that I was logged in as an administrator, enabling the management portal button.

This isn't that bad inherently, I'd only tricked the frontend into enabling a button. However, this soon exposed the much larger vulnerability.
The Admin Panel
Curious, I clicked the Management button. The admin portal showed up, populated with real information.
While tricking the frontend to display this panel wasn't that significant, none of the requests that the admin portal uses to fetch information were secured. This meant that the recipient lists, device lists, labels, etc are all populated with REAL INFORMATION in this admin view.
Student Room Numbers
One page returned a paginated list of all students, their dorms and room numbers on campus, their addresses, and other information (some phone numbers) without me being an actual admin.
If you were a student or faculty at Stanford in the last few years, you were in here.

Other Pages
Other pages were also visible, displaying the names of all MPS staff and the Zebra scanners they use to scan packages. I'm not showing them here to protect the security of the platform, but it was cool to learn how the system worked!
Editing Config
There were a few pages where printed label format, site design, and email alerts were configured. Luckily, I was unable to modify any configuration, as all of the modification routes were secured correctly. Only fetching the information was possible.
Responsible Disclosure
Immediately, I disclosed the vulnerability to Stanford UIT and FacilityOS's support team, where it was forwarded to the proper VPs and patched in the next few weeks.
Huge props to them for taking it seriously and resolving it quickly!
No bug bounty as this project wasn't in the scope of Stanford's responsible disclosure program.