Glances, OpenDJ, and Spinnaker control-plane boundary checks¶

Source: hourly offensive-security scan, 2026-06-22. Primary entries: GitHub advisories GHSA-v5r2-qh84-fjx5 / CVE-2026-46606, GHSA-43x2-g84q-fmqx / CVE-2026-46495, and GHSA-c8q4-9h32-2ww8 / CVE-2026-44795. Late same-hour updates added GHSA-w856-8p3r-p338 / CVE-2026-46611, GHSA-87qc-fj39-wccr / CVE-2026-46608, and GHSA-3f62-qv96-4p78 / CVE-2026-46700.

This batch is durable because each advisory exposes a reusable operator workflow around privileged control planes: virtualization inventory names crossing into command construction, observability browser trust reaching system-monitoring datasets, directory-server monitoring interfaces deserializing unauthenticated network input, deployment pipeline YAML crossing into unsafe Java object loading, and finance-app sync secrets leaking through role-check drift.

What changed¶

Adjacent GHSA-7cfq-5mhv-jrp9 was processed but not promoted because the public detail is an unprivileged container crash of an Inspektor Gadget USDT note parser and the advisory states no shipped gadget is affected. GHSA-7gh7-258j-4mpq was also processed without promotion because Actual CLI CSV formula injection is a useful report-hygiene finding but does not add a new operator workflow beyond existing CSV/export formula checks. Revisit only if future detail ties either item to a non-availability boundary, privilege crossing, or reusable exploit-path validation pattern.

Operator triage¶

1. Identify who controls the input. VM names may be set by tenant admins or compromised orchestration paths; Glances XML-RPC may be reachable from browsers on operator workstations or internal dashboards; Actual sync-server secret names may be guessable by any authenticated non-admin OpenID user; Spinnaker YAML may be contributed through repos, templates, or pipeline parameters; JMX RMI may be reachable only from monitoring networks.
2. Separate management-plane reachability from application reachability. These issues often sit on hypervisor hosts, observability daemons, finance sync services, LDAP/identity nodes, and CI/CD services that do not share the public web tier.
3. Use canary-only proofs. VM labels, owned browser origins, lab XML-RPC requests, synthetic Actual secret names, lab JMX listeners, disposable directory servers, and synthetic pipeline descriptors are enough. Do not run payloads that alter host state, dump monitoring datasets, enumerate real bank-sync credentials, dump directory data, or execute commands in shared deployment systems.
4. Record preconditions. Include Glances run user, libvirt permissions, XML-RPC bind address and cors_origins, Actual auth mode and user role, OpenDJ JMX handler state/port, Java version/classpath constraints, Spinnaker feature path, and whether CloudFormation or CloudFoundry baking is enabled.
5. Prefer construction and callback evidence over impact escalation. A logged command split, harmless local marker in a disposable VM lab, browser-origin allow/deny tables, positive/negative synthetic secret-name probes, JMX handshake/deserialization reachability in a lab, or rejected/patched YAML comparison is safer and clearer than demonstrating broad RCE or secret access.

Replayable validation boundaries¶

Glances VM-name command-construction harness¶

• Preconditions: written approval for a disposable KVM/QEMU host or nested-virtualization lab, permission to create/rename VMs, and a Glances instance configured with the VM plugin.
• Create baseline VM names and one harmless canary name containing only an inert marker designed to show command-token interpretation in logs or a temporary lab output path.
• Run Glances as the same user and configuration used in scope, then capture virsh command construction, process arguments, or marker-only output from a temp directory.
• Do not run destructive shell operators, write outside temporary lab paths, alter production VM definitions, or target hosts where Glances runs as root unless the environment is disposable.
• Negative controls: patched Glances version, domain names passed as argument arrays rather than split command strings, strict libvirt naming validation, and Glances running with least privilege.

Glances XML-RPC browser-trust harness¶

