Secret Server identity/crypto trust cluster + hardcoded update-channel keys in OT software (5 GHSAs)¶

Source: hourly offensive-security scan of GitHub Security Advisories on 2026-09-16 (waves published 2026-09-16T00:31Z–03:31Z).

Two compact clusters with reusable axes for engagements that touch secrets vaults and appliance/OT update channels:

1. The vault itself has identity and crypto boundaries. Delinea Secret Server published three critical advisories in one wave: a padding oracle reachable by an authenticated-but-low-privilege user, a SAML impersonation path, and a link-driven script-execution sink. Secrets managers are "assume breach" assets in red-team scope: the durable workflow is to treat the vault UI as just another web app and to verify that SAML assertions are bound to the destination tenant/user and that stored-secret crypto is authenticated (AEAD) rather than encrypt-then-trust.
2. Hardcoded cryptographic keys in update controllers. Wärtsilä FOS-Onboard (marine operations software) shipped a hardcoded server key in the Update Controller component and a hardcoded client authentication key in its robot testing framework. When an update or automation channel authenticates with a key embedded in distributed software, the key is public — anyone can forge or mitm that channel. For any vendor appliance/OT software you assess, extracting bundled keys from the update/automation path is a first-class check.

Advisory table¶

Adjacent, tracked without publication from the same waves: @jitsi/electron-sdk before 10.0.5 (CVE-2026-92299, high) exposes getDesktopSources() via contextBridge with no active getDisplayMedia() picker, so any script in a meeting page silently enumerates screens/windows with thumbnails — a durable Electron/IPC axis (privileged IPC route reachable without the user-gesture gate) already covered by the existing desktop-client IPC pages; the Chrome 153.0.8010.47 memory-safety GHSA mirror wave (no public exploit path); Arista EOS IS-IS/VRRP/DHCP/MLAG protocol DoS set; Netcore NR255/NR268 firmware bundle (single-product CGI command-construction, axis already on appliance pages); mySCADA myPRO unauth command API and hardcoded-key records (OT appliance, tracked); VeloCloud Edge input-validation and update-signature records (vendor embargo — the update-integrity axis above applies); Microsoft Edge (Chromium) memory-safety records; Oracle GraalVM CPU patches; a2ui/ag-ui/vLLM sparse entries; Cotonti unserialize(); Podman podman load tar follow-up; adm-zip decompression limits; GIMP file-psd; QloApps back-office XSS; Devolutions log disclosure; rejected-CVE records.

Why this is worth an operator page¶

• Secrets vaults are the highest-value web app in the estate, and operators rarely test them as such. The padding-oracle record is the reminder: server-side crypto that answers "did this decrypt validly?" hands you a decryption oracle on the exact data class you were hired to protect. Same for SAML binding checks on the vault's own SSO.
• Hardcoded update-channel keys collapse the vendor supply chain to a network-position problem. If the update controller trusts a key that ships inside the product, "authorized update path" = "anyone who captured the binary." Pair with the existing archive/update-integrity workflows.
• Both clusters give clean positive/negative test shapes that never require touching real secrets.

Validation workflow (authorized scope only)¶

1. Vault crypto oracle check (lab only). With a low-privilege lab account, enumerate every endpoint that returns encrypt/decrypt-or-validity behavior on attacker-influenced ciphertext (import/export, backup restore, folder-key paths). Record timing/error differentials per ciphertext modification. Evidence = a decision table (ciphertext variant → response class), never plaintext of a real secret.
2. SAML binding parity. With a disposable IdP and two lab users, test whether an assertion minted for user A is accepted for user B across each SSO entry route (SP-initiated, IdP-initiated, token-exchange siblings). Check audience, recipient, and Subject-to-local-user binding separately. Stop at an identity-mapping decision table.
3. Vault XSS grammar sweep. Treat the vault UI like any app: reflected/stored/mXSS on search, folder names, secret display names, and link-shaped entry points (the advisory confirms a malicious-link → script sink exists). Report only with harmless DOM markers in your own session.
4. Update-channel key extraction (authorized product assessments). For appliance/OT software in scope, inspect the shipped update/automation components for embedded key material (search bundles for PEM blobs, hardcoded public-key constants, signature-verification call sites). Demonstrate that the extracted key verifies a synthetic manifest against the product's own verifier — never deliver a manifest to a live system.
5. Report decision tables and byte-level evidence; do not claim decryption of customer data or firmware update takeover without a lab end-to-end proof.

