CVE-2026-48067: Filament Select Validation Bypass in AttachAction and AssociateAction

Technical summary

The vulnerability stems from a scope validation gap in Filament's AttachAction and AssociateAction components. Developers can call recordSelectOptionsQuery() to apply an Eloquent query scope that restricts which records appear in the Select field's dropdown—for example, filtering by team ownership or active status. However, the built-in validation rule that processes submitted form data does not apply this same scope. An authenticated user with network access can intercept or manipulate the Livewire component's state before submission, injecting an out-of-scope record ID. The server-side validation accepts the tampered value because the validation rule lacks the scope constraint. This is a classic input validation bypass: the UI enforces a restriction that the backend does not. The flaw affects filament/actions versions 4.0.0–4.11.3 and 5.0.0–5.6.3, and filament/tables versions 3.0.0–3.3.50.

Business impact

For applications using Filament's AttachAction or AssociateAction with query scoping, this vulnerability enables privilege escalation and data integrity violations. An authenticated user could attach or associate records they should not have access to—for instance, assigning a customer to a different sales team, linking a product to an unauthorized category, or modifying relational data in ways the application's business logic intended to prevent. The impact is limited to authenticated users (it requires login) and does not expose confidential data directly, but it allows unauthorized modification of application state. The severity depends on the sensitivity of the relationships being managed and the criticality of enforcing data isolation in your application.

Affected systems

Applications built with Laravel and Filament that use the filament/actions package versions 4.0.0–4.11.3 or 5.0.0–5.6.3, or filament/tables versions 3.0.0–3.3.50. The vulnerability is only exploitable if the application uses AttachAction or AssociateAction components with recordSelectOptionsQuery() to limit available options. Applications that do not use these components or do not rely on query scoping for access control are not affected. Verify your composer.lock or require section to confirm which versions are in use.

Exploitability

Exploitability is moderate. An attacker must be an authenticated user with access to trigger the AttachAction or AssociateAction—the vulnerability does not grant unauthenticated access. However, once authenticated, exploiting it requires only basic web inspection or network interception tools to identify the Livewire component's data structure and craft a tampered request. No complex social engineering or exotic techniques are needed. The barrier to exploitation is low for anyone with application access, making this a credible threat if your user base includes adversarial insiders or accounts with low privilege levels that are compromised.

Remediation

Update filament/actions to version 4.11.4 or later (5.6.4 for the v5 series), and filament/tables to version 3.3.51 or later. These patch versions apply the recordSelectOptionsQuery() scope to the validation rule, ensuring that out-of-scope values are rejected at the server side. After updating, clear application caches and restart any long-running processes. For applications that cannot patch immediately, implement additional server-side validation in your action handlers to re-verify that submitted record IDs match the expected scope—do not rely solely on Filament's built-in validation until patched.

Patch guidance

Use composer to update to the fixed versions: run `composer update filament/actions filament/tables` and verify that composer.lock reflects versions 4.11.4+ (or 5.6.4+) for actions and 3.3.51+ for tables. Test in a staging environment first to ensure no custom overrides of the validation rules are affected. If you have extended these components or overridden their validation, audit those customizations to ensure they also apply the query scope. Deploy during a maintenance window if possible, as the update may require a cache clear and application restart. Verify the update by checking `composer show filament/actions filament/tables` in production post-deployment.

Detection guidance

Look for Livewire component state modifications where AttachAction or AssociateAction requests include record IDs that fall outside the scope defined by recordSelectOptionsQuery(). This is challenging without application-level logging, but you can monitor for: (1) database audit logs showing unexpected attachments or associations created by specific users, (2) application logs or Livewire event logs showing validation errors or component state anomalies, (3) network inspection of form submissions to these actions, comparing submitted record IDs against the dropdown options that should have been displayed. Implement application-level logging in your action handlers to capture which records were attached and by whom, and alert on any attachment that does not match the expected scope.

Why prioritize this

Prioritize this patch because it closes a straightforward input validation bypass that any authenticated user could exploit. While the CVSS score of 6.5 (MEDIUM) reflects the requirement for authentication, the ease of exploitation and potential for privilege escalation or data integrity violations warrant prompt attention. Organizations with multi-tenant or fine-grained access control models—where data isolation is critical—should treat this as higher priority. Update within 2–4 weeks; it is not an emergency, but delaying beyond a month increases exposure risk.

Risk score, explained

The CVSS 3.1 score of 6.5 (MEDIUM, CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N) reflects: Network attack vector (AV:N) because Livewire operates over HTTP; low attack complexity (AC:L) because no special conditions are needed; low privilege requirement (PR:L) because the attacker must be authenticated; no user interaction (UI:N); unchanged scope (S:U); no confidentiality impact (C:N); high integrity impact (I:H) because the attacker can modify application state and associations; and no availability impact (A:N). The score correctly captures that this is a data tampering vulnerability requiring authentication, not a critical remote code execution or widespread outage risk.

Frequently asked questions