• Preconditions: scoped Glances XML-RPC server (glances -s) in a lab or customer-approved environment, an owned browser origin/domain, and approval to test browser-origin behavior against monitoring endpoints.
• Test Host handling separately from CORS: send baseline XML-RPC requests with the expected host, then an owned rebinding/alternate Host canary, and record whether the XML-RPC server accepts both.
• Test single-origin and multi-origin cors_origins configurations. Capture only headers and a harmless method/version or synthetic monitoring value; do not collect process lists, network peers, file-system paths, credentials, or full host telemetry from production systems.
• Negative controls: Glances 4.5.5+, XML-RPC disabled or bound to localhost/management VPN, strict Host validation, no wildcard CORS fallback for multi-origin lists, and browser access blocked by network segmentation.

Actual sync-server secret-name authorization harness¶

• Preconditions: owned @actual-app/sync-server lab or explicit authorization for a self-hosted deployment, OpenID multi-user mode, one admin user, and one disposable non-admin user.
• As admin, create synthetic secret names only, for example skillz_canary_simplefin_accessKey, then attempt GET /secret/:name as the non-admin user for both existing and nonexistent canaries.
• Evidence should show role asymmetry and existence inference only: status codes, response-shape differences, and patched-vs-vulnerable comparisons. Never enumerate real integration names in production, retrieve secret values, or touch live bank-sync credentials.
• Negative controls: @actual-app/sync-server 26.6.0+, admin checks on both GET and POST secret routes, non-admin users receiving identical responses for existing and nonexistent names, and deployments without multi-user OpenID secret management.

OpenDJ JMX RMI pre-auth deserialization harness¶

• Preconditions: an owned OpenDJ lab instance, explicit approval to test management ports, and confirmation whether the JMX connection handler is enabled.
• Enumerate configured JMX/RMI listeners from admin-approved configuration or scoped port scans. Avoid broad Internet scanning unless the engagement explicitly authorizes it.
• In the lab, send a harmless serialization canary that proves bytes are parsed before authentication, or compare vulnerable and patched versions with connection/log evidence only.
• Do not deploy public gadget chains, trigger command execution, read directory contents, capture credentials, or fuzz production identity servers.
• Negative controls: OpenDJ 5.1.1+, JMX disabled, listener bound to localhost/management VPN, authentication before object deserialization, and JVM serialization filters.

Spinnaker YAML deserialization harness¶

• Preconditions: an isolated Spinnaker lab, disposable cloud/bake targets, and permission to run CloudFormation deployment or CloudFoundry baking workflows.
• Submit a baseline YAML descriptor and a canary descriptor that exercises type handling without creating cloud resources or invoking commands.
• Capture parser errors, class-resolution logs, or benign marker behavior that proves unsafe constructor reachability. Keep pipeline artifacts and screenshots free of cloud secrets.
• Do not deploy infrastructure, bake images, run system commands, or use production credentials while validating parser behavior.
• Negative controls: patched Spinnaker releases 2025.3.3, 2026.0.3, or 2025.4.4; feature disabled; YAML parsed with safe constructors only; pipeline templates restricted to trusted repositories.

Reporting notes¶

• Lead with the boundary: VM inventory label to command runner, browser origin/Host header to observability XML-RPC dataset, non-admin finance-app user to admin-managed secret-name oracle, JMX RMI network bytes to Java deserialization before auth, or deployment YAML to privileged Java class loading.
• Include reachability and role context: who can rename VMs, which browsers/networks can reach Glances XML-RPC, who can authenticate to Actual as non-admin, who can submit pipeline descriptors, which networks can reach JMX, and what OS/service account executes the affected component.
• Keep evidence non-sensitive: canary names, temp paths, lab listener logs, CORS/Host decision tables, synthetic secret-name status differences, parser traces, version matrices, and patched-vs-vulnerable comparisons.

June 23 Glances AMP command update¶

GitHub Advisory Database added GHSA-3vwc-qwhc-3mj7 / CVE-2026-53925 for another Glances secure_popen() boundary: AMP command configuration could include shell redirection or chaining operators and reach arbitrary file write or command execution.