October 9 follow-up: openPDC / openHistorian coordinated wave — the OT data platform's own service interfaces skip auth, deserialize clients, and dial arbitrary Modbus peers¶

GitHub advisories published a coordinated RMS/openPDC/openHistorian wave at 2026-10-09T15:31Z (Grid Solutions products deployed across utility OT/monitoring estates). Legs:

Operator axes (extends the update-channel-key workflow above):

• OT data platforms carry IT-shaped bugs with OT-shaped blast radius. The unauthenticated publisher/topology leak is passive-recon gold once you're on the network: a single TCP connect reveals the entire measurement model (devices, points, naming conventions) with zero credentials — that catalog then drives every later Modbus/protocol interaction. Scan posture: enumerate non-HTTP service ports on monitoring hosts; default-config "internal" publishers are the fingerprint.
• .NET service-console deserialization on OT appliances: the Windows-Auth on/off toggle flips 9.8 authenticated to 9.8 unauthenticated — edition/config posture is the exploitability gate; fingerprint which auth mode a target runs before credentialed testing. Same server-to-client trust inversion theme as the Sept 15 parser page's LDAP leg, but in the client→server direction.
• Protocol-connector SSRF in management UIs (caller-specified Modbus host:port) = an authorized internal-mapping oracle handed to any low-priv account on SCADA-adjacent platforms — reusable across historian/SCADA products that offer "test connection" flows.
• Fixed-credential container images join the hardcoded-key family above: pull the vendor image in scope, diff baked credentials/config against defaults before any live test. Proofs stay lab-only: connect to your own lab openPDC publisher for the topology leg; never touch a live utility data plane.

October 13 follow-up: D-Link DCS-930L — the emergency HTTP recovery server's firmware signature check is the weaker twin of the main update path¶

GHSA-5vhf-mw8w-298v / CVE-2026-108971 (high, DCS-930L B1.08B4): the function mpfd_decode in bootloader_region.bin — the Emergency HTTP Recovery Server — improperly verifies the firmware image's cryptographic signature (firmware argument manipulated), remote attack, public exploit. The durable axis is not the single device but the structural pattern it confirms: the emergency/bootloader recovery listener is a separate firmware pipeline with its own signature-verification implementation, and it is routinely the weaker one — shipped to work even when the main OS is bricked, so it carries the minimal validation, is absent from product security docs and CVE history, and is often reachable in a state where the main web UI's auth/CSRF layers don't exist.

Operator workflow for any IP camera / IoT / appliance assessment where the product ships a recovery mode (button-hold boot, TFTP/HTTP recovery endpoint, bootloader_region-style separate flash partition):

1. Recover the recovery server itself as an artifact. Dump or obtain the bootloader-region image (vendor firmware update files commonly concatenate a main-image region + a recovery region — split by entropy/magic scanning), then locate the decode/verify routine by its imports (crypto memcmp/SHA call sites) — advisory-style function names like mpfd_decode are greppable anchors.
2. Differential-test the two signature paths. Build a synthetic mis-signed image (valid header, wrong signature digest) and feed each update path in a lab: main-path reject + recovery-path accept = the finding, proven with a benign replacement payload on your own device only.
3. Reachability triage first: recovery listeners usually bind only in recovery state — fingerprint the state (distinct HTTP banner/port set when the boot button is held) before any write attempt, and treat "which ports appear in recovery state" as a recon deliverable in its own right.
4. Pair with the page's existing update-channel key-extraction workflow: extracted/weak verifier keys plus the recovery-path acceptance gap compose into the full update-takeover chain; prove verification bypass with a synthetic manifest against the product's own verifier, never flash a live third-party device.

October 13 15:3xZ follow-up: BMC firmware trust anchor is a writable file (H3C HDM) and shipped-as-source-code SNMPv3 keys (Huawei openUBMC)¶

Two BMC/IPMI-adjacent records from the 15:32Z wave extend the page's two standing axes directly:

