Within three to six months, 9000% of all new code will be written by AI.
February 12, 2026 at 6:49 PM
Within three to six months, 9000% of all new code will be written by AI.
New @react.dev patches released today for CVE-2026-23864. Fixes for DoS issues reported by several people, including Yours Truly 🙂
The blog post at react.dev/blog/2025/12... has been updated with the new info.
The blog post at react.dev/blog/2025/12... has been updated with the new info.
Denial of Service and Source Code Exposure in React Server Components – React
The library for web and native user interfaces
react.dev
January 26, 2026 at 7:54 PM
New @react.dev patches released today for CVE-2026-23864. Fixes for DoS issues reported by several people, including Yours Truly 🙂
The blog post at react.dev/blog/2025/12... has been updated with the new info.
The blog post at react.dev/blog/2025/12... has been updated with the new info.
O(n²) works great until n+1.
January 26, 2026 at 12:10 PM
O(n²) works great until n+1.
me: move fast and break things
my dentist: what
my dentist: what
January 20, 2026 at 1:46 PM
me: move fast and break things
my dentist: what
my dentist: what
Reposted by Joachim Viide
The way you handled my semi-coherent devalue reports only reinforced my already high opinion of the Svelte team.
January 16, 2026 at 11:58 AM
The way you handled my semi-coherent devalue reports only reinforced my already high opinion of the Svelte team.
Huge props to the @svelte.dev team for an exceptionally well-handled vulnerability process, despite my terrible timing of reporting the devalue issues just before New Year’s Eve 🙂
We've released fixes for 5 CVEs affecting the Svelte ecosystem. Please upgrade your apps!
Read the post to learn if you're affected:
svelte.dev/blog/cves-af...
Read the post to learn if you're affected:
svelte.dev/blog/cves-af...
CVEs affecting the Svelte ecosystem
Time to upgrade
svelte.dev
January 15, 2026 at 7:36 PM
Huge props to the @svelte.dev team for an exceptionally well-handled vulnerability process, despite my terrible timing of reporting the devalue issues just before New Year’s Eve 🙂
AND THEY EXPECT US TO BELEIVE THIS IS "JUST A COINCIDENCE" ?? !?
January 12, 2026 at 2:53 PM
AND THEY EXPECT US TO BELEIVE THIS IS "JUST A COINCIDENCE" ?? !?
OPEN YOU'RE EYES 👁️👄👁️
January 12, 2026 at 11:50 AM
OPEN YOU'RE EYES 👁️👄👁️
Reposted by Joachim Viide
Pretty cool that you have to create a Facebook account to file a vulnerability report to Meta.
January 8, 2026 at 3:22 PM
Pretty cool that you have to create a Facebook account to file a vulnerability report to Meta.
TIL there's a VSCode setting called chat.disableAIFeatures.
January 6, 2026 at 12:43 AM
TIL there's a VSCode setting called chat.disableAIFeatures.
Wishing you all an Extralight Semibold New Year! soundcloud.com/extralight-s...
Starberry Jam
Listen to Starberry Jam by Extralight Semibold #np on #SoundCloud
soundcloud.com
January 4, 2026 at 7:40 PM
Wishing you all an Extralight Semibold New Year! soundcloud.com/extralight-s...
Turns out that the gym app has a Year in Review feature, and I'm now contemplating a side hustle as a part-time nutcracker.
December 30, 2025 at 10:27 PM
Turns out that the gym app has a Year in Review feature, and I'm now contemplating a side hustle as a part-time nutcracker.
Reposted by Joachim Viide
Merriam-Webster’s human editors have chosen ‘slop’ as the 2025 Word of the Year.
December 15, 2025 at 2:07 PM
Merriam-Webster’s human editors have chosen ‘slop’ as the 2025 Word of the Year.
Last month was one of those years that feel like a decade.
December 15, 2025 at 10:35 AM
Last month was one of those years that feel like a decade.
In the end, it would be best if NPM just blocked TOTP reuse.
TOTP stands for “Time-based One-Time Password,” after all. The “one-time” property is important enough to account for 50% of the acronym. 🙂
Even the spec explicitly calls for blocking reuse: datatracker.ietf.org/doc/html/rfc... 6/6
TOTP stands for “Time-based One-Time Password,” after all. The “one-time” property is important enough to account for 50% of the acronym. 🙂
Even the spec explicitly calls for blocking reuse: datatracker.ietf.org/doc/html/rfc... 6/6
December 12, 2025 at 1:08 PM
In the end, it would be best if NPM just blocked TOTP reuse.
TOTP stands for “Time-based One-Time Password,” after all. The “one-time” property is important enough to account for 50% of the acronym. 🙂
Even the spec explicitly calls for blocking reuse: datatracker.ietf.org/doc/html/rfc... 6/6
TOTP stands for “Time-based One-Time Password,” after all. The “one-time” property is important enough to account for 50% of the acronym. 🙂
Even the spec explicitly calls for blocking reuse: datatracker.ietf.org/doc/html/rfc... 6/6
What should you do as a package maintainer?
I’d argue that “don’t get phished” isn’t very constructive advice. To err is human.
Upgrading to phishing-resistant 2FA methods such as passkeys is a good idea. See docs.npmjs.com/configuring-...
But this would require all maintainers to act. 5/
I’d argue that “don’t get phished” isn’t very constructive advice. To err is human.
Upgrading to phishing-resistant 2FA methods such as passkeys is a good idea. See docs.npmjs.com/configuring-...
But this would require all maintainers to act. 5/
Configuring two-factor authentication | npm Docs
Documentation for the npm registry, website, and command-line interface
docs.npmjs.com
December 12, 2025 at 1:08 PM
What should you do as a package maintainer?
I’d argue that “don’t get phished” isn’t very constructive advice. To err is human.
Upgrading to phishing-resistant 2FA methods such as passkeys is a good idea. See docs.npmjs.com/configuring-...
But this would require all maintainers to act. 5/
I’d argue that “don’t get phished” isn’t very constructive advice. To err is human.
Upgrading to phishing-resistant 2FA methods such as passkeys is a good idea. See docs.npmjs.com/configuring-...
But this would require all maintainers to act. 5/
So, with a single phished NPM TOTP token + password combo, a well-prepared (automated?) attacker can quickly list your packages, downgrade some of their publishing requirements, and then create a granular token.
This extends the attacker's window for publishing nasty versions of your packages. 4/
This extends the attacker's window for publishing nasty versions of your packages. 4/
December 12, 2025 at 1:08 PM
So, with a single phished NPM TOTP token + password combo, a well-prepared (automated?) attacker can quickly list your packages, downgrade some of their publishing requirements, and then create a granular token.
This extends the attacker's window for publishing nasty versions of your packages. 4/
This extends the attacker's window for publishing nasty versions of your packages. 4/
The “require 2FA for publishing” setting can’t be downgraded without a 2FA check.
But the attacker can reuse the phished TOTP code to perform a downgrade and allow publishing with “a granular access token with bypass 2FA enabled.”
Granular access tokens can be created without any 2FA checks. 3/
But the attacker can reuse the phished TOTP code to perform a downgrade and allow publishing with “a granular access token with bypass 2FA enabled.”
Granular access tokens can be created without any 2FA checks. 3/
December 12, 2025 at 1:08 PM
The “require 2FA for publishing” setting can’t be downgraded without a 2FA check.
But the attacker can reuse the phished TOTP code to perform a downgrade and allow publishing with “a granular access token with bypass 2FA enabled.”
Granular access tokens can be created without any 2FA checks. 3/
But the attacker can reuse the phished TOTP code to perform a downgrade and allow publishing with “a granular access token with bypass 2FA enabled.”
Granular access tokens can be created without any 2FA checks. 3/
In NPM, a package can be configured to require 2FA for publishing (“Require two-factor authentication and disallow tokens”).
However, if an attacker phishes your password and a valid TOTP code, they can reuse them to publish packages in your name.
But at least the time window is limited, right? 2/
However, if an attacker phishes your password and a valid TOTP code, they can reuse them to publish packages in your name.
But at least the time window is limited, right? 2/
December 12, 2025 at 1:08 PM
In NPM, a package can be configured to require 2FA for publishing (“Require two-factor authentication and disallow tokens”).
However, if an attacker phishes your password and a valid TOTP code, they can reuse them to publish packages in your name.
But at least the time window is limited, right? 2/
However, if an attacker phishes your password and a valid TOTP code, they can reuse them to publish packages in your name.
But at least the time window is limited, right? 2/
To recap, NPM allows 2FA TOTP token reuse within the token’s validity window.
I reported this and was told it’s a “known low-risk issue” and that they “don’t consider this to present a significant security risk.”
So, let’s look at how this seemingly small issue could be leveraged by a phisher. 1/
I reported this and was told it’s a “known low-risk issue” and that they “don’t consider this to present a significant security risk.”
So, let’s look at how this seemingly small issue could be leveraged by a phisher. 1/
Seems that NPM too allows TOTP reuse within the time-step window. Seen a similar issue in multiple services over the years.
Per RFC 6238, a TOTP (Time-based One-Time Password) should be single-use. Allowing reuse, even within the short-ish time window, is not ideal (shoulder surfing, phishing etc.)
Per RFC 6238, a TOTP (Time-based One-Time Password) should be single-use. Allowing reuse, even within the short-ish time window, is not ideal (shoulder surfing, phishing etc.)
December 12, 2025 at 1:08 PM
To recap, NPM allows 2FA TOTP token reuse within the token’s validity window.
I reported this and was told it’s a “known low-risk issue” and that they “don’t consider this to present a significant security risk.”
So, let’s look at how this seemingly small issue could be leveraged by a phisher. 1/
I reported this and was told it’s a “known low-risk issue” and that they “don’t consider this to present a significant security risk.”
So, let’s look at how this seemingly small issue could be leveraged by a phisher. 1/
Reposted by Joachim Viide
Update on React Server Components CVE-2025-55182: over 165K IPs & 644K domains with vulnerable code found on 2025-12-08 after scan targeting improvements!
See: dashboard.shadowserver.org/statistics/c...
Check for compromise & patch!
Thank you to Validin & LeakIX for the collaboration!
See: dashboard.shadowserver.org/statistics/c...
Check for compromise & patch!
Thank you to Validin & LeakIX for the collaboration!
December 9, 2025 at 4:24 PM
Update on React Server Components CVE-2025-55182: over 165K IPs & 644K domains with vulnerable code found on 2025-12-08 after scan targeting improvements!
See: dashboard.shadowserver.org/statistics/c...
Check for compromise & patch!
Thank you to Validin & LeakIX for the collaboration!
See: dashboard.shadowserver.org/statistics/c...
Check for compromise & patch!
Thank you to Validin & LeakIX for the collaboration!
From the thread: "Attacks from bot compromised Next.js assets spiked on 2025-12-05 from the usual 100 IP baseline to close to a 1000."
If you're not 100% sure you're NOT vulnerable, you should patch your Next.js apps ASAP.
And if you're 100% sure... patch anyway.
If you're not 100% sure you're NOT vulnerable, you should patch your Next.js apps ASAP.
And if you're 100% sure... patch anyway.
Like others we are seeing attacks attempting to exploit React CVE-2025-55182 at scale, incl. botnet related activity. How successful have these attacks been? You can get a view here, where we track compromised host with Next.js attacking our sensors:
dashboard.shadowserver.org/statistics/h...
dashboard.shadowserver.org/statistics/h...
December 8, 2025 at 6:12 PM
From the thread: "Attacks from bot compromised Next.js assets spiked on 2025-12-05 from the usual 100 IP baseline to close to a 1000."
If you're not 100% sure you're NOT vulnerable, you should patch your Next.js apps ASAP.
And if you're 100% sure... patch anyway.
If you're not 100% sure you're NOT vulnerable, you should patch your Next.js apps ASAP.
And if you're 100% sure... patch anyway.