CVE-2026-64821: djangoSIGE CSRF Vulnerability

CVE-2026-64821 Overview

CVE-2026-64821 is a Cross-Site Request Forgery (CSRF) vulnerability affecting djangoSIGE through version 1.10 (commit a6fe7e8). The flaw resides in four order-cancellation views: CancelarOrcamentoVendaView, CancelarPedidoVendaView, CancelarOrcamentoCompraView, and CancelarPedidoCompraView. These views implement state-changing cancellation logic inside HTTP GET handlers. Django's CsrfViewMiddleware enforces CSRF token validation only on unsafe HTTP methods such as POST, so GET-based state changes bypass token validation entirely. An unauthenticated attacker can trick an authenticated user with change_orcamentovenda or equivalent permissions into loading a cross-origin resource that triggers cancellation of sales or purchase orders. The issue maps to CWE-352.

Critical Impact
Attackers can cancel sales or purchase orders on behalf of authenticated djangoSIGE users through a single cross-origin img tag, without any valid CSRF token.

Affected Products

djangoSIGE through version 1.10 (commit a6fe7e8)
Deployments using CancelarOrcamentoVendaView and CancelarPedidoVendaView sales cancellation endpoints
Deployments using CancelarOrcamentoCompraView and CancelarPedidoCompraView purchase cancellation endpoints

Discovery Timeline

2026-07-21 - CVE-2026-64821 published to NVD
2026-07-23 - Last updated in NVD database

Technical Details for CVE-2026-64821

Vulnerability Analysis

The vulnerability stems from djangoSIGE placing destructive business logic behind HTTP GET requests. Order cancellation should be an unsafe operation and must therefore require a POST request with a validated CSRF token. Django's built-in CsrfViewMiddleware treats GET, HEAD, OPTIONS, and TRACE as safe methods and skips CSRF validation for them. When the developer implemented cancellation logic inside get() handlers of the four class-based views, the middleware silently allowed cross-origin requests through. The result is a classic confused-deputy scenario where the victim's browser attaches session cookies to a request the user never intended to make.

Root Cause

The root cause is a violation of HTTP method semantics combined with reliance on middleware defaults. State-changing actions were coded as idempotent GET operations, so no CSRF token is ever checked. Any authenticated session cookie carried by the browser is sufficient to execute the cancellation. Permissions such as change_orcamentovenda gate the action at the authorization layer, but do not stop a forged cross-origin request from the victim's own browser.

Attack Vector

An attacker hosts a page containing a cross-origin reference to the cancellation endpoint, for example an <img src="https://target/vendas/orcamento/cancelar/<id>/"> tag or an auto-loading iframe. When a djangoSIGE user with cancellation permissions visits the attacker's page, the browser issues a GET request with the user's session cookies. The server-side view executes the cancellation without validating a CSRF token or Referer header. Exploitation requires user interaction to visit the malicious page but requires no privileges from the attacker.

No verified exploit code is published; see the VulnCheck Security Advisory and the GitHub PoC Repository for technical details.

Detection Methods for CVE-2026-64821

Indicators of Compromise

HTTP GET requests to cancellation URLs such as /vendas/orcamento/cancelar/, /vendas/pedido/cancelar/, /compras/orcamento/cancelar/, and /compras/pedido/cancelar/ originating from a cross-origin Referer.
Cancellation actions in application audit logs that do not correlate with a preceding user-initiated navigation from the djangoSIGE UI.
Bursts of cancellation events tied to a single user session shortly after that user visited an external site.

Detection Strategies

Alert on any GET request to the four Cancelar*View endpoints whose Referer header is absent or points to an external domain.
Correlate web server access logs with djangoSIGE application logs to flag cancellations lacking a matching POST from the confirmation form.
Deploy web application firewall rules that inspect requests to cancellation paths and block cross-site references.

Monitoring Recommendations

Ingest djangoSIGE web logs and Django audit records into a centralized SIEM for cross-origin request analysis.
Track per-user cancellation frequency and alert on statistical deviations from baseline.
Monitor for HTML content served by internal collaboration tools that references the vulnerable endpoints.

How to Mitigate CVE-2026-64821

Immediate Actions Required

Upgrade djangoSIGE to a patched build that incorporates the fix proposed in GitHub Pull Request #163.
Restrict access to the four cancellation views to authenticated POST requests only, and require a valid CSRF token.
Review recent order cancellations for legitimacy and restore any records that were cancelled without user intent.

Patch Information

A fix is proposed upstream in GitHub Pull Request #163 for the djangoSIGE repository maintained by thiagopena. The remediation moves cancellation logic out of get() handlers and into post() handlers so Django's CsrfViewMiddleware enforces token validation. Refer to the VulnCheck Security Advisory for advisory metadata.

Workarounds

Place djangoSIGE behind a reverse proxy that rejects GET requests to the four cancellation URL patterns.
Enforce SameSite=Strict on the Django session cookie by setting SESSION_COOKIE_SAMESITE = 'Strict' to block cross-origin cookie attachment.
Require re-authentication or a signed one-time token appended to cancellation URLs until the upstream patch is deployed.

bash

# Django settings.py hardening example
SESSION_COOKIE_SAMESITE = 'Strict'
SESSION_COOKIE_SECURE = True
CSRF_COOKIE_SAMESITE = 'Strict'
CSRF_COOKIE_SECURE = True

# Example Nginx rule to block GET to cancellation endpoints
# location ~ ^/(vendas|compras)/(orcamento|pedido)/cancelar/ {
#     limit_except POST { deny all; }
#     proxy_pass http://djangosige_upstream;
# }