Alerts

The commit changes production error handling for all browser bundles to minify prod error codes/messages, reducing information leakage. It also expands the error code map (scripts/error-codes/codes.json) and flips minifyWithProdErrorCodes from false to true for multiple bundles. The resulting behavior is that production browser errors no longer expose verbose internal messages or stack traces, mitigating potential information disclosure about internal server/client boundaries and bundler details.

The commit changes the Data Hover UI rendering to sanitize and constrain link rendering in data-hover tooltips. Previously, values could be rendered as clickable links via a shared geomap/ui utility (renderValue) that wrapped URLs in an anchor tag without URL sanitization. The new approach introduces a dedicated renderValue implementation under data-hover that only renders http/https URLs and sanitizes the href via textUtil.sanitizeUrl, while leaving non-http/https values as plain text. It also adds an isHttpUrl helper and tests for it. In effect, this mitigates potential XSS via untrusted inputs in Data Hover tooltips by preventing execution of untrusted or malicious URLs and ensuring sanitized, safe anchor targets.

The commit adds an AllowsKind gate and configurable ScopeAttribute for ResourcePermission mappers, plus a storage backend exclusion of BasicRole for service accounts. Before this change, nil allowedKinds meant all permission kinds (including BasicRole) could be assigned to resources, enabling potential authorization bypass/privilege escalation by granting BasicRole to a ServiceAccount or other resource. The patch hardens RBAC by ensuring only whitelisted kinds are allowed for a given resource and scope, and by avoiding dangerous combinations in storage.

The commit moves BTF validation logic into a dedicated check_btf.c and wires it into the BPF verifier. It hardens handling of BTF-derived information for func_info, line_info, and core_relo, preventing malformed or inconsistent BTF attributes from bypassing the verifier's security checks. This is a genuine security hardening against potential verifier bypasses that could lead to code execution on crafted BPF programs. The change is not merely a dependency update or a cosmetic cleanup; it adds targeted validation paths and integrates them with the verifier flow.

The commit fixes a race condition in the pending-delete cleanup flow for tenants in Grafana's Unified Storage. Prior to this change, the pending-delete lifecycle could be mishandled during cleanup, potentially allowing a tenant to be recreated or left in an inconsistent state while the cleanup is in progress. The patch introduces a DeletedAt timestamp and an Orphaned flag to differentiate between orphaned and non-orphaned pending-delete records, and adjusts deletion logic to guard against reprocessing and unintended recreation. Key points addressed: - Added DeletedAt to PendingDeleteRecord. Non-orphaned records are marked DeletedAt after successful deletion, preventing reprocessing by the tenant deleter. - Reconciler now propagates Orphaned flag instead of Force, and clear logic skips orphaned records rather than forcing skip behavior. - Non-orphaned records are not re-created during cleanup because the tenant deleter will mark them DeletedAt and skip reprocessing. - Tests updated to reflect new behavior (DeletedAt set after expiry, orphaned records removed entirely, etc.). Affects scenarios where a tenant could be concurrently cleaned up and re-considered by the watcher, creating a timing window for inconsistent deletion state. The fix provides deterministic cleanup semantics by ensuring DeletedAt gates further processing and orphaned records are handled distinctly.

The commit standardizes NotFound error handling for annotations across in-memory, SQL, and Kubernetes adapters. It maps internal NotFound errors to API-level NotFound responses and avoids leaking whether a resource exists when access is restricted. Previously, error messages or HTTP statuses could disclose existence or details about resources, enabling resource enumeration. The changes aim to minimize information disclosure by returning uniform NotFound responses for missing resources (and related permission scenarios) rather than revealing existence through mixed error messages or statuses.

The commit adds an optimization in ActiveSupport::ParameterFilter to detect anchored exact-match regular expressions and treat those keys as exact matches to be masked. Specifically, it introduces extract_exact_key to derive a literal key from anchored patterns like /^token$/ or \Atoken\z and stores these in an @exact_keys hash. During filtering, if a key exactly matches one of these literals, or if a general regex matches the key, the value is masked. This reduces the risk of information disclosure by ensuring that sensitive parameter names that are intended to be masked (even when specified with anchored exact-match regex) are reliably hidden across both top-level and nested parameter structures. The change also adds a test for anchored exact-match regexp filters to verify the behavior.

The commit fixes a race/resource-leak in the write concurrency limiter. Previously, Read() could decrease the available concurrency tokens (via DecConcurrency()) and, if IncConcurrency() failed, the token would not be re-acquired, potentially leaking a slot permanently. This could drain the concurrency limiter channel over time, eventually causing ingestion to deadlock when no slots remain. The patch adds per-reader tracking of whether a token has been obtained (increasedConcurrency) and ensures tokens are released correctly when the reader is returned.

The commit adds a validation guard in ParseDataKeyParts to ensure the resource version metadata (rvMeta) contains at least 3 tilde-separated parts before accessing rvParts[1] and rvParts[2]. Previously, crafted or malformed rvMeta values with only 1 or 2 segments could lead to an index-out-of-range panic when parsing storage KV keys, potentially crashing Unistore and causing a denial-of-service condition or information leakage. The change is accompanied by tests covering edge cases and panic avoidance.

The commit changes public dashboards to avoid reusing a session-scoped scene cache and to build the dashboard scene from API data instead of cached scene data. Before this fix, public dashboards could be loaded from a per-session cache, risking information disclosure or leakage across sessions if a cached scene containing user/session-specific data was reused for another user or session. The fix ensures public dashboards are not pulled from the session cache and are constructed from API data, reducing stale or cross-session data exposure and aligning authorization context with the API response. This is a genuine vulnerability fix for cache mishandling related to public dashboards.

The commit fixes a UI-driven information-disclosure risk in the Grafana Connections landing page. Previously, the landing page derived its cards from a hardcoded CardData.ts, which did not reflect actual backend visibility (RBAC) or plugin availability. This could cause a user to see cards for resources they should not access, effectively leaking the existence (and structure) of restricted plugins or data sources. The patch derives landing page cards from the backend-provided navIndex (which applies full plugin availability and RBAC checks) and enriches the card data via a metadata map. This aligns UI visibility with backend access control and edition-specific copy, reducing information disclosure and preventing exposure of inaccessible items.

The commit adds v2-specific sanitization for public dashboards to strip potentially dangerous fields from query specs for v2 dashboards, preventing injection or leakage of query expressions. It introduces isDashboardV2 and sanitizeDataV2 and uses them in GetPublicDashboardForView, so v1 dashboards continue using existing sanitization. This appears to be a security-conscious change aimed at avoiding execution or disclosure of user-provided query expressions in v2 dashboards when served via public dashboards.

