| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Unauthenticated Broken Access Control in AppMySite <= 3.15.4 versions. |
| Contributor Cross Site Scripting (XSS) in The Post Grid <= 7.9.5 versions. |
| Subscriber Broken Access Control in Fluent Support <= 2.3.2 versions. |
| Contributor Cross Site Scripting (XSS) in Podcast Importer SecondLine <= 1.5.6 versions. |
| Unauthenticated Broken Access Control in Online Booking & Scheduling Calendar for WordPress by vcita <= 4.6.0 versions. |
| Unauthenticated Bypass Vulnerability in Netgsm <= 2.10.0 versions. |
| Subscriber Arbitrary File Deletion in WP User Frontend <= 4.3.11 versions. |
| The Import and export users and customers plugin for WordPress is vulnerable to Privilege Escalation in all versions up to, and including, 2.4.17 via the plugin's own export and re-import workflow. The vulnerability exists because the exporter writes CSV cells using fputcsv() with a NUL byte (\0) as the escape character, while the importer parses the same file using SplFileObject::fgetcsv() with only a single delimiter argument, causing PHP's default backslash escape character to be applied instead; because the export column layout places display_name immediately before the role column and nickname immediately after, an attacker can store crafted values in those two profile fields — saved by WordPress core via the standard profile page — such that the escape mismatch causes the parser to merge the display_name cell into the role field and rebalance the column count via nickname, yielding administrator as the parsed role for their own row when it reaches the import_user function's add_role function. This makes it possible for authenticated attackers with Subscriber-level access or above to escalate their privileges to Administrator. Exploitation requires a site administrator to trigger the plugin's documented export re-import migration with both "Update existing users" and "Update roles for existing users" set to "yes". |
| A vulnerability was identified in Fast FAC1900R 20190827_2.0.2. The impacted element is the function get_alias_name of the component uhttpd. Such manipulation leads to stack-based buffer overflow. The attack may be performed from remote. The exploit is publicly available and might be used. The vendor was contacted early about this disclosure but did not respond in any way. |
| RunAdHocCommand.build_args() appends limit as bare
positional (args.append(limit)) instead of using
args.extend(['-l', limit]) like RunJob. A limit beginning
with - is parsed as an ansible CLI option. Currently
limited to short-circuit flags (--version, --help) since
injected element displaces required pattern positional.
Would escalate if ansible-core ever defaults pattern. |
| LaunchConfigurationBaseSerializer.scm_branch has no
validate_scm_branch() leading-dash check, unlike
Project/JobTemplate/JobLaunch serializers. Schedule and
WFJT Node accept --upload-pack=/bin/id as scm_branch.
Currently blocked at runtime by jobs.py:1502 ValueError
check (defense-in-depth), but the API validation gap
means sole reliance on a task-layer guard. Refactoring
that guard away would promote this to RCE. |
| Notification template Jinja AST whitelist only inspects
static Getattr nodes. Dynamic subscripts (job['job'+'_env'])
and {% if job.id > 100 %} conditional gating bypass both
the AST check and the test-render (stub has small job.id).
At runtime, the gated branch executes and exceptions write
full tracebacks into notification body, which is POSTed
to attacker-controlled webhook URL. Leaks install paths,
Python version, source line numbers. |
| A flaw was found in the Ansible Automation Platform automation-controller. When a
WorkflowJobTemplate is copied, the deep-copy permission sanitizer validates only the inventory,
unified_job_template, and credentials of each cloned node and fails to check the instance_groups
(and execution_environment and labels) that were preserved from the original. A user with
organization workflow-admin permission but no role on the referenced instance groups can copy a
workflow, become its administrator, and launch jobs pinned to instance groups they are not
authorized to use — including the control-plane instance group — bypassing the InstanceGroup
use_role boundary and causing attacker-influenced automation to run in the control-plane
execution context. |
| A flaw was found in the automation-controller input-validation
guard sanitize_jinja(). The function uses two regular
expressions to reject user-supplied Jinja, but the patterns
stop at the first interior '}' or '%' character, so a Jinja
expression containing an inner brace (for example an empty
dict) is accepted while remaining valid Jinja. Because
sanitize_jinja() is the sole guard on several launch-time
fields — ad-hoc command module_args, Machine-credential
username / become_method / become_user, and inventory host
names — a low-privileged user can inject Jinja that ansible-core
evaluates in the execution environment. This enables execution
of arbitrary commands in the execution environment (bypassing an
administrator's AD_HOC_COMMANDS module allowlist) and disclosure
of secrets belonging to credentials the attacker cannot read
(by templating a co-attached credential's injected environment
variables), across the credential access-control boundary. |
| A flaw was found in Ansible Automation Platform's automation-controller. The custom
Credential Type environment-variable injector validates variable names against a
deny-list (an ANSIBLE_* prefix check plus a fixed ENV_BLOCKLIST) that omits
process-hijacking loader variables such as BASH_ENV, ENV, LD_PRELOAD, LD_LIBRARY_PATH,
PYTHONSTARTUP and GIT_SSH_COMMAND. Combined with the credential file injector, a
privileged user can write an attacker-controlled script into the execution environment
and point BASH_ENV at it, obtaining arbitrary code execution inside the
execution-environment container for any job that attaches a credential of that type. |
| A flaw was found in Red Hat Ansible Automation Platform's automation-
controller. The setting that formats the log message emitted for API 4XX errors
is an administrator-controlled Python format-string template that is rendered
with a live user object as an argument. Because Python string formatting permits
attribute and item traversal on its arguments, an administrator can craft a
template that walks from the user object into the application settings and reads
the Django secret key and the database password. The formatted message is written
to a logger that can be forwarded to an external log aggregator, whose destination
is also administrator-controlled, allowing the secrets to be sent off the host. An
authenticated administrator can thereby obtain the master encryption key used to
protect all stored credentials and the database service password, enabling offline
decryption of every stored credential, forgery of user sessions, and direct
access to the controller database. |
| A flaw was found in Red Hat Ansible Automation Platform's automation-
controller. The HTML view of job, ad hoc command, project update, and inventory
update standard output escapes HTML metacharacters but does not remove ANSI
terminal escape sequences before conversion to HTML. An ANSI OSC 8 hyperlink
sequence in the output is expanded into an HTML anchor whose href is not scheme-
filtered or escaped, so a low-privileged user who can produce output -- or an
external party whose data a playbook echoes -- can embed a javascript: link that
is rendered into a text/html response with no Content-Security-Policy. When a
higher-privileged user views the output page and clicks the link, attacker-
controlled JavaScript executes in their authenticated session, allowing actions
as that user up to full platform takeover. |
| A flaw was found in Red Hat Ansible Automation Platform's automation-
controller. The Project scm_url field is not validated against values that
begin with a dash and is stored and passed verbatim to the git SCM module.
Because the module runs git ls-remote with the URL as a positional argument and
without a "--" separator, a git project URL such as "--upload-pack=<command>:x"
is interpreted by git as the --upload-pack option and executed via a shell. A
user with permission to create or modify a project in a single organization can
thereby execute arbitrary commands on the control-plane task pod, with output
reflected through the project update stdout endpoint, leading to cross-tenant
compromise and in-cluster lateral movement |
| A flaw was found in Red Hat Ansible Automation Platform's automation-
controller. Four debug views that trigger the internal task, dependency, and
workflow schedulers are configured to allow any user (including unauthenticated
clients) and are routed in production builds because their URL include is not
gated on the debug setting. An unauthenticated remote attacker can repeatedly
invoke these endpoints to acquire the cluster-wide scheduler advisory lock;
because the legitimate scheduler acquires the same lock without waiting, the
attacker causes real scheduler runs to be skipped, stalling job dispatch for
all tenants, while also consuming controller web workers. The debug root view
additionally discloses the list of debug endpoints to unauthenticated callers. |
| A flaw was found in Red Hat Ansible Automation Platform's automation-
controller. The provisioning-callback secret (host_config_key) is exposed to
users holding only the read-level view_jobtemplate permission -- both in the
job template API representation and in the activity stream -- and the
provisioning callback endpoint trusts a client-supplied X-Forwarded-For
header to determine the calling host when the controller is deployed behind
the AAP gateway with an empty proxy allow-list. By reading the secret and
spoofing X-Forwarded-For to match any host in the job template's inventory, a
minimally privileged or unauthenticated remote attacker can launch the job
template against arbitrary managed hosts using the job template's credentials,
resulting in privilege escalation and remote code execution on managed hosts. |
