Django's October Fixes: Test Who Can Change Each Record

An administration screen can display exactly the right records and still process an unauthorized change. The permission boundary has to survive the submitted request, not just the query used to build the page. That is the practical concern behind one of Django's October security fixes.

What the October 6 release fixes

Django released 6.1.2, 6.0.9, and 5.2.18 on October 6, 2026. Among the fixes, CVE-2026-87975 addresses model formsets with editable primary keys. Forged POST data could allow deletion outside the limiting queryset or creation through an edit-only formset. Models using the default BigAutoField primary key were not affected by this issue. See Django's release announcement.

The same release addresses denial-of-service issues in language handling and header parsing, request forgery involving spatial lookup bytes, and additional hardening for a previous geometry-related fix. Install the complete security release for your branch rather than treating the formset change as the only relevant update.

A list of allowed records is only the start

Think about a customer portal that lets a user edit several delivery addresses. The page might correctly show only that customer's addresses. The server still needs to ensure that every submitted identifier belongs to the same permitted set, including identifiers used in deletion and bulk-update paths.

A useful regression test gives two test accounts separate records. Account A should be able to perform its allowed operation on A's record, and must fail when the same operation references B's record. Check the database afterward: an error message alone is insufficient if a side effect already happened.

Apply the same idea to APIs. Test read, update, delete, and bulk operations independently. Access to a collection does not imply permission over every object identifier, and a UUID is an identifier rather than an authorization control.

What to review after patching

1. Update the framework in the deployed application and workers. Confirm that the running release matches the lockfile and deployment record.
2. Inventory model formsets and inline formsets. Review custom primary keys, editable identifiers, bulk deletion, and any UI intended only for existing objects.
3. Add ownership and role checks to regression tests using isolated fixtures. Include denied operations and verify that they leave stored data unchanged.
4. Review related endpoints that implement the same business action outside the formset. A mobile API and an admin page may enforce permissions in different code.

Use BlackSight to expand coverage

A public-page scan cannot see the whole logged-in application. BlackSight supports authenticated web scan configuration, and Pro API settings accept OpenAPI, GraphQL, or SOAP inputs with an authentication check. Configure the actual protected routes and verify that the scanner successfully authenticates before interpreting the report.

Those scans can surface supported web and response-level findings on the routes they reach. They do not infer which customer's records a test account should own. Keep the two-account authorization tests above as the direct check for this class of failure, and scope active operations to a test environment with disposable data.

BlackSight helps make reachable coverage and follow-up scans repeatable while developers verify the application's business rules. Our guide to vulnerability scanning and penetration testing explains how to combine automation with deeper authorization review.