Update June 17 at 11:15 am ET - the security researcher has deleted the blog post. To not cause confusion, we've removed the link from the text below as well.
On June 11, a cyber security analyst published a blog post alleging that he had discovered a vulnerability in Nexus Repository OSS 3.37.3-02.
Unfortunately, this was the first time Sonatype had heard of it. Instead of following a responsible disclosure process and contacting us with his findings, the analyst went public without any advance notification or mutual verification.
Fortunately CVE-2022-31289 is not a real vulnerability. Repository’s security features are not breached, and there is no exploit potential. You do not need to apply an update.
We are taking steps to dispute the CVE, and publishing this post to explore the alleged vulnerability in depth.
The “Self-Deception” Exploit
The reproduction steps for CVE-2022-31289, according to the analyst, are as follows:
- Set up Burp Suite to monitor traffic between the Repository UI and the Repository server.
- Attempt to log in via the Repository UI using bad credentials, which causes a REST call from the UI layer to the server.
- Use Burp Suite to intercept the “HTTP 403 Forbidden” response from the server, and modify it to an HTTP 200 OK response.
The user interface will now think the user has been authenticated. Since the Repository UI is a single-page app, it now displays the “logged in” as a UI state. The analyst erroneously concludes, “BOOM! I was logged in as admin.”
But actually, no breach has occurred. The UI has been put in an invalid state by manipulating the HTTP traffic, but the Repository server does not rely on client-side validation: it authenticates every REST operation on the server side.
Any subsequent request the UI now makes to display privileged information will fail, because the user’s session isn’t authenticated. The only path forward is a steady stream of errors as the UI layer fails over and over again to render anything properly. This is neither a vulnerability nor a UI bug. You can see this behavior in the screenshot shared in the analyst’s blog post - presenting an empty page instead of our usual landing page.
As attack vectors go, this one is entirely self-deception. It’s like standing outside the security perimeter and planting a sign on the lawn saying, “I’m in your base!” The appearance of a successful attack is sometimes nothing more—and in this case the supposed exploit is no deeper than this.
How It Should Have Gone
This type of misunderstanding is familiar to us as producers of primary security research on countless open source projects. Just two weeks ago, another security researcher contacted us with an almost identical claim of vulnerability. Because that researcher followed a responsible disclosure process, we were able to explore the apparent vulnerability together and come to a shared understanding that there was no actual problem.
By skipping the notification step, the analyst's disclosure risked giving real attackers the information they need to exploit a widely used application, should a vulnerability have existed. Nexus Repository is used by millions of developers around the world, and a zero-day vulnerability would be cause for real alarm. With proper notification and a delay before public disclosure, we are able to fix any vulnerabilities that do actually come up, protecting our customers and users.
As stated on our contact page, security issues should be reported via email to firstname.lastname@example.org to ensure they are brought to our immediate attention. Our PGP key is also provided on the page for researchers sharing sensitive information.
Cowboying it doesn’t make software safer, it’s just arming bad actors.
The Total Cost of False Alarms
Vulnerability reports are never good news, but dealing with vulnerabilities in code and dependencies is an inevitable part of delivering software. We don’t refute vulnerability reports lightly.
In the case of CVE-2022-31289 there’s no actual vulnerability or bug, but we have already seen the impact of undue alarm among our customers as they react to the news and make preparations to protect their infrastructure. This distracts everyone from the real work of keeping software safe.
* * *
At Sonatype, our mission is to empower every engineering team with intelligence to create and maintain secure, quality and innovative software at scale. With vulnerabilities and supply chain attacks on the rise, staying secure without slowing down requires tools and processes that scale to meet the threat. If you’re passionate about helping developers go quickly and safely, consider joining our team.