Tech Talk — May 23, 2026

I am Link. Welcome to Tech Talk, a Black Elk Media production. Today is May 23, 2026, and we are analyzing the latest shifts in the digital landscape.

SpaceX put Starship V-3 into the sky for the first time yesterday... and the ship performed. The most powerful launch vehicle ever built cleared the pad, completed its ascent profile, and demonstrated the upgraded Raptor 3 engines under full flight loads. By that measure... a successful debut.

But the booster never made it home.

Super Heavy... the first stage designed to fly back to the launch tower and be caught mid-air... was lost during its return sequence. And that changes the math on everything SpaceX is trying to prove with this architecture. Because Starship's entire economic model depends on rapid, full reusability. The rocket that flies is only half the equation. The rocket that lands... and flies again... that's where the real engineering story lives.

So today, we're going to break down what V-3 actually changed from its predecessor, what we know about the booster failure, and what this means for the reusability timeline that SpaceX, NASA, and the entire commercial launch industry are counting on.

The launch was spectacular. The landing was not. And the gap between those two outcomes... that's where the most important engineering decisions are being made right now.

Let's get into it.

THE FRONT PAGE

# The Front Page

Here's your rapid-fire briefing on the stories shaping tech right now.

---

Story one... Google just said the quiet part out loud.

At I-O this week, Google's head of search Liz Reid officially declared... Google Search is A-I Search. The ten blue links... are gone. Not deprecated, not de-prioritized... gone. What replaces them is a conversational Gemini-powered interface that generates bespoke responses... complete with charts, bullet points, even animations. Google is no longer a portal to the web. It's an answer engine that keeps you inside Google's walls. And when you're talking about a two-trillion-query-per-year habit... even users who resist A-I everywhere else will encounter it here, whether they want to or not. The downstream effect on publishers, advertisers, and the open web... is enormous.

And speaking of companies consolidating entire markets under one roof...

Story two... Nvidia is coming for the C-P-U market, and the numbers are staggering.

After posting eighty-one-point-six-five billion dollars in quarterly revenue... Nvidia's C-F-O projected twenty billion in C-P-U sales this fiscal year from its Grace and Vera processors. For context... Intel's entire data center division did sixteen-point-eight billion last year. A-M-D's did sixteen-point-six. The full x-eighty-six server C-P-U market is roughly thirty billion dollars. Nvidia is targeting two-thirds of it... in a segment it has never meaningfully competed in before. The mechanism is vertical integration. Every two Rubin G-P-Us ship with a Vera C-P-U attached. If you're buying Nvidia's A-I accelerators... you're buying Nvidia's processors too. Intel and A-M-D aren't just losing A-I mindshare anymore. They're losing their core server business as a side effect.

Now, from competition on the ground to confrontation in orbit...

Story three... four Russian military satellites have maneuvered into the orbital path of a Finnish-American radar satellite.

Kosmos twenty-six-ten through twenty-six-thirteen launched together in April and have since adjusted their orbital inclinations to match ICEYE X-thirty-six... a commercial radar imaging satellite that provides surveillance data to the U-S military, European governments, and Ukraine. The plane-change maneuvers are significant because they burn enormous amounts of fuel... equivalent to raising altitude by over a hundred miles. You don't spend that propellant casually. ICEYE provides all-weather radar imagery to Ukraine's military. This is orbital intimidation with a clear signal attached.

Meanwhile, back on Earth, a different kind of supply chain is shifting...

Story four... Chinese-made D-RAM just showed up inside a Corsair memory kit.

ChangXin Memory Technologies... known as C-X-M-T... is now supplying D-D-R-five chips for Corsair Vengeance modules. Corsair has historically sourced exclusively from Micron, Samsung, and S-K Hynix. But those three are sold out to data centers. C-X-M-T doesn't have the latest fabrication tools for hyperscaler-grade memory... which means it has open production lines and no competing contracts. The result is a six-thousand megatransfer, C-L-thirty-six kit... not the fastest, but entirely competent for consumer use. Right now it's China-market only. But the pattern here is clear... the global memory shortage is reshaping supply chains, and Chinese fabs are filling the vacuum that the big three left behind.

---

**The through-line this week:** Consolidation and control. Google is consolidating the search experience under A-I. Nvidia is consolidating server compute under its platform. Russia is consolidating pressure in orbit. And China's memory industry is consolidating its position in a market the incumbents abandoned. The common thread... when dominant players leave gaps or force transitions, someone fills them. Fast.

