Famous Software and Server Vulnerabilities and the Lessons They Taught Us

Famous software vulnerabilities are publicly disclosed security flaws in widely used components — such as Apache Log4j, Windows SMBv1, and the Spring Framework — that attackers exploit at scale. The most critical famous software vulnerabilities share one pattern: trusted, widely deployed code, slow patching, and hidden transitive dependencies that organisations did not know they were running.

• Key Takeaway 1: Most critical famous software vulnerabilities exploit trust in widely shared libraries or protocols, not exotic zero-days.
• Key Takeaway 2: CVSS scores alone do not tell you risk. Context, exposure, and exploitability in your environment matter just as much.
• Key Takeaway 3: Dependency scanning and a software bill of materials (SBOM) are now baseline practices, not optional extras.
• Key Takeaway 4: Legacy services like SMBv1 and vsftpd 2.3.4 survive in production long after patches exist, purely because of inertia.
• Key Takeaway 5: India’s CERT-In mandatory reporting rules mean Indian organisations must now treat vulnerability disclosure as a compliance obligation, not just a security best practice.

Application and Framework Vulnerabilities That Changed Everything

The most damaging famous software vulnerabilities of the last decade did not live in obscure corner-case code. They lived in libraries every developer trusted without thinking twice.

Log4j: CVE-2021-44228

Log4j is a Java-based logging library maintained by the Apache Software Foundation. In December 2021, security researchers at Alibaba Cloud disclosed CVE-2021-44228, a remote code execution flaw scoring a perfect 10.0 on the CVSS v3 scale according to the National Vulnerability Database (NVD). An attacker could send a single crafted string in a log message and force the server to fetch and execute arbitrary code from an attacker-controlled server via JNDI lookup.

The blast radius was enormous. According to Cisco Talos, over 40 percent of corporate networks were actively targeted within 72 hours of public disclosure. The flaw affected Apache Log4j versions 2.0-beta9 through 2.14.1. Apache released a patch with version 2.15.0, then followed with 2.16.0 and 2.17.0 as researchers found bypass techniques in quick succession. Indian organisations in banking, telecom, and IT services were among those scrambling to audit their Java stacks, with CERT-In issuing an emergency advisory within 48 hours of the global disclosure.

The lesson was not just to patch faster. It was that most organisations had no idea Log4j was even running in their environment because it shipped as a transitive dependency inside other products. You did not install Log4j. Something you installed installed it for you.

Is SLF4J Affected by the Log4j Vulnerability?

This question came up immediately after disclosure. SLF4J (Simple Logging Facade for Java) is a different library. It acts as an abstraction layer and does not contain the JNDI lookup mechanism that made Log4j exploitable. SLF4J itself was not vulnerable to CVE-2021-44228. However, if your application used SLF4J as a facade with Log4j 2 as the underlying implementation, the Log4j component was still exploitable. The facade was clean. The engine behind it was not.

Spring Framework: CVE-2022-22965 (Spring4Shell)

In March 2022, a remote code execution vulnerability in the Spring Framework, tracked as CVE-2022-22965 and immediately nicknamed Spring4Shell, scored 9.8 on the CVSS v3 scale. It affected Spring MVC and Spring WebFlux applications running on JDK 9 or later, deployed as a WAR file on Apache Tomcat. The flaw allowed an attacker to manipulate class loader properties via data binding and write a web shell to the server.

Spring released patches in versions 5.3.18 and 5.2.20. The Spring vulnerability 2022 episode reinforced one hard truth: framework updates are not optional maintenance. They are security events. This is one of the famous software vulnerabilities that demonstrated how quickly a framework-level flaw can cascade across millions of production deployments.

Axios Vulnerability: A JavaScript Supply Chain Warning

Axios, one of the most downloaded HTTP client libraries in the Node.js ecosystem, has appeared in several CVE advisories, including CVE-2023-45857, which exposed HTTP headers to unauthorised third parties due to a cross-site request forgery weakness. With over 50 million weekly downloads on npm, even a moderate-severity axios vulnerability can affect millions of applications simultaneously. It is a reminder that the JavaScript supply chain carries the same risks as the Java one, and that famous software vulnerabilities are not limited to enterprise frameworks.

Network Service and File-Sharing Vulnerabilities

Not every critical flaw lives in application code. Some of the most persistent famous software vulnerabilities sit in the protocols and services that networks depend on every day.

SMB Vulnerability: EternalBlue and CVE-2017-0144

The Server Message Block (SMB) protocol is how Windows machines share files, printers, and other resources across a network. CVE-2017-0144 targeted SMBv1 and allowed unauthenticated remote code execution. Microsoft patched it in MS17-010, but many organisations had not applied it when the WannaCry ransomware campaign hit in May 2017. According to the UK’s National Cyber Security Centre, WannaCry infected over 200,000 systems in 150 countries, causing an estimated $4 billion to $8 billion in damages globally. Indian public sector units and hospital networks were among the affected organisations, prompting CERT-In to issue a national advisory.

