The best way to learn how software breaks is to break real software, responsibly, and then help fix it. That is the idea behind the Thoropass Vulnerability Research Program (VRP): a structured effort in which our penetration testing team digs into widely used open-source projects, uncovers previously unknown vulnerabilities, reports them privately to the maintainers, and publishes the write-ups publicly. It is a training ground for our testers, a genuine contribution to the open-source community, and a way to harden the tools our clients depend on every day.
To date, the program has produced 15 assigned CVEs across six open-source projects, all published at the Thoropass VRP repository.
Research & Learning
A checklist can tell a new tester what to look for. It cannot teach the instinct for why a feature is dangerous. That instinct comes from following a real vulnerability end-to-end: forming a hypothesis, proving it, understanding the root cause, and watching the fix land.
The VRP is deliberately structured so that junior and mid-level engineers grow through exactly that loop:
- From reading CVEs to writing them. Studying published advisories teaches pattern recognition. The next step is reproducing a class of bug in live software and documenting it well enough that a maintainer can act on it. That jump, from consumer of research to author of it, is where testers level up fastest.
- Root cause over surface symptom. Every finding in the program is mapped to a CWE and explained at the level of why the code was wrong, not just what request triggered it. That habit carries directly into client engagements, where the goal is to explain risk, not just demonstrate it.
- Writing that a maintainer will read. Coordinated disclosure forces clear, reproducible reporting. Learning to write an advisory that a stranger can act on is one of the most transferable skills in security.
Each CVE below is a case study that a newer tester can walk through, and the patterns section at the end distills them into lessons that apply far beyond these specific projects.
Open Source Contributions
Open source runs under the products that almost everyone uses, and it is maintained largely by small teams and volunteers. When a testing team finds a flaw and reports it, gives the maintainer time, and then publishes a clear advisory, the whole ecosystem gets safer.
The program follows coordinated vulnerability disclosure without exception: findings go to maintainers privately first, maintainers get a reasonable time to remediate, and public disclosure follows through GitHub Security Advisories and CVE Numbering Authorities.
Protecting the tools our clients use
This research is not academic. The projects studied here are the kinds of applications that appear in real environments: network controllers, data platforms, annotation tools, and content services. When Thoropass hardens an open-source project, the benefit reaches every customer who runs it, including our own clients, before an attacker ever gets the chance. Research and client testing feed each other: patterns found in the wild sharpen the engagements, and the engagements surface new questions worth researching.
Assigned CVEs
The findings so far span six projects and the classic weak points of web and API security: broken authorization, injection, request forgery, cross-site scripting, path traversal, and resource exhaustion.
TP-Link Omada Software Controller (2025)
TP-Link's free on-premises controller for the Omada networking line, access points, switches, and gateways, used by small businesses and enterprises to manage their networks from a single console. Three findings, all affecting versions before 6.0.
- CVE-2025-9520, IDOR to owner-account hijacking (CWE-639, High). An administrator could hijack the Owner account by changing a user-ID parameter in an account update request, rewriting the Owner's username and password.
- CVE-2025-9521, secondary verification bypass (CWE-522, Low). An authenticated attacker could change account settings, including passwords, without the secondary verification the flow was meant to enforce.
- CVE-2025-9522, blind SSRF (CWE-918, Medium). Webhook functionality could be abused to probe internal infrastructure and enumerate open ports and services, even without seeing the response body.
Watch what the server trusts. Client-supplied identifiers and "already handled" security checks are where these three live.
Research by Eduardo Bido.
grit42 (2026)
Grit, from Grit42 A/S, is an open-source platform for storing and visualizing preclinical drug-discovery data such as compounds, assays, and experiment results. Two SQL injection findings.
- CVE-2026-12188, SQL injection in the CSV export endpoint (CWE-89, Medium). A low-privilege authenticated user could inject SQL through the export path and exfiltrate sensitive columns, including password hashes and API tokens, opening a route to full administrator takeover.
- CVE-2026-12206, boolean-blind SQL injection in the data-table entity endpoint (CWE-89, Medium). Any active account, including a zero-role account, could read every column the database role can see and extract administrator tokens for permanent access.
Export and reporting features are a frequent blind spot. They build queries dynamically and hide behind the assumption that "read-only" means "safe."
Research by Natan Morette and Manfred Carvajal.
COCO Annotator (2026)
A popular open-source, web-based image-annotation tool for building computer-vision datasets, with around 2.3k GitHub stars. Four findings at version 0.11.1 and earlier, covering both authorization and availability.
- CVE-2026-7680, path traversal via the dataset folder parameter (CWE-22, Medium). Insufficient sanitization in the dataset browsing API lets an authenticated attacker walk the filesystem and enumerate sensitive directories.
- CVE-2026-7681, unauthenticated dataset modification (CWE-306, Medium). A single unauthenticated POST request could modify dataset categories and annotation metadata for any dataset.
- CVE-2026-2109, broken function-level authorization on delete (CWE-285, Medium). Any authenticated user could delete categories created by others, with no permission check.
- CVE-2026-2108, unauthenticated task-queue flood (CWE-306 and CWE-400, Medium). An unauthenticated attacker could flood a long-task endpoint, saturate the background workers, bloat the database, and take the application offline.
Authorization has to be checked on every sensitive action, and availability is part of security, not separate from it.
Research by Natan Morette.
i-Educar (2026)
i-Educar bills itself as the largest free education software in Brazil, an open-source school management system adopted by municipal education networks nationwide to manage enrollment, student records, and academic data.
- CVE-2026-2064, stored XSS via profile file upload (CWE-79, Low). In i-Educar 2.10.0, an authenticated attacker could upload an SVG containing embedded JavaScript as a profile picture, so that arbitrary script ran in the browser of anyone who viewed it.
File uploads that accept SVG are effectively HTML uploads unless they are handled with care.
Research by Natan Morette.
YAFNET (2026)
YAFNET (Yet Another Forum) is a long-established open-source forum engine used to power community discussion boards. Three findings, patched in 4.0.5 (and 3.2.12 on the 3.x branch).
- CVE-2026-43937, authorization bypass enabling blind SQL injection (CWE-841 and CWE-89, High). YAFNET's only admin gate was a result filter that ran after the page handler, so a low-privilege or self-registered user could reach the
/Admin/RunSqlhandler and execute arbitrary SQL before the check ever fired, reading data through a time-based blind oracle and escalating to host administrator. - CVE-2026-43938, unauthenticated stored XSS in the admin event log (CWE-79, High). An anonymous request carrying a script payload in its
User-Agentheader was logged verbatim and later rendered unescaped when an administrator opened the event log, running attacker script in the admin's session with no account required. - CVE-2026-43939, stored XSS in thread posts and replies (CWE-79, High). Post content was rendered without sufficient sanitization, so any member could plant a payload that fired for every viewer of the thread.
The lesson from 43937 is the sharpest in the program: a check is only as good as when it runs. Authorization that executes after the side effect is not authorization at all.
Research by Muhammad Uwais.
ApostropheCMS (2026)
Two stored XSS findings in ApostropheCMS, a full-featured open-source CMS built on Node.js with around 4.6k GitHub stars, affecting versions 4.29.0 and earlier.
- CVE-2026-45011, stored XSS via a javascript: link in the image widget (CWE-79, High). An editor could point an image's link at a
javascript:URL that executed in the browser of any visitor, including an administrator, who clicked the published image. - CVE-2026-45014, stored XSS via an unsanitized display name (CWE-79, Medium). A user-controlled display name rendered without escaping in the draft-version tooltip ran script when another user viewed the version history.
A link is code when its scheme says so: an href that accepts javascript: is as dangerous as an unescaped script tag.
Research by Muhammad Uwais.
Patterns worth remembering
Across fifteen CVEs, a short list of root causes keeps returning. These are the lessons a tester can carry into any engagement:
- Authorization assumed instead of enforced. IDOR, broken function-level authorization, missing authentication, and an admin console whose access check ran too late account for the largest share of the findings. The fix is almost always a server-side check tied to the authenticated user, enforced before the action runs, on every sensitive action.
- Injection through the features nobody audits. Exports, reporting, and data-table endpoints build queries dynamically and get trusted because they feel read-only.
- Uploads and rich fields as script-delivery vectors. SVG profile pictures, unescaped display-name fields,
javascript:links, and even a loggedUser-Agentheader all became stored XSS, some firing in an administrator's session. - Availability is part of security. An unauthenticated request that can exhaust a worker queue.
None of these are exotic, and that is the point. They are the everyday mistakes that turn into breaches, and learning to spot them reliably is the whole job.
Disclosure Process
Every advisory follows the same discipline: private report to the maintainer, a remediation window, public disclosure with a CVE identifier and a clear write-up, and no released exploit code. CVE identifiers matter because they give everyone, defenders, scanners, and vendors, a single reference to track the issue, its patch, and its severity.
Conclusion
The Thoropass VRP is three things at once: a place where pentesters grow by studying and producing real CVEs, a contribution to the open-source community that helps keep shared software safer, and a way to harden the very tools our clients depend on. If these findings look familiar, that is the value. They are the everyday authorization and injection mistakes that turn into breaches, caught and fixed before they happen.
The full set of advisories, with technical details on each, is available in the Thoropass Vulnerability Research Program repository. To have the Thoropass team review your applications, request a penetration test at thoropass.com.
Related Posts
Stay connected
Subscribe to receive new blog articles and updates from Thoropass in your inbox.
Want to join our team?
Help Thoropass ensure that compliance never gets in the way of innovation.










.png)