Our first ever CVE
And why we’re actually GLAD IT'S THERE...
In May 2026, Syncplify got its first ever CVE.
It’s for a bug we fixed in 2020. In forty-eight hours.
Pull up a chair, because the six years in between are the interesting part.
The timeline
2020 — A security researcher finds an unquoted service path in Syncplify.me Server! 5.0.37 and emails us about it. He is, for the record, extremely decent about the whole thing.
2020, plus about 48 hours — We ship the fix. We find no evidence any customer was affected. And we release it as v5.1.0 rather than 5.0.38, because we wanted a version number that cut the psychological cord with the affected build. Nobody should have to squint at a patch level to know whether they’re clear.
2020, shortly after — The finding goes public on Exploit-DB as entry 49009. No secret, no embargo, no quiet burial. Anyone could read it. Nobody assigned it a CVE number.
Six years pass. Nothing happens. The bug stays fixed. The record stays empty. Not a single customer has ever contacted us to report this bug being exploited. Not one.
16 May 2026 — VulnCheck, a CVE Numbering Authority that assigns identifiers to historically unnumbered vulnerabilities, files CVE-2020-37230. Same bug. Same version. Six years later.
And that is how a company with a clean vulnerability record for thirteen years acquires a HIGH-severity CVE overnight, for something that has not existed in a shipping build since 2020.
The facts, up front, no burying
CVE CVE-2020-37230
Product Syncplify.me Server! 5.0.37
Component the `SMWebRestServicev5` service
Class unquoted service path — CWE-428
CVSS 4.08.5 HIGH
CVSS 3.17.8 HIGH
Attack vector Local
Fixed in v5.1.0
Assigned by VulnCheck, 16 May 2026
NVD record CVE-2020-37230
If you are somehow still running 5.0.37 six years later, please update to the most recent version of our software. If you’re on anything 5.1.0 or later, you were never exposed to this in the first place.
What it actually is (and isn’t)
An unquoted service path is one of the oldest and least glamorous bugs on Windows. When a service’s binary path contains spaces and isn’t wrapped in quotes, the service control manager tries several interpretations of that path before finding the right one. Someone who can write an executable into one of the earlier interpretations gets their code executed instead of ours, with LocalSystem privileges, the next time the service starts.
To exploit it, an attacker needs to already be on the machine, already hold write access to a privileged directory, and then needs to wait for a restart.
OK, that is not “nothing”, which is why the fix took two days rather than two sprints. But be precise about what it is not. Not remotely exploitable. Not pre-authentication. Not network-reachable. Nobody can be scanning the internet for this. It does not let anyone touch your files from the outside.
About that 8.5 score
You’ll notice the score is HIGH, and you may reasonably wonder how a bug requiring a local foothold lands at 8.5.
CVSS scores impact after exploitation, and escalation to LocalSystem scores about as badly as anything can. The difficulty lives in the AV:L (Attack Vector: Local) which is exactly the part that evaporates the moment the number gets pasted into a risk register.
We could spend three paragraphs arguing that number down. We’re not going to, for a specific reason.
We spend a fair amount of time pointing out that when a vendor acts as its own CVE Numbering Authority, it gets to score its own bugs, and that some vendors’ own scores land at 3.5 LOW for bugs NIST rates 9.8 CRITICAL. That’s a fair criticism. It stops being fair the instant we run it in reverse on ourselves.
So: 8.5 HIGH. That’s the number. It’s on the record and we’re not litigating it. Argue the class if you want to argue something. We’ve given you everything above to do that.
The genuinely interesting part
Here’s what this episode should actually tell you, and it’s bigger than us.
The CVE system is not a real-time feed. It’s a lagging, incomplete, retroactively-edited index.
A vulnerability existed. It was found, reported, fixed in 48 hours, and published on Exploit-DB all the way back in 2020. The CVE arrived in 2026. For six years, the public record of that bug was: nothing. And then one day, without any change to any shipping software anywhere, it was a HIGH.
Three things follow, and we’d rather you took all three than just the flattering one:
One. “No recent CVEs” means much less than people think. A quiet record can mean a solid product. It can also mean nobody has gotten around to the paperwork. Those look identical from outside.
Two. The same is true of everybody else. Some of our competitors’ records are probably understated for exactly the reason ours was. We’re not going to pretend otherwise to win an argument. If VulnCheck’s backfill program reaches further, several vendors in this category are going to have an interesting quarter.
Three. Which is why you should read the record, not the count. One local priv-esc fixed in two days is not the same animal as an unauthenticated SQL injection that sat in shipping code across multiple major versions. Both are “a CVE.” A number is not a risk assessment. Open the entries and look at the attack vector, the class, and how long the thing lived.
So, why are we “glad”?
Nobody is glad about a bug (thank you, Captain Obvious 😉). Here’s what we’re actually glad about, and the distinction is the entire point.
Glad the entry exists at all. “Zero CVEs” was never the flex people think it is, and we always knew where the hole was: a CVE only exists if somebody looked. Zero is equally consistent with “solid” and with “irrelevant,” and no amount of insisting fixes that. Somebody looked. This is what they found. One local privilege escalation, needing an attacker already inside the building, fixed in two days, six years ago. We will take that trade every single time, an honest entry beats an unfalsifiable boast.
Glad about the forty-eight hours. The response to a stranger’s email in 2020 was to fix it, verify it, and ship a version number that made the boundary unmistakable. Not to negotiate. Not to ask him to sit on it. Not to quietly slipstream it into a release three months later and hope nobody joined the dots.
Glad you’re reading this from us, ten weeks after the ID appeared, rather than from somebody’s competitive comparison page. If a vendor’s security posture only becomes visible when somebody else discovers it, that isn’t a security posture. It’s a press strategy.
Now go check us. Then go check everyone else.
The NVD is public, machine-readable, adversarially maintained, and profoundly uninterested in anybody’s marketing. Put this in your browser: https://services.nvd.nist.gov/rest/json/cves/2.0?keywordSearch=Syncplify
One result. The one above. Fixed in 2020.
Now change the keyword. Try whatever moves your files today. Try the one with the analyst logo on the slide deck. Or the one with an endless line of certifications. or the one you’re using right now in your company.
We’re not running those queries for you here, because a vendor listing a competitor’s CVEs looks precisely like what it is. Run them yourself. Read the entries, not the counts. It takes ten minutes and it’s the highest-value ten minutes in your whole vendor due-diligence process.
Found something? Contact us privately. We answer.