A proof of concept (PoC) is a piece of code or a process designed to demonstrate that a vulnerability is real and exploitable. The goal isn't necessarily to launch an attack, but to clearly, technically and precisely show how the vulnerability can be exploited—and what the potential consequences will be if it remains unpatched.
The Standard PoC Pipeline
Typically, a PoC is created after a security researcher or cybercriminal discovers a vulnerability, whether through manual testing, code review, fuzzing or other methods. The researcher then builds a PoC to confirm the issue is reproducible and real. From there, among the paths that are possible:
- The researcher can report the vulnerability to the vendor through a process known as responsible disclosure. The vendor is usually given a grace period to fix the issue before the PoC is made public.
- The researcher may choose to publish the PoC directly online—often after a patch is released, but not always.
- In some cases, the researcher may decide to keep the information private or attempt to sell it. This a less ethical route that’s typically followed by threat actors rather than white hats.
But what happens when a PoC is published before a fix is available? That’s where things get risky.
The Risks of Public PoCs Without a Patch
It doesn’t take much to get to this point. There are cases where companies ignore reports. Sometimes they don’t have a bug bounty program or sometimes they just cannot find a solution. Then, once the PoC is online without a patch, it becomes a roadmap for attackers. Anyone with minimal technical skill can exploit the vulnerability in the PoC and attack the affected products, putting users and organizations at serious risk. Even when no attacks are immediately observed, public PoCs without a fix can leave organizations exposed for extended periods of time. The following case studies, where the existence of PoCs combined with a delayed or missing vendor response, illustrate just how complex and risky vulnerability disclosure can be.
Case Studies: When PoCs Are Public and Patches Are Missing
While there are no public reports of active exploitation in the cases below, they both illustrate the risks introduced when proof-of-concept exploits are made publicly available without a corresponding patch. The vulnerability is proven, the PoC is out there. That combination creates a dangerous window of exposure, even if there is no record (yet) of attackers taking advantage of it.
The Brother Printers
In mid-2024, researchers at Rapid7 discovered a flaw in over 600 Brother printer models. The vulnerability (CVE 2024 51978) allows attackers to generate the default admin password based on the printer’s serial number—a logic fused into the hardware itself. This means it can’t be fixed through software or firmware update. Addressing the vulnerability would require a recall and changes to the hardware. The vulnerability was rated with a score of 9.8 (critical), indicating high severity and potential for full device compromise.
-
Responsible Disclosure:
Rapid7 reported the vulnerabilities to Brother in May 2024, coordinating via JPCERT/CC (Japan’s national CERT), and worked with the vendor for over a year before publicly disclosing in June 2025.
-
Vulnerability Management:
Brother released firmware updates addressing most of the vulnerabilities reported by Rapid7, but CVE‑2024‑51978 remains unpatched due to its reliance on hardware-level logic. Brother also put out an advisory to change the default admin password. Changing the password is an effective mitigation which blocks exploitation for now. However, the vulnerability itself remains present in the hardware, and can re-emerge when the device is factory reset.
-
PoC Exploit:
A working PoC was published on GitHub by Rapid7 alongside their technical white paper, demonstrating how CVE 2024 51977 can be used to retrieve the printer’s serial number, and from that derive the default admin password via the algorithm provided in CVE 2024 51978, leaving organizations that are unaware of the advisory to change the default password exposed.
Tenda AC9 Routers
In early 2025, a critical vulnerability was disclosed in the firmware of Tenda AC9 routers. The flaw, tracked as CVE 2025 29384, resides in the WAN MTU parameter of the /goform/AdvSetMacMtuWan API endpoint, which contains a stack overflow vulnerability.
This flaw allows an attacker to execute remote arbitrary code without authentication, simply by sending a crafted POST request. The attack is possible from both local and remote networks if remote management is enabled. The vulnerability is also rated with a score of 9.8 (critical).
-
Vulnerability Management:
A public working PoC exploit has been released. To date, there appears to be no official firmware update or advisory provided by the vendor. Public sources such as the National Vulnerability Database (NVD) list the vulnerability, but did not reference any patch or response from the vendor.
-
PoC Exploit:
A public PoC exploit has been released online demonstrating how to exploit the WAN MTU parameter to gain full control over the router. The PoC performs command injection via a crafted POST request and shows how arbitrary shell commands can be executed on the device. As of now, the PoC is circulating freely, and no official patch has been provided by the vendor.
-
Risk Level and Implications:
The flaw in CVE 2025 29384 poses a severe risk:
- Enables remote code execution with no authentication.
- Can be exploited at scale and leveraged by botnets.
- Affects all Tenda AC9 devices using the specific firmware version.
The situation illustrates the broader complexities in IoT vulnerability management, where public PoCs may surface before vendors are able to issue a fix or respond formally.
Conclusion
Public proof-of-concept (PoC) exploits play a vital role in validating security research and promoting accountability. However, when released before a patch is available, they can also expose organizations to widespread exploitation. As IoT adoption continues to accelerate, the need for clearer and more consistent vulnerability handling practices—such as timely and effective vendor responses—become increasingly urgent. While researchers are instrumental in exposing the cracks in our systems, the broader ecosystem must be prepared to act quickly and decisively to ensure those cracks don’t escalate into full-blown breaches.