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.

The commit patches ActiveSupport::NumberHelper::NumberConverter to reject strings containing scientific notation (digits followed by e or d, case-insensitive) when converting to BigDecimal. Previously, number inputs using scientific notation (e.g., "9e1000000" or similar) could be parsed by BigDecimal(number, exception: false), which can incur extreme resource usage (CPU/memory) and lead to denial-of-service conditions. The fix guards against such inputs by skipping BigDecimal parsing when the string matches /[de]/i. This aligns with the referenced CVE-2026-33176 and GHSA-2j26-frm8-cmj9, and the tests added in the patch validate that scientific notation inputs are treated as non-numeric rather than parsed as BigDecimal. Vulnerability type: Denial of Service (DoS) via input validation / BigDecimal parsing of scientific notation in NumberConverter. Affected code: activesupport/lib/active_support/number_helper/number_converter.rb (valid_bigdecimal) and related tests (activesupport/test/number_helper_test.rb).

Summary of the change: The commit hardens the Dockerfile template and related test fixture to run the Rails application in a non-root context and to ensure runtime files are owned by a non-root user. Specifically: - The Dockerfile template now creates a non-root user (rails) and sets USER rails:rails for the runtime stage. - COPY commands in the final image use explicit ownership (COPY --from=build --chown=rails:rails). - The test fixture Dockerfile now mirrors the non-root runtime setup and adjusts file ownership accordingly. What this fixes: Running containers as root inside a production image is a common security risk, as root inside a container can potentially be abused to escalate privileges within the container, or to exploit host/kernel features if combined with other misconfigurations. By ensuring the runtime process runs as a non-root user and by binding file ownership to that user, the surface area for privilege escalation is reduced when using Rails’ Dockerfile templates. Scope and impact: This affects applications scaffolded via Rails generators that include the Dockerfile template (railties/lib/rails/generators/rails/app/templates/Dockerfile.tt) and the related test fixtures (railties/test/fixtures/Dockerfile.test). Since the tracked version is 8.1.3, prior versions (< 8.1.3) would benefit from this hardening if they used the affected templates. It is a security-hardening improvement rather than a change in Rails core functionality. Assessment: This is a genuine hardening change that mitigates privilege-escalation risk in containerized deployments by avoiding root execution in the runtime image and by tightening file ownership. It is not a behavioral security bug in Rails’ runtime logic, but it aligns with best practices for container security. The change is not a pure dependency bump; it alters template/fixture code to improve security posture.

This commit is a genuine security fix. Previously, the Action Text Markdown link generation path (markdown_link) did not validate URI schemes, allowing attacker-controlled URLs with dangerous schemes (e.g., javascript:, data:text/html, etc.) to pass through in Markdown representations and potentially render unsafe links or images. The patch adds a URI scheme validation guard via Rails::HTML::Sanitizer.allowed_uri? inside MarkdownConversion.markdown_link, rendering disallowed URIs as escaped bracketed text (e.g., \[title\]) instead of emitting a link. It also centralizes image/link formatting through an image: keyword argument and updates several call sites (RemoteImage, ActiveStorage::Blob) to route through the same validation. Tests were added to cover allowed data:image URIs and the no-attachment fallback behavior, strengthening defense-in-depth against XSS in Action Text Markdown rendering.

The commit adds an InspectBackport module and uses instance_variables_to_inspect to limit what Object#inspect reveals on Ruby versions below 4.0. It replaces or augments previous custom inspect implementations that could leak internal state (e.g., @attribute, @type, @options) in various Rails components (ActiveModel, ActiveRecord, ActionText, etc.). This reduces information disclosure via inspect output and hardens public representations that could be exposed in logs, error messages, or debugging output. The changes include a new backport file (inspect_backport.rb) and conditional inclusion of the backport in classes for Ruby < 4, plus per-class instance_variables_to_inspect methods to control leaked state. Tests have been added to confirm that sensitive internals are not exposed via inspect.