Operator value: this expands Glances testing beyond VM inventory names and browser-origin trust. Assessments should review monitoring plugin configuration to command runner paths, especially where low-privilege operators, config-management pipelines, or tenant-provided templates can influence AMP commands.

Safe validation boundaries:

1. Use a lab Glances instance with a disposable AMP config and a temporary output directory owned by the test user.
2. Compare a baseline AMP command with an inert canary containing redirection or a single benign chaining marker. Evidence should be command parsing, a temp-file marker, or rejection logs; do not run shell payloads that enumerate the host.
3. Confirm the run user and plugin enablement. Running Glances as root or with broad host mounts materially changes impact and should be called out as a precondition, not assumed.
4. Negative controls: AMP command arguments passed as arrays, shell metacharacters rejected before secure_popen(), and configs restricted to trusted administrators.

Reporting heuristic: title as AMP command config to Glances command runner, include the exact config source, service account, command line or parser trace, temp marker path, and patched-version rejection.

July 24 OpenDJ proxy-identity and DSML URI follow-up¶

Two OpenDJ 5.1.2 fixes add distinct directory-server boundaries:

• GHSA-p279-2cqp-84jg: SASL PLAIN authzid accepted a different resolvable user when the authenticating account held proxied-auth, but omitted the target-scoped mayProxy ACI decision enforced by other proxy paths.
• GHSA-68r5-9hpg-7qw9: the unauthenticated DSMLv2 SOAP gateway dereferenced xsd:anyURI values, including local-file and outbound HTTP sources, before the fixed release disabled dereferencing by default and bounded the opt-in path.

For SASL, create a proxy account, one in-scope synthetic target, and one out-of-scope synthetic target. Compare PLAIN dn:/u: forms with RFC 4370, DIGEST-MD5, or GSSAPI controls, and preserve only the effective canary identity and access decision. Do not impersonate administrators or read directory data.

For DSML, use an owned callback and a benign file created under a lab temp directory. Send one add/modify request containing the canary URI and record callback or marker-byte handling; never point at metadata, internal production services, directory configuration, or credentials. Report DSML value coercion -> URI dereference -> owned network/file canary, and keep the unbounded-read availability behavior out of the proof.

September 22 Checkmk follow-up: GUI-hidden secrets served by the API + newline injection into the query protocol¶

Two Checkmk advisories (GHSA-xwvr-5xw4-qv5w / CVE-2026-92882, and GHSA-v742-5hjw-gqcp / CVE-2026-90990) extend monitoring-plane testing in two directions:

• API-read parity for GUI-hidden secrets. Host and folder configuration REST endpoints returned stored SNMP community strings, SNMPv3 auth/privacy passphrases, and IPMI passwords in cleartext GET responses to any authenticated user allowed to view host configuration — even though the setup GUI never displays these values. Audit rule for every admin/console product with both a GUI and a REST API: the GUI's field-hiding is not an access control; as a low-privilege viewer, GET the same object through the API and diff which fields the GUI masks but the API serves. Sweep secret-shaped keys (community, passphrase, password, secret, authkey) in API responses; prove only with your own lab-configured fake credentials on a disposable host object.
• Filter values crossing into protocol framing. Monitoring host/service list APIs passed filter values into Livestatus query headers without newline neutralization, letting an authenticated user inject additional query headers to bypass object-visibility restrictions in count queries — an inference oracle over hosts/services outside their contact groups. This is the query-protocol sibling of the header-injection family: any UI/API parameter that becomes a line in a text-framed protocol (Livestatus, HTTP, SMTP, SIP, LDAP filters rendered as header lines) must be CRLF-free by enforcement, not convention. Test battery: append \r\n<Header>: x shaped inert markers to each filter/search/sort parameter and record the raw bytes toward the backend (patched socket recorder in a lab), plus a count-delta oracle comparing your contact group's totals with and without the injected header against synthetic rows you own. The count oracle is the reportable impact — infer existence/attributes of out-of-scope objects without ever reading their full rows.
• Both items also reinforce the monitoring-plane target map: a monitoring server aggregates credentials and inventory for the whole estate, so low-role viewer drift (this pair) escalates fast. Fingerprint the low-role API surface first, keep proofs inside two synthetic contact groups you created, and never dump live SNMP/IPMI credentials from a production site.

