A Rough Few Weeks: PHP, Node.js, APT and a $6.3B Homebrew Lesson

If the last few weeks felt loud, you're not imagining it. In barely a fortnight we got two critical PHP bugs that attackers jumped on within days, a Node.js flaw with a working proof of concept, a package manager bug that could hand out root, and the largest crypto theft on record, which started with one engineer installing what looked like Homebrew.

None of this is a reason to panic. It's a reason to tidy up, tighten a few policies, and make sure that when something like this lands, the right person actually hears about it. Here's a friendly tour of what happened, what to do about each one, and how we think about alarms.

This is a snapshot from 5 November 2026. Versions and advisories move fast, so always check the official advisory before you act.

If you only have ten minutes

PHP: two critical bugs, exploited within days

On 21 October the PHP project shipped fixes for CVE-2026-109618 and CVE-2026-109619. Both are memory corruption bugs in the PHP core itself (not in a framework or a plugin), both are rated 9.2, and both allow unauthenticated remote code execution as the web worker. PHP-FPM, mod_php, php-cgi, FrankenPHP and LiteSpeed are all affected, with mod_php considered the riskiest.

It didn't stay theoretical for long. Exploitation attempts were reported almost immediately, and on 26 October CISA added both CVEs to its Known Exploited Vulnerabilities catalog.

What to do:

• Update to 8.2.35, 8.3.36, 8.4.27 or 8.5.12 (or your distribution's patched package), then restart PHP-FPM or Apache so the old workers are gone.
• Check php -v on every server, including the "temporary" one nobody has logged into since spring.
• PHP 8.1 and older are end of life. If you're still there, this is the push to plan the upgrade.
• Config tweaks such as disabling session upload progress reduce the risk but do not fix it. Patching is the fix.
• Because exploitation started before many teams patched, look back as well as forward: new files in web roots, unexpected outbound connections from web workers, unfamiliar cron entries.

Node.js: a Brotli bug, and another release on 11 November

CVE-2026-111497, nicknamed Node2Shell or HTTP2Shell, is an out-of-bounds write in the Brotli decoder that Node.js bundles. A crafted compressed payload can crash the process, leak memory or, in the worst case, run code. A public proof of concept exists, and CISA added it to the KEV catalog on 27 October.

You're exposed when an old runtime meets attacker-controlled Brotli data: request body parsers that decompress (for example Express 5 with body-parser 2), compression middleware that decompresses requests, fetch() on URLs users choose, or direct node:zlib calls.

What to do:

• Update to Node.js 22.23.4, 24.22.1 or 26.12.1 (Bun users: 1.4.4). This is a runtime fix, so bumping npm packages won't help. Rebuild your container images too, not just your laptop.
• Node.js 20 and older are end of life and won't get a fix. Time to move.
• Put 11 November in the calendar. The Node.js project has announced another security release for the 22.x, 24.x and 26.x lines, with the highest severity rated High. Details come on release day, so book the upgrade slot now and you won't be scrambling.

APT: when a download retry hands out root

CVE-2026-109518 is a bug in APT's HTTP download handling. Combined with a download retry, it can trick APT into installing a package whose signature check failed, and since packages run their install scripts as root, that means root on the machine. The attacker has to sit between you and the mirror (a hostile network, a compromised proxy, a malicious mirror), so it's not a drive-by, but it's exactly the kind of thing that hits build servers and cloud images.

What to do:

• Update APT itself, with retries switched off for that one run: sudo apt update && sudo apt install -o Acquire::Retries=0 --only-upgrade '?source-package(^apt$)'
• Move your sources to https:// mirrors where you can. HTTPS protects against this attack.
• If unattended-upgrades is on, it will pick the fix up within a day. Still worth checking the version against Ubuntu's notice (USN-8996-1).

A fake Homebrew installer, and a $6.3 billion lesson

This one isn't a CVE at all, which is why it matters most.

Binance published its findings on 3 November. As Binance tells it, the theft of about $6.3 billion on 29 October started back in June, when a wallet DevOps engineer searched for an AI coding tool and ended up running a malicious clone of the Homebrew installer. Binance caught that, but the attackers had already learned who worked on the wallets. In September a different engineer was invited to a fake job interview and asked to run a coding "assignment" on a work machine. That one wasn't caught, and weeks later it became the way in.

No zero-day was needed. Just a search result and a friendly recruiter.

What to do:

• Install developer tools from the official site, typed by hand or from a bookmark, never from a search result or an ad. That includes Homebrew, language version managers and "AI coding tools".
• Interview tasks, "quick tests" and repositories from strangers run in a throwaway VM, never on a work laptop.
• Keep deploy tokens and cloud credentials off laptops where you can, short-lived where you can't.
• Make it easy and blame-free to say "I think I ran something I shouldn't have". The sooner you hear it, the cheaper it is.

Tighten the basics

None of these are new, but weeks like these show which ones you actually have:

• Know what you run. A simple inventory of runtimes and versions per server turns "are we affected?" from a day of SSH into a five-minute query.
• Patch windows that already exist. If you have to negotiate a maintenance window every time, you'll always be late.
• Least privilege for people and pipelines. The engineer who deploys doesn't need the keys that move money.
• Fewer long-lived secrets. Every token on a laptop is a token that can leave with the laptop.
• Out-of-date means exposed. End-of-life PHP and Node.js lines get no fixes at all, so they belong on the roadmap, not on the wish list.

The information is out there, and it's mostly free

The good news: you don't need a big budget to know what's going on. There are plenty of threat intelligence services, many with free tiers, and the primary sources cost nothing:

• Vendor advisories and mailing lists. The Node.js security list, your distribution's security notices, PHP's release announcements. If you run it, subscribe to it.
• CISA's Known Exploited Vulnerabilities catalog. A free, machine-readable list of bugs that are being exploited right now. If a CVE lands there and you run that software, it's not a "next sprint" item.
• Internet-wide views. Public dashboards of traffic, outages and attack trends are getting friendlier too. Cloudflare, for example, redesigned its Radar homepage in October around an interactive map so non-specialists can explore it.

The hard part was never finding the information. It's making sure the right person sees the important bit in time, and isn't drowning in everything else.

Turn the important ones into alarms

Most teams pipe advisories into a chat channel. That's fine for "good to know". It's not fine for "actively exploited, and we run it", because a chat message at 11pm on a Friday is a message nobody reads until Monday.

So split them:

• Everything else goes to the channel or the weekly review.
• Known exploited + in our stack becomes an alarm with an owner, a deadline, and a phone that rings.

Here's a small script that checks the CISA catalog every hour for software you actually run and raises an alert for anything new. It sends a generic JSON webhook, so it works with any alerting tool that accepts one.

#!/usr/bin/env bash
# kev-watch: alert when CISA marks a CVE in our stack as known exploited.
set -euo pipefail

FEED=https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json
WATCH='\b(php|node\.js|nginx|openssh|postgresql|redis)\b'   # what you actually run
SEEN=/var/lib/kev-watch/seen.txt
HOOK="${ALERT_WEBHOOK_URL:?set ALERT_WEBHOOK_URL}"

mkdir -p "$(dirname "$SEEN")"
first_run=false; [ -s "$SEEN" ] || first_run=true; touch "$SEEN"

curl -fsS "$FEED" | jq -r --arg re "$WATCH" '
  .vulnerabilities[]
  | select((.vendorProject + " " + .product) | test($re; "i"))
  | [.cveID, .vendorProject, .product, .vulnerabilityName, .dueDate] | @tsv' |
while IFS=$'\t' read -r cve vendor product name due; do
  grep -qx "$cve" "$SEEN" && continue
  echo "$cve" >> "$SEEN"
  $first_run && continue            # first run: remember the backlog, don't page for it
  jq -n --arg cve "$cve" --arg t "$vendor $product: $name" --arg due "$due" '{
      title: ("Known exploited: " + $t),
      body: ($cve + " is being exploited in the wild. CISA due date: " + $due + ". Check our versions."),
      severity: "high",
      dedup_key: $cve,
      link: ("https://nvd.nist.gov/vuln/detail/" + $cve),
      tags: { source: "kev-watch" }
    }' | curl -fsS -X POST "$HOOK" -H 'Content-Type: application/json' -d @-
