Developer dashboard, identity handoff, and file-serving boundary checks¶

Source: hourly offensive-security scan, 2026-07-02, with July 3 and July 5 follow-ups. Primary entries: GitHub Advisory Database GHSA-rh62-j648-g5qc, GHSA-g6g7-pvmx-m74p, GHSA-jphh-m39h-6gwx, GHSA-6g2f-w7g3-77vf, GHSA-q8r6-xj3f-wrrm, GHSA-6929-8p9f-26jx, GHSA-794g-x443-36f7, GHSA-5g75-477j-2c2f, GHSA-mm6c-5j6x-hq8m, GHSA-fggg-964j-3j7h, GHSA-3ggm-c5m7-hfv5, GHSA-82m5-3pcp-hccq, GHSA-qhqw-rrw9-25rm / CVE-2025-65896, GHSA-rxw2-pc8j-vxwm, GHSA-58f6-6rj2-3v8r, GHSA-227r-jm2g-7cp4, GHSA-q62h-354g-5r85, GHSA-7fqc-p256-7pwj, and GHSA-c96p-56gh-3pvw / CVE-2026-14781.

These advisories are durable for operators because they repeat the same validation seams across developer tools, identity middleware, and file-serving helpers: unauthenticated dashboard APIs reaching SQL or shell primitives, trusted identity responses accepted outside their original issuer/request binding, static or media helpers reading/writing outside intended roots, and URL/upload/vector metadata helpers crossing into server-side fetch or query construction. Keep proofs to owned labs, disposable projects, synthetic identities, marker files, canary callbacks, and fixed-version negative controls.

What changed¶

Operator triage¶

1. Start from exposure and role. Confirm whether the dashboard, file server, media helper, SAML SP, or vector API is reachable by the tested principal. Do not assume a library advisory is exploitable unless the application exposes the vulnerable helper or route.
2. Capture the crossed boundary, not secret contents. Positive proof should be a marker file, fake JWT/session, synthetic IdP user, callback log, route decision table, or seeded database row. Never read production keys, configs, customer files, IdP metadata, media libraries, or model/vector data.
3. Use paired negative controls. For every positive canary, include a fixed version, patched route, non-vulnerable adapter, wrong role, wrong IdP, or canonicalized path that blocks the same action.
4. Separate route bugs from deployment bugs. 9router and Recce are most relevant when reachable from untrusted networks or exposed through tunnels/reverse proxies; prove the actual deployment topology before reporting impact.
5. Normalize before policy. For SAML, URLs, request targets, filenames, vector metadata, and Host/Origin/locality checks, record both raw input and canonical values used by the security decision.

Replayable validation boundaries¶

Recce DuckDB query-to-filesystem check¶

• Preconditions: disposable Recce project, affected recce version, DuckDB-backed configuration, exposed server route under test, and a scratch directory containing only marker files.
• Establish that unauthenticated or lower-trust access can reach the query-run API.
• Execute only harmless DuckDB filesystem canaries against a temp path you control, such as reading a synthetic marker file or writing a marker into a disposable scratch directory.
• Positive evidence: the server process reads or writes the marker path through the query route.
• Negative controls: Recce >= 1.50.0, authentication in front of the server, non-DuckDB adapter behavior, and a non-writable/read-only application filesystem.
• Do not read .env, dbt profiles, SSH keys, cloud credentials, notebooks, model artifacts, or application source outside the canary directory.

9router dashboard/MCP authority checks¶

• Preconditions: disposable 9router lab, affected versions, fake JWT secret state, fake machine ID/CLI-token material, inert MCP tools, and no live operator credentials.
• Route coverage: enumerate dashboard and API route families and compare which routes pass through the same guard. Positive evidence is a spawn/tunnel/MCP-capable route reachable without the documented guard while the guarded route rejects the same request.
• Default secret: with JWT_SECRET intentionally unset in the lab, mint only a disposable dashboard token for a fake user and verify whether the dashboard accepts it. Negative control is a non-default secret or fixed version.
• Local-only gate: behind a controlled proxy/tunnel, vary Host and Origin while recording the TCP peer address and final access decision. Positive evidence is loopback-only behavior granted from a non-loopback peer because headers claimed locality.
• MCP/process evidence should be inert: a marker-only tool invocation or dry-run argv log. Do not install tailscale, pass real sudo passwords, run shell payloads, or operate on production agent profiles.

July 6 9router provider, usage, database, and rate-limit follow-up¶

Later July 6 entries add three adjacent 9router checks: GHSA-vjc7-jrh9-9j86 for unauthenticated provider CRUD and API-key leakage through usage stats, GHSA-qvfm-67h2-2qfx / CVE-2026-55500 for sensitive information exposure and unprotected database import/export, and GHSA-7cfm-pqrj-xgq7 / CVE-2026-55501 for login brute-force protection bypass via spoofed X-Forwarded-For.

