VYPR
← All advisories
Medium severity4.3NVD Advisory· Published May 29, 2026· Updated May 29, 2026

CVE-2026-48811

CVE-2026-48811

Description

FreeScout is a free help desk and shared inbox built with PHP's Laravel framework. Prior to 1.8.221, FreeScout allows a non-admin user to permanently delete an internal note (private thread) from any conversation, even after that user's access to the mailbox containing the conversation has been revoked. The ThreadPolicy::delete authorization policy does not verify mailbox membership, so a former team member retains destructive write access to notes they created. This vulnerability is fixed in 1.8.221.

AI Insight

LLM-synthesized narrative grounded in this CVE's description and references.

FreeScout <1.8.221 allows non-admin users to permanently delete internal notes they authored even after mailbox access is revoked due to missing mailbox membership check in ThreadPolicy::delete.

Vulnerability

FreeScout versions prior to 1.8.221 contain an authorization flaw in the ThreadPolicy::delete method (app/Policies/ThreadPolicy.php). This policy authorizes deletion of threads solely based on authorship without verifying the user's current access to the mailbox containing the conversation. As a result, a non-admin user who has been removed from a mailbox can still permanently delete any internal note (private thread) they previously created. Only threads with type 3 (NOTE) are affected, as the controller checks $thread->isNote() before deletion. The vulnerability exists in all versions through commit 49a9a4d (latest at the time of discovery). [1]

Exploitation

An attacker requires a valid session cookie and CSRF token for an account that was formerly a member of the mailbox. They must know the ID of a note they created while they had access. The attack is performed by sending a POST request to /conversation/ajax with parameters action=delete_thread and thread_id=. No additional authentication bypass is needed; the existing session is sufficient. [1]

Impact

A former team member can permanently delete internal notes from any conversation in mailboxes they no longer have access to. This allows unauthorized destruction of sensitive information, potentially disrupting operations or destroying evidence. The deletion is irreversible through the application interface. The vulnerability does not grant access to view or modify other data, but the ability to delete notes can have significant operational impact. [1]

Mitigation

The issue is fixed in FreeScout version 1.8.221. Users should upgrade to this or a later version. No workarounds are documented in the available reference. [1]

References
  1. Thread Deletion Bypasses Mailbox Access Revocation

AI Insight generated on May 29, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.

Affected products

2
  • Freescout/Freescoutinferred2 versions
    <1.8.221+ 1 more
    • (no CPE)range: <1.8.221
    • (no CPE)range: <1.8.221

Patches

2
5dab098380dc

Improve permissions check when deleting notes - GHSA-9vx8-gx3p-9mh6

https://github.com/freescout-help-desk/freescoutFreeScoutMay 17, 2026Fixed in 1.8.221via llm-release-walk
commit
1 file changed · +6 −1
  • app/Policies/ThreadPolicy.php+6 −1 modified
    @@ -39,8 +39,13 @@ public function edit(User $user, Thread $thread)
 
     public function delete(User $user, Thread $thread)
     {
+        // Admin also can delete only own notes.
         if ($thread->created_by_user_id == $user->id) {
-            return true;
+            if ($thread->conversation && !$thread->conversation->userHasAccessToMailbox($user->id)) {
+                return false;
+            } else {
+                return true;
+            }
         } else {
             return false;
         }
ae68e194b14f

Improve permissions check when editing messages - GHSA-3w38-h42v-3h6w

https://github.com/freescout-help-desk/freescoutFreeScoutMay 18, 2026Fixed in 1.8.221via llm-release-walk
commit
1 file changed · +9 −2
  • app/Policies/ThreadPolicy.php+9 −2 modified
    @@ -23,8 +23,13 @@ public function edit(User $user, Thread $thread)
         if ((
                 $thread->created_by_user_id 
                 && in_array($thread->type, [Thread::TYPE_MESSAGE, Thread::TYPE_NOTE])
-                && ($user->isAdmin() || ($user->hasPermission(User::PERM_EDIT_CONVERSATIONS) && $thread->created_by_user_id == $user->id))
-            ) || (
+                && ($user->isAdmin() || (
+                        $user->hasPermission(User::PERM_EDIT_CONVERSATIONS)
+                        && $thread->created_by_user_id == $user->id
+                        && $thread->conversation
+                        && $thread->conversation->userHasAccessToMailbox($user->id)
+                    )
+                )) || (
                 $thread->created_by_customer_id
                 && in_array($thread->type, [Thread::TYPE_CUSTOMER])
                 && $thread->conversation
@@ -51,6 +56,8 @@ public function delete(User $user, Thread $thread)
         }
     }
 
+    // If user can see only assigned conversations,
+    // check if he/she has access to the conversation.
     public function checkIsOnlyAssigned($conversation, $user)
     {
         // Maybe user can see only assigned conversations.

Vulnerability mechanics

Root cause

"Missing mailbox membership check in ThreadPolicy::delete allows a user to delete notes they authored even after their access to the mailbox has been revoked."

Attack vector

A non-admin user who previously had mailbox access sends a POST request to `/conversation/ajax` with `action=delete_thread&thread_id=<id>` and a valid session cookie and CSRF token [ref_id=1]. The `ThreadPolicy::delete` method authorizes deletion solely based on authorship (`$thread->created_by_user_id == $user->id`) without verifying that the user still has access to the mailbox containing the conversation [CWE-862]. Only threads of type `NOTE` can be deleted via this path, so customer messages and agent replies are not affected [ref_id=1].

Affected code

The vulnerability resides in `app/Policies/ThreadPolicy.php` in the `delete` method. The controller path is `app/Http/Controllers/ConversationsController.php` via the `ajax()` action handling `delete_thread`.

What the fix does

The patch adds a mailbox membership check inside the `delete` method of `ThreadPolicy` [patch_id=3107103]. After confirming the user is the thread author, it now calls `$thread->conversation->userHasAccessToMailbox($user->id)` and returns `false` if the user no longer has access. This mirrors the check already present in `ConversationPolicy::delete` and prevents a former team member from permanently deleting notes after their mailbox access has been revoked [ref_id=1].

Preconditions

  • authAttacker must have a valid session cookie and CSRF token for a non-admin user account
  • inputAttacker must know the thread ID of a note they created while they had mailbox access
  • inputThe target note must be of type NOTE (type=3)
  • configThe attacker's mailbox access must have been revoked prior to the deletion attempt

Generated on May 29, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.

References

1

News mentions

0

No linked articles in our index yet.