thijs.gg

June 9, 2026

Hacking Stanford

How a finals-week distraction exposed where 23,000+ Stanford students live.

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.

Sample of the kind of student data that was exposed
This is not real data — a recreation of the data I could access.

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:

The maintenance notice now shown on stanford.*******.com

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.

Flipping isAdministrator to true in the proxied response
A view of the script editor in Proxyman.

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

The Management button enabled in the frontend

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.

Paginated list of students with dorms and room numbers

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.

Join Mailing List

I'll email you when I write a new post.

© 2026 Thijs Simonian