Bug 2547374 (CVE-2026-107152)

Summary:	CVE-2026-107152 rubygem-smart_proxy_dynflow: Dynflow console authorizes any client certificate the capsule CA signed
Product:	[Other] Security Response	Reporter:	OSIDB Bzimport <bzimport>
Component:	vulnerability	Assignee:	Product Security <prodsec-ir-bot>
Status:	NEW ---	QA Contact:
Severity:	high	Docs Contact:
Priority:	high
Version:	unspecified	CC:	anthomas, ehelms, ggainey, jpasqual, juwatts, lblicha, mdellweg, mhulan, nmoumoul, ogajduse, osousa, pcreech, rchan, security-response-team, smallamp, tmalecek, zhunting
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	---
Doc Text:	An improper authentication vulnerability has been found in the task console in the smart_proxy_dynflow package. The console accepts any client certificate signed by the capsule's certificate authority. It does not check the list of servers the capsule trusts. A low-privileged network attacker or user must already hold such a certificate. They can open the console and read job details. Those details include passwords when a job was given them. They can also cancel a running task.	Story Points:	---
Clone Of:		Environment:
Last Closed:		Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Deadline:	2026-12-15

Description OSIDB Bzimport 2026-10-07 10:33:38 UTC

Proxy::Dynflow::Core.web_console mounts the Dynflow web console at /dynflow/console and, when console_auth is true (the default), calls do_authorize_with_ssl_client only. That helper rejects an empty SSL_CLIENT_CERT and does not compare the certificate subject with trusted_hosts or the certificate serial with accepted_cert_serial. The serial is still computed in Core#initialize, with a comment that only the proxy’s own certificate should be trusted, and nothing reads it.

Before the merge, smart_proxy_dynflow_core’s authorize_with_ssl_client halted unless the client serial matched the proxy certificate (added in commit 444cc84, Ivan Necas, 2016-06-20, “to avoid being able to use any valid certificate”). Commit e205e19 (2021-06-03) switched the console to the proxy-wide helper and dropped that comparison. First release carrying the drop is 0.4.0. The installer text for console_auth says it enables trusted hosts and SSL. The code does not check trusted hosts.

The console is the Dynflow 2.x web UI (dynflow >= 1.6, < 3). Its index lists every execution plan. The step view runs YAML.dump on action input and output with no redaction. A remote-execution action input includes the script, hostname, effective user, and the secrets hash (ssh_password, key_passphrase, effective_user_password) when those are set. The same before filter covers POST /:id/resume, POST /:id/cancel, POST /:id/skip/:step_id, and POST /:id/cancel/:step_id. Resume requires a paused plan. Skip requires a paused plan and a failed step. Cancel works when the plan or step is cancellable.

The proxy listens with SSLVerifyClient = VERIFY_PEER and without FAIL_IF_NO_PEER_CERT, so a missing certificate still completes the handshake and then fails this check. A presented certificate must chain to ssl_ca_file. On Satellite that file is the Katello CA, which also issues content-host consumer certificates, so a registered host that is not in trusted_hosts passes. console_auth: false removes the check. The dynflow plugin listens on HTTPS by default. The proxy HTTP port is off by default (foreman_proxy::http defaults to false). If HTTP is enabled, this SSL check does not run.

Current puppet default for the dynflow database is in-memory. Plans remain until the execution-plan cleaner (default 30 minutes) or a proxy restart. Secrets of in-flight and recent jobs are in the console during that window.