| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| A vulnerability exists in the maintenance restore functionality of Analytics and Location Engine (ALE). Successful exploitation of this vulnerability could allow an authenticated remote attacker to gain unauthorized access to the file system with root privileges, potentially resulting in full system compromise. |
| Vulnerabilities in the Analytics and Location Engine web interface allows remote authenticated users to run arbitrary commands on the underlying host. A successful exploit could allow an attacker to execute arbitrary commands as root on the underlying operating system leading to complete system compromise. |
| A vulnerability in an administrative component of Analytics and Location Engine (ALE) is vulnerable to a man-in-the-middle (MitM) attack. Successful exploitation of this vulnerability could allow an unauthenticated remote attacker to execute arbitrary code with root privileges on the affected appliance. |
| Multiple vulnerabilities exist in the Analytics and Location Engine (ALE) that may allow for unauthorized access or denial of service. An unauthenticated remote attacker could exploit these vulnerabilities by sending specially crafted input or leveraging improper security configurations. Successful exploitation could result in a denial of service condition or unauthorized access to sensitive information. |
| A vulnerability exists in the Analytics and Location Engine (ALE) API that may allow for the disclosure of sensitive information. An unauthenticated remote attacker could exploit this vulnerability by providing specially crafted input to a specific API endpoint. Successful exploitation could result in the disclosure of sensitive user information, including password hashes, which could be used to facilitate further attacks. |
| Kaneo versions 2.3.12 before 2.12.2 contain a missing authorization vulnerability that allows authenticated workspace members with viewer or member roles to delete and modify tasks beyond their assigned permissions by exploiting the bulk task endpoint that omits workspace permission checks. Attackers can send requests to the PATCH /api/task/bulk endpoint, which verifies only workspace membership without calling the role-based permission check enforced on all other task endpoints, to permanently delete all tasks or modify task status, priority, assignee, due date, and labels in a workspace. |
| lwIP TCP/IP Stack MQTT is vulnerable to an out-of-bounds write, which may allow an attacker to gain full code execution on the device. |
| IBM Guardium Data Protection 12.2 could allow a remote unauthenticated attacker to execute arbitrary code on the system due to the deserialization of untrusted data. |
| NVIDIA NeMo contains a vulnerability in its dataset-loading workflow where a maliciously crafted model_config.yaml can inject unsafe parameters. A successful exploit of this vulnerability may lead to code execution, data tampering, denial of service, and information disclosure. |
| A vulnerability in the Eclipse Vert.x toolkit causes a memory leak in TCP servers configured with TLS and SNI support. When processing an unknown SNI server name assigned the default certificate instead of a mapped certificate, the SSL context is erroneously cached in the server name map, leading to memory exhaustion. This flaw allows attackers to send TLS client hello messages with fake server names, triggering a JVM out-of-memory error. |
| A vulnerability in the Eclipse Vert.x toolkit results in a memory leak due to using Netty FastThreadLocal data structures. Specifically, when the Vert.x HTTP client establishes connections to different hosts, triggering the memory leak. The leak can be accelerated with intimate runtime knowledge, allowing an attacker to exploit this vulnerability. For instance, a server accepting arbitrary internet addresses could serve as an attack vector by connecting to these addresses, thereby accelerating the memory leak. |
| source-map-js through 1.2.1 fails to validate the per-section offset line value in indexed source maps, allowing attackers to specify arbitrary numeric values. Attackers can supply extremely large offset line values that cause synchronous event loop blocking for extended periods, preventing the service from handling other requests. |
| A flaw was found in Red Hat Ansible Automation Platform's automation-controller. The
Project SCM branch and SCM refspec fields are accepted without rejecting values that begin
with a dash and are passed to the git module during project synchronization, where they
reach a `git checkout`/`git fetch` command line as bare arguments with no end-of-options
separator. An authenticated user permitted to create or edit a project can set the SCM
branch to a git option such as `--pathspec-from-file=<path>`, causing git to read an
arbitrary file on the synchronization host and reflect its contents back through the
project-update output. Because project synchronization runs on the control-plane host on
default OpenShift Operator deployments, an attacker can read the control-plane Kubernetes
ServiceAccount token, the Controller SECRET_KEY, and the database credentials, leading to
full compromise of the Automation Platform and its Kubernetes namespace. System
administrator privileges are not required and the impact crosses tenants. |
| A flaw was found in Red Hat Ansible Automation Platform's automation-controller.
The execute-permission check on a workflow job template node's unified job
template is skipped when the node's currently stored unified job template is
empty: the check inspects only the existing value, not the incoming one, and a
node can be created without a unified job template. An authenticated user who
holds admin permission on a single workflow job template can create an empty node
and then patch it to reference any job template, project, inventory source,
system job, or workflow on the platform -- including ones in other organizations
that they cannot otherwise read or launch. Running their own workflow then
executes the victim template with the victim's attached credentials, inventory
and project, resulting in cross-organization privilege escalation to arbitrary
automation execution. The patch response also discloses the victim template's
name and description. |
| A flaw was found in Red Hat Ansible Automation Platform's automation-
controller. When attaching an instance group to a schedule or a workflow job
template node through the dedicated API relationship endpoint, the controller
verifies only that the requesting user can read (view) the instance group,
rather than that they hold use permission on it, unlike every other instance
group assignment in the product. An authenticated user with read-only
visibility of an instance group -- for example a system auditor -- can attach a
use-restricted instance group, including the control plane group or another
tenant's container group, to a schedule or workflow node they control. Their
playbook then executes on the control plane node or within another tenant's
execution environment, leading to privilege escalation and, in the control
plane case, full compromise of the platform. |
| A flaw was found in Red Hat Ansible Automation Platform's automation-
controller. When attaching a Galaxy or Automation Hub credential to an
organization through the galaxy_credentials relationship endpoint, the
controller verifies only that the requesting user can read the credential,
rather than that they hold use permission on it, unlike other credential
consumption in the product. An authenticated user who administers one
organization and has read-only visibility of a credential in another
organization -- for example a platform auditor -- can bind that foreign
credential to their own organization. On the next project synchronization the
controller decrypts the credential server-side and uses its token to
authenticate to the credential owner's Automation Hub, allowing cross-tenant use
of another organization's secret. |
| A flaw was found in Red Hat Ansible Automation Platform's automation-controller. When a
custom credential type is created or updated, the injector configuration is validated by
rendering each attacker-supplied Jinja2 template synchronously inside the web request
worker, with no limit on iteration count, output size, or execution time. An
authenticated superuser can submit a credential type whose injector contains deeply
nested loops or large string operations, consuming CPU and wall-clock time in the web
worker until it is killed by the request timeout; issuing enough concurrent requests
places all web workers into a kill-and-respawn loop, making the Controller API and UI
unavailable for the duration of the attack. Additionally, certain template constructs
raise exception types that the validator does not handle, resulting in an unhandled
server error (HTTP 500) instead of a clean validation error. The rendering sandbox
prevents code execution, so there is no confidentiality or integrity impact. |
| A flaw was found in Red Hat Ansible Automation Platform's automation-
controller. When attaching a source inventory to a constructed inventory through
the input_inventories relationship endpoint, the controller verifies only that
the requesting user can read the source inventory, rather than that they hold use
permission on it, unlike instance group attachment on the same access class. An
authenticated user who can administer a constructed inventory and has read-only
visibility of an inventory in another organization -- for example an
organization or system auditor -- can attach that foreign inventory as an input.
On synchronization the controller clones every host and host variable, including
secrets, into the attacker's inventory, and because the attacker administers the
constructed inventory they can run ad hoc commands against the cloned hosts,
resulting in cross-tenant disclosure of inventory data and secrets and code
execution against another tenant's managed hosts. |
| A flaw was found in Red Hat Ansible Automation Platform's automation-controller. A user
with the delegated Instance Group Admin role on a container group can set a free-form
pod specification override that is deep-merged, without filtering, into every job pod
launched on that group. The only hardening applied is forcing
automountServiceAccountToken to false, which does not remove an explicitly declared
projected serviceAccountToken volume or secret volume mounts. A non-superuser can
therefore cause the kubelet to mint a ServiceAccount token for the control-plane
automation-controller service account into the job container and mount arbitrary
secrets from the control-plane namespace, obtaining the control-plane service-account
identity on the Kubernetes API and cleartext control-plane secrets (including the
platform database password and Django SECRET_KEY), leading to full platform data
compromise. |
| A flaw was found in Red Hat Ansible Automation Platform's automation-
controller. The bulk job launch endpoint builds workflow job nodes from client
input using a serializer that leaves the node's job reference -- a field normally
set by the workflow task manager after it spawns a child job -- writable and does
not include it in the permission validation performed for the other node fields.
An authenticated user with permission to execute a single job template can submit
a bulk job launch whose node references the identifier of any unified job in any
organization, including jobs they cannot access. The node then exposes that job's
metadata, and cancelling the attacker's workflow cancels the referenced job
through the workflow cancellation cascade, without any per-job authorization
check. Repeated, this allows a low-privileged user to cancel running jobs,
project and inventory syncs, ad hoc commands, and system jobs across all
organizations, denying automation service platform-wide. |
