ArcadeDB, Nuclio, and Pheditor control-boundary checks¶

Sources: hourly offensive-security scan, 2026-07-16 GitHub Security Advisory updates. Primary entries: GHSA-x9f9-r4m8-9xc2, GHSA-48qw-824m-86pr, GHSA-vwjc-v7x7-cm6g, GHSA-x8mg-6r4p-87pf, GHSA-vg6x-6pg9-6qwg, GHSA-8w86-m9h8-hvqg, GHSA-3v79-m2cg-89ww, GHSA-wpcj-rmv4-86qg, GHSA-p4h7-p9rj-2pq2, GHSA-9643-6xjp-vx57, and GHSA-wg4w-wr5q-6vjc.

This batch is durable for operators because it exposes reusable boundaries across database scripting/import surfaces, serverless build control planes, and web-based file editors: low-privilege roles reaching host-aware interpreters, import sources crossing into SSRF or local files, unauthenticated function-build APIs writing outside their workspace, template-rendered build configuration becoming executable code, and prefix-based terminal allowlists reaching a shell.

What changed¶

Replayable validation boundaries¶

ArcadeDB script, schema, and import probes¶

1. Build a disposable ArcadeDB instance with a synthetic database, a low-privilege reader user, and a separate schema-update user. Use fake data only.
2. Enumerate which HTTP command/query or MCP-adjacent database analysis paths are exposed in the target deployment. Record whether each path requires authentication and which database role is bound to the token.
3. For script-language checks, avoid host secret reads and process-control payloads. Use a synthetic file placed by the tester under a temp directory and prove only that the vulnerable role can or cannot read that canary. Include both direct polyglot command routes and SQL function-library routes such as user-defined JavaScript functions, because fixes may gate only one interpreter entry point.
4. For trigger checks, use an inert command marker such as writing a nonce to a disposable temp path in a lab. Do not place payloads in production triggers or fire triggers against customer records.
5. For schema mutation checks, create a throwaway type/property and attempt harmless rename or property-flag changes with the low-privilege token. Immediately drop the disposable object in the lab.
6. For IMPORT DATABASE, use an owned callback endpoint and a synthetic local file under an allowlisted temp directory. Do not target cloud metadata, loopback admin panels, configuration directories, keys, or unrelated filesystem paths.
7. For cross-database handler checks, create two disposable databases (a and b), authorize the test user only for a, and compare the expected 403 from canonical command/query routes with alternate time-series, batch, Prometheus, or Grafana routes that name b. Positive evidence should be limited to marker rows, marker series, or route-status differences.
8. Repeat every probe against a patched version and an admin-only positive control so the report shows role drift rather than generic database reachability.

Report ArcadeDB findings as database role -> script/import/schema feature -> host, network, or schema side effect outside documented permission boundary, or database-scoped token -> alternate handler family -> second database read/write without authorization. Evidence should include role names, endpoint family, version, canary-only outputs, and negative controls.

Nuclio dashboard build-control checks¶

1. Use a lab Nuclio dashboard or an explicitly approved target where function creation and builds are in scope. Confirm whether the dashboard is in NOP/no-auth mode or behind an identity layer.
2. Create a disposable function whose source returns a static marker and has no access to live secrets, queues, model artifacts, or production clusters.
3. For build-configuration injection, place only inert marker statements in Java runtime repository metadata and capture whether the generated build configuration executes during Gradle configuration.
4. For handler path traversal, attempt only writes to a disposable temp path inside the dashboard container or a mounted scratch directory approved for the test. Never write cron files, shell startup files, binaries, Kubernetes credentials, or application configuration.
5. Capture the API route, auth posture, function spec fields, build logs with markers, file path decision table, container user context, and cleanup.
6. Run patched 1.16.5 or later as a negative control.

Report Nuclio findings as dashboard function API -> build metadata or handler module path -> build-container code execution or file write. Keep payload syntax out of public reports unless the program explicitly permits full reproduction details.

Pheditor default-credential and terminal-wrapper checks¶

