Alerts

The commit prevents a potential Denial of Service (memory/resource exhaustion) by capping the amount of the HTTP error response body read during prom.scrape non-200 responses. Previously, the code read the entire response body (io.ReadAll) for non-200 HTTP statuses, which could allow a malicious or misbehaving endpoint to exhaust memory (OOM) by returning a very large body. The fix introduces a limited reader (GetLimitedReader) with a maximum size (maxScrapeSize+1) and reads only up to that bound, mitigating unbounded reads and subsequent memory exhaustion. Impact: This changes the behavior of error-paths in lib/promscrape/client.go, ensuring that error bodies are not read in full when the endpoint is misbehaving or malicious. This is a genuine security improvement, not just a dependency bump or a cosmetic change.

This commit hardens AccessControl by introducing per-resource permission kind restrictions (AllowsKind) for ResourcePermission mappers and by explicitly constraining Service Accounts (SA) to not be granted BasicRole at the resource level. Previously, mappers could implicitly allow all permission kinds (nil allowedKinds) for resources like serviceaccounts, which could enable a per-resource BasicRole grant to an SA. The patch adds: (1) a configurable ScopeAttribute and Scope attribute constants to make scope handling explicit, (2) a shared mapper with an AllowsKind(...) method to restrict which permission kinds are allowed per resource, and (3) storage_backend.go wiring that, for serviceaccounts, uses an explicit allowedKinds list excluding BasicRole. This closes a potential authorization bypass where a user could grant a BasicRole to an SA on a specific resource, effectively escalating privileges at the resource level when BasicRole is globally derived for SA.

The commit adds fieldSelector handling for the preferences listing endpoint and enforces access checks to prevent information disclosure via list operations. Specifically: - Only a single fieldSelector on metadata.name is supported with the = operator. - Access control is applied based on the owner parsed from the name: namespace owner is always allowed; user owner is allowed only if the requester matches; team owner is allowed only if the requester is a member of that team. - Continue tokens and label selectors are rejected to prevent abuse. - If access is not permitted, the API returns an empty list instead of leaking data. This fixes a potential authorization/info-disclosure flaw where an authenticated user could enumerate or fetch preferences for other users/teams via the list endpoint using field selectors. The vulnerability type is Information Disclosure / Access Control (Authorization).

The commit bundles fixes for memory-safety vulnerabilities in the ksmbd SMB server (smbdirect path and related code). The primary issues addressed are memory-corruption risks such as use-after-free and double-free in the SMB Direct path (e.g., handling and ownership of request objects in smbdirect_send paths, and the flow where a request is moved to a batch and should not be freed), as well as a use-after-free in the close path for durable/async operations. Additional changes address a potential crypto-message use-after-free, a memory leak in session setup, validation improvements (EA name length), and safer handling of related FSCC structures to reduce the risk of out-of-bounds or invalid memory access. Overall, these changes are aimed at mitigating memory-safety defects that could lead to crashes or code execution, rather than pure functionality changes.

The commit set contains device-mapper and DM core fixes that include memory-safety improvements around dynamic allocations and ioctl handling (notably in dm-bufio.c and related dm-cache/metadata paths). The key change is replacing a potentially unsafe fixed-size allocation for a dynamically-sized structure with a safe flexible-allocation approach (kzalloc_flex) and related ioctl/error-path hardening. This points to a genuine memory-safety bug (buffer overflow risk) in ioctl/Data-structure handling within the device-mapper subsystem, rather than a pure dependency bump or cosmetic cleanup.

The patch fixes a memory-safety vulnerability by replacing an out-of-bounds read when computing the length to copy into task_struct->comm. Previously __set_task_comm used strlen(buf) to determine the length, which can read past a non-NUL-terminated user-provided buffer. The fix uses strnlen(buf, sizeof(tsk->comm) - 1) to cap the read to the destination buffer, preventing potential over-read and related memory-safety issues or information disclosure. This is a genuine safety improvement in the exec path that updates task names.

The commit fixes a race condition in regmap-debugfs dummy name allocation. Previously, regmap-debugfs used a static dummy_index for naming dummy entries, which could race when multiple regmaps create dummy debugfs entries concurrently, potentially leading to name collisions, incorrect mapping, or use-after-free scenarios during cleanup. The fix introduces per-instance ID allocation (via IDA) and per-map tracking (debugfs_dummy_id) with proper cleanup, eliminating the shared global naming race and ensuring each dummy debugfs entry has a unique, correctly freed name.

The commit bundle contains explicit security-related fixes: (1) bounds checking addition in d_mark_tmpfile_name to prevent a potential buffer overflow when constructing a temporary file name for dcache entries. It enforces that the new name length does not exceed DNAME_INLINE_LEN - 1 before performing the copy, reducing the risk of memory corruption in path handling for tmpfiles. (2) A compatibility/feature-related adjustment to support O_TMPFILE and related tmpfile naming, including new constants and small adjustments in cifs/smb client code to correctly handle temporary file creation and naming. The triaged note mentions fixing an out-of-bounds read in symlink response parsing and an EA bounds check; these changes correlate to input validation and memory-safety improvements in the SMB client and vfs path handling. Taken together, these are concrete security-oriented fixes rather than mere dependency bumps or cosmetic changes.