The commit addresses a performance vulnerability in ActiveSupport::NumberHelper::NumberToDelimitedConverter related to formatting large numbers with a delimiter pattern. Previously, the conversion path always invoked a regular expression-based delimited insertion (via delimiter_pattern). This regex-based path can be computationally expensive and susceptible to denial-of-service-like CPU exhaustion on large inputs or crafted patterns. The fix introduces a guarded branch: if a delimiter_pattern is not present, it uses a deterministic manual grouping path (no regex) to insert delimiters; if a delimiter_pattern is present, it continues to use the regex-based approach. The change reduces exposure by avoiding regex-based processing for inputs where a straightforward grouping is possible, and adds tests asserting expected formatted outputs for edge cases (e.g., 1234 -> 1,234; 12345 -> 12,345).

The commit adds defensive error handling around deserialization of cached payloads in ActiveSupport::Cache. It catches deserialization errors during cache load (both uncompressed and compressed payload paths), reports the error via ActiveSupport.error_reporter, and, in certain paths, raises a Cache::DeserializationError (or ActiveSupport::Cache::DeserializationError) instead of allowing a deserialization exception to crash or be exploited. It also ensures that corrupted payloads do not trigger uncontrolled exceptions when loading cache entries, and updates tests to cover corrupted payload handling. This is a real vulnerability fix for deserialization-related errors in cache loading paths, mitigating DoS and potential gadget-based issues by validating/describing failures rather than leaking stack traces or crashing.

The commit fixes a use-after-free in the HTTP parser when freeParser() is called during llhttp_execute() while processing pipelined HTTP requests. If a synchronous 'close' event handler frees the parser mid-execution, the parser state is nulled while llhttp_execute() is still on the stack, which could crash on the next callback. The fix introduces an is_being_freed_ flag, sets it via parser->markFreed() in freeParser(), and makes Proxy::Raw abort callbacks if the flag is set, ensuring safe unwinding and preventing memory-safety crashes. A regression test was added to cover the scenario of two pipelined requests in one write.

The commit adds a setter for ClientRequest.path that validates assigned values against INVALID_PATH_REGEX, ensuring that path mutations (after construction) cannot inject unsafe characters into HTTP headers. Previously, path could be mutated post-construction without revalidation, potentially allowing CR/LF or other characters to reach _implicitHeader() and cause header injection/TOCTOU issues. The change includes a getter for path, validation on assignment, and regression tests confirming invalid mutations are rejected and valid mutations succeed.

The commit fixes a race where socket errors emitted in the early window between onSocket and onSocketNT could be unhandled if the user had not yet attached a request error handler. Previously, an error could be emitted on the socket before the request’s error handling was wired up, potentially causing unhandled error events and denial of service (process crash or degraded service). The fix attaches a synchronous socket error listener in onSocket, marks the socket with _httpMessage, and forwards errors to the request. It also guards the _destroy path in onSocketNT to avoid double-firing if the early listener already emitted the error. Additionally, the changes in net.js ensure synchronous destruction of sockets on various error paths (e.g., IP block, connect errors, timeouts) rather than deferring to the next tick, reducing the window during which such errors could be mishandled. The test mentions the case where a blocklist or synchronous lookup error could emit before the request error handler is set up and asserts the prevention of double-emission. Vulnerability type: Denial of Service (DoS) risk from unhandled socket errors leaking out before user error handlers are attached; potential crash due to unhandled error events. Affected versions: pre-25.9.0 (versions prior to this patch)

The commit patches a potential Denial of Service (resource exhaustion) vulnerability in minimatch by introducing a maximum expansions cap (EXPANSION_MAX) and allowing callers to supply a max option. Prior to this update (minimatch 10.1.1 and earlier), pathological glob patterns with brace expansions could trigger unbounded expansion, consuming excessive CPU and memory. The fix sets a default expansion cap of 1e5 and threads expansion through a max limit to prevent unbounded growth.

The commit fixes a race condition in HTTP keep-alive socket reuse between responseOnEnd() and requestOnFinish(). If the response ends before the request finishes writing, the socket might be released and subsequently reused by another request, leading to socket corruption or misrouting of requests. The fix adds a guard to requestOnFinish() so that responseKeepAlive() is only called if the request is not already destroyed (i.e., still alive). This prevents attempting to keep-alive a socket that has already been released, addressing a potential security-impacting race in connection reuse.

