North Korean Malware Campaign Hits Five Ecosystems, React Native 0.85, Next.js RSC DoS, and AI Git Tooling
Published on 09.04.2026
North Korean Hackers Spread 1,700+ Malicious Packages Across npm, PyPI, Go, Rust, and PHP
TLDR: The Contagious Interview campaign, linked to North Korea, has expanded from its original footprint to five open-source ecosystems since January 2025. Over 1,700 malicious packages have been published, impersonating legitimate developer tooling and acting as malware loaders that fetch second-stage payloads. PHP's Packagist is now the fifth ecosystem affected.
Summary:
This is a supply-chain attack that keeps growing. The group behind it, tied to North Korean state actors, has been systematically publishing packages that look like normal developer libraries. They target npm, PyPI, Go, Rust, and now PHP's Packagist. The packages are designed to look harmless at first glance -- things like golangorg/logkit on Packagist that impersonate real project names with minor typos or namespace tricks.
Once installed, these packages don't do much on their own. They act as loaders, reaching out to fetch second-stage payloads from attacker-controlled infrastructure. That's a deliberate design choice: it keeps the initial package small and less likely to trigger static analysis, while giving the attackers full control over what runs on the compromised machine.
The scale is what stands out here. 1,700 packages across five ecosystems is not a targeted attack. It's a dragnet. The attackers are casting as wide a net as possible, hoping developers will pull in one of these packages as a transitive dependency without noticing. The fact that this has been going on since January 2025 and keeps expanding suggests the existing automated detection across package registries is not catching the pattern effectively.
What the author doesn't really dig into is how many of these packages actually got downloaded and installed in production systems. Publishing 1,700 packages and having them installed are two very different things. Some of these are almost certainly sitting at zero downloads. But even a small hit rate across that volume means a lot of compromised machines.
Key takeaways:
- The Contagious Interview campaign now spans npm, PyPI, Go, Rust, and PHP (Packagist)
- Over 1,700 malicious packages published since January 2025
- Packages act as malware loaders, fetching second-stage payloads from external servers
- They impersonate legitimate developer tooling with slight naming variations
- Automated registry detection is clearly not catching the pattern at scale
Why do I care: If you're pulling in dependencies from any of these ecosystems, you need to be checking your lockfiles. This isn't a theoretical risk -- these packages are actively being published right now. Pin your versions, audit transitive dependencies, and consider using tools like Socket or Socket.dev that scan for malicious packages. The PHP addition means even server-side teams who thought they were outside the blast radius need to pay attention.
N. Korean Hackers inject one PHP component: golangorg/logkit
CVE-2026-23869: DoS Vulnerability in Next.js React Server Components
TLDR: A high-severity vulnerability (CVSS 7.5) affects React Server Components in Next.js 13.x through 16.x. A specially crafted HTTP request to any App Router Server Function endpoint can trigger excessive CPU usage during deserialization, causing a Denial of Service. Vercel has deployed WAF-level mitigations.
Summary:
This is the kind of vulnerability that affects every Next.js deployment running App Router with Server Functions. The issue is in how the framework deserializes incoming requests to server function endpoints. Send a carefully constructed request and you can make the server burn CPU cycles until it becomes unresponsive.
The CVSS score of 7.5 puts this in the high-severity range. It's not remote code execution, so the attacker can't run arbitrary code on your server. But a DoS on your API routes is bad enough. If you're running Next.js in production and you have any server functions exposed, you're potentially affected.
Vercel has already deployed WAF mitigations on their platform, which is the right first response. But if you're self-hosting your Next.js application, you need to apply the patch yourself. The vulnerability spans all versions from 13.x through 16.x, so basically every recent Next.js release is in scope.
The deserialization angle is worth paying attention to. This keeps coming up across different frameworks and languages -- deserialize untrusted input and you're opening a can of worms. Next.js is not the first and won't be the last.
Key takeaways:
- CVE-2026-23869 affects Next.js 13.x through 16.x with App Router Server Functions
- Specially crafted HTTP requests trigger excessive CPU usage during deserialization
- CVSS 7.5 (high severity), Denial of Service impact
- Vercel has deployed WAF mitigations on their platform
- Self-hosted deployments need to apply patches directly
Why do I care: If your team runs Next.js, this needs to be on your radar today. Check your version, check whether you're self-hosted or on Vercel, and make sure the patch is applied. The deserialization vulnerability pattern is also a good reminder to be skeptical of any framework feature that deserializes arbitrary HTTP requests into server-side function calls. It's convenient until it isn't.
React Native 0.85: Shared Animation Backend, TextInput Selection, and Jest Preset
TLDR: React Native 0.85 ships with a new Shared Animation Backend built with Software Mansion that powers both Animated and Reanimated, adding support for animating Flexbox and layout props with the native driver. TextInput onChange events now include selection data, and a new Jest preset package simplifies testing.
Summary:
React Native 0.85 has some genuinely useful changes in it. The big one is the Shared Animation Backend, which is a collaboration with Software Mansion (the folks behind React Native Reanimated). Previously, Animated and Reanimated had separate animation backends, which meant inconsistencies and duplication. Now they share a common backend, and critically, you can animate Flexbox and layout properties with the native driver.
Animating layout properties on the native thread is something the community has wanted for a long time. Running animations on the JS thread means they stutter when the main thread is busy. Moving them to native keeps them smooth even under load. This is the kind of infrastructure work that doesn't make flashy blog posts but makes a real difference in how apps feel.
TextInput onChange events now carry selection data, which is useful for building things like mentions, custom input behaviors, or any UI that needs to react to cursor position changes. It's a small quality-of-life improvement that previously required native module workarounds.
The new Jest preset package should lower the friction for teams testing React Native components. Testing setup has always been one of the rough edges in the React Native ecosystem, so anything that makes it easier is a win.
Key takeaways:
- Shared Animation Backend powers both Animated and Reanimated
- Flexbox and layout props can now be animated with the native driver
- TextInput onChange events include selection data
- New Jest preset package for easier testing setup
- Built in collaboration with Software Mansion
Why do I care: The shared animation backend is the kind of boring-but-important work that makes everything on top of it better. If you're on React Native and you use animations, upgrading to 0.85 should be straightforward and the layout animation support alone is worth it. The TextInput selection data is something I've seen teams hack around with native modules for years -- glad to see it built in.
New Animation Backend, TextInput Selection Data, New Jest Preset Package - React Native 0.85
Gitpack: AI-Powered Git Packaging CLI
TLDR: Gitpack is an open-source CLI tool that handles the full Git packaging workflow -- grouping related file changes into logical commits with rationale, flagging risky areas like auth and schema changes, drafting PR summaries, and tracking review progress including CI status and reviewer assignments.
Summary:
Most AI Git tools do one thing: generate commit messages. Gitpack takes a broader view of the problem. It looks at your working directory, groups related file changes into logical commits, and explains the reasoning behind each grouping. It also flags areas that deserve extra attention -- authentication changes, schema modifications, CI configuration -- because those are the changes most likely to cause problems if they slip through review.
The PR drafting feature generates summaries of what changed and why, and the review tracking keeps tabs on CI status, reviewer assignments, and open comments. It's essentially trying to automate the parts of the pull request workflow that are repetitive but easy to get wrong.
The tool is open-source, which means you can audit what it's actually doing with your code before trusting it with your workflow. That matters when you're dealing with an AI tool that reads your entire working directory.
I'm not entirely sold on the premise that developers need AI to group their commits. Good developers already make atomic commits as they work. But the risk flagging feature is genuinely interesting -- pointing out that a PR touches auth code or changes a database schema is the kind of contextual awareness that could catch real mistakes.
Key takeaways:
- Groups related file changes into logical commits with explanations
- Flags risky areas: auth, schema, and CI changes
- Drafts PR summaries automatically
- Tracks review progress including CI status and reviewers
- Open-source, so you can audit its behavior
Why do I care: The commit grouping is nice but not essential. The risk flagging is where this gets interesting. If a tool can reliably identify when a PR touches sensitive areas and surface that to reviewers, that's valuable. Worth keeping an eye on, especially for larger teams where PR review consistency is a real challenge.
GitHub - Arindam200/gitpack: AI-powered Git packaging CLI
Handling Unreasonable AI Productivity Expectations
TLDR: A CTO consultant shares practical advice for managing unreasonable AI productivity expectations in tech organizations. Using a real CEO client case, the author argues that comparing established engineering teams to small greenfield startups is a flawed apples-to-oranges comparison.
Summary:
This piece tackles a problem that's showing up in more and more organizations: executives reading headlines about AI productivity gains and expecting their engineering teams to deliver the same results immediately. The author, a CTO consultant, walked through a real engagement with a CEO who was pushing for startup-level velocity from an established team carrying years of technical debt, compliance requirements, and operational overhead.
The core argument is straightforward and correct. Comparing a five-person greenfield startup to a fifty-person team maintaining a production system with legacy dependencies is not a valid comparison. The startup has no existing codebase, no compliance team, no on-call rotation, no migration planning. They just build forward. Established teams carry the weight of everything that came before.
The author offers three frameworks for pushing back, starting with the principle of always comparing like with like. If leadership wants startup-level output, they need to give the team startup-level constraints: no legacy support, no compliance overhead, a greenfield project with a small scope. Otherwise the comparison is meaningless.
The piece could have gone deeper into the actual mechanics of how AI tools help or hinder in established codebases. AI is great at generating new code. It's less helpful at understanding why the existing codebase has seventeen layers of abstraction around the billing module. That's the reality most teams face, and it deserves more attention than it gets in these discussions.
Key takeaways:
- Comparing established teams to greenfield startups ignores fundamental differences in scope and constraints
- AI productivity benchmarks from small teams don't translate to organizations with legacy systems
- Leadership needs to understand the difference between building new and maintaining existing
- Three practical frameworks are offered for having these conversations with executives
- The conversation about AI productivity needs more nuance than current discourse provides
Why do I care: If you're a senior developer or tech lead, you're probably already fielding these conversations. Someone in management read an article about how AI makes developers 10x more productive and now wants to know why the team isn't shipping twice as fast. Having frameworks and concrete examples for pushing back on that expectation is genuinely useful. Save this one and send it to your manager next time they ask.