A stored cross-site scripting vulnerability, tracked as CVE-2021-45919, was identified in elFinder File Manager. The vulnerability can result in the theft of user credentials, tokens, and the ability to execute malicious JavaScript in the user's browser. Any organization utilizing an out-of-date elFinder component on its web application could be affected.
Recently, a critical out-of-bounds vulnerability, assigned to CVE-2021-44142, was disclosed in Samba versions prior to 4.13.17. The Samba vulnerability carries a critical CVSS of 9.9 and allows attackers to remotely execute code on machines running a Samba server with a vulnerable configuration. The vulnerability was disclosed as part of the Pwn2Own Austin competition where researchers are challenged to exploit widely-used software and devices with unknown vulnerabilities.
What happens when the software, scripts and code snippets that your business uses on your website and network have been compromised at the source? The compromise could be unintentional—perhaps the coders simply made a mistake. Or the compromise could be intentional—maybe hackers wrote a malicious script and promoted it as legitimate on a third-party library source to encourage users to download and install.
Researcher Moshe Zioni from Apiiro, discovered a major software supply chain critical vulnerability - CVE-2022-24348 - in the popular open-source CD platform Argo CD. Exploiting it enables attackers to obtain sensitive information like credentials, secrets, API keys from other applications. This in turn can lead to privilege escalation, lateral movements, and information disclosure.
Protecting cloud workloads from zero-day vulnerabilities like Log4Shell is a challenge that every organization faces. When a vulnerability is published, organizations can try to identify impacted artifacts through software composition analysis, but even if they’re able to identify all impacted areas, the patching process can be cumbersome and time-consuming. As we saw with Log4Shell, this can become even more complicated when the vulnerability is nearly ubiquitous.
We’re almost two months from the disclosure of Log4Shell, and we here at Snyk couldn’t be more excited with the role we’ve gotten to play in finding and fixing this critical vulnerability that’s impacted so many Java shops. For starters, we’ve been able to help our customers remediate Log4Shell 100x faster than the industry average! How have we been able to achieve that?