• H3C HDM Family-A: the firmware signature trust anchor is a mutable file any privileged Redfish client can replace (GHSA-3886-vrm6-hhxp / CVE-2026-65197, observed on G5 HDM 6.14.01): signature verification reads the RSA public key from /conf/public.pem, and the UpdateService.UploadSignKey Redfish action stores an uploaded body verbatim after checking only that the multipart filename ends in .pem. A firmware-update-privileged (not admin-required) account swaps the key, signs its own image, and passes verification; Family-A has no hardware root-of-trust (PFR) to catch the substitution. Durable rules: (1) enumerate where the verifier reads its key — if the answer is a filesystem path inside attacker-reachable writable state (config partition, Redfish-managed store, NVRAM exposed via CLI), signature verification is confidentiality-of-a-file, not crypto; (2) the .pem filename-suffix check is the validation-vs-confinement mismatch again — validated property (suffix) ≠ dangerous property (content/location); (3) recon workflow on any BMC/IPMI target: pull the Redfish registry (GET /redfish/v1/UpdateService and Actions), grep action names for key/cert/sign upload verbs before testing firmware upload — UploadSignKey-class actions are the trust-anchor write endpoint hiding in plain sight; prove on owned hardware only with a self-signed pair and a benign payload.
• Huawei openUBMC ships SNMPv3 USM keys as source-code constants (GHSA-5754-6w67-33hx / CVE-2026-65198, high) — one value for both auth and privacy keys, recoverable from the open-source build (default_password.lua paths named in the advisory), plus a second shipped community seed; units that never changed it accept SNMPv3 auth and decrypt from anyone holding the build. Adjacent leg (246r/CVE-2026-65199): SNMP callers get pseudo-identities with the full privilege set, so SNMP reach = max-priv API access. These are the same "estate-wide static key" and "one extraction defeats every deployment" rules as the Oct 8 Brocade ASCG binaries and this page's update-key family — with the extra twist that the "extraction" here is git clone. Pre-engagement recon: for open-source firmware (openUBMC, and any Lua/config-seeded build), grep the upstream repo for default_password|AuthenticationKey|EncryptionKey before first contact; shipped-constant hits convert any unpatched unit from "harden later" to "authenticated access available now, in lab scope only." The full-privilege-pseudo-identity leg is the general rule again: protocol-layer identity mappings (SNMP→internal principal, IPMI→user) are authorization inputs — check what privilege tier the mapping mints, not just that mapping exists.

October 14 follow-up: Ignition Perspective — a Vision session spent at the Designer gate, SCADA-authoring RCE from a viewer-tier login (CVE-2026-92817 / GHSA-q9c5-fvvm-69h6, high)¶

Inductive Automation Ignition (the SCADA/HMI platform that sits between OT devices and plant dashboards) published a session-class confusion in the Perspective module: Designer-level (authoring) access checks accept a valid Vision session identifier. An authenticated user scoped only to a Vision project presents their own valid session token at the Perspective/Designer gate, inherits Designer-level privileges, and executes arbitrary code in the Ignition Gateway process — the crown-jewel process of the whole plant configuration.

Operator axes:

1. Multi-module products mint one session but multiple privilege surfaces — test every surface's gate with the lowest session you can obtain. Ignition ships Vision and Perspective as parallel module families over one Gateway session; the gate that decides "may author projects" failed to bind the session to the module class it was issued for. This is the credential-class boundary (ezBookkeeping API-token→session uplift, Oct 4) in its SCADA shape: on any multi-module platform (SCADA suites, low-code platforms, CMSes with editor/runtime split), enumerate authoring/admin/design/preview verbs and replay your ordinary session against each — the check that "session is valid" is not the check that "session is the right class."
2. SCADA authoring privilege = code execution by definition. Designer-level access in Ignition means running project scripts server-side; there is no meaningful capability ceiling above it. Post-auth ladder on authorized OT engagements: viewer/read account → authoring gate differential → Gateway-process code exec is a single-account, single-request chain worth testing before any protocol-level OT work.
3. Version/posture recon: fingerprint the Gateway (/system/ status pages, module list); Vision+Perspective co-install is the vulnerable-population marker. Lab-only proof with your own two-tier accounts on an owned Gateway; never test privilege uplift on a live plant Gateway.