Export limit exceeded: 14986 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Export limit exceeded: 385751 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (385751 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2024-58377 | 1 Nokogiri | 1 Nokogiri | 2026-09-01 | N/A |
| This CVE ID has been rejected as a duplicate. | ||||
| CVE-2024-14047 | 2026-09-01 | 7.2 High | ||
| A local vulnerability in the Winlogbeat Windows installer caused runtime files to be placed in a directory writable by unprivileged users. A low-privileged attacker with existing access to the system could pre-position malicious filesystem links, causing a subsequent elevated Winlogbeat operation to write to or delete arbitrary files. Successful exploitation could result in a denial of service. | ||||
| CVE-2026-84288 | 1 Nousresearch | 1 Hermes-agent | 2026-09-01 | 4.3 Medium |
| A vulnerability has been found in NousResearch hermes-agent up to 0.18.2. This affects the function HermesACPAgent.prompt of the file acp_adapter/session.py of the component ACP Prompt Workflow. Such manipulation leads to denial of service. The attack may be performed from remote. The exploit has been disclosed to the public and may be used. The vendor was contacted early about this disclosure but did not respond in any way. | ||||
| 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-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-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-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-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-82747 | 1 Ash-project | 1 Ash | 2026-09-01 | N/A |
| Incorrect Authorization vulnerability in ash-project ash returns records that a runtime read policy denies to any actor. When a resource has an access_type :runtime read policy (a check evaluated per record rather than compiled to a filter), Ash.Policy.Authorizer decides each record in check_result/1 (lib/ash/policy/authorizer/authorizer.ex) by discarding impossible policy scenarios and inspecting what remains. When every scenario for a record was impossible, meaning no policy can authorize it and it must be forbidden, the empty-scenario branch instead kept the record ({[record | data], authorizer, any_forbidden?}) and returned it as authorized. As a result, records the runtime read policy denies are returned to any actor. The fix forbids a record whose scenarios are all impossible. This issue affects ash: from 3.4.44 before 3.32.2. | ||||
| CVE-2026-82748 | 1 Ash-project | 1 Ash | 2026-09-01 | N/A |
| Incorrect Authorization vulnerability in ash-project ash authorizes an aggregate under one read action while computing it under another, so an aggregate can run with policies that do not match the action it was authorized against. Ash.Actions.Aggregate groups aggregates by their {authorize?, read_action} and authorizes each group under that read action, but when building the data query it selected the action as opts[:action] || read_action || <primary read> (lib/ash/actions/aggregate.ex). When a caller passed an :action option, the aggregate query ran under that action while authorization had been computed for the group's own read_action. If the run action's read policies are more permissive than the authorized one, the aggregate (a count or sum) is computed over records the authorized action's policies would have excluded, disclosing information about data the actor cannot read. The fix runs the aggregate under the same read_action it is authorized against. This issue affects ash: from 3.5.13 before 3.32.2. | ||||
| CVE-2026-78699 | 1 Ash-project | 1 Ash Postgres | 2026-09-01 | N/A |
| Unchecked Return Value vulnerability in ash-project ash_postgres allows a user who can drive a tenant rename to a name that collides with an existing tenant's schema to have their tenant record repointed at that other tenant's live schema, gaining access to its data. AshPostgres.MultiTenancy.rename_tenant/3 issues the ALTER SCHEMA ... RENAME TO ... with the non-raising Ecto.Adapters.SQL.query/2, discards its {:ok, _} | {:error, _} result, and unconditionally returns :ok. PostgreSQL rejects the rename when the target schema already exists (and on insufficient privilege or lock timeout), but that failure never reaches the caller. The calling manage_tenant update action therefore sees success and commits the tenant row with the new name, which is the schema of a different existing tenant, so subsequent reads and writes for that tenant run against the other tenant's data. This issue affects ash_postgres: from 0.25.0 before 2.13.0. | ||||
| 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-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-71380 | 1 Erlang | 3 Erlang/otp, Erlang\/otp, Otp | 2026-09-01 | N/A |
| Missing Release of Resource after Effective Lifetime vulnerability in Erlang/OTP inets httpd allows an unauthenticated remote attacker to cause denial of service by sending valid request headers with a large Content-Length and then stalling before the body is complete. httpd_request_handler:handle_info/2 cancels the request timeout as soon as a parse step succeeds, which includes the headers, and the clause that handles a decoder asking for more data re-arms the socket with {active, once} without setting any further timer. httpd_request:whole_body/2 returns such a continuation whenever the bytes received are fewer than the announced Content-Length, so a well-formed request that stops mid-body leaves the worker waiting indefinitely. The periodic byte-rate check that would reclaim it is armed only when minimum_bytes_per_second is configured, which it is not by default. Repeating this across connections occupies every worker permitted by max_clients and denies service to legitimate clients at negligible bandwidth cost. This issue affects OTP from OTP 17.0 before OTP 27.3.4.17, from OTP 28.0 before OTP 28.5.0.6, and from OTP 29.0 before OTP 29.0.6, corresponding to inets from 5.10 before 9.3.2.7, from 9.4 before 9.6.2.3, and from 9.7 before 9.7.2. Whether OTP before OTP 17.0, corresponding to inets before 5.10, is affected is unknown. | ||||
| CVE-2026-74837 | 1 Ash-project | 1 Ash Typescript | 2026-09-01 | N/A |
| Allocation of Resources Without Limits or Throttling vulnerability in ash-project ash_typescript allows an unauthenticated attacker to exhaust the BEAM atom table and abort the node via client-supplied RPC field names. AshTypescript.FieldFormatter.convert_to_field_atom/2 in lib/ash_typescript/field_formatter.ex converts a client-supplied field name to an atom with String.to_atom/1 when no matching atom already exists. It delegates first to parse_input_field/2, which resolves the name with String.to_existing_atom/1 and falls back to returning the plain string; convert_to_field_atom/2 then mints an atom from that string rather than treating the name as unknown. RPC field selection reaches it for every requested field name through AshTypescript.Rpc.FieldProcessing.FieldSelector, which resolves each name before checking that the field exists, with no allowlist, length bound, or rate limit. Atoms are never garbage collected, so each distinct name mints a permanent one and the VM aborts once the atom table limit is reached. A field name over 255 characters additionally raises an uncaught SystemLimitError. This issue affects ash_typescript: from 0.1.0 before 0.18.0. | ||||
| CVE-2026-73270 | 1 Erlang | 2 Erlang\/otp, Otp | 2026-09-01 | N/A |
| Improper Handling of Case Sensitivity vulnerability in Erlang/OTP inets httpd allows a remote unauthenticated attacker to read files inside a mod_auth protected directory by requesting them with different casing, on deployments whose filesystem is case-insensitive. mod_auth:secret_path/3 decides whether a resolved filesystem path lies inside a protected directory block by running the configured directory path through re:run/3 without the caseless option. A request for /secret/file against a directory configured as /Secret therefore does not match, so the request is treated as unprotected and no authentication challenge is issued, while the filesystem resolves the differently cased path to the same file and mod_get serves it. Deployments on case-sensitive filesystems are unaffected, because there the filesystem itself rejects the mismatched casing. This issue affects OTP from OTP 17.0 before OTP 27.3.4.17, from OTP 28.0 before OTP 28.5.0.6, and from OTP 29.0 before OTP 29.0.6, corresponding to inets from 5.10 before 9.3.2.7, from 9.4 before 9.6.2.3, and from 9.7 before 9.7.2. Whether OTP before OTP 17.0, corresponding to inets before 5.10, is affected is unknown. | ||||
| CVE-2026-74835 | 1 Erlang | 3 Erlang/otp, Erlang\/otp, Otp | 2026-09-01 | N/A |
| The inets application HTTP server httpd fails to enforce a configured body-size limit on chunked request. This issue affects OTP from OTP 17.0 before OTP 27.3.4.17, from OTP 28.0 before OTP 28.5.0.6, and from OTP 29.0 before OTP 29.0.6, corresponding to inets from 5.10 before 9.3.2.7, from 9.4 before 9.6.2.3, and from 9.7 before 9.7.2. Whether OTP before OTP 17.0, corresponding to inets before 5.10, is affected is unknown. | ||||
| CVE-2026-66357 | 1 Erlang | 3 Erlang/otp, Erlang\/otp, Otp | 2026-09-01 | N/A |
| httpd has never implemented obs-fold (RFC 2616 §2.2 / RFC 7230 §3.2.4 header continuation lines). Every CRLF followed by a non-CRLF octet unconditionally starts a new header. This missing feature became a security concern as the understanding of HTTP request smuggling attacks evolved. This issue affects OTP from OTP 17.0 before OTP 27.3.4.17, from OTP 28.0 before OTP 28.5.0.6, and from OTP 29.0 before OTP 29.0.6, corresponding to inets from 5.10 before 9.3.2.7, from 9.4 before 9.6.2.3, and from 9.7 before 9.7.2. Whether OTP before OTP 17.0, corresponding to inets before 5.10, is affected is unknown. | ||||
| CVE-2026-70399 | 1 Erlang | 3 Erlang/otp, Erlang\/otp, Otp | 2026-09-01 | N/A |
| Allocation of Resources Without Limits or Throttling vulnerability in Erlang/OTP inets httpd allows an unauthenticated remote attacker to cause denial of service by opening and holding open a large number of connections. The max_clients option is documented to default to 150, and the inets hardening guide presents that limit as the first layer of denial-of-service defence, but a server that does not set it explicitly accepts an unlimited number of simultaneous connections. Establishing the connections is sufficient; no valid request and no authentication are required. The accept gate in httpd_manager:handle_new_connection/4 reads the option with httpd_util:lookup/2, which returns undefined when the key is absent, rather than the three-argument form carrying the 150 default that the neighbouring get_ustate/2 uses. Erlang term ordering places every integer before every atom, so the Count =< Max guard holds for any connection count and the server never returns {reject, busy}. Each accepted connection occupies a worker process and a socket for as long as it is held, driving the node towards process, memory and file descriptor exhaustion. Servers that set max_clients explicitly are unaffected, because a configured value is applied as intended. This issue affects OTP from OTP 17.0 before OTP 27.3.4.17, from OTP 28.0 before OTP 28.5.0.6, and from OTP 29.0 before OTP 29.0.6, corresponding to inets from 5.10 before 9.3.2.7, from 9.4 before 9.6.2.3, and from 9.7 before 9.7.2. | ||||
| CVE-2026-70409 | 1 Erlang | 2 Erlang/otp, Erlang\/otp | 2026-09-01 | 5.3 Medium |
| Improper Validation of Specified Quantity in Input vulnerability in Erlang/OTP eldap allows a malicious or compromised LDAP server to degrade availability by returning a referral URL whose port component is a very long run of digits. eldap:parse_port/2 passes the port substring straight to list_to_integer/1 with no length bound. The surrounding try ... catch only rejects a value that fails to parse, so a syntactically valid port of up to roughly 1.26 million digits converts successfully and costs the caller hundreds of milliseconds of arbitrary-precision arithmetic per referral. The conversion function itself is documented to accept integers of any size, so bounding the input is the caller's responsibility. Reaching the flaw requires the application to pass a server-supplied referral to eldap:parse_ldap_url/1, which eldap never calls itself: referral strings are returned to the caller unparsed. This issue affects OTP from OTP 17.0 before OTP 27.3.4.17, from OTP 28.0 before OTP 28.5.0.6, and from OTP 29.0 before OTP 29.0.6, corresponding to eldap from 1.0.3 before 1.2.14.2, from 1.2.15 before 1.2.16.1, and from 1.3 before 1.3.1. | ||||