FreeScout: the Polycast vulnerability we reported

When you open a ticket in FreeScout and a colleague is looking at the same conversation, their name appears at the top. It's a small, handy feature: it stops two people from replying to the same customer at the same moment. To make it work, every agent's browser regularly sends the server a request that says, in essence, "I'm looking at conversation number X". The server didn't check that the conversation existed, or that the user had the right to see it. It simply accepted the value and stored it.

That is the flaw described in advisory GHSA-vcgj-6qfr-7qr6, published on 17 October 2026 and fixed in FreeScout 1.8.248. We reported it: the discovery is by Liam Giannini (Liam-G on GitHub) of the Webcracy security research group. Our thanks to the FreeScout maintainers, who shipped the fix in the next release.

What was happening behind the "is viewing" indicator

FreeScout is one of the most popular and widely used open source helpdesks: developed since 2018, it has more than 4,600 stars on GitHub and is used by a great many companies as a self-hosted alternative to services like Help Scout or Zendesk. It's written in PHP, on Laravel. With a project this widespread, a flaw is never a problem for just a few. Real-time updates go through a component called Polycast, which receives the browsers' periodic requests on the POST /polycast/receive endpoint.

Every request ended up in a method, processConvView(), which read the data[conversation_id] field and used it as it was. No check that it was a number, no length limit, no permission check. The conversation was looked up in the database only in some cases, and even when the lookup failed the value wasn't discarded. For every new identifier the server created a dedicated cache entry and added that same identifier to a single shared array, conv_view, which holds the active views for the whole installation.

The detail that turns a missing check into an availability problem is that array. It is read in full, modified and written back in full on every request, with a lifetime of twenty minutes. If someone stuffs thousands of made-up identifiers into it, every subsequent write gets heavier, and that includes the legitimate requests of the other agents, who use the same object. Making things worse is a scheduled command, freescout:check-conv-viewers, which runs every minute: it walks through all the entries, and for each expired entry it removes a key from the cache and fires a real-time event. More fake entries, more work for the database and the broadcast system. On top of that, the endpoint had no specific rate limit.

The upshot is that a single agent account, even without admin privileges, could slow down the helpdesk for everyone: slower requests, busy workers, pressure on Redis or whichever cache backend is configured, delayed scheduled tasks. There's no access to other people's data and no tampering with content. GitHub rates the issue as moderate severity, CVSS 3.1 6.5 (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H), under CWE-400, uncontrolled resource consumption.

Why "you have to be logged in" isn't enough

It would be easy to dismiss this by saying the attacker needs an account. In a helpdesk, though, accounts are numerous and change often: seasonal agents, external contractors, suppliers given access to a shared mailbox, credentials reused from some other breached service. Polycast's access control checked that the user was logged in and allowed to listen on the requested channel. It said nothing about the content of the request. The right boundary isn't "the user is authenticated", it's "the user can see this specific conversation".

There's also a precedent on the same endpoint. In July, GHSA-gh3r-jh6q-wrvj (CVE-2026-62856) was published: a high-severity flaw, fixed in 1.8.226, that abused the wildcards of a LIKE query in channel selection to read other users' notifications. Our case is different: the vulnerable field is data[conversation_id] and the impact is on resources, not confidentiality. But the fact that the same entry point produced two advisories within a few months tells you something. Polling endpoints, the ones the browser calls every few seconds without anyone giving them a thought, tend to get less attention than the screens the user actually sees.

How we verified it

The problem surfaced during a review of the FreeScout 1.8.247 source code (commit 9d11ff0), following the data from the endpoint all the way to the cleanup command. In our report we described how to reproduce it in a lab: log in as a regular agent, send a few requests with non-existent identifiers, watch the cache and the growth of the conv_view object, then let the scheduled command run. A few dozen entries are enough to see the effect: you don't need to take a helpdesk down to show that it can go down.

The fix in 1.8.248

The release notes for version 1.8.248 mention sanitising the identifier in processConvView(). In the fixed code the value is only accepted if it's a positive integer of at most ten digits, the user must be authenticated, and before anything is written to the cache the code checks that the user can actually see the conversation. A request with a fake identifier, or one pointing to a conversation the user can't access, no longer leaves a trace.

In our report we had also proposed further measures: a dedicated rate limit for the Polycast endpoint, a cap on the number of active views per user and per conversation, and above all replacing the global array with a per-conversation structure, so that the whole thing isn't rewritten on every request. Validation combined with the permission check closes the attack path described in the advisory. The other measures are defence in depth, useful against future abuse, and remain a design decision for the maintainers.

The same release fixes three other advisories: GHSA-w3jr-fphw-whgv, on previous conversations being visible to users who should only see the ones assigned to them; GHSA-c8rg-2r2h-5vgc, on creating multiple sessions by redeeming the same invitation in parallel; and GHSA-cxf4-7mrp-vvpr, a control-character issue in the league/flysystem dependency. That alone is reason enough not to put off the update.

What to do if you use FreeScout

If your installation is older than 1.8.248, update it. The advisory doesn't list any workarounds, and disabling Polycast would mean losing the real-time updates the interface relies on. Before updating, it's worth backing up the database and the modules folder: many problems after a FreeScout upgrade come from third-party modules that are out of step, more than from the core.

If you've noticed unexplained slowdowns in your helpdesk, it's also worth checking the size of the conv_view entry in the cache. A value with far more entries than there are conversations actually open by agents is a sign worth looking into. In any case, after the update the existing entries expire on their own within twenty minutes.

And if FreeScout runs on a server nobody has looked at in months, this advisory is probably not your only problem. A helpdesk holds customer emails, attachments, sometimes sensitive personal data: it deserves the same maintenance as the company website, if not more.

Why we do research on open source software

Many of our clients use self-hosted open source tools, and we often recommend them: no per-user fees, data on your own server, code you can read. But "you can read it" doesn't mean anyone is reading it. Spending part of our time reviewing the projects we install, and reporting what we find responsibly to the maintainers, is the most concrete way we know to give something back to those projects. And to really know what we're putting into production.

If you'd like a similar review of your helpdesk, your business software or a custom-built application, we're happy to talk. Our penetration testing work starts right here: reading the code and the configuration, understanding where a piece of data isn't being checked, and telling you precisely what we verified and what we didn't.

Let's talk about the security of your applications↗