Django
Monthly
Brute-forceable magic-code email login in Plane versions prior to 1.4.0 allows unauthenticated remote attackers to guess a six-digit numeric login code and take over accounts. The verify endpoint extends django.views.View instead of DRF's APIView, so the configured AnonRateThrottle never runs, and there is no per-code attempt counter, no counter invalidation, and no Django-level throttle middleware behind it, leaving roughly 20 bits of OTP entropy with effectively unlimited guesses inside the code's Redis TTL window. There is no public exploit identified at time of analysis and no confirmed active exploitation, but the 9.1 CVSS reflects a full account takeover path (C:H/I:H) with no authentication or user interaction required, and the fix was released in Plane 1.4.0.
Plane's InstanceAdminSignUpEndpoint in versions 0.13 through pre-1.4.0 allows unauthenticated remote attackers to exploit a time-of-check time-of-use race during first-run setup and create a second instance administrator with full instance-admin authority alongside the legitimate operator. Exploitation requires that no instance administrator exists yet and that the attacker wins a concurrent-request race before the legitimate first admin is committed; after setup completes, the endpoint rejects new admins and the flaw is unreachable. No public exploit identified at time of analysis, and the risk is situational because the vulnerable window is brief and requires network reachability to the admin signup path.
Authenticated code injection in Horilla HR (horilla-hr) before 2.0.0 lets any user with access to the HorillaListView export functionality run arbitrary operating-system commands with the privileges of the application process - root, in the project's shipped horilla/horilla-hr Docker image. The issue is rated CVSS v3.1 8.8 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H): exploitable remotely over the network with low privileges, requiring only a valid account able to reach the list/export endpoint, with no user interaction and no non-default configuration. No public exploit code and no confirmed active exploitation were identified at time of analysis, and the vendor released a fix in version 2.0.0.
Command injection in the automation controller's external logging (rsyslog) configuration of Red Hat Ansible Automation Platform 2 allows a superuser to achieve arbitrary command execution inside the control-plane rsyslog component, exposing the controller SECRET_KEY and database credentials and enabling decryption of all stored credentials. Exploitation requires authenticated superuser privileges (CVSS 3.1 7.2, PR:H, no user interaction) and only takes effect when external logging is in use, so the malicious RainerScript configuration is actually generated and loaded. No public exploit code was identified and there is no CISA KEV listing indicating active exploitation, meaning real-world risk is strongly gated by the elevated privilege requirement even though the post-exploitation impact is a full control-plane compromise.
Missing authorization checks in the Red Hat Ansible Automation Platform 2 automation-controller allow an authenticated organization workflow-admin - a delegated, non-superuser role - to escalate into the control plane by copying a WorkflowJobTemplate and then launching jobs pinned to instance groups they hold no use_role on. The deep-copy permission sanitizer re-validates only the inventory, unified_job_template, and credentials of each cloned node, silently carrying over instance_groups, execution_environment, and labels, so the copier becomes administrator of a workflow that executes attacker-influenced automation in the control-plane execution context (CVSS 9.9, scope changed, high confidentiality, integrity, and availability impact). Exploitation is confirmed to require only a normal multi-tenant deployment plus workflow-admin rights; no public exploit code has been identified at time of analysis and there is no CISA KEV entry, and no vendor-released patch version was confirmed in the available intelligence.
Authenticated but low-privileged users of Red Hat Ansible Automation Platform 2 can bypass the automation-controller's sanitize_jinja() input-validation guard and have ansible-core evaluate attacker-supplied Jinja inside the execution environment, yielding arbitrary command execution and disclosure of secrets belonging to credentials the attacker cannot normally read. The flaw is exploitable remotely with no user interaction (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N per independent assessment) and requires only a controller account able to set one of the affected launch-time fields. No public exploit code has been identified at time of analysis, and the issue is not listed in CISA KEV; priority is bounded by the required authenticated foothold and the niche deployment footprint.
Remote code execution in Red Hat Ansible Automation Platform 2's automation-controller is possible when a privileged, authenticated user (CVSS PR:H) defines a custom Credential Type and abuses its environment-variable injector to set a process-hijacking loader variable such as BASH_ENV, ENV, LD_PRELOAD, LD_LIBRARY_PATH, PYTHONSTARTUP, or GIT_SSH_COMMAND, which the existing ANSIBLE_* prefix check and fixed ENV_BLOCKLIST fail to catch. Paired with the credential file injector, the attacker plants a script in the execution environment and points the loader variable at it, so arbitrary code executes inside the execution-environment container for any job that later attaches a credential of that type; this requires both the high privilege to author the credential type and a subsequent job consuming it. Red Hat's published CVSS of 7.6 (C:L/I:H/A:N) is lower than our independent assessment of the full vector (C:H/I:H/A:H), and because the vulnerable controller and the impacted execution-environment container are different security scopes, S:C applies. There is no CISA KEV listing and no public exploit identified at time of analysis.
Privilege escalation in Red Hat Ansible Automation Platform 2 (built on the AWX upstream project) lets an authenticated AAP platform administrator escape the container-group sandbox and obtain OpenShift namespace-level access, including the ability to read and exfiltrate namespace secrets. The flaw is reachable over the network (AV:N) with no user interaction (UI:N) and changes scope across the container/namespace boundary (S:C), but it is gated on the highest AAP privilege tier (PR:H), so it is an insider or compromised-admin scenario rather than an unauthenticated attack; only deployments that use container groups backed by OpenShift/Kubernetes are exposed. No public exploit code has been identified at time of analysis and the issue is not confirmed actively exploited (CISA KEV); no vendor-released patch has been identified at time of analysis, so mitigation depends on restricting the vulnerable field or the administrators who can reach it.
Stored cross-site scripting in the automation-controller component of Red Hat Ansible Automation Platform 2 lets an authenticated low-privileged user embed a javascript: hyperlink into job, ad hoc command, project update, or inventory update standard output, which is then rendered as a text/html link in the controller's stdout view. Because the HTML conversion escapes HTML metacharacters but never strips ANSI terminal escape sequences, an OSC 8 hyperlink becomes an unfiltered HTML anchor, and the response carries no Content-Security-Policy; a higher-privileged user (for example an administrator) who views that output page and clicks the link executes attacker-controlled JavaScript in their authenticated session, allowing actions up to full platform takeover. The vector is network-reachable with low privileges (CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:N, 8.7), but exploitation hinges on a privileged victim actively clicking the crafted link; no public exploit code and no confirmed active exploitation were identified at time of analysis.
Stored password survey answers in Red Hat Ansible Automation Platform 2's automation-controller can be recovered in plaintext by an authenticated user holding the delegated JobTemplate Admin role. The attacker tightens the minimum/maximum length constraint on a password-type survey question, then forces revalidation of a schedule or workflow job template node created by a higher-privileged user, causing the controller to decrypt the stored secret and embed it in the HTTP length-validation error response. No public exploit identified at time of analysis; exploitation is not unauthenticated (CVSS PR:L) and requires both the delegated role and an existing password-type survey value, making this a lateral, privilege-crossing credential-disclosure issue rather than a mass-exploitable perimeter break.
Privilege escalation and remote code execution on managed hosts is possible in Red Hat Ansible Automation Platform 2 because the automation-controller exposes the provisioning-callback secret (host_config_key) to anyone holding only read-level view_jobtemplate permission and accepts a client-supplied X-Forwarded-For header as proof of caller identity when the gateway proxy allow-list is empty. An attacker who reads the secret from the job template API representation or the activity stream and spoofs X-Forwarded-For to match any host in the target job template's inventory can launch that template against arbitrary managed hosts using the template's stored credentials; CVSS 3.1 base score is 9.9 (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H), no public exploit code was identified at time of analysis, and the decisive enabler is a non-default deployment condition - an empty proxy allow-list combined with provisioning callbacks actually being in use.
Command injection in MaxKB before 2.10.5-lts allows unauthenticated remote attackers to execute arbitrary shell commands when an assistant is configured with a tool, MCP tool, skill, or sub-application. Untrusted chat messages or ingested documents can coerce the LLM into invoking the un-gated `execute` shell tool, which lacks human approval and is exposed by the SandboxShellBackend. Both source deployments with MAXKB_SANDBOX disabled and the official root container's vulnerable gosu wrapper permit command execution outside the intended sandbox; no public exploit code or confirmed active exploitation was identified at time of analysis. A vendor patch is available in version 2.10.5-lts.
Cross-workspace read and modification of model parameter defaults in MaxKB 2.10.3-lts and earlier is possible for an authenticated user who holds model-read permission in a workspace they control, simply by supplying a model_id that belongs to a victim workspace. The model parameter form route checks authorization against the workspace in the URL path, but the underlying ModelSerializer.ModelParams fetches the Model by id alone without filtering on workspace_id, so the object-level check is bypassed (CWE-639, CVSS 3.1 base 7.4, AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:L). Impact is bounded: it is limited to reading or overwriting the victim's model_params_form, which can indirectly alter the default behavior of workflows that consume that model, and practical exploitation requires a multi-tenant deployment plus knowledge or guessing of a valid victim model_id; no public exploit identified at time of analysis and no fixed version is available as of this review.
Forged content modification in django-page-cms through 2.0.13 lets unauthenticated remote attackers exploit five CSRF-exempt admin mutation views in pages/admin/views.py to store unescaped page content that then renders to every site visitor as stored cross-site scripting. The attack is unauthenticated from the attacker's side (CVSS vectors list PR:N) but requires user interaction: an authenticated editor or admin must be lured to attacker-controlled HTML while holding an active CMS session (UI:P), so this is a genuine but conditional risk rather than a drop-everything emergency. No public exploit code and no confirmed active exploitation have been identified at time of analysis, and the secondary effects are bounded - the forged mutation only persists once a privileged victim's browser has sent the request successfully.
Unauthenticated arbitrary Python module import in djust before 1.0.7 lets any client that can reach the WebSocket or SSE mount endpoint force the server to import a module chosen by a client-supplied dotted path, executing that module's import-time side effects before any LiveView subclass check or per-view authentication occurs. The LIVEVIEW_ALLOWED_MODULES allowlist that should constrain this lookup is fail-open (the check is skipped when the setting is unset, which is the framework default) and uses loose startswith matching, so the flaw is reachable in a default configuration; the assessed vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. Impact is bounded by what is already installed and importable on the host: guaranteed outcomes are denial of service (import bombs, expensive dependency trees) and a module/class enumeration oracle exposed through distinct error strings, escalating to RCE-by-proxy where a suitably side-effectful module exists. No public exploit has been identified at time of analysis - the maintainer retains the reproducer privately - and there is no CISA KEV listing.
Broken object-level access control in djust before 1.0.7 lets an authenticated user view - and on some paths act on - object-scoped views they are not authorized for, by loading the page via a direct HTTP GET, navigating to it through SPA url_change, or embedding it as a {% live_render %} child (eager or lazy). The flaw exists because per-object authorization (get_object plus has_object_permission, ADR-017) was enforced only on the WebSocket mount and event paths, leaving these three render entry points unchecked; views that do not define a custom get_object are unaffected. Exploitation requires a valid account (CVSS PR:L), knowledge or enumeration of the target object identifier, and a djust deployment older than 1.0.7 that exposes an object-scoped view through any of those paths, giving high confidentiality impact with limited integrity impact (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N, score 7.1); no public exploit code was identified at time of analysis and CISA KEV does not list this issue.
An authentication/authorization bypass in the djust Python live-view framework (versions prior to 1.0.7) lets unauthenticated remote attackers mount any view over the WebSocket/SSE transport even when that view is protected by standard Django guards such as LoginRequiredMixin, PermissionRequiredMixin, UserPassesTestMixin, @method_decorator(login_required, name="dispatch"), a custom dispatch() override, or the djust admin extension's staff gate. Because djust authorizes WebSocket mounts through its own check_view_auth helper instead of Django's View.dispatch() chain, those HTTP-only guards are enforced on the initial GET but silently skipped where all events and application state actually flow, so an anonymous or under-privileged client can invoke handlers - including admin list, create, change, and delete operations. The CVSS vector (AV:N/AC:L/PR:N/UI:N/C:H/I:H/A:N, 9.1) confirms the attack is remote and requires no authentication or user interaction, making this a high-priority flaw; no public exploit code has been identified at time of analysis, and the issue is not listed in CISA KEV. Exploitation is limited to deployments that gate live views with HTTP-only Django authorization patterns - applications using djust's own transport-agnostic login_required, permission_required, or check_permissions attributes are unaffected.
Cross-site request forgery in djust's Server-Sent-Events transport affects all versions prior to 1.0.7 and allows a cross-origin attacker page to drive a victim's cookie-authenticated SSE session, firing state-changing LiveView event handlers as that victim. Remote attackers need no authentication of their own, but exploitation requires the victim to be lured to an attacker-controlled page while holding an active authenticated djust session and while the SSE transport is enabled (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N - integrity impact only, no confidentiality or availability impact). The flaw is fully fixed in 1.0.7 (Origin validated against ALLOWED_HOSTS with 403 for cross-origin requests, and POST endpoints now requiring Content-Type: application/json with 415 otherwise); no public exploit code was identified at time of analysis and the CVE has not been listed in CISA KEV.
Mass assignment in djust, a Django library providing Phoenix LiveView-style reactive server-side rendering, allows any client with an established WebSocket session to overwrite arbitrary public attributes on a LiveView instance through the framework's default `update_model` event handler. The handler ships in `djust.mixins.model_binding.ModelBindingMixin`, which sits in the LiveView base MRO and is therefore exposed by every view, and it `setattr`s a view attribute whose name is supplied entirely by the client - gated only by a 14-entry framework-internal denylist, an underscore-prefix rejection, and an opt-in `allowed_model_fields` allowlist that defaults to `None` (allow all). Affected deployments are djust versions prior to 1.0.7 that leave the allowlist unset and keep authorization, ownership, or business state such as `self.account_id`, `self.is_admin`, or `self.total_price` as public view attributes; the advisory's own reproducer set all three without any `dj-model` binding. Exploitation yields state tampering that can escalate to authorization-flag manipulation or IDOR when downstream handlers act on the tampered attributes without re-authorizing, giving a High integrity impact with no confidentiality or availability impact (assessed CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N); no public exploit code was identified at time of analysis and there is no CISA KEV entry, though the vendor retained a private reproducer.
Unauthenticated remote attackers can read live Django view and session state and invoke server-side handlers through djust's observability endpoints when a deployment leaves DEBUG enabled and omits the optional localhost-restriction middleware. The exposure requires that specific documented-but-misconfigured combination, which is why the assessed base score of 7.4 carries AC:H despite being network-reachable with PR:N - the endpoints themselves enforced only DEBUG prior to version 1.0.7. No public exploit code has been identified at time of analysis, and the flaw (CWE-306, missing authentication for critical function) is fully neutralized by upgrading to 1.0.7, by setting DEBUG=False, or by installing the localhost-gating middleware.
Server-side file-write and server-side request forgery (SSRF) in Django's GeoDjango spatial lookups expose authenticated staff users as an attack surface capable of writing arbitrary files to disk or issuing outbound network requests as the Django process user. Affected are Django 5.2 (before 5.2.17) and 6.0 (before 6.0.8), where the Django admin changelist's standard filter mechanism made the flaw reachable by any staff account holding view permissions on a model with a spatial field. Depending on the GDAL raster driver available on the server, file writes can escalate to remote code execution. No public exploit is identified at time of analysis; patched releases Django 5.2.17 and 6.0.8 were issued August 4, 2026.
Unbounded memory consumption in Django ASGI applications allows unauthenticated remote attackers to bypass DATA_UPLOAD_MAX_MEMORY_SIZE protections via malformed Content-Length headers, leading to denial of service. Affects Django 6.0 before 6.0.4, 5.2 before 5.2.13, and 4.2 before 4.2.30. CVSS 7.5 (High) with network-accessible, low-complexity attack vector requiring no privileges. EPSS data not available; no public exploit identified at time of analysis. Vendor patches released April 2026 across all affected major branches.
Unauthenticated attackers can bypass add permissions in Django GenericInlineModelAdmin (versions 6.0 <6.0.4, 5.2 <5.2.13, 4.2 <4.2.30) by submitting forged POST data to inline model forms. Permission checks fail to validate creation rights on inline model instances, enabling unauthorized database record insertion with network access alone. CVSS 9.8 critical severity reflects complete confidentiality, integrity, and availability impact. No public exploit identified at time of analysis. Low observed exploitation activity (EPSS 0.01%).
Header spoofing in Django 4.2 through 6.0 allows remote attackers to bypass security controls by exploiting ambiguous ASGI header normalization. The ASGIRequest handler incorrectly maps both hyphenated and underscored header variants to the same underscored version, enabling attackers to send conflicting headers where the malicious version overwrites legitimate security headers. Affects Django 6.0 before 6.0.4, 5.2 before 5.2.13, and 4.2 before 4.2.30. No public exploit identified at time of analysis. EPSS data not available, but the unauthenticated network attack vector and high integrity impact warrant immediate patching.
Unauthenticated attackers can enumerate workspace members and harvest sensitive information including email addresses, user roles, and internal identifiers from Plane prior to version 1.2.2 due to misconfigured Django REST Framework permissions. The vulnerability requires no authentication or user interaction and allows remote attackers to directly access protected endpoints over the network. No patch is currently available for affected Golang and Django deployments.
Django URL field validation triggers excessive Unicode normalization on Windows when processing certain malicious Unicode characters, enabling remote attackers to cause denial of service through crafted URL inputs. Affected versions include Django 6.0 before 6.0.3, 5.2 before 5.2.12, and 4.2 before 4.2.29, with potential impact to unsupported series 5.0.x, 4.1.x, and 3.2.x. A patch is available for all affected supported versions.
METIS WIC devices expose an unauthenticated /dbviewer/ endpoint that permits remote attackers to directly access and export internal SQLite databases containing sensitive operational telemetry. The affected Golang and Django applications run with debug mode enabled, causing error responses to leak backend source code, local file paths, and system configuration details. No patch is currently available.
JinJava template engine has a server-side template injection vulnerability enabling arbitrary code execution through crafted Jinja-style templates.
Django's HTML truncation functions (chars(), words(), and related template filters) are vulnerable to denial-of-service attacks when processing specially crafted inputs with excessive unmatched HTML end tags. Affected versions include Django 6.0 before 6.0.2, 5.2 before 5.2.11, 4.2 before 4.2.28, and potentially unsupported series 5.0.x, 4.1.x, and 3.2.x. Remote attackers can exploit this to cause service disruptions without requiring authentication or user interaction.
Tandoor Recipes instances running versions prior to 2.6.10 let any authenticated user infer sensitive database values - including password hashes, email addresses, and administrator status - by supplying crafted sort_order or order_field values that Django's ORM resolves as double-underscore foreign-key traversal paths during recipe search and RecipeBook ordering. The exposure is scored 6.5 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N, CWE-943), with confidentiality impact rated High but reach constrained by the need for valid credentials and the indirect, oracle-style nature of the leak. No public exploit code has been identified at time of analysis, and there is no confirmed active exploitation.
Information disclosure in Plane (open-source, self-hosted project management) before version 1.4.0 lets remote attackers probe the backend database schema and infer stored field values by manipulating the order_by query parameter, which is passed unsanitized into Django's order_by(). The only fully unauthenticated path runs through published public deploy boards handled by IssueListSpaceEndpoint; the other affected listing endpoints (cycles, modules, intake, notifications, projects, issue activity) require authenticated project access. No public exploit code has been identified at time of analysis and there is no KEV listing, but the upstream fix commit and pull request are publicly visible, so reverse-engineering is feasible; the issue is fixed in 1.4.0.
wger before 2.6 contains a CSRF bypass (CWE-352) that lets an attacker-controlled web page silently rebind an authenticated trainer's session to an arbitrary user account. Because the trainer_login view (wger/core/views/user.py, ~lines 161-210) accepts GET and calls django_login() directly, it falls outside Django's CsrfViewMiddleware enforcement, which only checks unsafe methods; a single <img> tag pointing at /en/user/<user_pk>/trainer-login forces the victim's browser to issue the request with the session cookie attached. Exploitation is authenticated (CVSS PR:L) and requires user interaction (UI:R) - the trainer must hold trainer privileges and be lured onto the malicious page - and, per the assessed vector, it depends on a non-trivial SameSite=Lax bypass via the view's ?next= 302 redirect chain, which raises attack complexity to AC:H and makes this a targeted rather than opportunistic or wormable issue. No CISA KEV listing or independent public exploit code was identified at time of analysis, though the vendor advisory documents a Playwright-verified reproduction in Chromium 147.
Authenticated users who are permitted to submit a Django model formset can delete database rows outside that formset's limiting queryset - without holding any permission on the targeted object - by forging management-form POST data when the affected model's primary key is editable through the form. The flaw is an authorization bypass through a user-controlled key (CWE-639) in django.forms.models.BaseModelFormSet.save_existing_objects(), rated CVSS 4.3 (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N) with integrity-only impact; it affects Django 6.1 before 6.1.2, 6.0 before 6.0.9, and 5.2 before 5.2.18, while models using the default AutoField/BigAutoField primary key are not affected. No public exploit code identified at time of analysis, and there is no confirmed active exploitation (not in CISA KEV); this is a genuinely moderate-severity authorization flaw and the signals are internally consistent.
Server-side request forgery (SSRF) in Django's GeoDjango spatial lookups allows remote unauthenticated attackers to make the Django process issue outbound network requests when an application passes attacker-controlled `bytes` raster values directly into a lookup against a `RasterField`. Affected versions are Django 6.1 before 6.1.2, 6.0 before 6.0.9, and 5.2 before 5.2.18; older unsupported series (5.1.x, 5.0.x, 4.2.x) were not evaluated and may also be affected. The flaw is an incomplete fix for CVE-2026-15307, and exploitation requires a deployment that uses GeoDjango raster fields and forwards raw untrusted bytes into spatial lookups - not a default Django configuration. There is no public exploit identified at time of analysis and the issue is not in CISA KEV; Django rates it 'moderate' severity (CVSS 5.3), with impact limited to attacker-directed outbound requests rather than data compromise or code execution.
Quadratic-time parsing of quoted HTTP header parameters in Django 5.2 (before 5.2.18), 6.0 (before 6.0.9), and 6.1 (before 6.1.2) allows unauthenticated remote clients to consume disproportionate CPU by supplying a header value containing many separator characters inside a quoted parameter, potentially degrading or exhausting worker capacity. The vulnerable code path is reached by default through content negotiation such as HttpRequest.accepts() and Accept/Content-Type header handling, and the existing per-call length limit does not bound the combined size of repeated headers, so an attacker can amplify the cost across many headers in a single request. Impact is availability-only (CVSS 5.3, A:L, CWE-407); vendor patches are available in Django 6.1.2, 6.0.9, and 5.2.18, and no public exploit code was identified at time of analysis.
Remote denial-of-service in the Django web framework's language-negotiation helper django.utils.translation.get_supported_language_variant(), which caches attacker-supplied language codes as keys in an in-memory LRU cache before enforcing a length limit. An unauthenticated remote attacker (CVSS:3.1/AV:N/AC:L/PR:N/UI:N) who can influence the negotiated language - typically via the Accept-Language header, a language URL prefix, or LocaleMiddleware - can send many distinct, very long language codes so that each becomes a unique cache entry and steadily consumes process memory, degrading or exhausting the application worker. Affected are Django 6.1 before 6.1.2, 6.0 before 6.0.9, and 5.2 before 5.2.18; unsupported earlier series such as 5.1.x, 5.0.x, and 4.2.x were not evaluated and may also be affected. Impact is limited to availability (A:L) and requires sustained request volume rather than a single request, and no public exploit code or confirmed active exploitation was identified at time of analysis.
Hard-coded JWT signing key in Lybbn Django-Vue-Lyadmin through version 3.2.12 allows remote attackers who know the publicly documented default SECRET_KEY in backend/application/settings.py to forge valid JSON Web Tokens, impersonating arbitrary users and bypassing authentication (CWE-321). Publicly available exploit code exists, but exposure is context-dependent: the maintainer states the key is documented and must be changed manually before deployment, so any instance that rotated SECRET_KEY to a private value is not affected. Our independent assessment rates this CVSS 3.1 9.1 (network-reachable, no authentication or user interaction required against an unremediated instance) versus the CVSS 4.0 5.5 recorded by VulDB, but the decisive limiting factor is operator configuration rather than attacker capability.
Cross-site request forgery in Horilla HR (horilla-hr) versions before 2.0.0 allows an unauthenticated attacker to silently approve pending attendance requests under a logged-in manager's identity, because the /attendance/approve-validate-attendance-request/ endpoint performed state-changing work (setting attendance_validated, is_validate_request_approved, approved_by and related pending-request flags, then calling attendance.save()) over an HTTP GET that Django's CSRF middleware never validates. The CVSS 3.1 assessment rates this AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N, i.e. a low-integrity-impact flaw that requires a manager holding attendance.change_attendance to be authenticated and tricked into visiting attacker-controlled content while that session is active; the attacker cannot choose the approving identity and the impact is bounded to what that victim manager could approve. Vendor-released patch: 2.0.0. No public exploit identified at time of analysis, and the flaw is not confirmed actively exploited (not in CISA KEV).
An authenticated user with a valid CSRF token can read Django password hashes, request metadata, and related-user attributes from Horilla HR/CRM mail-preview functionality in versions 1.0.0 through pre-1.6.0 and prior to 2.0.0. The get_mail_preview handlers at /recruitment/get-mail-preview/ and /employee/get-employee-mail-preview render a user-supplied mail body as a Django template while the full request object sits in the template context, so template attribute traversal such as request.user.password or request.META exposes the underlying data; the Django template sandbox limits this to information disclosure rather than code execution. Exploitation requires only a low-privileged authenticated session with a CSRF token (no public exploit identified at time of analysis), and the confidentiality impact is high because the leaked password hashes can be attacked offline or used to identify accounts for follow-on compromise; vendor fixes ship in 1.6.0 and 2.0.0.
Authenticated employees can read other employees' payroll records in Horilla HR 1.5.0-85 and earlier by substituting the emp_id, allowance_id, or deduction_id identifiers on the allowances_deductions_tab, view_single_allowance, and view_single_deduction endpoints in payroll/views/component_views.py. Exploitation requires only a valid logged-in account at any privilege level - no payroll-view permission and no ownership of the target record are needed - and exposes salary structures, allowance and deduction amounts, personal loan disbursements, and repayment schedules, making this a confidentiality-only disclosure flaw rated CVSS 6.5. There is no confirmed active exploitation (no CISA KEV listing) and no public exploit identified at time of analysis, but the absence of a complete fixed version leaves defenders with limited options.
Argument injection in Red Hat Ansible Automation Platform 2's automation-controller system-job subsystem allows an authenticated user with superuser privileges to inject arbitrary command-line arguments into the control-plane awx-manage process, gaining control of its argument vector and the first entry of its Python module search path. The root cause is that the system-job template launch endpoint stores a caller-supplied 'days' value without applying the integer validation used elsewhere for that field, and the dispatcher flattens the management-command argument list into a single space-delimited string that the job runner re-splits, so embedded spaces become additional arguments; system jobs run in-process on the control node without the container isolation applied to other job types. Confirmed remote code execution does not follow from the injected arguments alone - it would require an additional import gadget that is not present in the current management commands - so the demonstrated impact is argument injection and search-path control rather than code execution, and no public exploit was identified at time of analysis.
Server-side request forgery in Red Hat Ansible Automation Platform 2's automation-controller email notification backend lets an authenticated user holding organization notification-admin permission point an email notification template's SMTP host and port at arbitrary internal, loopback, link-local or reserved addresses; the controller task process then opens a raw TCP connection to that target when the notification test is triggered. Because the resulting connection error is surfaced through the notification record, an attacker gains a three-state internal port-scan oracle (open, closed, filtered) over the control-plane cluster network, including the in-cluster Kubernetes API, and if a shared organization template stores an SMTP password, redirecting the host can leak that credential to an attacker-controlled server. Impact is moderate (vendor CVSS 6.4, CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N) and requires a privileged, already-authenticated role rather than anonymous access; no public exploit code has been identified at time of analysis and CISA KEV does not list this CVE.
Secret values that playbook authors explicitly marked with no_log can be recovered from Red Hat Ansible Automation Platform 2 (automation-controller) through the REST filter backend, because the WorkflowJobNode.ancestor_artifacts column is not wrapped in prevent_search() and therefore remains queryable even though it is omitted from the API serializer. An authenticated user - one with only read access to a workflow, or any authenticated user with no roles at all by abusing a regular-expression lookup that bypasses the JSON cross-relation filter guard via the world-readable credential-types endpoint - can use the result count as a boolean/count oracle to extract secrets character by character, potentially across organizations. The issue is rated CVSS 6.5 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N, CWE-639); no public exploit code or confirmed active exploitation was identified at time of analysis, and because recovery requires an account plus many incremental requests per character, the practical risk is a bounded confidentiality exposure rather than a top-tier emergency.
Source-IP spoofing in Ansible Automation Platform 2's automation-controller allows an authenticated remote attacker to forge the client IP recorded in audit and access logs when the application runs its shipped production reverse-proxy configuration and trusts the client-supplied X-Forwarded-For header. The flaw is CWE-348 and only affects log integrity (CVSS 3.1 4.3, AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N), with no access, confidentiality, or availability gain. No public exploit identified at time of analysis and no confirmed active exploitation (CISA KEV).
Red Hat Ansible Automation Platform 2 (automation-controller) lets an unauthenticated remote attacker enumerate which Job Template and Workflow Job Template IDs have a Bitbucket Data Center webhook configured, by abusing an observable response discrepancy in the Bitbucket DC webhook receiver. For diagnostics:ping events the receiver performs the template lookup before HMAC signature verification is skipped, so the endpoint returns HTTP 200 for a template with a Bitbucket DC webhook and HTTP 403 otherwise - an oracle that requires neither authentication (PR:N in the assessed vector) nor knowledge of the secret webhook_key. Assessed at CVSS 5.3 (AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N), this is a low-impact information-disclosure and enumeration issue: no secrets, code execution, or elevated access are exposed; no public exploit identified at time of analysis and no confirmed actively exploited status.
TLS peer impersonation in Red Hat Ansible Automation Platform 2's automation-controller instance install-bundle endpoint lets an authenticated controller System Administrator obtain a mesh-CA-signed X.509 certificate that TLS peers will accept as a different control node. The flaw arises because a caller-chosen instance hostname is copied verbatim into the certificate's Common Name, DNS SAN, and receptor node-id, and the hostname charset validator is case-insensitive while the uniqueness validator is case-sensitive, so a case variant of an existing control node's hostname passes registration and yields a hard-coded ten-year, non-revocable mesh peer credential. Realizing the impact additionally requires an on-path/man-in-the-middle position on the receptor mesh, and the scenario is most meaningful in managed or hosted deployments where a customer holds controller superuser while the platform operator runs the mesh; there is no public exploit identified at time of analysis, and the flaw does not grant direct remote code execution because receptor work submission is gated by a separate signing key absent from the bundle.
Authenticated users of any privilege level on Red Hat Ansible Automation Platform 2 automation-controller deployments can extract other tenants' notification secrets-PagerDuty service keys and Slack, Mattermost, RocketChat, and generic Webhook bearer-token URLs-by abusing the API filter backend as a boolean count-oracle. The attack requires only a low-privilege account (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N, base 6.5), is network-reachable and low in complexity, and yields high confidentiality impact with no integrity or availability effect. Impact is greatest in multi-tenant installations where recovered secrets break organization isolation and permit notification-channel impersonation; exploitation is inherently slow, requiring many iterative requests that may be visible in API logs. No public exploit code has been identified at time of analysis, and the flaw is not listed as confirmed actively exploited (CISA KEV).
Information disclosure in the automation-controller API of Red Hat Ansible Automation Platform 2 lets any remote unauthenticated party read the automation mesh topology from the health-check endpoint /api/v2/ping/ (CVSS 3.1: 5.3, AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N). Because the ApiV2PingView view is declared with the AllowAny permission class and over-serializes RBAC-gated mesh data into its anonymous response, an attacker needs only network reachability to walk away with node hostnames, node types, UUIDs, heartbeats, capacities, exact software versions, instance-group names and membership, the deployment install UUID, and the identity of the active control node. The exposure is confidentiality-only - no secrets, credentials, or tenant data are involved - and there is no public exploit identified at time of analysis, so this is a genuine but modest reconnaissance-grade issue rather than an urgent one.
Information disclosure in Red Hat Ansible Automation Platform 2 allows an authenticated administrator (PR:H per the CVSS vector) to leak controller-side implementation details, including install paths, Python version, and source line numbers, into notification payloads delivered to an attacker-controlled webhook URL. A crafted Jinja notification template using a dynamic subscript such as job['job'+'_env'] slips past the static-Getattr AST whitelist, while a conditional gate like {% if job.id > 100 %} prevents the branch from firing during the small-job.id stub test-render, so the payload executes only against a real job whose exception produces a full traceback in the notification body. Impact is confined to low confidentiality loss (C:L) with no integrity or availability effect, and no public exploit has been identified at time of analysis.
An authenticated tenant superuser on Red Hat Ansible Automation Platform 2 can use the automation-controller API to confirm the existence of arbitrary absolute filesystem paths inside the controller-web pod, because StringListPathField.to_internal_value() calls os.path.exists() on unbounded user-supplied input and the 200-versus-400 response difference acts as an existence oracle. The issue is rated CVSS 4.1 (AV:N/AC:L/PR:H/UI:N/S:C/C:L/I:N/A:N) and only reads existence, not content, but it lets a tenant admin probe paths such as /etc/tower/SECRET_KEY, Kubernetes service-account tokens, receptor sockets and ConfigMap mount points. It is materially impactful only in managed AAP deployments (ansiblecloud.com) where the tenant administrator is not the host administrator; there is no public exploit identified at time of analysis and no vendor-released patch identified at time of analysis.
Information disclosure in the automation-controller component of Red Hat Ansible Automation Platform 2 lets any authenticated user of any privilege level extract internal database and ORM structure by sending crafted values through the host_filter query parameter of the Host list REST API. Because HostList.list() catches a bare Exception and returns str(e) verbatim, a malformed relation lookup such as credential__search=x raises a Django FieldError that exposes the complete Host model relation graph (including internal reverse accessors), while a malformed pattern such as name__regex=[bad raises a PostgreSQL DataError that reflects the raw database error string. The flaw is rated CVSS 4.3 (MEDIUM) with a vector of AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N; exploitation requires valid credentials but no user interaction, impact is limited to low-confidentiality schema and error-text leakage with no modification or code execution, and no public exploit was identified at time of analysis.
Authenticated users of Red Hat Ansible Automation Platform 2 can read sensitive commercial license metadata - account number, subscription ID, pool ID, SKU, support level, and instance counts - from the /api/v2/config/ endpoint, which is guarded only by Django REST Framework's IsAuthenticated permission class. The superuser/auditor gate that protects other configuration keys such as project_base_dir, project_local_paths, and custom_virtualenvs does not extend to the license_info block, so any logged-in account of any privilege level can retrieve it without user interaction or non-default configuration. Per the independent assessment this is a genuinely low-priority, information-disclosure issue (CVSS 4.3, PR:L) - no public exploit has been identified at time of analysis, and the practical risk is reconnaissance and social-engineering enablement against Red Hat support rather than direct compromise.
Chat-record management routes in 1Panel-dev MaxKB 2.10.2-lts and earlier authorize only the application_id supplied in the request path, then load chat data using globally scoped chat_id and chat_record_id values without confirming that the chat actually belongs to that application, so a low-privileged authenticated user in the same workspace can read a victim's persisted chat records by re-homing a known chat_id under an application they own. Impact is limited (CVSS 4.2, C:L/I:L), the attack is network-reachable but requires an authenticated normal account in the victim's workspace and prior knowledge or enumeration of valid global chat identifiers, which is the dominant practical hurdle. A second variant uses the add_knowledge flow, available to any user with an owned knowledge base and document, to copy victim answers while overwriting the victim record's improve_paragraph_id_list. No public exploit code has been identified at time of analysis and no fixed version was available as of review; despite the supplied 'Authentication Bypass' tag, this is an object-level authorization/IDOR defect rather than a true auth bypass.
Missing object-level authorization in MaxKB 2.10.2-lts and earlier lets an authenticated, non-privileged user of a workspace read another user's hidden MCP tool record - including the Tool.code field, which can embed MCP server configuration and headers - by requesting the tool-detail route with a known tool_id. The same weakness permits a secondary abuse path: a user who can create or edit their own workflow can reference the foreign mcp_tool_id in a workflow MCP node so that workflow debug executes with the victim's MCP configuration without any permission check. The flaw is confined to members of the same workspace and requires prior knowledge of a valid tool_id, and no public exploit identified at time of analysis; no fixed version is available as of this review.
MaxKB 2.10.2-lts and earlier accepts expired non-permanent ApplicationApiKey credentials on the /chat/api/mcp endpoint, allowing an authenticated attacker who already holds such a key secret to initialize the MCP interface, enumerate the published application's tool metadata, invoke tools/call, and persist application_chat and application_chat_record records - operations the standard /chat/api/open path refuses with the same key. The root cause is CWE-613 (Insufficient Session Expiration): the MCP authentication path validates only the key secret and its active flag while omitting the is_permanent and expire_time checks enforced elsewhere. This is a bounded credential-lifecycle bypass rather than unauthenticated access - the attacker must already possess a leaked, retained, or previously delegated key that is still marked active and past its expiry - and no public exploit has been identified at time of analysis, with no vendor-released patch identified at time of analysis.
InvenTree versions prior to 1.4.0 expose business data through the report and label print endpoints because POST /api/report/print/ and POST /api/report/label/print/ authenticate the caller but never invoke users.permissions.check_user_permission against the target model's view role. Any authenticated account - including one with no roles or only unrelated roles - can enumerate object primary keys and render them through the default templates InvenTree ships for major business models, then retrieve the resulting artifact from DataOutput, obtaining purchase, sales, part, bill-of-materials, stock, build, supplier, customer, pricing, and inventory data that the corresponding detail APIs would correctly deny. Fixed in 1.4.0; no public exploit code or confirmed active exploitation was identified at time of analysis, and the EPSS-style risk is modest because valid credentials are required and impact is limited to confidentiality (CVSS 4.3, CWE-639).
Unauthenticated information disclosure in InvenTree prior to 1.4.0 lets a remote caller retrieve plugin names, setting keys, descriptions, types, choices and non-secret configuration values through /api/plugin/settings/ and the per-plugin settings endpoints, because PluginSettingList, PluginAllSettingList and PluginSettingDetail registered GlobalSettingsPermissions without the IsAuthenticated permission used by equivalent global-settings endpoints. Exposure is confined to metadata and non-secret configuration: protected secret values remain masked as three asterisks, only safe methods are readable, and at least one plugin must be installed and active for the disclosure to be meaningful, so the practical impact is limited. The assessed CVSS 3.1 vector is AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N (score 5.3), confirming remote unauthenticated exploitation with low confidentiality impact and no integrity or availability effect; no public exploit identified at time of analysis.
Broken object-level authorization in InvenTree versions prior to 1.4.0 lets any authenticated user, including an account with no assigned roles, read the staged import data and column mappings belonging to another user's DataImportSession by supplying that session's identifier to the /api/importer/row/ or /api/importer/mapping/ endpoints. The impact is confidentiality-only (CVSS 4.4 base, assessed as 4.3: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N) and requires a valid login plus knowledge or enumeration of a victim's session ID on an instance where another user has an active import in progress; no public exploit code has been identified at time of analysis and the flaw is not confirmed actively exploited (CISA KEV). The vendor's threat model treats authenticated instance users as trusted, so the realistic exposure is between distrustful co-tenants of the same instance rather than remote outsiders, and version 1.4.0 resolves it.
InvenTree versions prior to 1.4.0 render report and label templates with WeasyPrint's default URL fetcher, so an authenticated staff user who can author templates can make the server fetch attacker-chosen resources over http/https or read local files through the file:// scheme and later recover the fetched bytes from the stored PDF attachment. This yields full-read server-side request forgery, local file disclosure (potentially including application credentials), and in the worst case compromise of a superuser account. The issue is access-gated and not a broad internet-facing threat: it requires staff-level template-authoring privileges (CVSS 3.1 AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:L/A:N, base 6.5) plus the ability to retrieve the generated attachment, and no public exploit has been identified at time of analysis. A vendor-released fix is available in InvenTree 1.4.0.
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.
Information disclosure in the djust Python WebSocket framework before 1.0.7 causes Django Model instances assigned to public (non-underscore) view attributes to be serialized to the browser with no sensitive-field denylist, exposing fields such as the password hash, is_staff/is_superuser privilege flags, tokens, and other PII inside the render payload sent to the client. Exploitation requires authenticated access to a view that assigns a full model to a public attribute (CVSS:3.1 AV:N/PR:L), and the resulting impact is confidentiality-only but rated High (C:H/I:N/A:N). No public exploit code has been identified at time of analysis and the issue is not listed in CISA KEV.
Stored and reflected cross-site scripting in djust (pip package djust) before 1.0.7 allows a javascript: URL supplied through user-controllable data to survive into the href/action attributes of built-in component template tags, executing script in a victim's authenticated browser session when the link is clicked. Only applications that bind untrusted URLs to components such as breadcrumb, dj_nav link/dropdown/brand, citation URL, cookie-consent privacy link, error-page action or form action are affected; default djust output is not exposed. The issue is developer-usage-conditional, the assessed vector is CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:C/C:L/I:L/A:N (user interaction required, low-privileged/authenticated injecting party), no public exploit identified at time of analysis, and the vendor fix is available in djust 1.0.7.
Stored cross-site scripting in Django admin's URLField rendering allows a malicious URL value (e.g., using a `javascript:` scheme) to be displayed as a clickable link on changelist views and read-only admin fields without scheme validation. Any application that accepts URLField input via public-facing forms and exposes those records in the Django admin is affected, covering Django 5.2 through the 6.1 release candidate. No public exploit or active exploitation (CISA KEV) has been identified at time of analysis; patches were released August 4, 2026 as Django 5.2.17 and 6.0.8.
Memory exhaustion in Django's `check_for_language()` function allows denial-of-service via the `set_language` view when it is explicitly enabled in URL configuration. Attackers can submit many distinct, very long language codes via POST requests, causing each code to be cached as an in-memory key and progressively consuming process memory. Django rates this severity 'low' because built-in guards - `DATA_UPLOAD_MAX_MEMORY_SIZE` and the cache's maximum entry count - bound the total exploitable memory; no public exploit identified at time of analysis.
Denial-of-service via recursive GEOMETRYCOLLECTION parsing crashes Django processes through a segmentation fault in the underlying GEOS library. Django's GEOSGeometry class, GeometryField form field, and spatial field lookups in versions 5.2, 6.0, 6.1 (RC), and main are all affected when processing WKT or WKB input containing deeply nested or excessively numerous GEOMETRYCOLLECTION objects. No public exploit code or active exploitation has been identified at time of analysis; the Django team rated this 'moderate' severity and issued fixed releases Django 5.2.17 and 6.0.8 on August 4, 2026.
Header injection in Django's DomainNameValidator allows network attackers to inject arbitrary HTTP response headers when applications pass validator-accepted domain values directly into HTTP responses, affecting Django 6.0 before 6.0.7 and 5.2 before 5.2.16. The validator silently accepts embedded newline characters in domain name strings, enabling HTTP response splitting that can facilitate session hijacking, open redirects, or cross-site scripting against end users. No public exploit code or CISA KEV listing exists at time of analysis; practical risk is narrowed significantly by Django's HttpResponse class independently rejecting newlines, meaning only non-standard code paths are exploitable.
Memory over-read in Django's GIS module allows unauthenticated remote attackers to potentially disclose adjacent heap memory or degrade service availability via a segmentation fault. The `django.contrib.gis.gdal.GDALRaster` class fails to correctly bound its read when constructed from a bytes object, exposing raw memory when the `vsi_buffer` property is subsequently accessed. Affects Django 6.0 before 6.0.7 and 5.2 before 5.2.16; no public exploit identified at time of analysis and not listed in CISA KEV.
Cache poisoning in Django's UpdateCacheMiddleware and cache_page() decorator exposes private user data to unauthenticated remote attackers by incorrectly serving cached responses across different cookie contexts. Versions 6.0 before 6.0.7 and 5.2 before 5.2.16 are confirmed affected; older unsupported branches (5.0.x, 4.1.x, 3.2.x) were not evaluated but may share the flaw. No public exploit or CISA KEV listing exists at time of analysis, and the low CVSS 4.0 score of 2.3 reflects meaningful preconditions, though the data-disclosure consequence for applications serving personalized, cookie-gated content through a shared cache is concrete.
Incorrect cache storage in Django's UpdateCacheMiddleware exposes responses that should have been excluded from caching due to uppercase or mixed-case Cache-Control directives (e.g., 'Private', 'NO-STORE'). Affected versions 5.2.x before 5.2.15 and 6.0.x before 6.0.6 fail to perform case-insensitive comparison of Cache-Control directive strings, causing the middleware to cache responses it should skip, which remote attackers can then retrieve. No public exploit has been identified at time of analysis, and active exploitation is not confirmed; the low CVSS 4.0 score of 2.3 accurately reflects limited scope, though real-world impact scales with how sensitive the incorrectly cached data is.
Django's SMTP email backend silently downgrades to cleartext transmission when a STARTTLS handshake fails under the `fail_silently=True` configuration, exposing email content to on-path network interception. Affected are Django 6.0.x before 6.0.6 and 5.2.x before 5.2.15; older unsupported series (5.0.x, 4.1.x, 3.2.x) were not evaluated but may also be vulnerable. No public exploit has been identified at time of analysis, and the CVSS 4.0 score of 2.3 reflects the high attack complexity and mandatory on-path network positioning required for exploitation.
Cookie context confusion in Django's signed cookie implementation allows a remote low-privileged attacker to substitute a cookie signed in one application context into a different context where a distinct (name, salt) pair produces the same concatenated string. Affected are Django 6.0 before 6.0.6 and Django 5.2 before 5.2.15; older unsupported series (5.0.x, 4.1.x, 3.2.x) were not evaluated but may also be affected. The real-world impact is limited to low-confidence data exposure (VC:L), with no public exploit identified at time of analysis, and the CVSS 4.0 score of 2.3 reflects a low-severity, contextually constrained flaw.
Cache-bypass information disclosure in Django's `has_vary_header()` utility allows remote attackers to read cached HTTP responses intended for other users by exploiting improper whitespace handling in `Vary` header comparisons. Affected versions are Django 5.2.x before 5.2.15 and 6.0.x before 6.0.6; earlier unsupported series (5.0.x, 4.1.x, 3.2.x) were not evaluated and may also be affected per the vendor. The CVSS 4.0 score of 2.3 reflects constrained real-world impact requiring both a non-default prerequisite condition and user interaction, with no public exploit or confirmed active exploitation identified at time of analysis.
Cache information disclosure in Django 5.2.x and 6.0.x allows remote unauthenticated attackers to read private authenticated responses served from shared caching layers. The `UpdateCacheMiddleware` component omits `Authorization` from the `Vary` response header when authenticated requests lack an explicit `Cache-Control: public` directive, causing caches to serve authenticated users' responses to subsequent unauthenticated requestors at the same URL. No public exploit has been identified at time of analysis, and the CVSS 4.0 score of 2.3 reflects meaningful - but constrained - real-world impact gated behind specific deployment prerequisites.
Django 6.0 before 6.0.5 and 5.2 before 5.2.14 fail to vary response headers on session cookies when SESSION_SAVE_EVERY_REQUEST is enabled but the session is unmodified, allowing remote attackers with user interaction to steal session tokens from cached public pages. The vulnerability affects server configurations that cache responses aggressively while maintaining per-request session handling, exposing authenticated users to session hijacking after visiting pages served from cache.
Django's UpdateCacheMiddleware incorrectly caches HTTP responses containing a Vary header with an asterisk value in versions 6.0 before 6.0.5 and 5.2 before 5.2.14, causing private user data to be cached and served to other users. The vulnerability has low confidentiality impact and requires user interaction (UI:P) combined with passive attack timing, making real-world exploitation dependent on specific cache timing conditions and application architecture.
Django 6.0 before 6.0.5 and 5.2 before 5.2.14 allow remote attackers to bypass the FILE_UPLOAD_MAX_MEMORY_SIZE limit by submitting ASGI requests with missing or understated Content-Length headers, potentially loading large files into memory and causing denial of service through resource exhaustion. No active exploitation confirmed, but the vulnerability requires only network access and no authentication, making it trivially exploitable once the bypass is understood.
Django's MultiPartParser allows authenticated remote attackers to cause denial of service through performance degradation by submitting multipart uploads with Content-Transfer-Encoding: base64 and excessive whitespace. Affected versions include Django 6.0 before 6.0.4, 5.2 before 5.2.13, and 4.2 before 4.2.30, with unsupported series 5.0.x, 4.1.x, and 3.2.x potentially also vulnerable. The vulnerability has a CVSS 6.5 score reflecting high availability impact but requires authentication (PR:L) and is not actively exploited or publicly weaponized at analysis time.
Django admin changelist forms with ModelAdmin.list_editable enabled allow high-privileged users to create new instances via forged POST requests, bypassing intended access controls. Affects Django 6.0 before 6.0.4, 5.2 before 5.2.13, and 4.2 before 4.2.30; unsupported versions 5.0.x, 4.1.x, and 3.2.x may also be vulnerable. The vulnerability requires admin-level privileges and results in unauthorized data modification rather than data exposure or availability impact. No public exploit code or active exploitation has been confirmed at time of analysis.
Stored XSS in Wagtail's simple_translation module allows authenticated admin users to inject malicious JavaScript through specially-crafted page titles that executes when other admins perform translation actions, potentially compromising their credentials. The vulnerability affects Wagtail versions prior to 6.3.8, 7.0.6, 7.2.3, and 7.3.1, and requires admin-level access to exploit, limiting exposure to internal threats. Patches are available for all affected versions.
Stored XSS in Wagtail's TableBlock allows authenticated users with page editing permissions to inject malicious class attributes that execute arbitrary JavaScript when pages are viewed by other users. An attacker could exploit this to perform administrative actions or steal credentials from higher-privileged users viewing the compromised content. The vulnerability affects Wagtail versions prior to 6.3.8, 7.0.6, 7.2.3, and 7.3.1, with patches now available.
Allauth versions up to 65.14.1 is affected by url redirection to untrusted site (open redirect) (CVSS 6.1).
An issue was discovered in 6.0 before 6.0.3, 5.2 before 5.2.12, and 4.2 before 4.2.29. [CVSS 3.7 LOW]
Wagtail is an open source content management system built on Django. [CVSS 2.7 LOW]
SQL injection in Django's QuerySet.order_by() method allows authenticated attackers to execute arbitrary SQL commands through specially crafted column aliases containing periods when used with FilteredRelation and dictionary expansion. This vulnerability affects Django versions 6.0 before 6.0.2, 5.2 before 5.2.11, and 4.2 before 4.2.28, with potentially older unsupported versions also impacted. Patches are available for all affected versions.
SQL injection via FilteredRelation column aliases in Django 4.2, 5.2, and 6.0 allows authenticated attackers to execute arbitrary SQL queries through crafted dictionary arguments in QuerySet methods like annotate() and aggregate(). An attacker with database access can exploit control characters in alias names to bypass input validation and potentially extract sensitive data or modify database contents. Patches are available for all affected versions, and unsupported Django releases may also be vulnerable.
SQL injection in Django's PostGIS RasterField lookups allows authenticated attackers to execute arbitrary SQL commands through the band index parameter in affected versions 6.0 before 6.0.2, 5.2 before 5.2.11, and 4.2 before 4.2.28. Unsupported Django series including 5.0.x, 4.1.x, and 3.2.x may also be vulnerable. A patch is available and authentication is required to exploit this vulnerability.
An issue was discovered in 6.0 before 6.0.2, 5.2 before 5.2.11, and 4.2 before 4.2.28. `ASGIRequest` allows a remote attacker to cause a potential denial-of-service via a crafted request with multiple duplicate headers. [CVSS 7.5 HIGH]
Django versions up to 6.0.2 contains a vulnerability that allows attackers to enumerate users via a timing attack (CVSS 5.3).
Authentication bypass in django-allauth versions before 65.13.0 allows an authenticated attacker with a valid Okta or NetIQ identity provider account to impersonate other users by modifying the mutable 'preferred_username' claim used as the account identifier, potentially leading to account takeover. This moderate-severity flaw (CWE-287) only affects deployments configured with these specific third-party login providers, and exploitation requires the attacker to be able to set or change their preferred_username value. No public exploit code or active exploitation has been identified at time of analysis; the vendor has released patch 65.13.0 which switches to the immutable 'sub' claim.
Deactivated django-allauth identity-provider accounts retain access to protected resources because OAuth2/OpenID Connect access and refresh tokens issued while the account was active were not rejected after the user was marked is_active=False. This affects django-allauth (allauth-django) releases before 65.13.0, but only deployments that use the built-in IdP feature and rely on is_active=False as their account-revocation mechanism. An authenticated holder of such a token (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N, base 5.4) can keep performing low-impact reads and writes through the IdP until the already-issued tokens expire; no public exploit code was identified at time of analysis and there is no indication of active exploitation. The issue is fixed in 65.13.0.
Brute-forceable magic-code email login in Plane versions prior to 1.4.0 allows unauthenticated remote attackers to guess a six-digit numeric login code and take over accounts. The verify endpoint extends django.views.View instead of DRF's APIView, so the configured AnonRateThrottle never runs, and there is no per-code attempt counter, no counter invalidation, and no Django-level throttle middleware behind it, leaving roughly 20 bits of OTP entropy with effectively unlimited guesses inside the code's Redis TTL window. There is no public exploit identified at time of analysis and no confirmed active exploitation, but the 9.1 CVSS reflects a full account takeover path (C:H/I:H) with no authentication or user interaction required, and the fix was released in Plane 1.4.0.
Plane's InstanceAdminSignUpEndpoint in versions 0.13 through pre-1.4.0 allows unauthenticated remote attackers to exploit a time-of-check time-of-use race during first-run setup and create a second instance administrator with full instance-admin authority alongside the legitimate operator. Exploitation requires that no instance administrator exists yet and that the attacker wins a concurrent-request race before the legitimate first admin is committed; after setup completes, the endpoint rejects new admins and the flaw is unreachable. No public exploit identified at time of analysis, and the risk is situational because the vulnerable window is brief and requires network reachability to the admin signup path.
Authenticated code injection in Horilla HR (horilla-hr) before 2.0.0 lets any user with access to the HorillaListView export functionality run arbitrary operating-system commands with the privileges of the application process - root, in the project's shipped horilla/horilla-hr Docker image. The issue is rated CVSS v3.1 8.8 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H): exploitable remotely over the network with low privileges, requiring only a valid account able to reach the list/export endpoint, with no user interaction and no non-default configuration. No public exploit code and no confirmed active exploitation were identified at time of analysis, and the vendor released a fix in version 2.0.0.
Command injection in the automation controller's external logging (rsyslog) configuration of Red Hat Ansible Automation Platform 2 allows a superuser to achieve arbitrary command execution inside the control-plane rsyslog component, exposing the controller SECRET_KEY and database credentials and enabling decryption of all stored credentials. Exploitation requires authenticated superuser privileges (CVSS 3.1 7.2, PR:H, no user interaction) and only takes effect when external logging is in use, so the malicious RainerScript configuration is actually generated and loaded. No public exploit code was identified and there is no CISA KEV listing indicating active exploitation, meaning real-world risk is strongly gated by the elevated privilege requirement even though the post-exploitation impact is a full control-plane compromise.
Missing authorization checks in the Red Hat Ansible Automation Platform 2 automation-controller allow an authenticated organization workflow-admin - a delegated, non-superuser role - to escalate into the control plane by copying a WorkflowJobTemplate and then launching jobs pinned to instance groups they hold no use_role on. The deep-copy permission sanitizer re-validates only the inventory, unified_job_template, and credentials of each cloned node, silently carrying over instance_groups, execution_environment, and labels, so the copier becomes administrator of a workflow that executes attacker-influenced automation in the control-plane execution context (CVSS 9.9, scope changed, high confidentiality, integrity, and availability impact). Exploitation is confirmed to require only a normal multi-tenant deployment plus workflow-admin rights; no public exploit code has been identified at time of analysis and there is no CISA KEV entry, and no vendor-released patch version was confirmed in the available intelligence.
Authenticated but low-privileged users of Red Hat Ansible Automation Platform 2 can bypass the automation-controller's sanitize_jinja() input-validation guard and have ansible-core evaluate attacker-supplied Jinja inside the execution environment, yielding arbitrary command execution and disclosure of secrets belonging to credentials the attacker cannot normally read. The flaw is exploitable remotely with no user interaction (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N per independent assessment) and requires only a controller account able to set one of the affected launch-time fields. No public exploit code has been identified at time of analysis, and the issue is not listed in CISA KEV; priority is bounded by the required authenticated foothold and the niche deployment footprint.
Remote code execution in Red Hat Ansible Automation Platform 2's automation-controller is possible when a privileged, authenticated user (CVSS PR:H) defines a custom Credential Type and abuses its environment-variable injector to set a process-hijacking loader variable such as BASH_ENV, ENV, LD_PRELOAD, LD_LIBRARY_PATH, PYTHONSTARTUP, or GIT_SSH_COMMAND, which the existing ANSIBLE_* prefix check and fixed ENV_BLOCKLIST fail to catch. Paired with the credential file injector, the attacker plants a script in the execution environment and points the loader variable at it, so arbitrary code executes inside the execution-environment container for any job that later attaches a credential of that type; this requires both the high privilege to author the credential type and a subsequent job consuming it. Red Hat's published CVSS of 7.6 (C:L/I:H/A:N) is lower than our independent assessment of the full vector (C:H/I:H/A:H), and because the vulnerable controller and the impacted execution-environment container are different security scopes, S:C applies. There is no CISA KEV listing and no public exploit identified at time of analysis.
Privilege escalation in Red Hat Ansible Automation Platform 2 (built on the AWX upstream project) lets an authenticated AAP platform administrator escape the container-group sandbox and obtain OpenShift namespace-level access, including the ability to read and exfiltrate namespace secrets. The flaw is reachable over the network (AV:N) with no user interaction (UI:N) and changes scope across the container/namespace boundary (S:C), but it is gated on the highest AAP privilege tier (PR:H), so it is an insider or compromised-admin scenario rather than an unauthenticated attack; only deployments that use container groups backed by OpenShift/Kubernetes are exposed. No public exploit code has been identified at time of analysis and the issue is not confirmed actively exploited (CISA KEV); no vendor-released patch has been identified at time of analysis, so mitigation depends on restricting the vulnerable field or the administrators who can reach it.
Stored cross-site scripting in the automation-controller component of Red Hat Ansible Automation Platform 2 lets an authenticated low-privileged user embed a javascript: hyperlink into job, ad hoc command, project update, or inventory update standard output, which is then rendered as a text/html link in the controller's stdout view. Because the HTML conversion escapes HTML metacharacters but never strips ANSI terminal escape sequences, an OSC 8 hyperlink becomes an unfiltered HTML anchor, and the response carries no Content-Security-Policy; a higher-privileged user (for example an administrator) who views that output page and clicks the link executes attacker-controlled JavaScript in their authenticated session, allowing actions up to full platform takeover. The vector is network-reachable with low privileges (CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:N, 8.7), but exploitation hinges on a privileged victim actively clicking the crafted link; no public exploit code and no confirmed active exploitation were identified at time of analysis.
Stored password survey answers in Red Hat Ansible Automation Platform 2's automation-controller can be recovered in plaintext by an authenticated user holding the delegated JobTemplate Admin role. The attacker tightens the minimum/maximum length constraint on a password-type survey question, then forces revalidation of a schedule or workflow job template node created by a higher-privileged user, causing the controller to decrypt the stored secret and embed it in the HTTP length-validation error response. No public exploit identified at time of analysis; exploitation is not unauthenticated (CVSS PR:L) and requires both the delegated role and an existing password-type survey value, making this a lateral, privilege-crossing credential-disclosure issue rather than a mass-exploitable perimeter break.
Privilege escalation and remote code execution on managed hosts is possible in Red Hat Ansible Automation Platform 2 because the automation-controller exposes the provisioning-callback secret (host_config_key) to anyone holding only read-level view_jobtemplate permission and accepts a client-supplied X-Forwarded-For header as proof of caller identity when the gateway proxy allow-list is empty. An attacker who reads the secret from the job template API representation or the activity stream and spoofs X-Forwarded-For to match any host in the target job template's inventory can launch that template against arbitrary managed hosts using the template's stored credentials; CVSS 3.1 base score is 9.9 (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H), no public exploit code was identified at time of analysis, and the decisive enabler is a non-default deployment condition - an empty proxy allow-list combined with provisioning callbacks actually being in use.
Command injection in MaxKB before 2.10.5-lts allows unauthenticated remote attackers to execute arbitrary shell commands when an assistant is configured with a tool, MCP tool, skill, or sub-application. Untrusted chat messages or ingested documents can coerce the LLM into invoking the un-gated `execute` shell tool, which lacks human approval and is exposed by the SandboxShellBackend. Both source deployments with MAXKB_SANDBOX disabled and the official root container's vulnerable gosu wrapper permit command execution outside the intended sandbox; no public exploit code or confirmed active exploitation was identified at time of analysis. A vendor patch is available in version 2.10.5-lts.
Cross-workspace read and modification of model parameter defaults in MaxKB 2.10.3-lts and earlier is possible for an authenticated user who holds model-read permission in a workspace they control, simply by supplying a model_id that belongs to a victim workspace. The model parameter form route checks authorization against the workspace in the URL path, but the underlying ModelSerializer.ModelParams fetches the Model by id alone without filtering on workspace_id, so the object-level check is bypassed (CWE-639, CVSS 3.1 base 7.4, AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:L). Impact is bounded: it is limited to reading or overwriting the victim's model_params_form, which can indirectly alter the default behavior of workflows that consume that model, and practical exploitation requires a multi-tenant deployment plus knowledge or guessing of a valid victim model_id; no public exploit identified at time of analysis and no fixed version is available as of this review.
Forged content modification in django-page-cms through 2.0.13 lets unauthenticated remote attackers exploit five CSRF-exempt admin mutation views in pages/admin/views.py to store unescaped page content that then renders to every site visitor as stored cross-site scripting. The attack is unauthenticated from the attacker's side (CVSS vectors list PR:N) but requires user interaction: an authenticated editor or admin must be lured to attacker-controlled HTML while holding an active CMS session (UI:P), so this is a genuine but conditional risk rather than a drop-everything emergency. No public exploit code and no confirmed active exploitation have been identified at time of analysis, and the secondary effects are bounded - the forged mutation only persists once a privileged victim's browser has sent the request successfully.
Unauthenticated arbitrary Python module import in djust before 1.0.7 lets any client that can reach the WebSocket or SSE mount endpoint force the server to import a module chosen by a client-supplied dotted path, executing that module's import-time side effects before any LiveView subclass check or per-view authentication occurs. The LIVEVIEW_ALLOWED_MODULES allowlist that should constrain this lookup is fail-open (the check is skipped when the setting is unset, which is the framework default) and uses loose startswith matching, so the flaw is reachable in a default configuration; the assessed vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. Impact is bounded by what is already installed and importable on the host: guaranteed outcomes are denial of service (import bombs, expensive dependency trees) and a module/class enumeration oracle exposed through distinct error strings, escalating to RCE-by-proxy where a suitably side-effectful module exists. No public exploit has been identified at time of analysis - the maintainer retains the reproducer privately - and there is no CISA KEV listing.
Broken object-level access control in djust before 1.0.7 lets an authenticated user view - and on some paths act on - object-scoped views they are not authorized for, by loading the page via a direct HTTP GET, navigating to it through SPA url_change, or embedding it as a {% live_render %} child (eager or lazy). The flaw exists because per-object authorization (get_object plus has_object_permission, ADR-017) was enforced only on the WebSocket mount and event paths, leaving these three render entry points unchecked; views that do not define a custom get_object are unaffected. Exploitation requires a valid account (CVSS PR:L), knowledge or enumeration of the target object identifier, and a djust deployment older than 1.0.7 that exposes an object-scoped view through any of those paths, giving high confidentiality impact with limited integrity impact (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N, score 7.1); no public exploit code was identified at time of analysis and CISA KEV does not list this issue.
An authentication/authorization bypass in the djust Python live-view framework (versions prior to 1.0.7) lets unauthenticated remote attackers mount any view over the WebSocket/SSE transport even when that view is protected by standard Django guards such as LoginRequiredMixin, PermissionRequiredMixin, UserPassesTestMixin, @method_decorator(login_required, name="dispatch"), a custom dispatch() override, or the djust admin extension's staff gate. Because djust authorizes WebSocket mounts through its own check_view_auth helper instead of Django's View.dispatch() chain, those HTTP-only guards are enforced on the initial GET but silently skipped where all events and application state actually flow, so an anonymous or under-privileged client can invoke handlers - including admin list, create, change, and delete operations. The CVSS vector (AV:N/AC:L/PR:N/UI:N/C:H/I:H/A:N, 9.1) confirms the attack is remote and requires no authentication or user interaction, making this a high-priority flaw; no public exploit code has been identified at time of analysis, and the issue is not listed in CISA KEV. Exploitation is limited to deployments that gate live views with HTTP-only Django authorization patterns - applications using djust's own transport-agnostic login_required, permission_required, or check_permissions attributes are unaffected.
Cross-site request forgery in djust's Server-Sent-Events transport affects all versions prior to 1.0.7 and allows a cross-origin attacker page to drive a victim's cookie-authenticated SSE session, firing state-changing LiveView event handlers as that victim. Remote attackers need no authentication of their own, but exploitation requires the victim to be lured to an attacker-controlled page while holding an active authenticated djust session and while the SSE transport is enabled (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N - integrity impact only, no confidentiality or availability impact). The flaw is fully fixed in 1.0.7 (Origin validated against ALLOWED_HOSTS with 403 for cross-origin requests, and POST endpoints now requiring Content-Type: application/json with 415 otherwise); no public exploit code was identified at time of analysis and the CVE has not been listed in CISA KEV.
Mass assignment in djust, a Django library providing Phoenix LiveView-style reactive server-side rendering, allows any client with an established WebSocket session to overwrite arbitrary public attributes on a LiveView instance through the framework's default `update_model` event handler. The handler ships in `djust.mixins.model_binding.ModelBindingMixin`, which sits in the LiveView base MRO and is therefore exposed by every view, and it `setattr`s a view attribute whose name is supplied entirely by the client - gated only by a 14-entry framework-internal denylist, an underscore-prefix rejection, and an opt-in `allowed_model_fields` allowlist that defaults to `None` (allow all). Affected deployments are djust versions prior to 1.0.7 that leave the allowlist unset and keep authorization, ownership, or business state such as `self.account_id`, `self.is_admin`, or `self.total_price` as public view attributes; the advisory's own reproducer set all three without any `dj-model` binding. Exploitation yields state tampering that can escalate to authorization-flag manipulation or IDOR when downstream handlers act on the tampered attributes without re-authorizing, giving a High integrity impact with no confidentiality or availability impact (assessed CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N); no public exploit code was identified at time of analysis and there is no CISA KEV entry, though the vendor retained a private reproducer.
Unauthenticated remote attackers can read live Django view and session state and invoke server-side handlers through djust's observability endpoints when a deployment leaves DEBUG enabled and omits the optional localhost-restriction middleware. The exposure requires that specific documented-but-misconfigured combination, which is why the assessed base score of 7.4 carries AC:H despite being network-reachable with PR:N - the endpoints themselves enforced only DEBUG prior to version 1.0.7. No public exploit code has been identified at time of analysis, and the flaw (CWE-306, missing authentication for critical function) is fully neutralized by upgrading to 1.0.7, by setting DEBUG=False, or by installing the localhost-gating middleware.
Server-side file-write and server-side request forgery (SSRF) in Django's GeoDjango spatial lookups expose authenticated staff users as an attack surface capable of writing arbitrary files to disk or issuing outbound network requests as the Django process user. Affected are Django 5.2 (before 5.2.17) and 6.0 (before 6.0.8), where the Django admin changelist's standard filter mechanism made the flaw reachable by any staff account holding view permissions on a model with a spatial field. Depending on the GDAL raster driver available on the server, file writes can escalate to remote code execution. No public exploit is identified at time of analysis; patched releases Django 5.2.17 and 6.0.8 were issued August 4, 2026.
Unbounded memory consumption in Django ASGI applications allows unauthenticated remote attackers to bypass DATA_UPLOAD_MAX_MEMORY_SIZE protections via malformed Content-Length headers, leading to denial of service. Affects Django 6.0 before 6.0.4, 5.2 before 5.2.13, and 4.2 before 4.2.30. CVSS 7.5 (High) with network-accessible, low-complexity attack vector requiring no privileges. EPSS data not available; no public exploit identified at time of analysis. Vendor patches released April 2026 across all affected major branches.
Unauthenticated attackers can bypass add permissions in Django GenericInlineModelAdmin (versions 6.0 <6.0.4, 5.2 <5.2.13, 4.2 <4.2.30) by submitting forged POST data to inline model forms. Permission checks fail to validate creation rights on inline model instances, enabling unauthorized database record insertion with network access alone. CVSS 9.8 critical severity reflects complete confidentiality, integrity, and availability impact. No public exploit identified at time of analysis. Low observed exploitation activity (EPSS 0.01%).
Header spoofing in Django 4.2 through 6.0 allows remote attackers to bypass security controls by exploiting ambiguous ASGI header normalization. The ASGIRequest handler incorrectly maps both hyphenated and underscored header variants to the same underscored version, enabling attackers to send conflicting headers where the malicious version overwrites legitimate security headers. Affects Django 6.0 before 6.0.4, 5.2 before 5.2.13, and 4.2 before 4.2.30. No public exploit identified at time of analysis. EPSS data not available, but the unauthenticated network attack vector and high integrity impact warrant immediate patching.
Unauthenticated attackers can enumerate workspace members and harvest sensitive information including email addresses, user roles, and internal identifiers from Plane prior to version 1.2.2 due to misconfigured Django REST Framework permissions. The vulnerability requires no authentication or user interaction and allows remote attackers to directly access protected endpoints over the network. No patch is currently available for affected Golang and Django deployments.
Django URL field validation triggers excessive Unicode normalization on Windows when processing certain malicious Unicode characters, enabling remote attackers to cause denial of service through crafted URL inputs. Affected versions include Django 6.0 before 6.0.3, 5.2 before 5.2.12, and 4.2 before 4.2.29, with potential impact to unsupported series 5.0.x, 4.1.x, and 3.2.x. A patch is available for all affected supported versions.
METIS WIC devices expose an unauthenticated /dbviewer/ endpoint that permits remote attackers to directly access and export internal SQLite databases containing sensitive operational telemetry. The affected Golang and Django applications run with debug mode enabled, causing error responses to leak backend source code, local file paths, and system configuration details. No patch is currently available.
JinJava template engine has a server-side template injection vulnerability enabling arbitrary code execution through crafted Jinja-style templates.
Django's HTML truncation functions (chars(), words(), and related template filters) are vulnerable to denial-of-service attacks when processing specially crafted inputs with excessive unmatched HTML end tags. Affected versions include Django 6.0 before 6.0.2, 5.2 before 5.2.11, 4.2 before 4.2.28, and potentially unsupported series 5.0.x, 4.1.x, and 3.2.x. Remote attackers can exploit this to cause service disruptions without requiring authentication or user interaction.
Tandoor Recipes instances running versions prior to 2.6.10 let any authenticated user infer sensitive database values - including password hashes, email addresses, and administrator status - by supplying crafted sort_order or order_field values that Django's ORM resolves as double-underscore foreign-key traversal paths during recipe search and RecipeBook ordering. The exposure is scored 6.5 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N, CWE-943), with confidentiality impact rated High but reach constrained by the need for valid credentials and the indirect, oracle-style nature of the leak. No public exploit code has been identified at time of analysis, and there is no confirmed active exploitation.
Information disclosure in Plane (open-source, self-hosted project management) before version 1.4.0 lets remote attackers probe the backend database schema and infer stored field values by manipulating the order_by query parameter, which is passed unsanitized into Django's order_by(). The only fully unauthenticated path runs through published public deploy boards handled by IssueListSpaceEndpoint; the other affected listing endpoints (cycles, modules, intake, notifications, projects, issue activity) require authenticated project access. No public exploit code has been identified at time of analysis and there is no KEV listing, but the upstream fix commit and pull request are publicly visible, so reverse-engineering is feasible; the issue is fixed in 1.4.0.
wger before 2.6 contains a CSRF bypass (CWE-352) that lets an attacker-controlled web page silently rebind an authenticated trainer's session to an arbitrary user account. Because the trainer_login view (wger/core/views/user.py, ~lines 161-210) accepts GET and calls django_login() directly, it falls outside Django's CsrfViewMiddleware enforcement, which only checks unsafe methods; a single <img> tag pointing at /en/user/<user_pk>/trainer-login forces the victim's browser to issue the request with the session cookie attached. Exploitation is authenticated (CVSS PR:L) and requires user interaction (UI:R) - the trainer must hold trainer privileges and be lured onto the malicious page - and, per the assessed vector, it depends on a non-trivial SameSite=Lax bypass via the view's ?next= 302 redirect chain, which raises attack complexity to AC:H and makes this a targeted rather than opportunistic or wormable issue. No CISA KEV listing or independent public exploit code was identified at time of analysis, though the vendor advisory documents a Playwright-verified reproduction in Chromium 147.
Authenticated users who are permitted to submit a Django model formset can delete database rows outside that formset's limiting queryset - without holding any permission on the targeted object - by forging management-form POST data when the affected model's primary key is editable through the form. The flaw is an authorization bypass through a user-controlled key (CWE-639) in django.forms.models.BaseModelFormSet.save_existing_objects(), rated CVSS 4.3 (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N) with integrity-only impact; it affects Django 6.1 before 6.1.2, 6.0 before 6.0.9, and 5.2 before 5.2.18, while models using the default AutoField/BigAutoField primary key are not affected. No public exploit code identified at time of analysis, and there is no confirmed active exploitation (not in CISA KEV); this is a genuinely moderate-severity authorization flaw and the signals are internally consistent.
Server-side request forgery (SSRF) in Django's GeoDjango spatial lookups allows remote unauthenticated attackers to make the Django process issue outbound network requests when an application passes attacker-controlled `bytes` raster values directly into a lookup against a `RasterField`. Affected versions are Django 6.1 before 6.1.2, 6.0 before 6.0.9, and 5.2 before 5.2.18; older unsupported series (5.1.x, 5.0.x, 4.2.x) were not evaluated and may also be affected. The flaw is an incomplete fix for CVE-2026-15307, and exploitation requires a deployment that uses GeoDjango raster fields and forwards raw untrusted bytes into spatial lookups - not a default Django configuration. There is no public exploit identified at time of analysis and the issue is not in CISA KEV; Django rates it 'moderate' severity (CVSS 5.3), with impact limited to attacker-directed outbound requests rather than data compromise or code execution.
Quadratic-time parsing of quoted HTTP header parameters in Django 5.2 (before 5.2.18), 6.0 (before 6.0.9), and 6.1 (before 6.1.2) allows unauthenticated remote clients to consume disproportionate CPU by supplying a header value containing many separator characters inside a quoted parameter, potentially degrading or exhausting worker capacity. The vulnerable code path is reached by default through content negotiation such as HttpRequest.accepts() and Accept/Content-Type header handling, and the existing per-call length limit does not bound the combined size of repeated headers, so an attacker can amplify the cost across many headers in a single request. Impact is availability-only (CVSS 5.3, A:L, CWE-407); vendor patches are available in Django 6.1.2, 6.0.9, and 5.2.18, and no public exploit code was identified at time of analysis.
Remote denial-of-service in the Django web framework's language-negotiation helper django.utils.translation.get_supported_language_variant(), which caches attacker-supplied language codes as keys in an in-memory LRU cache before enforcing a length limit. An unauthenticated remote attacker (CVSS:3.1/AV:N/AC:L/PR:N/UI:N) who can influence the negotiated language - typically via the Accept-Language header, a language URL prefix, or LocaleMiddleware - can send many distinct, very long language codes so that each becomes a unique cache entry and steadily consumes process memory, degrading or exhausting the application worker. Affected are Django 6.1 before 6.1.2, 6.0 before 6.0.9, and 5.2 before 5.2.18; unsupported earlier series such as 5.1.x, 5.0.x, and 4.2.x were not evaluated and may also be affected. Impact is limited to availability (A:L) and requires sustained request volume rather than a single request, and no public exploit code or confirmed active exploitation was identified at time of analysis.
Hard-coded JWT signing key in Lybbn Django-Vue-Lyadmin through version 3.2.12 allows remote attackers who know the publicly documented default SECRET_KEY in backend/application/settings.py to forge valid JSON Web Tokens, impersonating arbitrary users and bypassing authentication (CWE-321). Publicly available exploit code exists, but exposure is context-dependent: the maintainer states the key is documented and must be changed manually before deployment, so any instance that rotated SECRET_KEY to a private value is not affected. Our independent assessment rates this CVSS 3.1 9.1 (network-reachable, no authentication or user interaction required against an unremediated instance) versus the CVSS 4.0 5.5 recorded by VulDB, but the decisive limiting factor is operator configuration rather than attacker capability.
Cross-site request forgery in Horilla HR (horilla-hr) versions before 2.0.0 allows an unauthenticated attacker to silently approve pending attendance requests under a logged-in manager's identity, because the /attendance/approve-validate-attendance-request/ endpoint performed state-changing work (setting attendance_validated, is_validate_request_approved, approved_by and related pending-request flags, then calling attendance.save()) over an HTTP GET that Django's CSRF middleware never validates. The CVSS 3.1 assessment rates this AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N, i.e. a low-integrity-impact flaw that requires a manager holding attendance.change_attendance to be authenticated and tricked into visiting attacker-controlled content while that session is active; the attacker cannot choose the approving identity and the impact is bounded to what that victim manager could approve. Vendor-released patch: 2.0.0. No public exploit identified at time of analysis, and the flaw is not confirmed actively exploited (not in CISA KEV).
An authenticated user with a valid CSRF token can read Django password hashes, request metadata, and related-user attributes from Horilla HR/CRM mail-preview functionality in versions 1.0.0 through pre-1.6.0 and prior to 2.0.0. The get_mail_preview handlers at /recruitment/get-mail-preview/ and /employee/get-employee-mail-preview render a user-supplied mail body as a Django template while the full request object sits in the template context, so template attribute traversal such as request.user.password or request.META exposes the underlying data; the Django template sandbox limits this to information disclosure rather than code execution. Exploitation requires only a low-privileged authenticated session with a CSRF token (no public exploit identified at time of analysis), and the confidentiality impact is high because the leaked password hashes can be attacked offline or used to identify accounts for follow-on compromise; vendor fixes ship in 1.6.0 and 2.0.0.
Authenticated employees can read other employees' payroll records in Horilla HR 1.5.0-85 and earlier by substituting the emp_id, allowance_id, or deduction_id identifiers on the allowances_deductions_tab, view_single_allowance, and view_single_deduction endpoints in payroll/views/component_views.py. Exploitation requires only a valid logged-in account at any privilege level - no payroll-view permission and no ownership of the target record are needed - and exposes salary structures, allowance and deduction amounts, personal loan disbursements, and repayment schedules, making this a confidentiality-only disclosure flaw rated CVSS 6.5. There is no confirmed active exploitation (no CISA KEV listing) and no public exploit identified at time of analysis, but the absence of a complete fixed version leaves defenders with limited options.
Argument injection in Red Hat Ansible Automation Platform 2's automation-controller system-job subsystem allows an authenticated user with superuser privileges to inject arbitrary command-line arguments into the control-plane awx-manage process, gaining control of its argument vector and the first entry of its Python module search path. The root cause is that the system-job template launch endpoint stores a caller-supplied 'days' value without applying the integer validation used elsewhere for that field, and the dispatcher flattens the management-command argument list into a single space-delimited string that the job runner re-splits, so embedded spaces become additional arguments; system jobs run in-process on the control node without the container isolation applied to other job types. Confirmed remote code execution does not follow from the injected arguments alone - it would require an additional import gadget that is not present in the current management commands - so the demonstrated impact is argument injection and search-path control rather than code execution, and no public exploit was identified at time of analysis.
Server-side request forgery in Red Hat Ansible Automation Platform 2's automation-controller email notification backend lets an authenticated user holding organization notification-admin permission point an email notification template's SMTP host and port at arbitrary internal, loopback, link-local or reserved addresses; the controller task process then opens a raw TCP connection to that target when the notification test is triggered. Because the resulting connection error is surfaced through the notification record, an attacker gains a three-state internal port-scan oracle (open, closed, filtered) over the control-plane cluster network, including the in-cluster Kubernetes API, and if a shared organization template stores an SMTP password, redirecting the host can leak that credential to an attacker-controlled server. Impact is moderate (vendor CVSS 6.4, CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N) and requires a privileged, already-authenticated role rather than anonymous access; no public exploit code has been identified at time of analysis and CISA KEV does not list this CVE.
Secret values that playbook authors explicitly marked with no_log can be recovered from Red Hat Ansible Automation Platform 2 (automation-controller) through the REST filter backend, because the WorkflowJobNode.ancestor_artifacts column is not wrapped in prevent_search() and therefore remains queryable even though it is omitted from the API serializer. An authenticated user - one with only read access to a workflow, or any authenticated user with no roles at all by abusing a regular-expression lookup that bypasses the JSON cross-relation filter guard via the world-readable credential-types endpoint - can use the result count as a boolean/count oracle to extract secrets character by character, potentially across organizations. The issue is rated CVSS 6.5 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N, CWE-639); no public exploit code or confirmed active exploitation was identified at time of analysis, and because recovery requires an account plus many incremental requests per character, the practical risk is a bounded confidentiality exposure rather than a top-tier emergency.
Source-IP spoofing in Ansible Automation Platform 2's automation-controller allows an authenticated remote attacker to forge the client IP recorded in audit and access logs when the application runs its shipped production reverse-proxy configuration and trusts the client-supplied X-Forwarded-For header. The flaw is CWE-348 and only affects log integrity (CVSS 3.1 4.3, AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N), with no access, confidentiality, or availability gain. No public exploit identified at time of analysis and no confirmed active exploitation (CISA KEV).
Red Hat Ansible Automation Platform 2 (automation-controller) lets an unauthenticated remote attacker enumerate which Job Template and Workflow Job Template IDs have a Bitbucket Data Center webhook configured, by abusing an observable response discrepancy in the Bitbucket DC webhook receiver. For diagnostics:ping events the receiver performs the template lookup before HMAC signature verification is skipped, so the endpoint returns HTTP 200 for a template with a Bitbucket DC webhook and HTTP 403 otherwise - an oracle that requires neither authentication (PR:N in the assessed vector) nor knowledge of the secret webhook_key. Assessed at CVSS 5.3 (AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N), this is a low-impact information-disclosure and enumeration issue: no secrets, code execution, or elevated access are exposed; no public exploit identified at time of analysis and no confirmed actively exploited status.
TLS peer impersonation in Red Hat Ansible Automation Platform 2's automation-controller instance install-bundle endpoint lets an authenticated controller System Administrator obtain a mesh-CA-signed X.509 certificate that TLS peers will accept as a different control node. The flaw arises because a caller-chosen instance hostname is copied verbatim into the certificate's Common Name, DNS SAN, and receptor node-id, and the hostname charset validator is case-insensitive while the uniqueness validator is case-sensitive, so a case variant of an existing control node's hostname passes registration and yields a hard-coded ten-year, non-revocable mesh peer credential. Realizing the impact additionally requires an on-path/man-in-the-middle position on the receptor mesh, and the scenario is most meaningful in managed or hosted deployments where a customer holds controller superuser while the platform operator runs the mesh; there is no public exploit identified at time of analysis, and the flaw does not grant direct remote code execution because receptor work submission is gated by a separate signing key absent from the bundle.
Authenticated users of any privilege level on Red Hat Ansible Automation Platform 2 automation-controller deployments can extract other tenants' notification secrets-PagerDuty service keys and Slack, Mattermost, RocketChat, and generic Webhook bearer-token URLs-by abusing the API filter backend as a boolean count-oracle. The attack requires only a low-privilege account (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N, base 6.5), is network-reachable and low in complexity, and yields high confidentiality impact with no integrity or availability effect. Impact is greatest in multi-tenant installations where recovered secrets break organization isolation and permit notification-channel impersonation; exploitation is inherently slow, requiring many iterative requests that may be visible in API logs. No public exploit code has been identified at time of analysis, and the flaw is not listed as confirmed actively exploited (CISA KEV).
Information disclosure in the automation-controller API of Red Hat Ansible Automation Platform 2 lets any remote unauthenticated party read the automation mesh topology from the health-check endpoint /api/v2/ping/ (CVSS 3.1: 5.3, AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N). Because the ApiV2PingView view is declared with the AllowAny permission class and over-serializes RBAC-gated mesh data into its anonymous response, an attacker needs only network reachability to walk away with node hostnames, node types, UUIDs, heartbeats, capacities, exact software versions, instance-group names and membership, the deployment install UUID, and the identity of the active control node. The exposure is confidentiality-only - no secrets, credentials, or tenant data are involved - and there is no public exploit identified at time of analysis, so this is a genuine but modest reconnaissance-grade issue rather than an urgent one.
Information disclosure in Red Hat Ansible Automation Platform 2 allows an authenticated administrator (PR:H per the CVSS vector) to leak controller-side implementation details, including install paths, Python version, and source line numbers, into notification payloads delivered to an attacker-controlled webhook URL. A crafted Jinja notification template using a dynamic subscript such as job['job'+'_env'] slips past the static-Getattr AST whitelist, while a conditional gate like {% if job.id > 100 %} prevents the branch from firing during the small-job.id stub test-render, so the payload executes only against a real job whose exception produces a full traceback in the notification body. Impact is confined to low confidentiality loss (C:L) with no integrity or availability effect, and no public exploit has been identified at time of analysis.
An authenticated tenant superuser on Red Hat Ansible Automation Platform 2 can use the automation-controller API to confirm the existence of arbitrary absolute filesystem paths inside the controller-web pod, because StringListPathField.to_internal_value() calls os.path.exists() on unbounded user-supplied input and the 200-versus-400 response difference acts as an existence oracle. The issue is rated CVSS 4.1 (AV:N/AC:L/PR:H/UI:N/S:C/C:L/I:N/A:N) and only reads existence, not content, but it lets a tenant admin probe paths such as /etc/tower/SECRET_KEY, Kubernetes service-account tokens, receptor sockets and ConfigMap mount points. It is materially impactful only in managed AAP deployments (ansiblecloud.com) where the tenant administrator is not the host administrator; there is no public exploit identified at time of analysis and no vendor-released patch identified at time of analysis.
Information disclosure in the automation-controller component of Red Hat Ansible Automation Platform 2 lets any authenticated user of any privilege level extract internal database and ORM structure by sending crafted values through the host_filter query parameter of the Host list REST API. Because HostList.list() catches a bare Exception and returns str(e) verbatim, a malformed relation lookup such as credential__search=x raises a Django FieldError that exposes the complete Host model relation graph (including internal reverse accessors), while a malformed pattern such as name__regex=[bad raises a PostgreSQL DataError that reflects the raw database error string. The flaw is rated CVSS 4.3 (MEDIUM) with a vector of AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N; exploitation requires valid credentials but no user interaction, impact is limited to low-confidentiality schema and error-text leakage with no modification or code execution, and no public exploit was identified at time of analysis.
Authenticated users of Red Hat Ansible Automation Platform 2 can read sensitive commercial license metadata - account number, subscription ID, pool ID, SKU, support level, and instance counts - from the /api/v2/config/ endpoint, which is guarded only by Django REST Framework's IsAuthenticated permission class. The superuser/auditor gate that protects other configuration keys such as project_base_dir, project_local_paths, and custom_virtualenvs does not extend to the license_info block, so any logged-in account of any privilege level can retrieve it without user interaction or non-default configuration. Per the independent assessment this is a genuinely low-priority, information-disclosure issue (CVSS 4.3, PR:L) - no public exploit has been identified at time of analysis, and the practical risk is reconnaissance and social-engineering enablement against Red Hat support rather than direct compromise.
Chat-record management routes in 1Panel-dev MaxKB 2.10.2-lts and earlier authorize only the application_id supplied in the request path, then load chat data using globally scoped chat_id and chat_record_id values without confirming that the chat actually belongs to that application, so a low-privileged authenticated user in the same workspace can read a victim's persisted chat records by re-homing a known chat_id under an application they own. Impact is limited (CVSS 4.2, C:L/I:L), the attack is network-reachable but requires an authenticated normal account in the victim's workspace and prior knowledge or enumeration of valid global chat identifiers, which is the dominant practical hurdle. A second variant uses the add_knowledge flow, available to any user with an owned knowledge base and document, to copy victim answers while overwriting the victim record's improve_paragraph_id_list. No public exploit code has been identified at time of analysis and no fixed version was available as of review; despite the supplied 'Authentication Bypass' tag, this is an object-level authorization/IDOR defect rather than a true auth bypass.
Missing object-level authorization in MaxKB 2.10.2-lts and earlier lets an authenticated, non-privileged user of a workspace read another user's hidden MCP tool record - including the Tool.code field, which can embed MCP server configuration and headers - by requesting the tool-detail route with a known tool_id. The same weakness permits a secondary abuse path: a user who can create or edit their own workflow can reference the foreign mcp_tool_id in a workflow MCP node so that workflow debug executes with the victim's MCP configuration without any permission check. The flaw is confined to members of the same workspace and requires prior knowledge of a valid tool_id, and no public exploit identified at time of analysis; no fixed version is available as of this review.
MaxKB 2.10.2-lts and earlier accepts expired non-permanent ApplicationApiKey credentials on the /chat/api/mcp endpoint, allowing an authenticated attacker who already holds such a key secret to initialize the MCP interface, enumerate the published application's tool metadata, invoke tools/call, and persist application_chat and application_chat_record records - operations the standard /chat/api/open path refuses with the same key. The root cause is CWE-613 (Insufficient Session Expiration): the MCP authentication path validates only the key secret and its active flag while omitting the is_permanent and expire_time checks enforced elsewhere. This is a bounded credential-lifecycle bypass rather than unauthenticated access - the attacker must already possess a leaked, retained, or previously delegated key that is still marked active and past its expiry - and no public exploit has been identified at time of analysis, with no vendor-released patch identified at time of analysis.
InvenTree versions prior to 1.4.0 expose business data through the report and label print endpoints because POST /api/report/print/ and POST /api/report/label/print/ authenticate the caller but never invoke users.permissions.check_user_permission against the target model's view role. Any authenticated account - including one with no roles or only unrelated roles - can enumerate object primary keys and render them through the default templates InvenTree ships for major business models, then retrieve the resulting artifact from DataOutput, obtaining purchase, sales, part, bill-of-materials, stock, build, supplier, customer, pricing, and inventory data that the corresponding detail APIs would correctly deny. Fixed in 1.4.0; no public exploit code or confirmed active exploitation was identified at time of analysis, and the EPSS-style risk is modest because valid credentials are required and impact is limited to confidentiality (CVSS 4.3, CWE-639).
Unauthenticated information disclosure in InvenTree prior to 1.4.0 lets a remote caller retrieve plugin names, setting keys, descriptions, types, choices and non-secret configuration values through /api/plugin/settings/ and the per-plugin settings endpoints, because PluginSettingList, PluginAllSettingList and PluginSettingDetail registered GlobalSettingsPermissions without the IsAuthenticated permission used by equivalent global-settings endpoints. Exposure is confined to metadata and non-secret configuration: protected secret values remain masked as three asterisks, only safe methods are readable, and at least one plugin must be installed and active for the disclosure to be meaningful, so the practical impact is limited. The assessed CVSS 3.1 vector is AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N (score 5.3), confirming remote unauthenticated exploitation with low confidentiality impact and no integrity or availability effect; no public exploit identified at time of analysis.
Broken object-level authorization in InvenTree versions prior to 1.4.0 lets any authenticated user, including an account with no assigned roles, read the staged import data and column mappings belonging to another user's DataImportSession by supplying that session's identifier to the /api/importer/row/ or /api/importer/mapping/ endpoints. The impact is confidentiality-only (CVSS 4.4 base, assessed as 4.3: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N) and requires a valid login plus knowledge or enumeration of a victim's session ID on an instance where another user has an active import in progress; no public exploit code has been identified at time of analysis and the flaw is not confirmed actively exploited (CISA KEV). The vendor's threat model treats authenticated instance users as trusted, so the realistic exposure is between distrustful co-tenants of the same instance rather than remote outsiders, and version 1.4.0 resolves it.
InvenTree versions prior to 1.4.0 render report and label templates with WeasyPrint's default URL fetcher, so an authenticated staff user who can author templates can make the server fetch attacker-chosen resources over http/https or read local files through the file:// scheme and later recover the fetched bytes from the stored PDF attachment. This yields full-read server-side request forgery, local file disclosure (potentially including application credentials), and in the worst case compromise of a superuser account. The issue is access-gated and not a broad internet-facing threat: it requires staff-level template-authoring privileges (CVSS 3.1 AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:L/A:N, base 6.5) plus the ability to retrieve the generated attachment, and no public exploit has been identified at time of analysis. A vendor-released fix is available in InvenTree 1.4.0.
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.
Information disclosure in the djust Python WebSocket framework before 1.0.7 causes Django Model instances assigned to public (non-underscore) view attributes to be serialized to the browser with no sensitive-field denylist, exposing fields such as the password hash, is_staff/is_superuser privilege flags, tokens, and other PII inside the render payload sent to the client. Exploitation requires authenticated access to a view that assigns a full model to a public attribute (CVSS:3.1 AV:N/PR:L), and the resulting impact is confidentiality-only but rated High (C:H/I:N/A:N). No public exploit code has been identified at time of analysis and the issue is not listed in CISA KEV.
Stored and reflected cross-site scripting in djust (pip package djust) before 1.0.7 allows a javascript: URL supplied through user-controllable data to survive into the href/action attributes of built-in component template tags, executing script in a victim's authenticated browser session when the link is clicked. Only applications that bind untrusted URLs to components such as breadcrumb, dj_nav link/dropdown/brand, citation URL, cookie-consent privacy link, error-page action or form action are affected; default djust output is not exposed. The issue is developer-usage-conditional, the assessed vector is CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:C/C:L/I:L/A:N (user interaction required, low-privileged/authenticated injecting party), no public exploit identified at time of analysis, and the vendor fix is available in djust 1.0.7.
Stored cross-site scripting in Django admin's URLField rendering allows a malicious URL value (e.g., using a `javascript:` scheme) to be displayed as a clickable link on changelist views and read-only admin fields without scheme validation. Any application that accepts URLField input via public-facing forms and exposes those records in the Django admin is affected, covering Django 5.2 through the 6.1 release candidate. No public exploit or active exploitation (CISA KEV) has been identified at time of analysis; patches were released August 4, 2026 as Django 5.2.17 and 6.0.8.
Memory exhaustion in Django's `check_for_language()` function allows denial-of-service via the `set_language` view when it is explicitly enabled in URL configuration. Attackers can submit many distinct, very long language codes via POST requests, causing each code to be cached as an in-memory key and progressively consuming process memory. Django rates this severity 'low' because built-in guards - `DATA_UPLOAD_MAX_MEMORY_SIZE` and the cache's maximum entry count - bound the total exploitable memory; no public exploit identified at time of analysis.
Denial-of-service via recursive GEOMETRYCOLLECTION parsing crashes Django processes through a segmentation fault in the underlying GEOS library. Django's GEOSGeometry class, GeometryField form field, and spatial field lookups in versions 5.2, 6.0, 6.1 (RC), and main are all affected when processing WKT or WKB input containing deeply nested or excessively numerous GEOMETRYCOLLECTION objects. No public exploit code or active exploitation has been identified at time of analysis; the Django team rated this 'moderate' severity and issued fixed releases Django 5.2.17 and 6.0.8 on August 4, 2026.
Header injection in Django's DomainNameValidator allows network attackers to inject arbitrary HTTP response headers when applications pass validator-accepted domain values directly into HTTP responses, affecting Django 6.0 before 6.0.7 and 5.2 before 5.2.16. The validator silently accepts embedded newline characters in domain name strings, enabling HTTP response splitting that can facilitate session hijacking, open redirects, or cross-site scripting against end users. No public exploit code or CISA KEV listing exists at time of analysis; practical risk is narrowed significantly by Django's HttpResponse class independently rejecting newlines, meaning only non-standard code paths are exploitable.
Memory over-read in Django's GIS module allows unauthenticated remote attackers to potentially disclose adjacent heap memory or degrade service availability via a segmentation fault. The `django.contrib.gis.gdal.GDALRaster` class fails to correctly bound its read when constructed from a bytes object, exposing raw memory when the `vsi_buffer` property is subsequently accessed. Affects Django 6.0 before 6.0.7 and 5.2 before 5.2.16; no public exploit identified at time of analysis and not listed in CISA KEV.
Cache poisoning in Django's UpdateCacheMiddleware and cache_page() decorator exposes private user data to unauthenticated remote attackers by incorrectly serving cached responses across different cookie contexts. Versions 6.0 before 6.0.7 and 5.2 before 5.2.16 are confirmed affected; older unsupported branches (5.0.x, 4.1.x, 3.2.x) were not evaluated but may share the flaw. No public exploit or CISA KEV listing exists at time of analysis, and the low CVSS 4.0 score of 2.3 reflects meaningful preconditions, though the data-disclosure consequence for applications serving personalized, cookie-gated content through a shared cache is concrete.
Incorrect cache storage in Django's UpdateCacheMiddleware exposes responses that should have been excluded from caching due to uppercase or mixed-case Cache-Control directives (e.g., 'Private', 'NO-STORE'). Affected versions 5.2.x before 5.2.15 and 6.0.x before 6.0.6 fail to perform case-insensitive comparison of Cache-Control directive strings, causing the middleware to cache responses it should skip, which remote attackers can then retrieve. No public exploit has been identified at time of analysis, and active exploitation is not confirmed; the low CVSS 4.0 score of 2.3 accurately reflects limited scope, though real-world impact scales with how sensitive the incorrectly cached data is.
Django's SMTP email backend silently downgrades to cleartext transmission when a STARTTLS handshake fails under the `fail_silently=True` configuration, exposing email content to on-path network interception. Affected are Django 6.0.x before 6.0.6 and 5.2.x before 5.2.15; older unsupported series (5.0.x, 4.1.x, 3.2.x) were not evaluated but may also be vulnerable. No public exploit has been identified at time of analysis, and the CVSS 4.0 score of 2.3 reflects the high attack complexity and mandatory on-path network positioning required for exploitation.
Cookie context confusion in Django's signed cookie implementation allows a remote low-privileged attacker to substitute a cookie signed in one application context into a different context where a distinct (name, salt) pair produces the same concatenated string. Affected are Django 6.0 before 6.0.6 and Django 5.2 before 5.2.15; older unsupported series (5.0.x, 4.1.x, 3.2.x) were not evaluated but may also be affected. The real-world impact is limited to low-confidence data exposure (VC:L), with no public exploit identified at time of analysis, and the CVSS 4.0 score of 2.3 reflects a low-severity, contextually constrained flaw.
Cache-bypass information disclosure in Django's `has_vary_header()` utility allows remote attackers to read cached HTTP responses intended for other users by exploiting improper whitespace handling in `Vary` header comparisons. Affected versions are Django 5.2.x before 5.2.15 and 6.0.x before 6.0.6; earlier unsupported series (5.0.x, 4.1.x, 3.2.x) were not evaluated and may also be affected per the vendor. The CVSS 4.0 score of 2.3 reflects constrained real-world impact requiring both a non-default prerequisite condition and user interaction, with no public exploit or confirmed active exploitation identified at time of analysis.
Cache information disclosure in Django 5.2.x and 6.0.x allows remote unauthenticated attackers to read private authenticated responses served from shared caching layers. The `UpdateCacheMiddleware` component omits `Authorization` from the `Vary` response header when authenticated requests lack an explicit `Cache-Control: public` directive, causing caches to serve authenticated users' responses to subsequent unauthenticated requestors at the same URL. No public exploit has been identified at time of analysis, and the CVSS 4.0 score of 2.3 reflects meaningful - but constrained - real-world impact gated behind specific deployment prerequisites.
Django 6.0 before 6.0.5 and 5.2 before 5.2.14 fail to vary response headers on session cookies when SESSION_SAVE_EVERY_REQUEST is enabled but the session is unmodified, allowing remote attackers with user interaction to steal session tokens from cached public pages. The vulnerability affects server configurations that cache responses aggressively while maintaining per-request session handling, exposing authenticated users to session hijacking after visiting pages served from cache.
Django's UpdateCacheMiddleware incorrectly caches HTTP responses containing a Vary header with an asterisk value in versions 6.0 before 6.0.5 and 5.2 before 5.2.14, causing private user data to be cached and served to other users. The vulnerability has low confidentiality impact and requires user interaction (UI:P) combined with passive attack timing, making real-world exploitation dependent on specific cache timing conditions and application architecture.
Django 6.0 before 6.0.5 and 5.2 before 5.2.14 allow remote attackers to bypass the FILE_UPLOAD_MAX_MEMORY_SIZE limit by submitting ASGI requests with missing or understated Content-Length headers, potentially loading large files into memory and causing denial of service through resource exhaustion. No active exploitation confirmed, but the vulnerability requires only network access and no authentication, making it trivially exploitable once the bypass is understood.
Django's MultiPartParser allows authenticated remote attackers to cause denial of service through performance degradation by submitting multipart uploads with Content-Transfer-Encoding: base64 and excessive whitespace. Affected versions include Django 6.0 before 6.0.4, 5.2 before 5.2.13, and 4.2 before 4.2.30, with unsupported series 5.0.x, 4.1.x, and 3.2.x potentially also vulnerable. The vulnerability has a CVSS 6.5 score reflecting high availability impact but requires authentication (PR:L) and is not actively exploited or publicly weaponized at analysis time.
Django admin changelist forms with ModelAdmin.list_editable enabled allow high-privileged users to create new instances via forged POST requests, bypassing intended access controls. Affects Django 6.0 before 6.0.4, 5.2 before 5.2.13, and 4.2 before 4.2.30; unsupported versions 5.0.x, 4.1.x, and 3.2.x may also be vulnerable. The vulnerability requires admin-level privileges and results in unauthorized data modification rather than data exposure or availability impact. No public exploit code or active exploitation has been confirmed at time of analysis.
Stored XSS in Wagtail's simple_translation module allows authenticated admin users to inject malicious JavaScript through specially-crafted page titles that executes when other admins perform translation actions, potentially compromising their credentials. The vulnerability affects Wagtail versions prior to 6.3.8, 7.0.6, 7.2.3, and 7.3.1, and requires admin-level access to exploit, limiting exposure to internal threats. Patches are available for all affected versions.
Stored XSS in Wagtail's TableBlock allows authenticated users with page editing permissions to inject malicious class attributes that execute arbitrary JavaScript when pages are viewed by other users. An attacker could exploit this to perform administrative actions or steal credentials from higher-privileged users viewing the compromised content. The vulnerability affects Wagtail versions prior to 6.3.8, 7.0.6, 7.2.3, and 7.3.1, with patches now available.
Allauth versions up to 65.14.1 is affected by url redirection to untrusted site (open redirect) (CVSS 6.1).
An issue was discovered in 6.0 before 6.0.3, 5.2 before 5.2.12, and 4.2 before 4.2.29. [CVSS 3.7 LOW]
Wagtail is an open source content management system built on Django. [CVSS 2.7 LOW]
SQL injection in Django's QuerySet.order_by() method allows authenticated attackers to execute arbitrary SQL commands through specially crafted column aliases containing periods when used with FilteredRelation and dictionary expansion. This vulnerability affects Django versions 6.0 before 6.0.2, 5.2 before 5.2.11, and 4.2 before 4.2.28, with potentially older unsupported versions also impacted. Patches are available for all affected versions.
SQL injection via FilteredRelation column aliases in Django 4.2, 5.2, and 6.0 allows authenticated attackers to execute arbitrary SQL queries through crafted dictionary arguments in QuerySet methods like annotate() and aggregate(). An attacker with database access can exploit control characters in alias names to bypass input validation and potentially extract sensitive data or modify database contents. Patches are available for all affected versions, and unsupported Django releases may also be vulnerable.
SQL injection in Django's PostGIS RasterField lookups allows authenticated attackers to execute arbitrary SQL commands through the band index parameter in affected versions 6.0 before 6.0.2, 5.2 before 5.2.11, and 4.2 before 4.2.28. Unsupported Django series including 5.0.x, 4.1.x, and 3.2.x may also be vulnerable. A patch is available and authentication is required to exploit this vulnerability.
An issue was discovered in 6.0 before 6.0.2, 5.2 before 5.2.11, and 4.2 before 4.2.28. `ASGIRequest` allows a remote attacker to cause a potential denial-of-service via a crafted request with multiple duplicate headers. [CVSS 7.5 HIGH]
Django versions up to 6.0.2 contains a vulnerability that allows attackers to enumerate users via a timing attack (CVSS 5.3).
Authentication bypass in django-allauth versions before 65.13.0 allows an authenticated attacker with a valid Okta or NetIQ identity provider account to impersonate other users by modifying the mutable 'preferred_username' claim used as the account identifier, potentially leading to account takeover. This moderate-severity flaw (CWE-287) only affects deployments configured with these specific third-party login providers, and exploitation requires the attacker to be able to set or change their preferred_username value. No public exploit code or active exploitation has been identified at time of analysis; the vendor has released patch 65.13.0 which switches to the immutable 'sub' claim.
Deactivated django-allauth identity-provider accounts retain access to protected resources because OAuth2/OpenID Connect access and refresh tokens issued while the account was active were not rejected after the user was marked is_active=False. This affects django-allauth (allauth-django) releases before 65.13.0, but only deployments that use the built-in IdP feature and rely on is_active=False as their account-revocation mechanism. An authenticated holder of such a token (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N, base 5.4) can keep performing low-impact reads and writes through the IdP until the already-issued tokens expire; no public exploit code was identified at time of analysis and there is no indication of active exploitation. The issue is fixed in 65.13.0.