October 2 follow-up: ejabberd SASL-PLAIN accepts an unvalidated authzid — arbitrary user impersonation¶

GHSA-339c-8fr4-g2w4 / CVE-2026-104733 (ProcessOnes XMMP Server, ejabberd ≤ 26.04, fixed 26.07): the SASL-PLAIN mechanism accepted an unvalidated authzid (authorization identity) parameter, letting any authenticated (or in some deployments, unauthenticated-at-mechanism-level) client assert an arbitrary identity — full user impersonation across the XMPP server. This is the RFC 4422/RFC 4370 control that isn't: PLAIN carries three fields (authzid, authcid, password), and the server must only honor authzid when it differs from authcid if the authenticating credential is explicitly authorized to proxy that identity. ejabberd checked the password against authcid and then used authzid as the session identity with no proxy-authorization decision.

• Direct sibling of the July 24 OpenDJ authzid/mayProxy item above: OpenDJ enforced proxied-auth but missed the target-scoped ACI; ejabberd skipped the whole layer. Durable rule for any SASL-speaking server engagement (XMPP, LDAP, IMAP, SMTP AUTH, database drivers): send authzid divergent from authcid and observe which identity the session gets. Decision table on a lab server with three synthetic accounts (authenticator A, in-scope target B, out-of-scope target C): authcid=A, authzid=A (baseline), authcid=A, authzid=B (must be refused absent explicit proxy grant), and each mechanism variant — PLAIN vs SCRAM vs DIGEST-MD5 vs ANONYMOUS — because proxy handling is implemented per-mechanism and drift lives in the least-used one. On XMPP specifically, verify whether the server-to-server and component ports expose PLAIN with the same gap, and whether session-steering binds at SASL or at resource-bind.
• Reporting: prove with your own two lab accounts and record the effective bound JID/identity per row. Claim identity assertion/impersonation, not message-content access, unless you demonstrably read another account's offline queue with your own credentials.

October 5 follow-up: the Zabbix transport trio — per-message auth skip, hidden-field guess oracle, trap-delimiter injection¶

Three Zabbix advisories from the 2026-10-05 12:31Z wave extend this page's monitoring-plane map, one per trust layer of the monitoring transport:

• Active-agent heartbeat ignores PSK/certificate config (GHSA-jmxh-h64m-45qp / CVE-2026-59786): Server and Proxy accept the active-agent heartbeat message regardless of the configured PSK or certificate authentication — anyone who can reach the trapper port can report any arbitrary host as available. Durable axis: authentication is configured per-protocol but enforced per-message-type, and the heartbeat/ping sibling routinely skips it. Audit rule for any agent-based monitoring/messaging protocol (Zabbix trapper, NRPE, statsd-over-TLS, MQTT heartbeat, DICOM C-ECHO): enumerate message types on the port and test each unauthenticated even when the data-carrying type demands TLS-PSK — availability reporting is an integrity primitive (poison monitoring state, mask incidents, seed false health).
• Host search filters hidden fields → credential guess oracle (GHSA-pr2j-9fvv-cqvq / CVE-2026-59785): Frontend host search allows filtering by fields that are not displayed, including stored IPMI and PSK credentials — a read-role user guesses a credential value and the result set tells them whether the guess was right, uncovering it character by character. This is the Checkmk item above wearing an oracle costume: Checkmk served the secrets in API JSON; Zabbix never displays them yet leaks them through an equality-filter primitive. Standing sweep for every admin/console product with a searchable table: (a) GET the object through the API (GUI-hiding ≠ access control), and (b) if the API is clean, enumerate filterable columns (&filter[]=, advanced-search syntax, sort parameters) against secret-shaped field names and use the empty/non-empty result differential as a per-guess oracle. Report with a recovered lab-set fake credential only; the boolean-diff log is the proof.
• SNMP trap receiver: ZBXTRAP record-delimiter injection (GHSA-3p5c-5fm7-qp72 / CVE-2026-59787): the shipped Perl trap script does not neutralize the ZBXTRAP record delimiter inside trap content, so anyone able to send SNMP traps can inject a record targeting another host. Query/text-framing injection sibling of the Sept 22 Livestatus newline item: any parser that splits records on a literal marker (ZBXTRAP, ------=_Part, __END__, MIME boundaries) must treat the marker as sacred inside payload bytes. Probe battery: embed the record marker + a synthetic second host row into a single trap varbind and diff ingestion results on a lab Zabbix with two disposable hosts.
• Monitoring-plane framing (unchanged rule, now three layers deep): the monitoring server holds credentials, inventory, and availability truth for the whole estate — heartbeat spoofing (integrity), credential oracles (confidentiality), and record injection (identity of data source) each cross an estate-wide boundary from a single low-privilege position. Lab Zabbix only, synthetic hosts/credentials, never production trapper ports.

