Headline grabbing vulnerabilities, like SolarWinds and Log4Shell, target management software and end hosts, but if you search for “most exploited vulnerabilities” on Google, you will quickly learn that some of them directly target network and security devices as well as server load balancers. These are the 3 most exploited CVEs in the last couple of years: Would you be surprised to learn that network device operating systems can be vulnerable to security flaws like any other software?

As your development and security teams grow, it becomes critical that each of your team members using Snyk has only the required permissions to do their job. You need to ensure everyone can perform their jobs with ease, while also avoiding security and compliance issues. A developer, for example, needs the ability to find and fix vulnerabilities in his code but should not be able to change Snyk billing details.

From day one, Snyk’s vision has been to enable development and security teams across the world to develop fast while staying secure. A key component of this vision is ensuring our customers feel confident in using our developer security platform. This is why we place the utmost importance on keeping our customers’ data safe and helping them address their security and compliance requirements.

This past March we posted an analysis of a vulnerability in the Apache HTTP Server mod_sed filter module, CVE-2022-23943, in which a Denial of Service (DoS) can be triggered due to a miscalculation of buffers’ sizes. While analyzing this Apache httpd vulnerability and its patch, we suspected that although the fix resolved the issue, it created a new unwanted behavior. Our suspicion turned out to be true: we discovered that another way to cause a DoS was introduced.

CrowdStrike Services recently investigated a suspected ransomware intrusion attempt. The intrusion was quickly stopped through the customer’s efforts and those of the CrowdStrike Falcon Complete™ managed detection and response (MDR) team, which was supporting this customer’s environment.

For application security, the shift left strategy is something that every enterprise is embracing today, which essentially means putting the security controls in earlier stages of development. This is more like a “nipping the problem in the bud” strategy where the security controls in their respective domains highlight the potential security weaknesses related to vulnerabilities in code, vulnerabilities in third-party packages and code quality issues.

In a recent report by the incident response giant Mandiant, which was purchased by Google in March, their researchers found that 2021 was a record year for the total number of 0-day vulnerabilities disclosed and exploited. According to their findings, their team identified some 80 0-days exploited in the wild. At the same time, Google Project Zero researchers reported the detection and disclosure of 58 0-days.

Snyk Ambassadors are passionate about sharing their security expertise. Become one today by signing up! In the shipping industry, the container format follows ISO 668, a standard format that regulates the safe stacking of containers. Imagine your applications with multiple containers, running different applications, serving different purposes for people all over the world.

It has been 10 years since Project Basecamp, a research project conducted by Digital Bond that investigated how critical operational technology (OT) devices and protocols were, to use the term they coined, “insecure by design.” Since then, we have seen hugely impactful real-world OT malware such as Industroyer, TRITON, Industroyer2 and INCONTROLLER abusing insecure-by-design functionality.

While studying for my master's degree in cyber security, I co-authored a paper regarding the rollout of IoT devices and the security considerations that businesses need to address to ensure these devices are secure. The paper underscored how a large majority of IoT devices used vulnerable components and did not follow basic secure programming principles.

Open source software is a key component in modern applications. It has created a new era in software development, promoting a free exchange of ideas within the developer community and enabling developers to build more functional software, faster than ever. Based on most estimates, 70-90% of any piece of modern software includes open source code.

I want to take some time to explain the importance of using a white-box approach when testing applications for vulnerabilities. To help in this endeavor, I will use a real-world example to demonstrate how researchers (in this case Karim El Ouerghemmi and Simon Scannell) *may* have found a vulnerability in WordPress (CVE-2022-21662 a 2nd order stored XSS) and how you, as a security researcher, can also use a white-box approach to find an exotic XSS vulnerability.

Two packages of well-known origin were found exfiltrating Windows SAM and SYSTEM files, apparently as part of internal security research rather than a targeted dependency confusion attack. On June 6th, 2022, the Mend research team used Supply Chain Defender to detect and flag two malicious packages from the same author that contained identical code. We alerted npm and the packages were removed within three hours of publication.

A few weeks ago, a new version for Fastjson was released (1.2.83) which contains a fix for a security vulnerability that allegedly allows an attacker to execute code on a remote machine. According to several publications, this vulnerability allows an attacker to bypass the “AutoTypeCheck” mechanism in Fastjson and achieve remote code execution. This Fastjson vulnerability only recently received a CVE identifier – CVE-2022-25845, and a high CVSS – 8.1.

The recently discovered Windows zero-day vulnerability continues to make news as threat actors across the globe are relentless in their efforts to exploit it. The vulnerability, dubbed Follina, can be exploited when the Microsoft Support Diagnostic Tool (MSDT) is called by a Microsoft Office application using the URL protocol.

