Sakai is a Collaboration and Learning Environment (CLE). From 23.0 until 23.5 and 25.3, the DELETE /api/users/{userId}/profile/image endpoint allows an authenticated user to delete another user's profile image because ProfileController.removeProfileImage() passes the attacker-controlled userId to ProfileServiceImpl.removeProfileImage() without verifying ownership, and profileImageUploadedRepository.deleteById(userId) removes the selected row. The related DELETE /api/users/{userId}/profile/pronunciation endpoint also omits session validation and ownership checks before ProfileServiceImpl.removePronunciationRecording() deletes the target user's recording. The upload path is not affected because it already verifies ownership, and superusers remain intentionally authorized to modify other profiles. Successful exploitation can repeatedly remove profile identity artifacts, including administrator and instructor images, and disrupt workflows that rely on those artifacts. This issue is fixed in versions 23.5, 25.3, and 26.0.

Affected: Maven: org.sakaiproject.profile2:profile2-api, Maven: org.sakaiproject.profile2:profile2-impl

### 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:

```java @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:

```java if (!sakaiProx…