Loading story…
Security researchers detailed multiple ways applications can be tricked into accepting malicious URLs when validation relies on weak regular expressions or unsafe handling of non-ASCII hostnames. Common flaws include missing ^ or $ anchors, unescaped dots, multiline matching, overly broad scheme checks, and denylist-style filters for user-controlled subdomains such as *.example.jp. The reported impact includes open redirect, access-control bypass, and XSS, with additional edge cases involving userinfo, protocol-relative URLs, and parser discrepancies between browsers and language libraries, especially around backslashes.
A separate analysis showed that multibyte and invalid non-ASCII characters can also subvert redirect and link validation by causing downstream components to emit ? inside the hostname, changing how a trusted-looking domain is interpreted. The behavior was observed across legacy Java, Tomcat, ASP.NET, PHP, and some tooling, while newer Java and Tomcat versions mitigated parts of the issue; Burp Suite was also noted as a source of false positives in some HTTP/2 proxy scenarios. Researchers recommended strict allowlist validation, fixed https handling, parser-based host verification, rejection of non-ASCII subdomains unless safely converted with Punycode and STD3ASCIIRules, URL-encoding before redirects, and testing regexes for ReDoS with input length limits.
See affected versions and whether adversaries are exploiting it.
3 events from the most recent confirmed update back to the earliest known activity.
MBSD published follow-up research describing open redirect and link-manipulation bypasses that rely on multibyte or non-ASCII characters later being transformed into question marks in URL hosts. The article covered behaviors in legacy Java, Tomcat, ASP.NET, PHP, and Burp Suite, and recommended rejecting non-ASCII subdomains or safely converting them to ASCII.
On its technical blog, Mitsui Bussan Secure Directions published an analysis of how weak regular expressions used to validate trusted-domain URLs can be bypassed. The article detailed pitfalls such as missing anchors, unescaped dots, userinfo handling, protocol-relative URLs, parser discrepancies, and ReDoS risk, and recommended stricter allowlist-style validation.
Jonathan Birch published research describing the HostSplit and HostBond exploit classes, showing how Unicode normalization and IDNA implementation weaknesses can make software validate one hostname while resolving or displaying another. The paper documented affected products including Edge/IE, .NET, Python, Java, Office 365, and Gmail, and recommended making security decisions on ASCII A-labels and enforcing safer IDNA conversions.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
See whether adversaries are exploiting this yet, and where the affected versions run in your environment.
4 references tracked. Mallory keeps watching after this page renders.
mbsd.jp
Open sourcembsd.jp
Open sourceowasp.org
Open sourcei.blackhat.com
Open sourceMap indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
A high-severity server-side request forgery flaw tracked as **`CVE-2026-67201`** affects the V programming language through version **0.5.2**, allowing remote attackers to bypass host-based allowlists. The issue arises from a parser differential between **`net.urllib`** and **`net.http`**: `net.urllib.parse()` can validate a seemingly trusted host, while `net.http.get()` later normalizes a backslash in the URL authority field and connects to an internal destination instead. The vulnerability was addressed in merged commit **`85859f0`** through a change titled **"net.urllib: reject backslashes in URL authorities"**, with accompanying tests for `vlib/net/urllib` and `vlib/net/http`. Published guidance recommends upgrading to a patched release and reviewing applications to ensure URL normalization and host validation are performed consistently across parsing and request-handling components.
Jul 30, 2026
Researcher Orange Tsai disclosed an unauthenticated remote-code-execution chain in an Amazon internal collaboration service built on the Nuxeo Java content-management platform. The attack exploited inconsistent handling of URL path parameters between Nuxeo and Tomcat to bypass authentication, then abused legacy JBoss Seam Expression Language functionality and a blacklist bypass to execute arbitrary commands. Amazon isolated and investigated the affected server after receiving the report; Nuxeo released version `8.10` to address the RCE condition. The finding reflects a broader class of URL-parser inconsistencies that can undermine application security controls. Differences in URL normalization, DNS resolution, and HTTP-client behavior can permit SSRF filter bypasses and protocol smuggling to internal services, including Redis, Memcached, SMTP, Graphite, and Docker. Organizations should upgrade affected Nuxeo deployments, remove or isolate end-of-life JBoss Seam components, avoid reusing attacker-controlled URLs after validation, and enforce network-layer restrictions that prevent application servers from reaching sensitive internal endpoints.
Sep 3, 2026
A critical flaw in Bouncy Castle Java certificate validation, tracked as **CVE-2026-8763**, allows attackers to bypass **Name Constraints** checks by appending a trailing dot to `rfc822Name` and `URI` values in certificates. The bug affects **Bouncy Castle for Java** before `1.85`, **BC-LTS** before `2.73.12`, and **Bouncy Castle FIPS (BC-FJA)** before `1.0.2.7`, `2.0.2`, and `2.1.3`, and carries a **CVSS 4.0 score of 9.3**. The weakness is classified as **CWE-295: Improper Certificate Validation** and is considered remotely exploitable without privileges or user interaction. Project maintainers said the issue stems from inconsistent handling of trailing dots in `PKIXNameConstraintValidator`: `dNSName` values were normalized for comparison, but `rfc822Name` and `URI` values were not, enabling excluded subtree checks to be evaded. An attacker controlling a name-constrained intermediate CA could issue certificates for email addresses or URI hosts that policy should have blocked. The vulnerable path is reachable through the Java 8+ PKIX certificate validation flow, and fixes were released in the patched versions above, including commit `2c28b253a446`.
Aug 5, 2026