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

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

Is there a public PoC exploit available for EUVD-2026-81306?

Yes, a public proof-of-concept exploit is available for EUVD-2026-81306. Prioritise patching immediately. EPSS: 0.2%.

Is there a patch available for EUVD-2026-81306?

Yes, a patch is available for EUVD-2026-81306. Update the affected software to the latest version immediately.

djust EUVD-2026-81306

Q: Which versions of djust are affected by EUVD-2026-81306?

Cross-tenant data exposure on the djust live WebSocket path affects installations before 1.0.7 that use host-, subdomain-, or domain-based TenantResolvers for multi-tenancy.. A patch is available.

| CVE-2026-61589 MEDIUM

Use of Less Trusted Source (CWE-348)

2026-09-16 https://github.com/djust-org/djust

GHSA-v9rj-xjfv-xj9r

Python Information Disclosure Django

6.3

CVSS 3.1 · Vendor: https://github.com/djust-org/djust

View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

Access

Authenticate to multi-tenant djust app
Delivery

Open live-view over WebSocket
Exploit

Reconstructed request omits Host, resolves to 'testserver'
Execution

TenantResolver returns None, scoping disabled
Impact

Read unscoped cross-tenant rows

Vulnerability Assessment

Weakness	CWE CWE-348 ASVS 5.0 V6 - Authentication IP-independent access control
Exploitation Conditions	Requires a djust deployment (version < 1.0.7) configured for multi-tenancy using host-, subdomain-, or domain-based TenantResolvers, AND the setting STRICT_MODE=False for the cross-tenant DISCLOSURE outcome; with the default STRICT_MODE the same flaw only breaks tenancy (empty queryset), not leaks. Exploitation occurs specifically on the WebSocket 'live path' (handle_mount / ViewRuntime._build_request), which rebuilds the request via RequestFactory().get(...) without HTTP_HOST. Limiting factors: an authenticated user must open the live-view mount (PR:L), the multi-tenant host-resolver architecture must be in use, and the disclosure worst case depends on the non-default STRICT_MODE=False; the ordinary HTTP path resolves tenants correctly and is unaffected. The only remediation on the live path is upgrading to 1.0.7 - there is no configuration workaround.
Impact	This is a moderate-severity, low-real-priority multi-tenancy flaw. The vendor CVSS 3.1 vector (AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:N/A:N = 6.3) is internally coherent and I concur with it: network-reachable over the WebSocket live path, but AC:H reflects that impactful cross-tenant disclosure only occurs under a non-default configuration (STRICT_MODE=False) combined with host/subdomain/domain TenantResolvers, and PR:L reflects that an authenticated client must open the live-view mount. Under the default STRICT_MODE the same bug degrades to an empty queryset (broken tenancy / availability of data to the legitimate tenant), not disclosure - so the C:H worst case is conditional. No EPSS score, no CISA KEV entry, and no public POC were provided, and no SSVC decision data was supplied. There is no signal of active exploitation. The confidentiality impact is real (cross-tenant data leakage in a multi-tenant deployment) but the compounding preconditions (multi-tenant host-based resolver + STRICT_MODE disabled + authenticated live-path access) keep realistic risk well below the raw score. Treat as a routine patch-and-verify item, prioritized only for operators running djust multi-tenancy with STRICT_MODE=False.
Exploit ScenarioDerived	In a djust multi-tenant deployment using host/subdomain TenantResolvers with STRICT_MODE=False, an authenticated user opens a live-view over WebSocket; because the reconstructed request carries no Host header and defaults to 'testserver', tenant resolution returns None and the tenant-scoped managers return unscoped rows, exposing other tenants' records to that user's session. No public exploit code was identified at time of analysis, and the attack requires the specific non-default multi-tenant configuration.

This Month Plan within 30 days. Why: MEDIUM severity (CVSS 4.0-6.9).

Patch available 0.2% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv1 – Sep 16, 2026

Cross-tenant data exposure on the djust live WebSocket path affects installations before 1.0.7 that use host-, subdomain-, or domain-based TenantResolvers for multi-tenancy. Because the request rebuilt by handle_mount and ViewRuntime._build_request carries no client Host, get_host() falls back to "testserver", so the tenant resolves to None on the live path even though the ordinary HTTP path resolves it correctly; with STRICT_MODE=False the tenant-scoped managers then return unscoped rows and an authenticated user can read other tenants' data. With the default STRICT_MODE the identical flaw only yields empty querysets (broken tenancy, no disclosure). No public exploit code exists and there is no confirmed active exploitation; EPSS/KEV data were not provided, and the CVSS vector (AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:N/A:N, 6.3) reflects the high attack complexity and the dependency on an explicit STRICT_MODE=False configuration.

RemediationAI

Vendor-released patch: djust 1.0.7. Upgrade all djust installations to 1.0.7 or later, after which the ASGI handshake Host is validated against ALLOWED_HOSTS and propagated with the TLS scheme into the reconstructed request so live-path tenant resolution matches HTTP; see the advisory at https://github.com/djust-org/djust/security/advisories/GHSA-v9rj-xjfv-xj9r and the release at https://github.com/djust-org/djust/releases/tag/v1.0.7. The vendor states plainly that there is no workaround on the live path short of upgrading, so treat the version bump as the only definitive fix. Where immediate patching is impossible, actionable compensating controls are: first, confirm STRICT_MODE is left at its default (not False) - this reduces the flaw from cross-tenant disclosure to broken tenancy (empty querysets and failed mounts on the live path) and carries the operational trade-off that tenant-scoped views may appear empty or error for live users; second, migrate tenant resolution away from Host/subdomain/domain TenantResolvers to path- or session-based resolution for as long as the unpatched version is running, which prevents the None-tenant fallback but requires an architectural change and coordinated URL/routing updates; and third, since exploitation requires an authenticated user (PR:L) able to open a live-view mount, restrict access to live-view endpoints to fully trusted accounts until the upgrade completes. Note that neither compensating control is a substitute for upgrading, and that with the default STRICT_MODE the residual risk is availability/functionality rather than disclosure.

