Cilium Envoy socket, Formie hidden-field SSTI, OpenRemote datapoint, and Open Babel parser-boundary checks¶

Source: hourly offensive-security scan, 2026-07-06. Primary entries: GitHub Advisory Database GHSA-3fcv-jvfp-m4q9 / CVE-2026-49445, GHSA-565m-g33j-jq96 / CVE-2026-52889, GHSA-xj53-j257-hxvg / CVE-2026-49439, and GHSA-55f6-pf8r-c2f4 / CVE-2022-46292.

These advisories are durable for operators because each exposes a reusable boundary to test during authorized reviews: pod-local access to infrastructure admin sockets, request metadata rendered as server-side templates, read-only asset permissions reaching a write endpoint, and untrusted scientific file formats crossing into native parsers. Keep proofs synthetic: route/socket reachability, fixed canary strings, disposable asset datapoints, and local sanitizer traces only.

What changed¶

Operator triage¶

Prioritize targets where one of these conditions exists:

1. Kubernetes node or pod-local code execution is in scope. Cilium Envoy socket reachability matters when a workload, debug pod, daemonset, or low-privilege node user can touch CNI/service-mesh admin interfaces that were assumed private.
2. Public Craft/Formie forms use dynamic Hidden defaults. The interesting cases are request-controlled fields rendered server-side: User-Agent, Referer, current URL, query parameter, or cookie value.
3. OpenRemote tenants expose read-only asset roles. Test whether read-only principals can mutate predicted, cached, derived, or forecast data tied to assets.
4. Applications parse user-supplied chemistry files. Open Babel is often embedded behind upload converters, molecule previewers, notebook workflows, search indexing, or ETL jobs.
5. The impact crosses a real trust boundary. A route that returns only a canary, a disposable predicted datapoint, or a local sanitizer crash is evidence; production secret reads, traffic disruption, or destructive parser payloads are not acceptable wiki proof artifacts.

Replayable validation boundaries¶

Cilium Envoy admin-socket exposure check¶

Use this only in an owned cluster or an engagement where Kubernetes node/pod-local testing is explicitly authorized.

• Preconditions: affected Cilium version range, L7 policy or functionality enabled, a disposable namespace or lab node, and a low-privilege test identity matching the threat model.
• From the test context, enumerate only socket presence and permission metadata for Cilium/Envoy admin sockets. Capture path, owner, mode, and whether a harmless read-only admin endpoint is reachable.
• Positive evidence: the low-privilege context can connect to the Envoy admin socket that should be confined to Cilium/Envoy control processes.
• Negative controls: patched Cilium version, cluster without L7 Envoy enabled, and a context that should not have node-local socket access.
• Do not invoke disruptive admin operations, dump TLS secrets, terminate Envoy, alter routes, or capture live traffic. Report reachability and redacted endpoint metadata only.

Formie request-derived Hidden default SSTI canary¶

Use this when a public Formie form contains a Hidden field whose default source is request-derived rather than an admin-authored custom template.

• Preconditions: authorized Craft/Formie target or local reproduction, affected verbb/formie version, public form with an affected Hidden default source, and an inert canary string.
• Send a request where the selected metadata source carries harmless template syntax that evaluates to a fixed marker, not code execution or secret access.
• Render or submit the form through the normal front-end path and capture whether the response or submitted field value contains the evaluated marker rather than the literal input.
• Positive evidence: request-controlled metadata is evaluated by server-side Twig during Hidden field rendering.
• Negative controls: patched Formie 3.1.27 or later, a Hidden field using a static literal default, and a custom admin-authored default where template rendering is expected.
• Do not attempt RCE, read Craft config, enumerate environment variables, or inject persistent payloads into production forms.

OpenRemote predicted-datapoint write authorization check¶

Use this for API authorization reviews where synthetic assets and test users are available.

• Preconditions: disposable OpenRemote realm or tenant, one synthetic asset, one attribute such as temperature, and a test principal with read:assets but not write:assets.
• Confirm the same principal cannot update the asset through normal asset-write APIs.
• Attempt to write a predicted datapoint with a harmless marker value to the predicted-datapoint route for the synthetic asset.
• Positive evidence: the API accepts the write and later reads or database evidence show only the synthetic predicted datapoint changed.
• Negative controls: patched build, a principal with no asset permissions, and a legitimate writer role to prove the route itself works.
• Do not alter production telemetry, commands, setpoints, billing data, or operational assets. Keep marker values obviously synthetic.

Open Babel native-parser ingestion harness¶

Use this only in a local lab or an explicitly authorized file-ingestion test harness.

• Preconditions: affected Open Babel build, ASAN/UBSAN or equivalent instrumentation where practical, and disposable input/output directories.
• Prefer the upstream minimized regression sample or a vendor-supplied proof file over crafting new payloads.
• Run the parser/converter in a sandboxed process with strict CPU, memory, and filesystem limits. Capture version, command line, sanitizer trace, and patched-version negative control.
• Positive evidence: an affected build trips the UNIT CELL TRANSLATION parser issue while patched Open Babel 3.2.0 or later does not.
• Keep proofs local. Do not upload crash files to third-party production converters, shared notebooks, customer ETL jobs, or public molecule previewers.

Reporting notes¶

