No smoke without fire? ‘Critical’ Loguru security flaw turns out to be non-issue

Invalid CVE saga highlights potential problems in the automated vulnerability alert process

GitHub has promised to stop sending out advisories about a vulnerability reported in Loguru, a popular Python logging package, which later turned out to be invalid.

Last week, the DevOps platform started notifying tens of thousands of users about what was claimed to be a critical remote code execution vulnerability in Loguru that was designated as CVE-2022-0329 and given a critical rating of 9.8/10.

However, it has since emerged that the reported issue isn’t a valid vulnerability after all.

RECOMMENDED Vulnerability in PostBus public transport platform exposed customer data

The story began when a researcher reported untrusted loading of data by Loguru’s function – which serializes and deserializes arbitrary Python objects – leading to arbitrary code execution. He suggested that the issue had similarities to the notorious Log4Shell exploit.

However, the maintainer disputed this on the grounds that the offending method did not form part of the Loguru public API, and that Pickle was only used to serialize objects already loaded in the code – meaning that there was only a problem if the loaded data didn’t come from a trusted source.

“The user receiving untrusted data should be responsible for sanitizing it before processing it. We can’t expect this job to be done by the third-library, otherwise there might be infinite way to execute arbitrary code,” they said.

“This has little to do with the pickle module. Loguru isn’t fetching and executing arbitrary code by itself.”

However, after a lengthy discussion, the maintainer was pressured into action. A CVE was issued and posted on GitHub, which then started sending out automatic alerts via its Dependabot service.

Undeserved credence

Now, though, GitHub has reviewed the issue, and says it will stop sending out the warnings.

“We don’t currently have a way to retract the Dependabot alerts we’ve already sent, but I've asked the team to look into functionality to do that in future,” says Justin Hutchings, director of product management at GitHub.

Read more of the latest GitHub security news

“I’ve also asked them to look into adding a clear way to display CVEs in the GitHub Advisory Database that we have chosen not to alert on (even if they have not been withdrawn from the National Vulnerability Database).”

The issue highlights just how easy it can be for a false or disputed report to be given undeserved credence, and Hutchings says he plans to involve the GitHub Security Lab in finding solutions.

“I’d like us (GitHub) to learn from the above and improve our security-related features and processes to help more when a maintainer receives a security report,” he says.

YOU MIGHT ALSO LIKE Xerox belatedly addresses web-based printer bricking threat