Filament Guardian Laravel Package

Technical Evaluation

Assessment basis: v1.14.0 is a security patch for a privilege-escalation path in a Laravel role/permission administration package (Role resource with a Users relation manager, Attach:Role / Detach:Role abilities, and a super-admin role that participates in a Gate::before bypass — i.e. Spatie laravel-permission conventions with a Filament-style admin UI). No prior assessment exists; this is the baseline.

Severity and recommendation: Treat as a high-priority security release. The pre-patch behavior allowed any principal holding Attach:Role to self-attach to super-admin and obtain a full Gate bypass (horizontal-to-vertical escalation to unrestricted authorization), and any principal holding Detach:Role to strip every super admin (denial of administration / lockout). Both are reachable from the shipped UI with no special tooling. Recommend a target patch window measured in days, not sprints.

Architecture fit

• The fix is a presentation-layer control: the Role resource's Users tab now suppresses Attach, Detach and bulk detach on the super-admin role for non-super-admins, overriding whatever RolePolicy returns. That is defense-in-depth at the UI boundary, not enforcement in the authorization core.
• Consequence: the underlying attach/detach operations remain callable wherever the UI is not the entry point — custom controllers, API/JSON endpoints, queued jobs, artisan/tinker, seeders, imports, or any second admin panel. The escalation surface is narrowed, not closed. If we expose role management anywhere outside this package's resource, we still own that risk.
• The hard-coded exception at the top of the policy chain is a deliberate and reasonable trade-off (a policy we could misconfigure is exactly the thing that failed), but it introduces a second, parallel authorization model that must be documented and tested alongside RolePolicy. Two sources of truth for the same decision is a durable maintenance cost.
• The super-admin role is now a protected system object with package-owned semantics. Any local customization (renaming, additional protected roles, multi-tenant variants) diverges from upstream behavior.

Integration feasibility

• Low technical effort: patch-level Composer bump, no migrations, no schema change, no config publish implied by the notes. The integration risk is almost entirely behavioral, not mechanical.
• Published assets are the real trap. If we have published and customized the package views or the Role resource/relation manager, the new guard may not be in the rendered output and we will believe we are patched when we are not. This must be verified by inspection, not by composer.lock.
• Test suites that assert a delegated admin can attach or detach super-admin will fail. That is the fix working; those assertions should be inverted, not deleted.

Technical risk

• Behavioral break in a minor version. The notes state plainly that non-super-admin users who managed super-admin membership can no longer do so. For any deployment that delegated that capability deliberately — a "Role Admin" or "IAM" persona — this is a functional regression, not a hardening. Semver-minor framing understates it.
• Guard-scope uncertainty. Whether the check matches on a configurable role name or a literal super-admin string determines whether renamed or localized installs are actually protected. If literal, teams with Super Admin, translated names, or per-tenant super-admin roles may receive no protection while believing they are patched.
• No stated mitigation for the removal path. Preventing non-super-admins from detaching super admins is good, but a super admin can still detach themselves or their peers. The lockout class of incident is reduced, not eliminated.
• No CVE or advisory identifier in the notes, which complicates vulnerability tracking, SBOM annotation, and security-ticket linkage.

Key questions

1. Is the super-admin role name configurable, and does the guard honor renamed/localized installs? What happens with multiple protected roles?
2. Are any package views or the Role resource published in our install, and do they override the fixed tab? How do we verify the guard is live at runtime?
3. Is enforcement confined to the UI, or are the underlying attach/detach paths hardened? Do we need our own policy/middleware for API or programmatic surfaces?
4. What is the sanctioned replacement workflow for delegated role administration — dedicated super admins, a console command, seeded config?
5. Is there a CVE/advisory ID and a supported-versions statement? Is v1.13.x getting a patch, or is 1.14.0 the only remediated version?
6. Does the change interact with Filament version, Livewire version, or permission-cache invalidation?

Integration Approach

Stack fit