The commit refactors RBAC checks for snapshot operations to use general dashboard actions instead of per-snapshot actions. Specifically, it replaces references to dashboardsnapshots.ActionSnapshotsCreate/Delete/Read with dashboards.ActionSnapshotsCreate/Delete/Read and adjusts evaluators to require both the create/delete/read action and the corresponding dashboards read permission with the correct dashboard scope. This aligns authorization checks across dashboards and snapshots, reducing the risk of misconfigurations allowing unauthorized access to snapshot functionality. In prior versions, mismatch between snapshot-specific actions and roles could permit unintended access or block legitimate access, depending on how roles were defined.

The commit removes legacy access control logic and related permissions imports used for annotation/dashboard access checks, replacing them with a newer access control path. Specifically, it eliminates the old RBAC filter (NewAccessControlDashboardPermissionFilter) insertion into SQL query construction and stops passing legacy Filters to the dashboard search. This appears to be an authorization hardening effort intended to unify access control checks under a newer mechanism (OpenFGA-based path mentioned in code comments). While the code changes suggest removing a potential bypass route from the legacy ACL checks, the exact security impact depends on the surrounding new authorization path being correctly enforced in all call sites. The triage notes indicate the intent to mitigate bypasses in legacy ACL checks for annotations and dashboards.

The commit contains a targeted fix in the Android binder driver related to VMA (vm_area_struct) handling and vm_ops identity checks. Specifically: - binder/page_range.rs wraps the static vm_operations_struct in a Sync-enabled wrapper (AssertSync) and adjusts the identity check to compare the vm_ops pointer against the inner value (BINDER_VM_OPS.0) rather than the wrapper object. - binder/rust_binder_main.rs defines a small AssertSync<T> wrapper and makes the inner type Sync, ensuring the global C binding type is treated as Sync, with a clarified safety comment. - These changes fix a potential memory-safety issue where an incorrect or non-atomic comparison of vm_ops could lead to misidentification of a VMA, potentially allowing use-after-free or memory misuse in binder IO/vma handling. The vulnerability is described as a memory-safety (use-after-free) risk in the kernel binder VMA handling, mitigated by making the vm_ops identity check precise and ensuring correct Sync semantics for a global C-binding struct. Affects pre-fix 7.0-rc6; fixed in 7.0-rc7 and related patches.

The commit adds a guard in When.__init__ to prevent internal keyword arguments (_connector, _negated) from propagating to Q(**lookups). If such invalid kwargs are present in the lookups passed to When, it raises a TypeError with a descriptive message listing the invalid kwargs. This is defensive input-validation hardening in query construction to prevent misuse of internal flags during query building. The change appears to be a genuine fix focused on validating inputs rather than a general code cleanup or a test-only change.

The commit hardens warning output by caching and reusing internal Django file prefixes and using skip_file_prefixes to suppress Django’s own filesystem paths from warning traces. Previously, certain warnings could leak internal Django file paths in stack traces (information disclosure). The change introduces django_file_prefixes() to return a tuple of internal Django prefixes and updates warning calls to pass these prefixes, effectively filtering out Django’s own path components from warning output. This reduces leakage of internal filesystem structure in error/warning messages.

The commit fixes a bug in multipart header parsing where the parser could be fed the entire header line (including the header name) instead of just the header value. This could lead to incorrect parsing or misinterpretation of header parameters for multipart requests. The change tightens input handling by splitting the header line at the first colon and only passing the value portion to parse_header_parameters, ensuring the header name is not mis-parsed as part of the value. A test asserting proper handling of malformed headers (e.g., spaces around the colon) was added to validate robust parsing.

The commit fixes an edge-case in ASGIRequest.path_info calculation. Previously, the code derived path_info by simply removing the script_name prefix from the request path (using removeprefix). This caused incorrect path_info for request paths that start with the script_name but do not have a slash boundary immediately after it. Example: path "/rootprefix/somepath/" with script_name "/root" would incorrectly strip "/root" and yield "prefix/somepath/". The new logic only strips the script_name when the path starts with script_name + "/" or when the path exactly equals script_name. Otherwise, it preserves the full path. This prevents miscomputation of path_info that could lead to unintended access to resources or leakage of path data, addressing a path handling vulnerability.

The commit implements propagation of the ORM's fetch_mode state across related objects when traversing relationships. Previously, fetch_mode restrictions applied to the top-level queryset but were not consistently propagated to related objects fetched via relationships (forward and reverse). The patch copies the fetch_mode from a source instance to related objects in multiple code paths (prefetching, related descriptors, and query iteration), and updates tests and docs to reflect that fetch modes apply to an entire object graph, not just the initial model. This reduces the risk of information disclosure or access-control bypass where related objects could be fetched under a different (potentially less restrictive) fetch_mode. The triage notes align with this being a security fix improving consistency and enforcement of fetch-mode-based access controls across related fetches, rather than introducing a new feature.

The commit introduces Action Text Markdown conversion and a safety mechanism for links during Markdown rendering. It adds to_markdown conversions across Content, Fragment, RichText, and Attachments, plus a new MarkdownConversion module that converts HTML to Markdown. Crucially, it enforces that Markdown links are filtered against Loofah's allowed URI protocols to prevent unsafe schemes (e.g., javascript:) from appearing in output. This mitigates a potential XSS/vector risk where attacker-supplied content could be transformed into unsafe Markdown links and rendered in a way that executes script code. The vulnerability is mitigated by disallowing dangerous protocols and stripping unsafe link representations during Markdown generation.

This commit implements explicit cleanup of environment variables to prevent ENV leakage across processes and test boundaries. Specifically, it changes the migrations task to delete ENV['FROM'] after use and uses the deleted value for logic, reducing the risk that the value remains in the process environment. It also strengthens test cleanup by removing or restoring ENV['RAILS_ENV'] (and related vars) in teardown and via helpers, ensuring environment vars are not leaked into child processes. Collectively, this reduces potential information disclosure where sensitive data or configuration exposed in ENV could be inherited by spawned processes or future operations.

The commit changes Rails' atomic file write to use a temporary file name that includes a random suffix. Previously the temporary file name was effectively predictable (based on the target file name) and could be pre-created by an attacker in the same directory, enabling a TOCTOU/race condition or a symlink-like interference during the atomic write. The patch mitigates this by appending a random suffix to the temporary file name, reducing predictability and lowering the likelihood of successful pre-creation or race attacks. Tests were added to verify that two atomic writes produce unique temp file names, reinforcing the security intent.

This commit centralizes the protected_environments API by moving it from ActiveRecord::Base to ActiveRecord, defaulting to production, and introducing deprecation warnings for older usage. This hardens protection against destructive migrations by ensuring a single, canonical source of truth for environment-based restrictions and guiding developers to migrate usage. It reduces the risk of accidentally allowing destructive actions in non-production environments due to API scoping mistakes or legacy code paths. The tests are updated to reflect the new API usage and to signal deprecation for the old path.