The commit mitigates a prototype pollution risk by avoiding calls to String.prototype.startsWith with user-controlled input in lib/internal/locks.js. The vulnerable code used name.startsWith('-'); if an attacker can mutate String.prototype.startsWith (prototype pollution), they can bypass the hyphen-prefix check by returning false, potentially allowing lock names starting with '-' to be processed.

The commit adds a default error handler for TLSSocket instances during TLS connection initialization (tlsConnectionListener). Prior to this fix, if a TLS socket emitted an error before the user attached an error handler, it could trigger an unhandled 'error' event, potentially crashing the Node.js process (DoS via crash). The new code attaches a listener for 'error' on the socket (socket.on('error', onSocketTLSError)) to ensure the error is handled even if the application does not attach its own error handler. This resolves a class of denial-of-service scenarios where a misbehaving or abruptly destroyed TLS connection during initialization could crash the server. The patch is tied to CVE-2025-59465 and represents a genuine vulnerability fix rather than a mere dependency bump or test addition.

The commit adds a network permission check in PipeWrap::Connect to enforce network-scoped authorization before initiating a pipe connect (PermissionScope::kNet). This change protects IPC/pipe connection paths from being accessed by untrusted code lacking net permissions, addressing an access-control vulnerability identified as CVE-2026-21636. Prior to this change, pipe_wrap.connect could be invoked without verifying network permissions, potentially allowing unauthorized processes or modules to establish network-related IPC connections.

The commit changes util.inspect's handling of Error objects to only consider own properties for the 'cause' and 'errors' fields. Previously, non-own (prototype-inherited) properties named 'cause' or 'errors' could be revealed by util.inspect due to the use of the 'in' operator. This could leak internal or prototype-level information when debugging errors. The fix aligns inspect behavior with other parts of the codebase by ensuring only own properties are considered for these fields, reducing the risk of information disclosure via error objects.

The commit adds a permission check around realpath.native for both async and sync code paths, enforcing FileSystemRead permissions before resolving a path. This fixes an authorization bypass where an unprivileged caller could trigger path disclosure by resolving arbitrary filesystem paths via realpath without the required read permission. The change aligns realpath usage with other FS operations by denying access when the caller lacks FileSystemRead permission.

What was fixed: The commit changes how util.inspect formats errors that are thrown by property getters. Previously, when a getter threw or when an error object had problematic properties, util.inspect could access err.message directly inside the catch block to build the inspection string. If err.message (or nested properties) used getters that throw or reveal sensitive data, this could lead to information disclosure or unexpected crashes during object inspection. The patch switches to formatting the entire error value using formatValue(ctx, err, recurseTimes) instead of directly using err.message, and it adjusts indentation around the getter handling. Tests were added to cover various edge cases, including nested causes, circular references, and unusual error values. In short, this is a real vulnerability fix for information disclosure via util.inspect when getters throw, and it adds safer, sanitized formatting for such errors.

The commit fixes a memory safety issue in the Latin1 path of Buffer.indexOf. Previously, IndexOfString used a heap allocation (UncheckedMalloc) for the needle in the LATIN1 branch, with an explicit free. If allocation failed or due to edge-case error handling, this path could be prone to memory-management bugs such as use-after-free or double-free scenarios. The patch replaces the heap allocation with MaybeStackBuffer, removing the explicit free and relying on stack allocation when possible, with a heap fallback managed by MaybeStackBuffer. This reduces memory-management risks in a hot path and improves overall memory safety for the Latin1 indexOf operation.

The commit replaces memcmp with CRYPTO_memcmp in HMAC and KMAC verification paths used by Web Crypto (HMAC and KMAC outputs). The previous non-constant-time comparison could leak information about how many initial bytes of the MAC were correct, enabling a timing attack to recover the MAC. The change fixes this by using a timing-safe comparison function (CRYPTO_memcmp) to compare computed MACs against supplied signatures.