In recent years more open source vulnerabilities have been discovered than ever before. This is all part of the natural evolution; it’s what we expect to see as the amount of open source usage grows within organizations. But there’s something that we missed in this equation: while identifying vulnerabilities, organizations haven’t found a way to block unwanted dependencies, which made them vulnerable to attacks like never before.

A zero-day vulnerability has been re-disclosed that is very similar to the Follina zero-day announced last week and is actively being tracked by Trustwave SpiderLabs. The vulnerability was initially publicly disclosed back in 2020 but dismissed by Microsoft, which replied at the time: "We are also always seeking to improve these protections.

The JFrog Security Research team is constantly looking for new and previously unknown software vulnerabilities in popular open-source projects to help improve their security posture. As part of this effort, we recently discovered a denial of service (DoS) vulnerability in Envoy Proxy, a widely used open-source edge and service proxy server, designed for cloud-native applications and high traffic websites.

This article provides a synopsis of the Follina exploit and simple steps you can take to mitigate this severe remote code execution vulnerability within Microsoft Support Diagnostic Tool (MSDT). This vulnerability is triggered via common Windows applications such as Microsoft Word and is being actively exploited by known hacking groups.

On May 31, 2022, a critical vulnerability in Atlassian Confluence Server and Confluence Data Center was disclosed by Volexity. While conducting an incident response investigation involving internet-facing servers with the Confluence server installed, Volexity determined that the servers were compromised and attackers were launching successful remote code execution (RCE) exploits.

Recently, Atlassian issued a major security notice to all of its users about a critical vulnerability, identified as CVE-2022-26134, in its widely-used Confluence Server solution. The vulnerability would allow an unauthenticated malicious actor to execute arbitrary code on a Confluence Server or Data Center instance that could grant an attacker full command of the vulnerable server.

Great things happen when the academic world and the software industry work together! Today, we’d like to share a story about our recent collaboration with the CISPA Helmholtz Center for Information Security, a big science institution in Germany. Back in January, Cris Staicu Ph.D. (Tenure-Track Faculty, CISPA), contacted us about his research on NodeJS and JavaScript.

A new zero day vulnerability actively exploited in the wild has been found in Atlassian Confluence. The vulnerability CVE-2022-26134 affects all supported versions of Confluence Server and Confluence Data Center allowing an unauthenticated user to run arbitrary commands remotely. The Atlassian team confirmed the vulnerability with an official tweet and then also published a security advisory to update its customers.

If you want just to see how to find evidence of the Atlassian vulnerability in your Confluence systems, skip down to the “detections” sections. Otherwise, read on for a quick breakdown of what happened, how to detect it, and MITRE ATT&CK mappings.

Trustwave SpiderLabs is tracking the critical-rated zero-day vulnerability CVE-2022-26134. Threat actors are reported to be actively exploiting this vulnerability in the wild. Atlassian disclosed and issued guidance for CVE-2022-26134 on June 2. Trustwave is diligently watching over our clients for exposure and associated attacks and working closely with our clients to ensure that mitigations are in place.

Trustwave SpiderLabs is tracking the critical-rated zero-day vulnerability CVE-2022-30190. Threat actors are reported to be actively exploiting this vulnerability in the wild. Microsoft disclosed and issued guidance for CVE-2022-30190 on May 30. Trustwave is diligently watching over our clients for exposure and associated attacks and working closely with our clients to ensure that mitigations are in place.

Follina—while we’re sure this commune in Italy is lovely, the same can’t be said about this new vulnerability by the same name for InfoSec folks. Thanks to a zero-day bug in the Microsoft Support Diagnostic Tool, Follina is now making the headlines but for all the wrong reasons. This blog talks in detail about the zero-day vulnerability in Microsoft Support Diagnostic Tool (MSDT), popularly known as Follina.

CVE-2022-30190, aka Follina, was published by @nao_sec on Twitter on May 27, 2022 — the start of Memorial Day weekend in the U.S. — highlighting once again the need for round-the-clock cybersecurity coverage. Threat hunting in particular is critical in these instances, as it provides organizations with the surge support needed to combat adversaries and thwart their objectives.

On May 27, 2022, the nao_sec independent security research group shared a VirusTotal link to a weaponized Microsoft Office document revealing a previously unknown vulnerability in the Microsoft Support Diagnostic Tool (MSDT). This vulnerability is most likely to be exploited via phishing lure attachments and is triggered when a document is opened.

Cybersecurity awareness, protection, and prevention is all-encompassing. In addition to implementing the right tools and resources, and hiring skilled professionals with the right cybersecurity education and experience, organizations should be aware of the latest CVEs.

On May 27, 2022, a Microsoft Office document was submitted from Belarus to VirusTotal, using a novel method to deliver its payload. This new technique was identified as a Zero-Day RCE (Remote Code Execution) vulnerability in Microsoft Support Diagnostic Tool (MSDT), which is now being tracked as CVE-2022-30190. As of this writing, it affects only Windows computers running with MSDT URI protocol enabled.