Skip to content
Control Plane Labs

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.

Frequently asked questions

How did attackers get trusted certificates for Google domains under .gh, .sl, and .as?+
They compromised the country-code registries and changed authoritative DNS records, which let them pass domain-control validation. Google says the issuing CAs did nothing wrong; the certificates were found in CT logs, rejected by Chrome through CRLSets, and revoked.
Does a CAA record stop certificate issuance during a DNS hijack?+
No. An attacker who controls DNS can change CAA too. Restrictive CAA with RFC 8657 accounturi and validationmethods limits which accounts and methods can issue, which helps stop reuse of cached validation once you regain control.
Which Kubernetes feature gates must be removed before upgrading to 1.38?+
Remove SeparateTaintEvictionController from kube-controller-manager flags before upgrading. Also drop references to removed gates such as DynamicResourceAllocation and KubeletTracing, and any explicit false for DRADeviceTaints or DRADeviceTaintRules.
Who is affected by CVE-2026-19444?+
Only Windows users who run kubectl cp to copy files from a container they don't fully control. Upgrade to kubectl 1.34.12, 1.35.9, 1.36.5, or later.
What should FortiMail administrators do now?+
Check Fortinet's advisory FG-IR-26-175 for fixed builds, hunt with the published indicators of compromise, and until patched disable IBE or restrict web access to the management interface to trusted sources.
What caused GitHub's October 5 Actions incident?+
A partial networking failure between an on-premises datacenter region and cloud-hosted database and storage services. Hosted runners were degraded from 18:48 to 22:49 UTC; self-hosted runners were not affected.

Tags: #weekly-recap, #tls, #caa, #certificate-transparency, #kubernetes, #security, #sre