Skip to content

Sync opencraft/ulmo with upstream 2026-08-04--1785884912 - #857

Closed
opencraft-requirements-bot wants to merge 2 commits into
opencraft/ulmofrom
sync-release/ulmo-2026-08-04--1785884912
Closed

Sync opencraft/ulmo with upstream 2026-08-04--1785884912#857
opencraft-requirements-bot wants to merge 2 commits into
opencraft/ulmofrom
sync-release/ulmo-2026-08-04--1785884912

Conversation

@opencraft-requirements-bot

Copy link
Copy Markdown

Description

Syncing opencraft/ulmo with upstream openedx/openedx-platform#release/ulmo.
This PR was auto-created by the sync-opencraft-forks-with-upstream workflow.
It may be reviewed in the scope of SE-6622 (private ticket).
Regular sync-ups like this one help reduce drift and ensure recent patches (security, fixes, etc.) are pulled in.

❗ Important

When merging, please always use the "Create a merge commit" option as it avoids issues when checking diffs with upstream later on.

⚠️ Note on Conflicts

In cases of conflicts you can go ahead and resolve them here on GitHub if it is simple enough. However if it is a more complicated conflict please follow the steps below:

  1. Check out sync-release/ulmo-2026-08-04--1785884912 locally:
  2. Pull latest changes from opencraft/ulmo into that branch, make sure your [REMOTE] is pointing to opencraft/ulmo:
git pull [REMOTE] opencraft/ulmo
  1. Resolve the conflicts locally, then commit the result. This will create a new merge commit.
  2. Push the new merge commit to sync-release/ulmo-2026-08-04--1785884912 to update this PR.
  3. Review the PR again and merge when ready!
    Note: As mentioned above, please use the "Create a merge commit" option when merging.

jacobo-dominguez-wgu and others added 2 commits July 20, 2026 14:39
CourseTeamManageAPIView at
lms/djangoapps/support/rest_api/v1/views.py declared only
`permission_classes = (IsAuthenticated,)`, so any authenticated
user — including a plain enrolled learner — could invoke GET and
use the 404-vs-200 response for user enumeration against arbitrary
email/username/user_id values, confirming which accounts exist and
are active. Callers holding any course/org `instructor` role
additionally received the target user's `staff`/`instructor` role
map across the caller's scope.

Gate `get()` on `_caller_can_manage_course_team()`, a new helper
that returns True only for:

  - is_staff (GlobalStaff), or
  - is_superuser, or
  - SupportStaffRole, or
  - any user with a CourseAccessRole of role="instructor"

This is the union of PUT's current authorization set (admin/staff/
superuser/instructor) and the global SupportStaffRole. Read access
must match write access — a user who can PUT role changes must be
able to see the current state before making them — and the endpoint
lives in the support module, so support staff belong in the set
too. Also extend `get_accessible_courses_for_user` so that
SupportStaffRole users get the same all-courses view as admin/
staff, otherwise they'd fall through to the instructor branch and
receive an empty result set.

Anonymous callers still get 401 from DRF's IsAuthenticated; plain
learners now get 403 before the target lookup runs, so the 404-vs-
200 enumeration discrepancy (CWE-204) is no longer reachable by
unauthorized callers. Course instructors retain their scoped view.

`put()` retains its existing authorization for now; it lacks
SupportStaffRole in the set — a separate design gap best handled in
a public follow-up after publication (cross-linked to
GHSA-95xv-3c54-c3pw), where the `_caller_can_manage_course_team`
helper can also become the shared PUT check.

Fixes GHSA-95xv-3c54-c3pw. Credit: 5ud0 / Tarmo Technologies.
@samuelallan72
samuelallan72 deleted the sync-release/ulmo-2026-08-04--1785884912 branch August 4, 2026 23:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants