A New Firm Is Quietly Reverse-Engineering Open-Source ERPs for Remote Code Execution. Their GitHub Forks Tell You Exactly Who's Next.
- Patrick Duggan
- 2 hours ago
- 5 min read
Our exploit-harvester flagged two fresh proof-of-concept exploits the day they were published — both authenticated remote-code-execution flaws in Vtiger CRM, from a GitHub account called JivaSecurity that almost nobody is watching yet. Zero stars. Zero followers. A brand-new name. But the interesting thing isn't the individual bugs. It's that when you lay out everything this researcher has published, and cross it against the repositories they've quietly forked but not yet published on, their next targets are sitting right there in plain sight. This is a small post about a large idea: a methodical researcher leaves a roadmap, and the roadmap is readable if you bother to read it.
Who they are (and what they are not)
First, the honest framing, because it matters. JivaSecurity is a legitimate security researcher, not a criminal actor. The account carries a real brand — a website, an X presence, a YouTube channel — with the plain bio "offensive security, penetration testing, red teaming and vulnerability research." Their proof-of-concepts are clean, single-file Python, no obfuscation, no malware hidden in a fake exploit. The CVEs they publish are real and assigned, and the affected vendors have shipped fixes. This is coordinated-disclosure vulnerability research of the ordinary, useful kind. We are not naming an adversary. We are reading a researcher's public work and drawing the obvious conclusion they've left in the open — which is exactly what threat intelligence is supposed to do with public signal.
The account is new: created in March 2026, and every repository still sits at zero stars and zero followers. That's the part worth sitting with. This is high-quality work that the wider world simply hasn't noticed yet. We noticed because our pipeline watches for freshly-published exploit code as a category, not because anyone was talking about it.
The pattern is a workflow, and the workflow is visible
Here is what JivaSecurity has published, in order:
In March, an RCE in Dolibarr, the open-source ERP — an evaluation-whitelist bypass that turns a restricted expression into arbitrary code. A week later, an RCE in EspoCRM, which they titled "Formula for Disaster" — a formula-injection path to code execution. And this week, two at once in Vtiger CRM 8.3.0: one via a .phar file upload through the Documents module that slips past the extension filter, rated 8.8, and a second via module import. Same class of target every time: an open-source business application — ERP, CRM — that mid-market companies quietly run their whole operation on. Same class of bug every time: authenticated remote code execution, the kind where a low-privilege user turns into a shell on the server.
But the published exploits are only half the repository list. The other half is the tell. Before they publish a finding, they fork the target's source code — Dolibarr, EspoCRM, and Vtiger were all forked into their account before the PoCs appeared. It's the natural workflow of source-code auditing: pull the code local, read it, find the flaw, write the exploit. And that workflow leaves fingerprints, because they have also forked several applications they have not yet published anything on.
The forks are the forecast
Sitting in JivaSecurity's account right now, forked and presumably under the knife, are: osTicket, the support-ticketing system; Kimai, the time-tracking application; Laravel CRM; OpenSourcePOS, a point-of-sale system; and FrontAccounting. If the pattern that held across Dolibarr, EspoCRM, and Vtiger holds again — fork, audit, publish an authenticated RCE — then these five are the likely next drops.
We hold that at about 95 percent, and we're careful to call it inference rather than confession: a fork is not a promise, and a researcher can audit something and find nothing, or move on. But three-for-three is a pattern, not a coincidence, and the target class is dead consistent. If you run any of those five applications, the responsible reading of this is not "maybe someday." It is "someone competent may be reading your application's source code this month, and the finding will be a remote shell." That is a gift of lead time, and lead time is the only advantage defense ever really gets.
What to actually do
If you run Dolibarr, EspoCRM, or Vtiger: these are published, with working PoCs, today. Patch now — Vtiger users specifically to 8.4.0, which closes both of this week's flaws. Assume the exploit is in circulation, because it is, in a public repository, in readable Python.
If you run osTicket, Kimai, Laravel CRM, OpenSourcePOS, or FrontAccounting: you have been handed something rare, which is warning before the fact. Get your instance off the open internet if it doesn't need to be there. Tighten authenticated-user privileges, because every one of these findings is authenticated RCE — the attacker needs a login first, which means your low-trust accounts and your file-upload paths are the ground to watch. Watch the vendor's releases. And frankly, watch JivaSecurity's GitHub, because they're telling you.
The honest footnotes
Two, in the spirit of not dressing anything up. First, on speed: our harvester caught the Vtiger PoCs the same day, but not ahead of the disclosure — the CVE hit the national database at 17:16 UTC and our detection landed at 18:00, roughly forty-four minutes later. Same-day and automated, which is the point of the pipeline, but we're not going to call a forty-four-minute lag a lead, because it isn't one. Second, on the researcher: publishing this is, if anything, free publicity for good work that deserves eyes, and we'd rather point at it than pretend we found the bugs ourselves. We didn't. JivaSecurity did. We just read the room they left the lights on in.
The larger point outlasts these particular CVEs. Methodical adversaries — and methodical researchers, who share the same habits — are legible if you watch the staging rather than the strike. The fork before the exploit, the pre-registered infrastructure before the campaign, the source-code clone before the finding: these are the pre-boom signals, and they are almost always sitting in public. Most people only look at the explosion. The whole game is looking at the fuse.
We hold this at about 95 percent, as always. The published flaws are certain; the forecast from the forks is a well-founded inference we're labeling as one. But the discipline is the durable part: read the staging, name what's coming, and hand the defender the one thing they can actually use — a little bit of time.
Sources: JivaSecurity public GitHub repositories and published PoCs; NVD record for CVE-2026-23697 (Vtiger CRM 8.3.0 authenticated RCE via .phar upload, CVSS 8.8, fixed 8.4.0, published July 7 2026); DugganUSA exploit-harvester detections, same day. Fork-based target forecast is our inference from JivaSecurity's fork-then-publish pattern across Dolibarr, EspoCRM, and Vtiger.
Every indicator in this post is in the feed. Free.
1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.