The Control Plane — Week of Mon Oct 12, 2026

Let's Encrypt sets 64-day certificates for February 2027, Microsoft ships a record Patch Tuesday, Ivanti is exploited again, and Node.js changes its release schedule.

The theme this week is renewal cadence. The 200-day cap that took effect in March already changed how commercial CAs issue, and Let’s Encrypt has now set the date for its own cut to 64 days. Hard-coded renewal intervals are about to go stale everywhere at once. If a cron job, wrapper script, or runbook in your estate renews at a fixed number of days, this is the month to find it.

Kubernetes and cloud

The Kubernetes official CVE feed, last updated October 15, now lists two more issues fixed in the September patch round. CVE-2026-76654 (CVSS 5.8) affects the kubelet on Windows nodes: subpath symlinks can point at UNC paths, which permits NTLM coercion. The fixed kubelet refuses UNC symlink targets. CVE-2026-2270 (CVSS 5.9) is in the StatefulSet controller. A user with namespace-scoped write access to StatefulSet and ControllerRevision objects can create a pod in another namespace. The garbage collector deletes that pod at once unless the attacker can build a valid owner reference, which requires the UID of an existing StatefulSet in the target namespace.

Both are fixed in 1.34.12, 1.35.9, 1.36.5, and 1.37.1. Clusters on 1.37.0 or older patch levels are affected. The patch release calendar targeted the October round for October 13, but as of October 15 the GitHub release list still showed 1.37.1 as the newest 1.37 patch. The next target date is November 10.

Two checks are worth doing now. If you run Windows node pools, confirm the kubelet version on each pool, not only the control plane. If tenants can write StatefulSets and ControllerRevisions in a shared cluster, review those RBAC grants, since ControllerRevision write access is rarely needed by application teams. The Kubernetes YAML linter helps when you edit the Role manifests.

TLS and certificates

Let’s Encrypt announced on October 7 that on February 10, 2027, all subscribers will move to 64-day certificates by default. The 45-day and 6-day lifetimes remain available. The staging environment started issuing 64-day certificates on October 14, and Let’s Encrypt expects the last 90-day certificate to expire around May 11, 2027. Authorization reuse drops from 30 days to 10 days at the same time. In 2028, the default falls to 45 days and authorization reuse to seven hours. Valid certificates won’t be revoked, and rate limits, ACME endpoints, and chains don’t change.

The practical work is in renewal logic. Let’s Encrypt recommends ACME Renewal Info (ARI), which lets the CA tell the client when to renew. If your renewals are fixed relative to expiry, change them to renew at about two-thirds of the lifetime. The announcement suggests searching cron jobs, wrapper scripts, and runbooks for hard-coded values such as 83, 80, or 60. A job that renews at 30 days left still works with 64-day certificates. One set to renew at “60 days before expiry” would renew four days after every issuance. Point your client at staging this month, then confirm what is actually being served with the TLS inspector.

Security

Microsoft’s October Patch Tuesday on October 13 was the largest on record. BleepingComputer counted 1,411 flaws, not including 348 fixed earlier in the month, and Tenable counted 1,407; the totals differ by how each vendor counts. Seventy are rated Critical. Elevation of privilege makes up nearly half the list. Three are zero-days: CVE-2026-96951, a Windows Shell security feature bypass that is exploited in the wild, and two publicly disclosed issues, a .NET Framework security feature bypass (CVE-2026-108398) and a MessagePack-CSharp denial of service (CVE-2026-92707).

The MessagePack entry matters for teams that ship .NET services, because the fix lives in a NuGet package, not in Windows Update. Search your lock files and packages.lock.json for MessagePack and rebuild what depends on it. A release this size also tends to break things. Stage the Windows rollout by ring, and put CVE-2026-96951 first.

CISA added Ivanti Connect Secure CVE-2026-104935 to the Known Exploited Vulnerabilities catalog on October 13. Affected versions are 25.1.1.1 and earlier, 25.1.2.2 and earlier, and 22.8R2.4 and earlier. CISA says determining compromise requires network and memory forensics. If compromise is suspected, follow Ivanti’s recovery procedure: factory-reset or rebuild the appliance, restore the configuration, reset all account passwords, revoke and reissue stored certificates, and reset stored API keys. Treat the certificate step as mandatory. A VPN appliance’s private keys are exactly what an attacker on the box would copy.

Web development and tooling

