5+1 Vulnerabilities All Pentesters Know And Attackers Still Exploit

In cybersecurity, when we take on candidates to mentor the next generation of professionals,  we teach them about well-known and documented classes of vulnerabilities, like remote code execution, memory disclosure, injection flaws, supply-chain compromise, misconfiguration, and so on. Unfortunately, last year saw these “textbook” weaknesses show up in a number of widely used online services and infrastructure, perhaps even more so than in years prior.  

Surely, there are some learnings to be had. Let's explore a few of these together.

1. Unauthenticated Memory Disclosure

MongoBleed likely came as a surprise to much of the cyber community. Attackers could send malformed zlib-compressed network messages that cause the server to return uninitialized heap memory remotely, without authentication (CVE-2025-14847). Perhaps one of the most significant instances of memory bleed since the infamous Heartbleed vulnerability, a decade prior, except this time, instead of SSL private keys, the issue could be used to leak credentials and tokens, which, if successfu,l then allowed a second wave of follow-on attacks, and potential access to cloud services or web backends that relied on MongoDB.

This is classic improper input handling leading to information disclosure, because no authentication is required. The learning here is that even in the case of mature platforms, it is not necessarily the case that they are exempt from memory-safety issues. Remind your mentees to treat unauthenticated parsing code as hostile-input territory.

2. Remote Code Execution in Web Frameworks

React2Shell demonstrates how RCEs can increasingly be hidden behind abstraction layers, which people may intuitively assume to be safe. With this vulnerability, it was possible to run code in applications using default configurations, owing to React handling server-side payloads insecurely.

This mirrors the infamous Apache Struts vulnerability exploited in the Equifax breach in 2017. In that case, unsafe deserialization in the framework allowed attackers to execute code on public-facing servers.

Both cases demonstrate the potential dangers of overly trusting frameworks, especially when application logic is generated or interpreted dynamically. Have a healthy amount of sus, and keep an eye on CVEs reported by the projects you rely on.

3. Automated JavaScript Injection at Scale

In March 2025, around 150,000 websites were compromised by a coordinated JavaScript injection that didn’t rely on a novel backend flaw but rather classic unsafe output encoding and DOM-based XSS patterns. Attackers injected malicious scripts and iframes, replacing legitimate site content with gambling pages and evading some standard XSS controls in popular frameworks.

These mass JS injection campaigns are a direct descendant of Magecart-style attacks (CVE2015–2020). Magecart thrived because client-side security was not quite the main priority. It is not difficult to imagine these attacks getting "industrialized" to grow in scale through the use of automation. 

It is somewhat clear that client-side security is still undervalued. Quite often, we come across inconsistent output encoding, third-party scripts that are long overdue for an update, and the simple practice of following configuration guidelines on setting CSP headers. 

4. Supply Chain Attacks 

Cloud development tooling isn’t immune either. In 2025 a supply-chain vulnerability was found in the Amazon Q Developer Extension for Visual Studio Code. This allowed a malicious pull request to delete local files and AWS resources. This is a good example of how the security perimeter extends beyond traditional infrastructure and should include, for example, tooling. 

This is a smaller-scale but structurally identical problem to SolarWinds in 2020, where a poisoned update mechanism delivered backdoors to thousands of organizations, including government agencies.

Both instances demonstrate that trust relationships, especially automated ones, can represent attack surfaces, demonstrating why it is an excellent idea to follow ISO27001 guidelines and carry out supply chain reviews and risk assessments regularly. We should also be mindful of the pace at which modern supply chains can move, and that this would allow any compromise to propagate paster and further.

5. Legacy Classics Still Have Lessons to Teach

Although originally disclosed in 2021, the Log4Shell (CVE-2021-44228) class remains an example of improper input validation in a logging functionality leading to RCE, and still appears in many older environments today. Shocking, I know. 

The vulnerability remains relevant not because it’s new, but because it’s deeply embedded. Like Shellshock before it (2014), which exploited how Bash processed environment variables, Log4Shell exploits lookups in log messages, and in both cases, the vulnerabilities can be used far beyond their original context.

There is a brutal lesson here: the more "boring" and widespread a component is, the more dangerous its failures can become. Maintaining a software bill of materials (SBOM), has been hailed as a solution for many issues, and although the cybersecurity community is somewhat split about it's true effectiveness, Shellshock and Log4Shell are two instances where it would be helpful to have SBOMs.  

+1. Monoculture: Systemic Infrastructure Fragility 

There were a number of major cloud outages in the past year or so, which I'm sure a lot of us can recall for one reason or another. The AWS and CloudFlare disruptions exposed how software or configuration flaws affecting dominant cloud providers can cascade across global services, and affect financial systems and travel infrastructure alike.

Even though these were not caused by direct attacks, there is now a growing concern about risks tied to dependency on centralised infrastructure. At the core is architectural monoculture, where failure can impact many downstream services, demonstrating that resilience is as critical as vulnerability remediation. 

Indeed, there has been more discussion in the industry about cyber resilience as a comprehensive strategic concept, needless to say, for the better. 

Learnings

These cases show that textbook vulnerabilities like memory disclosure, code injection and supply-chain issues still pop up from time to time.

If you’re looking to benchmark your defenses or test against these patterns in your own stack, 45 Cyber Labs can help model threats and harden the services that might otherwise be at risk. Drop us a message to learn how we can help secure your systems.