October 5 follow-up: Perforce P4 Search — shipped-container defaults and fail-open auth on an SCM control plane¶

The 2026-10-05 09:31Z GHSA wave published a seven-advisory Perforce P4 Search pack (fixed 2026.4.2). Durable because P4 Search fronts the connected P4 Server — the source-of-truth repository — so every leg is framed by the vendor as potential compromise of the connected SCM server, and because the pack splits cleanly between the product binary and its shipped container images, which are a separate artifact with their own defaults.

• GHSA-9p2m-pch8-59mp / CVE-2026-100102 (critical): P4 Search container images ship with an unauthenticated Java debug interface enabled — network access to the debug port = arbitrary code execution as the P4 Search service account. Direct sibling of this page's OpenDJ JMX RMI item: management/debug listeners on control-plane hosts. Oct 2's shipped-config-stub family (gopay/go-micro/alexpechkarev/gist) generalizes here from config-file defaults to container-image defaults — the same product deployed bare-metal vs containerized can have materially different attack surfaces. Scan rule: for any enterprise product with official container images, fingerprint the image's exposed listeners (JDWP/agentlib:jdwp, JMX, /actuator, pprof, admin consoles) independently of the documented product ports; a JDWP banner on a non-HTTP port in a scanned container is the whole fingerprint.
• GHSA-crr7-cpqh-vjm5 / CVE-2026-100103 (critical): container images reset the service authentication token to a publicly documented default value — network access = highest application privilege. Shipped-default family (Armatura fixed superuser password, Oct 3), with the added audit primitive: the default is documented, so the vendor's own docs are the credential source; grep product docs for default tokens/secrets as a standing recon step.
• GHSA-rgmx-jfh8-6fx8 / CVE-2026-103510 (critical): the service fails open when its auth token is blank — an empty/absent token config yields highest privilege rather than refusing to serve. Sibling of the ImageMagick zero-policy and kubernetes-client missing-CA fail-opens: when probing any token/password-gated service, include the empty/absent-credential row in the decision table (valid token, wrong token, blank token, no token file); blank-behaves-as-authenticated is a distinct bug from blank-behaves-as-anonymous.
• GHSA-w4rv-834f-h4j4 / CVE-2026-103507 (high) + GHSA-49f3-gp89-25v9 / CVE-2026-103511 (medium): token-privileged attacker can write arbitrary files via the logging configuration interface and write arbitrary-content files via the extension installation feature — the "config-write interface is a file-write primitive" axis; after obtaining any service token, enumerate every config surface that accepts a path (log targets, plugin/extension upload, template dirs) before pivoting, because these are the lateral paths to auto-loaded locations.
• GHSA-mv4f-7chx-wrhv / CVE-2026-103512 (medium): auth validation trusts a client-supplied address, bypassing host-based ticket restrictions — the client-declared-peer-identity class: any allowlist enforced against a value in the request payload/headers rather than the transport peer is bypassable with a stolen ticket; test by presenting a stolen-lab-ticket from a different source address and a spoofed in-allowlist address.
• Validation boundaries: lab P4 Search install/image only; JDWP/JMX presence proof is a banner read, not code execution; blank-token probes against your own disposable instance; canary file writes only into disposable install paths; never touch a production P4 server or depot contents.

