CWE-915
AllowedImproperly Controlled Modification of Dynamically-Determined Object Attributes
Abstraction: Base · Status: Incomplete
The product receives input from an upstream component that specifies multiple attributes, properties, or fields that are to be initialized or updated in an object, but it does not properly control which attributes can be modified.
276 vulnerabilities reference this CWE, most recent first.
GHSA-6862-8MF9-7VG4
Vulnerability from github – Published: 2026-07-14 15:32 – Updated: 2026-07-14 15:32Sustainable Irrigation Platform (SIP) through version 5.2.16 contains a mass assignment vulnerability that allows unauthenticated attackers to overwrite sensitive configuration settings by supplying arbitrary parameter names in HTTP requests. Attackers can manipulate parameters corresponding to sensitive values such as the passphrase and listening port, and can also achieve the same result through cross-site request forgery due to the absence of adequate request validation.
{
"affected": [],
"aliases": [
"CVE-2026-58477"
],
"database_specific": {
"cwe_ids": [
"CWE-915"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-14T15:17:06Z",
"severity": "HIGH"
},
"details": "Sustainable Irrigation Platform (SIP) through version 5.2.16 contains a mass assignment vulnerability that allows unauthenticated attackers to overwrite sensitive configuration settings by supplying arbitrary parameter names in HTTP requests. Attackers can manipulate parameters corresponding to sensitive values such as the passphrase and listening port, and can also achieve the same result through cross-site request forgery due to the absence of adequate request validation.",
"id": "GHSA-6862-8mf9-7vg4",
"modified": "2026-07-14T15:32:17Z",
"published": "2026-07-14T15:32:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-58477"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/sustainable-irrigation-platform-mass-assignment-via-http-parameters"
},
{
"type": "WEB",
"url": "https://www.zeroscience.mk/#/advisories/ZSL-2026-5997"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:L",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-695C-X5GC-94GJ
Vulnerability from github – Published: 2026-04-27 12:30 – Updated: 2026-05-05 14:45Apache Camel's camel-coap component is vulnerable to header injection because it maps CoAP request URI query parameters directly into Camel message headers without applying a HeaderFilterStrategy. An unauthenticated attacker can send a crafted CoAP request to inject arbitrary Camel internal headers into the exchange.
When a vulnerable route forwards that exchange to a header-sensitive downstream producer, the attacker may be able to control producer behavior. For example, in routes using camel-exec, injected headers can override the configured executable and arguments, which can result in arbitrary command execution with the privileges of the Camel process. Command output may be returned to the attacker in the CoAP response.
This issue affects org.apache.camel:camel-coap from 4.14.0 through 4.14.5 and from 4.18.0 before 4.18.1. It is fixed in 4.14.6, 4.18.1, and 4.19.0.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.14.5"
},
"package": {
"ecosystem": "Maven",
"name": "org.apache.camel:camel-coap"
},
"ranges": [
{
"events": [
{
"introduced": "4.14.0"
},
{
"fixed": "4.14.6"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.camel:camel-coap"
},
"ranges": [
{
"events": [
{
"introduced": "4.18.0"
},
{
"fixed": "4.18.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-33453"
],
"database_specific": {
"cwe_ids": [
"CWE-915"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-05T14:45:11Z",
"nvd_published_at": "2026-04-27T11:16:01Z",
"severity": "CRITICAL"
},
"details": "Apache Camel\u0027s camel-coap component is vulnerable to header injection because it maps CoAP request URI query parameters directly into Camel message headers without applying a HeaderFilterStrategy. An unauthenticated attacker can send a crafted CoAP request to inject arbitrary Camel internal headers into the exchange.\n\nWhen a vulnerable route forwards that exchange to a header-sensitive downstream producer, the attacker may be able to control producer behavior. For example, in routes using camel-exec, injected headers can override the configured executable and arguments, which can result in arbitrary command execution with the privileges of the Camel process. Command output may be returned to the attacker in the CoAP response.\n\nThis issue affects org.apache.camel:camel-coap from 4.14.0 through 4.14.5 and from 4.18.0 before 4.18.1. It is fixed in 4.14.6, 4.18.1, and 4.19.0.",
"id": "GHSA-695c-x5gc-94gj",
"modified": "2026-05-05T14:45:11Z",
"published": "2026-04-27T12:30:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33453"
},
{
"type": "WEB",
"url": "https://github.com/apache/camel/pull/22146"
},
{
"type": "WEB",
"url": "https://github.com/apache/camel/pull/22147"
},
{
"type": "WEB",
"url": "https://github.com/apache/camel/pull/22148"
},
{
"type": "WEB",
"url": "https://github.com/apache/camel/commit/05cffa5ec05ff2ec3c50a77825625da6e426e7a8"
},
{
"type": "WEB",
"url": "https://github.com/apache/camel/commit/3926ab2b7745e36da2cd8e0dc019018bc415aff9"
},
{
"type": "WEB",
"url": "https://github.com/apache/camel/commit/e074c01a719cccf3b1c2efbd2ff31e60fd6220ce"
},
{
"type": "WEB",
"url": "https://camel.apache.org/security/CVE-2026-33453.html"
},
{
"type": "PACKAGE",
"url": "https://github.com/apache/camel/blob/main/components/camel-coap"
},
{
"type": "WEB",
"url": "https://issues.apache.org/jira/browse/CAMEL-23222"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2026/04/26/3"
}
],
"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": "Apache camel-coap allows header injection that can lead to remote code execution"
}
GHSA-6FPP-RGJ9-8RWC
Vulnerability from github – Published: 2019-08-01 19:18 – Updated: 2023-09-13 17:18SubTypeValidator.java in FasterXML jackson-databind before 2.9.9.2, 2.8.11.4, and 2.7.9.6 mishandles default typing when ehcache is used (because of net.sf.ehcache.transaction.manager.DefaultTransactionManagerLookup), leading to remote code execution.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "com.fasterxml.jackson.core:jackson-databind"
},
"ranges": [
{
"events": [
{
"introduced": "2.9.0"
},
{
"fixed": "2.9.9.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "com.fasterxml.jackson.core:jackson-databind"
},
"ranges": [
{
"events": [
{
"introduced": "2.8.0"
},
{
"fixed": "2.8.11.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "com.fasterxml.jackson.core:jackson-databind"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.7.9.6"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2019-14379"
],
"database_specific": {
"cwe_ids": [
"CWE-1321",
"CWE-915"
],
"github_reviewed": true,
"github_reviewed_at": "2019-08-01T15:38:02Z",
"nvd_published_at": "2019-07-29T12:15:00Z",
"severity": "CRITICAL"
},
"details": "SubTypeValidator.java in FasterXML jackson-databind before 2.9.9.2, 2.8.11.4, and 2.7.9.6 mishandles default typing when ehcache is used (because of net.sf.ehcache.transaction.manager.DefaultTransactionManagerLookup), leading to remote code execution.",
"id": "GHSA-6fpp-rgj9-8rwc",
"modified": "2023-09-13T17:18:23Z",
"published": "2019-08-01T19:18:00Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-14379"
},
{
"type": "WEB",
"url": "https://github.com/FasterXML/jackson-databind/issues/2387"
},
{
"type": "WEB",
"url": "https://github.com/FasterXML/jackson-databind/commit/ad418eeb974e357f2797aef64aa0e3ffaaa6125b"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/f17f63b0f8a57e4a5759e01d25cffc0548f0b61ff5c6bfd704ad2f2a@%3Ccommits.ambari.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/ee0a051428d2c719acfa297d0854a189ea5e284ef3ed491fa672f4be@%3Cdev.tomee.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/e25e734c315f70d8876a846926cfe3bfa1a4888044f146e844caf72f@%3Ccommits.ambari.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/d161ff3d59c5a8213400dd6afb1cce1fac4f687c32d1e0c0bfbfaa2d@%3Cissues.iceberg.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/b0656d359c7d40ec9f39c8cc61bca66802ef9a2a12ee199f5b0c1442@%3Cdev.drill.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/99944f86abefde389da9b4040ea2327c6aa0b53a2ff9352bd4cfec17@%3Cissues.iceberg.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/940b4c3fef002461b89a050935337056d4a036a65ef68e0bbd4621ef@%3Cdev.struts.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/87e46591de8925f719664a845572d184027258c5a7af0a471b53c77b@%3Cdev.tomee.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/8723b52c2544e6cb804bc8a36622c584acd1bd6c53f2b6034c9fea54@%3Cissues.iceberg.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/859815b2e9f1575acbb2b260b73861c16ca49bca627fa0c46419051f@%3Cissues.iceberg.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/75f482fdc84abe6d0c8f438a76437c335a7bbeb5cddd4d70b4bc0cbf@%3Cissues.iceberg.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/689c6bcc6c7612eee71e453a115a4c8581e7b718537025d4b265783d@%3Cissues.iceberg.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/6788e4c991f75b89d290ad06b463fcd30bcae99fee610345a35b7bc6@%3Cissues.iceberg.apache.org%3E"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHBA-2019:2824"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/f9bc3e55f4e28d1dcd1a69aae6d53e609a758e34d2869b4d798e13cc@%3Cissues.drill.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r1b103833cb5bc8466e24ff0ecc5e75b45a705334ab6a444e64e840a0@%3Cissues.bookkeeper.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rf1bbc0ea4a9f014cf94df9a12a6477d24a27f52741dbc87f2fd52ff2@%3Cissues.geode.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2019/08/msg00011.html"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/OVRZDN2T6AZ6DJCZJ3VSIQIVHBVMVWBL"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/TXRVXNRFHJSQWFHPRJQRI5UPMZ63B544"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/UKUALE2TUCKEKOHE2D342PQXN4MWCSLC"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20190814-0001"
},
{
"type": "WEB",
"url": "https://support.apple.com/kb/HT213189"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpuApr2021.html"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpuapr2020.html"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpujan2020.html"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpujul2020.html"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpuoct2020.html"
},
{
"type": "WEB",
"url": "https://www.oracle.com/technetwork/security-advisory/cpuoct2019-5072832.html"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2019:2743"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2019:2858"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2019:2935"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2019:2936"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2019:2937"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2019:2938"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2019:2998"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2019:3044"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2019:3045"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2019:3046"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2019:3050"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2019:3149"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2019:3200"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2019:3292"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2019:3297"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2019:3901"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2020:0727"
},
{
"type": "PACKAGE",
"url": "https://github.com/FasterXML/jackson-databind"
},
{
"type": "WEB",
"url": "https://github.com/FasterXML/jackson-databind/compare/jackson-databind-2.9.9.1...jackson-databind-2.9.9.2"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/0d4b630d9ee724aee50703397d9d1afa2b2befc9395ba7797d0ccea9@%3Cdev.tomee.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/0fcef7321095ce0bc597d468d150cff3d647f4cb3aef3bd4d20e1c69@%3Ccommits.tinkerpop.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/2766188be238a446a250ef76801037d452979152d85bce5e46805815@%3Cissues.iceberg.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/2d2a76440becb610b9a9cb49b15eac3934b02c2dbcaacde1000353e4@%3Cdev.tomee.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/34717424b4d08b74f65c09a083d6dd1cb0763f37a15d6de135998c1d@%3Cdev.tomee.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/519eb0fd45642dcecd9ff74cb3e71c20a4753f7d82e2f07864b5108f@%3Cdev.drill.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/525bcf949a4b0da87a375cbad2680b8beccde749522f24c49befe7fb@%3Ccommits.pulsar.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/56c8042873595b8c863054c7bfccab4bf2c01c6f5abedae249d914b9@%3Cdev.tomee.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/5ecc333113b139429f4f05000d4aa2886974d4df3269c1dd990bb319@%3Cdev.tomee.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/5fc0e16b7af2590bf1e97c76c136291c4fdb244ee63c65c485c9a7a1@%3Cdev.tomee.apache.org%3E"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2022/Mar/23"
}
],
"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": "Deserialization of untrusted data in FasterXML jackson-databind"
}
GHSA-6FW4-HR69-G3RV
Vulnerability from github – Published: 2021-05-06 17:29 – Updated: 2021-07-29 22:00The package property-expr before 2.0.3 are vulnerable to Prototype Pollution via the setter function.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "property-expr"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.0.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2020-7707"
],
"database_specific": {
"cwe_ids": [
"CWE-1321",
"CWE-915"
],
"github_reviewed": true,
"github_reviewed_at": "2021-05-05T21:16:41Z",
"nvd_published_at": "2020-08-18T14:15:00Z",
"severity": "CRITICAL"
},
"details": "The package property-expr before 2.0.3 are vulnerable to Prototype Pollution via the setter function.",
"id": "GHSA-6fw4-hr69-g3rv",
"modified": "2021-07-29T22:00:50Z",
"published": "2021-05-06T17:29:47Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-7707"
},
{
"type": "WEB",
"url": "https://github.com/jquense/expr/commit/df846910915d59f711ce63c1f817815bceab5ff7"
},
{
"type": "WEB",
"url": "https://snyk.io/vuln/SNYK-JAVA-ORGWEBJARSNPM-598857"
},
{
"type": "WEB",
"url": "https://snyk.io/vuln/SNYK-JS-PROPERTYEXPR-598800"
}
],
"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": "Prototype Pollution in property-expr"
}
GHSA-6FW7-3Q8R-M5VJ
Vulnerability from github – Published: 2026-05-14 14:52 – Updated: 2026-06-09 13:09Summary
A Mass Assignment vulnerability exists in the variable update endpoint of FlowiseAI.
The endpoint allows authenticated users to modify server-controlled properties such as workspaceId, createdDate, and updatedDate when updating a variable resource.
Due to missing server-side validation and authorization checks, an attacker can manipulate the workspaceId field and reassign variables to arbitrary workspaces.
This behavior may break tenant isolation in multi-workspace environments.
Details
The endpoint responsible for updating variables:
PUT /api/v1/variables/{variableId}
accepts a JSON request body containing the variable definition.
However, the backend does not restrict which attributes can be modified by the client. As a result, user-controlled request bodies can include internal properties that should normally be controlled exclusively by the server.
Server-controlled fields that can be manipulated include:
- workspaceId
- createdDate
- updatedDate
These fields appear to be directly mapped to the database entity without strict input validation or authorization checks.
For example, the following request body was accepted by the server:
{
"name": "aaa",
"value": "bbbe",
"type": "static",
"createdDate": "2016-03-06T17:59:30.000Z",
"updatedDate": "2016-03-06T18:00:17.000Z",
"workspaceId": "11111111-2222-3333-4444-555555555555"
}
The server accepted the attacker-controlled workspaceId and metadata fields and persisted them.
PoC
Request
PUT /api/v1/variables/<VARIABLE_ID>
Content-Type: application/json
{
"name": "aaa",
"value": "bbbe",
"type": "static",
"createdDate": "2016-03-06T17:59:30.000Z",
"updatedDate": "2016-03-06T18:00:17.000Z",
"workspaceId": "11111111-2222-3333-4444-555555555555"
}
Response
{
"id": "0a2b9f61-4a97-4ff8-b80d-00275ed18674",
"name": "aaa",
"value": "bbbe",
"type": "static",
"createdDate": "2016-03-06T17:59:30.000Z",
"updatedDate": "2026-03-06T18:05:17.000Z",
"workspaceId": "11111111-2222-3333-4444-555555555555"
}
This confirms that the backend accepts and persists attacker-controlled internal properties.
Impact
This vulnerability allows authenticated users to manipulate internal attributes of variable resources.
Possible impacts include:
- Cross-workspace reassignment of variables (workspaceId)
- Unauthorized modification of metadata (createdDate, updatedDate)
- Potential tenant isolation bypass in multi-workspace deployments
In multi-tenant environments, this may allow an attacker to move variables between workspaces without authorization.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.1.1"
},
"package": {
"ecosystem": "npm",
"name": "flowise"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.1.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-42861"
],
"database_specific": {
"cwe_ids": [
"CWE-284",
"CWE-639",
"CWE-915"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-14T14:52:24Z",
"nvd_published_at": "2026-06-08T16:16:39Z",
"severity": "HIGH"
},
"details": "### Summary\nA Mass Assignment vulnerability exists in the variable update endpoint of FlowiseAI.\n\nThe endpoint allows authenticated users to modify server-controlled properties such as workspaceId, createdDate, and updatedDate when updating a variable resource.\n\nDue to missing server-side validation and authorization checks, an attacker can manipulate the workspaceId field and reassign variables to arbitrary workspaces.\n\nThis behavior may break tenant isolation in multi-workspace environments.\n\n### Details\nThe endpoint responsible for updating variables:\n\n**PUT /api/v1/variables/{variableId}**\n\naccepts a JSON request body containing the variable definition.\n\nHowever, the backend does not restrict which attributes can be modified by the client. As a result, user-controlled request bodies can include internal properties that should normally be controlled exclusively by the server.\n\nServer-controlled fields that can be manipulated include:\n\n- workspaceId\n- createdDate\n- updatedDate\n\nThese fields appear to be directly mapped to the database entity without strict input validation or authorization checks.\n\nFor example, the following request body was accepted by the server:\n\n```json\n{\n \"name\": \"aaa\",\n \"value\": \"bbbe\",\n \"type\": \"static\",\n \"createdDate\": \"2016-03-06T17:59:30.000Z\",\n \"updatedDate\": \"2016-03-06T18:00:17.000Z\",\n \"workspaceId\": \"11111111-2222-3333-4444-555555555555\"\n}\n```\n\nThe server accepted the attacker-controlled workspaceId and metadata fields and persisted them.\n\n### PoC\n**Request**\n\n```http\nPUT /api/v1/variables/\u003cVARIABLE_ID\u003e\nContent-Type: application/json\n\n{\n \"name\": \"aaa\",\n \"value\": \"bbbe\",\n \"type\": \"static\",\n \"createdDate\": \"2016-03-06T17:59:30.000Z\",\n \"updatedDate\": \"2016-03-06T18:00:17.000Z\",\n \"workspaceId\": \"11111111-2222-3333-4444-555555555555\"\n}\n```\n\n**Response**\n\n```json\n{\n \"id\": \"0a2b9f61-4a97-4ff8-b80d-00275ed18674\",\n \"name\": \"aaa\",\n \"value\": \"bbbe\",\n \"type\": \"static\",\n \"createdDate\": \"2016-03-06T17:59:30.000Z\",\n \"updatedDate\": \"2026-03-06T18:05:17.000Z\",\n \"workspaceId\": \"11111111-2222-3333-4444-555555555555\"\n}\n```\n\nThis confirms that the backend accepts and persists attacker-controlled internal properties.\n\n### Impact\nThis vulnerability allows authenticated users to manipulate internal attributes of variable resources.\n\nPossible impacts include:\n\n1. Cross-workspace reassignment of variables (workspaceId)\n2. Unauthorized modification of metadata (createdDate, updatedDate)\n3. Potential tenant isolation bypass in multi-workspace deployments\n\nIn multi-tenant environments, this may allow an attacker to move variables between workspaces without authorization.",
"id": "GHSA-6fw7-3q8r-m5vj",
"modified": "2026-06-09T13:09:53Z",
"published": "2026-05-14T14:52:24Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/FlowiseAI/Flowise/security/advisories/GHSA-6fw7-3q8r-m5vj"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42861"
},
{
"type": "PACKAGE",
"url": "https://github.com/FlowiseAI/Flowise"
},
{
"type": "WEB",
"url": "https://github.com/FlowiseAI/Flowise/releases/tag/flowise%403.1.2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "FlowiseAI has Mass Assignment in Variable Update Endpoint that Allows Cross-Workspace Resource Reassignment"
}
GHSA-6GP3-H3JJ-PRX4
Vulnerability from github – Published: 2020-04-07 15:47 – Updated: 2022-04-28 17:58class-transformer through 0.2.3 is vulnerable to Prototype Pollution. The 'classToPlainFromExist' function could be tricked into adding or modifying properties of 'Object.prototype' using a 'proto' payload.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "class-transformer"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.3.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2020-7637"
],
"database_specific": {
"cwe_ids": [
"CWE-1321",
"CWE-915"
],
"github_reviewed": true,
"github_reviewed_at": "2020-04-07T15:46:31Z",
"nvd_published_at": "2020-04-06T13:15:00Z",
"severity": "MODERATE"
},
"details": "class-transformer through 0.2.3 is vulnerable to Prototype Pollution. The \u0027classToPlainFromExist\u0027 function could be tricked into adding or modifying properties of \u0027Object.prototype\u0027 using a \u0027__proto__\u0027 payload.",
"id": "GHSA-6gp3-h3jj-prx4",
"modified": "2022-04-28T17:58:13Z",
"published": "2020-04-07T15:47:40Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-7637"
},
{
"type": "WEB",
"url": "https://github.com/typestack/class-transformer/commit/8f04eb9db02de708f1a20f6f2d2bb309b2fed01e"
},
{
"type": "PACKAGE",
"url": "https://github.com/typestack/class-transformer"
},
{
"type": "WEB",
"url": "https://github.com/typestack/class-transformer/blob/a650d9f490573443f62508bc063b857bcd5e2525/src/ClassTransformer.ts#L29-L31,"
},
{
"type": "WEB",
"url": "https://snyk.io/vuln/SNYK-JS-CLASSTRANSFORMER-564431"
}
],
"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:N",
"type": "CVSS_V3"
}
],
"summary": "Prototype pollution in class-transformer"
}
GHSA-6HWH-RQWF-CXXR
Vulnerability from github – Published: 2021-05-07 16:32 – Updated: 2021-07-28 18:36vega-util prior to 1.13.1 allows manipulation of object prototype. The 'vega.mergeConfig' method within vega-util could be tricked into adding or modifying properties of the Object.prototype.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "vega-util"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.13.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2019-10806"
],
"database_specific": {
"cwe_ids": [
"CWE-1321",
"CWE-20",
"CWE-915"
],
"github_reviewed": true,
"github_reviewed_at": "2021-04-23T20:26:16Z",
"nvd_published_at": "2020-03-09T16:15:00Z",
"severity": "MODERATE"
},
"details": "vega-util prior to 1.13.1 allows manipulation of object prototype. The \u0026#39;vega.mergeConfig\u0026#39; method within vega-util could be tricked into adding or modifying properties of the Object.prototype.",
"id": "GHSA-6hwh-rqwf-cxxr",
"modified": "2021-07-28T18:36:56Z",
"published": "2021-05-07T16:32:02Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-10806"
},
{
"type": "WEB",
"url": "https://github.com/vega/vega/commit/8f33a0b5170d7de4f12fc248ec0901234342367b"
},
{
"type": "WEB",
"url": "https://snyk.io/vuln/SNYK-JS-VEGAUTIL-559223"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Improperly Controlled Modification of Dynamically-Determined Object Attributes in vega-util"
}
GHSA-6XP4-CF37-PPJH
Vulnerability from github – Published: 2026-06-12 18:28 – Updated: 2026-06-12 18:28Summary
/api/public/v1/roles/assign is guarded by the builderOrAdmin middleware, which passes any user who is a builder for the app id in the x-budibase-app-id header. That check admits both global builders and workspace-scoped builders (builder.apps set but builder.global unset). The controller then spreads the request body into the SDK call, and the SDK grants builder.global=true or admin.global=true on whichever user ids the caller supplies. Bob, a workspace-scoped builder with an API key, promotes himself or any other user to global admin with one POST. The whole flow is tenant-wide privilege escalation from an app-level role, available to anyone with an Enterprise license that unlocks the EXPANDED_PUBLIC_API feature.
Details
Controller (packages/server/src/api/controllers/public/roles.ts:13-17):
export async function assignAppBuilder(ctx: Ctx) {
const { userIds, ...assignmentProps } = ctx.request.body
await sdk.publicApi.roles.assign(userIds, assignmentProps)
ctx.body = { data: { userIds } }
}
Nothing filters assignmentProps. The request body's builder and admin keys flow directly into the SDK.
SDK (packages/pro/src/sdk/publicApi/roles.ts:17-47):
export async function assign(userIds: string[], opts: AssignmentOpts) {
if (!(await isExpandedPublicApiEnabled())) {
throw new Error("Unable to assign roles - license required.")
}
const users = await userDB.bulkGet(userIds)
for (let user of users) {
// ...
if (opts.builder) {
user.builder = { global: true }
}
if (opts.admin) {
user.admin = { global: true }
}
}
await userDB.bulkUpdate(users)
}
No check that the caller already holds the privilege they are granting. user.builder is overwritten unconditionally, which also strips any existing builder.apps scope from the target.
Route guard (packages/backend-core/src/middleware/builderOrAdmin.ts:6-20):
export async function builderOrAdmin(ctx: UserCtx, next: any) {
if (ctx.internal || isAdmin(ctx.user)) { return next() }
const workspaceId = await getWorkspaceIdFromCtx(ctx)
if (!workspaceId && !env.isWorker()) {
ctx.throw(403, "This request required a workspace id.")
} else if (!workspaceId && !hasBuilderPermissions(ctx.user)) {
ctx.throw(403, "Admin/Builder user only endpoint.")
} else if (workspaceId && !isBuilder(ctx.user, workspaceId)) {
ctx.throw(403, "Workspace Admin/Builder user only endpoint.")
}
// passes
}
isBuilder(user, workspaceId) returns true for any user whose builder.apps array contains the workspace id, even when builder.global is unset. The endpoint therefore trusts an app-level builder with a global-scope grant.
Proof of Concept
Tested on Budibase 3.35.8 (master at f960e361). The public API license gate at roles.ts:18 was disabled in the test bundle so the underlying privilege-escalation could be reproduced end-to-end; on a licensed Enterprise tenant the gate passes and the same requests land.
Step 1: the admin creates two users. Alice is a workspace-scoped builder on an app (builder.apps: [app_...], builder.global unset, admin.global unset). Victim is a BASIC user.
Step 2: Alice calls GET /api/global/self/api_key to mint an API key tied to her identity:
curl -sS -b alice "$BASE/api/global/self/api_key"
# → {"apiKey":"80f28...","userId":"us_dab...","createdAt":"..."}
Step 3: Alice calls /api/public/v1/roles/assign with the victim's id and builder: true. She scopes the request to her own app via x-budibase-app-id so builderOrAdmin passes:
curl -sS -X POST "$BASE/api/public/v1/roles/assign" \
-H "Content-Type: application/json" \
-H "x-budibase-api-key: $ALICE_APIKEY" \
-H "x-budibase-app-id: $APP_ID" \
-d '{"userIds":["us_70b6...victim"],"builder":true}'
Admin verifies:
BEFORE: builder: {'global': False} admin: {'global': False}
ATTACK: HTTP 200 {"data":{"userIds":["us_70b6..."]}}
AFTER: builder: {'global': True} admin: {'global': False}
Step 4: Alice follows up with "admin": true and can target her own id:
curl -sS -X POST "$BASE/api/public/v1/roles/assign" \
-H "Content-Type: application/json" \
-H "x-budibase-api-key: $ALICE_APIKEY" \
-H "x-budibase-app-id: $APP_ID" \
-d '{"userIds":["us_dab...alice"],"admin":true}'
AFTER: builder: {'apps': ['app_...']} admin: {'global': True}
Alice is now a global admin of the tenant. She kept builder.apps because the SDK only overwrites the keys it was asked to set; admin: true writes admin = { global: true } without touching builder.
Impact
Every workspace-scoped builder of any app in the tenant is one request away from global admin. Global admin grants unrestricted access to the tenant: every app in every workspace, every user, every datasource credential, every automation, every SCIM / OIDC / audit-log config. The mass-assignment also strips scoping from the target's existing role, so downgrading a legitimate global builder to an app-scoped builder fails: a later call reinstates global: true.
A tenant that shares app-building duties across teams (the common Enterprise pattern) cannot hold the per-app boundary with the current middleware. This matches GHSA-2g39-332f-68p9 (Critical Privilege Escalation & IDOR via Missing RBAC) in shape and impact.
Recommended Fix
Enforce the caller's privilege in the SDK, matching the grant they want to make:
// packages/pro/src/sdk/publicApi/roles.ts:32-43
const caller = context.getIdentity() // or however the SDK resolves the caller
if (opts.builder) {
if (!caller?.builder?.global && !caller?.admin?.global) {
throw new HTTPError("Only global builders or admins can grant global builder", 403)
}
user.builder = { global: true }
}
if (opts.admin) {
if (!caller?.admin?.global) {
throw new HTTPError("Only global admins can grant global admin", 403)
}
user.admin = { global: true }
}
Alternative, equally valid: tighten builderOrAdmin so that endpoints which can set global-scope properties require isGlobalBuilder or isAdmin. That fixes this endpoint and any future endpoint that shares the middleware.
Whichever fix lands, also strip builder and admin from assignmentProps at the controller boundary (packages/server/src/api/controllers/public/roles.ts:14) unless the caller has admin.global=true. Defense-in-depth against a future SDK regression.
Found by aisafe.io
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "@budibase/server"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.39.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-48150"
],
"database_specific": {
"cwe_ids": [
"CWE-915"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-12T18:28:26Z",
"nvd_published_at": "2026-05-27T18:16:27Z",
"severity": "CRITICAL"
},
"details": "## Summary\n\n`/api/public/v1/roles/assign` is guarded by the `builderOrAdmin` middleware, which passes any user who is a builder for the app id in the `x-budibase-app-id` header. That check admits both global builders and workspace-scoped builders (`builder.apps` set but `builder.global` unset). The controller then spreads the request body into the SDK call, and the SDK grants `builder.global=true` or `admin.global=true` on whichever user ids the caller supplies. Bob, a workspace-scoped builder with an API key, promotes himself or any other user to global admin with one POST. The whole flow is tenant-wide privilege escalation from an app-level role, available to anyone with an Enterprise license that unlocks the `EXPANDED_PUBLIC_API` feature.\n\n## Details\n\nController (`packages/server/src/api/controllers/public/roles.ts:13-17`):\n\n```typescript\nexport async function assignAppBuilder(ctx: Ctx) {\n const { userIds, ...assignmentProps } = ctx.request.body\n await sdk.publicApi.roles.assign(userIds, assignmentProps)\n ctx.body = { data: { userIds } }\n}\n```\n\nNothing filters `assignmentProps`. The request body\u0027s `builder` and `admin` keys flow directly into the SDK.\n\nSDK (`packages/pro/src/sdk/publicApi/roles.ts:17-47`):\n\n```typescript\nexport async function assign(userIds: string[], opts: AssignmentOpts) {\n if (!(await isExpandedPublicApiEnabled())) {\n throw new Error(\"Unable to assign roles - license required.\")\n }\n const users = await userDB.bulkGet(userIds)\n for (let user of users) {\n // ...\n if (opts.builder) {\n user.builder = { global: true }\n }\n if (opts.admin) {\n user.admin = { global: true }\n }\n }\n await userDB.bulkUpdate(users)\n}\n```\n\nNo check that the caller already holds the privilege they are granting. `user.builder` is overwritten unconditionally, which also strips any existing `builder.apps` scope from the target.\n\nRoute guard (`packages/backend-core/src/middleware/builderOrAdmin.ts:6-20`):\n\n```typescript\nexport async function builderOrAdmin(ctx: UserCtx, next: any) {\n if (ctx.internal || isAdmin(ctx.user)) { return next() }\n const workspaceId = await getWorkspaceIdFromCtx(ctx)\n if (!workspaceId \u0026\u0026 !env.isWorker()) {\n ctx.throw(403, \"This request required a workspace id.\")\n } else if (!workspaceId \u0026\u0026 !hasBuilderPermissions(ctx.user)) {\n ctx.throw(403, \"Admin/Builder user only endpoint.\")\n } else if (workspaceId \u0026\u0026 !isBuilder(ctx.user, workspaceId)) {\n ctx.throw(403, \"Workspace Admin/Builder user only endpoint.\")\n }\n // passes\n}\n```\n\n`isBuilder(user, workspaceId)` returns true for any user whose `builder.apps` array contains the workspace id, even when `builder.global` is unset. The endpoint therefore trusts an app-level builder with a global-scope grant.\n\n## Proof of Concept\n\nTested on Budibase 3.35.8 (master at f960e361). The public API license gate at `roles.ts:18` was disabled in the test bundle so the underlying privilege-escalation could be reproduced end-to-end; on a licensed Enterprise tenant the gate passes and the same requests land.\n\nStep 1: the admin creates two users. Alice is a workspace-scoped builder on an app (`builder.apps: [app_...]`, `builder.global` unset, `admin.global` unset). Victim is a BASIC user.\n\nStep 2: Alice calls `GET /api/global/self/api_key` to mint an API key tied to her identity:\n\n```bash\ncurl -sS -b alice \"$BASE/api/global/self/api_key\"\n# \u2192 {\"apiKey\":\"80f28...\",\"userId\":\"us_dab...\",\"createdAt\":\"...\"}\n```\n\nStep 3: Alice calls `/api/public/v1/roles/assign` with the victim\u0027s id and `builder: true`. She scopes the request to her own app via `x-budibase-app-id` so `builderOrAdmin` passes:\n\n```bash\ncurl -sS -X POST \"$BASE/api/public/v1/roles/assign\" \\\n -H \"Content-Type: application/json\" \\\n -H \"x-budibase-api-key: $ALICE_APIKEY\" \\\n -H \"x-budibase-app-id: $APP_ID\" \\\n -d \u0027{\"userIds\":[\"us_70b6...victim\"],\"builder\":true}\u0027\n```\n\nAdmin verifies:\n\n```\nBEFORE: builder: {\u0027global\u0027: False} admin: {\u0027global\u0027: False}\nATTACK: HTTP 200 {\"data\":{\"userIds\":[\"us_70b6...\"]}}\nAFTER: builder: {\u0027global\u0027: True} admin: {\u0027global\u0027: False}\n```\n\nStep 4: Alice follows up with `\"admin\": true` and can target her own id:\n\n```bash\ncurl -sS -X POST \"$BASE/api/public/v1/roles/assign\" \\\n -H \"Content-Type: application/json\" \\\n -H \"x-budibase-api-key: $ALICE_APIKEY\" \\\n -H \"x-budibase-app-id: $APP_ID\" \\\n -d \u0027{\"userIds\":[\"us_dab...alice\"],\"admin\":true}\u0027\n```\n\n```\nAFTER: builder: {\u0027apps\u0027: [\u0027app_...\u0027]} admin: {\u0027global\u0027: True}\n```\n\nAlice is now a global admin of the tenant. She kept `builder.apps` because the SDK only overwrites the keys it was asked to set; `admin: true` writes `admin = { global: true }` without touching `builder`.\n\n## Impact\n\nEvery workspace-scoped builder of any app in the tenant is one request away from global admin. Global admin grants unrestricted access to the tenant: every app in every workspace, every user, every datasource credential, every automation, every SCIM / OIDC / audit-log config. The mass-assignment also strips scoping from the target\u0027s existing role, so downgrading a legitimate global builder to an app-scoped builder fails: a later call reinstates `global: true`.\n\nA tenant that shares app-building duties across teams (the common Enterprise pattern) cannot hold the per-app boundary with the current middleware. This matches GHSA-2g39-332f-68p9 (Critical Privilege Escalation \u0026 IDOR via Missing RBAC) in shape and impact.\n\n## Recommended Fix\n\nEnforce the caller\u0027s privilege in the SDK, matching the grant they want to make:\n\n```typescript\n// packages/pro/src/sdk/publicApi/roles.ts:32-43\nconst caller = context.getIdentity() // or however the SDK resolves the caller\nif (opts.builder) {\n if (!caller?.builder?.global \u0026\u0026 !caller?.admin?.global) {\n throw new HTTPError(\"Only global builders or admins can grant global builder\", 403)\n }\n user.builder = { global: true }\n}\nif (opts.admin) {\n if (!caller?.admin?.global) {\n throw new HTTPError(\"Only global admins can grant global admin\", 403)\n }\n user.admin = { global: true }\n}\n```\n\nAlternative, equally valid: tighten `builderOrAdmin` so that endpoints which can set global-scope properties require `isGlobalBuilder` or `isAdmin`. That fixes this endpoint and any future endpoint that shares the middleware.\n\nWhichever fix lands, also strip `builder` and `admin` from `assignmentProps` at the controller boundary (`packages/server/src/api/controllers/public/roles.ts:14`) unless the caller has `admin.global=true`. Defense-in-depth against a future SDK regression.\n\n---\n*Found by [aisafe.io](https://aisafe.io)*",
"id": "GHSA-6xp4-cf37-ppjh",
"modified": "2026-06-12T18:28:26Z",
"published": "2026-06-12T18:28:26Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/Budibase/budibase/security/advisories/GHSA-6xp4-cf37-ppjh"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-48150"
},
{
"type": "PACKAGE",
"url": "https://github.com/Budibase/budibase"
}
],
"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:L",
"type": "CVSS_V3"
}
],
"summary": "Budibase: Workspace-scoped builder escalates to global admin via /api/public/v1/roles/assign"
}
GHSA-728H-4MWJ-F2P4
Vulnerability from github – Published: 2026-05-14 16:19 – Updated: 2026-06-09 13:10Summary
Type: Mass assignment via Object.assign(entity, body) -> client-controlled workspaceId (and on create, id) overwritten on the CustomTemplate entity -> cross-workspace data takeover and IDOR.
File: packages/server/src/services/marketplaces/index.ts
Root cause: The CustomTemplate controller/service constructs a new CustomTemplate() and copies the request body into it via Object.assign(...) without an explicit field allowlist. The request body therefore can include workspaceId, id, createdDate, updatedDate. The server only rebinds some of these after the assign (e.g. on create, it overwrites workspaceId but not id; on update, it overwrites id but not workspaceId). The remaining client-controlled values land directly on the persisted row, breaking workspace isolation. Same root pattern as the customtemplate entity's sibling controllers and as DocumentStore before it was patched in commit 840d2ae.
Affected Code
File: packages/server/src/services/marketplaces/index.ts
// at line 211
Object.assign(newTemplate, body) // <-- BUG: body.id, body.workspaceId accepted
Why it's wrong: Object.assign(target, source) copies every own enumerable property of source onto target. The TypeORM/SQL persistence layer below it does not strip ownership-bearing columns, so workspaceId set in the request body lands as the new workspaceId of the persisted row. The DocumentStore patch (commit 840d2ae) demonstrated the intended fix shape (explicit field-by-field allowlist) but it has not been applied to this entity.
Exploit Chain
- Attacker is an authenticated member of workspace A. They have a session cookie / JWT for the Flowise web UI. State at this point: attacker can read and write entities scoped to workspace A.
- Attacker creates a customtemplate in workspace A via the documented API (or reuses an existing one they own). They note its entity
id. - Attacker issues a
PUT /api/v1/customtemplates/<id>(or equivalent endpoint) with a JSON body that includes"workspaceId": "<workspace-B-id>"(an arbitrary other workspace's UUID). State at this point: the request reaches the controller as a workspace-A authenticated request. - The controller calls
Object.assign(updateEntity, body). The body'sworkspaceIdoverwrites the entity'sworkspaceIdfield. The persistence layer commits the row. - Final state: the customtemplate row is now owned by workspace B. Workspace B members can see it, modify it, and use it. Workspace A loses access (it no longer satisfies their workspace filter). The original creator's workspace audit shows nothing because the operation looked like a normal update.
Security Impact
Severity: High. Cross-workspace boundary violation by any authenticated workspace member.
Attacker capability: Any authenticated user with permission to update a customtemplate can move it to any workspace whose UUID they can guess or enumerate (workspace UUIDs are exposed in many API responses, so enumeration is trivial). CustomTemplates encode reusable workflow templates scoped to a workspace. Cross-workspace movement via workspaceId overwrite makes the template appear in another workspace's marketplace listing.
Preconditions: Authenticated session with edit permission for the source customtemplate. No second factor required. Workspace UUIDs are exposed via the /api/v1/workspaces listing or via any cross-referenced object's workspaceId field, so target enumeration is trivial.
Differential: PoC-verified by source inspection of the original GHSA-q4pr-4r26-c69r. Patched build (with the suggested fix below) refuses the workspaceId field; vulnerable build accepts it and persists it.
Suggested Fix
Already fixed in PR https://github.com/FlowiseAI/Flowise/pull/6129 (allowlist pattern applied).
// Allowlist pattern (matches commit 840d2ae for DocumentStore):
const updatedCustomTemplate = new CustomTemplate()
if (body.<allowed_field_1> !== undefined) updatedCustomTemplate.<allowed_field_1> = body.<allowed_field_1>
if (body.<allowed_field_2> !== undefined) updatedCustomTemplate.<allowed_field_2> = body.<allowed_field_2>
// ...whitelist only the documented fields. Never copy id, workspaceId, createdDate, updatedDate from the client.
Regression tests should assert that a request body containing workspaceId, id, createdDate, or updatedDate is rejected (or at minimum: does not change those columns on the persisted row) for both create and update paths.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.1.1"
},
"package": {
"ecosystem": "npm",
"name": "flowise"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.1.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-46476"
],
"database_specific": {
"cwe_ids": [
"CWE-915"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-14T16:19:32Z",
"nvd_published_at": "2026-06-08T16:16:41Z",
"severity": "HIGH"
},
"details": "## Summary\n\n**Type:** Mass assignment via `Object.assign(entity, body)` -\u003e client-controlled `workspaceId` (and on create, `id`) overwritten on the CustomTemplate entity -\u003e cross-workspace data takeover and IDOR.\n**File:** `packages/server/src/services/marketplaces/index.ts`\n**Root cause:** The CustomTemplate controller/service constructs a `new CustomTemplate()` and copies the request body into it via `Object.assign(...)` without an explicit field allowlist. The request body therefore can include `workspaceId`, `id`, `createdDate`, `updatedDate`. The server only rebinds *some* of these after the assign (e.g. on create, it overwrites `workspaceId` but not `id`; on update, it overwrites `id` but not `workspaceId`). The remaining client-controlled values land directly on the persisted row, breaking workspace isolation. Same root pattern as the customtemplate entity\u0027s sibling controllers and as `DocumentStore` before it was patched in commit 840d2ae.\n\n## Affected Code\n\n**File:** `packages/server/src/services/marketplaces/index.ts`\n\n```ts\n// at line 211\nObject.assign(newTemplate, body) // \u003c-- BUG: body.id, body.workspaceId accepted\n```\n\n**Why it\u0027s wrong:** `Object.assign(target, source)` copies every own enumerable property of `source` onto `target`. The TypeORM/SQL persistence layer below it does not strip ownership-bearing columns, so `workspaceId` set in the request body lands as the new `workspaceId` of the persisted row. The DocumentStore patch (commit 840d2ae) demonstrated the intended fix shape (explicit field-by-field allowlist) but it has not been applied to this entity.\n\n## Exploit Chain\n\n1. Attacker is an authenticated member of workspace A. They have a session cookie / JWT for the Flowise web UI. State at this point: attacker can read and write entities scoped to workspace A.\n2. Attacker creates a customtemplate in workspace A via the documented API (or reuses an existing one they own). They note its entity `id`.\n3. Attacker issues a `PUT /api/v1/customtemplates/\u003cid\u003e` (or equivalent endpoint) with a JSON body that includes `\"workspaceId\": \"\u003cworkspace-B-id\u003e\"` (an arbitrary other workspace\u0027s UUID). State at this point: the request reaches the controller as a workspace-A authenticated request.\n4. The controller calls `Object.assign(updateEntity, body)`. The body\u0027s `workspaceId` overwrites the entity\u0027s `workspaceId` field. The persistence layer commits the row.\n5. Final state: the customtemplate row is now owned by workspace B. Workspace B members can see it, modify it, and use it. Workspace A loses access (it no longer satisfies their workspace filter). The original creator\u0027s workspace audit shows nothing because the operation looked like a normal update.\n\n## Security Impact\n\n**Severity:** High. Cross-workspace boundary violation by any authenticated workspace member.\n**Attacker capability:** Any authenticated user with permission to update a customtemplate can move it to any workspace whose UUID they can guess or enumerate (workspace UUIDs are exposed in many API responses, so enumeration is trivial). CustomTemplates encode reusable workflow templates scoped to a workspace. Cross-workspace movement via `workspaceId` overwrite makes the template appear in another workspace\u0027s marketplace listing.\n**Preconditions:** Authenticated session with edit permission for the source customtemplate. No second factor required. Workspace UUIDs are exposed via the `/api/v1/workspaces` listing or via any cross-referenced object\u0027s `workspaceId` field, so target enumeration is trivial.\n**Differential:** PoC-verified by source inspection of the original GHSA-q4pr-4r26-c69r. Patched build (with the suggested fix below) refuses the `workspaceId` field; vulnerable build accepts it and persists it.\n\n## Suggested Fix\n\nAlready fixed in PR https://github.com/FlowiseAI/Flowise/pull/6129 (allowlist pattern applied).\n\n```ts\n// Allowlist pattern (matches commit 840d2ae for DocumentStore):\nconst updatedCustomTemplate = new CustomTemplate()\nif (body.\u003callowed_field_1\u003e !== undefined) updatedCustomTemplate.\u003callowed_field_1\u003e = body.\u003callowed_field_1\u003e\nif (body.\u003callowed_field_2\u003e !== undefined) updatedCustomTemplate.\u003callowed_field_2\u003e = body.\u003callowed_field_2\u003e\n// ...whitelist only the documented fields. Never copy id, workspaceId, createdDate, updatedDate from the client.\n```\n\nRegression tests should assert that a request body containing `workspaceId`, `id`, `createdDate`, or `updatedDate` is rejected (or at minimum: does not change those columns on the persisted row) for both create and update paths.",
"id": "GHSA-728h-4mwj-f2p4",
"modified": "2026-06-09T13:10:36Z",
"published": "2026-05-14T16:19:32Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/FlowiseAI/Flowise/security/advisories/GHSA-728h-4mwj-f2p4"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46476"
},
{
"type": "WEB",
"url": "https://github.com/FlowiseAI/Flowise/pull/6129"
},
{
"type": "WEB",
"url": "https://github.com/FlowiseAI/Flowise/commit/f64047bdcf4cbd6a30ec348b9e3f2899ff514e89"
},
{
"type": "PACKAGE",
"url": "https://github.com/FlowiseAI/Flowise"
},
{
"type": "WEB",
"url": "https://github.com/FlowiseAI/Flowise/releases/tag/flowise%403.1.2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "FlowiseAI: CustomTemplate create+update mass-assignment allows cross-workspace template takeover"
}
GHSA-77XQ-CPVG-7XM2
Vulnerability from github – Published: 2021-05-10 19:07 – Updated: 2023-09-05 22:45This affects the package @tsed/core before 5.65.7. This vulnerability relates to the deepExtend function which is used as part of the utils directory. Depending on if user input is provided, an attacker can overwrite and pollute the object prototype of a program.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "@tsed/core"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.65.7"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2020-7748"
],
"database_specific": {
"cwe_ids": [
"CWE-1321",
"CWE-915"
],
"github_reviewed": true,
"github_reviewed_at": "2021-04-20T17:41:36Z",
"nvd_published_at": "2020-10-20T11:15:00Z",
"severity": "MODERATE"
},
"details": "This affects the package @tsed/core before 5.65.7. This vulnerability relates to the `deepExtend` function which is used as part of the utils directory. Depending on if user input is provided, an attacker can overwrite and pollute the object prototype of a program.",
"id": "GHSA-77xq-cpvg-7xm2",
"modified": "2023-09-05T22:45:47Z",
"published": "2021-05-10T19:07:56Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-7748"
},
{
"type": "WEB",
"url": "https://github.com/TypedProject/tsed/commit/1395773ddac35926cf058fc6da9fb8e82266761b"
},
{
"type": "WEB",
"url": "https://github.com/TypedProject/tsed/blob/production/packages/core/src/utils/deepExtends.ts%23L36"
},
{
"type": "PACKAGE",
"url": "https://github.com/tsedio/tsed"
},
{
"type": "WEB",
"url": "https://snyk.io/vuln/SNYK-JS-TSEDCORE-1019382"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
}
],
"summary": "Prototype pollution in @tsed/core"
}
Mitigation
- If available, use features of the language or framework that allow specification of allowlists of attributes or fields that are allowed to be modified. If possible, prefer allowlists over denylists.
- For applications written with Ruby on Rails, use the attr_accessible (allowlist) or attr_protected (denylist) macros in each class that may be used in mass assignment.
Mitigation
If available, use the signing/sealing features of the programming language to assure that deserialized data has not been tainted. For example, a hash-based message authentication code (HMAC) could be used to ensure that data has not been modified.
Mitigation
Strategy: Input Validation
For any externally-influenced input, check the input against an allowlist of internal object attributes or fields that are allowed to be modified.
Mitigation
Strategy: Refactoring
Refactor the code so that object attributes or fields do not need to be dynamically identified, and only expose getter/setter functionality for the intended attributes.
No CAPEC attack patterns related to this CWE.