Export limit exceeded: 397058 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (397058 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-59845 | 2 Libssh, Redhat | 4 Libssh, Enterprise Linux, Hardened Images and 1 more | 2026-09-01 | 5.3 Medium |
| A flaw was found in libssh. When ProxyCommand is used, an unchecked fork() failure can be stored as process ID -1; during cleanup, signals may then be sent across the caller's accessible process tree, leading to local denial of service. | ||||
| CVE-2026-59844 | 2 Libssh, Redhat | 4 Libssh, Enterprise Linux, Hardened Images and 1 more | 2026-09-01 | 6.5 Medium |
| A flaw was found in libssh. A remote authenticated client can issue SSH_FXP_READ requests with an arbitrarily large length, causing a libssh SFTP server to allocate excessive memory and potentially exhaust it through repeated requests. | ||||
| CVE-2026-59843 | 2 Libssh, Redhat | 4 Libssh, Enterprise Linux, Hardened Images and 1 more | 2026-09-01 | 6.5 Medium |
| A flaw was found in libssh. A remote authenticated peer can advertise a zero maximum packet size in SSH_MSG_CHANNEL_OPEN, causing later channel writes to loop indefinitely and consume CPU, leading to denial of service. | ||||
| CVE-2025-71407 | 1 Nokogiri | 1 Nokogiri | 2026-09-01 | 8.1 High |
| This CVE ID has been rejected as a duplicate. | ||||
| CVE-2025-71406 | 1 Nokogiri | 1 Nokogiri | 2026-09-01 | 7.8 High |
| This CVE ID has been rejected as a duplicate. | ||||
| CVE-2025-71346 | 1 Sparklemotion | 1 Nokogiri | 2026-09-01 | 2.9 Low |
| This CVE ID has been rejected as a duplicate. | ||||
| CVE-2024-58378 | 2 Nokogiri, Sparklemotion | 2 Nokogiri, Nokogiri | 2026-09-01 | 7.5 High |
| This CVE ID has been rejected as a duplicate. | ||||
| CVE-2024-58377 | 1 Nokogiri | 1 Nokogiri | 2026-09-01 | 5.5 Medium |
| This CVE ID has been rejected as a duplicate. | ||||
| CVE-2026-82749 | 1 Ash-project | 1 Ash | 2026-09-01 | N/A |
| Incorrect Authorization vulnerability in ash-project ash widens a relationship's parent(...) scoping filter to match unintended records when the referenced parent field cannot be resolved. Loading a relationship whose filter references parent(...) resolves that expression against the parent record. resolve_parent_in_filter/3 (lib/ash/actions/read/relationships.ex) resolved an unresolvable parent reference (for example when the referenced field was not selected on the source query) to nil rather than failing. A scoping predicate such as org_id == parent(org_id) then becomes an IS NULL match, and a guard like is_nil(parent(org_id)) or org_id == parent(org_id) activates its unrestricted branch, so the relationship returns records the scope was meant to exclude. The fix fails the read with an error when a parent(...) reference cannot be resolved, instead of defaulting to nil. This issue affects ash: from 3.13.2 before 3.32.2. | ||||
| CVE-2026-82746 | 1 Ash-project | 1 Ash | 2026-09-01 | N/A |
| Missing Authorization vulnerability in ash-project ash allows an actor to update records forbidden by resource policies through the atomic path of Ash.update_many/4. Ash.update_many/4 runs as a single atomic statement (a data-layer update_many, for example a SQL MERGE) whenever an atomic strategy is used and the data layer supports it. Ash.Actions.Update.UpdateMany (lib/ash/actions/update/update_many.ex) took that path even under authorize?: true without applying the resource's policies, so the statement updated every row matched by primary key regardless of the policy filter that authorization would impose. An actor could therefore update records the policies forbid, such as rows belonging to another actor or tenant. The fix restricts the atomic path to data layers supporting changeset filters when authorizing, authorizes each changeset, and merges the resulting policy filter into each changeset so the statement only touches authorized rows. This issue affects ash: from 3.29.0 before 3.32.2. | ||||
| CVE-2026-82745 | 1 Ash-project | 1 Ash | 2026-09-01 | N/A |
| Improper Access Control vulnerability in ash-project ash lets a create action overwrite an existing record when the ETS or Mnesia data layer is used, because neither enforced primary-key uniqueness on insert. Unlike a SQL data layer, whose unique primary-key constraint rejects a duplicate, the ETS and Mnesia data layers implemented create as a keyed insert that replaces any existing entry with the same primary key (lib/ash/data_layer/ets/ets.ex, lib/ash/data_layer/mnesia/mnesia.ex). An actor who can set the primary key on a create (for example a user-supplied string or integer key) can submit a create whose key matches an existing record and silently overwrite it, destroying and replacing another entity's data without going through the update action or its policies. The fix rejects a create whose primary key already exists with an already-taken error, and only allows duplicates for keyless resources. This issue affects ash: from 0.4.0 before 3.32.2. | ||||
| CVE-2026-82741 | 1 Ash-project | 1 Ash | 2026-09-01 | N/A |
| Improper Validation of Specified Type of Input vulnerability in ash-project ash lets an attacker confuse the stored type tag of an Ash.Type.Union value that uses storage: :map_with_tag, bypassing that member's validation and any tag-based authorization. For a union with storage: :map_with_tag, each member is identified in storage by a configured tag and tag_value. Ash.Type.Union.dump_to_native/2 (lib/ash/type/union.ex) did not force the configured tag when writing the value, so a tag carried in the submitted value was persisted verbatim. An attacker can therefore store a value whose data belongs to one member but whose tag names a different member. On read the value is re-selected by its tag and treated as the incompatible member (a type confusion), bypassing the real member's constraints and any logic or policy that branches on the union tag. The fix drops any incoming tag and forces the configured tag value on dump. This issue affects ash: from 2.14.18 before 3.32.2. | ||||
| CVE-2026-82734 | 1 Ash-project | 1 Ash | 2026-09-01 | N/A |
| Improper Validation of Specified Quantity in Input vulnerability in ash-project ash allows an attacker to submit a non-finite decimal value that bypasses numeric bounds constraints or fails later operations on the value. Ash.Type.Decimal cast input through Ecto's decimal cast in cast_input/2 and cast_stored/2 (lib/ash/type/decimal.ex) without checking that the resulting value is finite. Elixir's Decimal represents Infinity and NaN as valid structs, so a value such as "Infinity" or "NaN" passed casting and was persisted. Because NaN compares as false against every bound, min and max constraints do not reject it, and the stored special value later raises when used in Decimal arithmetic or is refused by the data layer, failing subsequent requests. The fix rejects any non-finite Decimal during casting. This issue affects ash: from 1.28.0 before 3.32.2. | ||||
| CVE-2026-82733 | 1 Ash-project | 1 Ash Typescript | 2026-09-01 | N/A |
| Generation of Error Message Containing Sensitive Information vulnerability in ash-project ash_typescript allows an unauthenticated attacker to read internal application data from an HTTP 500 response body. When a typed-controller route handler returns anything other than a %Plug.Conn{}, dispatch/3 in lib/ash_typescript/typed_controller/request_handler.ex passes the value to unexpected_return/2, which interpolates inspect(value, limit: 50) directly into the response message. The limit option bounds elements per collection rather than the term as a whole, so a handler falling through with a term such as {:error, %User{}} or a changeset serialises its full field set, including hashed passwords, tokens, and tenant identifiers, into the JSON error returned to the caller. This contradicts the module's own posture elsewhere: the rescue clause gates Exception.message/1 behind AshTypescript.typed_controller_show_raised_errors?/0 and otherwise returns a generic message, while this path is ungated and always echoes. This issue affects ash_typescript: from 0.15.0 before 0.18.0. | ||||
| CVE-2026-82732 | 1 Ash-project | 1 Ash Typescript | 2026-09-01 | N/A |
| Improper Input Validation vulnerability in ash-project ash_typescript allows a remote attacker to submit argument values outside a declared allowlist or bound on typed-controller routes. AshTypescript.TypedController.RequestHandler in lib/ash_typescript/typed_controller/request_handler.ex calls Ash.Type.cast_input/3 and treats an {:ok, cast} result as fully validated. In Ash these are separate steps: cast_input/3 only coerces the term, while every constraint declared on the argument is applied by Ash.Type.apply_constraints/3, which this path never calls. Constraints such as one_of, max_length, min and max, and match are therefore inert, so a value outside a declared allowlist is accepted and passed to the route handler. Codegen renders the same constraints into the generated TypeScript types, so an allowlist appears enforced to a TypeScript caller while any other HTTP client ignores it. Empty-string to nil normalization also lives in apply_constraints, so the allow_nil?: false check accepts "" for a required argument. Where a constraint gates a role, a status, or a sort direction, this becomes a privilege or state-machine bypass. This issue affects ash_typescript: from 0.15.0 before 0.18.0. | ||||
| CVE-2026-82731 | 1 Ash-project | 1 Ash Typescript | 2026-09-01 | N/A |
| URL Redirection to Untrusted Site ('Open Redirect') vulnerability in ash-project ash_typescript allows an attacker who controls a path-parameter value to redirect a generated client's request, and the credentials attached to it, to an unintended route or an external origin. The URL builders in lib/ash_typescript/typed_controller/codegen/route_renderer.ex replace each :param placeholder with a bare template interpolation and never call encodeURIComponent, so the value reaches executeTypedControllerRequest raw. A value containing ../ is normalised away by the fetch URL resolver and reaches a different route, while ? or # truncates the path and can smuggle or override query parameters. For a route whose path begins with a parameter, a value such as /evil.example.com/x yields the protocol-relative URL //evil.example.com/x, sending the request and the credentials from TypedControllerConfig to an attacker-controlled host. Nothing constrains the value at runtime: get_path_param_type/2 emits only a TypeScript type, which is erased. The query-string path is unaffected, since URLSearchParams.set encodes its own values. This issue affects ash_typescript: from 0.15.0 before 0.18.0. | ||||
| CVE-2026-82730 | 1 Ash-project | 1 Ash Typescript | 2026-09-01 | N/A |
| Incorrect Authorization vulnerability in ash-project ash_typescript allows an unauthorized RPC caller to read attribute values that Ash field policies denied. When a field policy denies an attribute, Ash substitutes %Ash.ForbiddenField{}, which retains the real value in original_value because embedded resources must remain writable, and hides it from Inspect rather than removing it. AshTypescript.Rpc.ResultProcessor strips these markers to nil on its template-driven paths, but normalize_primitive/1 in lib/ash_typescript/rpc/result_processor.ex had no such clause, so a marker fell through to the generic struct branch which calls Map.from_struct/1 and serializes every key, original_value included. The denied value is returned to the caller inside the marker that represents its own denial. The simplest trigger is an action returning an embedded resource as a map, which routes through normalize_resource_struct/2 with an empty template. normalize_value_for_json/1 is a public, unguarded entry point to the same path. This issue affects ash_typescript: from 0.11.0 before 0.18.0. | ||||
| CVE-2026-82725 | 1 Ash-project | 1 Ash Phoenix | 2026-09-01 | N/A |
| Authorization Bypass Through User-Controlled Key vulnerability in ash-project ash_phoenix lets an attacker who controls filter form parameters filter across relationships the resource author marked non-public, turning the returned rows into a boolean oracle over private related data. AshPhoenix.FilterForm resolved every relationship hop in the user-supplied path with Ash.Resource.Info.related/2, which traverses private relationships, and only checked the terminal field for publicity. parse_path_and_field/2 also rewrote a field naming a relationship into an extra path segment, so field=some_private_rel was accepted too. Both path and field come straight from form params, and the resulting ref went to Ash.Query.do_filter/2 without the public-only enforcement of Ash.Filter.parse_input/2. The fix resolves each hop with Ash.Resource.Info.public_relationship/2, rejecting the first non-public hop, and requires the terminal field to be public. This issue affects ash_phoenix: from 0.6.0-rc.1 before 2.3.25. | ||||
| CVE-2026-82367 | 1 Ash-project | 1 Ash Graphql | 2026-09-01 | N/A |
| Exposure of Data Element to Wrong Session vulnerability in ash-project ash_graphql can deliver one subscription's resolved records to a different subscriber's topic. AshGraphql.Subscription.Batcher.do_send/5 reads the resolved batch from the process dictionary via Process.get(:batch_resolved) and then unconditionally deletes it. That is sound only inside a task the library owns. On the :backpressure_sync and :noproc fallbacks do_send/5 runs inline in the publishing caller's process, so if a resolver inside an outer do_send/5 triggers another synchronous Ash notification, the inner call finds the outer run's value still under :batch_resolved, adopts it as its own result, and publishes it to the inner topic, a different subscription document with a different actor and tenant. It then deletes the key, so the outer run publishes nothing. The key is not namespaced by run, so records cannot be told apart. The fix saves, clears, and restores :batch_resolved around each run. This issue affects ash_graphql: from 1.4.0 before 1.11.0. | ||||
| CVE-2026-81322 | 1 Ash-project | 1 Ash Cloak | 2026-09-01 | N/A |
| Exposure of Sensitive Information to an Unauthorized Actor vulnerability in ash-project ash_cloak allows anyone with access to logs, error trackers, or crash reports, or anyone who can trigger a validation error, to recover the plaintext of a field the library encrypts. AshCloak.Transformers.SetUpEncryption removes each cloaked attribute from the action's accept list and adds an action argument that carries the plaintext into the encryption change. That argument is built with sensitive?: attr.sensitive?, inheriting the flag from the source attribute, so a cloaked attribute declared without sensitive? true produces a non-sensitive argument. It is the only place the cleartext value lives, and the one place Ash will not redact: it appears verbatim in inspect(changeset), Ash.Error.Invalid and validation error messages, telemetry, :sys dumps, and error-tracker payloads. The generated encrypted attribute and decrypt calculation are already hardcoded sensitive. This issue affects ash_cloak: from 0.1.0 before 0.4.0. | ||||