Security release: two vulnerabilities fixed in WorkAdventure 1.33.2

In short

• If you self-host WorkAdventure, upgrade your installation to 1.33.2 now — every container at once, as usual.
• If you use our hosted service at play.workadventu.re, the fixes were deployed on August 16th 2026, and there is nothing for you to install.
• We have no indication that either issue was exploited.
• Both were reported to us privately by two security researchers, and we thank them.

Two security researchers reported two separate vulnerabilities to us on August 13th. Both are fixed in 1.33.2, published today, and both have a public advisory with the full technical details: GHSA-rwrg-qwj3-p8xw: Cross-site scripting: a nearby player can execute arbitrary JavaScript through an emote (CVE number pending) and GHSA-c498-phfm-7662: Unrestricted file upload in the WorkAdventure uploader allows stored cross-site scripting (CVE number pending).

We are writing this article because our usual way of reaching self-hosted installations —(the SECURITY_EMAIL environment variable) only reaches those who filled it in. Most did not. If you run WorkAdventure on your own servers, this is the notice.

What was found

A player could run code in the browser of the players near them. WorkAdventure sends the emote you play to the people around you, and that value was inserted into their page without being neutralised first. Someone sending a crafted emote could therefore run their own JavaScript in the browser of every player standing nearby, in the context of your WorkAdventure instance: enough to act in the application on their behalf, or to read the session their browser holds… the chat session included. On an instance that allows anonymous access, no account was needed. This is the serious one, and it has been there since emotes were introduced in 2021.

A file uploaded through the uploader service was served back as a web page. The service kept the file type from the name given by the sender, so an HTML file came back as HTML and the browser ran it. How much that is worth depends on how you deploy: if the uploader answers on your application’s own domain, the code runs on the same origin as WorkAdventure and your users’ sessions are in reach; if it answers on its own subdomain, the impact is limited, but anyone can still hand out a link that starts with your domain. On installations without an admin API, that upload endpoint needed no account at all.

Who is concerned

What to do if you self-host

Upgrade to 1.33.2, upgrading every container of your installation at once. The containers of a release are made to run together and check each other’s version, so a partial upgrade is not something we support.

If you want to be extra safe: once upgraded, you may want to invalidate the sessions issued before the fix, so that a token captured earlier stops working. On WorkAdventure, rotating SECRET_KEY does it. If you run the chat, that is a separate step: the Matrix sessions have to be closed on your homeserver. Both log your users out, and closing chat sessions can cost a user access to their encrypted history if they never set up a recovery key… so weigh it against your own exposure (reminder: we have no proof those issues were ever exploited).

What to do if you use our hosted service

Nothing. Both fixes were deployed on August 16th, 2026.

If you want to be thorough, log out and log back in: a session issued before the fix remains valid for up to 30 days.

Were these exploited?

We have no indication that either was. We also want to be precise about what we can and cannot verify: emotes travel between browsers and are not stored on our servers, so there is no log we could go back through to prove it either way. We would rather write that plainly than imply a certainty we do not have.

How we will reach you next time

If you self-host, set SECURITY_EMAIL in your .env (or values.yaml file) and leave ENABLE_TELEMETRY enabled. Your installation then reports its version to us once a day, and when a vulnerability affects that version we email you directly, instead of hoping you read an article. We only use it for that.

And if you find a security issue in WorkAdventure, write to [email protected]. We answer, we work with you on a disclosure date, and we credit you.

Thanks

Romain Igounet (Oreo) (@NumberOreo_) and 0xNaSu (@0xNaSu) found both issues and reported them privately, with clear reports and working proofs of concept, and waited for the fixes to be released before saying anything publicly. That is what makes it possible to fix things before they are abused, and we are grateful for it.