Bug 2547374 (CVE-2026-107152) - CVE-2026-107152 rubygem-smart_proxy_dynflow: Dynflow console authorizes any client certificate the capsule CA signed
Summary: CVE-2026-107152 rubygem-smart_proxy_dynflow: Dynflow console authorizes any c...
Keywords:
Status: NEW
Alias: CVE-2026-107152
Deadline: 2026-12-15
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
high
high
Target Milestone: ---
Assignee: Product Security
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2026-10-07 10:33 UTC by OSIDB Bzimport
Modified: 2026-11-12 18:47 UTC (History)
17 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed:
Embargoed:


Attachments (Terms of Use)

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.


Note You need to log in before you can comment on or make changes to this bug.