Base de CVEs

oRPC is a tool that helps build APIs that are end-to-end type-safe and adhere to OpenAPI standards. Prior to 1.14.10, the @orpc/zod ZodSmartCoercionPlugin and experimental_ZodSmartCoercionPlugin collect object and record properties in plain objects and resolve shape keys through the prototype chain. A remote client that can reach a procedure with an object or record input can supply __proto__ to replace the prototype of the returned request object, allowing attacker-controlled inherited values to reach application lookups. For object schemas, keys such as constructor, toString, and __proto__ can instead resolve inherited members as Zod schemas and cause an unhandled TypeError before validation. The global Object.prototype, unrelated objects, other requests, and other users are not modified, and the availability effect is limited to crafted requests rather than persistent process-wide state. This issue is fixed in version 1.14.10.

oRPC is a tool that helps build APIs that are end-to-end type-safe and adhere to OpenAPI standards. Prior to 1.14.9, the @orpc/json-schema SmartCoercionPlugin uses JsonSchemaCoercer to collect object properties in a plain object and to resolve schema.properties entries through the prototype chain. A remote client that can reach a procedure with an object input schema can supply __proto__ to replace the prototype of the single coerced request object, or supply Object.prototype member names such as constructor and toString so inherited values are treated as sub-schemas and pass the coercer's satisfaction check. Attacker-controlled inherited properties can consequently affect handler, Object.assign, or configuration lookups, while legitimate __proto__ properties are dropped. The global Object.prototype, unrelated objects, other requests, and other users are not modified, and downstream schema validation still runs. This issue is fixed in version 1.14.9.

Bludit CMS through 3.22.0 contains a mass assignment vulnerability that allows authenticated users with the Author role to modify privileged page fields reserved for administrators by injecting reserved parameters into a content save request. Attackers can submit reserved fields such as type and username through the Pages::edit() function in bl-kernel/pages.class.php, which iterates all fields declared in dbFields without per-field authorization, enabling an Author to convert pages to static site-wide navigation entries or transfer page ownership to arbitrary accounts.

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.

scim-patch is a library for applying SCIM patch operations. Prior to 0.9.2, navigate() reads inherited properties and assign() uses prototype-chain membership checks while resolving attacker-controlled SCIM PATCH paths. A path or one of the dotted value keys beginning with an inherited property such as toString can therefore traverse into a shared built-in function object and add attacker-controlled properties, causing process-global mutation that may affect application logic reading inherited-method properties. This issue is fixed in version 0.9.2.

Improperly Controlled Modification of Dynamically-Determined Object Attributes vulnerability in ash-project ash_oban allows a user whose input reaches the :args option of AshOban.build_trigger/3 to retarget an update or destroy trigger at another record, including across tenants. build_trigger/3 builds the trusted job arguments with atom keys (:primary_key, :tenant, :action_arguments) and merges the caller's :args underneath so the trusted values win on collision. Because Oban job arguments round-trip through JSON, the caller's keys arrive as strings, so Map.merge sees no collision and both keys survive. When the job is persisted the JSON object is de-duplicated keeping the last (string) key, and the worker reads the caller's value. The documentation describes :args as unable to affect the action, so an application that forwards user input into it for uniqueness scoping is exposed to authorization bypass and tenant isolation breaks. This issue affects ash_oban: from 0.2.5 before 0.8.14.

Spring Data REST does not preserve the persisted version (@Version) property of an aggregate root when handling an HTTP PUT against an immutable target type. Spring Data REST 5.1.0 Spring Data REST 5.0.0 - 5.0.6 Spring Data REST 4.5.0 - 4.5.12 Spring Data REST 4.0.0 - 4.4.15 Spring Data REST 3.7.20 and earlier

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.