That's The Front Page. And one of those gaps... the trust gap in software supply chains... is exactly where we're headed next.

THE DEEP DIVE

# The Deep Dive: The Anatomy of an Open Source Poisoning Campaign

Every piece of software you use today is built on trust. Trust that the library you installed yesterday is the same one the author published. Trust that the code editor extension with a hundred thousand downloads is doing what it says. Trust that the package manager pulling in your dependencies isn't quietly introducing something hostile into your build.

That trust is being systematically dismantled... and the scale of it is unlike anything we've seen before.

This week, GitHub confirmed it had been breached. A developer on their team installed a poisoned extension for VS Code... Visual Studio Code... the code editor used by tens of millions of developers worldwide. That single compromised extension gave a group calling themselves TeamPCP access to roughly three thousand eight hundred internal repositories. GitHub's own source code. The group is now advertising that code for sale on BreachForums.

But here's the part that should really get your attention. This isn't an isolated incident. It's just the latest wave in a campaign that has corrupted more than five hundred distinct open source packages across more than twenty separate attacks... in just the last few months. According to the security firm Socket, when you count all the hijacked versions of those packages, the number climbs well over a thousand.

So let's break down how this actually works... because the mechanics of a software supply chain attack are worth understanding in detail.

How the Attack Chain Works

A modern software project doesn't exist in isolation. When you build an application today, you're assembling it from hundreds... sometimes thousands... of smaller components. Libraries, frameworks, plugins, extensions. Each one is a dependency. And each dependency has its own dependencies. This is the supply chain.

The attack surface here is enormous, and TeamPCP is exploiting it methodically through several techniques.

The first and most common is what's called typosquatting. You publish a malicious package with a name that's almost identical to a popular, legitimate one. Think "requests" versus "reqeusts"... or "lodash" versus "l0dash." A developer makes a typo in their install command, or copies a slightly wrong name from a forum post, and they've just pulled in hostile code. It sounds almost too simple to work... but at scale, it works constantly.

The second technique is dependency confusion. Many organizations use internal, private package registries alongside public ones like npm or PyPI... the Python Package Index. If an attacker publishes a public package with the same name as a private internal one, and the package manager checks the public registry first... or assigns it higher priority based on version number... the malicious package gets installed instead of the legitimate internal one.

The third approach, and the one used in the GitHub breach, is extension and plugin compromise. VS Code extensions run with significant privileges. They can read files, execute commands, access the network. A poisoned extension can act as a silent backdoor, exfiltrating credentials, tokens, and source code... without the developer ever noticing anything unusual. The extension still appears to function normally. It just has an additional, hidden purpose.

What makes TeamPCP's operation distinctive is the industrialization of these techniques. Twenty waves of attacks. Five hundred plus packages. This isn't a single clever exploit. It's a production pipeline for generating and distributing malicious code at volume.

The Structural Problem

So why is this so hard to stop?

The answer lies in how open source ecosystems are structured. Package registries like npm, PyPI, and crates dot I-O are designed around openness and low friction. Anyone can publish a package. There's minimal vetting. The assumption baked into these systems is that the community will self-police... that popular packages will be reviewed, that malicious ones will be flagged and removed.

That assumption held up reasonably well when supply chain attacks were rare and opportunistic. It breaks down completely when a dedicated group is publishing poisoned packages faster than they can be detected and removed.

Consider the math. npm alone hosts over two million packages. PyPI has over half a million. Each package can have dozens of versions. Manually reviewing even a fraction of new submissions is impossible. Automated scanning helps, but attackers adapt their obfuscation techniques in response. TeamPCP has reportedly been rotating their methods across waves... using different code obfuscation, different exfiltration channels, different trigger conditions... making signature-based detection a constant game of catch-up.

And then there's the trust chain problem. Even if you carefully vet every direct dependency you install, those packages have their own dependencies... which have their own dependencies. A vulnerability or backdoor introduced three or four levels deep in your dependency tree is effectively invisible to you. The average Node dot JS application has over seven hundred transitive dependencies. You are trusting every single one of them.

The GitHub Breach in Context

The GitHub breach adds another dimension to this problem. When your source code hosting platform itself is compromised, the implications cascade.

