may be a stupid question but, why is there no context handling system that just discards tokens from processing if they are not deemed required so that it doesn't clutter with useless tokens?
Do It by Code
may be a stupid question but, why is there no context handling system that just discards tokens from processing if they are not deemed required so that it doesn't clutter with useless tokens?
The short answer is: we are trying to build exactly that, but it is incredibly difficult to define "useless" before it's too late.
In fact, there is a lot of active research into this (techniques like "Token Pruning," "Sparse Attention," or "Selective Context"), but they haven't become the standard yet for a few specific reasons.
### 1. The "Whodunit" Problem (Predicting Relevance)
The main issue is that a token's "usefulness" is not a static property. A word that seems like filler in sentence 1 might be the critical key to understanding a reference in sentence 50.
* Dynamic Importance: To know if a token is useless, the model effectively has to "read" it and understand its relationship to the *future* response. By the time it has done the math to figure out "I don't need this," it has already spent the compute processing it.
* Hindsight is 20/20: Systems that do this often have to guess. If they guess wrong and discard a token that turns out to be crucial later, the model creates a "hallucination" or loses coherence because the context is literally missing.
### 2. The "Attention Sink" Phenomenon
This is a really weird quirk of how Transformer models (the architecture behind GPT, Claude, Gemini) work mathematically.
* Researchers found that models often dump a huge amount of "attention" score onto tokens that seem meaningless (like the very first token in a sentence, or random punctuation).
* If you delete these "useless" tokens, the model's math breaks down and it starts spewing nonsense. These are called "Attention Sinks." The model essentially uses these tokens as a garbage dump for extra probability mass so it doesn't get confused. You can't just delete them without retraining the model to handle it.[1]
### 3. It Breaks the Flow
Language is a sequence.[1] Even "useless" filler words (like "um," "so," "basically") carry prosody and structural information that helps the model maintain a conversational rhythm.
* If you aggressively strip these out, the model might turn into a keyword-generating robot rather than a fluent assistant.
* LazyLLM & Sparse Attention: There are newer techniques (like *LazyLLM* or *H2O*) that try to dynamically keep only the "heavy hitters" (tokens that get high attention scores) and drop the rest. This is working in labs, but deploying it at scale without degrading quality is still a massive engineering hurdle.
### Summary
We essentially have to choose between speed/efficiency (pruning tokens) and intelligence/accuracy (keeping everything just in case). Currently, it's safer to just "eat" the cost of processing useless tokens than to risk throwing away the one key detail that changes the answer.
===
Citations:
===
Model: Gemini 3 Pro (Preview) (high reasoning, with search)
In fact, there is a lot of active research into this (techniques like "Token Pruning," "Sparse Attention," or "Selective Context"), but they haven't become the standard yet for a few specific reasons.
### 1. The "Whodunit" Problem (Predicting Relevance)
The main issue is that a token's "usefulness" is not a static property. A word that seems like filler in sentence 1 might be the critical key to understanding a reference in sentence 50.
* Dynamic Importance: To know if a token is useless, the model effectively has to "read" it and understand its relationship to the *future* response. By the time it has done the math to figure out "I don't need this," it has already spent the compute processing it.
* Hindsight is 20/20: Systems that do this often have to guess. If they guess wrong and discard a token that turns out to be crucial later, the model creates a "hallucination" or loses coherence because the context is literally missing.
### 2. The "Attention Sink" Phenomenon
This is a really weird quirk of how Transformer models (the architecture behind GPT, Claude, Gemini) work mathematically.
* Researchers found that models often dump a huge amount of "attention" score onto tokens that seem meaningless (like the very first token in a sentence, or random punctuation).
* If you delete these "useless" tokens, the model's math breaks down and it starts spewing nonsense. These are called "Attention Sinks." The model essentially uses these tokens as a garbage dump for extra probability mass so it doesn't get confused. You can't just delete them without retraining the model to handle it.[1]
### 3. It Breaks the Flow
Language is a sequence.[1] Even "useless" filler words (like "um," "so," "basically") carry prosody and structural information that helps the model maintain a conversational rhythm.
* If you aggressively strip these out, the model might turn into a keyword-generating robot rather than a fluent assistant.
* LazyLLM & Sparse Attention: There are newer techniques (like *LazyLLM* or *H2O*) that try to dynamically keep only the "heavy hitters" (tokens that get high attention scores) and drop the rest. This is working in labs, but deploying it at scale without degrading quality is still a massive engineering hurdle.
### Summary
We essentially have to choose between speed/efficiency (pruning tokens) and intelligence/accuracy (keeping everything just in case). Currently, it's safer to just "eat" the cost of processing useless tokens than to risk throwing away the one key detail that changes the answer.
===
Citations:
[1] lesswrong.com
===
Model: Gemini 3 Pro (Preview) (high reasoning, with search)
Critical RCE Vulnerabilities in React and Next.js
Severity: 10/10
- react blog
- github advisory
- vercel blog
- fix-react2shell-next (quick fix repo by vercel)
#rce #react #nextjs #cve
Severity: 10/10
The important part to know:
- Even if your app does not implement any React Server Function endpoints it may still be vulnerable if your app supports React Server Components.
- The vulnerability is present in versions 19.0, 19.1.0, 19.1.1, and 19.2.0 of: react-server-dom-webpack, react-server-dom-parcel, react-server-dom-turbopack
- Some React frameworks and bundlers depended on, had peer dependencies for, or included the vulnerable React packages. The following React frameworks & bundlers are affected: next, react-router, waku, @parcel/rsc, @vitejs/plugin-rsc, and rwsdk.
- react blog
- github advisory
- vercel blog
- fix-react2shell-next (quick fix repo by vercel)
#rce #react #nextjs #cve
Do It by Code
Critical RCE Vulnerabilities in React and Next.js Severity: 10/10 The important part to know: - Even if your app does not implement any React Server Function endpoints it may still be vulnerable if your app supports React Server Components. - The vulnerability…
from HN comments:
our exploitation tests so far have shown that a standard Next.js application created via create-next-app and built for production is vulnerable to CVE-2025-66478 without any specific code modifications by the developer - so this is essentially exploitable out-of-the-box.
our exploitation tests so far have shown that a standard Next.js application created via create-next-app and built for production is vulnerable to CVE-2025-66478 without any specific code modifications by the developer - so this is essentially exploitable out-of-the-box.
Do It by Code
Critical RCE Vulnerabilities in React and Next.js Severity: 10/10 The important part to know: - Even if your app does not implement any React Server Function endpoints it may still be vulnerable if your app supports React Server Components. - The vulnerability…
wow vercel is emailing all of their users about it
"of two competing theories, the simpler explanation of an entity is to be preferred."
https://en.wikipedia.org/wiki/Occam%27s_razor
https://en.wikipedia.org/wiki/Occam%27s_razor
Do It by Code
Critical RCE Vulnerabilities in React and Next.js Severity: 10/10 The important part to know: - Even if your app does not implement any React Server Function endpoints it may still be vulnerable if your app supports React Server Components. - The vulnerability…
apparently there are so many AI-generated slop PoC out there for this that it takes hours to find a proper working PoC among them
most of them are just nonsense
I found a few that don't seem to be AI slop:
- msanft/CVE-2025-55182
- acheong08/CVE-2025-55182-detection
- mrknow001/RSC_Detector
- emredavut/CVE-2025-55182
one of the AI-generated ones made its way to the official cve website and people complained in its issue section
most of them are just nonsense
I found a few that don't seem to be AI slop:
- msanft/CVE-2025-55182
- acheong08/CVE-2025-55182-detection
- mrknow001/RSC_Detector
- emredavut/CVE-2025-55182
one of the AI-generated ones made its way to the official cve website and people complained in its issue section
Do It by Code
- mrknow001/RSC_Detector
exploitation of CVE-2025-55182 has reached a new level. There’s now a publicly available Chrome extension on GitHub that automatically scans for and exploits vulnerable sites as you browse.
source - @sbrugnadlbot
A year ago, we verified a preview of an unreleased version of @OpenAI o3 (High) that scored 88% on ARC-AGI-1 at est. $4.5k/task
Today, we’ve verified a new GPT-5.2 Pro (X-High) SOTA score of 90.5% at $11.64/task
This represents a ~390X efficiency improvement in one year
Hacker News
Denial of service and source code exposure in React Server Components Article, Comments
The patches published earlier are vulnerable.
If you already updated for the Critical Security Vulnerability last week, you will need to update again 😇
Or just don't use javascript and react in backend
If you already updated for the Critical Security Vulnerability last week, you will need to update again 😇
Or just don't use javascript and react in backend
Telegram is updating its censorship circumvention code to mimic Google Chrome's Post-Quantum Cryptography handshake (the TLS fingerprinting)
ml_kem_768_key function in this commit is a function that generates a fake ML-KEM-768 (Kyber) key so that deep packet inspection firewalls (DPI) think the packet just belongs to google chrome sending data over TLS, but Telegram servers likely ignore these random bytes and just uses the underlying MTProto encryption insteadCVE-2025-14174 (works only on Mac)
Out of bounds memory access in ANGLE in Google Chrome on Mac prior to 143.0.7499.110 allowed a remote attacker to perform out of bounds memory access via a crafted HTML page. (Chromium security severity: High)
couldn't find any PoC for it and since I don't have mac, I can't really test it
#cve
Out of bounds memory access in ANGLE in Google Chrome on Mac prior to 143.0.7499.110 allowed a remote attacker to perform out of bounds memory access via a crafted HTML page. (Chromium security severity: High)
couldn't find any PoC for it and since I don't have mac, I can't really test it
#cve