Node.js 24.22.0 LTS and 26.12.0 shipped on October 14. More important for planning, Node.js will release security updates for the 26.x, 24.x, and 22.x lines on Wednesday, October 21, and the highest severity is HIGH. Book the maintenance window now and make sure your base images can be rebuilt that day.

The project also changed its release schedule. Starting with Node.js 27, there will be one major release a year, in April, with LTS promotion in October. Every release becomes LTS, so the odd/even rule goes away, and each line gets 36 months of total support. Node.js 26 is the last line under the old model and enters LTS this month. Node.js 27 starts its alpha phase in October 2026 and ships as Current in April 2027. If your platform policy says “even-numbered releases only,” it needs rewriting before next October.

Firefox 158 shipped on October 13. CSS typed arithmetic lets calc() divide two values of the same type, even in different units, and use the unitless result elsewhere. WebTransport gains getStats() and the static supportsReliableOnly property, which returns false in Firefox because it doesn’t support WebTransport over HTTP/2 yet. The Notification() constructor accepts a navigate URL, and PerformanceResourceTiming.deliveryType now reports cache. If you feature-detect WebTransport and fall back to WebSockets, supportsReliableOnly is the property to check before you assume an HTTP/2 path exists.

SRE and reliability

Three incidents this week are worth a look. Google Cloud Storage in us-central1 had elevated latency and errors on uploads and writes on October 8, from 8:19 a.m. to 7:30 p.m. ET, according to StatusStack’s incident summary. A smaller share of reads was also affected, and no root cause had been published. On GitHub, the October 7 incident from 16:52 to 17:01 UTC was a recurrence of an earlier write-operation outage that day, with the same root cause.

The largest was physical. BleepingComputer reported that drone attacks damaged three Yandex data centers between October 8 and 11. Two stopped operating completely and a third was degraded. Yandex said the platform was in emergency mode, gave no restoration timeline, and told customers to use their own disaster-recovery plans.

The common lesson is that a single region is a single failure domain, whether the cause is software or a physical attack. For object storage, decide in advance which writes can be buffered locally and retried, and which need a second region. For CI, a nine-minute recurrence is short, but it’s a reminder to make deploy jobs idempotent, so a retry after a 503 doesn’t push a release twice.

Chart of the week: certificate lifetimes since the 200-day cap

The CA/Browser Forum’s Ballot SC-081 limits public TLS certificates issued on or after March 15, 2026 to 200 days, falling to 100 days on March 15, 2027 and 47 days in 2029. The thresholds are encoded in zlint’s SC-081 lints, and the ballot is listed on the CA/Browser Forum site. To see how CAs responded, we pulled the certificate inventory for the same 60 developer-infrastructure domains as our CAA survey from CertIndex on October 15. We kept certificates with a notBefore on or after March 15 and counted each precertificate and final certificate pair once.

The “before the cap” column covers certificates from the 12 months before March 15, 2026.

Across 349 certificates on 48 domains, none exceeded 199 days. The newest certificate longer than 200 days in the sample was issued on February 17, 2026. Many commercial certificates moved straight to the new ceiling: 107 certificates on 14 domains are 198 or 199 days long, and Amazon issues 198 days for every certificate in the set. ACME issuers didn’t change at all, because Let’s Encrypt and Google Trust Services were already well under the cap. A few operators already go shorter on purpose. Stripe ran DigiCert certificates of 12 to 29 days this spring, and hetzner.com has a 45-day Let’s Encrypt certificate.

The takeaway: teams on commercial CAs went from one renewal a year to two this year, and will go to about four next March. Teams on Let’s Encrypt will move from 90 to 64 days in February. Both changes land within five weeks of each other in early 2027. The data is a lower bound, since several of these inventories were still being backfilled, and it is published as JSON. Check any one of your own hosts with the CT lookup tool.

From the workshop

Three new pieces shipped since the last recap. The CAA survey of 60 developer-infrastructure domains found that 34 publish CAA and only one binds issuance to an account. The new CAA checker reads a domain’s effective CAA policy and compares it with the CAs that issue for it, and its guide explains each result. Why a new DNS record still returns NXDOMAIN covers negative caching, with measured negative TTLs from 43 zones.

Recommended reading

• Read Let’s Encrypt’s 64-day announcement and test your client against staging.
• Revisit why ACME renewal quietly broke before you change renewal intervals.
• Use reading a TLS certificate to check validity dates and chains by hand.

Tags: #weekly-recap, #tls, #certificate-lifetimes, #acme, #kubernetes, #security, #nodejs, #sre