CVE-2026-53901
HighCVSS 8.7Exploitation Probability (EPSS)
Low risk23th percentile - higher than 23% of all known CVEs
Summary
Cerebrate before version 1.37 contains a mass-assignment vulnerability in the generic CRUD add path. The add() function does not properly remove the 'id' field from input, allowing a user to set a custom identifier for a new object. This can lead to unauthorized creation of objects with chosen IDs, object spoofing, or identifier collisions.
Risk Assessment
An attacker can manipulate object identifiers, potentially leading to unauthorized data access, reference spoofing, or system disruption.
Recommendation
Update Cerebrate to version 1.37 or later. Restrict access to CRUD endpoints to trusted users only.
Other vulnerabilities in Cerebrate
See all- CVE-2025-66385Critical
UsersController::edit in Cerebrate before 1.30 allows an authenticated non-privileged user to escalate their privileges (e.g., obtain a higher role such as admin) via the user-edit endpoint by supplying or modifying role_id or organisation_id fields in the edit request.
- CVE-2026-53911Medium
Cerebrate before version 1.37 allowed the id primary key field to be supplied through request input during CRUD edit operations and certain custom entity patching flows. This enabled an authenticated attacker to craft edit requests that could modify unrelated records.
Original NVD description (English source)
Cerebrate before version 1.37 contains a mass-assignment vulnerability in the generic CRUD add path. The add() handler attempted to remove an attacker-supplied id from $params before normalizing the request through __massageInput(). Because the normalized $input could still contain an id field, a user able to reach an affected add endpoint could supply an identifier that should have been server-controlled. Successful exploitation could allow creation of objects with attacker-chosen identifiers, potentially causing unauthorized data manipulation, object spoofing, inconsistent references, or disruption through identifier collisions, depending on the affected model and endpoint permissions. The issue was fixed in v1.37 by removing id from the normalized input before entity patching.