Logo
Overview
a neat little cve in filament

a neat little cve in filament

b4r b4r
May 25, 2026
2 min read
vulnerability cve web exploitation laravel

TL;DR

I got another CVE, this time in Filament: CVE-2026-48067.

This one was not loud at all. No RCE, no auth bypass that immediately screams at you, no weird gadget chain. Just a scope mismatch in AttachAction and AssociateAction.

And honestly, that is exactly why I liked it.

It is the kind of bug that looks normal from the panel, right up until you stop trusting the UI and start poking the actual request flow.

The bug

Filament lets developers use recordSelectOptionsQuery() to scope what records appear inside the Select field for AttachAction and AssociateAction.

So on the surface, everything looked fine.

The dropdown only showed records that were supposed to be selectable.

The problem was that the built-in validation rule did not enforce the exact same scope.

So if a user could trigger AttachAction or AssociateAction, they could tamper with the Livewire state and submit a record that never should have passed the original scope restriction.

That is really the whole bug:

  • the UI was scoped
  • the validation was not scoped the same way

And once those two drift apart, the UI stops being a security boundary.

Why it matters

I like bugs like this because they are easy to overlook.

At first glance, everything looks scoped correctly:

  • the select only shows allowed records
  • the action behaves normally in the panel
  • the scoping code gives a false sense of safety

But once you treat the request as attacker-controlled, the issue becomes pretty obvious.

If the validation layer is not applying the same restriction, then the filtered dropdown is just presentation. It is not real enforcement.

What an attacker gets

According to the advisory, a user with permission to trigger AttachAction or AssociateAction could tamper with the Livewire state and submit a record ID that should have been out of scope.

So this is not really a disclosure bug. It is more of an integrity problem.

The public CVSS reflects that pretty well:

  • Attack vector: Network
  • Attack complexity: Low
  • Privileges required: Low
  • User interaction: None
  • Confidentiality: None
  • Integrity: High
  • Availability: None

Vector:

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N

Affected packages and versions

The advisory lists three affected package lines:

  • filament/actions >= 4.0.0, < 4.11.3
  • filament/actions >= 5.0.0, < 5.6.3
  • filament/tables >= 3.0.0, < 3.3.50

Patched versions:

  • filament/actions >= 4.11.4
  • filament/actions >= 5.6.4
  • filament/tables >= 3.3.51

What made it interesting to me

This is one of those bugs where nothing is fully broken by itself.

The scoping existed. The validation existed too. They just disagreed.

That is always worth paying attention to, especially in admin panels and Livewire-heavy apps.

Whenever the frontend says “you can only choose from this small set” but the backend does not truly enforce the same boundary, there is usually something there.

Fixed version

This issue was patched in:

  • filament/actions 4.11.4 and 5.6.4
  • filament/tables 3.3.51

The CVE assigned to this advisory is:

  • CVE-2026-48067

Reference