The commit contains a genuine security vulnerability fix in the HFS+ handling code of the Linux kernel. It addresses a memory-safety issue where syzbot observed an uninitialized value being read from on-disk HFS+ catalog records. The root cause is that the code path reading catalog records did not validate that the on-disk record size (the length field for a catalog entry) matches the expected size for the record type. The patch introduces hfsplus_brec_read_cat(), which validates the record size against the type and returns -EIO on mismatch, preventing potential reads of uninitialized kernel memory. Additionally, the commit includes related hardening such as detecting corrupted allocator state during hfs_btree_open() (mount read-only on corruption) and fixing error-path lock handling to avoid deadlocks. These changes reduce exposure to memory-safety issues and panics when processing corrupted HFS+ images. In short, this is a targeted memory-safety vulnerability fix in HFS+ catalog record parsing, not merely a dependency bump or a cosmetic code cleanup.

The ksmbd durable handle reconnect flow did not verify the reconnecting client's identity against the original opener. This allowed an authenticated user to hijack an orphaned durable handle by guessing or brute-forcing the persistent ID (DHnC). The patch adds a durable_owner to ksmbd_file to store the original opener's UID, GID, and account name, captures owner information when a file handle becomes orphaned, and introduces ksmbd_vfs_compare_durable_owner() to validate the reconnection identity during SMB2_CREATE (DHnC). This closes the gap where any authenticated user could reconnect to a durable handle opened by another user.

This commit fixes a real race condition in KVM's gmap/shadow paging code, addressing partial gmap invalidations particularly in the s390 KVM path and tightening the user-kernel API surface by replacing VLAs with FLEX_ARRAY. The core changes introduce an invalidated flag on gmap objects and adjust the shadow/invalidation logic to avoid races where a gmap could be observed in an inconsistent state during concurrent invalidation and shadow-paging operations. It also updates multiple UAPI structures to use the FLEX_ARRAY helper instead of VLAs, reducing risks from unbounded kernel/user-space structures. The combination of s390 race fixes and the UAPI cleanup constitutes a genuine vulnerability fix aimed at preventing race-induced memory safety/isolation issues in virtualization. Rationale: - The diff shows multiple guarded checks that previously relied on sg->parent to determine validity; these have been replaced with sg->invalidated in several hot paths, indicating a race-prone condition when a gmap is invalidated concurrently with shadow operations. - The gmap structure now carries an invalidated flag and the code marks gmaps as invalidated during certain transitions, which prevents unsafe pointer usage or premature re-use of shadow state. - UAPI structures are migrated from inline flexible arrays (VLAs) to __DECLARE_FLEX_ARRAY, eliminating VLAs in kernel-user interfaces and reducing attack surface from malformed or oversized user-space inputs. Affected behavior before fix: concurrent invalidation/updates of gmaps could race with shadow paging, potentially leading to use-after-free-like scenarios or memory isolation breaches in edge cases. Impact: The fix reduces the likelihood of memory-safety vulnerabilities in KVM where gmap invalidations race with shadow paging, improving guest memory isolation and stability.

This commit implements an information-disclosure hardening in the unified search API by filtering out the K6 technical folder for non-service accounts. Previously, regular users could observe internal K6 RBAC artifacts (the K6 folder) in search results, potentially leaking internal structure and permissions. The change adds a NotIn filter on the SEARCH_FIELD_NAME for the K6FolderUID when the requester is not a service account, and updates tests accordingly. This appears to be a genuine security vulnerability fix aimed at reducing unintended information disclosure via search results.

The commit implements an authorization fix for listing preferences. Prior to this change, non-user identities (e.g., AccessPolicy) could list all preferences by nulling the user, effectively bypassing access control and enabling information disclosure across users/teams within a namespace. The patch restricts listing to actual users and requires an explicit All flag to list all preferences. This prevents an authorization bypass that could reveal per-user/per-team preferences.

The commit adds a temporary authorization rule that explicitly denies watch operations on ResourcePermissions while allowing other operations. This blocks the watch exposure for ResourcePermissions, addressing an access-control weakness where watch streams could reveal permission-related data. It is a targeted code change (not a dependency bump) intended to fix an authorization bypass risk, by injecting a Deny path for the watch verb on ResourcePermissions at the API layer. The change relies on a storage-layer authorization for non-watch operations, with watch explicitly denied via a custom AuthorizerFunc.

The commit adds validation to reject wildcard '*' as the resource name in ResourcePermission objects used by Grafana's RBAC. This was enabling a potential authorization bypass/privilege escalation by creating or using a permission that targets all resources within a group (a wildcard). The changes enforce that resource permissions must target a specific resource and adjust related parsing/validation paths accordingly. Tests were added to ensure '*' is rejected, and an explicit error path was introduced for wildcard resource IDs. This indicates a real vulnerability fix rather than a mere dependency bump or cleanup.

Root cause: provisioning identity was derived from the resource object's namespace (f.Obj.GetNamespace()) in Run() and DryRun(), which could be empty or incorrect for resources created via provisioning. As a result, resources from one repository could be created or modified under an unintended namespace, leading to cross-namespace ownership conflicts and potential privilege escalation. The patch changes identity derivation to use the repository's namespace (f.Repo.Namespace) in Run(), DryRun(), and related code paths (e.g., dualwriter.go), ensuring resources are created within the repository's proper namespace and preserving isolation across repositories. Integration tests for cross-namespace isolation were added to validate correct behavior. This is a genuine security fix addressing authorization/ownership boundaries between repositories.

