An Editor can set file-provisioning metadata (the grafana.app/managedBy, grafana.app/managerId and grafana.app/sourcePath annotations) when creating a dashboard through the dashboard API, because these fields were stored without an authorization check. The dashboard then appears file-provisioned, and administrators can no longer update or delete it through Grafana. The impact is limited to the same organization and no data is exposed.
Improperly Controlled Modification of Dynamically-Determined Object Attributes vulnerability in ash-project ash allows a user to set the value of a private action argument on the bulk destroy and bulk update paths.
Action arguments declared with public?: false are meant to be set only by trusted server-side code (for example via Ash.Changeset.set_private_argument/3) and must not be settable from end-user input. CVE-2026-55736 fixed the non-bulk changeset path to strip private arguments from user-supplied parameter maps, but the bulk destroy and bulk update paths were not covered.
Ash.Actions.Destroy.Bulk.base_changeset/5 and Ash.Actions.Update.Bulk.base_changeset/5 match every key in the caller-supplied parameter map against all of the action's arguments with no public? check, then apply the matches to the base changeset. A caller who can submit parameters to a bulk destroy or bulk update action (for example through AshJsonApi, AshGraphql, or a controller that forwards request parameters to Ash.bulk_destroy/4 or Ash.bulk_update/4) can therefore set any private argument of that action, including one referenced by an arg(...) template in the action's changes or validations. Depending on how the application uses the argument (for example an acting_user_id driving authorization or record ownership, or audit metadata), this can lead to an integrity violation or privilege escalation.
The fix requires public? in the argument matching on both bulk paths; private arguments remain settable server-side via the :private_arguments option.
This issue affects ash: from 2.17.15 before 3.33.11.
Formie is a Craft CMS plugin for creating forms. Prior to 2.2.23 and 3.1.31, Formie's formie/integrations/form-settings control panel action in IntegrationsController::actionFormSettings is reachable without the required form integration permissions and passes request-supplied settings to a configured integration. An authenticated attacker can replace outbound host properties such as apiUrl while the server uses stored API keys or OAuth tokens, causing non-blind server-side requests to an attacker-controlled or internal host and returning the remote response. This residual flaw remained because the permission gate added in version 3.1.28 excluded the form-settings action. Sites that permit low-privileged or front-end user authentication can therefore expose integration credentials and internal network responses. This issue is fixed in versions 2.2.23 and 3.1.31.
CVE-2026-61834 is a vulnerability in the scim-patch library versions prior to 0.9.2. The issue involves improper control of dynamically-determined object attributes, where attacker-controlled SCIM PATCH paths can traverse into shared built-in function objects and add properties. This causes process-global mutation that may affect application logic relying on inherited-method properties. The vulnerability is fixed in version 0.9.2.
djust versions prior to 1.0.7 have a vulnerability where state snapshots embedded in client pages are not integrity-checked. This allows a client to modify unsigned state data, such as privilege flags or account information, and send it back to the server to escalate privileges or tamper with business state. The issue is fixed in version 1.0.7 by signing state snapshots and rejecting unsigned or forged snapshots. As a workaround, disabling state snapshots or avoiding storing authorization state in public view attributes mitigates the risk.
djust provides Phoenix LiveView-style reactive server-side rendering for Django with Rust-powered performance. Prior to version 1.0.7, `djust.mixins.model_binding.ModelBindingMixin` provides a default `update_model` event handler and is part of the LiveView base MRO, so every LiveView exposes it. It `setattr`s a view attribute whose name is client-supplied (`field`), gated only by: reject `_`-prefixed names; reject a 14-entry denylist of framework internals (`FORBIDDEN_MODEL_FIELDS`); optional `allowed_model_fields` which defaults to None = allow all; and `hasattr` existence. As a result, a client can set any public, existing view attribute — not just the fields actually bound with `dj-model=` in the rendered template. The denylist covers framework plumbing but nothing about developer business/authz state, and the allowlist is opt-in (off by default). A developer who binds one `dj-model="search"` input and also keeps `self.account_id` / `self.is_admin` / `self.total_price` as view state does not realize a client can set ALL of them via `{type:event, event:"update_model", params:{field, value}}` over the WebSocket. Type coercion matches the target attribute's type (so `"true"` -> bool True), aiding the attacker. This issue is fixed in djust 1.0.7. As a workaround, set `allowed_model_fields` explicitly on every view using dj-model (or subclassing LiveView) to the minimal list of bindable fields; do not keep authorization/ownership state in public view attributes that share the view with dj-model bindings.
flat-to-nested converts a hierarchy from a flat representation to a nested representation. Prior to 1.1.2, FlatToNested.prototype.convert in index.js uses attacker-influenced id and parent record fields directly as keys in the plain temp and pendingChildOf objects. When parent or id is __proto__, temp[parent] can resolve to Object.prototype, and initPush() can write attacker-controlled data to the global children prototype property while existing prototype methods remain intact. Any application that passes attacker-influenced flat records to convert() can therefore expose unrelated objects to polluted inherited state, causing application-logic corruption or denial of service and potentially enabling greater impact when a downstream prototype-pollution gadget is present. The constructor and prototype strings are also unsafe inherited-key values in the same lookup design. This issue is fixed in version 1.1.2.
CVE-2026-83557 is a deserialization vulnerability in FasterXML jackson-databind affecting versions from 2.11.0 up to but excluding 2.18.10, 2.19.0 up to 2.21.6, 2.22.0 up to 2.22.2, 3.0.0 up to 3.1.6, and 3.2.0 up to 3.2.2. The issue arises because the DefaultBaseTypeLimitingValidator does not include java.lang.Comparable in its unsafe base types list, allowing polymorphic deserialization of any class implementing Comparable when @JsonTypeInfo is used without a custom validator. This can lead to attacker-controlled object instantiation, such as creating a java.io.File with an attacker-chosen path. No direct code execution via deserialization alone has been identified. Global default typing with explicit validators is not affected. Users should upgrade to fixed versions 2.18.10, 2.21.6, 2.22.2, 3.1.6, or 3.2.2 to remediate.
CVE-2026-78038 is a medium severity vulnerability in ash-project's ash_oban component that allows improper modification of dynamically-determined object attributes. The flaw arises because user input passed to the :args option of AshOban.build_trigger/3 can override trusted job arguments due to JSON key handling, enabling an attacker to retarget update or destroy triggers at other records, potentially crossing tenant boundaries. This breaks authorization and tenant isolation assumptions. The vulnerability affects versions from 0.2.5 up to but not including 0.8.14.
CVE-2026-59284 is a medium severity vulnerability in Spring Cloud Commons affecting versions 3.1.10 and earlier through 5.0.2. It involves the lack of an allow list for property keys when the writable /actuator/env endpoint is enabled, potentially allowing improper modification of dynamically-determined object attributes. The vulnerability is classified under CWE-915. No official patch or remediation guidance is currently confirmed.
CVE-2026-47849 is a high severity vulnerability in Spring Data REST that allows mutation of identifier (@Id) and version (@Version) properties via JSON Patch requests. This improper control of dynamically-determined object attributes can lead to integrity issues. The vulnerability affects multiple versions of Spring Data REST including 3.7.20 and earlier, 4.0.0 through 4.4.15, 4.5.0 through 4.5.12, 5.0.0 through 5.0.6, and 5.1.0. There is no confirmed patch or official remediation available at this time.
CVE-2026-47850 is a medium severity vulnerability in Spring Data REST where the persisted version (@Version) property of an aggregate root is not preserved when handling HTTP PUT requests against immutable target types. This issue affects multiple versions of Spring Data REST including 3.7.20 and earlier, 4.0.0 through 4.4.15, 4.5.0 through 4.5.12, 5.0.0 through 5.0.6, and 5.1.0. The vulnerability relates to improper control of dynamically-determined object attributes, classified under CWE-915. No official patch or remediation level has been provided yet, and no known exploits are reported in the wild.
CVE-2026-77144 is a vulnerability in the TYPO3 Extension "Events 2" that allows a user with frontend event management access to create events attributed to organizers other than themselves. This occurs because the plugin assigns a new event to the submitting user's organizer record only if no organizer is specified in the request, and the permission check only verifies that the user has any organizer role, not that they own the organizer record. The vulnerability has a high severity with a CVSS score of 7.1.
Craft CMS versions from 4.0.0-RC1 before 4.18.2 and from 5.0.0-RC1 before 5.10.6 contain an authenticated remote code execution vulnerability in the control panel element-search condition handling. The vulnerability arises due to a JSON cleanse bypass in condition.config, allowing Yii behavior/event configuration keys to be interpreted after decoding, which enables command execution as the PHP/web user.
CVE-2026-62315 is a vulnerability in the Frappe web application framework versions 16.31.0 and earlier. It involves improper control of dynamically-determined object attributes in the frappe.client.set_value function, allowing an authenticated user to mass-assign protected fields via the client endpoint. No fixed version is currently available.
CVE-2026-53958 is an improper authentication vulnerability in 4gaBoards prior to version 3.3.9. It allows an authenticated user to modify backend-managed single sign-on (SSO) identity attributes via a PATCH request to the user API. This flaw enables an attacker to associate a victim's SSO provider identifier with the attacker's account, causing the victim to be logged into the attacker-controlled account upon their first SSO login. The vulnerability is fixed in version 3.3.9.
Improperly Controlled Modification of Dynamically-Determined Object Attributes (CWE-915) in the case management functionality of Elastic Security in Kibana can lead to unauthorized modification of case data by an authenticated user who has not been granted case editing privileges, via Manipulating User-Controlled Variables (CAPEC-77). Object attributes accepted by the case management API were not subject to the same authorization enforcement applied in the user interface, so a low-privileged user could alter case records they were only entitled to view.
A flaw was found in the Data Science Pipelines Operator (DSPO). A namespace editor can exploit a vulnerability in the spec.database.customExtraParams field, which allows for the injection of dangerous parameters into the MySQL Data Source Name (DSN) string. By manipulating these parameters, an attacker can enable LOCAL INFILE functionality and exfiltrate sensitive files, such as the service account token, from the operator pod. This can lead to privilege escalation, allowing a namespace editor to gain cluster-admin privileges.
Sonatype Nexus Repository 3 did not properly filter internal configuration keys from user-supplied task properties when creating or updating a scheduled task through the administrative UI. An account holding permission to create at least one scheduled task type could supply a crafted property value that caused the system to overwrite the configuration of an unrelated, existing task instead of creating a new one.