GitLab has remediated an issue in GitLab CE/EE affecting all versions from 18.0 before 19.0.5, 19.1 before 19.1.3, and 19.2 before 19.2.1 that under certain conditions could have allowed an authenticated user to modify CI/CD configuration belonging to another user due to improper validation of user-supplied attributes when processing pipeline schedule inputs.
Weakness
The product receives input from an upstream component that specifies multiple attributes, properties, or fields that are to be initialized or updated in an object, but it does not properly control which attributes can be modified.
Affected Software
| Name | Vendor | Start Version | End Version |
|---|---|---|---|
| Gitlab | Gitlab | 18.0.0 (including) | 19.0.5 (excluding) |
| Gitlab | Gitlab | 19.1.0 (including) | 19.1.3 (excluding) |
| Gitlab | Gitlab | 19.2.0 (including) | 19.2.0 (including) |
Extended Description
If the object contains attributes that were only intended for internal use, then their unexpected modification could lead to a vulnerability. This weakness is sometimes known by the language-specific mechanisms that make it possible, such as mass assignment, autobinding, or object injection.
Potential Mitigations
- If available, use features of the language or framework that allow specification of allowlists of attributes or fields that are allowed to be modified. If possible, prefer allowlists over denylists.
- For applications written with Ruby on Rails, use the attr_accessible (allowlist) or attr_protected (denylist) macros in each class that may be used in mass assignment.