October 6 follow-up: Prometheus UI stored XSS — ingested metric names are browser-executable operator-side markup¶

GHSA-vffh-x6r8-xx99 / CVE-2026-40179 (Prometheus ≥3.0.0 ≤3.5.1 and ≥3.6.0 ≤3.11.1, fixed 3.5.2 LTS / 3.11.2; advisory landed in the updated feed 2026-10-06 18:47Z): metric names and label values that arrive through ingestion — scrape target, remote-write receiver (--web.enable-remote-write-receiver), or OTLP receiver (--web.enable-otlp-receiver) — are interpolated into innerHTML in the web UI without escaping at four sinks (fix commits fddbccf79b/a4d5f98f42 in web/ui/mantine-ui/src/pages/query/uPlotChartHelpers.ts tooltip, web/ui/react-app/src/pages/graph/GraphHelpers.ts tooltip, web/ui/react-app/src/pages/graph/MetricsExplorer.tsx fuzzy-search results, web/ui/react-app/vendor/flot/jquery.flot.heatmap.js heatmap le-label tooltip). Execution is one hover away for any Prometheus user viewing the poisoned series in Graph, Metric Explorer, or heatmap.

• The ingest-to-operator-browser pivot is the durable axis. The attacker never touches the UI: they control a scrape target or any reachable remote-write/OTLP receiver and plant the payload server-side, where it persists like any stored XSS but enters through a data channel. Standing rule for any dashboard/observability product (Grafana, Kibana, Zabbix, Checkmk, Cloud Monitoring): every label/name/tag/id value that flows from ingestion into a rendered tooltip, table cell, or autocomplete is user data, and the render path must escape it. Fingerprint v3's UTF-8 name validation from the outside: GET /api/v1/label/__name__/values and grep for names containing <, >, " — their presence means the operator's Prometheus accepts markup-shaped metric names, which on ≤3.11.1 means a hover is a payload.
• PromQL links are a second, read-only-privilege trigger leg. A shared/bookmarked query whose functions (e.g. label_replace) produce poisoned label names renders the same unescaped tooltips — so even without ingestion access, luring a logged-in analyst to click a crafted query link executes in their session. Treat shared-dashboard and shared-query links as untrusted input surfaces during engagements.
• Post-XSS same-origin surface is what makes monitoring UIs fat targets: from the operator's browser the script can read /api/v1/status/config (secrets are redacted server-side, but topology/rules leak), and where optional flags are enabled, call /-/quit (--web.enable-lifecycle) or POST /api/v1/admin/tsdb/delete_series (--web.enable-admin-api) — a hover-triggered destructive path against the TSDB. Audit those two flags on any exposed Prometheus before claiming read-only impact.
• Historical anchor: CVE-2019-10215 was the same stored-DOM-XSS class in query history (fixed v2.7.2) — this sink family has recurred in this product twice; keep tooltips/autocomplete as first-class stored-XSS sweep targets on every metrics UI engagement.
• Validation boundaries: owned lab Prometheus only. Expose your own disposable remote-write receiver, push one canary metric name containing inert DOM markup (a marker <img onerror> that writes a benign text marker), and record execution in your own browser plus the patched-vs-vulnerable diff; enumerate the label-values fingerprint on instances you own or are scoped to. Never poison a production monitoring stack's ingest path, never click real operators into canary queries, and never exercise delete_series//-/quit outside a disposable instance.

October 7 follow-up: Apache Impala query-plane trio — unsigned executor JWT, alias-to-operator-browser stored XSS, and trusted-JAR prefix traversal (2026-10-07 09:32Z wave, fixed 4.5.3)¶

A three-leg coordinated pack on Apache Impala ≤4.5.2 that maps the analytics-plane boundary map this page already teaches (dashboards ingest attacker-influenced data into operator browsers; internal service UIs carry their own weaker auth):

