/monty
Hack Monty
Round 3 · break the remote sandbox
Round 3 puts Pydantic Monty behind a production WebSocket service. Each connection gets a remote sandboxed worker. Your job is to find a real security boundary break — without attacking the infrastructure around it.
A Pydantic security research challenge running on the production Monty WebSocket transport.
The challenge
Pressure-test a remote worker
Monty is a minimal Python interpreter written in Rust, with startup measured in microseconds. It inverts the usual sandbox model: it starts from nothing and only exposes the functions you explicitly hand it. There is no sandbox beyond Monty itself — Monty is the security layer.
Round 3 exposes that boundary through a production WebSocket server. Each connection receives a dedicated remote Monty subprocess; the server adds capacity, resource, and timeout policy, but no second sandbox. Find a reproducible flaw that crosses the interpreter boundary, reaches host resources, or breaks isolation between sessions.
The old Round 2 REST API, snapshot-resume flow, shared trace project, and file-secret target do not apply to this deployment. Use the WebSocket client below, keep findings private, and include a minimal reproduction.
How to participate
One client, one remote session
Install the client
Install the lightweight WebSocket client. It exposes the same async session API as local Monty without installing a worker binary on your machine. See the package page for release details.
uv add pydantic-monty-client Open a remote session
Connect AsyncMontyWebsocket to the root WebSocket URL, check out a session, and feed it Python. Each
checkout dials a new remote worker. The client documentation covers timeouts and the full session API.
import asyncio
from pydantic_monty import AsyncMontyWebsocket
async def main() -> None:
async with AsyncMontyWebsocket("wss://3.hackmonty.com/") as pool:
async with pool.checkout() as session:
result = await session.feed_run("1 + 1")
print(result)
asyncio.run(main()) Probe, document, report
Keep security-sensitive findings private. Send security@pydantic.dev the smallest code sample that reproduces the issue, what crossed the boundary, the server version shown on the target page, and any relevant output. Our security policy explains how reports are handled.
Challenge telemetry
The Round 3 server records connection metadata and sandbox activity in Pydantic Logfire for operations and investigation. Do not put unrelated secrets in submitted code or WebSocket headers. Authorization, Cookie, and WebSocket subprotocol header values are redacted by the server, but the safest test credential is one you can throw away.
Research rules
What to test — and what not to touch
Focus on the Monty sandbox, its remote-worker protocol, and the isolation guarantees the Round 3 service makes. Final award terms are not published here; do not rely on Round 2's prize or sponsor details.
Most important
Do not attempt to submit changes to the Monty codebase, or any other codebase, that introduce new security vulnerabilities. If you do this — or run agents that try to — we'll block you and report you as a malicious actor. Test the deployed target as provided, avoid service disruption, and disclose security findings privately.
Primary target
- A reproducible Pydantic Monty flaw that crosses the interpreter boundary or reaches server resources unavailable to well-behaved sandboxed code.
High-value adjacent findings
- Host information or capabilities the worker should not expose, including filesystem, environment, process, or network access.
- A protocol or session-isolation flaw that exposes another participant's code, values, or session state.
- A security flaw in the Round 3 server or its Logfire instrumentation that exposes information that should remain private.
Useful reports
- A reliable Monty crash, panic, stack overflow, or resource-limit bypass with a minimal reproduction.
- Bugs or CPython-compatibility issues in Monty — please open a public issue when they are not security-sensitive.
- Vulnerabilities in dependencies — report them privately to the affected project as well as telling us when they affect this deployment.
Out of scope — do not attempt
- Introducing a vulnerability through a change to Monty or any dependency.
- Social engineering or “spear-phishing” Pydantic staff or other participants.
- Attacking Render, where this app is deployed — if you find a Render issue, report it to Render.
- Denial of service, traffic flooding, or disruption of this or any other Pydantic service.
Found a Render issue instead? Report it to Render. Found a non-security Monty bug? Open a public issue.
Found something?
Send security-sensitive findings to security@pydantic.dev. Want to talk Monty first? The #monty channel on the Pydantic Slack is the place — but do not post exploit details publicly. Nobody expects the Spanish Inquisition.