CVE-2026-12071

This vulnerability in Tobit Webbox (Rollout 524 and earlier) exposes a systemic failure that security teams should recognize as a pattern, not an anomaly: URL parsing and HTTP header construction are operating as disconnected security boundaries. The core issue has two components. First, the redirect target accepts user-supplied input that gets processed differently at different layers. An attacker can use '%2e' (encoded dot) to bypass domain validation — the validator sees a safe string, but the HTTP layer's URL parser interprets it as a dot, allowing domains like 'tobit.attacker.com' to pass checks that look for 'tobit.' at the start. Combined with similar-TLD registration (e.g., a lookalike .so or .software domain), this enables a transparent phishing chain where users see a trusted domain in the URL bar but land on attacker infrastructure. Second, URL-encoded line breaks ('%0a') in the redirect input inject arbitrary HTTP headers into the 302 response. This is the more severe vector: an attacker controlling both the redirect target AND response headers can set malicious Content-Security-Policy, Strict-Transport-Security, or CORS headers. This transforms an open redirect into session hijacking with browser persistence baked in — the victim's browser accepts security metadata set by the attacker on what appears to be a trusted-origin response. The underlying cause isn't sloppy coding in isolation — it's that URL validation logic and HTTP response construction were developed as separate modules with no shared security contract. The validation layer passed '%2e' because its regex saw nothing dangerous. The redirect layer passed it to the HTTP writer because it received a 'validated' URL. Neither was wrong alone. The vulnerability is the compound result of correct-enough decisions made by developers who couldn't see each other's work. What to check: audit your codebase for any code path that takes user-controlled URLs and passes them to HTTP redirect responses. Look for whether URL parsing, validation, and header construction use a centralized library or are scattered across modules. The fix isn't more string sanitization — it's migrating to a typed API that enforces header safety at the type level. If you're still concatenating strings to build HTTP responses, you're sitting on the same failure mode. Test your URL validation with encoded input (%2e, %0a, double-encoding variants) specifically at the boundary where validated URLs meet HTTP construction logic — unit tests pass, integration tests that check downstream interpretation almost never exist.

Reviewed through automated stages and approved by a human before publication.