• Lead with the crossed boundary: pod-local user to Envoy admin socket, request metadata to server-side Twig, read-only asset role to predicted datapoint write, or untrusted scientific file to native parser memory corruption.
• Include version, feature/configuration preconditions, test identity, exact synthetic canary, positive/negative decision table, and patched or fixed-control evidence.
• Keep impact claims scoped to what was proven. Do not claim cluster compromise, RCE, telemetry manipulation, or arbitrary native code execution unless the authorized test safely demonstrates that chain in a lab.

July 6 OpenRemote KNX import and realm-boundary follow-up¶

Later July 6 GitHub Advisory Database entries add two adjacent OpenRemote checks: GHSA-7v6w-c3f4-9wpq / CVE-2026-54640 for an incomplete XXE fix in the KNX asset import path, and GHSA-xqr9-4wvv-gvch / CVE-2026-54641 for cross-realm user information disclosure in UserResourceImpl.

The October 13 description enrichment makes the mechanism precise and generalizable: the realm path parameter is accepted but never used — getUser(userId) queries the database by UUID with no realm filter — and the master-realm administrator is reachable from any tenant realm admin through three get/getUserClientRoles-style read endpoints that check the caller's read:admin role but omit the target-realm check. Fingerprint for any multi-tenant REST API: a path containing a {realm}/{tenant}/{org} segment whose handler never references that parameter is a cross-tenant read oracle; grep handlers for path variables declared and unused, then replay the same UUID against /admin/api/v2-beta/realms/<your-realm>/users/<foreign-uuid>-shaped routes with a low-tier tenant admin token and synthetic users only.

OpenRemote KNX XXE and realm-ownership harness¶

• Preconditions: disposable OpenRemote lab with two synthetic realms, non-sensitive test users, an affected KNX import path, one mounted canary text file outside application secrets, and no production telemetry or identity data.
• For KNX import, build a minimal ETS project ZIP that references only the synthetic canary file through an XML external entity. Positive evidence is the canary marker appearing in import output, logs, or controlled error text. Do not target /etc/passwd, cloud credentials, application config, or service-account files.
• For realm ownership, authenticate as a realm admin in tenant B and request only synthetic tenant A user IDs through the affected profile/role routes. Positive evidence is a route decision table showing tenant B can read tenant A canary user metadata despite lacking cross-realm authority.
• Negative controls: patched KNX parser path using the same secure XML factory as sibling handlers, external entities disabled in every XML/XSLT import path, explicit targetUser.realm == caller.realm checks, and patched builds that deny the same requests.
• Reporting should separate authenticated file-read through import parser from cross-tenant identity metadata disclosure and include only redacted/synthetic canary values.

July 6 OpenRemote datapoint crosstab SQL follow-up¶

A later July 6 GitHub Advisory Database entry adds GHSA-cgfv-jrfp-2r7v, subsequently mirrored as GHSA-rw7h-h988-gfff / CVE-2026-62238, an authenticated SQL injection boundary in OpenRemote's Datapoint Crosstab Export path. The later record makes the second-order source precise: an asset display name is stored through create or rename capability and later concatenated into the export query.

OpenRemote crosstab export SQL harness¶

• Preconditions: disposable OpenRemote realm, one synthetic asset/attribute, seeded datapoints containing only marker values, and a test user with the exact asset create or rename and export capabilities under review.
• Create two otherwise identical assets: one ordinary control and one whose display name contains only a harmless delimiter-shaped or syntax-error canary. Keep selector, attribute, time window, bucket, ordering, and every direct export parameter constant.
• Trigger the ordinary application crosstab export for each asset. Capture the stored display name, generated-query structure or parser error, response schema, and synthetic CSV marker. Prefer instrumented query logs in a local database; never use data-extraction expressions.
• Positive evidence: stored asset display name -> later export query construction -> query grammar changes or a deterministic parser error occurs, while the ordinary name and corrected build remain data values. This distinguishes second-order name injection from a direct export-parameter bug.
• Negative controls: corrected build, a principal unable to create or rename assets, the same canary stored in a field not used as a crosstab identifier, and the same export with an ordinary display name.
• Do not dump unrelated tables, enumerate tenants, run time-heavy queries, or export production telemetry. Report this as authenticated stored asset name to later SQL crosstab construction, with create/rename and export permissions stated separately.

July 6 Cilium Local Redirect Policy cross-namespace service follow-up¶

GHSA-q6h5-q3q6-f87x / CVE-2026-53935 adds another Cilium boundary: users who can create CiliumLocalRedirectPolicy objects can specify arbitrary addressMatcher ClusterIPs, which can redirect traffic for Services in other namespaces and break the namespace scoping that serviceMatcher normally provides.

Cilium local-redirect service-hijack harness¶

• Preconditions: disposable Kubernetes cluster, affected Cilium version, two synthetic namespaces, one canary Service in namespace A, a low-trust policy author in namespace B, and no production service traffic.
• Create a benign canary backend in namespace B and a CiliumLocalRedirectPolicy using addressMatcher for the namespace A Service ClusterIP. Positive evidence is only canary traffic or Cilium policy state showing namespace B can redirect namespace A's service address.
• Compare with a serviceMatcher policy that should enforce namespace scoping, and with a patched Cilium build that rejects the same cross-namespace address match.
• Do not redirect production Services, metadata endpoints, kube-system traffic, databases, ingress controllers, or customer workloads. Avoid policy deletion tests that could disrupt service translation outside an isolated lab.
• Report this as namespace-scoped CRD author to cross-namespace service traffic steering with Cilium version, CRD YAML, source/destination namespaces, ClusterIP mapping, canary backend evidence, and fixed-version negative control.