What is the CVSS score of EUVD-2026-34844?

EUVD-2026-34844 has a CVSS 3.1 base score of 6.5 (Medium). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N. EPSS exploitation probability: 0.0%.

sanic-cors EUVD-2026-34844

| CVE-2026-37737 MEDIUM

Origin Validation Error (CWE-346)

2026-06-05 mitre

GHSA-94jw-hqvj-vw74

Authentication Bypass N A

6.5

CVSS 3.1 · NVD

Severity by source

NVD PRIMARY

6.5 MEDIUM

AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N

Primary rating from NVD · only source for this CVE.

CVSS VectorNVD

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

Required

Scope

Unchanged

Confidentiality

High

Integrity

None

Availability

None

Lifecycle Timeline

Analysis Generated

Jun 05, 2026 - 21:24 vuln.today

CVSS changed

Jun 05, 2026 - 21:22 NVD

6.5 (MEDIUM)

CVE Published

Jun 05, 2026 - 00:00 nvd

UNKNOWN (no severity yet)

Blast Radius

ecosystem impact

† from your stack dependencies † transitive graph · vuln.today resolves 4-path depth

19 pypi packages depend on sanic-cors (16 direct, 4 indirect)

Ecosystem-wide dependent count for version 2.2.0.

DescriptionCVE.org

sanic-cors version 2.2.0 and prior contains an improper regular expression in the try_match() function in sanic_cors/core.py that uses re.match without end-anchoring. This allows an attacker to bypass CORS origin allowlists by registering a domain that begins with a trusted origin string, to gain unauthorized access to cross-origin requests for authenticated resources.

AnalysisAI

CORS origin allowlist bypass in sanic-cors 2.2.0 and prior enables cross-origin access to authenticated resources by exploiting an unanchored regular expression in the origin-matching logic. The library's try_match() function in sanic_cors/core.py uses Python's re.match() - which matches only from the start of a string, not the full string - allowing an attacker who controls a domain prefixed with a trusted origin (e.g., trusted.example.com.attacker.com) to satisfy the allowlist check. Exploitation requires a victim user to visit an attacker-controlled page, placing this in a network-accessible, user-interaction-required threat model. No public exploit code has been identified at time of analysis, and no KEV listing exists.

Technical ContextAI

sanic-cors is the CORS middleware library for the Sanic async Python web framework, analogous to flask-cors or django-cors-headers. CORS enforcement depends on accurately matching the incoming Origin header against a server-configured allowlist. The root cause is CWE-346 (Origin Validation Error): the try_match() function at sanic_cors/core.py uses Python's re.match(), which anchors only at the beginning of a string. When an allowlist entry such as 'https://trusted.example.com' is compiled as a pattern and matched via re.match(), the string 'https://trusted.example.com.attacker.com' satisfies the match because re.match() returns a match object for any input that starts with the pattern. The correct fix is re.fullmatch() or appending a '$' end anchor. Affected versions are 2.2.0 and all prior releases; CPE data in NVD is currently listed as n/a, meaning no machine-readable product identifier has been assigned yet.

RemediationAI

No vendor-released patch has been identified at time of analysis. Defenders should monitor the upstream repository at https://github.com/ashleysommer/sanic-cors and the PyPI package at https://pypi.org/project/Sanic-Cors/ for a fix release. As a compensating control, application owners can manually patch the try_match() function in their local installation by replacing re.match(pattern, origin) with re.fullmatch(pattern, origin), or by appending a '$' end anchor to all origin patterns before compilation - this ensures the full origin string is matched. Trade-off: this manual patch will be overwritten on package upgrade and requires re-application. Additionally, if the application allows wildcard or prefix-style origin patterns in its CORS configuration, tighten these to exact-string literals where possible, reducing reliance on regex matching altogether. Review whether CORS is functioning as an actual security boundary in the application; if sensitive authenticated endpoints rely solely on CORS enforcement without additional access controls (e.g., CSRF tokens, Authorization headers), add those controls as defense-in-depth.