What Users Get From This Update
This update is about closing practical gaps without making 1-SEC heavier to run. The engine now looks deeper into binary upload content for embedded executable markers and shellcode-like byte sequences, and the web platform now handles several Blob-backed state updates more defensively under concurrent traffic.
The important part for operators is simple: more detections land in the same product surface, and the dashboard state behind those detections is less likely to lose a counter or history update when requests arrive at the same time. No new service is required. No new external detection dependency is introduced.
Injection Shield Looks Past the Header
Attackers do not always place the interesting part of a payload at byte zero. They can bury executable content, loader fragments, or shellcode markers deeper inside an upload and rely on shallow scanners to make a decision from the first small window.
Injection Shield now scans bounded windows across larger binary payloads instead of relying only on the front of the file. It also validates common executable signatures more carefully so obvious PE, ELF, Mach-O, Java class, and WebAssembly markers still get caught without turning every random byte sequence into a scary-looking false positive.
Blob-Backed State Is More Defensive
The blog itself is still static content in the web repository. Netlify Blobs are used for customer-facing API state such as keys, quota usage, auth-failure rate limits, alert history, webhook settings, and dashboard data.
We tightened the most sensitive of those paths. Auth-failure counters, quota usage, key deactivation, key rotation, and event history now use strong Blob reads and conditional writes where the platform exposes ETags. If two requests try to update the same customer record at once, the write retries against the fresh value instead of casually overwriting the other request's change.
The Operating Model Stays the Same
The product philosophy is unchanged: one security engine, sixteen modules, deterministic local detection, and a dependency footprint customers can actually audit. The website platform can use managed storage for account and dashboard state, but the engine itself still does not need a cloud database, a model call, or a fleet of companion services to protect a host.
That distinction matters. The customer should get stronger product reliability and deeper detection coverage without inheriting a more fragile deployment story. This release keeps that line clean.