Eaton • Jun 24, 2026

Today I am revealing vulnerabilities I found in 2 very different Johnson & Johnson web apps. One is a vulnerability in a college campus recruiting system that exposed details of nearly 1,000 students, and the other is an admin takeover of an internal audit system used by 20 companies. Let’s dive in!

#1: Campus Recruiting

You know those career fairs and recruiting events on college campuses? JnJ likes to go to these to scout new talent. They built a “Campus Recruiting” website to manage these events:

Students are given an event key and they use it to submit their information:

Nothing particularly exciting… until you look at the underlying code of the website, where you can find some interesting private recruiter routes!

When you go to “/recruiter”, you are sent to the Microsoft SSO login page, confirming this part of the site is restricted to JnJ employees:

The authentication setup is really simple. The Microsoft Authentication Library (MSAL) is integrated into the frontend and it is in charge of making sure an employee is logged in:

One client-side trick that often helps me expose insecure web apps is to hack MSAL into always thinking someone is logged in. If there are underlying APIs that do not use the token correctly, this helps discover such issues quickly. In this case, all I had to do was modify the MSAL code to always return details of 1 account that is “logged in”:

Once done, the private recruiter routes were accessible. You could manage the events, create new ones, and view all the students’ information. The recruiter dashboard also lets you see the ratings and notes they give to specific students they interview:

What went wrong: the MSAL token was not actually used anywhere. Instead, a hardcoded API key was used to authenticate to their AWS APIs:

The Campus Recruiting site has since been updated to replace API key authentication with Bearer token (MSAL) authentication.

#2 Audit Tracking Management System

The Audit Tracking Management System (ATMS) is an internal web app to aid in managing audits across all of JnJ and their associated companies:

1. LifeScan
2. Ethicon, Inc
3. Biosense Webster
4. ITS
5. Depuy
6. Ethicon-Endo
7. Janssen
8. Vistakon
9. Acclarent
10. JDx
11. Sterilmed
12. CLS
13. JJSV
14. Cerenovus
15. EQ
16. Janssen UK & Ireland
17. RAD
18. Abiomed Inc.
19. CQ MedTech
20. V-Wave

This one required a bit more work to get into compared to Campus Recruiting. Immediately when visiting the site, you are redirected to the Microsoft SSO login page. Before this happens, the ReactJS app is downloaded and many interesting APIs could be found:

I decided to visit the “getAllUsers” API to see what would happen. It returned a list of 13.6k JnJ employees:

That was huge because it indicated all the APIs were unauthenticated, and it was just a matter of hacking up the client-side code to get full access to everything.

This is what the authentication code looked like. Like Campus Recruiting, it uses MSAL to authenticate the user using Microsoft SSO, and then it sets some values to local storage. There is no sign of it using the Bearer token, which is good for us!

For a user spoof to work correctly, I needed to find a username and WWID of a valid JnJ employee that uses this system. Preferably one with a lot of permissions. I came across the help page that gave me the details of the system administrator:

Searching that name against users in the getAllUsers API revealed the information I needed, and a patch was devised:

This stops the login redirect and sets hardcoded values into local storage as if a valid login had just taken place. This resulted in something new showing up:

Clicking OK was not the solution. Back into the code we go…

That is the code that creates a session. It is just a GET request to an API that returns a session GUID, and sets a timestamp for the purpose of calculating its expiry. Visiting that API, it returned a valid session ID:

I then plugged that in manually with a valid timestamp…

Refreshed, and I was in!

You can use the drop-down to switch between companies:

As admin, I had access to a special menu:

And that is about the extent of what I explored. The system is packed full of presumably confidential information and transcripts. Even from all the way over in Russia. Due to various confidentiality warnings, I have opted to not show any internal meeting minutes or transcripts here.

Bonus: they used a rather dumb client-side encryption scheme to try and obscure some secret values. Ironically, it seems this auditing system never received an audit itself if code like this ends up being published:

Timeline

The last time I reported a security vulnerability to JnJ was back in 2024. The experience I had back then was stellar – they took immediate action and were a true pleasure to work with. Fast forward to reporting these 2 vulnerabilities, the experience was less positive.

Both vulnerabilities were reported to them in October 2025. By the end of the month, they had resolved the Campus Recruiting vulnerability. However, the ATMS vulnerability was never acted upon. I followed up for months until April 2026, which is when I asked a journalist friend if they could help move things along. As predicted, their email to JnJ’s media relations finally got them to fix it. It was a bit perplexing that it took press involvement to address what I believed was a serious internal data breach waiting to happen.

Full timeline:

• October 6, 2025: Reported to JnJ’s Vulnerability Reporting Program.
• October 16, 2025: Followed up after no response and no action.
• October 17, 2025: First response from JnJ received confirming they will look into the findings.
• October 31, 2025: Campus Recruiting vulnerability fixed; I ask about ATMS.
• November 17, 2025: Followed up after no response and no action on ATMS.
• December 22, 2025: Followed up after no response and no action on ATMS.
• January 22, 2026: Followed up after no response and no action on ATMS.
• April 8, 2026: Journalist contacted.
• April 21, 2026: ATMS vulnerability finally fixed.
• June 24, 2026: Published

Not the best showing for JnJ here. It seemed they were a lot more effective at handling vulnerabilities back in 2024 compared to 2025. I hope they correct whatever broke down in this process so they can return to the amazing reporting experience I had with them back in 2024.