done

Run it from cron (0 * * * *), adjust WATCH to your stack, and you'll hear about the next PHP-style emergency the hour it's confirmed, not when someone happens to read the news.

Where WakeHook fits

This is the part we built WakeHook for. Point the script above (or Alertmanager, Grafana, Uptime Kuma, a cron job, anything that can POST) at a WakeHook source, and a "known exploited" alert doesn't sit quietly in a channel. It rings the on-call phone through Do Not Disturb and Focus until someone acknowledges it, and if nobody does, it moves on to the next person. Every ring is logged, so "I never got paged" stops being a thing.

Two features fit this use case nicely:

• Heartbeat monitors. Have the script check in every run. If the watcher itself dies quietly, WakeHook wakes you about that too.
• Fire drills. A scheduled test alert walks the whole path, so you find out the pager is broken on a Tuesday afternoon, not during the next big one.

The Free plan covers one person and one source, forever, with no credit card. Give it a try at wakehook.com.

Stay patched, keep your laptops boring, and make sure the important alerts are loud. If you'd like a hand with any of it, from an inventory to an alerting setup that actually wakes people, get in touch.

Sources

• CISA alert on the PHP vulnerabilities and the KEV catalog: cisa.gov
• Rapid7 analysis of CVE-2026-109618 and CVE-2026-109619: rapid7.com
• CVE-2026-111497 (Node2Shell) fixed versions and exposure: cycode.com
• Node.js November 2026 security releases: nodejs.org
• Ubuntu on the APT vulnerability: ubuntu.com
• The Binance incident and the fake Homebrew installer: 9to5mac.com