A scraper we built for Solebox started returning "IN STOCK" alerts for sneakers that weren't dropping for another three days. We assumed the monitor was broken. It wasn't. We'd accidentally stumbled into a privilege escalation exploit that let us buy unreleased products through a URL encoding trick against Solebox's PerimeterX (PX3) bot protection.
For 18 months, @botwht and Unreleased used this solebox bypass to checkout sneakers days before they hit the shelves. No queue. No raffle. Add to cart, pay, done.
The exploit is patched. What follows is a full technical breakdown of how it worked, why PerimeterX missed it, and what it tells you about the gaps in modern bot protection.
What is Solebox's bot protection?
Solebox uses PerimeterX (now rebranded as HUMAN Security) to block bots and automated traffic. PerimeterX analyzes TLS fingerprints, browser behavior, and JavaScript execution to distinguish real shoppers from scrapers. When it flags you, you'll see the "Press & Hold to confirm you are human" challenge.
Solebox is one of Europe's bigger sneaker boutiques, which makes it a constant target for sneaker bots. Their PerimeterX deployment covers product pages, the cart, and checkout. Or at least, it was supposed to cover all of those.
It missed the admin routes.
How the first solebox bypass worked
The story starts with a monitoring tool. We needed to track Solebox product pages for restocks, which meant sending automated requests to pages protected by PerimeterX.
Our first bypass was a URL encoding trick. We appended %3F.ico to the end of product URLs:
https://www.solebox.com/en/product-page%3F.ico
Two things happened simultaneously when that request hit the server:
- PerimeterX checked the URL extension, saw
.ico, and classified the request as a static asset fetch. Icon files don't need bot protection, so PX3 waved it through. - Solebox's application server decoded
%3Finto?, turning the URL into a normal query string. It served the full product page.
The decoding mismatch between the security layer and the application layer was the entire bypass. PerimeterX evaluated the raw URL; the web server evaluated the decoded URL. They saw two different requests.
# What PerimeterX saw:
"/en/product-page%3F.ico" # Looks like an icon file → skip protection
# What the application server processed after URL decoding:
"/en/product-page?.ico" # Normal product page with a junk query param → serve it
This worked for weeks. Then Solebox patched it, and our monitors went silent.
The admin route escalation
When the .ico trick stopped working, I started probing other routes. Standard product pages were all behind PerimeterX now. But admin routes might not be.
I tried:
https://www.solebox.com/admin/index.php%3F.ico
The monitor came back online. Requests through the admin path with the URL encoding suffix still bypassed PX3, because Solebox's PerimeterX integration didn't cover admin-prefixed routes.
But the responses looked wrong.
Product pages were returning inventory for items that weren't supposed to release for days. At first I assumed the monitor had a parsing bug; maybe it was misreading dates or matching against the wrong SKU list.
So I tested it manually. I hit a product URL through the admin route, grabbed the session, and tried adding an unreleased pair to the cart.
The cart accepted it. Checkout accepted it. Payment went through.
Requests routed through /admin/ inherited a permissions context that bypassed the release schedule. We could see and purchase inventory before Solebox's own storefront made it available to shoppers.
How we automated the solebox bypass
Once we confirmed the exploit was real, we built a bot around it. The architecture was straightforward:
import requests
session = requests.Session()
# Step 1: Generate session via admin route
admin_url = "https://www.solebox.com/admin/index.php%3F.ico"
resp = session.get(admin_url)
# Session now carries elevated privileges
# Step 2: Check unreleased inventory
# Products visible through admin context before public release
product_url = "https://www.solebox.com/admin/product-slug%3F.ico"
product_resp = session.get(product_url)
# Parse for size/variant IDs
# Step 3: Add to cart using the privileged session
cart_payload = {
"variant_id": "extracted-variant-id",
"quantity": 1
}
session.post("https://www.solebox.com/cart/add", data=cart_payload)
# Step 4: Checkout
# Standard checkout flow — payment details, shipping address
Note: This is a simplified reconstruction. The actual implementation included session cookie management, retry logic, and size selection. The exploit is patched and this code won't work against Solebox today.
The bot handled three jobs:
- Generate session cookies with elevated privileges through the admin route
- Query inventory that wasn't yet visible on the public storefront
- Complete checkout before the scheduled release date
While other botters set alarms for Saturday morning drops, we checked out on Wednesday.
The shipping problem
Early access created a logistics headache. Solebox's warehouse team ships fast, and orders to unusual destinations drew attention.
We learned this the hard way. UK shipping addresses triggered internal flags. Orders got marked "return to sender" before they left the warehouse. Whoever reviewed the order queue could see that someone was buying products days before the public drop — and shipping internationally made that order stand out.
The fix: German pack stations. DHL Packstationen are self-service lockers spread across Germany, near Solebox's warehouse. We shipped everything priority delivery, using different names and different stations. All within Germany, all close to the fulfillment center, all blending into normal domestic shipments.
Paranoid? Probably. But the orders went through for 18 months.
Why PerimeterX missed the admin route exploit
PerimeterX protects the routes its customer configures it to protect. Solebox deployed PX3 on their public-facing storefront: product pages, cart, checkout, account pages. The admin routes either sat outside PX3's coverage or were excluded from protection because Solebox's own team needed to access them without triggering bot challenges.
Three specific failures stacked on top of each other:
1. Route-level protection gap. PerimeterX wasn't applied to /admin/ paths. This is a configuration decision by the retailer, not a flaw in PerimeterX itself. But it meant that anyone who discovered an admin URL could reach the application without passing through bot detection.
2. URL decoding mismatch. The %3F.ico trick exploited a gap between PX3's URL evaluation (pre-decoding) and the web server's URL processing (post-decoding). This is a well-known class of web security bug — HTTP request smuggling and URL parser differentials show up on the OWASP Top 10 regularly. In Solebox's case, the mismatch let us reach admin routes even when some path-based filtering existed.
3. No privilege boundary between admin and storefront sessions. The application server granted admin-context sessions to unauthenticated requests that arrived through admin-prefixed paths. There was no login check, no role verification, no session scope restriction. The session simply inherited whatever context the route implied.
Any one of these, fixed independently, would have killed the bypass. All three had to be present for the exploit to work.
What Solebox should have done
If you're running an e-commerce site with bot protection, the Solebox bypass exposes three specific checks worth auditing:
Audit route coverage. List every route your application responds to. Check which ones sit behind your anti-bot layer. Admin paths, API endpoints, health checks, internal tools — anything that returns application data should be evaluated. If a route exposes inventory or allows cart operations, it needs protection regardless of its prefix.
Normalize URLs before evaluation. Your security layer and your application server should agree on what URL they're looking at. If your WAF evaluates %3F.ico as a static asset while your app decodes it as a query string, you have a parser differential. Test this by sending URL-encoded characters in path segments and comparing how each layer interprets them.
Enforce session privileges explicitly. A request arriving on an admin route shouldn't automatically get admin-level inventory access. Sessions should carry explicit permission scopes, and the application should validate those scopes on every state-changing action: adding to cart, viewing pre-release inventory, checking out.
What happened after the patch
Solebox eventually closed the admin route exploit. Someone on their side — possibly flagged by HUMAN Security's analytics, possibly tipped off by the unusual pre-release order patterns — locked down the admin paths and fixed the session privilege issue.
After the patch, a person claiming to be Solebox staff showed up in Discord servers threatening legal action. Screenshots of our orders, threats of lawsuits, promises to "take us down."
Nothing came of it. Discord threats aren't cease-and-desist letters, and no legal action followed. The exploit was dead, and apparently so was their interest in pursuing it further.
Bypassing Solebox's PerimeterX today
The admin route exploit is gone. If you're trying to bypass PerimeterX on Solebox in 2026, you're dealing with the same detection stack as any other HUMAN Security deployment:
- TLS fingerprinting: Python's
requestslibrary produces a TLS fingerprint that PerimeterX blocks immediately. Use curl_cffi with browser impersonation to match Chrome or Firefox fingerprints. - JavaScript challenges: The "Press & Hold" challenge requires a real browser environment. Tools like Camoufox, SeleniumBase UC mode, or Patchright handle this.
- Behavioral analysis: PerimeterX monitors mouse movement, scroll patterns, and click timing. Headless browsers need human-like interaction simulation, see humancursor for Playwright/Puppeteer.
- IP reputation: Datacenter IPs get flagged fast. Residential proxies are baseline for any serious Solebox botting. ISP proxies work too if they're German IPs, which match Solebox's core market.
For a deeper walkthrough of each detection layer and the current DIY bypass techniques, the PerimeterX bypass guide covers all six methods in detail.
FAQ
Is the Solebox admin route exploit still working?
No. Solebox patched the admin route vulnerability and the URL encoding bypass. The techniques described above are historical and won't work against Solebox's current PerimeterX deployment.
Can you still bot Solebox in 2026?
Solebox still runs PerimeterX (HUMAN Security). Bypassing it requires a fortified headless browser with correct TLS fingerprints, residential proxies, and session warming. It's harder than it was in 2023-2024, but HUMAN Security deployments remain bypassable with the right browser automation stack. Check the full PerimeterX bypass guide for current methods.
What proxies work best for Solebox?
German residential or ISP proxies. Solebox's primary market is Germany, so German IPs get the least friction from PerimeterX's geo-based risk scoring. Datacenter proxies will get blocked almost immediately. See our sneaker proxy guide for specific provider recommendations.
What was the URL encoding trick?
We appended %3F.ico to URLs. PerimeterX read the raw URL and treated .ico as a static asset (no protection needed). Solebox's server decoded %3F as ? and served the normal page. The two systems interpreted the same URL differently, which let requests through without bot detection.
How did admin routes give access to unreleased products?
Solebox's application server assigned elevated session privileges to requests that arrived through admin-prefixed paths, without requiring authentication. These sessions could view and purchase inventory that was loaded into the system but not yet released on the public storefront. The lack of explicit role verification on admin routes was the core vulnerability.
Wrapping up
The Solebox bypass ran for 18 months on three stacked misconfigurations: unprotected admin routes, a URL parser differential between PerimeterX and the application server, and missing session privilege checks. None of those are exotic attack vectors. URL encoding mismatches and route-level protection gaps show up in OWASP guidelines and penetration testing checklists.
The takeaway for anyone building or bypassing bot detection systems: protection only works on the routes it covers. One unprotected path to the same application logic can undo everything else.