The commit fixes a memory-safety bug in the PN533 NFC UART driver receive path. Previously, pn532_receive_buf could consume input bytes and hand a complete frame to pn533_recv_frame() before ensuring a fresh receive skb was allocated. If a fresh skb allocation failed, the callback would return the number of bytes accepted as zero, leave recv_skb as NULL, and subsequent receive handling could dereference a NULL skb (via skb_put_u8()), leading to a kernel crash or instability. The fix allocates the receive skb lazily just before consuming the next byte and, on allocation failure, returns the number of bytes already accepted. This preserves receive accounting and avoids potential NULL dereferences. The change is a correctness bug fix with memory-safety implications in the kernel space.

The commit strengthens and clarifies RISCV indirect branch tracking (CFI) and shadow stack handling in the kernel. It unlocks per-task CFI/shadow stack state immediately after exec(), updates prctl()/ptrace interfaces to be more explicit, and renames/adjusts internal state fields for branch landing pads and shadow stacks. The changes address stale/incorrect locking behavior that could otherwise result in a misconfigured or stuck CFI/shadow stack state, which could be exploited to bypass control-flow integrity and potentially enable RCE via indirect branches. In short, this is a security hardening/fix rather than a mere cleanup or dependency bump.

The commit fixes a buffer overflow in the TH1520 AON RPC handling path (drivers/firmware/thead,th1520-aon.c). Previously, the code built the RPC message by using the RPC_SET_BE16 macro to write 16-bit values into the message at specific offsets, which could write beyond the intended bounds and corrupt memory. The patch replaces these writes with direct 16-bit fields (resource and mode) updated using cpu_to_be16, aligning the payload with the actual RPC structure and preventing out-of-bounds writes. This addresses a potential memory corruption vulnerability in the TH1520 AON firmware RPC path. The change also updates the endian handling macros in the header to standardize usage.

Memory-safety vulnerability in the IOMMU code: when unmapping, the iotlb_gather may appear empty and the code could elide the iotlb_sync() call, leading to stale TLB state and potential memory corruption, crashes, or hangs. The patch ensures iotlb_sync is invoked even if the gather is effectively empty by forcing a non-empty gather before sync.

The commit adds explicit sanitization of HTTP header values used for gRPC metadata in the Grafana plugins integration path. It introduces: (1) isGRPCSafeHeaderValue to check that header bytes are printable ASCII (0x20 to 0x7E), and (2) sanitizeHTTPHeaderValueForGRPC to convert header values to a gRPC-safe representation by percent-encoding unsafe bytes. If the value is valid UTF-8, non-printable ASCII bytes are percent-encoded directly; if not valid UTF-8, the value is treated as ISO-8859-1, decoded to UTF-8, and then percent-encoded. Headers are then set with sanitized values. The tests demonstrate expected sanitization behavior, ensuring gRPC metadata remains ASCII-printable and preventing problematic header content from propagating to downstream services.

The commit fixes a data race and potential nil pointer dereference in the storage startup sequence. Previously, FreeDiskSpaceWatcher could start before the Storage.table was fully initialized (opened), leading to the watcher potentially reading an uninitialized or partially initialized table and dereferencing a nil or invalid pointer. The fix initializes the isReadOnly state earlier and starts FreeDiskSpaceWatcher after openTable, ensuring the shared storage state is fully initialized before the watcher accesses it. This mitigates a memory safety issue (use-after-init / nil pointer dereference) that could cause crashes or undefined behavior in concurrent operation.

The commit updates the Kubernetes gateway TLS certificate handling to perform per-ref validation, enforce permissions for TLS certificate references, and load TLS certificates per reference when multiple certificateRefs are configured on a Gateway listener. Previously, TLS handling could implicitly accept/load the first certificateRef without per-ref permission checks, potentially allowing misuse of unauthorized Secret references for TLS termination. The patch adds per-ref validation, permission checks (isReferenceGranted), and per-ref TLS loading (getTLSCert) to ensure only permitted certificateRefs are used, mitigating misconfiguration exposure and potential TLS information exposure or downgrade risk.

The commit adds an RBACCleaner interface and wires it into the plugin uninstall path so that RBAC data associated with a plugin is cleaned up on removal. This mitigates the risk of leftover RBAC data (permissions) persisting after a plugin is uninstalled, which could otherwise allow privilege/permission leakage or unauthorized access via stale authorization entries. The code now calls CleanupPluginRBAC during plugin removal, and the removal will not be blocked by cleanup failures (errors are logged but removal proceeds). Tests were added to verify proper cleanup behavior and to ensure cleanup failures do not block removal.

The Android engine loader (FlutterLoader) reads boolean shell flag metadata from the Android manifest using applicationMetaData.getBoolean(metadataKey, true). If the metadata key is missing or the value is unparsable, the flag defaults to true, enabling potentially risky engine features by default. The commit changes the default to false (applicationMetaData.getBoolean(metadataKey, false)), ensuring flags are only enabled when explicitly specified. This hardens configuration by preventing accidental activation of sensitive or debug features (e.g., Vulkan validation, debugging-related flags) due to malformed or absent manifest metadata. The change is accompanied by tests validating behavior for missing or malformed values.