• Executor webserver accepts any JWT whose signature is not verified (CVE-2026-97720 / GHSA-g6xq-6pmr-p37c) — where the executor UI is configured for JWT/OAuth auth, bearer tokens are parsed but signatures are never validated, so a forged unsigned-but-well-formed JWT authenticates to resources served by the executor's webserver. Durable axis for every internal service UI (Impala, Hue, Spark, Trino coordinators, K8s dashboards): structurally-valid-token-accepted ≠ authenticated — mint an invalid-signature canary token for a legitimate-looking subject and diff the response against a garbage token and a valid token (three-way decision table; "forged accepted, garbage 401" is the finding). Same absent/mismatched-verification family as this page's Perforce blank-token leg and the Oct 2 BC/wolfSSH KEX legs.
• Stored XSS from a SELECT-only SQL user to another user's browser via the query-plan UI (CVE-2026-93684 / GHSA-gr7f-9f5r-v3mg): JavaScript placed in a table alias renders unsanitized when another user opens that query's plan. This is the Prometheus ingest-to-operator-browser pivot moved into SQL tooling: the attacker needs only the lowest SQL privilege, the payload travels through metadata (aliases, comments, column aliases), and the sink is the operator's browser opening a "view plan" link. Sweep rule for every query engine's web UI: put an inert DOM-marker canary into every syntactically-permitted identifier position (alias, comment, CTE name, database name) and view the plan/history/log render as a second operator account — identifier positions are rarely on the app team's XSS input list because they're "SQL, not content."
• trusted_jar_paths prefix-traversal JAR load (CVE-2026-90466 / GHSA-xf54-j4ff-f2xp): the startup allowlist is checked by prefix, and path traversal within the same filesystem (schema preserved, ../ not) lets a JAR uploaded via ordinary DDL (CREATE DATA SOURCE/CREATE TABLE) at a different location satisfy the trusted-path check and get loaded — conditioned on a non-empty trusted_jar_paths config. Durable axis: allowlists compared as string prefixes over paths are containment misses (canonical Sept 15 static-file-prefix rule, now on the class-loading sink — the worst variant because the loaded bytes execute); recon-visible precondition (admin-configured trusted path), and the attacker's upload primitive is a normal DDL verb most authz audits treat as data-plane. Probe decision table per engine: relative-path spelling → path actually resolved → file actually loaded.
• Validation boundary: lab Impala only — forged canary JWTs against your own executor UI, inert marker-alias payloads viewed by your own second account, synthetic JARs containing a marker class inside your own lab's trusted path; never load third-party JARs or touch production clusters.

October 9 follow-up: Apache Camel Karavan — the design-time IDE applies your YAML to the cluster and commits your filename verbatim (2 GHSAs, fixed 4.22.1)¶

Karavan is the Camel low-code design UI shipped with integration platforms; the 18:31Z wave gave it two legs that are reusable classes on every developer-facing control plane (3.18.0–<4.22.1):

• kubernetes.yaml deploy = unprivileged user applies arbitrary cluster resources (CVE-2026-103413 / GHSA-5c9w-j8c6-h6m2, high): on deployment start Karavan unmarshals the project's kubernetes.yaml and applies every resource kind with Karavan's own service-account authority — no kind restriction, no rejection of security-sensitive pod options, no namespace pinning. Any authenticated user of any role gets pods with hostNetwork/hostPID/hostIPC/hostPath/privileged/cap-add through the tool's identity. Durable axis: the low-code/IDE layer is a confused deputy with cluster credentials, and "the file is just project metadata" framing keeps these paths out of authz review. Audit pattern for every builder/CD/IDE product: find where user-authored manifests or configs are apply-ed server-side, then diff (role required to author) vs (identity used to apply) vs (what the apply accepts). Proof: disposable namespace, canary pod requesting a marker hostPath that fails to mount (no host read needed to prove acceptance), plus the namespace-pinning probe (request a foreign namespace, see if it's rewritten or honored). Same apply-side-prilege family as this page's Spinnaker lineage and the Sept 21 ArtifactGC.PodSpecPatch pod-patch sink on the May 4 Argo page.
• Project filename written verbatim into the Git working copy (CVE-2026-103412 / GHSA-8cgr-63w4-hm5f, high, since 3.18.0): the file API's name becomes a raw path segment at commit-write time, so ../ lands content anywhere the Karavan process can write — named impact is overwriting app config or classpath files → code execution in the Karavan container. Axis: user-named artifacts (project/file/note/template names) crossing into filesystem writes is still the lexical-containment class, but the classpath destination is the tell — on Java/Kotlin control planes, a stray write primitive deserves immediate "can it land on the classpath, plugin dir, or config path?" evaluation rather than a generic path-traversal rating.

