Several integrations declare page_size or batch_size manifest variables with type: text when the value is always a positive integer. This means Fleet performs no numeric validation — a user (or a misconfigured policy) can set these to arbitrary strings like "abc" or unreasonably large numbers without any rejection at the UI or API layer.
These fields control API page sizes and directly affect memory consumption. Using type: integer would at minimum ensure Fleet rejects non-numeric input.
Affected integrations and fields
| Integration |
Data stream |
Field |
Default |
| abnormal_security |
ai_security_mailbox |
page_size |
100 |
| abnormal_security |
audit |
page_size |
100 |
| abnormal_security |
case |
page_size |
100 |
| abnormal_security |
threat |
page_size |
100 |
| abnormal_security |
vendor_case |
page_size |
100 |
| armis |
alert |
page_size |
— |
| armis |
device |
page_size |
— |
| armis |
vulnerability |
page_size |
— |
| authentik |
event |
page_size |
— |
| authentik |
group |
page_size |
— |
| authentik |
user |
page_size |
— |
| aws_securityhub |
finding |
batch_size |
— |
| cyberark_epm |
admin_audit |
page_size |
— |
| cyberark_epm |
aggregated_event |
page_size |
— |
| cyberark_epm |
policyaudit_aggregated_event |
page_size |
— |
| cyberark_epm |
policyaudit_raw_event |
page_size |
— |
| cyberark_epm |
raw_event |
page_size |
— |
| dataminr_pulse |
alerts |
page_size |
40 |
| elastic_security |
alert |
batch_size |
— |
| google_workspace |
alert |
page_size |
— |
| google_workspace |
calendar |
batch_size |
1000 |
| google_workspace |
chat |
batch_size |
1000 |
| google_workspace |
chrome |
batch_size |
1000 |
| google_workspace |
data_studio |
batch_size |
1000 |
| google_workspace |
gmail |
batch_size |
1000 |
| google_workspace |
keep |
batch_size |
1000 |
| google_workspace |
meet |
batch_size |
1000 |
| google_workspace |
vault |
batch_size |
1000 |
| menlo |
dlp |
batch_size |
1000 |
| menlo |
web |
batch_size |
1000 |
| microsoft_defender_endpoint |
machine |
batch_size |
— |
| microsoft_defender_endpoint |
machine_action |
batch_size |
— |
| microsoft_exchange_online_message_trace |
(package-level) |
batch_size |
1000 |
| microsoft_sentinel |
alert |
batch_size |
— |
| microsoft_sentinel |
incident |
batch_size |
— |
| servicenow |
event |
batch_size |
— |
| splunk |
alert |
batch_size |
— |
| splunk |
search |
batch_size |
— |
| sublime_security |
audit |
page_size |
— |
| sublime_security |
message_event |
page_size |
— |
| tenable_sc |
(package-level) |
batch_size |
1000 |
| ti_greynoise |
ip |
page_size |
5000 |
| ti_recordedfuture |
playbook_alert |
batch_size |
— |
| ti_recordedfuture |
triggered_alert |
batch_size |
— |
| trend_micro_vision_one |
audit |
page_size |
200 |
| trend_micro_vision_one |
detection |
page_size |
1000 |
Proposed fix
For each field listed above, change type: text to type: integer in the corresponding manifest.yml. This ensures Fleet validates the value is numeric before accepting it.
Note: type: integer alone does not enforce minimum/maximum bounds — the package-spec does not currently support minimum/maximum constraints on integer variables (elastic/package-spec would need to be extended for that). This fix addresses the weaker problem: preventing non-numeric input entirely.
Migration consideration
Changing type: text to type: integer for an existing variable is a non-breaking change for users whose current value is already a valid integer (which it should be in all cases — these fields are passed as numeric API parameters). However, any policy that somehow stored a non-integer string would fail validation on next edit. This is the desired behavior.
Several integrations declare
page_sizeorbatch_sizemanifest variables withtype: textwhen the value is always a positive integer. This means Fleet performs no numeric validation — a user (or a misconfigured policy) can set these to arbitrary strings like"abc"or unreasonably large numbers without any rejection at the UI or API layer.These fields control API page sizes and directly affect memory consumption. Using
type: integerwould at minimum ensure Fleet rejects non-numeric input.Affected integrations and fields
page_sizepage_sizepage_sizepage_sizepage_sizepage_sizepage_sizepage_sizepage_sizepage_sizepage_sizebatch_sizepage_sizepage_sizepage_sizepage_sizepage_sizepage_sizebatch_sizepage_sizebatch_sizebatch_sizebatch_sizebatch_sizebatch_sizebatch_sizebatch_sizebatch_sizebatch_sizebatch_sizebatch_sizebatch_sizebatch_sizebatch_sizebatch_sizebatch_sizebatch_sizebatch_sizepage_sizepage_sizebatch_sizepage_sizebatch_sizebatch_sizepage_sizepage_sizeProposed fix
For each field listed above, change
type: texttotype: integerin the correspondingmanifest.yml. This ensures Fleet validates the value is numeric before accepting it.Note:
type: integeralone does not enforce minimum/maximum bounds — the package-spec does not currently supportminimum/maximumconstraints on integer variables (elastic/package-spec would need to be extended for that). This fix addresses the weaker problem: preventing non-numeric input entirely.Migration consideration
Changing
type: texttotype: integerfor an existing variable is a non-breaking change for users whose current value is already a valid integer (which it should be in all cases — these fields are passed as numeric API parameters). However, any policy that somehow stored a non-integer string would fail validation on next edit. This is the desired behavior.