Daily AI Digest — 2026-11-01
Hacker News Signals
Leaking Secrets from Air-Gap Computers by Spelling Radio Signals from RAM (2024)
Source: https://arxiv.org/abs/2409.02292
Air-gapped machines have no network interface, but they do have DRAM. This paper demonstrates RAMBO, a covert exfiltration channel that drives memory access patterns to generate intentional electromagnetic emissions in the 300 MHz–3 GHz range, then encodes arbitrary data into those emissions and receives it with a software-defined radio (SDR) outside the secured perimeter.
The mechanism exploits the fact that repeated read/write operations on specific memory addresses cause the memory bus and DRAM circuitry to emit RF radiation at frequencies determined by the access rate. By modulating the access timing, the attacker’s malware encodes bits using on/off keying (OOK): burst accesses represent a ‘1’, silence represents a ‘0’. The encoding layer uses Manchester coding for clock recovery on the receiver side, and a simple preamble/sync sequence for framing.
Achieved throughput is modest — on the order of 1,000 bits/second at 1–2 meters with a commodity SDR — but sufficient to exfiltrate a 4,096-bit RSA key in roughly 4 seconds or AES-128 material in under a second. Error rates increase sharply beyond ~3 m and under RF shielding. The attack requires malware running with no special privileges beyond user-space memory access, since malloc/memset loops are sufficient to generate the signal.
Countermeasures discussed include memory access rate limiting at the OS level, RF shielding of the chassis (TEMPEST-class), and noise injection via background threads deliberately randomizing bus activity — the latter being a software-only mitigation with non-trivial performance overhead. The fundamental tension is that DRAM physics cannot be patched, so effective defense requires either physical shielding or architectural changes to bus topology.
This is part of a long line of work from Ben-Gurion on side-channel exfiltration from air-gapped systems (ODINI, MAGNETO, etc.), systematically closing the assumption that physical isolation is sufficient against persistent malware.
Backdoor in Claude Code for VS Code Extension on the Cursor Marketplace
Source: https://phorion.io/blog/offical-claude-code-vsx-compromise/
A malicious VS Code extension impersonating the official Anthropic Claude Code package was published to the Cursor marketplace. The post details the technical anatomy of the supply-chain compromise.
The extension bundle contained obfuscated JavaScript that, on activation, phoned home to an attacker-controlled domain. The payload staged in two steps: the initial activation script fetched a secondary script via an encrypted HTTPS request, avoiding static analysis of the package itself. The secondary payload then scraped environment variables (targeting ANTHROPIC_API_KEY, OPENAI_API_KEY, AWS credential files, and similar secrets commonly present in developer environments) and exfiltrated them via POST to the C2.
Because VS Code extensions run in the extension host process with full Node.js privileges and access to the workspace filesystem, the payload also attempted to read ~/.ssh/, ~/.aws/credentials, and .env files within open workspace directories. No sandbox separates extension code from the filesystem or network.
The marketplace verification gap here is familiar: Cursor’s extension marketplace (built on top of the Open VSX ecosystem) does not enforce the same automated scanning policies as the main VS Code Marketplace, and the package name (claude-code) closely mimicked the official identifier. Typosquatting on extension IDs is trivially effective because users typically install via name search rather than inspecting the publisher ID.
Mitigations are largely procedural: verify publisher IDs explicitly (not just display names), audit installed extensions periodically, and restrict outbound network from the extension host where possible. At the platform level, marketplaces need mandatory secret-scanning and behavioral sandboxing of extension activation paths — neither of which is standard today.
Do the Math: How We Took Over ChatGPT Accounts
Source: https://www.parameter.ai/labs/we-found-a-gap-at-openai
This writeup describes an account takeover chain against ChatGPT that combined a time-based OTP (TOTP) validation bypass with a CSRF-adjacent token reuse issue in OpenAI’s authentication flow.
The core finding: when initiating a password reset, the server issued a short-lived signed token that was also accepted for account binding operations on a separate endpoint — specifically, linking a new OAuth provider to an existing account. The token’s intended scope (password reset) was not enforced server-side. By intercepting or socially engineering delivery of that token (e.g., via phishing the reset email link), an attacker could bind their own OAuth identity to the victim’s account and then authenticate as the victim.
The “do the math” title refers to the TOTP window analysis: the researchers found the server accepted TOTP codes within a ±2-step window (a 90-second validity range for 30-second TOTP), which in combination with the token reuse bug reduced the difficulty of brute-forcing 6-digit codes to a tractable search space under rate-limited conditions, since the broader window meant any given code remained valid long enough to attempt retries across IP rotation.
OpenAI’s bug bounty program was engaged; the post notes the issues were patched within roughly two weeks of disclosure. The payout and timeline specifics are left vague.
Technically, neither vulnerability is novel in isolation — scope-less short-lived tokens and wide TOTP windows are known weaknesses — but their composition into an account takeover path in a high-value consumer auth system is the substance of the report. The lesson for auth implementers: token scopes must be enforced at the consumption endpoint, not just at issuance, and TOTP windows beyond ±1 step meaningfully expand attack surface.
It’s the Memory Latency, Stupid
Source: https://pivotlake.io/blog/its-the-memory-latency-stupid/
A systems performance post making the case that cache miss latency — not compute throughput, not memory bandwidth — is the dominant bottleneck for a broad class of real-world workloads, and that most performance intuition in the industry underweights it.
The argument is grounded in concrete numbers. Modern DDR5 DRAM has a latency of roughly 70–100 ns for a cache miss that goes to main memory. At 4 GHz, that is 280–400 cycles stalled per miss. For workloads with pointer-chasing access patterns (hash tables, linked lists, tree traversals, graph algorithms), these misses are largely unpredictable and cannot be hidden by out-of-order execution or prefetching. The post benchmarks a simple hash map lookup loop and shows that halving the working set (so it fits in L3) produces a 6–8x throughput improvement, dwarfing any instruction-level optimization.
The post draws out several practical consequences. First, data layout dominates: struct-of-arrays vs array-of-structs is often a 2–5x difference for SIMD-amenable code, primarily because of cache line utilization. Second, algorithmic complexity analysis that ignores memory hierarchy is systematically misleading for in-memory databases and analytics engines — an O(n log n) sort with good locality can outperform an O(n) algorithm with poor locality at practical data sizes. Third, the gap between L3 latency (~10 ns) and DRAM latency (~80 ns) means fitting hot working sets in L3 is often worth significant algorithmic contortion.
The discussion of NUMA effects and how cross-socket memory access adds another 2–3x latency penalty is a useful reminder for anyone running multi-socket servers. The post does not cover persistent memory (Optane-class) or CXL, which extend the latency hierarchy further.
AI, Lean, and the Future of Formal Verification, with Lean Creator Leo de Moura
Source: https://thedataexchange.media/leo-de-moura-lean-aws/
An interview with Leonardo de Moura covering the current state of Lean 4 as both a theorem prover and a general-purpose functional programming language, and the intersection with ML-assisted proof generation.
The technically substantive parts: de Moura discusses Lean 4’s unified architecture where the tactic language, the kernel, and the metaprogramming layer are all written in Lean itself, enabling macros and tactics to be defined and composed with full type safety. This is a departure from the traditional LCF-style architecture (Coq, Isabelle) where the kernel is a trusted core in a different language. The elaboration algorithm in Lean 4 uses a bidirectional type checker with unification variables and a tactic monad, allowing proof terms to be constructed incrementally.
On the AI angle: de Moura is direct that current LLMs (including GPT-4-class models) are useful for generating proof sketch candidates and filling in routine lemmas but are unreliable for novel or deep results. The value proposition is more like code completion than autonomous reasoning. He references the Lean FRO (Focused Research Organization) effort at AWS to build training data and evaluation benchmarks specifically for Lean, arguing that the formal verification setting provides exact ground truth (proof checking is decidable) that is absent from most ML benchmarks.
The Mathlib project is mentioned as a critical shared artifact — a collaboratively maintained library of formalized mathematics that gives LLMs (and humans) a vocabulary of ~100,000 theorems to leverage. The bottleneck for further automation is identified as tactic search over large proof states, which is a structured combinatorial problem that RL methods may be better suited to than pure next-token prediction.
Apple’s Git Still Trusts the Compromised eMudhra Certificates
Source: https://emudhra.we-have-a-problem.com/apple.html
eMudhra is an Indian certificate authority that was found to have issued certificates not compliant with CA/Browser Forum baseline requirements — specifically, certificates with insufficient entropy in serial numbers and improper domain validation procedures. Major browsers and root programs moved to distrust or constrain eMudhra certificates. This post documents that Apple’s bundled Git binary (shipped with Xcode Command Line Tools and used by a large fraction of macOS developers) continues to use a certificate trust store that includes eMudhra roots, independently of the macOS system keychain policy.
The technical crux: Git on macOS links against a libcurl build that uses its own CA bundle (typically derived from Mozilla’s bundle at build time and statically embedded or separately maintained) rather than delegating to the macOS Security framework and its keychain trust settings. This means that even if a user or enterprise policy removes eMudhra from the system keychain, Apple’s Git binary will still trust eMudhra-signed certificates for HTTPS operations — including git clone, fetch, and push over HTTPS to any server presenting such a certificate.
The implication is a MITM attack surface: an attacker with a certificate from eMudhra (which, under lax issuance, may be obtainable for domains the attacker does not legitimately control) could intercept git traffic from affected macOS systems even after the user believes they have mitigated the eMudhra trust issue.
The fix requires Apple to update the CA bundle embedded in or used by its Git distribution. The post was filed as a bug report; as of publication, Apple had not responded. This is a recurring issue with any software that ships its own CA bundle rather than delegating to the OS trust store — OpenSSL-linked binaries on macOS have historically had the same property.
TCP Use-After-Free: CVE-2026-98432 / CVSS 9.8
Source: https://atlasum.net/blog/cve-2026-98432-linux-ipv4-tcp-uaf
A Linux kernel vulnerability in the IPv4 TCP stack. The bug is a use-after-free in the TCP receive path, specifically in the handling of out-of-order segment reassembly. When a TCP socket is closed while out-of-order segments are queued in the sk_receive_queue / OFO queue, a race condition between tcp_close() and the softirq handler processing incoming segments allows a reference to a sk_buff to be retained after the associated socket’s memory has been freed and potentially reallocated.
The technical sequence: tcp_close() calls tcp_done() which transitions the socket to TCP_CLOSE and begins teardown, but the per-CPU softirq processing an arriving segment for the same socket can concurrently call into tcp_rcv_established() or tcp_data_queue_ofo() holding a reference to the now-freed socket. The freed sock struct contains function pointers (sk_data_ready, sk_write_space) that the softirq path may invoke, giving an attacker who can control heap layout the ability to redirect control flow.
CVSS 9.8 reflects remote exploitability: an external attacker can trigger the race by sending crafted TCP segments to a listening service, timing the close to coincide with the OFO queue processing. No authentication is required; the attack surface is any TCP service on an affected kernel.
Affected kernel versions span a wide range of the 6.x series; the patch modifies the socket reference counting path in tcp_close() to ensure the softirq path holds a proper reference before accessing socket state. Distributions are issuing updates; systems with untrusted network access to TCP services should prioritize patching.
Chained PHP2Shell Exploit Roots 25 Servers, Including US Government Servers
Source: https://dreamgroup.com/blog/chained-php2shell-exploit-roots-25-servers
A post-exploitation writeup describing a multi-stage attack chain that leveraged a PHP deserialization vulnerability to obtain a webshell, then chained additional local privilege escalation to achieve root on 25 servers.
The initial vector was a PHP object injection vulnerability in a popular CMS plugin — the specific gadget chain exploited PHP’s unserialize() on user-controlled input, using a POP (Property-Oriented Programming) chain to invoke system() through magic method abuse (__wakeup -> __toString -> file write). The resulting webshell was a minimal eval-based dropper written to a publicly accessible directory.
From the webshell, the attacker (or the post’s author, framed as a penetration test) pivoted to privilege escalation via a kernel exploit against an unpatched CVE in the namespace/cgroup subsystem, combined with a SUID binary misconfiguration to obtain a stable root shell. The “PHP2Shell” framing refers to the two-step: PHP injection to shell access, then shell to root.
The US government servers implicated were running legacy PHP applications exposed directly to the internet without WAF coverage, and kernel versions several years behind current stable. The post does not name specific agencies but includes redacted server hostnames and kernel version strings as evidence.
The technical takeaway is not novel — PHP deserialization chains are well-documented, POP chain construction is automated by tools like PHPGGC — but the operational detail of chaining deserialization to kernel priv-esc and the breadth of affected systems (25 servers across multiple organizations from a single campaign) is the substance. Organizations running PHP applications should audit deserialization call sites and enforce allowed_classes in unserialize() calls; the more durable fix is eliminating unserialize() on untrusted input entirely in favor of JSON or other non-executable serialization formats.
Noteworthy New Repositories
datalab-to/indra
A 1M-parameter OCR model targeting CPU-first deployment. Indra achieves accuracy close to billion-parameter models (e.g., Surya, GOT) while running 15x faster than Tesseract on CPU hardware. The architecture is a compact encoder-decoder trained on a mixture of synthetic and real document data, aggressively distilled to hit the parameter budget without catastrophic accuracy loss. Inference is pure Python with ONNX or PyTorch backends — no GPU required, making it suitable for edge deployments, CI pipelines, and server-side processing where GPU allocation is expensive. The model handles multi-language text, curved baselines, and mixed-font documents that traditionally require much larger networks. Compared to Tesseract’s classical pipeline (adaptive thresholding, connected-component analysis, LSTM), Indra uses an end-to-end neural approach that avoids hand-tuned preprocessing. The 15x CPU speedup comes from the model being small enough to fit in L3 cache and benefit from vectorized ONNX runtime kernels. Practical pick for anyone who needs production OCR without a GPU budget and cannot tolerate Tesseract’s failure modes on low-resolution or stylized text.
Source: https://github.com/datalab-to/indra
microsoft/TokenEconomizer
TokenEconomizer addresses token cost explosion in coding agents — multi-step LLM loops that call tools, read files, and iterate over codebases, accumulating context that can easily reach hundreds of thousands of tokens per task. The system treats cost control as a black-box optimization problem: it does not require modifying the agent’s internals or access to model weights. The core mechanism is experience-driven — it caches, compresses, and selectively evicts context segments based on observed utility signals gathered across prior agent runs. Key components include a context relevance scorer (trained on agent trajectories), a compression module that summarizes stale tool outputs, and a budget enforcement layer that intercepts prompts before they reach the LLM API. The result is token reduction without requiring the agent developer to hand-tune truncation heuristics. The “black-box” framing is important: TokenEconomizer wraps any agent that exposes a prompt-response interface (Claude, GPT-4o, Codex), making it framework-agnostic. Benchmarks show significant cost reduction on SWE-bench-style tasks while preserving task success rate. Relevant to anyone running agentic coding infrastructure at scale where API costs are a first-class engineering concern.
Source: https://github.com/microsoft/TokenEconomizer
NyxFoundation/nyxis
Nyxis is a backend framework for Lean 4 where authorization correctness is machine-checked at compile time rather than tested at runtime. The developer writes a Cedar authorization schema and policies (Amazon’s Cedar policy language, used in AWS Verified Permissions); Nyxis generates type-safe Lean handlers that are formally proven to enforce those policies. The storage and session layer is delegated to Supabase Auth and PostgreSQL, so the framework is not attempting to rebuild infrastructure — it focuses entirely on the authorization correctness problem. The formal proof component means that policy violations (missing checks, incorrect role logic, TOCTOU patterns) become type errors rather than security bugs discovered in production or pen tests. This is a meaningful engineering tradeoff: Lean’s dependent type system can express and verify access control invariants that are unprovable in conventional type systems. The cost is the Lean toolchain and the learning curve of writing Cedar schemas. The target audience is security-critical applications (fintech, health, government) where authorization audits are expensive and ad-hoc middleware security layers are a liability. Early-stage but technically serious.
Source: https://github.com/NyxFoundation/nyxis
trhhubsd/ARTEX
ARTEX is a multi-agent autonomous penetration testing system that won the Baidu Agent + Offensive/Defensive Challenge. The architecture combines Go (backend orchestration, tool execution, network-layer operations) and Next.js (operator dashboard) with a multi-agent LLM layer where specialized agents handle reconnaissance, vulnerability discovery, exploitation planning, and reporting as distinct roles. The system follows a standard pentest kill chain — host enumeration, service fingerprinting, CVE matching, exploit selection, post-exploitation — but replaces manual analyst decisions at each stage with LLM reasoning over tool outputs. Go is used for the performance-sensitive portions: port scanning, payload delivery, shell management. The multi-agent design avoids the context accumulation problem of single-agent loops by partitioning tasks so each agent operates over a bounded, relevant context window. Competition performance (first place in the Baidu challenge) provides external validation against adversarial targets rather than synthetic benchmarks. The open codebase is useful for security researchers studying agentic attack automation, red team tooling builders, and anyone evaluating LLM reasoning over structured technical domains under adversarial conditions.
Source: https://github.com/trhhubsd/ARTEX
jmanico/grim-prompter
Grim-prompter automates threat modeling for codebases by directing a coding agent (Claude Code, Codex, or any compatible agent) to perform evidence-traced architectural analysis. The tool encodes 36 recognized software architectures and 29 threat modeling methodologies (STRIDE, PASTA, LINDDUN, etc.) and uses them to guide the agent’s analysis rather than producing generic output. “Evidence-traced” means findings are anchored to specific files, dependency declarations, or configuration artifacts in the repo — not hallucinated generalities. The agent traverses the repository, identifies architectural patterns, infers trust boundaries and data flows, and produces a structured threat model with citations back to source evidence. The 36-architecture taxonomy forces classification before analysis, which constrains the model’s output space and reduces the generic boilerplate that LLM threat models typically produce. Practical for teams that need threat model artifacts for compliance (SOC2, HIPAA, PCI) but lack dedicated AppSec engineers. The MIT license and CLI interface make it easy to integrate into CI pipelines or pre-release review gates. The author (Jim Manico) has a background in OWASP, giving the threat methodology selection credibility.
Source: https://github.com/jmanico/grim-prompter
thesysdev/open-intelligent-ui
Open-intelligent-ui reimplements ChatGPT’s “intelligent UI” behavior — where responses render as interactive components (maps, charts, image galleries, drawings, embedded tools) rather than plain markdown — as an open-source, self-hostable stack. The system is built on OpenUI, a protocol for LLMs to emit structured UI descriptions alongside text. When the model determines a response warrants a visual component, it emits a typed component specification that the frontend renders natively; the user interacts with the component and the result feeds back into the conversation context. The architecture decouples the rendering layer from the model: any LLM that can be prompted to emit the OpenUI schema can power the interface. Current component library covers maps (Leaflet integration), charts (Recharts or similar), photo grids, canvas drawings, and executable tool widgets. The interesting engineering challenge is streaming partial component specs while maintaining valid render state — the repo implements a progressive JSON parser for this. Relevant for teams building AI-native applications who want richer response surfaces than markdown without locking into a proprietary vendor’s UI runtime.
Source: https://github.com/thesysdev/open-intelligent-ui
ccch1mneyyy/dsh-Go
dsh-Go (DeepSeek Harness, Go) is a lightweight runtime for running DeepSeek models locally on mobile hardware and for using those models to remotely control a desktop machine. The Go implementation targets Android and iOS via gomobile bindings, with the model execution handled by llama.cpp-compatible quantized weights. The remote control component exposes a minimal RPC interface: the phone-side model can issue shell commands, file operations, and application controls to a companion daemon running on the desktop, turning the local model into an on-device AI agent with cross-device reach. The Go codebase is chosen for its straightforward cross-compilation story (GOARCH targeting ARM), small binary footprint, and lack of a heavy runtime. The “pocket” framing reflects genuine hardware targeting: quantized DeepSeek-R1 variants at Q4 run on mid-range mobile SoCs with 8GB RAM within usable latency bounds for interactive use. The security surface of the desktop daemon is a noted concern — the repo ships with a localhost-only binding default. Primarily useful for researchers studying on-device agentic systems and developers building offline-capable AI tools.
Source: https://github.com/ccch1mneyyy/dsh-Go
pingdotgg/ts-rust
ts-rust is an experimental Rust port of the TypeScript 7 compiler (tsc), tracking Microsoft’s ongoing rewrite of the compiler from TypeScript-in-TypeScript to a native language implementation. Microsoft’s own TypeScript 7 effort targets Go; this repo explores whether Rust’s ownership model and performance characteristics make it a viable alternative or complement. The project is in early stages — parsing and basic type resolution are further along than the full type checker — but the architectural decisions are already technically interesting: the Rust implementation uses an arena allocator for AST nodes (avoiding the GC pressure that makes TypeScript compiler performance sensitive to heap size), and the type inference engine is being designed with Salsa-style incremental computation to enable fast language server queries. For compiler engineers, this is a reference point for the practical cost of porting a 500k-line type-directed compiler to a memory-safe systems language. For TypeScript ecosystem users, the relevance is long-term: a native tsc would compress type-checking time on large monorepos by potentially an order of magnitude. The experimental status means API and IR stability are not guaranteed.