• Preconditions: disposable 9router lab, fake provider credentials, synthetic usage rows, disposable database exports, and a controlled proxy/tunnel when testing forwarding headers.
• For provider and usage routes, use fake API keys with obvious marker prefixes and verify only route access, redaction state, and CRUD effects on disposable provider entries.
• For database import/export, export a lab database containing only marker users/providers; import only a marker snapshot into the same disposable lab. Do not collect real SQLite files, tokens, prompts, usage history, or provider secrets.
• For rate limiting, vary X-Forwarded-For behind known proxy and direct-connect paths while recording TCP peer, configured trusted proxy state, and throttle decisions. Do not conduct password spraying against real accounts.
• Negative controls: patched versions, route-level auth on every provider/stats/import/export endpoint, secret redaction at response boundaries, import role checks, and rate-limit keys derived from trusted proxy metadata rather than arbitrary browser headers.

SAML issuer, request, artifact, and encryption binding checks¶

• Preconditions: lab SimpleSAMLphp or Keycloak deployment, at least two lab IdPs with different trust labels, disposable SP/client, synthetic users, and lab signing/encryption keys.
• Build a matrix for: expected IdP A vs response from IdP B, signed assertion with and without SubjectConfirmationData/InResponseTo, unsigned outer response InResponseTo, artifact resolution over each configured TLS trust path, plaintext assertion, and encrypted assertion.
• Positive evidence: the SP/client issues a lab session or token for an assertion/artifact that does not match the expected issuer, request ID, artifact TLS trust anchor, audience, tenant, or encrypted-assertion authorization path.
• Negative controls: patched SimpleSAMLphp, fixed Keycloak behavior, single-IdP deployment, explicit issuer pinning, and assertions with wrong signatures rejected before session creation.
• Stop at lab session issuance and redacted decision tables; never access real applications, customer tenants, real SSO sessions, or live IdP metadata.

Keycloak OIDC email_verified source-binding check¶

• Preconditions: lab Keycloak realm, disposable client, attacker-controlled or mock upstream OIDC provider, trustEmail=true, userinfo endpoint enabled, synthetic users only, and no production account linking.
• Configure the upstream provider so the ID token returns email_verified=true for one controlled address while the userinfo response returns a different controlled address.
• Positive evidence: Keycloak stores or issues tokens for the userinfo email as verified even though the verification claim came from an ID token bound to another email value.
• Negative controls: fixed Keycloak behavior, trustEmail=false, userinfo disabled, matching email values only, or explicit application-side verification before account linking.
• Stop at realm/user metadata and redacted token claims. Do not target real IdPs, real inboxes, customer accounts, production tenants, or live account-takeover flows.

File-server and Windows filename canonicalization checks¶

• Preconditions: disposable LaunchServer or Algernon lab, synthetic web root, marker files only, and a process account with no access to sensitive host paths.
• LaunchServer: request only known canary filenames under and outside the intended file base. Include raw request-target variants that omit a leading slash if that is the parser differential under review.
• Algernon on Windows: create a harmless script with no secrets and request NTFS-equivalent names such as trailing-dot, trailing-space, or alternate data-stream forms. Positive evidence is raw source for the harmless script where normal requests execute/render it.
• Negative controls: patched version, canonical realpath containment after URL parsing, extension dispatch based on the resolved filesystem object, and requests for non-canary files blocked.
• Do not request .keys, config files, database credentials, production scripts, or private user uploads.

Media helper, URL fetch, upload-name, and vector metadata checks¶

• Preconditions: local Laravel app using Spatie Media Library, local agno/ClickHouse vector harness, asyncmy harness connected only to a disposable database, owned callback endpoint, synthetic uploads, seeded marker rows, and no production data.
• Media URL fetch: exercise only application paths that call addMediaFromUrl() with an owned callback URL and controlled redirects. Positive evidence is a server-originated callback from the application.
• Upload sanitizer: upload benign marker files with double-extension or omitted-extension variants and record stored filename, content type, web serving behavior, and fixed-version rejection. Do not upload executable payloads.
• Vector metadata: seed a single synthetic row and send metadata keys/values designed to change only the test query shape. Positive evidence can be a harmless SQL error mentioning a marker token or an unintended mutation of only the synthetic row.
• asyncmy mapping keys: instrument query logging against a scratch schema, then pass mapping/dict keys containing inert SQL marker tokens through only the affected helper path. Positive evidence is the key material changing the generated SQL text or query structure before execution.
• Negative controls: Spatie >= 11.23.0, application-level URL allowlists, forced attachment/non-executable storage, parameterized vector queries, metadata key allowlists, and database-client code that treats keys as fixed application identifiers rather than request-controlled input.

July 3 fast-mcp Telegram and Steeltoe actuator follow-up¶

The July 3 updated feed added two adjacent operator patterns that belong with this dashboard/control-plane batch rather than a standalone page.

MCP bearer-token-to-session-file boundary¶