The commit adds guard_load_hooks in ActionPack Railties to guard/whitelist the loading of hooks for ActionController and ActionDispatch. This hardening mitigates potential code execution paths via user-controlled or misconfigured load hooks during Rails initialization. By restricting which hooks can be loaded (and likely when), it reduces the risk that arbitrary code could be executed at boot or during initialization from external components. The fix appears to be a defensive measure to prevent abuse of Rails' hook-loading mechanism, rather than a fix for a widely-known external vulnerability; its impact depends on whether untrusted code can register or inject load hooks that Rails would execute during startup.

The patch targets a potential information disclosure during middleware stack construction by altering how the Flash middleware attaches its request methods. It moves the inclusion of Flash::RequestMethods behind an ActiveSupport.on_load(:action_dispatch_request) callback and removes an eager require of action_dispatch/request/session. This lazy-loading approach prevents early exposure or leakage of request/state objects while the middleware stack is being built, reducing the risk of information leaking across requests via the request object.

The commit refactors File.atomic_write to reduce TOCTOU/race-prone behavior and preserve permissions when writing a file atomically. The previous approach relied on a Tempfile-based path and a prior permission probing mechanism. The new code: - Uses a securely named temporary file with a random hex suffix (SecureRandom.hex) in the destination directory, avoiding deterministic names that could be guessed by an attacker. - Creates the temp file with exclusive creation (EXCL) to prevent races where a file could be created between checks and use of a non-unique name. - Captures the original file's permissions (old_stat) beforehand and applies them to the new file, ensuring the destination ends up with the intended permissions. - Cleans up on error (closes and unlinks the temp file) to prevent leaks. - Removes the previous probe-based permission check (which created a temporary file in the target directory to infer default permissions), reducing side effects and potential information disclosure. This addresses race conditions in atomic writes by ensuring the temporary file is securely created, with proper cleanup and permission handling, and by avoiding a race-prone path that could leak information or grant unintended permissions.

The commit adds escaping of CommonMark markdown metacharacters in Action Text markdown generation to ensure text nodes are treated as literal text by Markdown renderers, reducing the risk of XSS via injected markdown formatting. It introduces ActionText::MarkdownConversion.escape_markdown_text, updates Content#to_markdown to wrap attachment markdown in an action-text-markdown element (so content is passed through without escaping), and adjusts how markdown links are rendered to escape their text. Overall, it hardens markdown rendering against user-supplied content that could otherwise be interpreted as formatting (e.g., headings, links, or other markdown constructs) and potentially lead to XSS when rendered by a Markdown processor.

The commit changes the default middleware stack to only insert Rack::Sendfile when x_sendfile_header is configured. Previously Rack::Sendfile could be added to the stack with a nil header, which risks misconfiguration and potential information disclosure or exposure of internal file handling details. The fix ensures Rack::Sendfile is not in the stack unless a valid x_sendfile_header is set, reducing the chance of unintended file serving or exposure of internal paths.

The commit hardens parsing of sourceMappingURL for dynamic imports. Previously, code resolved the source map URL using new URL(sourceMappingURL, sourceURL).href, which could incorrectly accept malformed URLs and proceed to load source maps, potentially leading to crashes or unsafe behavior during dynamic imports. The fix introduces a dedicated URL parser (URLParse) and a null-check to reject invalid URLs early, preventing processing of invalid source maps and reducing attack surface. An accompanying test validates that invalid URLs are tolerated rather than causing crashes.

This commit upgrades undici to 7.22.0 and includes several security-relevant changes that address proxy boundary handling, credential parsing, and websocket upgrade handling. Key points: - EnvHttpProxyAgent no_proxy handling: improved logic to avoid proxying requests when the destination hostname matches the no_proxy rule or is a subdomain, reducing information disclosure and unintended proxy usage for internal hosts. - includesCredentials fix: in fetch/util.js, the function now treats a URL as containing credentials if either the username or the password is present (previously required both). This fixes incorrect handling of URLs like http://user@host/ and http://user:pass@host/, which could affect credential handling in cross-origin contexts or proxy scenarios. - Other related fixes in cache/deduplicate/web fetch code and websocket upgrade handling were also touched. Collectively, these changes address potential security issues around proxy usage leakage and credential handling, rather than being purely cosmetic or dependency version bumps. Affected attack surface includes proxy boundary bypass (information disclosure) and credential handling in URLs (security policy correctness).

The commit hardens Node.js embedding path by enabling embedder-specific handling for dynamic module loading. It adds an embedder module descriptor (embedder_module_hdo) and a new SourceTextModuleTypes with kEmbedder, and switches embedder-run modules to compile with a dedicated type (kEmbedder). The embedding flow now restricts dynamic module imports in embedder context to built-in modules only, via getBuiltinModuleWrapForEmbedder/loadBuiltinModuleForEmbedder, preventing embedder-supplied code from loading arbitrary or external modules. This appears to be a real security hardening rather than a mere cleanup or test addition. It affects the embedder path of dynamic module loading and import.meta initialization, reducing the attack surface where an attacker could influence module loading from an embedder-supplied module.

The commit hardens input validation for the internal stack-calling utility by enabling V8 internal checks (-DV8_ENABLE_CHECKS) and constraining frameCount to be an integer within [1, 200]. It changes: (1) lib/util.js to use validateInteger for frameCount instead of validateNumber; (2) GetCallSites path in src/node_util.cc to require an unsigned 32-bit frameCount value (IsUint32) and enforce the range; (3) tests to require integer frameCount (non-integers like 3.6 now throw ERR_OUT_OF_RANGE); (4) minor type-correctness fixes in several files to align with strict input handling. The net effect is to prevent non-integer or out-of-range inputs from being treated as valid, which reduces the risk of memory-safety issues or crashes due to invalid stack-capture inputs. This is a hardening of input validation and runtime checks rather than a feature addition. It addresses security-relevant input validation and memory-safety concerns.

The commit implements memory-allocation failure handling for ArrayBuffer BackingStore usage across several Node.js internals (encoding_binding.cc, node_blob.cc, node_buffer.cc). Previously, allocation failures could result in unchecked pointers or crashes due to relying on an assumption that a backing store (bs/store) would always be non-null (e.g., CHECK(bs);). The patch adds OnFailureMode for backing stores, checks for null returns, and throws a memory-allocation error (ERR_MEMORY_ALLOCATION_FAILED) which is now a RangeError to align with V8's OutOfMemory error type. It also updates ERR_MEMORY_ALLOCATION_FAILED in node_errors.h from a generic Error to a RangeError. This reduces the risk of memory-safety issues (null dereferences or use-after-free) when memory allocation fails during operations like Encoding to UTF-8, Buffer.concat, or ArrayBuffer creation. While not a classic security flaw like XSS/SQLi, it mitigates memory-safety vulnerabilities that could be exploited via resource exhaustion or crashes under memory pressure, which can have security implications in production environments.

