Search vulnerabilities

Results 425,932

CVE-2026-59850

Libssh: libssh: use-after-free via data callbacks on closed channels

A flaw was found in libssh. If data packets are processed after a channel is closed, channel data callbacks can be invoked after the associated data has already been freed, leading to crashes or possible use-after-free conditions.

CVSS 3.1 · 4.3 Medium EPSS < 1% KEV · Not listed
Vendors
CVE-2026-59848

Libssh: libssh: denial of service via sftp responses with unknown request ids

A flaw was found in libssh. A malicious SFTP server can send responses for unknown request IDs that libssh clients keep queued indefinitely, causing unbounded memory growth and client-side denial of service.

CVSS 3.1 · 5.3 Medium EPSS < 1% KEV · Not listed
Vendors
CVE-2026-59846

Libssh: libssh: information disclosure via proxycommand %r username expansion

A flaw was found in libssh. A malicious username expanded through %r in ProxyCommand handling can inject shell metacharacters, exposing environment variables and causing unintended shell behavior.

CVSS 3.1 · 3.9 Low EPSS < 1% KEV · Not listed
Vendors
CVE-2026-59845

Libssh: libssh: denial of service via unchecked proxycommand fork() failure

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.

CVSS 3.1 · 5.3 Medium EPSS < 1% KEV · Not listed
Vendors
CVE-2026-59844

Libssh: libssh: denial of service via oversized sftp read length

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.

CVSS 3.1 · 6.5 Medium EPSS < 1% KEV · Not listed
Vendors
CVE-2026-59843

Libssh: libssh: denial of service via zero advertised channel packet size

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.

CVSS 3.1 · 6.5 Medium EPSS < 1% KEV · Not listed
Vendors
CVE-2025-71407

rubygem-nokogiri: Nokogiri before 1.18.3 Stack Buffer Overflow and Use-After-Free

This CVE ID has been rejected as a duplicate.

CVSS 3.1 · 8.1 High EPSS n/a KEV · Not listed
Vendors
Products
CVE-2025-71406

nokogiri: libxslt: Nokogiri: Memory corruption via crafted XSLT

This CVE ID has been rejected as a duplicate.

CVSS 3.1 · 7.8 High EPSS n/a KEV · Not listed
Vendors
Products
CVE-2025-71346

nokogiri: libxml2: Nokogiri: Heap buffer under-read in XML Schema validation

This CVE ID has been rejected as a duplicate.

CVSS 3.1 · 2.9 Low EPSS n/a KEV · Not listed
Vendors
Products
CVE-2024-58377

rubygem-nokogiri: Nokogiri before 1.16.5 libxml2 Dependency Update

This CVE ID has been rejected as a duplicate.

CVSS 3.1 · 5.5 Medium EPSS n/a KEV · Not listed
Vendors
Products
CVE-2026-78699

rename_tenant returns :ok on a failed rename, enabling cross-tenant access in AshPostgres

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.

CVSS 4.0 · 7.2 High EPSS < 1% KEV · Not listed
Vendors
Products
CVE-2026-77950

RPC error handler fails open in AshTypescript, disclosing unredacted errors

Generation of Error Message Containing Sensitive Information vulnerability in ash-project ash_typescript allows an unauthenticated attacker to receive unredacted internal error data by provoking an error shape the configured error handler does not match. apply_error_handler/3 in lib/ash_typescript/rpc/errors.ex is the only hook an application has for redacting or suppressing errors before they reach the client, with a nil return dropping the error entirely. Its rescue clause logs a warning and then returns the original, pre-handler error map. Error handlers are conventionally written as pattern-matching functions over expected error shapes, so an unmatched shape raises FunctionClauseError and the raw transformed error, including any secrets carried in vars, is emitted instead. An intent to suppress an error becomes an intent to publish it. The rescue catches exceptions only, so a handler that throws or exits still propagates. This issue affects ash_typescript: from 0.8.0 before 0.18.0.

