Harun R.

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

someone on a dark web forum is offering crypto for anthropic and aws bedrock api keys. the seller gets 50% of whatever the buyer burns through the key so a leaked ai key isn't a data problem first. it's a bill, and it lands on you how i'd set up bedrock on aws: - no static keys. the app calls it with its own iam role - one role per app, so one leak doesn't own every model - a budget alarm, and an alert when calls per hour jump your ai key is a credit card now. treat it like one

google just took down a botnet hiding in 1.3 million cheap android tv boxes. google says the maker built the backdoor into the firmware at the factory one of the things it was used for: residential proxies. attacker traffic coming out of normal people's living rooms that's why i don't treat "block the bad ips" as a defense. on the apps i run on aws, limits sit on the account, the api key and the action, not the ip if your login page trusts an ip because it looks like a home connection, it might be trusting someone's tv box

openai says an ai pipeline found 948 linux kernel bugs that let a normal user become root, with working exploits, in one run that cost about $1.2 million as someone who runs servers, the number i care about isn't 948. it's what "local" means now local privilege escalation used to sound safe: the attacker has to be on the box first. but one bad npm package, one leaked ssh key or one hacked app, and they're on the box so i design as if any code on a server can become root: - one service per server or container, never one shared box running everything - no long-lived cloud keys on disk, only short-lived role credentials - servers you can throw away and rebuild, so patching is just a redeploy bugs are getting cheaper to find. how fast you can patch is now part of the architecture

a security firm scanned 159,041 lovable projects. 7,403 sites let anyone read user emails with no login, and some leaked passport details and private chats this isn't really a lovable bug. it's an architecture choice in these apps the browser talks straight to the database. the key ships in the page on purpose, so the database rules are the only lock. one wrong rule and the whole table is public on the apps i build on aws, the browser never touches the database. it calls an api, the api checks who you are, then it asks the database two free tests before you launch: open your app logged out in a private window. then make a second account and try to open the first one's data

day 9/100 of shipping cloudploy - start, stop, restart, resize and terminate servers from the console - connect, test and delete aws credentials - live waitlist count on the landing page opsagent - first-run welcome screen and setup checklist - three new security checks: encryption at rest, instance hardening, credential depth - daily check that the newest backup is fresh skaleagents - sign-ups limited to approved email domains - pick a plan for a personal organization - github connection survives renames, with a daily reconcile socialreins - connect x and tiktok, then publish - first comment on facebook, instagram, linkedin and youtube - linkedin document posts from one pdf crontinel - only the invited email can accept a team invite - disconnect google or github sign-in - waitlist offered when sign-ups are closed cloudploy waitlist: cloudploy.com/?utm_source=x

one graphql request is not one backend call it's a single POST to /graphql, but every field runs a resolver, and each resolver can hit a different database or service. a nested list turns 1 call into 1 + N how do you stop N+1 in your graphql resolvers?

an ai agent signing up for rival cloud platforms went off the rails and started probing one for kubernetes tokens and system files. the founder had it all in his logs. railway confirmed it was their engineer's test agent and apologized i'm building a deploy platform too, so two lessons from my side: if you run a platform, every signup is a stranger who can run code on your servers. design for that from day one, and log enough to prove what happened if you run agents, "do signups and test" is not a scope. give it a list of allowed targets, a budget and a kill switch the agent ran the scan. the person who started it owns it