Skip to content

Fix: Priviledge Escalation#52

Merged
ardelato merged 4 commits into
hermesfrom
fix/privilege-escalation-c1-c2-m1
Apr 24, 2026
Merged

Fix: Priviledge Escalation#52
ardelato merged 4 commits into
hermesfrom
fix/privilege-escalation-c1-c2-m1

Conversation

@ardelato
Copy link
Copy Markdown
Collaborator

Description

Patches three security vulnerabilities identified in the audit and already fixed upstream in TheRestartProject#843.

  • C1 (Critical): Profile edit endpoints accepted an unvalidated id parameter, allowing any authenticated user to edit any other user's profile, password, photo, or role. Added ownership-or-admin authorization checks to postProfileInfoEdit, postProfilePasswordEdit, postProfilePictureEdit, and an admin-only gate to postAdminEdit.
  • C2 (Critical): The edit() method passed $request->post() directly to User::update() with only a denylist of unset fields. Switched to an explicit allowlist via $request->only().
  • M1 (Medium): role and api_token were in the User model's $fillable array, making them mass-assignable. Removed both and updated all callers to use direct property assignment.

QA Notes

We will need to validate this in the test cluster.

Profile edit methods accepted an unvalidated id parameter from the
request body, allowing any authenticated user to edit any other user's
profile, password, photo, or role. This adds ownership-or-admin gates
to postProfileInfoEdit, postProfilePasswordEdit, and
postProfilePictureEdit, and an admin-only gate to postAdminEdit.
The role update in postAdminEdit is also changed from mass assignment
to direct assignment in preparation for removing role from $fillable.
The edit() method passed $request->post() directly to User::update()
after unsetting only a few keys. This denylist approach allowed
injection of sensitive fields like role and api_token. Switching to
$request->only() ensures only explicitly listed profile fields can
be mass-assigned through this endpoint.
These sensitive fields were mass-assignable, enabling privilege
escalation if any controller passed unfiltered request data to
User::update() or User::create(). All call sites that previously
set role via mass assignment now use direct property assignment.
Eight tests covering the C1 (IDOR), C2 (mass assignment), and M1
(sensitive fillable fields) vulnerabilities. Includes both negative
cases verifying non-admin users are blocked and positive cases
confirming administrators retain access.
Copy link
Copy Markdown
Member

@sctice-ifixit sctice-ifixit left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

CR 🌷

@ardelato
Copy link
Copy Markdown
Collaborator Author

QA 👍 Confirmed we are now getting 403 responses

@ardelato ardelato merged commit aaf54c9 into hermes Apr 24, 2026
@ardelato ardelato deleted the fix/privilege-escalation-c1-c2-m1 branch April 24, 2026 18:13
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.

2 participants