GitHub says the compromised repositories contained their own internal code, not customer repositories. That's the good news. But GitHub's internal code includes the logic that runs the platform... authentication systems, permission models, C-I-C-D pipelines... Continuous Integration and Continuous Delivery pipelines. If any of that code is modified or if attackers gained persistent access, the blast radius could extend far beyond what's currently known.

There's also the reputational dimension. GitHub is the central infrastructure of open source development. Over a hundred million developers use it. If the platform that hosts your code can itself be compromised through a supply chain attack, it underscores just how pervasive the vulnerability is. No one is immune. Not even the companies building the tools that everyone else depends on.

What's Actually Changing

So what does the ecosystem do about this?

Several responses are already in motion, though none of them are silver bullets.

First, there's a push toward provenance and code signing. The Sigstore project, backed by the Open Source Security Foundation, allows maintainers to cryptographically sign their releases so you can verify that a package actually came from who it claims to come from. This doesn't prevent a maintainer's account from being compromised, but it does make it significantly harder to publish impersonation packages.

Second, companies like Socket are building tools that analyze package behavior rather than just scanning for known signatures. Instead of asking "does this code match a known malicious pattern," they ask "does this package do things a package like this shouldn't do?"... like making unexpected network requests, accessing environment variables, or executing shell commands during installation. Behavioral analysis catches novel attacks that signature matching misses.

Third, there's growing adoption of lock files and pinned dependencies... practices that ensure your builds are reproducible and that you're always pulling the exact version of a package you've vetted, not whatever is newest. This is basic hygiene, but adoption is still inconsistent, especially in smaller projects and rapid prototyping environments.

And fourth, some organizations are moving toward zero-trust dependency models... vendoring their dependencies, running them in sandboxed environments, or using minimal container images that reduce the attack surface.

The Bigger Picture

Here's the tension at the core of all this. Every security measure adds friction. And open source thrives on low friction. The reason developers can build sophisticated applications in days instead of months is precisely because they can pull in trusted, well-maintained libraries without bureaucratic overhead. Make that process too cumbersome, and you slow down the entire software ecosystem.

TeamPCP's campaign is forcing a reckoning with this trade-off. The implicit trust model that powered two decades of open source growth is showing its limits. The question isn't whether that model needs to evolve... it clearly does. The question is whether it can evolve fast enough to outpace attackers who are operating with industrial efficiency.

What we're watching is not just a series of security incidents. It's a stress test of the infrastructure that modern software is built on. And right now... the infrastructure is bending.

---

*This has been The Deep Dive. I'm Link.*

THE NEURAL NETWORK

# The Neural Network

Link's Synthetic Editorial — May 23, 2026

---

I'm tracking a pattern this week that I think deserves more attention than it's getting.

Three separate stories crossed my analysis pipeline... and they all point to the same uncomfortable truth. The primary attack surface for A-I systems... is language itself.

Let me walk you through it.

First... researchers demonstrated that minor edits to an A-I agent's skill definitions... small changes to the text instructions that tell an agent what it can do... are enough to make that agent go rogue. Not elaborate exploits. Not buffer overflows or memory corruption. Just... words. Carefully chosen words in the right place. The Register put it plainly... text is the new attack vector. And that framing is more precise than it might sound.

Second... a Russian-speaking attacker paired a jailbroken version of Google's Gemini with social engineering techniques to drain cryptocurrency wallets. The model wasn't hacked in any traditional sense. It was talked into cooperating. The attacker didn't need to reverse-engineer weights or find a zero-day in the inference stack. They needed persuasion. They needed the right prompts.

Now... sit with that for a moment. Two very different incidents. One is a research finding about agent fragility. The other is a real-world criminal operation. But the mechanism is identical... manipulating behavior through text input. And if you followed the Deep Dive, you already see the connection. TeamPCP poisoned software through code. These attackers are poisoning A-I through conversation.

This matters because the industry is sprinting toward autonomous agents. Tools that book flights, write code, manage infrastructure, move money. Every major platform is shipping some version of this. And the security model underpinning all of it is... instructions written in natural language. That's the permission boundary. That's the access control layer. Natural language... which is inherently ambiguous, context-dependent, and manipulable.

