Edit: the DebridStream dev responded and denied their involvement.
It looks like DebridStream just tried to steal our new thumbnail preview implementation. It is just alleged at this point, I will be reaching out to the DebridStream dev for their comment. Here are the details.
Unauthorized bulk download of Wuplay trickplay assets — what we observed (2026-10-06)
On October 6, 2026, we observed a single automated client systematically downloading Wuplay's trickplay library — the seek-preview thumbnail images and their manifest files that Wuplay generates and hosts for its users. Here is what our logs show.
Timeline (UTC) – 21:17:52 — first request from the client. – ~21:35 — we noticed an unusual rise in read activity on the storage volume that serves these assets and began investigating. – 21:38:59 — the source address was blocked at our edge. No further requests from it have reached our servers.
Total duration: about 21 minutes.
What the client did – Made 9,373 requests to our asset paths in that window — roughly 7 requests per second, sustained. – Walked our title set in ascending IMDb-ID order (from tt0013442 to tt1431045), fetching each title's manifest.json and then every thumbnail image listed in it: 343 manifests and 9,030 images across 346 titles. – 9,340 of the requests returned 200 (success); 33 returned 404 for titles we don't have. The pattern — enumerate IDs, fetch manifest, fetch every file in it — is a mirroring job, not normal playback behaviour. Our own app fetches a single title's set when a user starts playing it. – Approximately 0.75 GB of image data was transferred.
How the client identified itself Every request carried the HTTP User-Agent header DebridStream-trickplay-mirror/1.0. A User-Agent is a free-text string set by whoever wrote the client software, so it is self-reported; we have no way to verify who operated it. We are publishing it because it is exactly what our logs recorded. DebridStream is the name of a separately published streaming app; we have not been in contact wking no claim about who was responsible.
Where it came from All requests originated from one IP address in a dynamic (residential) address block belonging to Bell Canada. There was no reverse-DNS record for it.
Impact Read load on the storage volume rose to roughly 82 reads/second (~4 MB/s) for the duration, then returned to near zero once the block took effect. No service disruption to Wuplay users was observed.
What we've done – Blocked the source address at the edge. – Trickplay asset URLs are moving to time-limited, signed links tied to the Wuplay app, so the files can no longer be fetched by enumerating IDs. That work was already built and is now being rolled out.
We're publishing this so our users understand what happened and so that the facts are on record.
Source: r/wuplay · by /u/wuplaydev