The commit introduces stricter HTTP token validation in undici (token character whitelist, updated isValidHTTPToken, and related utility changes). This hardens header-token handling and input validation to reduce the risk of malformed header values or token-based injection in HTTP requests. In particular, it adds a validated token character map, replaces per-character checks with a mixed per-char/regex approach, and tightens what is considered a valid HTTP token. These changes address potential weaknesses where previously permissive token parsing could allow anomalous tokens to bypass validation, potentially enabling header injection or related attacks via crafted header tokens. The upgrade to undici 7.18.2 includes this hardening alongside other stability fixes.

The commit includes a real code fix in the undici fetch path: when handling a 401 authentication scenario in browsers, the fetch logic now returns a network error instead of retrying, to prevent an infinite loop of re-sending requests after browser prompts for credentials. This mitigates a potential Denial of Service due to looping retries, and is accompanied by a dependency bump from undici 7.19.0 to 7.19.1. While the core change is a robustness guard, it targets a security-sensitive control flow and reduces the risk of resource exhaustion in adversarial or misbehaving environments.

The commit changes fs.rmSync to use std::filesystem::symlink_status instead of status when determining what to remove. The previous behavior used status, which follows symlinks, potentially dereferencing the symlink and exposing a risk where removal could act on the target of the symlink (or fail to handle broken symlinks safely). The fix ensures the operation considers the symlink itself (not its target), and adds tests that broken/invalid symlinks are handled safely by removing the link itself. This mitigates security concerns around symlink handling, containment, and race conditions in removal operations.

The commit hardens the internal proxy inspection logic used by util.inspect to avoid triggering proxy traps during inspection, especially for nested or revoked proxies. Previously, inspecting Proxy objects could inadvertently trigger traps or reveal internal state through the inspection path, creating side effects or information disclosure during debugging. The fix ensures that nested proxies are properly unwrapped without invoking traps and that revoked proxies render a safe placeholder, reducing security-relevant side effects when developers inspect objects.

The commit fixes how the nghttp2 tarball's detached signature is verified during dependency update. Previously the script piped the detached signature data (via STDIN) into gpgv together with the tarball path, which relied on STDIN for the signature and could be brittle or susceptible to misinterpretation or edge-case issues in signature verification. The fix downloads the detached signature to a file and invokes gpgv with both the signature file and the tarball file as explicit arguments, ensuring proper cryptographic verification of the downloaded dependency. This reduces the risk of signature verification bypasses or misverification during dependency updates.

The commit replaces uses of the public/user-mutable URL.parse with the internal URLParse in core code paths that parse URLs from untrusted input (e.g., socketaddress.js and test runner mocks). It also adds an ESLint rule to enforce using URLParse instead of URL.parse. This hardens URL handling by avoiding reliance on the potentially mutable URL.parse API, reducing risk from input misparsing, normalization issues, or downstream logic vulnerabilities related to URL handling.

The commit consolidates all asymmetric key import paths (DER/PEM, JWK, raw) into a single KeyObjectHandle::Init entry point with a uniform signature and centralizes key material validation via validateJwk across multiple formats. It removes per-type Init* methods and reduces JS-C++ round-trips for key material handling (e.g., createPublicKey/createPrivateKey/sign/verify). This hardens the key import/validation surface, reducing the likelihood of mis-parsed or improperly validated key material being used across formats (DER/PEM, JWK, raw). It is a security hardening/fix rather than a pure refactor or a new feature.

The commit refactors WebCrypto AEAD authentication tag handling for AES-GCM/OCB and ChaCha20-Poly1305. It removes ad-hoc extraction of the authentication tag from the input and standardizes tag handling across JavaScript and native code. This fixes potential vulnerabilities related to improper or inconsistent processing of authentication tags during decryption (and tag length usage), reducing the risk of AEAD bypass or tag misvalidation.

The commit includes a real fix to how undici constructs the HTTP request path used when dispatching a fetch in the HTTP client. Previously, the path was derived by slicing url.href, which could drop an explicit trailing '?' that denotes an empty query string. The patch reconstructs the path as url.pathname + url.search and adds a guard to preserve a trailing '?' when present. This hardens URL/path handling in the HTTP client, reducing edge-case discrepancies that could lead to misrouting or injection-like issues in some servers or proxies that distinguish /path from /path? (empty query). Although this is implemented as a dependency update to undici, it changes core URL handling logic and fixes a vulnerability surface related to URL construction in fetch paths.

The commit addresses a data race in the Dynamic Resource Allocation (DRA) pending allocation sharing path by refactoring in-flight allocation tracking to be guarded by a mutex and by switching from a sync.Map-based approach to a map guarded by an RWMutex. The changes introduce a dedicated inFlightMutex, an inFlightAllocation struct (holding a claim and a sharers counter), and updated accessors (GetPendingAllocation, SignalClaimPendingAllocation, MaybeRemoveClaimPendingAllocation, etc.). This is intended to prevent concurrent readers/writers from corrupting the in-flight allocations map and to ensure consistent sharing/removal semantics across concurrent scheduling cycles. While not a classic external-facing vulnerability, race conditions in scheduler state can cause inconsistent state, misallocation, or timing-related vulnerabilities in a concurrent system. The change is a genuine security-quality fix aimed at eliminating data races in the allocation-tracking mechanism.