• Preconditions: isolated fast-mcp-telegram HTTP server, disposable Telegram test account or mocked session files, temp config directory, and account-prefixed tools configured with inert sinks.
• Create a canary session file representing the reserved/default account, then try bearer-token variants that include path separators or dot segments.
• Positive evidence: the token selects the reserved/default session despite exact reserved-name rejection. Capture only session selector, account label, and inert tool availability.
• Negative controls: tokens rejected if they contain path separators, normalized session path constrained to the session directory, reserved names rejected after canonicalization, and patched behavior.
• Do not read real messages, send real messages, or capture MTProto session files from operator machines.

Steeltoe actuator and JWKS control-plane boundary¶

• Preconditions: Steeltoe app with synthetic actuator values, two lab JWT issuers with controlled kids, fake connection strings, and no real heap dumps or database credentials.
• Compare public listener requests whose Host header names the management port against requests that reach the actual management listener. Positive evidence is actuator access that follows spoofed Host rather than the bound socket/port.
• Build a Cloud Foundry role-to-endpoint matrix with low-trust lab roles. Positive evidence is access to sensitive actuator families such as heap dump, thread dump, or environment where the expected sensitive-data permission is absent. Record route/status only, not dump contents.
• Seed /actuator/env or /cloudfoundryapplication/env with fake ConnectionStrings:* and Steeltoe connector keys. Positive evidence is an unsanitized canary value containing only fake credentials.
• For JWT validation, configure two issuers with the same kid and different keys. Positive evidence is a token/key decision that uses a key cached for the wrong issuer or keeps a revoked key trusted until process restart.
• Do not dump heap/thread data, real environment variables, production tokens, customer rows, service bindings, or backing database contents.

Reporting notes¶

Lead with the crossed boundary:

• Unauthenticated Recce query route -> DuckDB filesystem primitive
• 9router public/tunnel route or default secret -> dashboard/MCP process authority
• SAML response/artifact/encrypted assertion -> wrong issuer/request/client session
• OIDC ID-token verification claim -> different userinfo email trusted as verified
• File-server request target or NTFS-equivalent name -> outside-root read or raw script source
• Media URL/upload metadata, vector metadata, or DB mapping keys -> server fetch, stored filename bypass, SQL construction, or generated-SQL mutation
• Bearer token string -> filesystem-backed MCP session selection
• Host header / CF role / shared kid -> actuator or token-authority drift

Strong reports include affected version, deployment topology, raw and normalized input, exact route/helper, test role, synthetic canary evidence, and fixed-version or configuration negative controls.

Reviewed but not promoted here¶

• GHSA-q675-qj96-32m9, GHSA-5pmv-rx8r-wmv5, GHSA-66m8-c62j-h6v5, GHSA-2v8p-fqpx-2q3w, and nearby Zebra/JXL resource-exhaustion or crash advisories were skipped as standalone wiki items because they did not add a non-availability operator workflow in this scan.
• GHSA-v8rp-6xcv-fwgh was not promoted because the advisory describes Kiwi TCMS /init-db/ repeat access as a reentrant/no-op migration status path.
• GHSA-5j8p-5rrj-8wjg was noted as a generic music-directory prefix traversal; it did not add a distinct workflow beyond the file-server path-boundary checks above.
• GHSA-rcjc-c4pj-xxrp, GHSA-6r7r-jj8h-pq6v, and GHSA-5843-p793-ghmm were processed without a new page because the July 2 update did not add a reusable operator workflow beyond existing LDAP input, unsafe deserialization, or availability-only multipart checks.

October 8 15:3xZ follow-up: OpenShift console /locales/resource.json lng/ns traversal — i18n loaders as unauth file readers (CVE-2026-75887 / GHSA-v74g-7mx6-787p, high)¶

The OpenShift console (web UI pod) accepts lng and ns query parameters on /locales/resource.json without sanitization, letting an unauthenticated attacker traverse the pod filesystem to read *.json files — plugin manifests, configuration — and traverse against registered dynamic-plugin backends (the ns value selects which backend/fetcher serves the "locale", so it becomes a request-shaping parameter toward internal services).

Durable axes for this page's file-serving section: (1) i18n/localization resource loaders are file readers wearing a UI feature's clothing — any endpoint shaped /locales|/i18n|/translations/{lang}/{ns} builds a path (or a backend route) from two user-controlled segments; traversal battery (../%2f, encoded variants, absolute paths) plus backend-selection probing applies to every dashboard product, not just OpenShift. (2) The namespace/selector parameter double-role pattern: ns picks which internal backend answers, making the same one query parameter both a file-read and an internal-routing primitive — when a traversal read lands, immediately test whether the same field can point at a different backend (SSRF pivot from an info-disclosure bug). (3) Console/proxied frontends commonly pass query params through to plugin servers without revalidation — treat every proxied-console param as reaching the backend. Proof: lab cluster, read a synthetic canary manifest; never pull live console config or tokens.