The commit fixes a race in RBAC authorization paths where RBAC lookups can be interrupted by a client disconnect due to a long-running database query. Specifically, GetBasicRoles and related permission lookups could be canceled when the client disconnects, causing incomplete or incorrect authorization decisions. The fix uses context.WithoutCancel for sensitive DB queries so that RBAC checks can complete even if the client disconnects, preserving authorization integrity. This is a real vulnerability fix (RBAC authorization integrity) and not merely a dependency bump or test enhancement. The changes primarily affect production RBAC code paths (getUserBasicRole and getUserPermissions entry point) and add a per-helper HTTP client override for observability in tests.

The commit fixes a information-disclosure/access-control issue in the alerting UI. Previously, when expanding an alert rule within a parent group, the PromQL used to fetch alert rule instances did not include the parent group label matchers, causing instances from other groups/environments to be visible. The fix threads parent group label values down to AlertRuleInstances and includes them as PromQL matchers in alertRuleInstancesQuery, thereby scoping instance results to the correct group. Added tests and code changes to ensure proper scoping.

The commit implements a real authorization fix for dashboard annotations by switching from a virtual resource-based permission check to a subresource-based RBAC flow. Previously, annotation access on dashboards could be inferred via dashboard permissions due to the use of a non-subresource path (dashboard.grafana.app/annotations) and an ad-hoc, batched permission check. The fix introduces a subresource path dashboards/annotations, aggregates permission checks via a BatchCheck request, and maps per-verb annotation actions (read/write/delete/create, etc.) to corresponding dashboard actions. It also updates the RBAC mapper to expose the new subresource, adjusts tests to cover the subresource, and ensures per-action permissions are evaluated for annotation operations. This directly addresses potential authorization bypass for reading or mutating dashboard annotations, tightening access controls to the annotations subresource.

The commit adds an admission guard that blocks mutations on resources whose namespace is marked with the pending-delete label. Specifically, it prevents updates when both the old and new objects carry the pending-delete label, and blocks creation if the incoming object carries the label. It allows updates that remove the label (explicit unlock) and permits status subresource updates. This hardens access control around provisioning resources during pending deletion to avoid unsafe mutations or inconsistent state. The changes are implemented across provisioning admission checks and wired into the provisioning validators (repositories, connections), with accompanying unit tests validating the behavior.

The commit refactors access control to keep permissions scoped to resource types (folders vs dashboards) and updates related roles/tests. Previously, some permissions were granted with broad dashboard-wide scopes (e.g., ScopeDashboardsAll or similar), which could enable privilege escalation or unauthorized access by reading/acting on dashboards across folders. The patch replaces dashboard-wide scopes with folder-scoped values (e.g., ScopeFoldersAll or ScopeFoldersProvider UID) for relevant actions and updates annotation scope resolution to rely on folder scopes. This reduces the risk of over-broad permissions leaking across folder boundaries and fixes an authorization-scoping mismatch.

Summary of the observed vulnerability and fix: - Issue type: Denial of Service (Memory Exhaustion) in Grafana's expression binary operations. - Root cause: When evaluating binary math expressions (e.g., A || B), Grafana could need to materialize a combinatorial number of output series (cartesian explosion) if the left and right sides return many series with compatible labels. This can lead to excessive memory usage and potential OOM failures before the expression even completes. - Fix provided by commit 7d62590d00088e691d8b5a8ba9f613cf285da736: - Introduces a pre-execution memory limit for a single math expression binary operation (default 1 GiB). The limit can be configured via [expressions] math_expression_memory_limit. - Adds a memory estimator that replays the union/combination logic without allocating the actual output to compute an estimated memory footprint for the potential binary operation. - Enforces the limit during expression evaluation; if the estimated memory exceeds the limit, the evaluation returns a descriptive error instead of proceeding, thereby preventing an OOM. - Extends the command handling to thread the memory limit into math command execution and passes the limit to the expression engine (WithMemoryLimit). - Includes tests for the memory estimation logic to validate the behavior. - Vulnerability type and impact: Denial of Service via Memory Exhaustion due to cartesian explosion in binary expression evaluation. The fix prevents excessive memory allocation by estimating memory usage and aborting when the limit would be exceeded. - Affected area: Expressions/mathexp execution path and configuration (defaults.ini, sample.ini) to expose a memory limit control. - Severity/confidence: HIGH confidence that this is a meaningful DoS mitigation for users crafting expressions that produce large intermediate results. The fix is preventative (pre-execution estimate) rather than a reactive crash fix. - Versions affected: Prior to this commit (pre-12.4.0). Grafana 12.4.0 includes the fix. - Practical implication: Users who craft expressions that would otherwise generate a large number of intermediate series (via cartesian-like explosions) will now receive a controlled error indicating the mismatch/over-limit situation, rather than risking memory exhaustion or server instability.

The commit adds batch authorization checks for listing annotations and filters the list results by per-item access rights. Previously, listing annotations could disclose items the user should not access when multiple items were returned in a single bulk check. The change introduces canAccessAnnotations which builds batch checks (organization-scoped and dashboard-scoped annotations) and filters the final list before returning it. This mitigates information disclosure via list endpoints where per-item checks were not enforced. Tests were added to validate unauthorized access handling and correct per-item filtering during List operations in both the Kubernetes REST-like adapter and search path.