CVSS 4.0 · 6.3 Medium EPSS < 1% KEV · Not listed
Vendors
Products
CVE-2026-74837

Unbounded atom creation from client-supplied RPC field names in AshTypescript field formatter

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.

CVSS 4.0 · 8.7 High EPSS < 1% KEV · Not listed
Vendors
Products
CVE-2026-82724

Broken access control in AshPhoenix SubdomainHook via a nil tenant in handle_subdomain

Incorrect Authorization vulnerability in ash-project ash_phoenix invokes the SubdomainHook authorization callback with a nil tenant, so tenant-scoped access checks never see the tenant they are meant to enforce. AshPhoenix.LiveView.SubdomainHook.on_mount/4 attached a handle_params hook to assign the tenant and then immediately called handle_subdomain in the same on_mount. The tenant assign is only written when LiveView later runs handle_params, strictly after on_mount returns, so handle_subdomain read an unset assign and ran as apply(m, f, [socket, nil | a]). A consumer gate that halts when the user does not belong to the tenant instead evaluated nil, either crashing or taking a permissive branch, and it was never re-run once the real subdomain was assigned or on later navigations. The fix runs handle_subdomain inside the handle_params hook with the real tenant on every navigation. This issue affects ash_phoenix: from 2.1.26 before 2.3.25.

CVSS 4.0 · 7.6 High EPSS < 1% KEV · Not listed
Vendors
Products
CVE-2026-75758

Unbounded recursion between Inspect.List charlist rendering and List.to_string/1 error path in Elixir

Uncontrolled Recursion vulnerability in the Elixir standard library allows an attacker who controls a list passed to inspect/1, List.to_string/1, or List.to_charlist/1 to exhaust a BEAM node's memory. Inspect.List's charlist branch in lib/elixir/lib/inspect.ex classifies a list as a charlist using List.ascii_printable?/2, which examines only the first :printable_limit (4096 by default) elements, and then calls IO.chardata_to_string/1 on the whole term. A list whose printable prefix exceeds that limit but which contains a later element that is not a code point (an atom, an out-of-range integer, or an improper tail) is therefore mis-classified, and the conversion raises ArgumentError. That conversion runs inside List.to_string/1, whose rescue clause builds its message by interpolating inspect(list), which re-enters the same branch and raises again. The nested inspection is an argument to raise, so the recursion is not in tail position and every level is retained: the process stack grows monotonically while each cycle re-walks the list, until the process is killed by max_heap_size or, by default, the node runs out of memory. List.to_charlist/1 has the same rescue shape. Below the printable limit the inner inspect/1 sees the invalid element within its counter and renders the list in ordinary bracket form, so a single ArgumentError is raised and no recursion occurs. This issue affects elixir: from 1.15.0-rc.0 before 1.18.5, from 1.19.0-rc.0 before 1.19.6, and from 1.20.0-rc.0 before 1.20.4.

CVSS 4.0 · 5.9 Medium EPSS < 1% KEV · Not listed
Vendors
Products
CVE-2026-82725

AshPhoenix FilterForm allows filtering across non-public relationships, disclosing private related data

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.

CVSS 4.0 · 2.3 Low EPSS < 1% KEV · Not listed
Vendors
Products
CVE-2026-82749

Ash relationship parent(...) filter degrades to an IS NULL match when the parent field is unresolved, leaking scoped records

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.

CVSS 4.0 · 5.9 Medium EPSS < 1% KEV · Not listed
Vendors
Products
Ash
CVE-2026-82748

Ash.Actions.Aggregate authorizes an aggregate under one action but computes it under another

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.

CVSS 4.0 · 2.1 Low EPSS < 1% KEV · Not listed
Vendors
Products
Ash
CVE-2026-82747

Ash.Policy.Authorizer returns records denied by a runtime read policy to any actor

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.

CVSS 4.0 · 5.9 Medium EPSS < 1% KEV · Not listed
Vendors
Products
Ash