Affected VersionsENISA

djust < 1.0.7

Affected Packages

pypi djust fix: 1.0.7

Source: OSV (Open Source Vulnerabilities)

Affects your stack

Affects 1 package in pypi

Checking this CVE against your own stacks and servers is part of the Basic plan and up.

Technical ContextAI · show details

djust is a Python/Django live-view framework (CPE pkg:pip/djust) that rebuilds an HttpRequest on the WebSocket path via RequestFactory().get(...) inside handle_mount and ViewRuntime._build_request. That synthetic request never set HTTP_HOST, so Django's request.get_host() fell back to the literal "testserver", which is the CWE-348 (Use of Less Trusted Source) root cause: a hardcoded placeholder was consulted instead of the authoritative Host from the ASGI connection scope. Host-, subdomain-, and domain-based TenantResolvers downstream of that value therefore saw no usable host and misresolved the active tenant to None, while the same resolver chain on the HTTP request path - where the real Host header is present - behaved correctly. The consequence is conditional: the default (strict) tenant-manager behavior produced an empty queryset and broke tenancy silently, whereas STRICT_MODE=False removed the tenant filter entirely and returned rows across all tenants. The fix in 1.0.7 extracts the handshake Host from the ASGI scope, validates it against Django's ALLOWED_HOSTS using the same gate logic already applied to the CSWSH Origin check (parsing with Django's split_domain_port so malformed or spoofed Hosts are rejected at the boundary), and propagates that Host together with the TLS scheme into the reconstructed request, making live-path tenant resolution identical to the HTTP path. The scope-change component (S:C) and confidentiality-only impact (C:H/I:N/A:N) in the assessed vector reflect that the flaw leaks data within the framework's tenant boundary but grants no write or code-execution capability.

Know when Django gets its next vulnerability

Watch products and get an email when something new is published
Check this CVE against your own stack and servers
Exploit and PoC references, threat intelligence from 22 sources

Continue with Google Continue with GitHub

No credit card · 7-day full trial

Severity by source

Vendor (https://github.com/djust-org/djust) PRIMARY 6.3 MEDIUM

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

vuln.today AI 6.3 MEDIUM

Network live-path access with authenticated mount (PR:L); AC:H because impactful disclosure needs multi-tenant host resolvers plus non-default STRICT_MODE=False; S:C for crossed tenant boundary, C:H disclosure only, no integrity/availability impact.

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

4.0 AV:N/AC:H/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N

Primary rating from Vendor (https://github.com/djust-org/djust).

CVSS VectorVendor: https://github.com/djust-org/djust

Attack Vector

Network

Attack Complexity

High

Privileges Required

Low

User Interaction

None

Scope

Changed

Confidentiality

High

Integrity

None

Availability

None

Lifecycle Timeline

Patch available

Sep 16, 2026 - 23:19 EUVD

DescriptionCVE.org

Impact

The WebSocket handle_mount and ViewRuntime._build_request rebuild an HttpRequest via RequestFactory().get(...) with no HTTP_HOST, so request.get_host() defaulted to "testserver" on the live path. Host/subdomain/domain TenantResolvers then misresolved the tenant - None on the live path while the HTTP path resolved correctly. With STRICT_MODE=False the tenant-scoped managers returned unscoped rows (cross-tenant disclosure); with the default they returned an empty queryset (broken tenancy).

Patches

Fixed in djust 1.0.7. The handshake Host is extracted from the ASGI scope, validated against ALLOWED_HOSTS (the same logic as the CSWSH Origin gate, parsed with Django's split_domain_port so malformed Hosts are rejected at the boundary), and propagated - with the TLS scheme - into the reconstructed request, so live-path tenant resolution matches HTTP exactly.

Workarounds

No workaround on the live path short of upgrading. Most exposed when combined with STRICT_MODE=False.

Threat Intelligence Overview

EPSS Score

0.2%

Top 95% exploitable

Prevalence

Low

niche open-source Django LiveView-style framework, minimal enterprise footprint

Threat Intel

1 source

Exploit

POC

Public exploit code exists

Data Quality

6 sources

Confidence: High

EUVD

NVD

CVE.org

EPSS GHSA

GitHub

VulDB

How this decision was reached

The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.

SignalValue

Severity MEDIUM

CISA KEV No

Public POC Yes

EPSS 0.2%

Patch available Yes

Active threat No

Deciding rule

MEDIUM severity (CVSS 4.0-6.9)

What every action level means

Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.

Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.

This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.

This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.

Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision· derived

Scheduled

Exploitation· derived

Poc

System Exposure· derived

Open

Automatable· derived

Human Impact· derived

Medium

Priority Score

Low Medium High Critical

KEV: 0

EPSS: 0

CVSS: +32

PoC: +20

Weaponized: 0

Threat intel: 0

Gov advisory: 0

Attack Technique

Information Disclosure MEDIUM

Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.