Security researchers from The Hunted Labs have released a blog about OpenJSON, a Go package that is commonly used across the world for cloud systems. They argue that OpenJSON poses a security risk because it is maintained by developers from VK, a Russian social media company.
Hunted Labs has discovered an open source software package that appears to be completely owned, maintained, and controlled by developers based in Moscow who work for one of Russia’s largest internet services conglomerates, VK Group (VK). Also known as Mail.ru, VK is controlled by Russian state-owned entities, and a member of its leadership is subject to U.S. and E.U. sanctions.
While using our platform Entercept to help a customer identify foreign ownership, control, and/or influence in their software, we found a suspicious component known as easyjson. This component is used across U.S. Government systems, Fortune 500 enterprises, and serves as the cornerstone of Cloud Native Computing Foundation projects that underpin the entire cloud-native ecosystem.
Since OpenJSON is a code serializer for Go, it is considerably more secure than most software packages. Because of this, it is also deeply integrated, hard to find, and difficult to remove as most cloud-native tools rely on it. The Hunted Labs is worried that the Russian government can take advantage of any zero-day vulnerabilities to compromise almost every network that relies on this package.
Russia doesn’t need to attack directly. By influencing state-sponsored hackers to embed a seemingly innocuous OSS project deep in the American tech stack, they can wait, watch, and pull strings when it counts. A well-placed backdoor or subtle bug could become the digital equivalent of a sleeper cell—with impact spanning from the Pentagon to your iPhone. Below are the top ways this package could be exploited:
A supply chain backdoor (mass compromise)
A remote code execution (RCE) via deserialization
Espionage & data exfiltration
A kill switch activation
So I was thinking, when it comes to open source projects, we often talk about security and privacy. But should we also be considering the nationality of the developers behind the project? Does it really matter where they’re from, or are we just distracting ourselves from the merits of the project itself? I’m curious to hear your thoughts
There is a careful line of the thinking of security / privacy and being xenophobic in my opinion. A scenario I imagine is a supply chain attack on this library, infecting machines.
Assuming worst case: we could hypothesize the government would force malware to be introduced. Users update to this version and are infected.
With this, I imagine the malware would surface, the project would lose credibility and get forked. Or, the code would be abandoned. The only time I can see malware shipped in FOSS is for large projects (Linux) or for highly complex projects (crypto libraries). Outside of that, I’d imagine it’s less likely, especially in a parser.
A more likely approach would be the government forks their own private version, and intercepts a download of the user with some DNS poisoning or other means. This would be targeted to an individual. This attack applies equally to all FOSS, so it’s project independent.
To prevent such attacks on shared libraries I recommend:
When installing a new package, vet it completely. If you don’t understand what you are about to run or trust the publisher, that’s dangerous.
Install updates only to fix identified issues that are currently happening in your system. Being an upgrade junky puts you at repeated risk for installing new janky code. Bugs are more likely going to be a headache.
These practices have nothing to do with the government.
That’s more or less Debian’s approach to updates, and it’s kind of infamous for its security shortcomings. On the PG desktop Linux guide, they explain some reasons as to why rolling or semi-rolling release cycles may be more ideal.
They were warning that it can be exploited by the Russian government? But then again, they don’t really explain whether the code itself is malicious; rather, they seem to hypothesize that it could happen rather than assert actual evidence.
I think this might be more of a juridiction and law problem than a race problem. PG recommends Adguard and SimpleX which have Russian developers, who’ve moved their services to other countries.
With Linux, my understanding is that they kind of had to do that to follow sanction laws and Linus has directly stated that he is not thrilled with this.
It’s not always binary, and threat models differ. There are update cycles more or less frequent. All with pros and cons. It doesn’t have to be Arch vs Debian.
The problem of the article is they don’t explain why VK/mailru would be OK to let russian hackers in, neither do they explain the legal venues for Russian state to do backdoors, nor do they mention that not all developers are Russian (this one for example is from the US nsd20463 (Nicolas S. Dade) · GitHub)
There are some big leaps in logic about Russians in this thread, so please take note of these important distinctions:
VK (a Russian social media site) is accused of censoring anti-Kremlin discourse and sharing data with the Kremlin
VK’s CEO Vladimir Kiriyenko is the son of Sergey Kiriyenko, a high level Kremlin official described as “Putin’s right-hand man”
There is a huge difference between state-linked companies and the general population. Don’t conflate the two.
That said, the article doesn’t make a strong case. It simply insists that since VK’s owners are sus, their company’s FOSS development may be malicious, without going into any technical detail.
So this software is not only written in Go, but it does other stuff with Go, right? I don’t have much technical knowledge in this field, but would it still be possible to write this in another language? If so, if a non-sus dev were to rewrite EasyJSON in, say Rust , then get everyone to replace EasyJSON with “RustyJSON”, would the potential problem be solved?
Of course, if it isn’t able to be rewritten, everything else would be a no-Go
Here’s an article on a real supply chain attack on Go. Who needs elaborate domain squatting when GitHub makes it easy. Again, FOSS independent attacks, but rather Go specific.
Unlike centralized package managers such as npm or PyPI, the Go ecosystem’s decentralized nature where modules are directly imported from GitHub repositories creates substantial confusion. Developers often encounter multiple similarly named modules with entirely different maintainers, as shown below. This ambiguity makes it exceptionally challenging to identify legitimate packages from malicious impostors, even when packages aren’t strictly “typosquatted.” Attackers exploit this confusion, carefully crafting their malicious module namespaces to appear trustworthy at a glance, significantly increasing the likelihood developers inadvertently integrate destructive code into their projects.
Ah, love it when freedom / privacy advocates pull ye old “I was just doing what I was told”. Nice to know that our heroes bend over at any moment someone powerful tells them to.
If Linus had a backbone he should’ve stated that open source, free OS is not bound / responsible / related to any outside wars or sanctions that have absolutely nothing to do with Linux. But I guess it’s far easier to submit to authority.
, then get everyone to replace EasyJSON with “RustyJSON”, would the potential problem be solved?