The commit fixes a vulnerability where SNICallback invocation in loadSNI() could throw synchronously and remain uncaught, allowing a remote attacker to crash a TLS server by sending a crafted TLS ClientHello with a crafted server_name. The code previously invoked owner._SNICallback(...) without guarding against exceptions; the fix wraps the invocation in a try/catch and routes any error to owner.destroy(), completing CVE-2026-21637. This matches the triage and diff changes, and the test updates verify proper tlsClientError emission.

This commit fixes a memory leak/resource leak in Node.js HTTP/2 by ensuring Http2Session is destroyed when a GOAWAY is caused by an HTTP/2 flow-control overflow. Specifically, nghttp2 can return NGHTTP2_ERR_FLOW_CONTROL in OnInvalidFrame for a WINDOW_UPDATE that pushes the connection-level flow control window past 2^31-1. Previously, OnInvalidFrame only treated NGHTTP2_ERR_STREAM_CLOSED and NGHTTP2_ERR_PROTO as fatal, which could leave the Http2Session reachable but not properly destroyed after such a GOAWAY, leading to a memory leak. The patch adds NGHTTP2_ERR_FLOW_CONTROL to the fatal-condition check and destroys the session in that case. A regression test that reproduces the scenario (WINDOW_UPDATE on stream 0 causing overflow) is added to confirm the fix.

Summary of the fix: - The commit adds a permission check for Net scope in PipeWrap::Bind and PipeWrap::Listen. Specifically, it invokes THROW_IF_INSUFFICIENT_PERMISSIONS with permission scope Net (and, for Bind, uses the socket/path name as context) before binding or listening on sockets. This enforces access control for net-related operations (including UNIX domain sockets) and prevents unprivileged code from binding/listening to sockets without the Net permission. What was changed: - In src/pipe_wrap.cc, Bind now creates the socket name using the Environment and checks NET permission before calling uv_pipe_bind2. - Listen now checks NET permission before calling uv_listen. - Tests were added to ensure that unprivileged attempts to bind/listen to UNIX domain sockets throw ERR_ACCESS_DENIED with permission Net. Reason this constitutes a real vulnerability fix: - Prior to this patch, non-privileged code could potentially bind/listen on UNIX domain sockets or network listeners without a permission gate, enabling an authorization bypass around socket creation and binding. By introducing a Net permission check, Node.js now enforces explicit permission to perform net-related operations, aligning with a more robust authorization model and preventing unauthorized service binding or unauthorized listening on sockets as described in the CVE. Affected behavior prior to patch (assumed): - Unprivileged code could call net.createServer().listen('/path/to/socket') or tls.createServer().listen('/path/to/socket') and bind to a UNIX socket without Net permission checks. Security impact: - Type: Access control / Authorization bypass for net-related operations (UNIX domain sockets and network listeners). - Severity: HIGH (because it gates the ability to bind/listen to sockets by permissions, preventing potential privilege escalation or resource binding by unprivileged actors). - Affected versions: versions prior to 25.9.0 (i.e., < 25.9.0). Notes: - The commit references a CVE-2026-21711 and includes tests asserting ERR_ACCESS_DENIED with permission Net for unprivileged attempts. - The changes are not just a dependency bump or a minor refactor; they introduce a functional security gate and corresponding tests.

The commit fixes a prototype pollution vulnerability in the HTTP incoming parser. It ensures that the destination objects used to accumulate distinct headers/trailers (headersDistinct and trailersDistinct) are created with a null prototype (via { __proto__: null }) instead of a plain {}. Previously, if a request included a __proto__ header, dest["__proto__"] could resolve to Object.prototype. Since Object.prototype is truthy and may have a push method on its prototype in certain workflows, the code could end up calling .push() on Object.prototype, leading to a TypeError and a crash. The fix prevents pollution by ensuring the destination objects cannot inherit from Object.prototype and thus cannot be polluted by a __proto__ header.

