REDHAT-BUG-2547357: Medium severity Red Hat smart_proxy_dynflow vulnerability
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.