Validation stays lab-only: disposable cluster/namespace, marker paths, no production SA tokens. Karavan fingerprint: Camel/Karavan console reachable behind the integration platform login — auth at any role is enough for both legs.

October 13 follow-up: Perforce Helix Authentication Service — shipped-install-template SCIM token + second-generation prototype pollution in the SCIM library = identity-provisioning chain to RCE¶

GHSA-8m68-j7cp-5rcm / CVE-2026-109758 (critical, Helix Authentication Service 2022.1–2025.2; underlying defect removed in 2026.1, released after the vulnerable band): the HAS 25.2 installation templates contain a default SCIM bearer token which the installer copies verbatim into the active configuration — neither the installer nor the config script replaces it with a random value. An attacker who knows the default token authenticates to the SCIM API and performs user/group operations against the configured provisioning backend — i.e., the gate in front of the SSO directory. The advisory states the token chains with CVE-2026-61834 in the scim-patch dependency: a crafted SCIM PATCH causes server-side prototype pollution, corrupts application state, disrupts health checks and SCIM/SSO requests, and was confirmed to reach RCE on a Node.js 24/Express deployment via gadget chains involving child_process, EJS/Pug, or Passport. The library's second-generation advisory GHSA-2mhw-wcx5-v3xj / CVE-2026-61834 shows why: the first fix blocked the literal __proto__/constructor/prototype path segments, but navigate() reads inherited properties (schema[subPath]) and assign() tests membership with key in obj — so path: "toString.scimPatchPolluted" resolves through the prototype chain onto the shared Object.prototype.toString function object and mutates it process-wide (working PoC in the advisory).

Durable axes:

• Install-template default credential is a new sub-family of the shipped-default lineage (this page's P4 Search publicly-documented default token, the Oct 3 Armatura fixed superuser password): the credential ships in a template file and the installer copies it into production config without randomizing. Recon step for any Perforce/HAS-style appliance in scope: obtain the vendor's install templates, sample configs, or shipped container tarball (docs and public images count) and grep the templates for token/secret/key fields before guessing — the template version fingerprints how a live config was generated.
• SCIM provisioning endpoints are identity control planes with a single bearer credential. One token = create/modify users and groups on the backend that gates SSO for the whole estate. Any reachable SCIM base URL is a top-gate target: try the shipped default token, then run the inherited-path PATCH battery (toString.x, valueOf.x, hasOwnProperty.x, constructor spellings beyond the blocked triple) and identify whether the server's patch library is scim-patch in an affected range.
• Prototype pollution second generation: blocked names ≠ blocked traversal. First generation: block the three magic names. This leg: traversal still follows inherited keys, so any safe-looking built-in method name becomes a path into shared function objects. Sweep rule for every patch/merge/path-walk library and every SCIM/JSON-Patch surface: after the __proto__ battery fails, retry the same sinks with inherited-method names as path segments; the finding assertion is ({}).toString.someProp !== undefined in a same-process canary. The confirmed Node 24 pollution→RCE transition (child_process/EJS/Pug/Passport gadgets) kills the automatic DoS downgrade: score pollution against the target app's dependency graph for known gadget sinks before rating impact.
• Validation boundaries: owned HAS/lab SCIM harness only; prove pollution with an inert canary property, prove RCE only via inert marker commands in your own container; never PATCH a real IdP provisioning endpoint or a production HAS instance.