← Writeups

One URL away from the room: an access-control bypass on a Dell video service

A Dell video-conferencing app asked you to pass a join step at one path, then quietly served the exact same room at a sibling path with no gate at all. Changing a single character in the address bar was the whole exploit.

Some bugs need a payload, a proxy, and an afternoon. This one needed the address bar and a bit of curiosity. It was an internet-exposed Dell deployment of a Pexip video-conferencing service, the kind of thing meant to sit behind a wall, and it had a front door with a check on it and a side door with none. Reported to Dell's bug bounty program and rewarded as a P3. The specific host is kept out of this writeup on purpose; the point is the shape of the bug, not the address.

A Bugcrowd submission titled Authentication Bypass on a *.dell.com target, VRT Broken Access Control, priority P3, rewarded 750 dollars. The host and other details are redacted. — The submission on Dell's program: **Broken Access Control**, priority P3, rewarded **$750**. The host and identifiers are redacted.

The front door

The service is a Pexip video room. Visiting the app's main path brought up its join flow: a welcome panel, then a prompt to enter a display name before you could go any further. It reads like the gate you would expect, the moment where the app decides whether to let you in and who you are.

The Pexip video service join page on a Dell subdomain, with a welcome panel and a prompt to enter a display name before continuing. The host in the address bar is blurred. — The join step at the app's main path. Enter a name, then continue. The host in the address bar is blurred.

Pass that step and you land in the meeting room itself, with the controls to turn on a camera, share content, and bring other people into the stream.

The Pexip meeting dashboard with camera, content and voice controls, reached after the join step. — The room behind the join step: camera, content sharing, and voice controls.

The side door

The app was not served from one path. There were sibling deployments living next to each other, distinguished by a number in the path, one app at /webapp3/, another at /webapp2/. Out of habit I tried the neighbour, going straight to its /home page instead of its front door.

It let me in. The sibling path dropped me directly into the same kind of room, with the same controls, without the join step ever standing in the way.

The sibling app path opened directly into the meeting dashboard, showing the room controls, with the host in the address bar blurred. — The sibling path, opened directly at its home page, served the room with no gate in front of it. Host blurred.

The gate was on the door, not on the room

The check lived on one entry path, not on the resource it was supposed to protect. Because a second path reached the same room without going through that check, the protection was optional: an attacker just knocks on the door that has no lock. Access control that is enforced at one route and assumed everywhere else is not access control, it is a suggestion.

Why it matters

Unauthorized entry. Anyone who reached the sibling path was inside the video service without passing whatever the join step was meant to enforce.
It is a room, not a page. Once inside, you have the meeting controls, camera, screen and content sharing, and the ability to pull other people into the stream. That is a foothold for abuse and for social engineering, not just a peek at a static page.
It was exposed to the internet. A tool like this belongs behind a VPN or an authenticating proxy. Finding it reachable at all is half the finding; finding it reachable without the gate is the rest.

The fix

Protect the resource, not the route. Enforce the access check on the room itself, so every path that can reach it has to pass the same gate.
Keep sibling deployments consistent. When the same app runs at several paths, they drift. Configuration that gates one and not another is exactly how a side door appears.
Do not expose internal video tooling to the public internet. Put it behind a VPN or SSO proxy, so a missing in-app check is not the only thing standing between the world and the room.

Key takeaways

When one entry path is gated, always try the others. Access control that is not enforced on the resource can usually be reached around.
Sibling deployments at /webapp2/, /webapp3/ and the like are a classic source of drift: same app, different, weaker configuration.
The cheapest exploit in the book is still a live one. Change a character in the URL before you reach for anything heavier.
An exposed internal tool is a finding on its own, before you even test what it does.