The commit implements a real concurrency fix for a race condition in the DRA pending allocation sharing mechanism. Previously, the scheduler tracked in-flight allocations using a data structure (sync.Map, with additional sharing counters) and performed reads/writes to shared state without sufficiently protecting all paths. The patch switches to a guarded map protected by an explicit mutex (inFlightMutex) and introduces a defined inFlightAllocation struct to model an allocation plus a sharer count. It also refactors the accessors (GetPendingAllocation, SignalClaimPendingAllocation, MaybeRemoveClaimPendingAllocation, AddSharedClaimPendingAllocation/RemoveSharedClaimPendingAllocation) to ensure all reads and mutations to inFlightAllocations happen under the mutex. This eliminates the data race between concurrent readers/writers of pending allocations, preventing inconsistent state observations, incorrect allocations, misreporting of pending allocations, and potential information leakage between pods in a PodGroup sharing scenario. The change spans the DRA manager and related cycle state handling impacted by the DRA flow, addressing a security-relevant race condition in allocation sharing.

The commit fixes an out-of-bounds memory access in the key extraction path for KEYNUM commands when the command arity is incorrect. Specifically, it ensures arity is checked via commandCheckArity() before performing key extraction in luaRedisAclCheckCmdPermissionsCommand, RM_ACLCheckCommandPermissions, and related code paths. It also corrects the KEYNUM index calculation (first + keynumidx) and adds a bounds check in genericGetKeys(). Without these checks, a wrong-arity command using KEYNUM keyspec (e.g., EVAL) could access argv out of bounds and crash, leading to a denial-of-service via memory safety violation. The patch also adds tests to lock in non-crashing behavior for wrong-arity EVAL under ACL and scripting/module contexts.

The commit fixes an integer-overflow bypass in lpSafeToAdd by replacing the len + add > LISTPACK_MAX_SAFETY_SIZE check with an overflow-safe comparison (add > max or len > max - add). The old check could be bypassed when add is near SIZE_MAX and len is near the safety cap, allowing a listpack growth request that would exceed the 1GB safety cap to be considered valid. This addresses a memory-allocation size safety issue that could enable denial-of-service via large or crafted allocations.

The commit fixes a use-after-free memory safety bug in Redis' incremental kvstore rehashing path. When a dictionary (dict) is in a two-phase unlink state during deletion (dbGenericDelete path) and the rehashing process is active, deleting the last element could free the underlying dict object without properly signaling that rehashing has completed. This could leave kvstoreIncrementallyRehash operating on a freed (dangling) pointer during serverCron, leading to a crash. The fix adds calls to rehashingCompleted in dictRelease and dictEmpty so that every rehashingStarted has a corresponding rehashingCompleted, ensuring memory safety. A unit test was added to consistently catch this scenario. Vulnerability type: Use-after-free / memory safety in dict/kvs rehashing path. Impact: Potential server crash (denial-of-service via crash) due to use-after-free under specific rehashing/deletion timing conditions. Patch intent: Ensure proper pairing of rehashingStart/rehashingCompleted to prevent use-after-free during incremental rehashing.

The commit implements a hard cap and FIFO/LRU eviction for Lua scripts created via EVAL (not those loaded with SCRIPT LOAD). Previously, each EVAL call could generate and cache a new Lua script indefinitely, consuming memory in the server and Lua engine, enabling memory exhaustion/DoS under abusive usage. The patch introduces: - A bounded cache for EVAL-created scripts with a hard limit of 500 (LRU-like) and eviction of the oldest scripts when the limit is reached. - A per-script node to track position in the LRU structure, enabling quick eviction and reordering on use. - Eviction counting exposed via INFO (evicted_scripts) and memory accounting updates (lua_scripts_mem, etc.). - Changes to the Lua script lifecycle: luaDeleteFunction to remove evicted scripts from the interpreter and server state, and updates to free/maintenance paths to handle the new lua_scripts_lru_list. - Adjusted info/string output to include evicted_scripts and updated memory accounting for the eviction list. - Tests referencing number_of_cached_scripts and eviction behavior to verify the cap and eviction correctness. Impact: Reduces the risk of memory exhaustion/DoS from abusive EVAL usage by bounding the number of cached Lua scripts. The vulnerability type is memory exhaustion / DoS via unbounded Lua script caching. The fix is not a simple dependency bump; it changes internal scripting data structures, eviction logic, and metrics.