Details
-
Bug
-
Status: Closed (View Workflow)
-
Critical
-
Resolution: Fixed
-
13.0
-
Can result in unexpected behaviour
-
The wsrep_notify_cmd functionality was susceptible to a parameter-injection vulnerability, as it failed to validate the peer-supplied wsrep_node_name and wsrep_node_incoming_address values before interpolating them into the notification command line.
-
Q2/2026 Replic. Development, Q3/2026 Replic. Maintenance
Description
Issue:
wsrep_notify_status() interpolates members[i].name() (peer's
wsrep_node_name) and members[i].incoming() verbatim into a command
string executed via 'sh -c'. A peer joining with shell metacharacters
in either field can inject arbitrary commands on every cluster member
that has wsrep_notify_cmd configured. Same threat class as
MDEV-39413/MDEV-39648 for SST, but the notify path was not covered.
Solution:
Validate both fields before substitution; reject values containing
shell-significant characters and skip the notification, mirroring
safe() in scripts/wsrep_sst_common.sh.
Reported by letchu_pkt
Attachments
Issue Links
- relates to
-
MDEV-39413 wsrep unsafe handling of parameters
-
- Closed
-
-
MDEV-39648 wsrep_sst_rsync.sh: apply safe() to joiner-supplied parameters
-
- Closed
-
-
MDEV-39676 Galera Cluster-peer > Donor command execution
-
- Closed
-
- links to