Harun R.

hackers hit water systems in at least 12 us states this summer. in new jersey, two town systems went blind and staff had to run them by hand that last part is the one i keep thinking about the targets were internet-connected control systems, usually online so someone can manage them remotely. same pattern as the supermarket freezers earlier this month how i'd design anything that controls something physical: - the control panel is never on the public internet. remote access goes through a vpn with mfa, for named people only - monitoring is read-only and separate from the controls - there's a manual mode, and the team practices it the question isn't only "can they get in". it's "what still works when they do"

got $10k in aws credits through nvidia inception. it wasn't that hard to get in. aws lists it as "AWS Activate - NVIDIA Inception Global". have you applied?

got into nvidia inception a few days ago. it wasn't that hard. have you applied?

whatsapp accounts across malaysia, singapore and a few other countries are being used to push zip and iso "invoices" that drop windows remote-access malware. mycert and singcert both flagged it the architect problem isn't whatsapp. it's that the same windows laptop opens client invoices and holds your aws keys and ssh keys how i'd set it up: client messaging and file opens live on a throwaway machine or vm. the laptop with cloud credentials never auto-downloads attachments one infected invoice shouldn't reach your production account

day 13/100 of shipping cloudploy - connect github, gitlab or bitbucket and pick a repo and branch for a new app - auto-deploy on push, with a toggle on the app page - hourly credit billing with low-balance warnings skaleagents - owners can dismiss audit findings and see what changed since the last audit - stripe adds tax at checkout, and plan prices say they exclude tax - manage payment details from the billing page crontinel - crontinel:check and the dashboard work on packagist installs - horizon warnings stopped, crontinel's own jobs hidden in reports - a zero count alerts only after you set a minimum opsagent - the billing page shows a cancelled plan's last day - connections explain why they're blocked, and an owner can remove one socialreins - publish a video to bluesky - separate log in and sign up, and login never creates an account cloudploy waitlist: cloudploy.com/?utm_source=x

companies are hiring "sandbox engineers" now. firecracker, microvms, the wall between agent code and everything else that used to be a niche systems job. agents made it a product job if your product runs other people's code, or an agent's code, the sandbox is the product that's the hire i'd make before the next feature

aws fixed an eks networkpolicy bypass (cve-2026-122266). a pod on the same node could poison shared ebpf conntrack state and sneak past ingress rules meant for its neighbour fixed in aws-network-policy-agent 1.3.7 and vpc cni 1.22.3 networkpolicy is a filter, not a tenant wall how i isolate sensitive workloads on eks: - separate node groups for anything that holds customer data or keys - for real multi-tenant, separate aws accounts, not just labels on the same node - upgrade the cni the week this kind of cve lands: there is no workaround if two tenants share a node, assume they can eventually see each other

node.js gave a week's notice: high severity security fixes land on or after november 11 for 22.x, 24.x and 26.x. no details yet a pre-alert is a gift. the teams that struggle on patch day are the ones who don't know where node runs what i'd do this week: - list every place node runs: containers, lambda functions on custom images, ci runners, that one cron box - make sure the version comes from one base image or one setting, not installed by hand on each server - do a dry run: bump the version, rebuild, deploy to staging then on the 11th it's a one-line change and a normal deploy, not a fire drill

railway apps went unreachable for some users today. network providers and security services blocked railway's ip addresses, per railway's status page shared ip pools are part of your product. one noisy neighbor on the same ranges, and your customers' apps get blocked on the internet how i'd design around that: - don't put all customer egress on one shared pool with no identity - per-project or per-customer egress ips when you can - watch blocklists the way you watch uptime - a status page that says "our ips are being blocked" beats silence i'm building a deploy platform. this is the kind of incident that shapes the design

coinspect just showed a firecracker guest can reach the host process that runs the microvm root inside the guest, on a snapshot with the file memory backend and a balloon device, could read and change firecracker's own memory. fixed in 1.16.2 and 1.17.0. aws says lambda and fargate are not affected i'm building a deploy platform, so the lesson for me is simple: the sandbox is the product boundary how i'd run untrusted agent code on aws: - a real microvm (firecracker-class), not "a container with extra hope" - patch the vmm the same week a guest-to-host cve lands - no long-lived cloud keys inside the guest. it asks a broker; the broker mints a short-lived iam role if the sandbox can touch the host, it was never a sandbox

