CVE-2026-37737: sanic-cors CORS Bypass via Improper Regex Anchoring

Technical summary

The try_match() function in sanic_cors/core.py uses Python's re.match() without anchoring the pattern to the end of the string. The re.match() function only anchors at the start, allowing partial matches. An attacker can register a domain beginning with a whitelisted origin to satisfy the regex without matching the full origin string. This is a classic regular expression anchoring mistake (CWE-625). The vulnerability affects CORS policy enforcement (CWE-346), which is meant to prevent unauthorized cross-origin requests.

Business impact

Attackers can access sensitive, authenticated resources via cross-origin requests despite CORS allowlist configuration. This is particularly dangerous for APIs or web applications serving user data, financial information, or account-specific resources. An attacker does not need to compromise the target site itself—only register a malicious domain and trick a user into visiting it while logged into the target application. The impact is confidentiality-focused: data exposure without requiring authentication bypass.

Affected systems

sanic-cors version 2.2.0 and all prior releases are vulnerable. sanic-cors is a Python library providing CORS support for Sanic web framework applications. Any application using sanic-cors with version ≤2.2.0 is at risk. Applications using newer versions, custom CORS implementations, or other frameworks (Flask, Django, etc.) are not directly affected.

Exploitability

Exploitability is moderate. An attacker must (1) register or control a domain starting with a trusted origin, (2) trick a user into visiting the attacker's domain while authenticated to the target site (often via phishing or social engineering), and (3) execute cross-origin requests to authenticated endpoints. No special privileges, network access, or authentication are required; user interaction (visiting the attacker's site) is the primary barrier. The attack is practical for motivated threat actors targeting high-value targets.

Remediation

Upgrade sanic-cors to a version after 2.2.0 that includes the fix. Verify that the patched version correctly anchors the origin regex pattern (using $ or re.FULLMATCH). Alternatively, implement custom CORS validation that compares origins without regex, ensuring exact string matching of the full origin domain. Review CORS configurations in production to ensure origin allowlists are as restrictive as possible (prefer specific domains over wildcards).

Patch guidance

Consult the sanic-cors project repository and release notes to identify the fixed version number (verify against the vendor advisory, as patch versions are not provided in the source data). Update the dependency in your requirements.txt or pyproject.toml, then test your application's CORS behavior against your allowlist before production deployment. Ensure testing covers edge cases such as subdomain allowlists and origin matching.

Detection guidance

Monitor application logs for cross-origin requests originating from unexpected domains, especially those with names similar to or containing trusted origin strings. Review CORS allowlist configurations and compare them to actual allowed origins in logs. Use browser developer tools to inspect cross-origin requests and their origin headers. Network-level detection is challenging without access to origin headers; focus on application-level logging of rejected and accepted CORS requests.

Why prioritize this

Although not currently listed in the CISA KEV catalog, this vulnerability merits prompt prioritization because (1) it directly undermines a primary web security control (CORS), (2) it requires no network-level exploitation and is easy to trigger, (3) it exposes authenticated resources and user data, and (4) the fix is straightforward (upgrade dependency). Organizations with sensitive APIs should treat this as high-priority; others with limited cross-origin traffic may schedule it as medium.

Risk score, explained

The CVSS 3.1 score of 6.5 (MEDIUM) reflects high confidentiality impact (user interaction required, no authentication needed, network-accessible) but no integrity or availability impact. The user interaction requirement (a user must visit the attacker's site) and the requirement to control a similarly-named domain reduce the score from HIGH. Organizations with strict CORS allowlists and user awareness training may see lower practical risk.

Frequently asked questions