[GHSA-7m6h-rg42-m449] Filament: Multi-factor authentication (app) management actions do not require password reauthentication

[ahbaqdadi]

Updates

• Affected products

Comments
The current affected ranges exclude 4.13.2 and 5.8.2, even though the patched versions are 4.13.3 and 5.8.3. This leaves the immediately preceding releases outside the vulnerable range. Please include both by changing the exclusive upper bounds to the corresponding first patched releases.

Public evidence:

• The 4.13.3 release notes list the password-check fix (#20522) in the comparison from 4.13.2: https://github.com/filamentphp/filament/releases/tag/v4.13.3
• The 5.8.3 release notes likewise list the fix in the comparison from 5.8.2: https://github.com/filamentphp/filament/releases/tag/v5.8.3
• Fix PR: fix: add password checks to MFA actions filamentphp/filament#20522
• In 4.13.2, the app-MFA setup action has no password field or current-password validation: https://github.com/filamentphp/filament/blob/v4.13.2/packages/panels/src/Auth/MultiFactor/App/Actions/SetUpAppAuthenticationAction.php
• The same is true in 5.8.2: https://github.com/filamentphp/filament/blob/v5.8.2/packages/panels/src/Auth/MultiFactor/App/Actions/SetUpAppAuthenticationAction.php
• The corresponding 4.13.3 and 5.8.3 files add a required password field and current-password validation. I also checked the disable and recovery-code regeneration actions across all four tags.

This is a metadata correction to an already-public vulnerability. The existing repository advisory also has the inconsistent exclusive bounds; the tagged source and released fix support the proposed correction. AI-assisted with Codex; validation was tagged-source inspection and release/patch cross-checking, not a runtime exploit reproduction.

[github]

Hi there @danharrin! A community member has suggested an improvement to your security advisory. If approved, this change will affect the global advisory listed at github.com/advisories. It will not affect the version listed in your project repository.

This change will be reviewed by our Security Curation Team. If you have thoughts or feedback, please share them in a comment here! If this PR has already been closed, you can start a new community contribution for this advisory

[danharrin]

All of Filament's advisories use these constraint formats, are you suggesting that they all need fixing?

The diff doesn't look correct to be honest, I don't know why you're removing that database_specific block rather than changing the version number if you think it is incorrect?

[ahbaqdadi]

Hey @danharrin , Thanks for checking this. I haven't audited the other Filament advisories, so I am only proposing a correction to these two ranges in this advisory.

I submitted this through GitHub's Suggest improvements form, changing the affected upper bounds from < 4.13.2 / < 5.8.2 to < 4.13.3 / < 5.8.3, leaving the patched versions unchanged. GitHub generated the JSON diff automatically; I didn't manually remove the blocks.

The existing OSV events already say introduced: 4.0.0, fixed: 4.13.3 and introduced: 5.0.0, fixed: 5.8.3. The form therefore removed the separate, mismatching upper bounds. GitHub's explanation of this field describes preserving mismatched internal ranges and representing a deterministic introduced/fixed range natively.

The reason for the endpoint correction is that the tagged 4.13.2 and 5.8.2 setup actions lack password validation, while the required checks appear in 4.13.3 and 5.8.3, as linked in the PR. An exclusive < 4.13.2 bound doesn't include 4.13.2.

I should also distinguish metadata consistency from scanner behavior: GitHub says OSV consumers should prefer the fixed event over a mismatched custom bound, so I'm not claiming every scanner misses these releases.

If the curation team prefers retaining the blocks, the alternative is to set their values to < 4.13.3 and < 5.8.3. I don't have push permission to this GitHub-managed branch, so I'll leave that serialization choice to the curators.

[advisory-database]

Hi @ahbaqdadi! Thank you so much for contributing to the GitHub Advisory Database. This database is free, open, and accessible to all, and it's people like you who make it great. Thanks for choosing to help others. We hope you send in more contributions in the future!

[taladrane]

👋 @danharrin given that, I would recommend re-reviewing the advisories to ensure that they affected version range includes all those affected. in this particular example, our global advisory had these affected version ranges from the repo GHSA:
>= 4.0.0, < 4.13.2 and >= 5.0.0, < 5.8.2, both excluding 4.13.2 and 5.8.2 as an affected version because they are lacking the inclusive = in the second half of each expression

it could be written as >= 4.0.0, <= 4.13.2 or >= 4.0.0, < 4.13.3, and >= 5.0.0, <= 5.8.2 or >= 5.0.0, < 5.8.3 to capture the last affected version before the patches were released

for more information: https://docs.github.com/en/code-security/tutorials/fix-reported-vulnerabilities/write-security-advisories#affected-versions

[danharrin]

@taladrane thanks, I updated all advisories, will this database also automatically update to follow? Or do I need to make a PR manually