CVE-2025-48481 is a critical business logic flaw (CVSS 9.8) in FreeScout, the self-hosted help desk. Before version 1.8.180, someone holding an unactivated invitation containing an invite hash could activate their own account even if it had been blocked or deleted. Upgrade to 1.8.180 or later.
What's affected
Per the CVE record and the GitHub advisory, FreeScout versions before 1.8.180 are affected, and 1.8.180 contains the fix. The advisory tested versions 1.8.173 and 1.8.174.
The condition is an unactivated invitation email that contains an invite hash. Someone who still has that email can use the link to activate the account, even after an administrator has blocked or deleted the user. The advisory describes the cause as a workflow that lets a user skip a required step and still reach the feature.
The record files this under CWE-841 (Improper Enforcement of Behavioral Workflow), improper enforcement of behavioral workflow. The base vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H: network reachable, low complexity, no interaction, with high impact on confidentiality, integrity and availability. The advisory scores it lower than the NVD record does, because it requires holding a specific invitation email, so the real risk depends on how many stale invitations exist.
This is also a lesson about offboarding. A blocked or deleted account should stay blocked, and an old invitation should not bring it back.
How to check if you're exposed
Find the FreeScout version in the admin area, or from a Git install:
git describe --tags
Anything before 1.8.180 is affected.
Then look for stale invitations. In the user list, find accounts that were invited and never activated, and accounts that were blocked or removed after being invited. Each of those is a case where an old invitation email might still exist in someone's inbox.
Review the access logs for requests to the invitation setup path, which the advisory shows as /user-setup/ followed by the hash, from users or addresses you did not expect. A successful setup for a user you thought was blocked is the signal that matters.
What to do now
- Upgrade FreeScout to 1.8.180 or later.
- List users with pending, never activated invitations, and delete or re-issue the ones you no longer need.
- Check that every user who should be blocked or deleted stays that way after the upgrade.
- Review the user list and recent logins for accounts that appeared active when they should not have been.
- Review access logs for invitation setup requests that you cannot explain.
- Apply the fix for CVE-2025-48471 in the same upgrade, since it is in a release before 1.8.180.
Why it matters
Business logic flaws are mistakes in the rules of a workflow, not in the code that implements a single function. Here the intended order is: an administrator invites a user, the user activates the account, and the administrator can later block the user. The flaw lets an old step in that sequence override a later one. Each function works as written, but the sequence is wrong.
The class is improper enforcement of behavioral workflow. Fixing it takes a server-side state check at every step, so that the system asks the current state of the account, not only whether a valid link was presented.
It is not listed in the CISA Known Exploited Vulnerabilities catalog, and the record does not report exploitation in the wild. The record scores it 9.8, and the advisory scores it lower, so use judgment: if you had no unactivated invitations to blocked accounts, your practical risk was small, but the upgrade is still the right move.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Which accounts are at risk?
Accounts that were invited but never activated, and then blocked or deleted, while the invitation email still exists. Check these first.
Do I need to upgrade for both FreeScout issues?
Upgrading to 1.8.180 or later covers both, since 1.8.179 fixes the upload flaw and 1.8.180 fixes this one.
Sources
Last reviewed: 18 October 2026.
