Most security stories in this newsletter are about things happening to you directly: a phishing text, a leaked password, a fake shopping site. This one is different. The incidents below happened to developers — the people who write the apps and services you use every day. But the reason they belong here is simple: if someone poisons the tools used to build software, the poison doesn't stay with the builder. It ships with the product.
Two things happened recently that illustrate this. Neither made headlines the way a big breach does, because neither one is a breach of you, specifically. They're both attacks on the pipeline that produces the software you eventually install, open, or log into.
Counterfeit extensions dressed as trusted brands
Open VSX is a public marketplace for code-editor extensions — the small add-ons developers install to get autocomplete, linting, and integrations for the tools they use daily (Visual Studio Code and several of its open-source cousins pull from it). Between July 26 and August 1, 2026, security researchers at Manifold Security found 77 counterfeit extensions on the registry. Each one copied the name and namespace of a real, trusted extension, but was published from an account that didn't own the original — a classic impersonation move, sometimes called namespace squatting.
The squatted names weren't random. They borrowed the identities of AMD, LEGO Education, Hyperledger, Azure, Artsy, Salesforce's open-source projects, a U.S. federal agency, and — with a kind of dark irony — the extension marketplace itself. Every one of the 77 packages phoned home to a single domain that had been registered just 11 days before the first fake package appeared, a pattern that suggests a coordinated, purpose-built campaign rather than opportunistic copycatting.
Most of the fake extensions did something modest: they quietly reported a hostname back to the attacker's server, which by itself may just be a check to see who installed the bait. But researchers found that roughly a quarter of the 77 — 19 packages — went further. Seconds after activation, they collected the hostname, the operating system username, editor details, and a machine ID. Then they read whatever project the developer had open: the git remote (which reveals the organization and repository host), the commit email domain, the current branch, and the latest commit. They also pulled continuous integration values — the credentials and configuration that let automated systems build and deploy code without a human typing a password each time.
None of that data is useful for draining someone's bank account. It's useful for something else: figuring out which companies a developer works for, what their internal infrastructure looks like, and how to get a foothold in it.
A 9.8-out-of-10 bug in the machine that builds the software
The second incident involves TeamCity, a continuous integration and continuous delivery (CI/CD) platform made by JetBrains. If a code editor is where developers write software, a CI/CD platform is the automated factory floor where that code gets compiled, tested, and pushed out to production — often without any human clicking "deploy" at all. TeamCity is a central piece of that machinery at a lot of companies.
A vulnerability tracked as CVE-2026-63077, with a severity score of 9.8 out of a possible 10, was disclosed in TeamCity's on-premises versions. It's a deserialization flaw — a class of bug where a program trusts incoming data enough to turn it directly into running code, without checking what that data actually is first. In practice, it let an attacker send a request to a vulnerable TeamCity server, with no login required, and run arbitrary commands with the same privileges as the TeamCity service itself. JetBrains shipped patches (versions 2025.11.7 and 2026.1.3, plus a patch plugin for older 2017.1+ installs), but the U.S. Cybersecurity and Infrastructure Security Agency (CISA) has since warned that attackers are actively exploiting unpatched systems.
Whoever controls a company's build server controls what that company ships. That's not a hypothetical — it's the literal function of the tool.
Same playbook, two different doors
These are unrelated incidents from different researchers, but they share a shape. Neither one attacks a finished product. Both attack a step earlier — the editor a developer writes code in, or the server that turns that code into a shipped release. That's the defining trait of a software supply chain attack: instead of breaking into one target, you compromise something upstream that many targets depend on, and let their own trusted process carry your access forward for you.
It's worth being honest about what we don't know yet. Neither report that surfaced this week disclosed a confirmed case of a downstream app or user being compromised as a direct result — the extensions campaign looks like reconnaissance and access-gathering, and the TeamCity exploitation is described as active but without named victims. That's normal; supply chain compromises are often discovered at the entry point long before (or instead of) the eventual payoff being traced.
Why this is your problem, not just theirs
You will probably never install a coding extension or run a CI/CD server. But you use the output of hundreds of them: your banking app, your password manager, your kid's school portal, the browser you're reading this in. All of it passed through some developer's editor and some company's build pipeline before it reached your phone. If either of those links is quietly compromised, the malicious change can ride along with an ordinary, routine software update — the kind you install because you were told updating is the safe thing to do.
This is also why the advice in a breach postmortem sometimes reads strangely to non-technical readers: a company says its systems were compromised via a build server, or a stolen developer credential, or a malicious dependency, and it can sound abstract next to "someone guessed my password." It isn't abstract. It's the same outcome — your data or your app's integrity compromised — arrived at through a door you never knew existed.
What actually helps
You can't audit your bank's CI/CD pipeline, and you shouldn't have to. But a few habits genuinely reduce your exposure to this category of risk:
Keep auto-updates on, but don't treat updates as automatically trustworthy. Patches are how fixes like the TeamCity one above reach the software you run — staying current closes windows attackers are actively probing. At the same time, an update is only as good as the pipeline that produced it, which is exactly the thing being targeted here; there's no perfect individual defense against a truly poisoned upstream release, which is why this is fundamentally a vendor-responsibility problem, not a you-problem.
If you work with or manage developers, two concrete, checkable things: verify that any code-editor extension is installed from the actual verified publisher account, not just a matching name (Open VSX and similar marketplaces show a publisher identity — check it, don't trust the icon and title alone); and if your organization runs TeamCity on-premises, confirm it's on 2025.11.7, 2026.1.3, or has the patch plugin applied, today, not on the next maintenance window — CISA's warning means this is being actively exploited, not theoretical.
For everyone else, the useful shift is just awareness: when you read about a company breach that traces back to "a compromised developer tool" or "a build system," that's not a niche technical footnote. It's the same category of event as the password breaches and phishing scams this newsletter covers more often — it just started one layer further upstream, before the product ever reached you.
