PyYAML@5.1 is highly vulnerable

[spinningrachel]

Affected versions of this package are vulnerable to Arbitrary Code Execution. It processes untrusted YAML files through the full_load method or with the FullLoader loader. This is due to an incomplete fix for CVE-2020-1747

Affected versions of this package are vulnerable to Improper Access Control. It has insufficient restrictions on the load and load_all functions because of a class deserialization issue, e.g., Popen is a class in the subprocess module.

Remediation: Pin PyYAML to version 5.4

https://app.snyk.io/vuln/SNYK-PYTHON-PYYAML-590151

https://app.snyk.io/vuln/SNYK-PYTHON-PYYAML-550022

[waylan]

As explained previously, I'm not sure why this should matter to MkDocs. MkDocs is only ever run from the command line. If anyone can get arbitrary code to run from a MkDocs build, then there are much bigger issues. Presumably that person could just run the commands themselves rather than embedding the calls in a YAML file.

[BetterThanReal]

As explained previously, I'm not sure why this should matter to MkDocs. MkDocs is only ever run from the command line. If anyone can get arbitrary code to run from a MkDocs build, then there are much bigger issues. Presumably that person could just run the commands themselves rather than embedding the calls in a YAML file.

Continuous Integration environments are often setup to allow code contributions from members outside of an organization. Allowing people to cause CI environments to mine crypto-currency, for example, just by including a malicious YML file within their own development branch of a repository, seems like just exactly the type of thing that is contributing to the glut of free services being overrun with crypto-miners presently.

[facelessuser]

Continuous Integration environments are often setup to allow code contributions from members outside of an organization. Allowing people to cause CI environments to mine crypto-currency, for example, just by including a malicious YML file within their own development branch of a repository, seems like just exactly the type of thing that is contributing to the glut of free services being overrun with crypto-miners presently.

People can alter any project to abuse a CI in a plethora of ways. What MkDocs does with YAML isn't going to make a bit of difference. CI environments need to figure out how to protect themselves moving forward. Whatever that answer is, it will have nothing to do with what version of PyYAML MkDocs uses.

With all of that said, I don't know if it hurts us to pin the minimum PyYAML to at least 5.4 which fixes recent security concerns, but considering that it would require someone to alter your mkdocs.yml to do something malicious, which in turn requires them to have access to your repo, you aren't really protected anyways. People could just change the dependency to some version prior to 5.4 and then do whatever they want 🤷🏻.

So, again, I'm not sure how this affects us.

[waylan]

If someone can edit the YAML file on my repo so that it runs bad code on a CI server, then they can also edit the code in my repo so that it runs bad code on the CI server. Having secure YAML offers no security whatsoever in that scenario.