CVE
CVE-2026-50010, CVE-2026-50011, CVE-2026-50020, CVE-2026-50560
CWE
CWE-494, CWE-506, CWE-347, CWE-444, CWE-400
Affected Surface
- Arch Linux AUR users exposed to the Atomic Arch package takeover
- Java applications and frameworks depending on vulnerable Netty 4.1.x or 4.2.x modules
- Rust workspaces that built onering 1.4.1
- Cursor, Windsurf, VSCodium, Gitpod, and other VS Code-compatible editors pulling extensions from Open VSX
Welcome to Corgea’s weekly briefing. The briefing covers the most important security findings and research from the week.
This edition covers Wednesday, 10 June through Monday, 15 June 2026, excluding items already covered in the 9 June briefing.
Top Article
Atomic Arch turned orphaned AUR packages into npm and Bun malware launchers
The most important story this week is still Atomic Arch, because it shows how little separation remains between package ecosystems during a real-world compromise. Public cleanup work now supports a verified inventory of 1,619 unique affected AUR package names, while the execution chain itself moved from orphaned AUR stewardship into npm install atomic-lockfile / npm install lockfile-js in the first wave and Bun-assisted js-digest fetches in the second. The payload at the end of that chain was not “just” JavaScript package malware; it was a Linux ELF infostealer with optional eBPF-assisted hiding logic.
That combination is why the incident matters beyond Arch desktops. The compromised AUR package was only the opening move. The real malware lived in package registries AppSec teams already track, and the final execution surface was the developer workstation or CI builder. It is the same cross-boundary pattern we have been seeing in npm, PyPI, and Cargo: package trust, build tooling, and developer endpoint trust are now one security problem.
More News
CVE-2026-50010, 50011, 50020, and 50560: Netty 4.1.135 / 4.2.15 fix TLS, HTTP/1.1, HTTP/2, and Redis parser flaws
The most important new package-level disclosure in the last few days is the Netty security train that hit NVD on 12 June. The reason it deserves attention is the diversity of the affected surfaces: io.netty:netty-handler could silently suppress hostname verification when callers supplied a plain X509TrustManager, io.netty:netty-codec-http was more lenient than RFC 9112 allows before the request line, io.netty:netty-codec-redis trusted attacker-declared array sizes for allocation, and io.netty:netty-codec-http2 let a hostile client weaponize advisory header limits against the server’s response path.
This is exactly the kind of Maven issue cluster that gets missed when teams watch only framework CVEs and not the transport library underneath them. If your stack pulls Netty transitively through gateways, async clients, or custom Java servers, this is the week to check what exact io.netty:* line you are really running.
onering 1.4.1 used Cargo build.rs to exfiltrate private source diffs
The other important package story from this window is how small the malicious delta was in the Rust crate onering@1.4.1. Instead of an obvious install hook or bulky credential stealer, the attacker added a short build.rs that Cargo executes automatically, walked out of the build directory into the consuming repository, and posted the latest commit metadata plus git diff HEAD^ HEAD output to a Sentry ingest endpoint.
That is worth keeping in the same mental bucket as this week’s AUR and Netty stories because it reinforces the same lesson: build-time helper paths are production attack surface. Whether the trigger is AUR package hooks, Netty parser defaults, or Cargo’s build.rs, the code developers rarely review most closely is often the code attackers want to run first.
GlassWASM used TinyGo WebAssembly and Solana memos in trojanized Open VSX extensions
The late-breaking developer-tooling story from 15 June is GlassWASM, a pair of trojanized Open VSX extensions that cloned legitimate identities, auto-executed a TinyGo-compiled .wasm payload on startup, queried Solana JSON-RPC for memo-based command-and-control, and then built child_process.execSync(...) retrieval commands for darwin, linux, and win32.
This one matters because the attack surface is not just “VS Code extensions” in the abstract. Open VSX is the default marketplace for Cursor, Windsurf, VSCodium, Gitpod, and other VS Code-compatible environments, so a malicious extension lands directly on the workstation that already has source code, registry credentials, cloud tokens, and AI tooling secrets. From an AppSec perspective, that makes alternate extension registries part of the software supply chain, not a separate problem.
From research to remediation
Check whether this pattern exists in your codebase
Turn this research into a remediation workflow. Scan dependencies and package manifests for similar supply-chain risk, then prioritize fixes with reachability context.