The SMB vulnerability lesson is straightforward: disable protocols you do not need, and treat unpatched legacy services as active threats, not acceptable risk.

Samba Vulnerability: CVE-2017-7494 (SambaCry)

Samba is the open-source implementation of SMB used extensively on Linux and Unix servers, particularly in mixed-OS environments common in Indian IT departments and university networks. CVE-2017-7494, dubbed SambaCry, allowed an authenticated user to upload a shared library to a writable share and cause the server to execute it, resulting in remote code execution. It affected Samba versions 3.5.0 and later, with a fix released in 4.6.4, 4.5.10, and 4.4.14.

SambaCry is among the famous software vulnerabilities that highlight why legacy services are dangerous: they run quietly in the background, often forgotten after initial setup, and rarely appear in routine vulnerability scans if the team has not configured authenticated scanning properly.

vsftpd 2.3.4: The Backdoor That Was Not Accidental

vsftpd 2.3.4 is a classic case study in supply chain compromise. In 2011, an attacker modified the vsftpd 2.3.4 source code on the official distribution server to include a backdoor, as documented by the vsftpd maintainer Chris Evans and later catalogued in Metasploit’s exploit database. When a user typed a username containing a smiley face “:)”, the server opened a root shell on port 6200. The compromised package was available for download for a short window before the maintainer caught it. It is still used as a training example in ethical hacking courses precisely because it shows how trust in a download source can be weaponised.

Microsoft IIS Vulnerabilities

Microsoft Internet Information Services (IIS) has accumulated a significant CVE history. CVE-2022-21907 was a critical HTTP Protocol Stack remote code execution flaw affecting IIS on Windows Server 2019 and 2022, scoring 9.8 on CVSS v3. Microsoft flagged it as wormable, meaning it could self-propagate without user interaction. The patch shipped in January 2022’s Patch Tuesday update. Teams running IIS should subscribe to Microsoft’s Security Response Center advisories and treat Patch Tuesday as a hard operational deadline.

CERT-In and Apple Device Vulnerabilities

India’s Computer Emergency Response Team (CERT-In) regularly issues advisories on high-severity famous software vulnerabilities, including those affecting Apple devices. In 2023, CERT-In issued multiple advisories on WebKit vulnerabilities in iOS, iPadOS, and macOS that allowed remote code execution and sandbox escape. These advisories carry a “High” or “Critical” severity rating and are legally significant for Indian organisations under CERT-In’s 2022 directions, which mandate reporting of cyber incidents within six hours of detection. Non-compliance can attract penalties under the Information Technology Act 2000, making vulnerability tracking a regulatory obligation for Indian enterprises.

The Dependency and Patching Lessons Defenders Must Apply Now

Every famous software vulnerability case above points to the same underlying failure. Organisations did not know what they were running, or they knew and had not acted. Both problems are solvable with process, not just tools.

Build and Maintain a Software Bill of Materials

A software bill of materials (SBOM) is a machine-readable inventory of every component in your software, including transitive dependencies. The US Executive Order 14028 on Improving the Nation’s Cybersecurity, issued in May 2021, made SBOMs mandatory for software sold to US federal agencies. Indian enterprises supplying to government or regulated sectors are increasingly expected to follow suit, particularly under CERT-In’s evolving guidance on supply chain security. Tools like Syft, SPDX, and CycloneDX can generate SBOMs from container images and build artifacts automatically.

Dependency Scanning Is Not Optional

Dependency scanning tools such as OWASP Dependency-Check, Snyk, and GitHub’s Dependabot continuously compare your dependency manifest against known CVE databases. According to the Synopsys 2023 Open Source Security and Risk Analysis report, 84 percent of codebases contained at least one open-source vulnerability, and 48 percent contained high-risk vulnerabilities. Running a scanner once at launch and never again is not a security programme. It is a checkbox. The OWASP Top 10 lists vulnerable and outdated components as a top application security risk, reinforcing that dependency management is a foundational control, not an advanced one.

Patch Management as a Timed Process

The gap between patch release and patch deployment is where attackers live. According to Ponemon Institute research cited by IBM, the average time to identify and contain a breach in 2023 was 277 days. That is not a technical problem. It is a process problem. Teams that track famous software vulnerabilities through NVD and vendor advisories, and that have defined SLAs for critical patch deployment, close that window significantly. NIST SP 800-40 provides a practical framework for enterprise patch management that Indian security teams can adopt directly.

