The Control Plane — Week of Mon Oct 5, 2026
ccTLD registry hijacks minted trusted certificates, Kubernetes 1.38 gate removals, an exploited FortiMail flaw, Chrome 155, and GitHub's Actions incident.
Control Plane Labs Staff
Published October 8, 2026
This week’s lead story is a reminder that a certificate proves control of DNS, not ownership of a brand. When the DNS above you is compromised, a CA can follow every rule and still issue to an attacker. The controls that help are the ones you set up before the incident: CT monitoring, tight CAA records, and a clear inventory of every domain you own, including the regional ones nobody looks at.
Kubernetes and cloud
Kubernetes v1.38.0-alpha.2 shipped on October 7, the second pre-release on the way to 1.38. The 1.38 changelog is mostly cleanup, but some of it breaks startup flags. SeparateTaintEvictionController is gone from kube-controller-manager, and the changelog says to remove the gate from --feature-gates before upgrading. To turn taint eviction off, use --controllers=-taint-eviction-controller. The DynamicResourceAllocation, KubeletTracing, ServiceAccountTokenPodNodeInfo, and WindowsHostNetwork gates are also removed. DRADeviceTaints and DRADeviceTaintRules are locked to true, so explicit false entries must go.
The September patch round also fixed a client-side issue worth tracking down on developer laptops. CVE-2026-19444 (CVSS 6.5) lets a malicious tar binary inside a container write files anywhere the local user can write when someone runs kubectl cp on Windows. Linux and macOS clients are not affected. The fixed client versions are kubectl 1.34.12, 1.35.9, and 1.36.5. Run kubectl version --client on Windows jump hosts and admin workstations. Search your control-plane manifests for the removed gates, and validate the edits with the Kubernetes YAML linter.
TLS and certificates
Google disclosed on October 6 that attackers had compromised the country-code registries for .gh (Ghana), .sl (Sierra Leone), and .as (American Samoa). They changed authoritative DNS records and obtained unauthorized HTTPS certificates for several Google domains and for “several leading global brands and widely used online services.” Google says its own systems were not compromised and that there is “no reason to believe” the issuing CAs did anything wrong. CT logs exposed the certificates. Chrome pushed them into its CRLSets, and the CAs revoked them to protect clients other than Chrome.
The Register adds Google’s warning that browser-side blocking should not be relied on, and that it cannot guarantee every affected domain was found. Google’s guidance for domain owners has two parts. First, monitor CT for your whole portfolio, including parked and regional ccTLD domains. Second, publish restrictive CAA records. CAA “won’t stop certificates from being issued during a DNS hijacking attack,” but RFC 8657 parameters (accounturi and validationmethods) can stop an attacker from using cached validation to mint new certificates after you regain control. If you own names under .gh, .sl, or .as, search CT for September and October issuance now with the CT lookup tool.
Security
CISA added Fortinet FortiMail CVE-2026-104286 to the Known Exploited Vulnerabilities catalog on October 1, with a due date of October 4. It is an unauthenticated path traversal flaw that lets an attacker write arbitrary files using crafted HTTP or HTTPS requests. Fortinet scores it 9.8, and NVD has not scored it yet. Affected releases are 7.2.0 to 7.2.9, 7.4.0 to 7.4.8, 7.6.0 to 7.6.6, and 8.0.0 to 8.0.1. As of October 2, SecurityWeek reported that fixes were planned for 7.4.9, 7.6.7, and 8.0.2. In the meantime, the interim mitigation is to disable IBE, or disable web access to the management interface and limit access to trusted sources.
For defenders: confirm the current fixed builds in Fortinet’s advisory FG-IR-26-175, hunt with the published indicators of compromise before you change anything, and treat any exposed appliance as a candidate for investigation, not just patching.
Closer to the platform layer, gRPC-Go advisory GHSA-vp52-pcj8-j9qc (CVE-2026-84304) fixes heap memory exhaustion triggered by fragmented HTTP/2 DATA frames in releases before v1.83.1. Prometheus 3.13.4 picked up the fix on October 2. Any Go service that embeds gRPC needs the same dependency bump, and a scan of go.sum across your repositories will find them.
Web development and tooling
Chrome 155 reached Stable on October 6 with 247 security fixes, and an early Stable build of Chrome 156 started rolling out to a small share of desktop users the next day. The Chrome 155 release notes add post-quantum algorithms to WebCrypto: ML-KEM-768 and -1024, ML-DSA-44, -65, and -87, the X-Wing hybrid KEM, and ChaCha20-Poly1305. CSS gains symbols() for inline counter styles, margin-trim for block and multicol containers, and text-decoration-skip-spaces. Additional Windowing Controls let installed apps with window-management permission call maximize(), minimize(), restore(), and setResizable().
The WebCrypto additions are the item to test first. If you have been shipping a JavaScript ML-KEM library, feature-detect the native algorithm before you load the library. Keep the library for browsers that don’t have it yet. Check the new display-state and resizable media features in any installed web app that styles its own title bar. Then confirm that your CDN still sends the security headers you expect with the HTTP header inspector.
SRE and reliability
GitHub’s status page write-up of the October 5 Actions incident is one of the more useful public reports this month. From 18:48 to 22:49 UTC, a partial networking failure between one of GitHub’s on-premises datacenter regions and a subset of cloud-hosted regional database and storage services degraded Actions, hosted runners, and Pages. Across the incident, 14.3% of workflow runs on GitHub-hosted runners and 26.5% of hosted jobs did not start within five minutes. During the worst 90 minutes, 47.0% of those workflow runs failed and 71.9% of hosted jobs didn’t start within five minutes. Self-hosted runners were not affected.
The lesson for CI owners is to measure queue time, not just job duration, and to decide in advance what happens when runners stop showing up. Set timeout-minutes on jobs. Alert when a job waits for a runner past a threshold, and treat a run of 503 responses from your deploy API as a separate signal. And keep at least one self-hosted runner pool, or a documented manual deploy path, for the releases that cannot wait four hours.
Chart of the week: CAA records on developer infrastructure
Google’s advice to publish restrictive CAA records raises an obvious question: how many of the sites developers depend on actually do? On October 8 we queried the CAA records for the same 15 hosts as last week’s issuer sample, through Google Public DNS. We then compared them with the issuer of each host’s current certificate, pulled from CertIndex on October 1. The record format is defined in RFC 8659.
| Host | Current issuer | CA identifiers in issue |
issuewild set |
iodef set |
Account binding |
|---|---|---|---|---|---|
| kubernetes.io | Let’s Encrypt | 2 | no | no | no |
| golang.org | Google Trust Services | 2 | no | no | no |
| netlify.com | DigiCert | 2 | no | yes | yes (critical flag) |
| pypi.org | GlobalSign | 3 | no | yes | no |
| github.com | Sectigo | 4 | yes | no | no |
| vercel.com | Let’s Encrypt | 4 | no | no | no |
| cloudflare.com | Google Trust Services | 5 | yes | yes | no |
| docker.com | Amazon | 6 | no | yes | no |
| npmjs.com | Let’s Encrypt | 6 | yes | no | no |
| letsencrypt.org | Let’s Encrypt | 6 | yes | no | no |
| digitalocean.com | Google Trust Services | 7 | yes | yes | no |
| gitlab.com | Sectigo | 11 | yes | yes | no |
| crates.io | Amazon | — | no CAA | — | — |
| grafana.com | DigiCert | — | no CAA | — | — |
| fly.io | Let’s Encrypt | — | no CAA | — | — |
Twelve of the 15 hosts publish CAA, and in every one of those 12 the current issuer is on the allowed list. Three hosts publish nothing, so any public CA may issue for them. The allowed lists vary widely, from two CA identifiers to eleven. Some identifiers belong to the same operator: amazon.com, amazontrust.com, and awstrust.com are all Amazon. Only netlify.com binds issuance to an account, using a CA-specific account= parameter with the critical flag set. None of the 15 use the RFC 8657 accounturi or validationmethods parameters that Google recommends. The three Google ccTLD names involved in the hijack now publish a single issue "pki.goog" record.
This is a 15-host sample on one day, not a survey. The practical point is narrower: on most of these hosts, cached validation at any listed CA would still be enough to issue. Check your own records against the CAA reference, and add accounturi for the CAs you actually use.
From the workshop
Two new pieces shipped this week. The timestamp converter guide covers seconds versus milliseconds, RFC 3339 and RFC 9557, the hour that repeats when daylight time ends, leap seconds, and the 2038 limit. The Kubernetes Service no-endpoints checklist walks through EndpointSlice conditions, selector mismatches, readiness gates, targetPort traps, and Services with no selector.
Recommended reading
- Read Google’s account of the ccTLD hijacks for the full operator guidance.
- Revisit Certificate Transparency explained to set up issuance alerts that cover every domain you own.
- Use the Kubernetes Service no-endpoints checklist the next time a rollout leaves a Service empty.
Frequently asked questions
How did attackers get trusted certificates for Google domains under .gh, .sl, and .as?+
Does a CAA record stop certificate issuance during a DNS hijack?+
Which Kubernetes feature gates must be removed before upgrading to 1.38?+
Who is affected by CVE-2026-19444?+
What should FortiMail administrators do now?+
What caused GitHub's October 5 Actions incident?+
Tags: #weekly-recap, #tls, #caa, #certificate-transparency, #kubernetes, #security, #sre