CVE-2026-107151: Rubygem-smart_proxy_dynflow: task update and done callbacks accept unauthenticated requests
Missing authentication has been found in remote-execution task updates in the smartproxydynflow package. The progress and completion callbacks accept a report when the one-time token is missing. A network attacker or user must already know the identifier of a running job. This applies when remote execution is set to pull or pull-mqtt mode. They can send their own job output and mark the job as a success or a failure. The job is then recorded with that result.
Other sources
Proxy::Dynflow::Api selects authorizewithtoken from the path alone. If the Authorization header is absent, that method returns false and does not halt. A Sinatra before filter ignores the return value, so POST /dynflow/tasks/<uuid>/update and /done reach dispatchexternalevent. A second bypass sits in the same check: OtpManager.authenticate treats a Basic token with no colon as otp = nil, and passwords[username] == nil is true when that task has no stored OTP. generateotp has no production caller on current smartproxyremoteexecutionssh 1.0.x. On 0.11.x it is called only by PollingScriptRunner, and only in async-SSH mode. Omitting the header still bypasses that case.
This does not launch jobs. In the default :ssh mode, Runner::Base#externalevent refreshes and drops the payload. In :pull and :'pull-mqtt', PullScript#processexternalevent stores the caller’s output and exitcode, and exit code 0 is recorded as success.
On Satellite 6.16–6.18, async-SSH PollingScriptRunner#externalevent can also apply the payload when manualmode is set. That runner was removed in smartproxyremoteexecutionssh 1.0.0 (commit d8d1811, 2025-11-28).
The attacker must already know a live execution-plan UUID. Step ids are small integers. The console flaw below is what gives those UUIDs to a host that holds a CA-signed certificate.
Likely to be introduced in smartproxydynflow 0.4.0 by commit e205e19.
— Red Hat
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
smart_proxy_remote_execution_sshto a version that resolves this vulnerability.Fixed in 1.0.0