Red Hat Ansible Automation Platform 2
Monthly
Jinja2 template injection in Ansible Operator Plugins (CWE-1336) lets an authenticated Kubernetes user who can create or modify a custom resource reconciled by an affected Ansible-based operator execute embedded Jinja2 expressions inside the operator pod, achieving remote code execution and escalating to the operator's service account. Because these operators typically hold cluster-wide RBAC, successful exploitation crosses a privilege boundary (CVSS 3.1 base 8.5, AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H), affecting components of Red Hat Ansible Automation Platform 2, Red Hat Advanced Cluster Management for Kubernetes 2, the Migration Toolkit for Applications/Containers/Virtualization, OpenShift Service Mesh 3 and related Red Hat OpenShift and OpenStack streams. No public exploit code and no confirmed active exploitation (CISA KEV) were identified at time of analysis; the high attack complexity reflects the prerequisite that the targeted operator must pass attacker-controllable CR spec values into Jinja2 templating without sanitization. This is a genuinely high-priority flaw rather than a CVSS-inflated one, but with an important authentication caveat: purely anonymous or read-only users cannot trigger it.
Symlink-following file overwrite on the Ansible control node is possible in ansible-core when a user runs `ansible-galaxy collection install` against a crafted collection tarball, because the archive extractor validates member paths with lexical normalization (os.path.abspath) instead of resolving symlinks (os.path.realpath) and performs no containment check on symlink-typed directory members before creating them, letting chained symlink entries redirect a subsequent file member outside the destination directory. The flaw (CWE-59, CVSS 8.8, vector AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H) is a bypass of the fix for CVE-2020-10691 and requires the victim to actively install the malicious collection, so an attacker can write arbitrary files with the privileges of the ansible-galaxy user and potentially achieve code execution on the control node. No public exploit has been identified at time of analysis and the CVE is not listed in CISA KEV; affected deployments include ansible-core 2.x as shipped in Red Hat Ansible Automation Platform 2 and numerous other Red Hat products, and no patched version is identified in the supplied intelligence, which currently cites only the Red Hat CVE page and Bugzilla 2531646.
Path traversal in the pulpcore content upload API allows an authenticated user holding only low-privilege file-repository permissions to read arbitrary files accessible to the Pulp server process by submitting a crafted 'file:' URL through the 'file_url' parameter, which is dispatched to the file downloader despite an intended scheme check. Baseline impact is confidentiality loss on the Pulp host; in deployments that include Pulp Container the same flaw escalates to theft of the container registry token signing private key, enabling forged bearer tokens and unauthorized access to every private container repository in the registry. Downstream products embedding pulpcore are affected, including Red Hat Satellite 6, Red Hat Ansible Automation Platform 2, and Red Hat Update Infrastructure 4/5. There is no public exploit identified at time of analysis, and EPSS data was not provided; Red Hat tracks the issue under advisory https://access.redhat.com/security/cve/CVE-2026-90959.
Command injection in the automation controller's external logging (rsyslog) configuration of Red Hat Ansible Automation Platform 2 allows a superuser to achieve arbitrary command execution inside the control-plane rsyslog component, exposing the controller SECRET_KEY and database credentials and enabling decryption of all stored credentials. Exploitation requires authenticated superuser privileges (CVSS 3.1 7.2, PR:H, no user interaction) and only takes effect when external logging is in use, so the malicious RainerScript configuration is actually generated and loaded. No public exploit code was identified and there is no CISA KEV listing indicating active exploitation, meaning real-world risk is strongly gated by the elevated privilege requirement even though the post-exploitation impact is a full control-plane compromise.
Missing authorization checks in the Red Hat Ansible Automation Platform 2 automation-controller allow an authenticated organization workflow-admin - a delegated, non-superuser role - to escalate into the control plane by copying a WorkflowJobTemplate and then launching jobs pinned to instance groups they hold no use_role on. The deep-copy permission sanitizer re-validates only the inventory, unified_job_template, and credentials of each cloned node, silently carrying over instance_groups, execution_environment, and labels, so the copier becomes administrator of a workflow that executes attacker-influenced automation in the control-plane execution context (CVSS 9.9, scope changed, high confidentiality, integrity, and availability impact). Exploitation is confirmed to require only a normal multi-tenant deployment plus workflow-admin rights; no public exploit code has been identified at time of analysis and there is no CISA KEV entry, and no vendor-released patch version was confirmed in the available intelligence.
Authenticated but low-privileged users of Red Hat Ansible Automation Platform 2 can bypass the automation-controller's sanitize_jinja() input-validation guard and have ansible-core evaluate attacker-supplied Jinja inside the execution environment, yielding arbitrary command execution and disclosure of secrets belonging to credentials the attacker cannot normally read. The flaw is exploitable remotely with no user interaction (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N per independent assessment) and requires only a controller account able to set one of the affected launch-time fields. No public exploit code has been identified at time of analysis, and the issue is not listed in CISA KEV; priority is bounded by the required authenticated foothold and the niche deployment footprint.
Remote code execution in Red Hat Ansible Automation Platform 2's automation-controller is possible when a privileged, authenticated user (CVSS PR:H) defines a custom Credential Type and abuses its environment-variable injector to set a process-hijacking loader variable such as BASH_ENV, ENV, LD_PRELOAD, LD_LIBRARY_PATH, PYTHONSTARTUP, or GIT_SSH_COMMAND, which the existing ANSIBLE_* prefix check and fixed ENV_BLOCKLIST fail to catch. Paired with the credential file injector, the attacker plants a script in the execution environment and points the loader variable at it, so arbitrary code executes inside the execution-environment container for any job that later attaches a credential of that type; this requires both the high privilege to author the credential type and a subsequent job consuming it. Red Hat's published CVSS of 7.6 (C:L/I:H/A:N) is lower than our independent assessment of the full vector (C:H/I:H/A:H), and because the vulnerable controller and the impacted execution-environment container are different security scopes, S:C applies. There is no CISA KEV listing and no public exploit identified at time of analysis.
Privilege escalation in Red Hat Ansible Automation Platform 2 (built on the AWX upstream project) lets an authenticated AAP platform administrator escape the container-group sandbox and obtain OpenShift namespace-level access, including the ability to read and exfiltrate namespace secrets. The flaw is reachable over the network (AV:N) with no user interaction (UI:N) and changes scope across the container/namespace boundary (S:C), but it is gated on the highest AAP privilege tier (PR:H), so it is an insider or compromised-admin scenario rather than an unauthenticated attack; only deployments that use container groups backed by OpenShift/Kubernetes are exposed. No public exploit code has been identified at time of analysis and the issue is not confirmed actively exploited (CISA KEV); no vendor-released patch has been identified at time of analysis, so mitigation depends on restricting the vulnerable field or the administrators who can reach it.
An authenticated automation-controller administrator in Red Hat Ansible Automation Platform 2 can turn the administrator-controlled format template for API 4XX log messages into a secret-reading primitive, using Python string-format traversal to walk from the interpolated user object into Django settings and pull out the SECRET_KEY and the database password. Because the log destination (external aggregator) is also administrator-controlled, the formatted message - and therefore the secrets - can be shipped off the host, giving the administrator the master key protecting all stored credentials, the ability to forge signed user sessions, and direct database access; the assessed vector is CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:N (8.7) with high confidentiality and integrity impact and scope change, since secrets leave the controller's security boundary. No public exploit code has been identified at time of analysis and there is no CISA KEV entry, so this is a high-priority hardening issue rather than an actively exploited one: the practical risk is driven by the very high value of the assets reachable once a privileged administrator account or the log pipeline is compromised.
Stored cross-site scripting in the automation-controller component of Red Hat Ansible Automation Platform 2 lets an authenticated low-privileged user embed a javascript: hyperlink into job, ad hoc command, project update, or inventory update standard output, which is then rendered as a text/html link in the controller's stdout view. Because the HTML conversion escapes HTML metacharacters but never strips ANSI terminal escape sequences, an OSC 8 hyperlink becomes an unfiltered HTML anchor, and the response carries no Content-Security-Policy; a higher-privileged user (for example an administrator) who views that output page and clicks the link executes attacker-controlled JavaScript in their authenticated session, allowing actions up to full platform takeover. The vector is network-reachable with low privileges (CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:N, 8.7), but exploitation hinges on a privileged victim actively clicking the crafted link; no public exploit code and no confirmed active exploitation were identified at time of analysis.
Stored password survey answers in Red Hat Ansible Automation Platform 2's automation-controller can be recovered in plaintext by an authenticated user holding the delegated JobTemplate Admin role. The attacker tightens the minimum/maximum length constraint on a password-type survey question, then forces revalidation of a schedule or workflow job template node created by a higher-privileged user, causing the controller to decrypt the stored secret and embed it in the HTTP length-validation error response. No public exploit identified at time of analysis; exploitation is not unauthenticated (CVSS PR:L) and requires both the delegated role and an existing password-type survey value, making this a lateral, privilege-crossing credential-disclosure issue rather than a mass-exploitable perimeter break.
Authenticated users who hold permission to create or modify a project within a single organization can execute arbitrary commands on the Ansible Automation Platform 2 automation-controller task pod by setting the Project scm_url to a value beginning with a dash, for example '--upload-pack=<command>:x'. The automation-controller's git SCM module passes that URL verbatim as a positional argument to 'git ls-remote' without a '--' end-of-options separator, so git treats it as the --upload-pack option and executes the attacker's command via a shell, with output reflected through the project update stdout endpoint, enabling cross-tenant compromise and in-cluster lateral movement (CVSS 3.1 9.9, scope changed). Exploitation needs valid platform credentials and the git project type but no admin or cross-organization rights, and no public exploit code has been identified at time of analysis.
Privilege escalation and remote code execution on managed hosts is possible in Red Hat Ansible Automation Platform 2 because the automation-controller exposes the provisioning-callback secret (host_config_key) to anyone holding only read-level view_jobtemplate permission and accepts a client-supplied X-Forwarded-For header as proof of caller identity when the gateway proxy allow-list is empty. An attacker who reads the secret from the job template API representation or the activity stream and spoofs X-Forwarded-For to match any host in the target job template's inventory can launch that template against arbitrary managed hosts using the template's stored credentials; CVSS 3.1 base score is 9.9 (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H), no public exploit code was identified at time of analysis, and the decisive enabler is a non-default deployment condition - an empty proxy allow-list combined with provisioning callbacks actually being in use.
Unauthenticated remote attackers can stall job dispatch for every tenant on Red Hat Ansible Automation Platform 2 by repeatedly calling four debug scheduler views that are routed in production builds because their URL include is not gated on the debug setting. Each call lets any network-reachable client acquire the cluster-wide scheduler advisory lock, and since the legitimate scheduler takes that same lock without waiting, genuine scheduler runs are skipped, job dispatch is delayed or halted, and controller web workers are consumed. The debug root view also discloses the list of debug endpoints to unauthenticated callers, and no public exploit code has been identified at time of analysis.
Missing object-level authorization in the JobTemplate copy endpoint (CopyAPIView) of AWX and Red Hat Ansible Automation Platform 2 lets an authenticated user duplicate a JobTemplate they are not permitted to read, disclosing the template's configuration - playbook reference, associated credentials, inventory and extra variables - that RBAC was intended to protect. The root cause is CWE-862 (Missing Authorization): the copy view's GET path enforces a read check on the source object, but the POST path that performs the copy only validates add and copy-related permissions, none of which imply read access on the source template. Per the independent assessment (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N; vendor score 8.5), exploitation requires an authenticated account already holding inventory.use_role, project.use_role, execution_environment.read_role and credentials.use_role, so this is an insider/multi-tenant privilege-boundary flaw rather than unauthenticated remote compromise; no public exploit code was identified at time of analysis.
SSRF vulnerabilities in AWX notification backends (webhook, Mattermost, Rocket.Chat, and Grafana) allow an authenticated organization notification administrator to cause the AWX control node to issue outbound HTTP requests to internal, loopback, or RFC-1918 addresses that are not externally reachable. Beyond basic SSRF, the webhook backend compounds the risk by following HTTP redirects and replaying configured Basic Authentication credentials to the redirect destination regardless of host change, enabling credential exfiltration to attacker-controlled endpoints; the Grafana backend similarly exposes its API key by forwarding the Authorization header verbatim to any configured target URL. No public exploit has been identified at time of analysis, but the Changed scope and high confidentiality impact in the CVSS vector reflect significant real-world risk given the network position AWX control nodes typically occupy.
Path traversal in AWX's project_archive action plugin allows arbitrary file writes to execution node filesystems outside the intended project directory. Red Hat Ansible Automation Platform 2 is affected when processing zip or tar archives whose member filenames contain directory traversal sequences. An attacker who controls archive content - via admin-level project configuration, a compromised upstream archive source, or a man-in-the-middle attack on an unencrypted HTTP fetch - can write files as the extraction user and escalate to remote code execution through cron entries, SSH authorized_keys injection, or playbook content poisoning. No public exploit has been identified at time of analysis and the vulnerability is not listed in CISA KEV.
Credential exfiltration via SSRF in AWX's GitHub webhook status callback affects Red Hat Ansible Automation Platform 2: an attacker holding admin role on a webhook-enabled job template can forge a signed GitHub pull request webhook with an arbitrary statuses_url, causing AWX to POST authenticated status updates - including the configured Git Personal Access Token in the Authorization header - to an attacker-controlled or internal endpoint. The Changed scope (S:C) in the CVSS 7.7 vector reflects that the leaked PAT extends attacker reach beyond AWX to connected Git repositories and any internal services reachable via SSRF. No public exploit identified at time of analysis, and no CISA KEV listing exists.
Server-side request forgery in the Red Hat Ansible Automation Platform 2 Controller's HashiCorp Vault credential plugin lets an authenticated user with credential-creation rights force the controller pod to leak its own Kubernetes service account token. When a HashiCorp Vault Secret Lookup credential configured for kubernetes_role authentication is tested, the kubernetes_auth() routine in awx_plugins/credentials/hashivault.py transmits the pod token to an attacker-supplied URL. With that token the attacker gains Kubernetes API access to control-plane namespaces, enabling full pod CRUD and secret reads including database credentials and the Django SECRET_KEY. No public exploit identified at time of analysis, and the flaw is not on the CISA KEV list.
Local code execution in the Visual Studio Code Ansible (Lightspeed) extension lets a malicious project run arbitrary shell commands on a developer's machine by abusing the ansible.executionEnvironment.containerOptions and volumeMounts settings, which fail to sanitize shell separators (CWE-78). Because these are workspace-scoped settings, simply opening a booby-trapped repository can auto-trigger execution during Language Server initialization, yielding code execution as the VS Code user. No public exploit has been identified at time of analysis, and the flaw is not listed in CISA KEV; CVSS is 7.8 (High).
Arbitrary command execution in ansible-core allows an attacker who controls a collection source URI to run commands on a victim's machine when that victim executes 'ansible-galaxy collection install' against the malicious git source. The flaw lives in _extract_collection_from_git() in concrete_artifact_manager.py, which builds git clone commands without a '--' end-of-options separator, letting crafted URIs be parsed as git arguments. It is an incomplete fix for CVE-2026-11332, which patched the analogous role-install path but left the collection-install path exposed; there is no public exploit identified at time of analysis and it is not listed in CISA KEV.
Arbitrary file write in pulpcore's FilesystemExport feature allows an authenticated administrator to escape the intended export directory via directory-traversal sequences embedded in a user-controlled relative_path. Because the exported file content is also attacker-supplied (an uploaded artifact), the flaw lets a privileged user plant or overwrite arbitrary files anywhere the Pulp service user can write, enabling service compromise or broader host takeover. Rated CVSS 9.0 and reported by Red Hat, it affects pulpcore as embedded in Ansible Automation Platform 2, Satellite 6, and Red Hat Update Infrastructure 4/5; there is no public exploit identified at time of analysis.
mTLS authentication bypass in the Red Hat Ansible Automation Platform (AAP) Gateway Envoy proxy allows unauthenticated remote attackers to inject spoofed events into protected Event-Driven Ansible (EDA) event streams. The non-mTLS route to EDA event streams fails to strip the client-supplied Subject HTTP header even though the source defines requestHeadersToRemove for it, so an attacker can forge a Subject value matching a legitimate client certificate's Distinguished Name and impersonate an authenticated client. No public exploit identified at time of analysis; the issue is tracked by Red Hat (CWE-290, CVSS 8.2) but is not on CISA KEV and no EPSS score was provided.
Credential disclosure in Red Hat Ansible Automation Platform 2.5 and 2.6 allows any authenticated user to retrieve plaintext OAuth tokens, vault passwords, and SSH keys by sending forged Worker messages to the Event-Driven Ansible websocket endpoint. The /api/eda/ws/ansible-rulebook endpoint fails to verify permissions on activation_id values, enabling lateral credential theft across tenants. No public exploit identified at time of analysis, but the low attack complexity and scope-changed CVSS of 9.6 make this a high-priority patch.
Remote code execution in galaxy_ng's legacy role import API (v1) allows an authenticated user controlling a git repository to execute arbitrary commands on the pulp worker by crafting a branch or tag name containing shell metacharacters. The flaw stems from unsanitized git ref interpolation into a subprocess.run() call with shell=True inside do_git_checkout(), and only affects deployments where GALAXY_ENABLE_LEGACY_ROLES is explicitly enabled (non-default). No public exploit identified at time of analysis.
Stored cross-site scripting in the Ansible Automation Platform unified UI lets an authenticated user who can publish or upload a collection to Automation Hub embed a link using a script-executing URL scheme (for example javascript:) in that collection's documentation; the Hub documentation renderer (formatPartURL in frontend/hub DocumentationParsers.tsx) writes the URL into a link without validating its protocol, so the script executes in the Hub UI origin when a second authenticated user opens the collection documentation page and clicks the link. Red Hat scores it CVSS 3.1 5.4 (AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N) - low confidentiality and integrity impact with a scope change, since the injected script runs with the privileges of the Hub origin rather than staying inside the published content. The flaw ships in the AAP 2.6 and 2.7 release branches only; no public exploit code and no confirmed active exploitation (CISA KEV) were identified at time of analysis, and exploitation requires both a malicious publisher and a victim who actively activates the crafted link.
Pulp Ansible's bearer-token refresh for collection remotes can disclose access tokens to an authenticated attacker who can create or sync a remote and point it at a malicious server. The attacker must then reuse the token at the issuing service, and exploitation is only possible if another token download for a different remote has run on the same worker process, meaning shared, multi-tenant deployments are primarily at risk. No public exploit code exists, and the assessed attack complexity is high (AC:H), so this is a moderate-priority information disclosure issue rather than a top-tier emergency.
Authenticated users with permission to create and sync container remotes in Pulp can obtain upstream registry credentials-usernames, passwords, or bearer tokens-stored for other remotes because the pulp-container worker reuses authentication material across sync operations. This affects deployments built on Red Hat Ansible Automation Platform 2, Red Hat Satellite 6, and Red Hat Update Infrastructure 4/5, particularly multi-tenant environments where remotes share worker processes. No public exploit code or confirmed active exploitation has been identified; the flaw rates CVSS 6.5 (moderate) and requires no user interaction beyond the attacker's own sync, though it does require an authenticated user with remote-creation and sync privileges.
DOM-based cross-site scripting in the Red Hat Ansible Automation Platform UI allows an attacker-crafted link to execute arbitrary JavaScript inside a logged-in user's session, because a specific redirect route takes the destination from the 'next' query parameter and assigns it straight to the browser's location.href while bypassing the platform's own URL and scheme validation. Exploitation is constrained by two concrete prerequisites: the victim must already be authenticated to the platform UI (PR:L) and must actively click the malicious link (UI:R), which is why the issue carries a moderate CVSS 3.1 base score of 5.4 rather than a critical rating. No public exploit code and no confirmed active exploitation were identified at the time of analysis, and the risk is best characterized as a moderate, not top-priority, issue that should be scheduled rather than emergency-patched.
Path traversal and symlink-validation flaws in ansible-runner's unstream_dir() (CVE-2026-103754) let an authenticated, low-privilege actor who can inject crafted archive content into the transmit/worker protocol create files, create symlinks, or change permissions outside the intended extraction directory, which can be leveraged toward code execution. The issue affects ansible-runner as shipped in Red Hat Ansible Automation Platform 2 (and upstream/AWX deployments) prior to the PR #1550 fix and carries a vendor-assigned CVSS 3.1 base score of 5.9 (AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:L). No public exploit code or confirmed active exploitation was identified at time of analysis, and exploitation is constrained by the need to supply crafted archive members into this specific worker protocol path.
Ansible Automation Platform 2's gateway permits an authenticated gateway administrator (CVSS PR:H) to create a new service key for the Controller service cluster through the API, even though service-key creation is supposed to occur only via the installer-provisioned path; the resulting key is cryptographically indistinguishable from a legitimate one, so it can be used to mint a service-authentication token that impersonates the Controller service. When the non-default gateway OIDC workload-identity endpoint is enabled (FEATURE_OIDC_WORKLOAD_IDENTITY_ENABLED) and a downstream resource server such as HashiCorp Vault trusts the gateway's OIDC signing key, the attacker can induce the gateway to sign Workload Identity Tokens for arbitrary Controller workloads and retrieve the AAP credentials bound to that workload, crossing the administrator's authorization boundary to disclose secrets (C:H, no integrity or availability impact). Exploitation requires admin privileges plus that specific non-default trust configuration, and no public exploit has been identified at time of analysis; the defect is access-gated rather than broadly exploitable.
Argument injection in Red Hat Ansible Automation Platform 2's automation-controller system-job subsystem allows an authenticated user with superuser privileges to inject arbitrary command-line arguments into the control-plane awx-manage process, gaining control of its argument vector and the first entry of its Python module search path. The root cause is that the system-job template launch endpoint stores a caller-supplied 'days' value without applying the integer validation used elsewhere for that field, and the dispatcher flattens the management-command argument list into a single space-delimited string that the job runner re-splits, so embedded spaces become additional arguments; system jobs run in-process on the control node without the container isolation applied to other job types. Confirmed remote code execution does not follow from the injected arguments alone - it would require an additional import gadget that is not present in the current management commands - so the demonstrated impact is argument injection and search-path control rather than code execution, and no public exploit was identified at time of analysis.
Server-side request forgery in Red Hat Ansible Automation Platform 2's automation-controller email notification backend lets an authenticated user holding organization notification-admin permission point an email notification template's SMTP host and port at arbitrary internal, loopback, link-local or reserved addresses; the controller task process then opens a raw TCP connection to that target when the notification test is triggered. Because the resulting connection error is surfaced through the notification record, an attacker gains a three-state internal port-scan oracle (open, closed, filtered) over the control-plane cluster network, including the in-cluster Kubernetes API, and if a shared organization template stores an SMTP password, redirecting the host can leak that credential to an attacker-controlled server. Impact is moderate (vendor CVSS 6.4, CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N) and requires a privileged, already-authenticated role rather than anonymous access; no public exploit code has been identified at time of analysis and CISA KEV does not list this CVE.
Secret values that playbook authors explicitly marked with no_log can be recovered from Red Hat Ansible Automation Platform 2 (automation-controller) through the REST filter backend, because the WorkflowJobNode.ancestor_artifacts column is not wrapped in prevent_search() and therefore remains queryable even though it is omitted from the API serializer. An authenticated user - one with only read access to a workflow, or any authenticated user with no roles at all by abusing a regular-expression lookup that bypasses the JSON cross-relation filter guard via the world-readable credential-types endpoint - can use the result count as a boolean/count oracle to extract secrets character by character, potentially across organizations. The issue is rated CVSS 6.5 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N, CWE-639); no public exploit code or confirmed active exploitation was identified at time of analysis, and because recovery requires an account plus many incremental requests per character, the practical risk is a bounded confidentiality exposure rather than a top-tier emergency.
Source-IP spoofing in Ansible Automation Platform 2's automation-controller allows an authenticated remote attacker to forge the client IP recorded in audit and access logs when the application runs its shipped production reverse-proxy configuration and trusts the client-supplied X-Forwarded-For header. The flaw is CWE-348 and only affects log integrity (CVSS 3.1 4.3, AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N), with no access, confidentiality, or availability gain. No public exploit identified at time of analysis and no confirmed active exploitation (CISA KEV).
Red Hat Ansible Automation Platform 2 (automation-controller) lets an unauthenticated remote attacker enumerate which Job Template and Workflow Job Template IDs have a Bitbucket Data Center webhook configured, by abusing an observable response discrepancy in the Bitbucket DC webhook receiver. For diagnostics:ping events the receiver performs the template lookup before HMAC signature verification is skipped, so the endpoint returns HTTP 200 for a template with a Bitbucket DC webhook and HTTP 403 otherwise - an oracle that requires neither authentication (PR:N in the assessed vector) nor knowledge of the secret webhook_key. Assessed at CVSS 5.3 (AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N), this is a low-impact information-disclosure and enumeration issue: no secrets, code execution, or elevated access are exposed; no public exploit identified at time of analysis and no confirmed actively exploited status.
TLS peer impersonation in Red Hat Ansible Automation Platform 2's automation-controller instance install-bundle endpoint lets an authenticated controller System Administrator obtain a mesh-CA-signed X.509 certificate that TLS peers will accept as a different control node. The flaw arises because a caller-chosen instance hostname is copied verbatim into the certificate's Common Name, DNS SAN, and receptor node-id, and the hostname charset validator is case-insensitive while the uniqueness validator is case-sensitive, so a case variant of an existing control node's hostname passes registration and yields a hard-coded ten-year, non-revocable mesh peer credential. Realizing the impact additionally requires an on-path/man-in-the-middle position on the receptor mesh, and the scenario is most meaningful in managed or hosted deployments where a customer holds controller superuser while the platform operator runs the mesh; there is no public exploit identified at time of analysis, and the flaw does not grant direct remote code execution because receptor work submission is gated by a separate signing key absent from the bundle.
Authenticated users of any privilege level on Red Hat Ansible Automation Platform 2 automation-controller deployments can extract other tenants' notification secrets-PagerDuty service keys and Slack, Mattermost, RocketChat, and generic Webhook bearer-token URLs-by abusing the API filter backend as a boolean count-oracle. The attack requires only a low-privilege account (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N, base 6.5), is network-reachable and low in complexity, and yields high confidentiality impact with no integrity or availability effect. Impact is greatest in multi-tenant installations where recovered secrets break organization isolation and permit notification-channel impersonation; exploitation is inherently slow, requiring many iterative requests that may be visible in API logs. No public exploit code has been identified at time of analysis, and the flaw is not listed as confirmed actively exploited (CISA KEV).
Information disclosure in the automation-controller API of Red Hat Ansible Automation Platform 2 lets any remote unauthenticated party read the automation mesh topology from the health-check endpoint /api/v2/ping/ (CVSS 3.1: 5.3, AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N). Because the ApiV2PingView view is declared with the AllowAny permission class and over-serializes RBAC-gated mesh data into its anonymous response, an attacker needs only network reachability to walk away with node hostnames, node types, UUIDs, heartbeats, capacities, exact software versions, instance-group names and membership, the deployment install UUID, and the identity of the active control node. The exposure is confidentiality-only - no secrets, credentials, or tenant data are involved - and there is no public exploit identified at time of analysis, so this is a genuine but modest reconnaissance-grade issue rather than an urgent one.
Argument injection in the ad hoc command builder of Red Hat Ansible Automation Platform 2 lets an authenticated user who is permitted to run ad hoc commands smuggle ansible CLI options by passing a host-restriction (`limit`) value beginning with a hyphen, which ansible-core then parses as an option flag. Impact today is minimal (CVSS 3.1, CWE-88): because the injected token displaces the required `pattern` positional argument, only short-circuit flags such as `--version` and `--help` are reachable, so integrity impact is limited to low and no arbitrary option or command control is achievable. There is no public exploit identified at time of analysis, and the issue would only escalate if a future ansible-core release were to default or make optional the `pattern` positional - a hypothetical, non-default upstream change rather than current behavior.
Red Hat Ansible Automation Platform 2 (AWX) accepts leading-dash values in the scm_branch field processed by LaunchConfigurationBaseSerializer, allowing an authenticated user who can create or edit a Schedule or Workflow Job Template node to supply a value such as --upload-pack=/bin/id. The gap is a latent argument-injection issue (CWE-88) that is currently neutralized at runtime by the ValueError guard at jobs.py:1502, so no command execution occurs in shipping code; it would escalate to remote code execution only if that task-layer guard were refactored or removed in a future release. No public exploit code has been identified at time of analysis, and impact today is limited to a low-severity hardening gap (CVSS 3.1, integrity-only).
Information disclosure in Red Hat Ansible Automation Platform 2 allows an authenticated administrator (PR:H per the CVSS vector) to leak controller-side implementation details, including install paths, Python version, and source line numbers, into notification payloads delivered to an attacker-controlled webhook URL. A crafted Jinja notification template using a dynamic subscript such as job['job'+'_env'] slips past the static-Getattr AST whitelist, while a conditional gate like {% if job.id > 100 %} prevents the branch from firing during the small-job.id stub test-render, so the payload executes only against a real job whose exception produces a full traceback in the notification body. Impact is confined to low confidentiality loss (C:L) with no integrity or availability effect, and no public exploit has been identified at time of analysis.
An authenticated tenant superuser on Red Hat Ansible Automation Platform 2 can use the automation-controller API to confirm the existence of arbitrary absolute filesystem paths inside the controller-web pod, because StringListPathField.to_internal_value() calls os.path.exists() on unbounded user-supplied input and the 200-versus-400 response difference acts as an existence oracle. The issue is rated CVSS 4.1 (AV:N/AC:L/PR:H/UI:N/S:C/C:L/I:N/A:N) and only reads existence, not content, but it lets a tenant admin probe paths such as /etc/tower/SECRET_KEY, Kubernetes service-account tokens, receptor sockets and ConfigMap mount points. It is materially impactful only in managed AAP deployments (ansiblecloud.com) where the tenant administrator is not the host administrator; there is no public exploit identified at time of analysis and no vendor-released patch identified at time of analysis.
Information disclosure in the automation-controller component of Red Hat Ansible Automation Platform 2 lets any authenticated user of any privilege level extract internal database and ORM structure by sending crafted values through the host_filter query parameter of the Host list REST API. Because HostList.list() catches a bare Exception and returns str(e) verbatim, a malformed relation lookup such as credential__search=x raises a Django FieldError that exposes the complete Host model relation graph (including internal reverse accessors), while a malformed pattern such as name__regex=[bad raises a PostgreSQL DataError that reflects the raw database error string. The flaw is rated CVSS 4.3 (MEDIUM) with a vector of AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N; exploitation requires valid credentials but no user interaction, impact is limited to low-confidentiality schema and error-text leakage with no modification or code execution, and no public exploit was identified at time of analysis.
Authenticated users of Red Hat Ansible Automation Platform 2 can read sensitive commercial license metadata - account number, subscription ID, pool ID, SKU, support level, and instance counts - from the /api/v2/config/ endpoint, which is guarded only by Django REST Framework's IsAuthenticated permission class. The superuser/auditor gate that protects other configuration keys such as project_base_dir, project_local_paths, and custom_virtualenvs does not extend to the license_info block, so any logged-in account of any privilege level can retrieve it without user interaction or non-default configuration. Per the independent assessment this is a genuinely low-priority, information-disclosure issue (CVSS 4.3, PR:L) - no public exploit has been identified at time of analysis, and the practical risk is reconnaissance and social-engineering enablement against Red Hat support rather than direct compromise.
Authenticated but unprivileged users of Red Hat Ansible Automation Platform 2 can read platform-wide job event information through the JobJobEventsChildrenSummary endpoint, which performs no object-level authorization check. Because the view declares no model or parent_model, ModelAccessPermission.check_get_permissions() falls through and returns True for every authenticated principal, and the handler substitutes a raw get_object_or_404(Job, pk), exposing event tree structure, event_processing_finished status, and the existence of arbitrary Job IDs via a 200/404 oracle. Exploitation requires only a valid zero-privilege account on the controller and no user interaction, making this a confidentiality-only information disclosure (assessed CVSS 5.0, AV:N/AC:L/PR:L/UI:N); no public exploit code has been identified at time of analysis, and the sibling endpoint /jobs/{id}/job_events/ correctly returns 403, confirming the defect is endpoint-specific.
Information disclosure in Red Hat Ansible Automation Platform 2 allows an authenticated low-privilege user to enumerate named resources - organizations, credentials, inventories, and hosts - across tenants, including internal hostnames, by observing a response-discrepancy in the URLModificationMiddleware. The middleware resolves named-URL lookups against unfiltered Model.objects before RBAC enforcement, and its 403→404 shim only rewrites 403 responses, so the pk=0 miss path remains distinguishable via 'Not found.' versus 'No <Model> matches...'. Exploitation requires an authenticated account (PR:L per CVSS) and is only meaningful on multi-tenant deployments; it yields existence information only, with no modification or availability impact. No public exploit identified at time of analysis and no CISA KEV status is indicated (no EPSS score was provided).
CPU exhaustion denial of service in jwcrypto's JWK.import_key() allows a remote unauthenticated attacker to supply a crafted JWK with an arbitrarily large key_ops array and trigger O(n²) duplicate-detection work, consuming CPU proportional to the square of the array length. Any Python application that passes externally-supplied JWK material to this API - via ECDH-ES key agreement, OIDC dynamic client registration, DPoP proof parsing, or ACME account key registration - is vulnerable. No public exploit or active exploitation (CISA KEV) has been identified at time of analysis; CVSS rates this at 5.9 (Medium) with AC:H reflecting the requirement that attacker-controlled key material must reach the vulnerable code path.
A path-handling flaw in the containers/storage Go library lets a crafted tar archive containing a malicious whiteout entry (for example 'victim/.wh.') cause UnpackLayer, ApplyLayer, or ApplyUncompressedLayer to replace the extraction destination directory with an arbitrary file. Systems that unpack container image layers with this library — notably Red Hat Enterprise Linux 10, Red Hat Ansible Automation Platform 2, OpenShift Container Platform 4, Quay 3, OpenShift Virtualization, Dev Spaces, and Red Hat Hardened Images — are in scope. Exploitation requires the operator or process to unpack an attacker-supplied archive, and the integrity impact is confined to the local extraction target; no public exploit code has been identified at time of analysis, and the vulnerability is not listed in CISA KEV, consistent with the modest CVSS 3.1 base score of 4.4.
Symlink-based path traversal in the buildah/copier Go package allows a crafted tar archive to create files outside the intended extraction directory when the library is used outside of Buildah by a non-root caller. Buildah's own extraction path applies chroot hardening and is explicitly not affected, so real exposure sits with downstream consumers of the package - including Red Hat Ansible Automation Platform 2 and Red Hat Enterprise Linux 10 in the published CPE data, plus other tagged Red Hat products - that unpack untrusted archives with it. Impact is integrity-only (no confidentiality or availability component in the assessed vector), the victim application must actually process the malicious archive (UI:R), EPSS is low at 0.25% (16th percentile), CISA's SSVC records exploitation as none and automatable as no, and no public exploit code has been identified at time of analysis.
Key-ID (kid) bypass in the jwcrypto Python JOSE library allows an attacker who holds any valid key within a JWK set to forge a General JSON Serialization JWS that satisfies verification for a different kid, effectively impersonating another tenant, user, or service. Affected deployments include Red Hat Ansible Automation Platform 2, RHEL 7-10, Red Hat OpenShift AI (RHOAI), and Red Hat OpenStack Platform 16.2, wherever jwcrypto performs JWS signature verification with kid-based authorization. No public exploit or CISA KEV listing has been identified at time of analysis, and the EPSS score is not provided, but the integrity impact is high for multi-tenant architectures.
Stored cross-site scripting in pulpcore's content serving layer allows authenticated users with file upload permissions to execute arbitrary JavaScript in the browsers of other users. When pulpcore uses local filesystem storage, uploaded files are served with their original MIME types (e.g., text/html, image/svg+xml) and without a Content-Disposition: attachment header, causing browsers to render the files inline within the host application's origin instead of prompting a download. This flaw affects Red Hat Ansible Automation Platform 2, Red Hat Satellite 6, and Red Hat Update Infrastructure 4 and 5; no public exploit code or confirmed active exploitation is identified at time of analysis.
Denial of service in jwcrypto's JWE.deserialize() function allows a remote unauthenticated attacker to crash any service that processes untrusted JWE tokens by submitting a malformed compact serialization containing an excessive number of period delimiters, triggering uncontrolled memory allocation and a MemoryError. Affected deployments include Red Hat Ansible Automation Platform 2, RHEL 9 and 10, OpenShift AI (RHOAI), and OpenStack Platform 16.2 as disclosed via Red Hat Bugzilla 2524147 and upstream advisory GHSA-96rv-c4vc-h4f4. No public exploit code or CISA KEV listing exists at time of analysis, and impact is confined to availability with no confidentiality or integrity exposure.
Server-side request forgery in galaxy_ng, the Ansible Galaxy server plugin for Pulp, allows authenticated users holding namespace management permissions to redirect a background worker process into probing arbitrary internal network addresses, including loopback interfaces and cloud instance metadata endpoints (e.g., 169.254.169.254). The dual-impact vulnerability enables both internal network reconnaissance (enumerating reachable IPs and reading service responses) and a denial-of-service condition against background workers due to the absence of an HTTP client timeout. No public exploit has been identified at time of analysis, and no confirmed KEV listing exists; however, the scope-changing CVSS vector (S:C) reflects that impact crosses trust boundaries from the application into adjacent internal infrastructure.
Incomplete RBAC authorization in AWX's websocket event consumer exposes real-time job stdout to any authenticated user, regardless of organizational access controls. Three event group types - inventory_update_events, project_update_events, and system_job_events - are absent from the consumer_access() authorization mapping, causing authorization checks to be silently skipped when users subscribe to these channels for arbitrary object IDs. This is confirmed as an incomplete remediation of CVE-2020-10698, affecting Red Hat Ansible Automation Platform 2. No public exploit or CISA KEV listing is identified at time of analysis.
Server-Side Request Forgery in AWX's GitHub webhook integration (Red Hat Ansible Automation Platform 2) enables a remote attacker possessing a job template's webhook_key to redirect PAT-bearing status callbacks to an attacker-controlled endpoint, exfiltrating the configured GitHub Personal Access Token. The attack exploits AWX's failure to validate that the pull_request.statuses_url field in an incoming webhook payload points to a legitimate GitHub API domain before using it as a POST target. No public exploit is identified at time of analysis, but successful exploitation yields persistent GitHub repository access through the stolen PAT, extending the blast radius well beyond the AWX system itself.
Insufficient OAuth token invalidation in Ansible Lightspeed (part of Red Hat Ansible Automation Platform 2.x) allows a remote attacker who has exfiltrated a valid access token to maintain persistent authenticated sessions even after the legitimate user has logged out. The backend fails to revoke the token server-side on logout, leaving it exploitable until natural expiration. Successful exploitation enables unauthorized read access to sensitive Ansible resources - including inventories, playbooks, and configuration data - with no public exploit or CISA KEV listing identified at time of analysis.
Path traversal in awxkit's YAML !include directive exposes arbitrary local files when a user imports a crafted YAML file via the AWX CLI. Affecting Red Hat Ansible Automation Platform 2, the vulnerability (CWE-22) allows an unauthenticated attacker who can deliver a malicious YAML file to a victim to read arbitrary YAML-formatted files from that user's local filesystem - including potentially sensitive configuration, credential, or key material files - without any write or execution capability. No public exploit identified at time of analysis; CVSS 4.7 reflects the real-world constraints of local attack vector, high complexity, and mandatory user interaction.
Log injection vulnerability in Red Hat Ansible Automation Platform 2 MCP server allows unauthenticated remote attackers to inject control characters and ANSI escape sequences via the `toolsetroute` parameter, enabling log forgery and obscuring legitimate audit trails to facilitate social engineering attacks that trick operators into executing malicious commands or accessing attacker-controlled URLs. CVSS 5.3 (medium) reflects the integrity impact on logs without direct confidentiality or availability impact; exploitation requires no authentication, credentials, or user interaction. No public exploit code or active exploitation has been identified at time of analysis.
Container privilege escalation in Red Hat Ansible Automation Platform 2 allows non-root users within affected container images to gain root privileges by modifying the group-writable /etc/passwd file. During the container build process, /etc/passwd is created with overly permissive group-write permissions, enabling any user in the root group to add arbitrary entries including a UID 0 account. This vulnerability requires local container execution access and elevated group membership, but results in complete container compromise when exploited.
Jinja2 template injection in Ansible Operator Plugins (CWE-1336) lets an authenticated Kubernetes user who can create or modify a custom resource reconciled by an affected Ansible-based operator execute embedded Jinja2 expressions inside the operator pod, achieving remote code execution and escalating to the operator's service account. Because these operators typically hold cluster-wide RBAC, successful exploitation crosses a privilege boundary (CVSS 3.1 base 8.5, AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H), affecting components of Red Hat Ansible Automation Platform 2, Red Hat Advanced Cluster Management for Kubernetes 2, the Migration Toolkit for Applications/Containers/Virtualization, OpenShift Service Mesh 3 and related Red Hat OpenShift and OpenStack streams. No public exploit code and no confirmed active exploitation (CISA KEV) were identified at time of analysis; the high attack complexity reflects the prerequisite that the targeted operator must pass attacker-controllable CR spec values into Jinja2 templating without sanitization. This is a genuinely high-priority flaw rather than a CVSS-inflated one, but with an important authentication caveat: purely anonymous or read-only users cannot trigger it.
Symlink-following file overwrite on the Ansible control node is possible in ansible-core when a user runs `ansible-galaxy collection install` against a crafted collection tarball, because the archive extractor validates member paths with lexical normalization (os.path.abspath) instead of resolving symlinks (os.path.realpath) and performs no containment check on symlink-typed directory members before creating them, letting chained symlink entries redirect a subsequent file member outside the destination directory. The flaw (CWE-59, CVSS 8.8, vector AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H) is a bypass of the fix for CVE-2020-10691 and requires the victim to actively install the malicious collection, so an attacker can write arbitrary files with the privileges of the ansible-galaxy user and potentially achieve code execution on the control node. No public exploit has been identified at time of analysis and the CVE is not listed in CISA KEV; affected deployments include ansible-core 2.x as shipped in Red Hat Ansible Automation Platform 2 and numerous other Red Hat products, and no patched version is identified in the supplied intelligence, which currently cites only the Red Hat CVE page and Bugzilla 2531646.
Path traversal in the pulpcore content upload API allows an authenticated user holding only low-privilege file-repository permissions to read arbitrary files accessible to the Pulp server process by submitting a crafted 'file:' URL through the 'file_url' parameter, which is dispatched to the file downloader despite an intended scheme check. Baseline impact is confidentiality loss on the Pulp host; in deployments that include Pulp Container the same flaw escalates to theft of the container registry token signing private key, enabling forged bearer tokens and unauthorized access to every private container repository in the registry. Downstream products embedding pulpcore are affected, including Red Hat Satellite 6, Red Hat Ansible Automation Platform 2, and Red Hat Update Infrastructure 4/5. There is no public exploit identified at time of analysis, and EPSS data was not provided; Red Hat tracks the issue under advisory https://access.redhat.com/security/cve/CVE-2026-90959.
Command injection in the automation controller's external logging (rsyslog) configuration of Red Hat Ansible Automation Platform 2 allows a superuser to achieve arbitrary command execution inside the control-plane rsyslog component, exposing the controller SECRET_KEY and database credentials and enabling decryption of all stored credentials. Exploitation requires authenticated superuser privileges (CVSS 3.1 7.2, PR:H, no user interaction) and only takes effect when external logging is in use, so the malicious RainerScript configuration is actually generated and loaded. No public exploit code was identified and there is no CISA KEV listing indicating active exploitation, meaning real-world risk is strongly gated by the elevated privilege requirement even though the post-exploitation impact is a full control-plane compromise.
Missing authorization checks in the Red Hat Ansible Automation Platform 2 automation-controller allow an authenticated organization workflow-admin - a delegated, non-superuser role - to escalate into the control plane by copying a WorkflowJobTemplate and then launching jobs pinned to instance groups they hold no use_role on. The deep-copy permission sanitizer re-validates only the inventory, unified_job_template, and credentials of each cloned node, silently carrying over instance_groups, execution_environment, and labels, so the copier becomes administrator of a workflow that executes attacker-influenced automation in the control-plane execution context (CVSS 9.9, scope changed, high confidentiality, integrity, and availability impact). Exploitation is confirmed to require only a normal multi-tenant deployment plus workflow-admin rights; no public exploit code has been identified at time of analysis and there is no CISA KEV entry, and no vendor-released patch version was confirmed in the available intelligence.
Authenticated but low-privileged users of Red Hat Ansible Automation Platform 2 can bypass the automation-controller's sanitize_jinja() input-validation guard and have ansible-core evaluate attacker-supplied Jinja inside the execution environment, yielding arbitrary command execution and disclosure of secrets belonging to credentials the attacker cannot normally read. The flaw is exploitable remotely with no user interaction (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N per independent assessment) and requires only a controller account able to set one of the affected launch-time fields. No public exploit code has been identified at time of analysis, and the issue is not listed in CISA KEV; priority is bounded by the required authenticated foothold and the niche deployment footprint.
Remote code execution in Red Hat Ansible Automation Platform 2's automation-controller is possible when a privileged, authenticated user (CVSS PR:H) defines a custom Credential Type and abuses its environment-variable injector to set a process-hijacking loader variable such as BASH_ENV, ENV, LD_PRELOAD, LD_LIBRARY_PATH, PYTHONSTARTUP, or GIT_SSH_COMMAND, which the existing ANSIBLE_* prefix check and fixed ENV_BLOCKLIST fail to catch. Paired with the credential file injector, the attacker plants a script in the execution environment and points the loader variable at it, so arbitrary code executes inside the execution-environment container for any job that later attaches a credential of that type; this requires both the high privilege to author the credential type and a subsequent job consuming it. Red Hat's published CVSS of 7.6 (C:L/I:H/A:N) is lower than our independent assessment of the full vector (C:H/I:H/A:H), and because the vulnerable controller and the impacted execution-environment container are different security scopes, S:C applies. There is no CISA KEV listing and no public exploit identified at time of analysis.
Privilege escalation in Red Hat Ansible Automation Platform 2 (built on the AWX upstream project) lets an authenticated AAP platform administrator escape the container-group sandbox and obtain OpenShift namespace-level access, including the ability to read and exfiltrate namespace secrets. The flaw is reachable over the network (AV:N) with no user interaction (UI:N) and changes scope across the container/namespace boundary (S:C), but it is gated on the highest AAP privilege tier (PR:H), so it is an insider or compromised-admin scenario rather than an unauthenticated attack; only deployments that use container groups backed by OpenShift/Kubernetes are exposed. No public exploit code has been identified at time of analysis and the issue is not confirmed actively exploited (CISA KEV); no vendor-released patch has been identified at time of analysis, so mitigation depends on restricting the vulnerable field or the administrators who can reach it.
An authenticated automation-controller administrator in Red Hat Ansible Automation Platform 2 can turn the administrator-controlled format template for API 4XX log messages into a secret-reading primitive, using Python string-format traversal to walk from the interpolated user object into Django settings and pull out the SECRET_KEY and the database password. Because the log destination (external aggregator) is also administrator-controlled, the formatted message - and therefore the secrets - can be shipped off the host, giving the administrator the master key protecting all stored credentials, the ability to forge signed user sessions, and direct database access; the assessed vector is CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:N (8.7) with high confidentiality and integrity impact and scope change, since secrets leave the controller's security boundary. No public exploit code has been identified at time of analysis and there is no CISA KEV entry, so this is a high-priority hardening issue rather than an actively exploited one: the practical risk is driven by the very high value of the assets reachable once a privileged administrator account or the log pipeline is compromised.
Stored cross-site scripting in the automation-controller component of Red Hat Ansible Automation Platform 2 lets an authenticated low-privileged user embed a javascript: hyperlink into job, ad hoc command, project update, or inventory update standard output, which is then rendered as a text/html link in the controller's stdout view. Because the HTML conversion escapes HTML metacharacters but never strips ANSI terminal escape sequences, an OSC 8 hyperlink becomes an unfiltered HTML anchor, and the response carries no Content-Security-Policy; a higher-privileged user (for example an administrator) who views that output page and clicks the link executes attacker-controlled JavaScript in their authenticated session, allowing actions up to full platform takeover. The vector is network-reachable with low privileges (CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:N, 8.7), but exploitation hinges on a privileged victim actively clicking the crafted link; no public exploit code and no confirmed active exploitation were identified at time of analysis.
Stored password survey answers in Red Hat Ansible Automation Platform 2's automation-controller can be recovered in plaintext by an authenticated user holding the delegated JobTemplate Admin role. The attacker tightens the minimum/maximum length constraint on a password-type survey question, then forces revalidation of a schedule or workflow job template node created by a higher-privileged user, causing the controller to decrypt the stored secret and embed it in the HTTP length-validation error response. No public exploit identified at time of analysis; exploitation is not unauthenticated (CVSS PR:L) and requires both the delegated role and an existing password-type survey value, making this a lateral, privilege-crossing credential-disclosure issue rather than a mass-exploitable perimeter break.
Authenticated users who hold permission to create or modify a project within a single organization can execute arbitrary commands on the Ansible Automation Platform 2 automation-controller task pod by setting the Project scm_url to a value beginning with a dash, for example '--upload-pack=<command>:x'. The automation-controller's git SCM module passes that URL verbatim as a positional argument to 'git ls-remote' without a '--' end-of-options separator, so git treats it as the --upload-pack option and executes the attacker's command via a shell, with output reflected through the project update stdout endpoint, enabling cross-tenant compromise and in-cluster lateral movement (CVSS 3.1 9.9, scope changed). Exploitation needs valid platform credentials and the git project type but no admin or cross-organization rights, and no public exploit code has been identified at time of analysis.
Privilege escalation and remote code execution on managed hosts is possible in Red Hat Ansible Automation Platform 2 because the automation-controller exposes the provisioning-callback secret (host_config_key) to anyone holding only read-level view_jobtemplate permission and accepts a client-supplied X-Forwarded-For header as proof of caller identity when the gateway proxy allow-list is empty. An attacker who reads the secret from the job template API representation or the activity stream and spoofs X-Forwarded-For to match any host in the target job template's inventory can launch that template against arbitrary managed hosts using the template's stored credentials; CVSS 3.1 base score is 9.9 (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H), no public exploit code was identified at time of analysis, and the decisive enabler is a non-default deployment condition - an empty proxy allow-list combined with provisioning callbacks actually being in use.
Unauthenticated remote attackers can stall job dispatch for every tenant on Red Hat Ansible Automation Platform 2 by repeatedly calling four debug scheduler views that are routed in production builds because their URL include is not gated on the debug setting. Each call lets any network-reachable client acquire the cluster-wide scheduler advisory lock, and since the legitimate scheduler takes that same lock without waiting, genuine scheduler runs are skipped, job dispatch is delayed or halted, and controller web workers are consumed. The debug root view also discloses the list of debug endpoints to unauthenticated callers, and no public exploit code has been identified at time of analysis.
Missing object-level authorization in the JobTemplate copy endpoint (CopyAPIView) of AWX and Red Hat Ansible Automation Platform 2 lets an authenticated user duplicate a JobTemplate they are not permitted to read, disclosing the template's configuration - playbook reference, associated credentials, inventory and extra variables - that RBAC was intended to protect. The root cause is CWE-862 (Missing Authorization): the copy view's GET path enforces a read check on the source object, but the POST path that performs the copy only validates add and copy-related permissions, none of which imply read access on the source template. Per the independent assessment (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N; vendor score 8.5), exploitation requires an authenticated account already holding inventory.use_role, project.use_role, execution_environment.read_role and credentials.use_role, so this is an insider/multi-tenant privilege-boundary flaw rather than unauthenticated remote compromise; no public exploit code was identified at time of analysis.
SSRF vulnerabilities in AWX notification backends (webhook, Mattermost, Rocket.Chat, and Grafana) allow an authenticated organization notification administrator to cause the AWX control node to issue outbound HTTP requests to internal, loopback, or RFC-1918 addresses that are not externally reachable. Beyond basic SSRF, the webhook backend compounds the risk by following HTTP redirects and replaying configured Basic Authentication credentials to the redirect destination regardless of host change, enabling credential exfiltration to attacker-controlled endpoints; the Grafana backend similarly exposes its API key by forwarding the Authorization header verbatim to any configured target URL. No public exploit has been identified at time of analysis, but the Changed scope and high confidentiality impact in the CVSS vector reflect significant real-world risk given the network position AWX control nodes typically occupy.
Path traversal in AWX's project_archive action plugin allows arbitrary file writes to execution node filesystems outside the intended project directory. Red Hat Ansible Automation Platform 2 is affected when processing zip or tar archives whose member filenames contain directory traversal sequences. An attacker who controls archive content - via admin-level project configuration, a compromised upstream archive source, or a man-in-the-middle attack on an unencrypted HTTP fetch - can write files as the extraction user and escalate to remote code execution through cron entries, SSH authorized_keys injection, or playbook content poisoning. No public exploit has been identified at time of analysis and the vulnerability is not listed in CISA KEV.
Credential exfiltration via SSRF in AWX's GitHub webhook status callback affects Red Hat Ansible Automation Platform 2: an attacker holding admin role on a webhook-enabled job template can forge a signed GitHub pull request webhook with an arbitrary statuses_url, causing AWX to POST authenticated status updates - including the configured Git Personal Access Token in the Authorization header - to an attacker-controlled or internal endpoint. The Changed scope (S:C) in the CVSS 7.7 vector reflects that the leaked PAT extends attacker reach beyond AWX to connected Git repositories and any internal services reachable via SSRF. No public exploit identified at time of analysis, and no CISA KEV listing exists.
Server-side request forgery in the Red Hat Ansible Automation Platform 2 Controller's HashiCorp Vault credential plugin lets an authenticated user with credential-creation rights force the controller pod to leak its own Kubernetes service account token. When a HashiCorp Vault Secret Lookup credential configured for kubernetes_role authentication is tested, the kubernetes_auth() routine in awx_plugins/credentials/hashivault.py transmits the pod token to an attacker-supplied URL. With that token the attacker gains Kubernetes API access to control-plane namespaces, enabling full pod CRUD and secret reads including database credentials and the Django SECRET_KEY. No public exploit identified at time of analysis, and the flaw is not on the CISA KEV list.
Local code execution in the Visual Studio Code Ansible (Lightspeed) extension lets a malicious project run arbitrary shell commands on a developer's machine by abusing the ansible.executionEnvironment.containerOptions and volumeMounts settings, which fail to sanitize shell separators (CWE-78). Because these are workspace-scoped settings, simply opening a booby-trapped repository can auto-trigger execution during Language Server initialization, yielding code execution as the VS Code user. No public exploit has been identified at time of analysis, and the flaw is not listed in CISA KEV; CVSS is 7.8 (High).
Arbitrary command execution in ansible-core allows an attacker who controls a collection source URI to run commands on a victim's machine when that victim executes 'ansible-galaxy collection install' against the malicious git source. The flaw lives in _extract_collection_from_git() in concrete_artifact_manager.py, which builds git clone commands without a '--' end-of-options separator, letting crafted URIs be parsed as git arguments. It is an incomplete fix for CVE-2026-11332, which patched the analogous role-install path but left the collection-install path exposed; there is no public exploit identified at time of analysis and it is not listed in CISA KEV.
Arbitrary file write in pulpcore's FilesystemExport feature allows an authenticated administrator to escape the intended export directory via directory-traversal sequences embedded in a user-controlled relative_path. Because the exported file content is also attacker-supplied (an uploaded artifact), the flaw lets a privileged user plant or overwrite arbitrary files anywhere the Pulp service user can write, enabling service compromise or broader host takeover. Rated CVSS 9.0 and reported by Red Hat, it affects pulpcore as embedded in Ansible Automation Platform 2, Satellite 6, and Red Hat Update Infrastructure 4/5; there is no public exploit identified at time of analysis.
mTLS authentication bypass in the Red Hat Ansible Automation Platform (AAP) Gateway Envoy proxy allows unauthenticated remote attackers to inject spoofed events into protected Event-Driven Ansible (EDA) event streams. The non-mTLS route to EDA event streams fails to strip the client-supplied Subject HTTP header even though the source defines requestHeadersToRemove for it, so an attacker can forge a Subject value matching a legitimate client certificate's Distinguished Name and impersonate an authenticated client. No public exploit identified at time of analysis; the issue is tracked by Red Hat (CWE-290, CVSS 8.2) but is not on CISA KEV and no EPSS score was provided.
Credential disclosure in Red Hat Ansible Automation Platform 2.5 and 2.6 allows any authenticated user to retrieve plaintext OAuth tokens, vault passwords, and SSH keys by sending forged Worker messages to the Event-Driven Ansible websocket endpoint. The /api/eda/ws/ansible-rulebook endpoint fails to verify permissions on activation_id values, enabling lateral credential theft across tenants. No public exploit identified at time of analysis, but the low attack complexity and scope-changed CVSS of 9.6 make this a high-priority patch.
Remote code execution in galaxy_ng's legacy role import API (v1) allows an authenticated user controlling a git repository to execute arbitrary commands on the pulp worker by crafting a branch or tag name containing shell metacharacters. The flaw stems from unsanitized git ref interpolation into a subprocess.run() call with shell=True inside do_git_checkout(), and only affects deployments where GALAXY_ENABLE_LEGACY_ROLES is explicitly enabled (non-default). No public exploit identified at time of analysis.
Stored cross-site scripting in the Ansible Automation Platform unified UI lets an authenticated user who can publish or upload a collection to Automation Hub embed a link using a script-executing URL scheme (for example javascript:) in that collection's documentation; the Hub documentation renderer (formatPartURL in frontend/hub DocumentationParsers.tsx) writes the URL into a link without validating its protocol, so the script executes in the Hub UI origin when a second authenticated user opens the collection documentation page and clicks the link. Red Hat scores it CVSS 3.1 5.4 (AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N) - low confidentiality and integrity impact with a scope change, since the injected script runs with the privileges of the Hub origin rather than staying inside the published content. The flaw ships in the AAP 2.6 and 2.7 release branches only; no public exploit code and no confirmed active exploitation (CISA KEV) were identified at time of analysis, and exploitation requires both a malicious publisher and a victim who actively activates the crafted link.
Pulp Ansible's bearer-token refresh for collection remotes can disclose access tokens to an authenticated attacker who can create or sync a remote and point it at a malicious server. The attacker must then reuse the token at the issuing service, and exploitation is only possible if another token download for a different remote has run on the same worker process, meaning shared, multi-tenant deployments are primarily at risk. No public exploit code exists, and the assessed attack complexity is high (AC:H), so this is a moderate-priority information disclosure issue rather than a top-tier emergency.
Authenticated users with permission to create and sync container remotes in Pulp can obtain upstream registry credentials-usernames, passwords, or bearer tokens-stored for other remotes because the pulp-container worker reuses authentication material across sync operations. This affects deployments built on Red Hat Ansible Automation Platform 2, Red Hat Satellite 6, and Red Hat Update Infrastructure 4/5, particularly multi-tenant environments where remotes share worker processes. No public exploit code or confirmed active exploitation has been identified; the flaw rates CVSS 6.5 (moderate) and requires no user interaction beyond the attacker's own sync, though it does require an authenticated user with remote-creation and sync privileges.
DOM-based cross-site scripting in the Red Hat Ansible Automation Platform UI allows an attacker-crafted link to execute arbitrary JavaScript inside a logged-in user's session, because a specific redirect route takes the destination from the 'next' query parameter and assigns it straight to the browser's location.href while bypassing the platform's own URL and scheme validation. Exploitation is constrained by two concrete prerequisites: the victim must already be authenticated to the platform UI (PR:L) and must actively click the malicious link (UI:R), which is why the issue carries a moderate CVSS 3.1 base score of 5.4 rather than a critical rating. No public exploit code and no confirmed active exploitation were identified at the time of analysis, and the risk is best characterized as a moderate, not top-priority, issue that should be scheduled rather than emergency-patched.
Path traversal and symlink-validation flaws in ansible-runner's unstream_dir() (CVE-2026-103754) let an authenticated, low-privilege actor who can inject crafted archive content into the transmit/worker protocol create files, create symlinks, or change permissions outside the intended extraction directory, which can be leveraged toward code execution. The issue affects ansible-runner as shipped in Red Hat Ansible Automation Platform 2 (and upstream/AWX deployments) prior to the PR #1550 fix and carries a vendor-assigned CVSS 3.1 base score of 5.9 (AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:L). No public exploit code or confirmed active exploitation was identified at time of analysis, and exploitation is constrained by the need to supply crafted archive members into this specific worker protocol path.
Ansible Automation Platform 2's gateway permits an authenticated gateway administrator (CVSS PR:H) to create a new service key for the Controller service cluster through the API, even though service-key creation is supposed to occur only via the installer-provisioned path; the resulting key is cryptographically indistinguishable from a legitimate one, so it can be used to mint a service-authentication token that impersonates the Controller service. When the non-default gateway OIDC workload-identity endpoint is enabled (FEATURE_OIDC_WORKLOAD_IDENTITY_ENABLED) and a downstream resource server such as HashiCorp Vault trusts the gateway's OIDC signing key, the attacker can induce the gateway to sign Workload Identity Tokens for arbitrary Controller workloads and retrieve the AAP credentials bound to that workload, crossing the administrator's authorization boundary to disclose secrets (C:H, no integrity or availability impact). Exploitation requires admin privileges plus that specific non-default trust configuration, and no public exploit has been identified at time of analysis; the defect is access-gated rather than broadly exploitable.
Argument injection in Red Hat Ansible Automation Platform 2's automation-controller system-job subsystem allows an authenticated user with superuser privileges to inject arbitrary command-line arguments into the control-plane awx-manage process, gaining control of its argument vector and the first entry of its Python module search path. The root cause is that the system-job template launch endpoint stores a caller-supplied 'days' value without applying the integer validation used elsewhere for that field, and the dispatcher flattens the management-command argument list into a single space-delimited string that the job runner re-splits, so embedded spaces become additional arguments; system jobs run in-process on the control node without the container isolation applied to other job types. Confirmed remote code execution does not follow from the injected arguments alone - it would require an additional import gadget that is not present in the current management commands - so the demonstrated impact is argument injection and search-path control rather than code execution, and no public exploit was identified at time of analysis.
Server-side request forgery in Red Hat Ansible Automation Platform 2's automation-controller email notification backend lets an authenticated user holding organization notification-admin permission point an email notification template's SMTP host and port at arbitrary internal, loopback, link-local or reserved addresses; the controller task process then opens a raw TCP connection to that target when the notification test is triggered. Because the resulting connection error is surfaced through the notification record, an attacker gains a three-state internal port-scan oracle (open, closed, filtered) over the control-plane cluster network, including the in-cluster Kubernetes API, and if a shared organization template stores an SMTP password, redirecting the host can leak that credential to an attacker-controlled server. Impact is moderate (vendor CVSS 6.4, CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N) and requires a privileged, already-authenticated role rather than anonymous access; no public exploit code has been identified at time of analysis and CISA KEV does not list this CVE.
Secret values that playbook authors explicitly marked with no_log can be recovered from Red Hat Ansible Automation Platform 2 (automation-controller) through the REST filter backend, because the WorkflowJobNode.ancestor_artifacts column is not wrapped in prevent_search() and therefore remains queryable even though it is omitted from the API serializer. An authenticated user - one with only read access to a workflow, or any authenticated user with no roles at all by abusing a regular-expression lookup that bypasses the JSON cross-relation filter guard via the world-readable credential-types endpoint - can use the result count as a boolean/count oracle to extract secrets character by character, potentially across organizations. The issue is rated CVSS 6.5 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N, CWE-639); no public exploit code or confirmed active exploitation was identified at time of analysis, and because recovery requires an account plus many incremental requests per character, the practical risk is a bounded confidentiality exposure rather than a top-tier emergency.
Source-IP spoofing in Ansible Automation Platform 2's automation-controller allows an authenticated remote attacker to forge the client IP recorded in audit and access logs when the application runs its shipped production reverse-proxy configuration and trusts the client-supplied X-Forwarded-For header. The flaw is CWE-348 and only affects log integrity (CVSS 3.1 4.3, AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N), with no access, confidentiality, or availability gain. No public exploit identified at time of analysis and no confirmed active exploitation (CISA KEV).
Red Hat Ansible Automation Platform 2 (automation-controller) lets an unauthenticated remote attacker enumerate which Job Template and Workflow Job Template IDs have a Bitbucket Data Center webhook configured, by abusing an observable response discrepancy in the Bitbucket DC webhook receiver. For diagnostics:ping events the receiver performs the template lookup before HMAC signature verification is skipped, so the endpoint returns HTTP 200 for a template with a Bitbucket DC webhook and HTTP 403 otherwise - an oracle that requires neither authentication (PR:N in the assessed vector) nor knowledge of the secret webhook_key. Assessed at CVSS 5.3 (AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N), this is a low-impact information-disclosure and enumeration issue: no secrets, code execution, or elevated access are exposed; no public exploit identified at time of analysis and no confirmed actively exploited status.
TLS peer impersonation in Red Hat Ansible Automation Platform 2's automation-controller instance install-bundle endpoint lets an authenticated controller System Administrator obtain a mesh-CA-signed X.509 certificate that TLS peers will accept as a different control node. The flaw arises because a caller-chosen instance hostname is copied verbatim into the certificate's Common Name, DNS SAN, and receptor node-id, and the hostname charset validator is case-insensitive while the uniqueness validator is case-sensitive, so a case variant of an existing control node's hostname passes registration and yields a hard-coded ten-year, non-revocable mesh peer credential. Realizing the impact additionally requires an on-path/man-in-the-middle position on the receptor mesh, and the scenario is most meaningful in managed or hosted deployments where a customer holds controller superuser while the platform operator runs the mesh; there is no public exploit identified at time of analysis, and the flaw does not grant direct remote code execution because receptor work submission is gated by a separate signing key absent from the bundle.
Authenticated users of any privilege level on Red Hat Ansible Automation Platform 2 automation-controller deployments can extract other tenants' notification secrets-PagerDuty service keys and Slack, Mattermost, RocketChat, and generic Webhook bearer-token URLs-by abusing the API filter backend as a boolean count-oracle. The attack requires only a low-privilege account (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N, base 6.5), is network-reachable and low in complexity, and yields high confidentiality impact with no integrity or availability effect. Impact is greatest in multi-tenant installations where recovered secrets break organization isolation and permit notification-channel impersonation; exploitation is inherently slow, requiring many iterative requests that may be visible in API logs. No public exploit code has been identified at time of analysis, and the flaw is not listed as confirmed actively exploited (CISA KEV).
Information disclosure in the automation-controller API of Red Hat Ansible Automation Platform 2 lets any remote unauthenticated party read the automation mesh topology from the health-check endpoint /api/v2/ping/ (CVSS 3.1: 5.3, AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N). Because the ApiV2PingView view is declared with the AllowAny permission class and over-serializes RBAC-gated mesh data into its anonymous response, an attacker needs only network reachability to walk away with node hostnames, node types, UUIDs, heartbeats, capacities, exact software versions, instance-group names and membership, the deployment install UUID, and the identity of the active control node. The exposure is confidentiality-only - no secrets, credentials, or tenant data are involved - and there is no public exploit identified at time of analysis, so this is a genuine but modest reconnaissance-grade issue rather than an urgent one.
Argument injection in the ad hoc command builder of Red Hat Ansible Automation Platform 2 lets an authenticated user who is permitted to run ad hoc commands smuggle ansible CLI options by passing a host-restriction (`limit`) value beginning with a hyphen, which ansible-core then parses as an option flag. Impact today is minimal (CVSS 3.1, CWE-88): because the injected token displaces the required `pattern` positional argument, only short-circuit flags such as `--version` and `--help` are reachable, so integrity impact is limited to low and no arbitrary option or command control is achievable. There is no public exploit identified at time of analysis, and the issue would only escalate if a future ansible-core release were to default or make optional the `pattern` positional - a hypothetical, non-default upstream change rather than current behavior.
Red Hat Ansible Automation Platform 2 (AWX) accepts leading-dash values in the scm_branch field processed by LaunchConfigurationBaseSerializer, allowing an authenticated user who can create or edit a Schedule or Workflow Job Template node to supply a value such as --upload-pack=/bin/id. The gap is a latent argument-injection issue (CWE-88) that is currently neutralized at runtime by the ValueError guard at jobs.py:1502, so no command execution occurs in shipping code; it would escalate to remote code execution only if that task-layer guard were refactored or removed in a future release. No public exploit code has been identified at time of analysis, and impact today is limited to a low-severity hardening gap (CVSS 3.1, integrity-only).
Information disclosure in Red Hat Ansible Automation Platform 2 allows an authenticated administrator (PR:H per the CVSS vector) to leak controller-side implementation details, including install paths, Python version, and source line numbers, into notification payloads delivered to an attacker-controlled webhook URL. A crafted Jinja notification template using a dynamic subscript such as job['job'+'_env'] slips past the static-Getattr AST whitelist, while a conditional gate like {% if job.id > 100 %} prevents the branch from firing during the small-job.id stub test-render, so the payload executes only against a real job whose exception produces a full traceback in the notification body. Impact is confined to low confidentiality loss (C:L) with no integrity or availability effect, and no public exploit has been identified at time of analysis.
An authenticated tenant superuser on Red Hat Ansible Automation Platform 2 can use the automation-controller API to confirm the existence of arbitrary absolute filesystem paths inside the controller-web pod, because StringListPathField.to_internal_value() calls os.path.exists() on unbounded user-supplied input and the 200-versus-400 response difference acts as an existence oracle. The issue is rated CVSS 4.1 (AV:N/AC:L/PR:H/UI:N/S:C/C:L/I:N/A:N) and only reads existence, not content, but it lets a tenant admin probe paths such as /etc/tower/SECRET_KEY, Kubernetes service-account tokens, receptor sockets and ConfigMap mount points. It is materially impactful only in managed AAP deployments (ansiblecloud.com) where the tenant administrator is not the host administrator; there is no public exploit identified at time of analysis and no vendor-released patch identified at time of analysis.
Information disclosure in the automation-controller component of Red Hat Ansible Automation Platform 2 lets any authenticated user of any privilege level extract internal database and ORM structure by sending crafted values through the host_filter query parameter of the Host list REST API. Because HostList.list() catches a bare Exception and returns str(e) verbatim, a malformed relation lookup such as credential__search=x raises a Django FieldError that exposes the complete Host model relation graph (including internal reverse accessors), while a malformed pattern such as name__regex=[bad raises a PostgreSQL DataError that reflects the raw database error string. The flaw is rated CVSS 4.3 (MEDIUM) with a vector of AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N; exploitation requires valid credentials but no user interaction, impact is limited to low-confidentiality schema and error-text leakage with no modification or code execution, and no public exploit was identified at time of analysis.
Authenticated users of Red Hat Ansible Automation Platform 2 can read sensitive commercial license metadata - account number, subscription ID, pool ID, SKU, support level, and instance counts - from the /api/v2/config/ endpoint, which is guarded only by Django REST Framework's IsAuthenticated permission class. The superuser/auditor gate that protects other configuration keys such as project_base_dir, project_local_paths, and custom_virtualenvs does not extend to the license_info block, so any logged-in account of any privilege level can retrieve it without user interaction or non-default configuration. Per the independent assessment this is a genuinely low-priority, information-disclosure issue (CVSS 4.3, PR:L) - no public exploit has been identified at time of analysis, and the practical risk is reconnaissance and social-engineering enablement against Red Hat support rather than direct compromise.
Authenticated but unprivileged users of Red Hat Ansible Automation Platform 2 can read platform-wide job event information through the JobJobEventsChildrenSummary endpoint, which performs no object-level authorization check. Because the view declares no model or parent_model, ModelAccessPermission.check_get_permissions() falls through and returns True for every authenticated principal, and the handler substitutes a raw get_object_or_404(Job, pk), exposing event tree structure, event_processing_finished status, and the existence of arbitrary Job IDs via a 200/404 oracle. Exploitation requires only a valid zero-privilege account on the controller and no user interaction, making this a confidentiality-only information disclosure (assessed CVSS 5.0, AV:N/AC:L/PR:L/UI:N); no public exploit code has been identified at time of analysis, and the sibling endpoint /jobs/{id}/job_events/ correctly returns 403, confirming the defect is endpoint-specific.
Information disclosure in Red Hat Ansible Automation Platform 2 allows an authenticated low-privilege user to enumerate named resources - organizations, credentials, inventories, and hosts - across tenants, including internal hostnames, by observing a response-discrepancy in the URLModificationMiddleware. The middleware resolves named-URL lookups against unfiltered Model.objects before RBAC enforcement, and its 403→404 shim only rewrites 403 responses, so the pk=0 miss path remains distinguishable via 'Not found.' versus 'No <Model> matches...'. Exploitation requires an authenticated account (PR:L per CVSS) and is only meaningful on multi-tenant deployments; it yields existence information only, with no modification or availability impact. No public exploit identified at time of analysis and no CISA KEV status is indicated (no EPSS score was provided).
CPU exhaustion denial of service in jwcrypto's JWK.import_key() allows a remote unauthenticated attacker to supply a crafted JWK with an arbitrarily large key_ops array and trigger O(n²) duplicate-detection work, consuming CPU proportional to the square of the array length. Any Python application that passes externally-supplied JWK material to this API - via ECDH-ES key agreement, OIDC dynamic client registration, DPoP proof parsing, or ACME account key registration - is vulnerable. No public exploit or active exploitation (CISA KEV) has been identified at time of analysis; CVSS rates this at 5.9 (Medium) with AC:H reflecting the requirement that attacker-controlled key material must reach the vulnerable code path.
A path-handling flaw in the containers/storage Go library lets a crafted tar archive containing a malicious whiteout entry (for example 'victim/.wh.') cause UnpackLayer, ApplyLayer, or ApplyUncompressedLayer to replace the extraction destination directory with an arbitrary file. Systems that unpack container image layers with this library — notably Red Hat Enterprise Linux 10, Red Hat Ansible Automation Platform 2, OpenShift Container Platform 4, Quay 3, OpenShift Virtualization, Dev Spaces, and Red Hat Hardened Images — are in scope. Exploitation requires the operator or process to unpack an attacker-supplied archive, and the integrity impact is confined to the local extraction target; no public exploit code has been identified at time of analysis, and the vulnerability is not listed in CISA KEV, consistent with the modest CVSS 3.1 base score of 4.4.
Symlink-based path traversal in the buildah/copier Go package allows a crafted tar archive to create files outside the intended extraction directory when the library is used outside of Buildah by a non-root caller. Buildah's own extraction path applies chroot hardening and is explicitly not affected, so real exposure sits with downstream consumers of the package - including Red Hat Ansible Automation Platform 2 and Red Hat Enterprise Linux 10 in the published CPE data, plus other tagged Red Hat products - that unpack untrusted archives with it. Impact is integrity-only (no confidentiality or availability component in the assessed vector), the victim application must actually process the malicious archive (UI:R), EPSS is low at 0.25% (16th percentile), CISA's SSVC records exploitation as none and automatable as no, and no public exploit code has been identified at time of analysis.
Key-ID (kid) bypass in the jwcrypto Python JOSE library allows an attacker who holds any valid key within a JWK set to forge a General JSON Serialization JWS that satisfies verification for a different kid, effectively impersonating another tenant, user, or service. Affected deployments include Red Hat Ansible Automation Platform 2, RHEL 7-10, Red Hat OpenShift AI (RHOAI), and Red Hat OpenStack Platform 16.2, wherever jwcrypto performs JWS signature verification with kid-based authorization. No public exploit or CISA KEV listing has been identified at time of analysis, and the EPSS score is not provided, but the integrity impact is high for multi-tenant architectures.
Stored cross-site scripting in pulpcore's content serving layer allows authenticated users with file upload permissions to execute arbitrary JavaScript in the browsers of other users. When pulpcore uses local filesystem storage, uploaded files are served with their original MIME types (e.g., text/html, image/svg+xml) and without a Content-Disposition: attachment header, causing browsers to render the files inline within the host application's origin instead of prompting a download. This flaw affects Red Hat Ansible Automation Platform 2, Red Hat Satellite 6, and Red Hat Update Infrastructure 4 and 5; no public exploit code or confirmed active exploitation is identified at time of analysis.
Denial of service in jwcrypto's JWE.deserialize() function allows a remote unauthenticated attacker to crash any service that processes untrusted JWE tokens by submitting a malformed compact serialization containing an excessive number of period delimiters, triggering uncontrolled memory allocation and a MemoryError. Affected deployments include Red Hat Ansible Automation Platform 2, RHEL 9 and 10, OpenShift AI (RHOAI), and OpenStack Platform 16.2 as disclosed via Red Hat Bugzilla 2524147 and upstream advisory GHSA-96rv-c4vc-h4f4. No public exploit code or CISA KEV listing exists at time of analysis, and impact is confined to availability with no confidentiality or integrity exposure.
Server-side request forgery in galaxy_ng, the Ansible Galaxy server plugin for Pulp, allows authenticated users holding namespace management permissions to redirect a background worker process into probing arbitrary internal network addresses, including loopback interfaces and cloud instance metadata endpoints (e.g., 169.254.169.254). The dual-impact vulnerability enables both internal network reconnaissance (enumerating reachable IPs and reading service responses) and a denial-of-service condition against background workers due to the absence of an HTTP client timeout. No public exploit has been identified at time of analysis, and no confirmed KEV listing exists; however, the scope-changing CVSS vector (S:C) reflects that impact crosses trust boundaries from the application into adjacent internal infrastructure.
Incomplete RBAC authorization in AWX's websocket event consumer exposes real-time job stdout to any authenticated user, regardless of organizational access controls. Three event group types - inventory_update_events, project_update_events, and system_job_events - are absent from the consumer_access() authorization mapping, causing authorization checks to be silently skipped when users subscribe to these channels for arbitrary object IDs. This is confirmed as an incomplete remediation of CVE-2020-10698, affecting Red Hat Ansible Automation Platform 2. No public exploit or CISA KEV listing is identified at time of analysis.
Server-Side Request Forgery in AWX's GitHub webhook integration (Red Hat Ansible Automation Platform 2) enables a remote attacker possessing a job template's webhook_key to redirect PAT-bearing status callbacks to an attacker-controlled endpoint, exfiltrating the configured GitHub Personal Access Token. The attack exploits AWX's failure to validate that the pull_request.statuses_url field in an incoming webhook payload points to a legitimate GitHub API domain before using it as a POST target. No public exploit is identified at time of analysis, but successful exploitation yields persistent GitHub repository access through the stolen PAT, extending the blast radius well beyond the AWX system itself.
Insufficient OAuth token invalidation in Ansible Lightspeed (part of Red Hat Ansible Automation Platform 2.x) allows a remote attacker who has exfiltrated a valid access token to maintain persistent authenticated sessions even after the legitimate user has logged out. The backend fails to revoke the token server-side on logout, leaving it exploitable until natural expiration. Successful exploitation enables unauthorized read access to sensitive Ansible resources - including inventories, playbooks, and configuration data - with no public exploit or CISA KEV listing identified at time of analysis.
Path traversal in awxkit's YAML !include directive exposes arbitrary local files when a user imports a crafted YAML file via the AWX CLI. Affecting Red Hat Ansible Automation Platform 2, the vulnerability (CWE-22) allows an unauthenticated attacker who can deliver a malicious YAML file to a victim to read arbitrary YAML-formatted files from that user's local filesystem - including potentially sensitive configuration, credential, or key material files - without any write or execution capability. No public exploit identified at time of analysis; CVSS 4.7 reflects the real-world constraints of local attack vector, high complexity, and mandatory user interaction.
Log injection vulnerability in Red Hat Ansible Automation Platform 2 MCP server allows unauthenticated remote attackers to inject control characters and ANSI escape sequences via the `toolsetroute` parameter, enabling log forgery and obscuring legitimate audit trails to facilitate social engineering attacks that trick operators into executing malicious commands or accessing attacker-controlled URLs. CVSS 5.3 (medium) reflects the integrity impact on logs without direct confidentiality or availability impact; exploitation requires no authentication, credentials, or user interaction. No public exploit code or active exploitation has been identified at time of analysis.
Container privilege escalation in Red Hat Ansible Automation Platform 2 allows non-root users within affected container images to gain root privileges by modifying the group-writable /etc/passwd file. During the container build process, /etc/passwd is created with overly permissive group-write permissions, enabling any user in the root group to add arbitrary entries including a UID 0 account. This vulnerability requires local container execution access and elevated group membership, but results in complete container compromise when exploited.