Hardware-Level Memory Attacks Are Getting Scarier
A post about 'Spaghettifying DRAM' described a new hardware attack that appears to be a software-reachable version of dynamic memory aliasing, comparable to the Battering Ram attack. Commenters flagged Christopher Domas as the researcher behind it, calling him one of the best hardware hackers working today. The attack requires deep CPU reverse engineering but the implication is that memory isolation assumptions baked into cloud infrastructure may not hold.
This sits alongside the Ruby 4.0 universal RCE deserialization gadget chain post, which showed that even well-documented warnings in Ruby's own docs ('never unmarshal user supplied input') are still being violated in ways that lead to full remote code execution. Two different layers of the stack, same underlying story: the attack surface is bigger than most builders assume.
The GLM-5.3 thread added a political dimension: commenters argued that frontier AI labs need to give security researchers access to offensive cyber models before attackers exploit the asymmetry. The gap between attackers using open models and defenders using restricted ones is a real structural problem.
So what?
If you're running anything on shared cloud infrastructure, the DRAM research is worth watching even if you can't act on it today. For application-layer founders, the Ruby deserialization issue is a reminder that 'the docs warned you' is not a defense when your dependencies do it anyway. Audit what your gem dependencies are doing with Marshal.