The commit fixes a data type conversion bug in zrangeResultBeginStore where a length of -1 (meaning unknown) could be passed through to zsetTypeCreate. After a prior change (#12185), -1 would be interpreted as SIZE_MAX, leading to a pathological path in dictExpand and potentially causing memory safety issues or incorrect encoding (dst key switching from listpack to skiplist). The fix clamps negative lengths to 0 to avoid passing -1 into zsetTypeCreate, improving memory safety and correctness in zrangestore-related paths (including cases where the zrangestore source does not exist or BYSCORE/BYLEX is used). This is a genuine vulnerability fix rather than a mere dependency bump or cleanup.

The commit adds validation of node IDs in cluster gossip messages. Each gossiped node ID is checked with verifyClusterNodeId, and any invalid IDs cause the gossip section to be discarded and a debug log to be emitted with the corrupted data. This prevents potentially malformed or corrupted node information from propagating through the cluster, which could lead to memory safety issues or inconsistent cluster state when processing gossip data. The fix uses existing validation logic and introduces an early return when invalid IDs are detected.

During RDB loading of binary quantized vectors, the code computed the number of bytes per vector using a simplistic expression: dim * (quant_type == HNSW_QUANT_Q8 ? 1 : 4). This could yield an incorrect vector_bytes for certain quantization configurations. The mismatch between vector_len and vector_bytes would only trigger a warning but not necessarily abort processing, leaving a potential path for out-of-bounds memory access or data corruption when deserializing vectors. The patch replaces the calculation with hnsw_quants_bytes(vset->hnsw), which derives the correct per-vector byte size from the current HNSW quantization settings, ensuring the bounds check is correct during RDB loading and preventing memory safety issues.

The commit adds validation and bounds checking for the HNSW M parameter used when creating vector sets, plus defaulting and consistency checks across a vector set. Previously M could be configured without bounds, which could lead to uncontrolled memory allocations and potential memory safety issues when creating or loading HNSW indexes (especially when loading from RDB). The fix introduces HNSW_MIN_M and HNSW_MAX_M bounds, requires M to be within these bounds, ensures M consistency across a vector set, stores M in RDB, and defaults M when loading older RDB files. This reduces the risk of memory exhaustion or memory corruption via oversized M values.

The commit fixes memory-safety issues in kvstore handling for empty kvstores and for kvstoreIterator usage without advancing the iterator. Specifically: - kvstoreGetFirstNonEmptyDictIndex() now returns -1 when the kvstore is empty, avoiding an incorrect assumption that a non-empty dict index exists during defragmentation. - kvstoreIteratorReset() now guards against freeing a dict when the iterator’s didx is -1, preventing potential out-of-bounds access when an iterator is initialized but never advanced via kvstoreIteratorNextDict(). These changes convert previously defensive-but-flawed behavior into robust bounds checks, addressing a memory-safety vulnerability surface (out-of-bounds access) in kvstore iteration/defragmentation logic. The patch also adds a unit test to exercise the case where an iterator is created and released without calling Next. Overall, this is a real vulnerability fix (memory safety) rather than a dependency bump or purely cosmetic change.

This commit appears to introduce a configurable lookahead pipeline for parsing and prefetching commands, along with a security constraint that limits lookahead depth for unauthenticated clients to 1. The intent is to mitigate a potential Denial of Service (DoS) vulnerability where unbounded or large prefetch/lookahead could exhaust server memory when handling many concurrent or pipelined clients. The changes include adding a new lookahead configuration (default 16) and reducing lookahead for unauthenticated clients, effectively constraining memory usage under attack scenarios. While the changes are architectural and performance-oriented, the explicit security note and safeguards indicate a vulnerability mitigation rather than a simple dependency or cleanup.

The commit replaces a normal dict iterator with a safe iterator for enumerating module configurations. This mitigates a class of memory-safety bugs that occur when the module configuration dictionary is mutated during iteration (e.g., another module or code path adds/removes config entries while iterating). Without a safe iterator, concurrent modification can lead to invalid memory access or a crash, which is a security-relevant DoS/stability issue. The change is a targeted hardening of the iteration path used when enumerating module configurations.

The commit appears to fix a race condition in the HNSW optimistic insert path by moving the node value assignment from the preparation path into the commit path and making the CAS-based commit atomic. Previously, the code assigned node->value during the nolock preparation phase, which could race with concurrent inserts and lead to inconsistent state or data races when multiple threads attempt to insert concurrently. The patch ensures that the value is only associated with a node during the commit phase (or full-lock path), reducing the window where another thread could observe or overwrite a partially prepared insertion. This is a genuine concurrency/atomicity fix in the insertion path for HNSW components used in vector/search contexts. Impact/Severity: This is a correctness fix for a concurrency issue in the HNSW insert path. If the race manifests, it could lead to inconsistent node values or graph state during concurrent inserts, which in worst cases could be observed by clients or lead to data corruption. Because this relies on timing and concurrent access, the exploitability is not straightforward but is non-trivial in highly concurrent workloads. Therefore, the vulnerability type is a race condition with potential data/state corruption risk in concurrent insertion paths. The exact CVSS-like severity would depend on exposure and impact of corrupted graph state in deployed deployments, but it is plausible to be MEDIUM in typical scenarios. Vulnerability type: Race condition / concurrency issue in HNSW CAS commit path.

The commit fixes data race conditions surfaced by ThreadSanitizer (TSAN) in Redis by replacing non-atomic volatile sig_atomic_t usages with atomic types and guarding access to shared state (e.g., server.crashing, server.shutdown_asap, last_sig_received). The root cause was unsynchronized reads/writes to server state across signal handlers and the main thread, which could lead to undefined behavior, crashes, or inconsistent server state under concurrent signal delivery. While not a classic external vulnerability like RCE, data races in a multi-threaded server can create unstable behavior that could be exploitable under certain conditions or lead to crashes that affect availability or integrity. In short, this is a real vulnerability fix in the sense of hardening against race conditions and undefined behavior in multi-threaded execution, reducing the risk of crash-induced security issues or misbehavior under concurrent signals.

The commit adds a guard in smembersCommand for set replies to detect a mismatch between the declared length (via addReplySetLen) and the actual number of elements sent. Previously, if a corrupted or mismatched length occurred (e.g., due to a corrupted dump, a bug in set iteration, or protocol desynchronization), the server could desynchronize the Redis protocol and cause the client to hang while waiting for more elements. The fix introduces a length counter initialized to the actual set size, decrements it as elements are sent, and asserts that the remaining length is zero after finishing. This prevents proceeding with a broken reply and turns a potential hang into a detectable failure (assert), mitigating a Denial-of-Service vector caused by protocol misbehavior. The change is accompanied by a test illustrating a corrupted-dump scenario that previously could hang the smembers response. Impact: DoS via protocol desynchronization leading to client hang during SMEMBERS when dealing with a set reply whose length did not match the actual element count. The fix ensures mismatches are caught, avoiding a hang at the cost of a crash/assert in corrupted scenarios when built with assertions.

The commit tightens input validation for hash field operations (HPERSIST, HPEXPIRE, HEXPIRE, etc.) by requiring that the provided numFields exactly match the number of field tokens given after the FIELDS keyword. Previously the code allowed a mismatch where numFields could be greater than the actual number of arguments, which could lead to inconsistent command handling or misinterpretation of arguments. The fix changes the check from a '>' comparison to an exact '==' and updates error messaging accordingly. This reduces the risk of malformed inputs being processed in a security-relevant manner and strengthens robustness against certain input validation edge cases.

The commit adds mutex/lock handling around the HNSW cursor and index data structures to make access thread-safe. Prior to this change, hnsw_cursor_init, hnsw_cursor_free, and hnsw_cursor_next manipulated the shared index cursors list without proper synchronization. This creates race conditions when multiple threads concurrently create, traverse, and free cursors, potentially leading to use-after-free, memory corruption, or crashes under concurrent access. The fix introduces a global lock (index->global_lock) to guard cursor insertion/removal and provides lock/unlock helpers for safe iteration. This is a genuine security-related improvement because race conditions in shared data structures can be exploited for crashes or information leakage under concurrency.

The commit fixes memory handling and corruption risks in the Redis expression evaluator. Key changes: - exprCopyToken: For EXPR_TOKEN_SELECTOR, ensures that the token's start pointer is set to the allocated heap string, preventing use of an uninitialized or stale pointer and reducing risk of exposing or wandering memory access during string handling. - exprProcessOperator: On stack underflow during operator processing, explicitly frees the top_op token to avoid leaks and potential use-after-free scenarios. - exprCompile: When an operator token causes an error, frees the allocated op_token via exprFreeToken instead of RedisModule_Free, preventing mismatched memory management paths. - exprRun: Adds a bounds/sanity check before copying an object attribute name. The code now ensures t.str.len > 0 and t.str.len <= sizeof(item_name) before memcpying, and uses t.str.len-1 as the copy length with a null terminator. This prevents an underflow (e.g., when len == 0) that could lead to an oversized memcpy and memory corruption, and it constrains copies to the fixed 128-byte buffer. Overall, these changes shore up memory safety (allocation/freeing correctness and bounds checking) in the expression handling path. While the patch does not introduce or fix a specific CVE by name, it mitigates potential memory corruption and information leakage scenarios stemming from unsafe memcpy and pointer handling in expression evaluation.

This commit appears to be a genuine security vulnerability fix. It adds a dedicated ACL check for key prefixes (RedisModule_ACLCheckKeyPrefixPermissions) and enhances internal key-prefix handling to ensure ACLs are evaluated for prefix-based operations. Previously, authorization checks for commands operating on key prefixes could miss cases where access to a prefix could be inferred from multiple individual key patterns, potentially allowing an unauthorized operation to proceed. The changes include: a new prefix-aware path in ACL key matching, a new RM_ACLCheckKeyPrefixPermissions API, integration points in headers and server logic, and tests for the new behavior. This is more than a simple dependency bump or a pure code cleanup; it adds a functional security check for a previously ambiguous path (prefix-based key access).

The commit fixes a memory-safety use-after-free scenario in BPF link deallocation for tracepoints. Previously, non-sleepable tracepoint BPF links used an RCU-based grace period wait (call_rcu) during deallocation, which could allow a tracepoint program to continue accessing memory after the link was freed. The patch introduces a non-faultable tracepoint path that uses an SRCU-based grace period wait (call_srcu) for deallocation, while faultable tracepoints continue using RCU Tasks Trace. This eliminates the incorrect reliance on RCU-based GP for non-faultable tracepoints and avoids potential use-after-free in tracepoint BPF links. In short, this is a memory-safety fix related to synchronization during link/program teardown in tracepoints.

The commit fixes a race condition in the HSR (High-Availability Seamless Redundancy) net layer. During node merging in net/hsr/hsr_framereg.c, hsr_handle_sup_frame() previously updated node_real->seq_blocks without holding node_curr->seq_out_lock, allowing concurrent mutations from duplicate registration paths. This can lead to an inconsistent state or corruption of data structures (notably XArray/bitmap) under concurrent access, potentially enabling instability or information leakage through timing or state discrepancies. The fix introduces pairwise locking of both involved nodes' seq_out_lock in a well-defined order to avoid ABBA deadlocks, ensuring the merge is serialized safely. In short: before the patch, a data race could occur during node merge that risks memory/state corruption; after the patch, the merge is protected by acquiring both seq_out_locks consistently. The vulnerability is a race condition in the network subsystem that could be exploited to cause memory corruption or DoS under crafted concurrent operations on HSR frames.

The commit fixes a data race in fib6_metric_set() used to update IPv6 per-destination metrics. Before the fix, two softirq contexts could concurrently observe the default metrics pointer and allocate separate dst_metrics objects, then publish one overwriting the other's pointer, leading to a memory leak (kmemleak report) and potential memory safety issues. The patch uses READ_ONCE/WRITE_ONCE and cmpxchg to ensure only one allocation is published and to guard the metrics write.

The commit fixes a vulnerability where HTTP access fallbacks during prerender recovery could leak inconsistent internal state or reuse Flight data and chunk references from a previously aborted prerender prelude when not-found/forbidden/unauthorized errors occurred. The fix finds the deepest matching HTTP fallback boundary and renders a segment-scoped fallback via the normal app router while teeing the replacement Flight stream to avoid mixing streams. If no matching boundary exists, the generic error payload is used. This reduces the risk of information disclosure about internal prerender state and flight data during prerender recovery.

This commit introduces a runtime guard to panic when a top-level TurboTask attempts an eventually-consistent read. The intent is to prevent leaking incomplete or partially-resolved state by disallowing top-level reads that rely on eventually-consistent reads. It also introduces a SUPPRESS_EVENTUAL_CONSISTENCY_TOP_LEVEL_TASK_CHECK flag and several operation wrappers to ensure reads at the top level are strongly consistent. In effect, this mitigates a class of information-disclosure timing issues where top-level code could observe partial computations. This appears to be a genuine vulnerability fix addressing information leakage through timing/inconsistent reads, rather than a mere cleanup or dependency bump. The changes are centered on enforcing stronger consistency for top-level reads rather than changing external APIs.

The commit adds a runtime input-validation hardening in test-mode for Turbopack to ensure static asset requests include a deployment token (?dpl=...). Specifically, in resolve-routes.ts, when NEXT_TEST_MODE and IS_TURBOPACK_TEST are true and the asset is a nextStaticFolder with a deploymentId, the server now validates that the incoming query parameter dpl matches the deploymentId; if not, it halts processing (404-like behavior). Additionally, next-server.ts forwards any dpl value from the original _next/image request to the internal static asset request so the validation can be applied consistently. Tests are updated to account for this behavior (and some test infra toggles like disableAutoSkewProtection). The change is primarily a test-infra/runtime hardening intended to prevent serving assets with an invalid or missing deployment token in Turbopack test mode, reducing risk of misrouting or leakage in test environments.

The commit adds support for an ignoreList in 3rd-party sourcemaps to filter out internal/third-party frames from Redbox/server error stacks. It introduces an is_ignored flag on StackFrame and on tokens, propagates this information through trace source operations and source-map handling, and updates server middleware and Turbopack core logic to respect ignored frames when constructing error traces. This reduces information disclosure via stack traces by avoiding leakage of internal or third-party implementation details. The changes affect server-side error tracing and Turbopack source-map handling, and are accompanied by test adjustments reflecting the new ignoreList handling behavior.

This commit hardens the server-client boundary by introducing explicit error handling for invalid imports between Server Components and Client Components (e.g., server-only and client-only) via the import map. It adds a new InvalidImportIssue and wiring in the import map so that importing server-only from a Client Component (and similarly client-only from a Server Component) yields a concrete, user-friendly error rather than a brittle or ambiguous failure. This tightens security by preventing server-only code from leaking into client bundles or being misused across the server-client boundary. The change also removes some older resolve-plugin checks in favor of the centralized import-map errors, and adjusts related code paths (e.g., NextFont local fixes) to surface consistent errors. This is a hardening fix related to server-client boundary violations rather than a pure feature add or dependency bump.

The commit hardens dynamic route parameter handling by normalizing and validating encoded parameters. It adds a check to reject encoded default placeholders (e.g., %5BteamSlug%5D) for dynamic route params and ensures values are only considered valid if they are properly decoded and not placeholders. This prevents scenarios where encoded placeholders could bypass routing validation or be misinterpreted as real parameter values. The change consists of a code fix in server-utils.ts (normalizeDynamicRouteParams) plus regression tests and related e2e tests.

The commit mitigates an information disclosure vulnerability by suppressing logging for 'use cache' server functions in development. Previously, when a client invoked a server function marked with the 'use cache' pattern, server logs could reveal internal identifiers (for example $$RSC_SERVER_CACHE_0) and the encoded bound arguments. This would leak internal implementation details through logs that developers or log collectors could access. The fix adds a guard so that such use-cache actions do not emit verbose internal logs, reducing the potential exposure.

The commit upgrades @vercel/agent-eval from 0.8.0 to 0.9.5 and changes how environment variables are loaded for the agent-eval harness. Previously, the harness could inherit environment from the parent process (including secrets in root or repo env files like .env, .env.local). This created a potential information disclosure risk if secrets were stored in the repository or environment and inadvertently leaked to the evaluation harness. The fix loads environment files from the harness's own working directory (evals/), and symlinks root env files into that directory before spawning the harness, effectively isolating the evaluation environment from the parent process. Additionally, evals/.env is added to .gitignore to prevent secrets from being committed. Overall, this is a security hardening to prevent leakage of environment secrets via process environment inheritance during agent-eval runs.

The commit fixes a potential information disclosure by normalizing encoded dynamic placeholders in app routes. Previously, segments like %5BprojectSlug%5D could be misinterpreted as literal path segments when parsing app route segments or during fallback/segment prefetch, which could leak or reveal internal dynamic parameter names (e.g., root param placeholders) via prefetch responses. The fix decodes encoded placeholders and checks whether the decoded segment represents a dynamic parameter (e.g., [param]); if so, it preserves it as a dynamic segment, otherwise it leaves the segment as-is. This prevents encoded placeholders from leaking param names and ensures correct dynamic-parameter handling in prefetch and route parsing. Tests were added to guard encoded placeholders in both fallback-params parsing and segment-prefetch responses.

This commit fixes an information disclosure risk by removing internal identifiers (dashboardId and datasourceId) from analytics payloads and related types. Prior to this change, analytics events could expose internal dashboard and datasource IDs to the analytics collector or logs, enabling potential mapping or enumeration of internal resources. The patch updates the analytics emission logic to drop the internal IDs, removes deprecated/internal-id fields from dashboards and related serialization, and cleans up types to ensure internal IDs are no longer exposed. While this is primarily a data-minimization/security hardening measure, it mitigates a concrete information-disclosure surface in analytics telemetry.

The commit adds lineNumber and columnNumber to the Flight stack frame filtering logic and wires them through both client and server paths. It then introduces a precise check to filter out a specific third-party stack frame (identified by line and column) from error stacks. The intent is to harden Flight debugging output by preventing leakage of internal server/file information via stack traces. This is a security-hardening fix for information disclosure in error stacks rather than a purely functional change. The change is not a dependency bump; it alters runtime behavior of stack filtering to reduce exposure of internal paths.

The commit adds guards in React Flight server code to ignore keys named 'then' when processing server references and model creation during Flight reply serialization/deserialization. Specifically, loadServerReference returns null if key === 'then', and createModel returns null if the key is 'then' and the value is a function. This mitigates potential deserialization/thenable abuse where a crafted payload containing a 'then' property could be misinterpreted as a promise/thenable, leading to unintended behavior or security risk. The fix prevents treating such keys/functions as valid flight payload data and instead nulls them, reducing exposure to promise-related abuse during Flight data handling.

The commit hardens the handling of Flight server references to prevent information disclosure by leaking server-side function source code through stringification or implicit toString conversions. It adds safeguards to ensure server references are not exposed when converted to strings (e.g., hiding the implementation body), introduces explicit error handling for invalid payloads, and improves robustness against cycles in Promises and stream lifecycles. Additionally, it changes how server references are encoded (e.g., serializeServerReferenceID) to reduce the chance of leaking internal identifiers. In short, the patch mitigates an information-disclosure risk associated with server function references and addresses related resource-handling concerns (cycle protection, stream cleanup).

The commit introduces logic to treat props that are functions returning JSX as render helpers and emits a Render validation effect during rendering. This aims to prevent unsafe side effects (notably mutating global state) that could occur when such functions are invoked during render, by more accurately distinguishing render helpers from event handlers or effects. It also fixes type unification so return types are preserved for functions, and extends tests to cover render-time mutations. The change is not merely a dependency bump or a cleanup; it modifies the compiler/inference logic to improve security guarantees around render-time side effects.

The commit adds UI-level RBAC checks to hide or disable access to contact point information and certain plugin pages unless the user has permission. It introduces a canAccessPluginPage helper and uses it to conditionally render links or show tooltips, mitigating information disclosure via the UI (e.g., contact point search links) and gating access to plugin-related pages in the Alerts UI. This is a security-related improvement focused on the presentation layer and does not appear to enforce backend access control beyond the UI. It is a genuine fix for information disclosure via the UI, with medium confidence given potential gaps in backend enforcement.

The commit changes quota enforcement from a global boolean (EnforceQuotas) to a per-resource mechanism (EnforcedQuotaResources with a helper ShouldEnforce). This is presented as hardening: quotas no longer block writes for all resources when a single quota is exceeded; instead, enforcement happens only for resources explicitly listed. The practical effect is a shift from a potential Denial of Service surface caused by broad quota enforcement to a more granular, configurable enforcement model. If misconfigured (e.g., enabling global enforcement or mismanaging the EnforcedQuotaResources map), there could still be DoS risks, but the patch aims to reduce the risk by scoping enforcement to specific resources. The change touches core storage/quota logic and related tests, indicating a real fix rather than a mere refactor or dependency bump.

The commit adds server-side validation for the sort query parameter on the team search API. It introduces a whitelist of sortable fields and maps them to internal sort keys via a new legacysort.ConvertToSortOptions helper, then applies these sort options when querying. This reduces the risk of SQL injection via an attacker-controlled sort field used in ORDER BY. The patch also adds tests (including 400 responses for invalid sort fields) and OpenAPI changes to reflect the sort parameter. Prior to this fix, there was a potential pathway for crafting an inappropriate sort value that could influence SQL generation tied to sort logic.

The commit fixes an authorization-related bug in folder listing where a special folder (k6) could be exposed or cause incorrect pagination when filtering by folder name using NotIn in legacy search. Previously, NotIn on the SEARCH_FIELD_NAME was not supported by the legacy search backend and could be misinterpreted as In, effectively altering which folders are returned for non-service accounts. The fix does two things: (1) for legacy search, NotIn on the name field is ignored and the caller relies on a post-filter to exclude k6 from results, (2) for unified/bleve (mode 4+), NotIn works at the query level, yielding correct pagination. A post-filter fallback remains for legacy mode to ensure k6 is excluded for non-service accounts, with a note to remove this fallback once legacy search is removed. This addresses an access control discrepancy in folder listings and stabilizes pagination behavior when a k6 folder is present.

The commit fixes a nil-pointer dereference panic in the IAM user StoreWrapper when running in multi-tenant deployments where a ConfigProvider is not set. Previously, StoreWrapper methods read hidden_users by calling cfgProvider.Get(ctx) unconditionally; if cfgProvider is nil (as can occur in NewAPIService multi-tenant setups), this caused a crash (panic) and potential denial of service. The fix introduces a getHiddenUsers helper that reads the hidden_users policy from either the local config provider or a remote settings service (settingService) and adds the settingService to the API builder. This ensures the hidden_users policy is enforced in both single-tenant and multi-tenant configurations and prevents the nil pointer panic when the config provider is unavailable.

The commit introduces explicit validation to ensure that a dashboard referenced by a snapshot (via the Kubernetes API) exists before creating the snapshot. It checks the dashboard UID (presence and existence) and returns a 400 error if the UID is missing or the dashboard cannot be found. This prevents snapshots from pointing to non-existent dashboards, reducing the risk of misconfiguration, inconsistent state, and potential information exposure or misuse via the Kubernetes API.

This commit adds a RoutePermissionsService and wires it into the alerting path (ngAlert), along with updates to the authz service to provide route-permission checks. The change appears to thicken the authorization model for alert routing by enforcing route-level permissions when handling alert routes. This addresses a potential authorization bypass where alert routes could be read/used without proper route permissions, by ensuring route permissions are consulted during alert routing operations.

The commit removes the BasicRole subject kind from RoleBinding subject kinds across API schemas and generated code. Previously, BasicRole could be used as a valid subject in role bindings, and the translator mapped BasicRole to an internal assignee/role construct. This created a potential privilege-escalation path where an attacker with permission to create or mutate RoleBindings could grant a Role to a BasicRole subject, effectively elevating permissions or bypassing intended access controls. The change hardens the IAM model by allowing only User, ServiceAccount, and Team as valid subjects and by removing the BasicRole path from the code and tests.

The commit adds tenant-scoped limits validation for alerting templates and silences by introducing a LimitsProvider (Noop and Remote) and wiring it into the template and silence services. The goal is to prevent resource exhaustion/DoS by enforcing count and size limits on templates and silences, especially when syncing config to remote alertmanager. It also introduces fail-open behavior if the remote limits endpoint is unavailable or returns an error (i.e., it will not block operation in degraded conditions). This is a hardening fix for denial-of-service scenarios that could arise from abuse of template/silence creation and updates, particularly in multi-tenant environments with remote alertmanager configurations. The changes are more than a minor cleanup: they implement new logic for limits enforcement and wiring, and include API-facing behavior changes (SilenceLimitsProvider exposure) to enforce these limits.

This commit hardens exposure of legacy numeric-id data source APIs by default. It renames and repurposes the feature toggle controlling access to APIs that use numeric internal IDs and gates the registration of data source endpoints by id behind a feature flag. The deprecated endpoints that allowed accessing a data source via its numeric id (e.g., GET /api/datasources/{id}, PUT /api/datasources/{id}, and related proxy endpoints) were removed from the OpenAPI schema and are only registered when the new feature flag is enabled. By default, the legacy-id APIs are disabled, reducing information disclosure through internal numeric IDs and potential misuse of legacy endpoints. This fixes a vulnerability where authorized users could enumerate and potentially misuse internal IDs via these endpoints.

The commit adds a fallback to a Kubernetes-native RBAC mapping for resources that are not registered in Grafana's internal RBAC mapper. This changes the authorization flow so that unregistered groups/resources are evaluated against a K8s-native action set rather than returning NotFound. While this can improve flexibility and correctness for unregistered resources, it also opens the possibility of an authorization bypass: if a user or service account has explicit K8s-native permissions for an unregistered resource (e.g., action myapp/widgets:get under group unregistered.grafana.app), they may gain access through the fallback path even though Grafana’s own mapper would not recognize the resource. The patch includes tests that demonstrate the fallback behavior, including an explicit test showing access is allowed when a K8s-native action permission exists for an unregistered group/resource.

The commit fixes an information disclosure risk in the trash (ListRequest_TRASH) listing. It ensures that only resources whose latest event is a deletion are included in trash, filters out provisioned (non-deleted) items, and sorts results by resource-version in descending order for proper pagination. The previous behavior could expose non-deleted resources or provisioned artifacts when listing trash, leading to unintended information disclosure. The changes also adjust pagination to be RV-based and add tests to validate the behavior.

This commit addresses an authorization/access-control integrity issue in provisioning. Previously, during full or incremental syncs, moving/renaming a folder could generate a delete followed by a create, which destroyed the Kubernetes resource identity (UID, creationTimestamp, generation) and any ACLs tied to that identity. As a result, permissions could be lost or require reapplication after the move. The patch introduces a DetectRenames post-processing step to identify delete+create pairs that represent a single resource rename and collapses them into a single FileActionUpdated change. This enables in-place updates (GET -> UPDATE) to preserve the resource identity (UID) and thereby preserve ACLs/permissions across moves. It also shifts to hash-based rename detection in full sync to avoid extra reads. Overall, this is a genuine security-related fix to preserve permission state during folder moves in provisioning.

The commit fixes MSSQL connection string handling when credentials contain special characters (notably semicolons and closing braces). Previously, username and password values that include ';' or '}' could break the connection string parsing by the go-mssqldb driver because ';' is a delimiter and braces are not escaped. The patch introduces odbc escaping: when either the username or password contains special characters, both values are wrapped in ODBC braces and the connection string is prefixed with 'odbc:'. It also normalizes and guards the odbc: prefix to prevent double prefixes and handles the Kerberos path accordingly. This hardens credential handling in the DSN and ensures correct parsing by the driver, preventing authentication failures due to misparsed credentials.

The commit addresses an authorization bypass risk around exporting or retrieving a managed route by moving the retrieval path behind the provisioning-aware service layer. Previously, access to the managed route could be performed via routeService without consistently enforcing provisioning-based permissions, potentially allowing a user without provisioning rights to access sensitive route definitions. The change introduces a path where GetManagedRoute is exposed through the NotificationPolicyService (which is wired with provisioning context) and delegated to a managedRoutesService, ensuring provisioning-based authorization is applied when exporting/viewing managed routes. This reduces the risk of privilege escalation via route exposure.

The change adds a VariableDescriptionTooltip that sanitizes and validates links found in variable descriptions to prevent XSS via javascript: URLs and ensures external links have safe attributes. Before this fix, user-provided variable descriptions could include unsafe links such as javascript: URLs; these could be rendered into the dashboard UI and executed when clicked, leading to XSS. The new code only renders https/http URLs via getSafeExternalUrl and sanitizeUrl, and marks external links with target/_blank and rel attributes.