Vulnerability	CVE ID	CVSS v3 Score	Affected Component	Patch Available
Log4Shell	CVE-2021-44228	10.0 (Critical)	Apache Log4j 2.x	Log4j 2.17.1+
Spring4Shell	CVE-2022-22965	9.8 (Critical)	Spring Framework MVC/WebFlux	Spring 5.3.18 / 5.2.20
EternalBlue (SMB)	CVE-2017-0144	8.1 (High)	Windows SMBv1	MS17-010
SambaCry	CVE-2017-7494	7.5 (High)	Samba 3.5.0+	Samba 4.6.4 / 4.5.10 / 4.4.14
IIS HTTP Stack RCE	CVE-2022-21907	9.8 (Critical)	Microsoft IIS 10.0	January 2022 Patch Tuesday

How Teams Track New Famous Software Vulnerabilities

The practical workflow is straightforward. Subscribe to NVD RSS feeds filtered by your technology stack. Set up alerts in your dependency scanner for new CVEs. Follow vendor security advisories directly: Microsoft’s MSRC, Apache’s security pages, and Spring’s security advisories. For India-specific context, monitor CERT-In advisories at cert-in.org.in. If you work in a regulated sector, assign a named owner to each advisory and track remediation in your ticketing system with a hard deadline tied to your patch SLA.

Understanding these patterns is exactly what separates reactive IT teams from proactive security teams. If you want to build those skills formally, exploring what cybersecurity skills companies are actually hiring for is a good place to start mapping your learning path.

The practical next steps are clear. Audit your running services and disable anything you do not actively use. Generate an SBOM for every application you own. Set a 72-hour SLA for critical patches and a 30-day SLA for high-severity ones. Subscribe to CERT-In and your relevant vendor advisories today, not after the next incident.

If you want to move from understanding famous software vulnerabilities to actively defending against them, 3University’s ethical hacking and cybersecurity certification courses give you hands-on, lab-based training built around real CVEs and real defensive techniques. Whether you are a student, a working IT professional, or switching careers into security, the curriculum is designed to build the practical skills that hiring teams actually test for.

Frequently Asked Questions

What are the most famous software vulnerabilities?

The most famous software vulnerabilities include Log4Shell (CVE-2021-44228), Spring4Shell (CVE-2022-22965), EternalBlue (CVE-2017-0144), SambaCry (CVE-2017-7494), and the IIS HTTP Stack RCE (CVE-2022-21907). Each scored 7.5 or higher on CVSS v3, affected millions of systems globally, and exposed the same root failure: widely trusted components left unpatched in production environments.

What was the Log4j vulnerability?

CVE-2021-44228, known as Log4Shell, was a remote code execution flaw in Apache Log4j 2.x scoring a perfect 10.0 on CVSS v3. It allowed attackers to send a crafted log message containing a JNDI lookup string, forcing the server to fetch and execute malicious code from a remote location. Apache patched it in versions 2.15.0 through 2.17.1. Millions of applications were affected because Log4j shipped as a hidden transitive dependency.

Is SLF4J affected by the Log4j vulnerability?

SLF4J itself is not vulnerable to CVE-2021-44228. It is a logging facade, not a logging implementation, and it does not contain the JNDI lookup code that made Log4j exploitable. However, if your application used SLF4J as a front end with Log4j 2 as the backend implementation, the Log4j component remained vulnerable. The risk depended entirely on which implementation sat behind the facade.

What is an SMB vulnerability?

An SMB (Server Message Block) vulnerability is a security flaw in the protocol Windows uses to share files and resources across networks. The most famous example is CVE-2017-0144, which targeted SMBv1 and was exploited by the WannaCry ransomware in 2017, infecting over 200,000 systems globally. Microsoft patched it in MS17-010. Disabling SMBv1 and keeping SMB services patched remains a core Windows hardening step.

Why are legacy services like vsftpd and Samba risky?

Legacy services like vsftpd and Samba are risky because they often run unmonitored in production long after patches are released. Samba’s CVE-2017-7494 sat in versions dating back to 2010. vsftpd 2.3.4 contained a backdoor introduced through supply chain compromise. Teams forget these services exist, skip authenticated vulnerability scans, and miss patches. The combination of low visibility and high privileges makes them attractive targets and keeps them among the most persistent famous software vulnerabilities in enterprise environments.

How do teams track new software vulnerabilities?

Effective teams combine several feeds: NVD CVE alerts filtered by their tech stack, vendor-specific security advisories (Microsoft MSRC, Apache, Spring), and India’s CERT-In advisories for region-specific alerts. Dependency scanning tools like Snyk, Dependabot, and OWASP Dependency-Check automate detection within codebases. The key is assigning ownership to each advisory and enforcing timed remediation SLAs rather than treating patch deployment as discretionary.

Last updated: June 2025. Reviewed by the 3University editorial team.