| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Generation of Error Message Containing Sensitive Information vulnerability in ash-project ash discloses the stored value of a confirmed field to an actor who fails its confirmation check.
Ash.Resource.Validation.Confirm's atomic implementation (atomic/2 in lib/ash/resource/validation/confirm.ex) built the mismatch error with its value set to the field being confirmed. When the actor supplies only the confirmation argument and not the field itself, value resolves through atomic_ref/2 to the field's current stored value, so the mismatch error echoes that stored value back to the actor. Against a confirmation guarding a sensitive attribute, an actor can submit a deliberately wrong confirmation and read the real value from the returned error. The fix reports the actor-supplied confirmation in the error instead of the stored field value.
This issue affects ash: from 2.17.20 before 3.32.2. |
| An Apache-proxied Dogtag CA REST endpoint exposed by IdM (POST /ca/rest/certrequests) returns HTTP 500 with internal Java stack traces for unauthenticated malformed requests. The same unauthenticated error path emits large multi-line stack traces into the CA debug log, creating a log-amplification resource exhaustion vector (disk growth and I/O contention) without requiring authentication. |
| 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. |
| 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. |
| Generation of Error Message Containing Sensitive Information vulnerability in ash-project ash_ai discloses internal error text to chat users.
In AshAi.ToolLoop and AshAi.Tools, an exception raised while executing a tool was serialized verbatim with Exception.message/1 into the tool-result content. That content is appended to the conversation, emitted as a {:tool_result, ...} stream event, and sent back to the model, which typically relays it to the user. No filtering happened first, so anything raised inside a tool callback or lifecycle hook (database constraint messages, adapter errors, query fragments, policy or validation internals) was echoed as-is. A chat user who can steer tool arguments into a raising code path receives the raw internal text. The fix routes raised tool errors through the same safe formatter used for other tool errors.
This issue affects ash_ai: from 0.6.0 before 1.0.0. |
| Generation of Error Message Containing Sensitive Information vulnerability in ash-project ash_graphql allows a remote client to read internal field names that an application configured its error_handler to redact.
In AshGraphql.Errors, each error is passed to the configured error_handler and the returned map is merged with the pre-handler path via Map.put_new(handled, :path, path). Because put_new defers to the handler only when the handler itself set :path, a sanitizing handler that returns a fresh map or deletes :path has that decision reverted. The re-injected path comes from build_error_path/5, which falls back to raw internal Ash attribute and argument names when no field_names mapping is configured. A validation failure on a non-exposed or nested field therefore returns internal names in the GraphQL error path, defeating the application's redaction.
This issue affects ash_graphql: from 1.9.0 before 1.11.0. |
| Generation of Error Message Containing Sensitive Information vulnerability in ash-project ash_ai discloses provider request state and credentials in a user-facing validation error.
In AshAi.Changes.Vectorize, when the embedding provider call fails the change added a changeset error whose message inspected the raw error term (An error occurred while generating embeddings: #{inspect(error)}). A plain-string add_error produces an Ash.Error.Changes.InvalidChanges in the :invalid class, which AshJsonApi and AshGraphql render back to the caller. The embedding client's error term is not sanitized, so it can carry the request URL, the provider response body, and, for HTTP clients that keep the request in the error struct, the outbound Authorization header with the provider API key. Failures are attacker-reachable via oversized or malformed vectorized content. The fix logs the raw error and returns a generic message.
This issue affects ash_ai: from 0.1.0 before 1.0.0. |
| Generation of Error Message Containing Sensitive Information vulnerability in ash-project ash_phoenix writes the entire raw submitted param map into an exception message, so secrets submitted alongside a union form field leak into logs, crash reports and the dev error page.
When AshPhoenix.Form.Auto builds a union sub-form and the submitted _union_type does not match a configured type, both raise sites built the message with inspect(params, pretty: true), embedding the full untrusted param map, and also inspected the internal union constraints[:types]. Because the message is constructed by the library rather than Phoenix's parameter logger, config :phoenix, :filter_parameters never redacts it. An attacker controls both the trigger and the contents: submitting %{"_union_type" => "nope", "password" => "..."} puts the password verbatim in the raised message. The fix reports only the offending _union_type and the valid type names, dropping the param and constraints dumps.
This issue affects ash_phoenix: from 1.2.17 before 2.3.25. |
| rclone before v1.75.0 includes full Go stack traces in RC API error responses when panics occur. Attackers can trigger panics to leak internal file paths, module versions, goroutine states, and memory addresses. |
| A Spring WebFlux application that supports WebSocket connections may expose indirectly sensitive user information by including request headers in an exception reason.
Spring Framework 7.0.0 - 7.0.8
Spring Framework 6.2.0 - 6.2.19
Spring Framework 6.1.0 - 6.1.28
Spring Framework 6.0.0 - 6.0.30
Spring Framework 5.3.0 - 5.3.49
Spring Framework 5.2.25.RELEASE and earlier |
| HCL BigFix Quantum Risk Analyzer has a certain validation process that provides overly descriptive error messages when it encounters malformed input which can allow an attacker to conduct more efficient reconnaissance and fine-tune automated fuzzing tools to produce valid input. |
| In the Linux kernel, the following vulnerability has been resolved:
tracing/probes: Remove WARN_ON_ONCE from parse_btf_arg
Sashiko found that user can cause this WARN_ON_ONCE() easily
with adding a kprobe event based on a raw address with BTF
parameter.
Since this is not an unexpected condition, remove the
WARN_ON_ONCE(). |
| The web GUI of affected Murrelektronik Xelity switches logs MAC addresses from the devices MAC address table when an authenticated administrator uses the 'Copy learned MAC Addresses' function. Due to improper generation of error messages, an unauthenticated attacker with network access to the web interface can retrieve the logged MAC addresses via browser developer tools. |
| When the RabbitMQ management aliveness check fails, the configured admin password is embedded in cleartext in the thrown exception message.
Spring AMQP 4.1.0
Spring AMQP 4.0.0 - 4.0.4
Spring AMQP 3.2.0 - 3.2.12
Spring AMQP 2.4.18 and earlier |
| Combodo iTop is a web based IT service management tool. Prior to 3.2.3, there is sensitive information disclosure in the error messages. This issue has been fixed in version 3.2.3. |
| n8n versions before 1.123.69, 2.33.4, and 2.34.1 contain an information disclosure vulnerability in the GraphQL node. When a GraphQL request fails at the connection level, the node re-throws the underlying HTTP client error unchanged instead of wrapping it in n8n's standard error type. That error contains the live request's headers, including a decrypted credential secret, which the execution engine persists verbatim. Any authenticated user able to read the resulting execution can retrieve the decrypted credential secret from the stored run data. |
| openssl_encrypt versions before 1.4.0 contain an information disclosure vulnerability in the /ready endpoint that returns full database exception strings to unauthenticated callers. Attackers can trigger database errors to extract sensitive information including hostnames, IP addresses, connection parameters, and potentially credentials from exception messages. |
| Blueprint Studio is a VS Code-like file editor for Home Assistant configuration files. Prior to 2.5.2, Blueprint Studio backend API handlers in custom_components/blueprint_studio/backend/api.py returned raw exception strings to authenticated Home Assistant users. Some exception messages could contain internal filesystem paths or implementation details. The disclosed information could help an authenticated user fingerprint a Home Assistant installation and refine follow-up attacks. This issue is fixed in version 2.5.2. |
| HCL Connections is vulnerable to information disclosure which could allow a user to obtain sensitive information they are not entitled to, caused by improper handling of request data.they are not entitled to, caused by improper handling of request data. |
| When trying to load a non-video in an audio/video context the exact status code (200, 302, 404, 500, 412, 403, etc.) was disclosed via the MediaError Message. This level of information leakage is inconsistent with the standardized onerror/onsuccess disclosure and can lead to inferring login status to services or device discovery on a local network among other attacks. This vulnerability affects Firefox < 80 and Firefox for Android < 80. |
