This vulnerability stems from a subtle but critical flaw in the platform’s GraphQL implementation. The backend allowed profile pictures to be referenced via a shared profile_picture_id — but failed to enforce strict ownership validation when that ID was mutated via profile updates.
The exploit took advantage of how GraphQL resolvers returned deeply nested user data (including profile picture metadata) to unauthorized users within the same class/group context. By chaining this exposure with a mutation that reused the ID, the attacker could overwrite and delete a victim's profile picture — all through legitimate UI actions, amplified by crafted GraphQL queries.
Unlike REST APIs, GraphQL often returns large, nested response objects. In this case, a query like getClassMembers exposed each user's profilePictureUrl, from which the profile_picture_id could be extracted by parsing the URL. This ID wasn't scoped per user, and the backend didn’t verify that the current user had ownership of the referenced media object when reusing it in a mutation.
Create two accounts:
- User A (victim)
- User B (attacker)
User A creates a “Class” and adds User B to it — establishing access context for viewing user details via GraphQL.
User B performs a query like:
query {{
classMembers(classId: "xyz") {{
id
name
profilePictureUrl
}}
}}
The returned profilePictureUrl contains a UUID — e.g.,
https://cdn.example.com/images/cb227e3c-4bb3-42fc-8c29-b3030d6e86ab/avatar.png
This UUID is the profile_picture_id used internally.
User B now uses a GraphQL mutation to update their own profile and sets:
mutation {{
updateProfile(input: {{
profile_picture_id: "cb227e3c-4bb3-42fc-8c29-b3030d6e86ab"
}}) {{
success
}}
}}
This effectively links both profiles to the same image.
To delete the image, the attacker either sends:
mutation {{
updateProfile(input: {{
profile_picture_id: null
}}) {{
success
}}
}}
Or performs a delete mutation if supported by the schema. Since the object is shared, it is removed globally — affecting the victim as well.