I recently got a talk accepted by a security conference, with an HTML <marquee> in my title. That led me to discover that a crafted talk title could take over the session of any logged-in organiser on the event platform, letting an attacker act in their admin portal and silently add themselves as an owner of the organisation. All it takes is a logged-in organiser opening a crafted, but not obviously suspicious, link.

The conference agenda was managed through aanmelder.nl, a Dutch event registration platform. They rendered my HTML not only in the acceptance email, but also on www.aanmelder.nl itself, through their view online link. That’s the same origin as aanmelder.nl’s admin portal for every tenant and user, which is exactly what the attack needed.

Extra fun: the conference was the ONE Conference, the Dutch government’s annual cybersecurity event, or, as they brand it: Europe’s prime cybersecurity event. My talk? Placing HTML in unusual places to get a foothold for exploits.

After I reported it to aanmelder.nl, they confirmed and fixed it within one day.

My entry point: a talk title

A ONE Conference speaker badge in a lanyard holder, with the name line reading 'Sasha <marquee><img src='//s42.re/oc.png'>' and a Speaker ribbon along the bottom.

My proposed title was “Strange <marquee> vectors, serious infrastructure impact”, so it contained a real <marquee> tag. I use <marquee> as a canary: it’s rarely used but still renders in modern browsers, and it’s funny. If I see parts of the page moving around, my inputs were not properly escaped. I registered with a tag in my name as well.

I don’t usually risk HTML in my talk titles, in case I break the Call for Papers form and miss my chance. But I made an exception for ONE Conference, which paid off.

First, the speaker upload portal, where I had to upload my slides. This was a separate vendor, SlideCrew, that the conference uses for slide collection:

I could not get enough access to this portal to confirm anything beyond a cosmetic joke.

Second, the acceptance email, which had a bigger impact. Mail clients are used to hostile HTML, so the scrolling title in an email is funny but not a security risk - on its own:

The interesting part is the link at the top: “Is this mail not displayed properly? Click here to view it online.” That link renders the mailing as a web page on www.aanmelder.nl, with my HTML.

So through a legitimate path, submitting a talk and being accepted, I could plant HTML on www.aanmelder.nl. I expect this would work for talk rejection notifications as well.

From marquee to javascript

A marquee proves my HTML is not being escaped, but that does not always mean javascript will run. To check, I made a trial account of my own and sent a test mailing to myself, with an alert(1) payload in my attendee’s first and last name fields.

Here is the view online link of that test mailing, on my own tenant subdomain:

That confirms javascript execution, not just HTML. But it ran on my own tenant subdomain, 179534.aanmelder.nl, not on www. A subdomain is a separate origin, so a payload there is limited by the same-origin policy. Could I get not only a marquee, but my own javascript, running on www itself?

Admin access from www.aanmelder.nl

The platform’s admin portal, where organisers manage their events, users and registrations, runs on www.aanmelder.nl, so to be most effective, I’d need to get my payload on that domain. Otherwise, the same-origin policy will interfere. But this seemed possible, as the view online link from my ONE Conference mail did render on www.

According to aanmelder.nl, new customers are on a different subdomain by default, but are moved to www once vetted and approved. I don’t know what the vetting process looks like. But the handful of previous emails I had from aanmelder.nl events all rendered on www.

Aanmelder.nl confirmed that the injection was not specific to my trial tenant: it would have executed on www as well. The email content rendering included user content (from the organiser or an attendee/speaker) without proper escaping.

HttpOnly and other mitigations didn’t help

The session cookies, user_key and session, are HttpOnly. As in my RIPE NCC chain, that only stops my payload from reading them: the browser still attaches them to the requests it makes. The Content-Security-Policy didn’t stop me either, as it was very open: its script-src even included unsafe-inline.

The admin portal does its real work over a Socket.IO websocket. It’s a rather convoluted interface, with blobs of HTML sent back and forth, tagged with random IDs. Actions aren’t regular HTTP POSTs, they’re “signals” sent down the socket. Setting the role to Owner while adding a user, for example, means sending a message like:

42["signal",{"signal":"change","id":"x2..9a",
  "page":"x5..15",
  "cookie_token":"QetxAjd...Gc.","rpc_count":4,
  "value":"organisation_owner"}]

Nonetheless, the XSS payload was able to add a new owner to the organisation. There was no re-authentication required, and the current owners would not be notified.

A full attack

End to end, it looks like this:

  1. Get content rendered on www, either as an approved customer or, more sneaky, through a mailing from a legitimate approved event, like my own acceptance email.
  2. An organiser opens the link while logged in, and the payload runs on www.
  3. The payload finds the organiser’s organisation from a login page redirect, and fetches the user admin page, which contains the tokens, IDs and websocket path it needs.
  4. It opens the websocket and uses the Add user dialog, creating an owner account for the attacker.

The attacker can almost certainly take other actions, but an owner account is the most interesting, because it outlives the session. It’s too messy to share, but I have built and verified the full payload.

Aanmelder.nl is a significant platform: they say they’ve handled over 100,000 events. A targeted organiser doesn’t need to be connected to the event that sent the mailing, so the same malicious link would have worked on any organiser who opened it while logged in.

Fixes

Aanmelder.nl deployed two of my recommended fixes the same day:

  • Escaping the user content in the mail rendering.
  • A stricter Content-Security-Policy. CSP can be set per response, so the email rendering page, which has a higher risk, now gets one that allows almost nothing.

In addition, they are planning to notify the existing owners when a new owner is added.

I also recommended, for defence in depth, separating tenants from each other and especially from the admin portal, for example with a different domain for user content like email renderings, ideally with separate hostnames per tenant. With the admin portal on a different origin, none of this escalation would have worked.

Disclosure

I reported this by email to security@aanmelder.nl on September 24, 2026. Their security policy was struck through, but they did respond quickly. As I felt I had to include this in my ONE Conference presentation, I gave them a deadline of 10 days. They fixed it within one day.

As their bug bounty program is paused, there was no bounty. I thought that cross-tenant account takeover might be worth making an exception for, but given they top out at just € 100 for a “high” severity finding, it wasn’t really worth it anyway.

I shared a draft of this post with them before publication.

Prior work

In April 2026, Elad Meged discovered CVE-2026-41241, a high-severity stored XSS in pretalx, an open source CFP tool. That one was in the “organiser search typeahead”. I had explored pretalx before for this kind of vulnerability, but didn’t spot this one. Elad found it, like I found mine, while preparing a talk submission.

I delivered a talk about putting HTML where it isn’t expected and the consequences it can have, and the submission itself ended up as one of my demos :)

I'm Sasha Romijn, an independent developer and internet infrastructure specialist in Amsterdam. I find security issues in internet infrastructure, usually in configurations, trust relationships, and cross-system behaviour that got overlooked. Some of my finds include taking over an event platform with a talk title, rooting OpenWrt via SSID, taking down a European network with a TLS certificate, rooting Home Assistant through MeshCore, and, some years back, compromising Apple keychain access groups.

Find me on Mastodon, Bluesky, or work with me.