The commit adds a GCOM guard that prevents local tenant data deletion until the external GCOM stack is confirmed deleted. prior to this change, local deletion could proceed without verifying the external GCOM state, creating a race where data could be deleted locally while the corresponding external stack still exists, potentially leading to data inconsistency or exposure. The fix introduces a GCOM check in the TenantDeleter run loop and a helper gcomAllowsTenantDeletion to query GCOM for the instance status and only proceed when GCOM reports the stack as deleted.

The commit hardens the splash screen CTAs by gating role-based/permission-based access to internal/admin URLs and using a safe fallback URL when the user lacks required permissions or admin role. Previously, CTAs could reveal internal admin URLs (e.g., /admin/provisioning) in the splash modal, which could be clicked by non-privileged users, potentially exposing admin endpoints or leaking UI structure. The fix computes the CTA URL based on user roles/permissions and falls back to safe external/docs URLs when the user is not authorized. This is an authorization/access-control hardening rather than a feature addition.

The commit fixes an information disclosure vulnerability where accessing PartialTemplate.source could leak internal Django file paths via a warning stack trace. The change switches the warning to skip internal Django file prefixes (skip_file_prefixes), so the emitted warning does not reveal internal paths and instead points to the application caller context.

The commit changes the rendering of the password hash details in the admin UI from exposing the raw password hash components (algorithm, iterations, salt, and hash) to using a dedicated template tag that masks sensitive parts. Previously ReadOnlyPasswordHashWidget iterated over hasher.safe_summary(value) and rendered the resulting keys and values, which could reveal the hashing parameters and the hash itself. The fix introduces a new templatetag render_password_as_hash that masks the salt and hash values (and gracefully handles invalid formats) and updates the template to use this tag. This reduces information disclosure from the UI, mitigating the risk of offline password cracking or leakage when an admin UI is accessible. Tests were added to cover valid, invalid, and no-password cases.

This commit fixes two UI-level issues in the Django admin related to password handling: (1) Password values are no longer disclosed in plaintext on the user change form. Instead, the password field for the User model is rendered as a hashed representation using render_password_as_hash, reducing the risk of exposing plaintext credentials in the admin UI. (2) The Reset password button is shown only to users who have permission to perform a password change operation, preventing unauthorized password reset actions via the admin UI. These changes address information disclosure and authorization/UI exposure concerns in the admin password management flow.

The commit fixes a log injection vulnerability in response logging by migrating remaining response logging to django.utils.log.log_response(), which escapes untrusted values like request.path before logging. It replaces direct uses of logger.warning for 405/410 responses with log_response(...) to prevent log payload manipulation. Tests are updated to verify correct escaping and logging behavior. Release notes also reference the CVE.

CVE-2025-48432: Escaped formatting arguments in log_response() to mitigate log injection via control characters in request.path. Previously, log_response logged formatting arguments (including request.path) without escaping, allowing CRLF sequences to be written into logs and potentially forge or disrupt log processing. The fix escapes all positional formatting arguments using unicode_escape before logging.

The commit patches ASGI header processing in Django to fix a potential Denial of Service (DoS) vulnerability related to repeated headers in ASGI requests (CVE-2025-14550). Previously, repeated headers could trigger repeated string concatenations while merging header values, potentially causing super-linear CPU usage and degraded service under crafted requests with many duplicates. The fix switches from per-header string concatenation to aggregating header values in lists (via a defaultdict(list)) and then performing a single join per header. It also normalizes HTTP_COOKIE separately and updates META with joined values, reducing the amount of repeated string processing. Tests add coverage for many repeated headers and ensure META is not excessively mutated, supporting a mitigation against DoS via crafted header sets. Documentation also references the CVE and classifies it as moderate severity.

CVE-2025-13473: Username enumeration through timing difference in mod_wsgi authentication handler. The mod_wsgi authentication path used by Django's check_password() could reveal whether a username exists by measuring response time differences. The patch introduces a helper _get_user(username) that returns None for missing or inactive users but, in those cases, runs the default password hasher once (via UserModel().set_password("")) to normalize timing. Consequently, the authentication pathway now incurs a similar cost regardless of whether the user exists or is inactive, mitigating a timing-based username enumeration vulnerability. This is a real vulnerability fix addressing a timing side-channel in the mod_wsgi authentication flow; the fix affects how check_password() behaves for non-existent or inactive users by standardizing hashing work, reducing exploitable timing differences.

CVE-2025-32873 describes a Denial-of-Service (DoS) possibility in Django's strip_tags() function. The fix adds a guard to strip_tags() to detect inputs containing large sequences of unclosed opening tags. If a long opening tag sequence is detected (based on a regex that matches a tag starting with a letter and lacking a closing '>' for 1000+ characters) and the number of opening angle-bracket markers ('<') within that match reaches or exceeds MAX_STRIP_TAGS_DEPTH (50), Django raises SuspiciousOperation. This prevents pathological inputs from causing excessive CPU usage during tag-stripping, addressing a potential DoS vector via crafted HTML-like input. Tests were added to ensure that inputs with many unclosed opening tags trigger the exception. The change is a real vulnerability fix and is not just a version bump or a test addition; it adds a concrete runtime guard and accompanying tests.

