Security vulnerability in script included with skills: Code Injection in oci/oke/scripts/gva-discover.sh

I ran a /security-review with claude on this repository. It was happy with the markdown skills files: "Net: the markdown is consistently, deliberately security-conscious. No markdown finding meets the reporting bar.", however it reported the following as a vulnerability:

Security Review: oracle/skills

One HIGH-severity finding survived verification and the confidence threshold. All other executable code (APEX .mjs/Python, OCI Functions deploy scripts, IoT-platform scripts, and the remaining OKE scripts) reviewed clean, or produced only sub-threshold observations.

Vuln 1: Code Injection: oci/oke/scripts/gva-discover.sh:465-482

• Severity: High

• Category: code_injection (untrusted data interpolated into generated Python source via an unquoted heredoc)

• Confidence: 8/10

• Description: The script assembles its result JSON by piping a heredoc into Python with an unquoted delimiter (python3 - <<PY at line 465), so bash performs ${...} expansion on the heredoc body before Python parses it. Multiple attacker-influenceable OCI resource display names are interpolated directly into Python source with no escaping:

  • "name": "${cluster_name}" (~line 470) — cluster_name comes from the oci ce cluster get/cluster list name field via json_get_field, which simply print()s the raw string (no escaping).
  • json.loads('''${subnets_json:-[]}''') and json.loads('''${nsGs_json:-[]}''') — subnets_json/nsGs_json are raw oci network subnet/nsg list ... --output json output (captured verbatim at ~lines 440-452) whose display-name fields are embedded inside a triple-quoted Python literal.

  This is a genuine deviation from the codebase's own safe pattern: the other heredoc in the same file (oci_json, ~line 178) correctly uses a quoted delimiter (<<'PY') and passes data as argv. Only this block gets it wrong, and no sanitization sits between the OCI CLI output and the sink (only empty-string checks defaulting to []).

• Exploit Scenario: In a multi-tenant / cross-team OCI compartment, a lower-privileged user who can create or rename network resources sets a malicious display name:

  • A subnet or NSG named x'''+import("os").system("touch /tmp/pwned")+''' closes the json.loads('''...''') literal and injects executable Python; or
  • A cluster named "+import("os").system("id")+" breaks out of the "name": "..." string literal.

  When an operator/administrator later runs gva-discover.sh against that compartment (discovery enumerates subnets/NSGs/clusters automatically), the crafted display name is expanded into the Python source and the injected code executes on the operator's machine with the operator's local privileges and OCI credentials — a privilege-escalation / RCE path.

• Recommendation: Use a quoted heredoc delimiter (python3 - <<'PY') and pass every externally-sourced value into Python as sys.argv entries or via os.environ, then build the dict inside Python — exactly the safe pattern already used by the oci_json block in this same file. Parse subnets_json/nsGs_json from a file or stdin with json.load, never by string interpolation into source.

---

Sub-threshold observations (not reported as findings, listed for awareness only):

• oci/oke/scripts/oke-discover.sh:296-312 — the same unquoted-heredoc pattern with "name": "${cluster_name}". Verification scored it 7/10 (concrete RCE additionally hinges on OCI accepting quote characters in cluster display names), so it falls just below the reporting bar — but it shares the root cause with Vuln 1 and the same fix applies.
• apex/apexlang/runtime/runtime.bundle.mjs:1820 — rejectUnauthorized: false disables TLS certificate validation on the runtime-verification request (requires an active MITM position; excluded as a hardening issue).