Search

Search Results (389995 CVEs found)

CVE Vendors Products Updated CVSS v3.1
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-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-69664 2 Erlang, Redhat 4 Erlang/otp, Erlang\/otp, Otp and 1 more 2026-09-01 7.5 High
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 a request with a chunked body whose chunk-size line is not a hexadecimal number. The worker serving the connection is never released and no timeout reclaims it, so repeating the request across connections occupies every available worker and denies service to legitimate clients. No authentication is required and the default configuration is affected. The chunk-size line must arrive in a write separate from the headers. When the body accompanies the headers, httpd_request_handler:handle_body/3 calls http_chunk:decode/3 inside a try ... catch throw:Error, so the {error, {chunk_size, _}} thrown by http_chunk:decode_size/4 is answered with 400 Bad Request. When the chunk size arrives later, the decoder is resumed through a bare catch in httpd_request_handler:handle_info/2, which converts the throw into a return value rather than raising it; the resulting error tuple is then treated as the next decoder continuation, the socket is re-armed, and the worker waits for data that never comes. The request timeout has already been cancelled at the point the headers were accepted, and the periodic byte-rate check is only armed when minimum_bytes_per_second is configured, which it is not by default. This issue affects OTP from OTP 18.1.4 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 6.0.3 before 9.3.2.7, from 9.4 before 9.6.2.3, and from 9.7 before 9.7.2.
CVE-2026-66835 1 Erlang 2 Erlang/otp, Erlang\/otp 2026-09-01 N/A
Path Equivalence vulnerability in Erlang/OTP inets httpd allows a remote unauthenticated attacker to read files inside a mod_auth protected directory by prefixing the request path with an extra slash. httpd_request:validate_uri/1 normalises the request URI with uri_string:normalize/1, which performs RFC 3986 dot-segment removal but does not collapse empty path segments, so a doubled slash survives. mod_alias:real_name/3 concatenates the document root with that URI, and mod_auth:secret_path/3 then decides whether the result lies inside a protected directory block by running the configured directory path as an unanchored regular expression against it. The doubled slash breaks the contiguous substring the regex needs, so the request is treated as unprotected and no authentication challenge is issued, while mod_get opens the same path and the operating system collapses the doubled slash and returns the protected file. The same path mismatch also evades the per-path accounting in mod_security. 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-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-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-74835 1 Erlang 3 Erlang/otp, Erlang\/otp, Otp 2026-09-01 7.5 High
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-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-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-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-82744 1 Ash-project 1 Ash 2026-09-01 N/A
Not Failing Securely (Failing Open) vulnerability in ash-project ash skips an Ash.Reactor change when the guard controlling it raises, so a change meant to run does not. An Ash.Reactor change step can be gated by where validations that decide whether the change runs. Ash.Reactor.ChangeStep (lib/ash/reactor/steps/change_step.ex) evaluated those guards in apply_where_clauses/3, and apply_validation rescued any exception into {:error, error}. The reduce treated that identically to a guard whose condition was simply not met and bypassed the change. So when a guard raises (for example on attacker-influenced input), a change that enforces a security-relevant modification is skipped rather than failing the step. The fix distinguishes a raised exception (now {:raised, error}) and halts the step with an error, failing closed. This issue affects ash: from 3.0.0-rc.17 before 3.32.2.
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-75538 1 Erlang 3 Erlang/otp, Erlang\/otp, Otp 2026-09-01 N/A
An attacker that connects to an open Erlang TCP port that uses the inet driver with {packet,4} mode can use a signed overflow in an incorrect packet length calculation to overflow the receive buffer into the VM allocator area and beyond up to about 2 GB. This would easily trash the allocated block's allocator metadata footer, and the next block, if any, and most likely cause the BEAM VM to crash. Utilizing this with precision enough to achieve Remote Code Execution would be extremely unfeasible. 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 erts from 6.0 before 15.2.7.13, from 16.0 before 16.4.0.6, and from 17.0 before 17.0.6. Whether OTP before OTP 17.0, corresponding to erts before 6.0, 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-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.