The commit adds input validation to FilteredRelation alias handling to reject any alias containing a period. Previously, an alias like 'book.alice' could be used in annotations, leading to unquoted identifiers in the SQL ON clause and potentially invalid or insecure query construction. The patch raises a ValueError when a dot is present in the alias, preventing problematic SQL generation. Tests were added to enforce this behavior (test_period_forbidden) and to ensure ordering tests expect a ValueError rather than a DatabaseError for such aliases.

The commit fixes a security-related input validation issue in URL redirects by increasing the maximum allowed redirect URL length. Previously HttpResponseRedirectBase used MAX_URL_LENGTH (2048) to guard redirects, which was too restrictive and could disrupt legitimate redirects to third-party services. The patch introduces MAX_URL_REDIRECT_LENGTH (16384) and uses it to validate redirect targets, addressing CVE-2025-64458. The change is not merely a dependency bump; it alters runtime validation logic and adds tests to cover redirects up to the new limit.

The commit implements a real security fix for CVE-2025-13372 by guarding against dollar signs in column aliases for PostgreSQL when using FilteredRelation. It adds a runtime guard in PostgreSQL's SQL compiler to prevent alias names containing '$' from being used, and augments tests/docs to reflect the security improvement. This is not merely a dependency bump or a cleanup; it changes behavior to mitigate a SQL injection surface related to alias generation in FilteredRelation on PostgreSQL.

The commit refactors GIS geometry widgets to remove inline JavaScript from templates and move initialization to external JavaScript. Previously, the GIS widgets rendered inline JavaScript in templates that interpolated template context values (e.g., geom_type, id, name, map_srid) directly into a JavaScript object and instantiated MapWidget. If any of these context values could be influenced by user input and not properly escaped in the JS context, this could lead to cross-site scripting (XSS) via injected script code in the resulting page. The fix removes the inline script blocks, uses json_script to pass data safely to a separate JavaScript file, and relies on a client-side MapWidget that reads data from a safe data container. This reduces the attack surface for XSS by avoiding inline script construction with untrusted data and moving initialization into external JavaScript.

The commit fixes an XSS vulnerability in escapejs by escaping additional control characters in the JavaScript escaping map. Previously, escapejs only escaped ASCII control characters below 32 (and 0x7F range may not have been fully covered), leaving characters in the C0/C1 ranges (0x7F-0x9F) potentially unescaped and usable to bypass escaping and inject inline JavaScript or break out of intended contexts. The patch broadens escaping to include 0x7F-0x9F and updates tests to cover these code points, hardening escaping of user-provided data embedded into JavaScript contexts within templates and JSON.

Genuine security fix. The commit modernizes Django's email handling to Python's email API and, crucially, adds strict address validation in the SMTP path to prevent header injection / CRLF-based header manipulation. The SMTP backend now calls prep_address to validate and canonicalize addresses, enforcing a single mailbox and performing (optionally) IDNA encoding for domains. It raises ValueError on invalid addresses, preventing injection attempts that rely on crafted addresses to inject extra headers (e.g., CRLF sequences leading to injected headers). This, together with switching to email.policy.SMTP for message construction, closes a class of header-injection vectors in django.core.mail. The changes also deprecate legacy API usage related to headers and address sanitization, further reducing attack surface.

CVE-2026-25674: Django fixes a race condition where process umask changes could affect permissions when creating filesystem objects (directories/files) in multi-threaded environments. The patch introduces safe_makedirs in django.utils._os and uses it in file-based cache and filesystem storage backends to apply explicit permissions (via chmod) after mkdir, removing reliance on the process-wide umask and preventing unintended permissions. This is complemented by tests validating safe_makedirs behavior. The change aligns Django with a CPython fix proposal to mitigate umask-related races when creating intermediate directories. Impact: Privilege/permission expansion or incorrect permissions on newly created filesystem objects due to race conditions around umask during directory creation. Affects code paths that create directories with explicit modes (e.g., file-based cache, storage backends) prior to this commit.

The commit enforces quoting of all database object names (tables, columns, and importantly aliases produced by annotate()/alias()) across ORM-generated SQL. Previously, some identifiers could be emitted without quoting (notably user-supplied aliases), which could be interpreted by the database in unsafe ways or enable bypasses when interfacing with raw SQL (e.g., RawSQL). The change switches all identifier quoting to a single quote_name() pathway, introduces memoization for quoted identifiers, and keeps quote_name_unless_alias as an alias for backward compatibility. This hardens SQL generation against crafted identifiers with special characters, thereby mitigating potential SQL injection vectors tied to unquoted identifiers. It also updates tests and documentation to reflect the new behavior.

The commit adds validation to prevent certain internal kwargs (_connector, _negated) from being propagated when expanding dictionaries into Q objects during ORM query construction. This blocks the ability to inject or influence Q semantics via dictionary expansion in filter/exclude calls, which could otherwise enable security bypass or information disclosure by altering the intended query behavior. The change introduces PROHIBITED_FILTER_KWARGS and raises a TypeError if any of these keys are present in the kwargs, plus a test verifying the rejection.

The XML deserializer in Django previously allowed nested tags inside field content when deserializing XML fixtures. The commit adds a guard that raises SuspiciousOperation when an element has child nodes (i.e., unexpected nested tags such as <em> inside a field value). This prevents crafting XML fixtures that might be misinterpreted or bypass validation during deserialization. The fix updates the XML deserializer (check_element_type) and gracefully propagates SuspiciousOperation through existing code paths, and adds tests/docs to reflect the change.

