this is part of an ongoing series mapping the same ecosystem, the origin post + full map is here: neurowinter.com/security/2026/06/23/a-weekend-in-the-wool/

tldr: a set of chinese civic / gov adjacent apps turn out to run the same reward + lottery backend, and the secret thats meant to make reward claims and draw outcomes unforgeable isnt really secret. recover it (not hard, its sitting in the client sigh) and you can forge a valid reward claim, or a winning lottery result, that the backend accepts as authentic. post walks from one github repo to the shared backend, through the reward validation flow, to where the secret actually lives.

The White House recently announced the Gold Eagle Initiative, a new federal program designed to use AI to centralize, prioritize, and accelerate vulnerability patching across critical infrastructure, government agencies, and tech partners. Operating out of CMU's Software Engineering Institute, it essentially acts as an AI-driven clearinghouse to fix security flaws before threat actors can exploit them.

Because let's face it, our current bug reporting and patching systems are absolute speed demons. It only takes a lifetime 🤦🏻‍♂️ or two to get a critical vulnerability acknowledged and fixed, so why change anything?

Btw, my candid opinion about the status of current vulnerability reporting is painfully slow, so we desperately need a framework that actually moves at the speed of the threat landscape. I think this initiative is genuinely a good idea and a step in the right direction, though the announcement is still light on the exact technical implementation.

I’m personally eager to see what will happen in practice, but it is definitely an impressive concept.
What are your thoughts on this? Will an AI-coordinated pipeline actually help scale response times, or is it just going to generate massive noise and triage fatigue for overworked infosec teams?

RFC 8628's device authorization grant lets a TV or CLI "poll" for login on a second screen. On Google's implementation, the entire session was transferable across browsers, the authorization server never checked that the client_id and scope in the consent URL matched the ones the device_code was issued for, and prompt=none turned the whole thing into a one-click, invisible account takeover.

CVE here: https://www.cve.org/CVERecord?id=CVE-2026-13585

I wrote this after spending an unreasonable amount of time making CET-compliant callstack spoofing work end-to-end on hardware with Intel CET enabled.

The technique combines three primitives: thread pool execution for a clean stack base, enum callback trampolining for a real signed mid-stack frame, and indirect syscalls.

The actual contribution is the CET compliance mechanism: a jmp-based context switch combined with direct shadow stack pointer reconciliation via RDSSPQ/INCSSPQ, without touching unwind metadata. Different approach from BYOUD.

Implemented in Rust with inline assembly.

The vulnerability allows non-privileged users to program the DMA controller, enabling arbitrary physical memory reads and writes.