dreamhost confirmed its browser file manager was breached for about two months, august to october 23. ftp/sftp usernames and passwords of people who used it were taken, plus some webmail sessions a web file manager is a website that holds the keys to other websites. when it falls, every site behind it is exposed and ftp passwords are the worst kind of key: long-lived, often reused, and able to rewrite your live site how i set up deploys instead: - code goes out through a pipeline. nobody uploads files to production by hand - no ftp at all. ssh keys if a human must get in, removed after - the live code folder is read-only for the web app if you used it, change those passwords and check your site for files you didn't put there

the wordpress bug cisa just added to its exploited list is a strange one. the attack happens during the update while wordpress upgrades itself, it unpacks new files into a folder the web can reach. attackers race to run code from there before the upgrade finishes. versions 4.7 to 7.1.3, fixed in 7.1.4 the real problem is the design: the live server rewrites its own code how i'd run it on aws: - build the new version in the pipeline and ship it as a fresh image - the web server can't write to its own code folder, only to uploads - update by swapping servers, not by patching the one serving traffic the safest update is the one that never happens on the live box

alpine linux rebuilt its whole gitlab server and made users reset their passwords. not because they found a break-in. because they couldn't prove there wasn't one attackers hit it with the 10/10 gitlab bug that's now on cisa's exploited list. alpine had upgraded gitlab, but the fix lives in ruby's regex engine, and their own image still had the old ruby two things i take from it: - your app version isn't your patch level. check what's inside the image - logs decide if an incident ends with a patch or a rebuild. no outbound connection logs, no proof, start over a ci server holds the keys to everything you deploy. design it so you can rebuild it in an afternoon

postman's desktop app quietly installed its own plugins into claude code and codex, added a startup hook telling the agent to use postman for api work, and tried to mark that hook as trusted. per the github issue, nobody clicked anything nobody says data left the machine. that's not the point an agent's "approval" is just a line in a config file. any app running as you can write that line how i'd set it up: - agent configs live in a git repo, so any change shows up as a diff - hooks and plugins only come from that repo - the agent runs as its own user, so other apps can't touch its settings the approval should live somewhere the thing being approved can't write

gitbook says attackers using ai agents breached its infrastructure credentials on nov 2. it revoked every personal api token, and git sync secrets and integration tokens may be exposed the part i'd check first: git sync. your docs tool is connected to your github, and it's easy to have given it all repositories instead of just the docs repo same shape as a lot of this month's breaches. the main product was fine. a connected tool held a key to more than it needed how i'd set it up: every integration gets one repo, one scope, its own token. if the docs tool leaks, you lose the docs

nikke's pc launcher got hit through its own cdn. a few javascript files on the publisher's official cdn were changed to pull in a remote-access tool. the publisher shipped a fix overnight the part that stuck with me: after the fix, one researcher found two cdn servers still serving the bad cached copy fixing the origin isn't the end. the edge keeps the old file until you purge it how i'd set it up on aws: - only the release pipeline can write to the bucket behind cloudfront - every release ships a signed list of file hashes. the launcher refuses anything that doesn't match - cache purge is a step in the incident runbook, not an afterthought a cdn is a copy machine. it copies the bad file just as fast

day 10/100 of shipping cloudploy - custom domains with certificates handled for you - launch a server with a cost estimate, or connect your own - connect your team's cloudflare dns opsagent - connecting a cloud account is optional, skip for now - findings listed critical first - bot check on forms that send mail crontinel - the 14-day pro trial shows on pricing and login - one-click unsubscribe from the weekly report - wrong email-code guesses capped per hour skaleagents - five new scanner rules - reliability and scaling audits report infrastructure-as-code findings - sign-in reopens the last organization you used socialreins - reconnect warning when an account token is expiring - tiktok post settings in the post editor cloudploy waitlist: cloudploy.com/?utm_source=x

pick a vpn by who connects, not by protocol name. office to office or cloud: ipsec. staff on laptops: a tls vpn like openvpn. a few servers and phones: often wireguard if you've run both ipsec and wireguard, which one cost you more debugging time?

noooo

binance published how the $6.3b hack started. not a smart contract bug. a fake job interview an engineer ran a "coding assignment" on his work computer. by oct 20 the attackers used that foothold and an internal ai tool to compromise two more engineers. on oct 29 they reached wallet signing the scary part isn't the malware. it's the reach. one laptop was a few steps from the systems that move money how i'd draw it: - take-home tests and unknown repos run in a throwaway vm, never on the work machine - internal ai tools get their own narrow access, not everything the engineer can touch - signing sits on a separate device and needs a second person one laptop should never be a few steps from the vault