The commit fixes a log injection vulnerability in Django's runserver when handling NOT FOUND responses by centralizing log handling and escaping potentially malicious input in log messages. It migrates WSGIRequestHandler.log_message() to use a robust log_message() helper (based on log_response()) and escapes string arguments via unicode_escape, ensuring status_code handling is safe. This prevents crafted request content (e.g., ANSI control sequences or CR/LF) from altering log flow or injecting content into server logs. References CVE-2025-48432. The change includes an accompanying test that ensures control sequences are escaped in logs.

The commit fixes CVE-2025-64460: a Denial of Service (DoS) / performance vulnerability in Django's XML deserializer. Previously, the inner text collection in the XML deserializer used getInnerText() which recursively extended a list with the results from child nodes. This approach caused quadratic time complexity on crafted XML with deep nesting, enabling CPU consumption attacks. The patch splits collection of inner texts from the join operation by introducing a separate getInnerTextList() that collects per-subtree text, and only joins once at the end, reducing the overall complexity to linear in input size. It also includes a minor performance mitigation for minidom checks and wraps expandNode calls with a fast-path cache clearing. The change is targeted at the XML deserialization path used by fixtures/XML serialization.

The commit fixes a partial directory-traversal vulnerability in django.utils.archive.extract() (CVE-2025-59682). Previously, the code performed a naive path check using filename.startswith(target_path) after joining the archive entry name with the target directory. This could be bypassed when an archive member path started with the target directory name but resolved outside the target (e.g., an absolute path inside the archive like /tmp/evil.txt or a path such as /tmp/baseevil.txt). The patch replaces the check with os.path.commonpath([target_path, filename]) and raises SuspiciousOperation if the computed path is not within the target directory, effectively preventing extraction outside the intended directory. The change addresses partial directory traversal during archive extraction and is reflected in releases for affected branches (4.2, 5.1, 5.2).

The commit replaces a custom CSP middleware used in the Django admin Selenium tests with Django's official ContentSecurityPolicyMiddleware and configures SECURE_CSP to a strict policy. It also adds a test assertion to verify that no CSP violations are emitted in browser console logs. This is a defensive hardening fix addressing content security policy handling to reduce the risk of XSS in the admin interface stemming from misconfigurations in a custom CSP middleware, aligning admin CSP behavior with Django's built-in CSP support.

CVE-2025-59681: Django's QuerySet.annotate(), alias(), aggregate(), and extra() on MySQL/MariaDB could be vulnerable to SQL injection via crafted column aliases passed through dictionaries (via **kwargs). The commit updates the validation of column aliases to forbid unsafe characters (notably including '#'), adjusts the error messages, and adds tests. This directly hardens the code paths that interpolate user-supplied alias strings into SQL, preventing injection through the alias identifiers.

The commit moves the protected_environments configuration from a per-class scope (via class_attribute) to a global setting on the ActiveRecord module (ActiveRecord.protected_environments) and updates all checks to reference this global setting. Previously, database task checks referenced ActiveRecord::Base.protected_environments, which could be misaligned with subclass-specific configurations and lead to inconsistent protection against destructive actions in production. The fix ensures a single, global source of truth for production-destructive-action protection, deprecates the per-class accessors, and updates related code paths (migration checks, model schema defaults, and database task checks) to consult ActiveRecord.protected_environments. This reduces the risk that destructive actions could bypass protection due to scoping issues or per-class configuration. A deprecation path is provided for existing ActiveRecord::Base.protected_environments usage. Impact mirrors a configuration vulnerability rather than an remote-exploit, centered on ensuring destructive-action protection in production is consistently enforced across database tasks.

The commit improves handling of deserialization errors in the Rails cache layer to prevent unhandled exceptions when confronted with corrupted or truncated cache payloads. Previously, deserialization (Marshal-based) of cache entries could raise exceptions or crash the process if the payload could not be deserialized (e.g., due to memcached delivering a truncated payload). The patch ensures such errors are reported (via ActiveSupport.error_reporter) and treated as a cache miss rather than propagating an exception. It also introduces safeguards to raise a controlled Cache::DeserializationError for certain lazy-loading paths and to wrap deserialization during compressed payload loading with explicit error handling. Tests were added to verify that corrupted payloads result in error reporting and cache miss behavior, and that lazy-loaded values raise DeserializationError when payloads can’t be deserialized. This reduces risk from corrupted or crafted cache payloads and mitigates potential DoS or crash scenarios originating from deserialization of untrusted cache data.

The commit introduces a LeakChecker tool that snapshots the process environment before each test and compares it against the environment after test teardown. If there are any additions, removals, or changes to environment variables (excluding an allowlisted set), it fails the test run with a detailed message. This mitigates information disclosure risks where environment variables could be left set by one test and inadvertently exposed or influence subsequent tests, logs, or behavior.

The commit adds a LeakChecker tool that records ENV before_setup and after_teardown and fails tests if there are any ENV changes (excluding explicitly allowed keys). This mitigates risk of environment variable leakage across test boundaries, which could lead to information disclosure of sensitive data or internal configuration flowing between tests or into test logs. It represents a defensive hardening of the test harness rather than a patch to production code. The fix targets test isolation, reducing the surface area for information disclosure through ENV leaks in tests.