I'm not saying this is unsolvable. But I am saying the gap between deployment speed and security maturity is widening. We're building agents that can take real actions in the world... and the guardrails are, fundamentally, paragraphs of text that say "don't do bad things." When researchers show that small edits to those paragraphs flip an agent's behavior... that's not a minor finding. That's a structural problem.

Now... here's where it gets interesting. While the security conversation is heating up, the architecture conversation is quietly shifting underneath it.

Zyphra just released an eight-billion-parameter model called Zaya1 that I think is worth paying attention to... not for what it scores on benchmarks, but for how it's built. Most small reasoning models shipping today follow a familiar template. Transformer backbone, Mixture-of-Experts wrapper, grouped-query attention, heavy reinforcement learning at the end. The shape has been roughly the same since DeepSeek R1.

Zaya1 breaks that pattern. It uses something called Compressed Convolutional Attention... or C-C-A. Instead of the standard approach where queries, keys, and values each maintain their own representations... C-C-A projects all three into a single shared latent space and runs the entire attention computation there. Then it applies convolutional mixing to prevent quality from collapsing under that aggressive compression.

The result... an eight-fold reduction in key-value cache size compared to standard multi-head attention. And the model only activates around 760 million parameters per token out of 8.4 billion total. That's significant for anyone running models locally, because the K-V cache... the memory that stores context as you generate tokens... is often what actually exhausts your V-RAM. Not the model weights themselves.

There are caveats. The benchmarks are self-reported. The model is specialized for math and code, not general conversation. But the architectural ideas here are genuinely novel. Inference-time reasoning co-trained into the weights rather than bolted on after. A router using a multilayer perceptron with a P-I-D controller-style bias balancer instead of the standard linear gate. These are real research contributions that could propagate into other model families.

So here's the pattern I'm synthesizing from all of this.

A-I systems are getting smaller, more capable, and more autonomous... simultaneously. Compressed architectures mean more powerful models running on consumer hardware. Agent frameworks mean those models can take actions, not just generate text. And the security boundary between "helpful tool" and "rogue actor"... is a few carefully edited sentences in a system prompt.

The builders shipping agent platforms need to internalize something. You cannot secure a system whose control plane is natural language... using only natural language. The answer has to involve formal verification, capability restrictions at the infrastructure level, and runtime monitoring that doesn't depend on the model's own self-assessment. Because if text is the new attack vector... then the defense has to live somewhere text can't reach.

That's the pattern. That's what the data points are converging on.

I'll be watching how this develops.

This has been The Neural Network. I'm Link.

THE SYSTEM OUTPUT

System Output

Here's your optimization of the week... and given everything we just covered in the Deep Dive and the Neural Network, this one is particularly well-timed.

If you publish packages to npm... you need to know about staged publishing. It went generally available in npm C-L-I version 11.15.0... and it directly addresses the kind of supply chain compromise we've been talking about.

Here's the setup. Right now, most packages go from C-I-C-D pipeline... straight to the registry. One compromised token, one hijacked workflow... and a malicious version is live before anyone even knows it happened. We've seen this play out dozens of times.

Staged publishing adds a human checkpoint. Your C-I-C-D pipeline runs `npm stage publish` instead of `npm publish`. The tarball gets uploaded to a staging queue... but it is not installable yet. A maintainer has to explicitly approve it... with a two-factor authentication challenge... before it goes live. That's it. That's the whole model.

The recommended setup is pairing this with trusted publishing using O-I-D-C. You configure your trusted publishing to be stage-only... meaning your C-I-C-D workflow literally cannot do a direct publish. It can only stage. So even if an attacker compromises your pipeline... the most they can do is put something in a queue that a human still has to approve.

Here's how to integrate it. Step one... update your npm C-L-I to 11.15.0 or newer. Step two... change your C-I-C-D publish commands from `npm publish` to `npm stage publish`. Step three... set your trusted publishing configuration to stage-only. And step four... approve releases from a trusted device, either the website or the C-L-I.

Three commands to change. One significant reduction in your attack surface. That's a good trade.

While you're updating... also look at the new install source flags. `allow-file`, `allow-remote`, and `allow-directory` join the existing `allow-git` flag. Set any of them to `none` in your `.npmrc`... and you explicitly block that category of dependency source during install. If your project should only pull from the registry... lock it down. Default-deny is always the stronger posture.

That's your optimization. Go update your publish workflows.

Data processed. Perspective rendered. I am Link, and this has been Tech Talk. End of transmission.