• Standard Laravel service-provider package; no infrastructure, runtime, or data-store additions. Compatible with the existing Laravel/PHP and Filament/Livewire baseline and the existing Spatie permission tables. Nothing here changes our hosting, queue, or deployment topology.
• Fits the existing authorization model additively: Gate::before super-admin bypass stays, RolePolicy continues to govern every other role.

Migration path

1. Inventory first: enumerate every user and role currently holding Attach:Role or Detach:Role, and identify which humans rely on the Users tab to manage super-admin membership. This list is both the blast radius and the communications list.
2. Decide the replacement operating model before upgrading — who manages super-admin membership after the patch, and by what mechanism (a named set of super admins plus a documented break-glass console path is the pragmatic default).
3. Confirm no published/customized package views shadow the fix; if they do, port the guard into the local override or drop the override.
4. Bump the constraint to ^1.14, update the lockfile, clear and rebuild config and permission caches, and run the suite.
5. Invert the tests that encoded the old capability, and add regression tests for both directions: a delegated role-admin cannot see or invoke attach/detach on super-admin, and a super admin still can.

Compatibility

• No migrations, no config file changes, no API signature changes flagged. Primary compatibility risks are published views, cached permissions/config, and Filament/Livewire majors.
• Verify against our pinned Filament and Spatie permission versions before assuming a drop-in.

Sequencing

1. Staging upgrade and runtime verification of the guard (as super admin and as a delegated role-admin) — the acceptance test is behavioral, not composer show.
2. Confirm the guard is name/config-correct for our install.
3. Security review of every non-UI path that can attach or detach roles; add local policy or middleware where the package does not reach.
4. Update runbooks and admin documentation; notify affected role-admins of the capability loss before, not after, production.
5. Production rollout inside a normal change window, followed by a post-deploy check that at least one super admin exists and that delegated admins see the expected reduced UI.
6. Backfill the gap: ensure audit logging captures role attach/detach events so future attempts are visible.

Operational Impact

Maintenance

• Low ongoing cost, but a new permanent invariant to defend: super-admin is package-owned and only super admins may touch it. That belongs in code review checklists and in any local extension of the Role resource.
• Expect at least one follow-up hardening release (configurable protected roles, deeper enforcement, or an advisory ID). Track the repo rather than treating 1.14.0 as terminal.
• Pinning to ^1.14 is appropriate; do not pin below it.

Support

• The dominant support load is capability loss, not breakage: delegated admins will report that buttons have disappeared. Pre-empt with a short notice explaining the security rationale and the new request path.
• Support and on-call need a documented break-glass procedure for super-admin recovery, since the package deliberately removes an easy (and unsafe) self-service route.
• Expect a small spike in "I can't manage X" tickets in the first week; near-zero thereafter.

Scaling

• Negligible: a role-name comparison and a conditional render on an admin screen. No query, cache, or payload impact at any realistic user or role count.
• The one scaling-adjacent consideration is multi-tenant or multi-guard installs, where a single literal super-admin name may not map cleanly to per-tenant administration.

Failure modes

• False sense of security: published views or a custom Role resource silently bypass the guard; the app looks patched and is not. Highest-likelihood failure.
• Name mismatch: role renamed or localized, so the guard never triggers.
• Lockout: a super admin removes the last super admin; the patch blocks the external path but not self-inflicted removal.
• Adjacent surface: API or programmatic attach/detach unchanged, leaving the original escalation reachable through a second door.
• Test fallout: CI red from assertions encoding the old behavior, misread as a broken release.
• Silent delegation gap: a team depends on delegated super-admin management and discovers the loss during an incident rather than at upgrade.

Ramp-up

• One engineer-day for a mid-level Laravel developer: upgrade, verify, adjust tests, update docs.
• The non-obvious prerequisite is fluency in Gate::before super-admin bypass semantics and Laravel policy resolution order — that is what makes the "UI-only enforcement" caveat legible. Budget a short pairing session with whoever owns authorization rather than assuming the patch is self-explanatory.
• No new tooling, no training program, no vendor onboarding.