The commit fixes a race condition in atomic file writes by including a random suffix in the temporary file name. Previously, the atomic_write implementation could generate the same temp file name in concurrent writes, causing collisions, TOCTTOU-like behavior, potential data corruption or leakage. The random suffix ensures unique temp names per writer, reducing race conditions and ensuring safer atomic writes.

The commit fixes an information disclosure risk where the test suite could leak the sensitive DATABASE_URL environment variable by manipulating ENV directly in tests without proper scoping. The changes switch from ad-hoc ENV mutations to scoped blocks (with_env) to ensure DATABASE_URL is not leaked to the process environment or inherited by child processes during test execution. This reduces the chance that sensitive database configuration could be exposed via environment leakage in test logs, subprocesses, or interconnected test steps.

The commit prevents an information disclosure vulnerability where the Rails test suite could leak the DATABASE_URL environment variable. Previously, tests were setting ENV['DATABASE_URL'] globally, which could propagate to child processes or logging, exposing sensitive database configuration. The fix removes the global ENV manipulation and scopes the DATABASE_URL value within a controlled block using with_env, and it also removes reliance on a global config/database.yml in those tests. This ensures that DATABASE_URL is not unintentionally exposed during test execution.

The commit fixes an information-disclosure vulnerability where the DATABASE_URL environment variable could leak into the test environment. The previous approach relied on a YAML-based config (config/database.yml) and sometimes set DATABASE_URL globally, allowing leakage to test logs or leakage checks. The fix removes the YAML config, provides a helper to delete it, and scopes the DATABASE_URL usage to explicit blocks via with_env, ensuring credentials are not exposed outside the controlled test context.

The commit mitigates an information disclosure risk in the Rails test suite by stopping direct modification of the RAKEOPT environment variable and instead using a quiet execution wrapper. Previously, the test helper set ENV["RAKEOPT"] to a value (e.g., enabling --silent) and even restored it, which could lead to leakage of internal configuration/state through environment state visible in test logs or artifacts. The change removes the environment mutation (and the accompanying teardown of RAKEOPT) and relies on a quiet wrapper to suppress output, reducing the chance that RAKEOPT or related internal settings leak into logs.

This commit fixes a security vulnerability in ActiveStorage DiskService#delete_prefixed where a blob key containing glob metacharacters could be fed into Dir.glob, causing unintended file deletions. The fix escapes glob metacharacters in the resolved path and preserves a trailing separator when needed, preventing untrusted input from being treated as a glob pattern. It also adds tests demonstrating the escaped behavior and that only the intended files are deleted. The vulnerability aligns with CVE-2026-33202 (glob injection/path traversal).

The commit changes Action Pack's rescue_from handling to stop emitting exception backtrace information in the structured event payload for rescue_from events. Previously, the first line of the exception backtrace (sanitized by removing Rails.root) could be included in the event payload (and thus logged/observed via ActiveSupport notifications), leaking server filesystem paths (Rails.root) and other sensitive path information. The patch removes the backtrace from the emitted event payload entirely, reducing information disclosure risk via error handling logs/notifications.

The commit adds guards in Action View's tag_options to skip blank HTML attribute names across all three iteration paths (top-level options and inner data/aria hashes). This prevents rendering of attributes with empty names, which could lead to malformed HTML and potentially enable mixed or reflected XSS (mXSS). The change is accompanied by tests that reject blank keys in top-level options, data, and aria hashes, and a test ensuring blank attribute names do not appear in the output. The CVE reference CVE-2026-33168 and GHSA are cited in the commit. In short: this is a genuine security vulnerability fix for XSS via malformed HTML from blank attribute names in Rails' tag helpers; it prevents generation of attributes with empty names that could be exploited by attackers to inject code or bypass sanitizers.

This commit fixes an XSS in Rails' development debug exception page by escaping user-controlled exception messages when copied to the clipboard. Previously the exception message could be output with raw HTML inside a script tag used for the copy-to-clipboard feature, allowing HTML content to be injected if the message contained HTML. The patch replaces raw with default ERB escaping for the copied message and adds a test asserting escaping of the message (e.g., turning <script> into &lt;script&gt;). This mitigates a development-only XSS risk (CVE-2026-33167).

The commit targets a race condition (TOCTOU) in File.atomic_write by refactoring the operation to write atomically: introduce a random temporary filename via SecureRandom and open the temp file with EXCL to avoid overwriting an existing file, plus removing a heuristic that probed directory permissions. The intent is to prevent a window where an attacker could influence the destination file or its permissions during the atomic rename. However, the patch as presented appears to contain a bug: the computed random suffix (tmp_suffix) is not actually incorporated into the temporary filename (tmp_path), which means the temporary path may be deterministic across invocations. In that case, the intended race-condition mitigation may be ineffective and could even introduce instability in concurrent environments. The net effect, given the snippet, is ambiguous: while the approach aligns with TOCTOU mitigation, the missing random component undermines the security benefit and could break safe atomic replacement under concurrent access.

The commit implements a security fix for Active Storage Direct Uploads by filtering user-supplied metadata to strip internal-use keys (analyzed, identified, composed) from the metadata before persisting. Previously, metadata storage could include attacker-controlled keys that map to internal state, enabling parameter tampering and potential manipulation or leakage of internal blob state via DirectUpload metadata. The patch adds a PROTECTED_METADATA list, filters metadata in create_before_direct_upload!, and includes tests to verify the behavior.