1. Confirm that password testing and web-terminal validation are in scope. If credential testing is not allowed, stop at version/configuration evidence.
2. Test only the documented default credential condition against a disposable install or an approved target. Do not brute-force or reuse credentials across systems.
3. If authenticated, verify the terminal permission state and configured command allowlist before sending any command.
4. Use a marker-only command in a lab, such as printing a nonce or writing under a disposable temp directory. Avoid network egress, shell profiles, persistence, interpreter downloaders, or web-root writes.
5. Separately test file upload/edit exposure with harmless text markers, not executable extensions or web shells.
6. Add controls for changed passwords, disabled terminal permission, patched versions, and allowlist entries that are validated after shell parsing rather than before it.

Report Pheditor findings as default or authorized login -> web editor terminal/upload feature -> shell or filesystem side effect beyond intended allowlist.

July 24 Pheditor forced-change and argv follow-up¶

Two later advisories sharpen this fixture:

• GHSA-f25v-x6vr-962g: when the stored password was still the default, the forced-change branch checked that stored state but did not verify the submitted current password. Any non-empty value could reach the change form and establish an administrator session. Use a disposable install, a synthetic password, and a second browser profile; prove only the login-state transition. Version 2.0.8 is the fixed control.
• GHSA-g3hq-hphg-8fhh: after metacharacter fixes, the terminal still prefix-matched an allowlisted program and passed the whole string to a shell. Program-native execution options therefore crossed the allowlist without shell separators. Test only with an argv recorder or a command that writes one nonce beneath a disposable temp root. Version 2.0.7 is the fixed control.

Run the password case separately from terminal capability. The first boundary is unauthenticated request -> unverified forced-change branch -> admin session; the second is terminal-enabled account -> first-token allowlist -> executable program option -> inert marker. Do not use the newly established session to execute a terminal proof on any non-disposable target, and do not publish reusable command payloads.

Operator checklist¶

• Which identity or role crosses the boundary: read-only database user, single-database user, schema admin, unauthenticated dashboard caller, default web-editor user, or terminal-enabled account?
• Is the proof reduced to a canary file, owned callback, marker command, synthetic schema object, or build log nonce?
• Does a patched negative control block the same request shape?
• Are dangerous locations explicitly avoided: service-account tokens, cloud metadata, production config, web roots, cron paths, customer records, and live function artifacts?
• Can the report distinguish source facts from lab observations without publishing weaponized strings?

August 2 ArcadeDB MCP principal and server-authority follow-up¶

Three advisories for ArcadeDB before 26.7.3 extend the database-role fixture into its MCP transport and trigger runtime:

MCP and trigger role matrix¶

1. Create a disposable database with root, read-only, read/write, and schema-admin users. Give each only the MCP access and database permissions needed for its row in the test matrix.
2. Through MCP, compare a harmless read, one marker-row write, creation of a throwaway type, and a recorder-only JavaScript query. Capture the authenticated transport principal and the principal observed by the engine separately.
3. Call get_server_settings only against a lab configured with a fake cluster-token sentinel. Record whether the complete sentinel is returned, but redact it from screenshots and reports.
4. Prove the forwarding half independently: replace cluster-token verification with a local recorder or use the fake lab sentinel, supply a synthetic forwarded username, and record the identity selected by the handler. Do not replay any token from a real deployment.
5. As schema admin, install a trigger whose host call is intercepted by a fake Security.createUser recorder. Positive evidence is the attempted method, arguments, and caller role; do not create an administrator, execute host commands, or leave the trigger installed.
6. Repeat all rows on 26.7.3. The patched negative control should preserve legitimate root behavior while denying lower-role operations at the engine, settings, forwarding, and trigger boundaries.

Keep the three claims separate: MCP-authenticated role -> missing engine principal -> unauthorized database operation, settings tool -> cluster bearer disclosure -> forwarded-user authority, and schema trigger -> unrestricted database host object -> server-security API call. A settings response alone does not prove root impersonation, and schema-update permission alone does not prove that a real administrator was created.

Reporting notes¶

• Lead with the trust boundary and precondition, not exploit spectacle: database role, dashboard auth mode, web-editor credential state, or shell-wrapper design.
• Preserve route names, versions, role matrices, and marker evidence. Redact hostnames, tokens, session cookies, tenant names, and filesystem layouts that reveal sensitive deployments.
• For multi-advisory clusters, group findings by reusable invariant: host-aware interpreter exposure, import source validation, build metadata execution, path confinement, or shell allowlist bypass.