Though in reality, I disagree with the premise of CVE-2017-18342 altogether. The pyyaml documentation always made it quite clear that the load() function was not safe for use with untrusted inputs and offered a safe_load() alternative which lacked the ability to evaluate arbitrary Python expressions. The vulnerability was not within pyyaml, but in the individual projects which chose to use it in clearly unsafe ways (and I do not think the uses of load() by oslo.config were patently unsafe). The pyyaml maintainers have chosen to make a non-backward-compatible change to load() so that it's synonymous with safe_load(), which strikes me as a reasonable decision, but that doesn't mean that all uses of the old version are instantly a liability.
Yes, this isn't an OpenStack vulnerability, the VMT is considering it a class C2 report (A vulnerability, but not in OpenStack supported code, e.g., in a dependency): https:/ /security. openstack. org/vmt- process. html#incident- report- taxonomy
Though in reality, I disagree with the premise of CVE-2017-18342 altogether. The pyyaml documentation always made it quite clear that the load() function was not safe for use with untrusted inputs and offered a safe_load() alternative which lacked the ability to evaluate arbitrary Python expressions. The vulnerability was not within pyyaml, but in the individual projects which chose to use it in clearly unsafe ways (and I do not think the uses of load() by oslo.config were patently unsafe). The pyyaml maintainers have chosen to make a non-backward- compatible change to load() so that it's synonymous with safe_load(), which strikes me as a reasonable decision, but that doesn't mean that all uses of the old version are instantly a liability.