Severity: Medium (latent — depends on the Custom Fields feature actually being wired up, see related issue)
CustomFieldModel::setValue() accepts any string for any field with no check against the field's field_type (text/textarea/select/checkbox/date/number), and for select-type fields there's no server-side check against the defined field_options.options list — validation, if it exists at all, would only happen client-side. Additionally, createDefinition()/updateDefinition() don't validate field_type against the six documented allowed values, so a malformed type could be stored and break whatever admin UI renders it.
Fix: Add server-side type/format validation in setValue() (e.g. numeric check for number, date format check for date, allowlist check for select/checkbox), and validate field_type against a fixed allowlist in the definition create/update endpoints.
**Severity:** Medium (latent — depends on the Custom Fields feature actually being wired up, see related issue)
`CustomFieldModel::setValue()` accepts any string for any field with no check against the field's `field_type` (text/textarea/select/checkbox/date/number), and for `select`-type fields there's no server-side check against the defined `field_options.options` list — validation, if it exists at all, would only happen client-side. Additionally, `createDefinition()`/`updateDefinition()` don't validate `field_type` against the six documented allowed values, so a malformed type could be stored and break whatever admin UI renders it.
**Fix:** Add server-side type/format validation in `setValue()` (e.g. numeric check for `number`, date format check for `date`, allowlist check for `select`/`checkbox`), and validate `field_type` against a fixed allowlist in the definition create/update endpoints.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Severity: Medium (latent — depends on the Custom Fields feature actually being wired up, see related issue)
CustomFieldModel::setValue()accepts any string for any field with no check against the field'sfield_type(text/textarea/select/checkbox/date/number), and forselect-type fields there's no server-side check against the definedfield_options.optionslist — validation, if it exists at all, would only happen client-side. Additionally,createDefinition()/updateDefinition()don't validatefield_typeagainst the six documented allowed values, so a malformed type could be stored and break whatever admin UI renders it.Fix: Add server-side type/format validation in
setValue()(e.g. numeric check fornumber, date format check fordate, allowlist check forselect/checkbox), and validatefield_typeagainst a fixed allowlist in the definition create/update endpoints.