How did the attacker get into Kernel's systems?

Every fact here comes from Kernel's own notice, with no independent confirmation as of 2026-11-06. The notice says a compromised Kernel API key was used to probe for access, with the earliest activity listed on 24 October 2026. On 27 October the same party reached a staff login at Kernel's logging provider and downloaded data that held a small number of Kernel API keys and app deployments' third-party secrets. On 3 November a compromised credential for Kernel's hosting-provider account gave access to four GPU servers. The notice does not say how the first key leaked, and it does not say how the hosting credential was obtained.

What should teams running similar infrastructure take from it?

The notice reports three credential-based steps in order: an API key, a logging-provider login with downloaded data that included secrets, and a hosting-provider account. It does not say the hosting credential came from the logging data, and any such link is our hypothesis. Scoped keys, network restrictions on where keys can be used, rotation, and keeping secrets out of logs would each narrow this kind of exposure. Kernel lists wider adoption of scoped API keys across its customers, network controls for key use and better rotation among its planned changes.

Kernel Breach: Leaked API Key Led to…

Q: Is the ARTEX link confirmed?

No. Kernel says it believes the attacker is using the AI-assisted pentesting platform ARTEX as a command center. The notice gives no further detail on how ARTEX was used and publishes no indicators. Microsoft separately describes ARTEX as an open-source penetration testing framework that can use any AI model, and says Storm-0940 used it in a campaign against ConnectWise-linked targets that Microsoft reported on 21 October. We found no evidence as of 2026-11-06, in the Kernel notice or the Microsoft post, of a link between the two. Microsoft's post does not mention Kernel.

Kernel disclosed on 4 November 2026 that an attacker used a compromised API key, accessed data at its logging provider, and used a compromised hosting-provider credential to reach four GPU-enabled servers. All incident facts in this article come from Kernel’s own notice, and we found no independent confirmation as of 2026-11-06. The notice does not say how the hosting credential was obtained. Three of those servers ran Kernel browser sessions. A cryptominer was started on at least one. Kernel says the incident affected 0.28% of its customers and that it believes the attacker used the AI-assisted pentesting platform ARTEX. That last point is Kernel’s belief, not an established finding.

Incident Summary

Field	Detail
Organization	Kernel (kernel.sh)
Detected	2 November 2026 (customer escalation at 19:28 UTC)
Initial access	A compromised Kernel API key, earliest activity listed 24 October 2026; how it leaked is not stated
Reported steps	Staff login at a logging provider, then a compromised hosting-provider account credential; the notice does not say how the second was obtained
Systems reached	Four GPU-enabled servers; three ran Kernel browser sessions, one held no customer data
Payload	A cryptominer, started on at least one server
Customer impact	0.28% of customers, per Kernel
Attribution	Unattributed. Kernel assesses a financially motivated actor and believes ARTEX was used
Published indicators	None. Kernel offers a technical fingerprint on request

Timeline

All times are UTC and come from Kernel’s notice. The notice lists a few entries slightly out of order, and we have kept its ordering where unclear.

24 October, 21:18: a leaked API key is used to read data across internal profiles. Elsewhere the notice says the key was used “to probe for access.”
27 October, 18:01: the same party verifies access to Kernel’s logging provider through a staff login reached with the compromised key, then accesses and downloads data. The data held a small number of Kernel API keys and app deployments’ third-party secrets.
2 November, 19:28: an affected customer escalates an issue.
2 November, 22:20: incident-1 is declared at high severity. At 22:30 the API key is found and revoked, and at 23:50 severity is raised to critical.
3 November, 05:41 to 07:17: server-1 (development, no data) is accessed and a cryptominer starts. Servers 2, 3 and 4 follow, and the same miner is attempted on server-3 at 06:48.
3 November, 07:11: incident-2 is declared at critical severity. Kernel traces it to a compromised credential for its hosting-provider account.
3 November, 07:37 to 09:29: hosting-provider API keys are rotated and the servers are taken offline. At 09:00 Kernel establishes that incident-1 and incident-2 are the same actor.
3 November, 22:50: containment ends and customer communications are sent.
4 November: the public notice is published.

How the chain worked

Kernel’s notice describes no exploit. It reports three credential-based steps in this order.

The first key was valid and apparently broad, since it could read across internal profiles. The same party then reached a staff login at a logging provider and downloaded data that included a small number of Kernel API keys and app deployments’ third-party secrets. Later, a compromised credential for Kernel’s hosting-provider account gave access to the servers. The notice does not say the hosting credential came from the downloaded data. That link is plausible, since the data included API keys, but it is our hypothesis and the notice does not state it.

There is a gap in the record. The notice twice lists a root cause analysis as established (2 November 23:50 and 3 November 11:12, both entries also noting that all indicators of compromise were identified) but does not publish either. It does not say how the key leaked, how the staff login at the logging provider was reached, or how the hosting credential was obtained. We have not tried to fill those in.

Note the gap of about nine days between the earliest activity Kernel lists, on 24 October, and the customer escalation on 2 November. The notice describes the escalation as coming from an affected customer, and does not mention an internal alert. We read that as a detection gap, though Kernel does not use that phrase.

The ARTEX claim

Kernel says: “Our evidence suggests that the attacker(s) are financially motivated and this was a part of a larger cryptomining campaign.” It adds: “We believe they are leveraging AI-assisted pentesting platform ARTEX as a command center”. The notice says no more about ARTEX.

For context, Microsoft describes ARTEX as “an open-source penetration testing framework that can use any AI model,” and reported on 21 October 2026 that Storm-0940 used it for scanning, password spraying and OAuth application abuse in a ConnectWise-linked campaign. We have covered other ARTEX reports on this site, including the Storm-0940 report. Those reports concern other actors (Storm-0940 and the TAG-217 cluster), and we found no evidence as of 2026-11-06 in the sources above of a link to this incident. The sourcing here is one party’s own notice, so treat the ARTEX attribution as unverified.

Remediation and response

Kernel reports that it:

revoked the compromised credentials and removed the attacker’s access to the logging provider;
blocked the IP addresses involved, rotated every credential the servers could reach, and rotated its hosting-provider API keys;
took the affected servers offline, cloned server-1 for forensics, and audited access across its systems;
notified affected organizations with remediation guidance, and shared intelligence with the hosting and logging providers.

It lists planned changes: wider adoption of scoped API keys across its customers, network controls on where keys can be used, better key rotation, SIEM detections for this actor and dynamic blocking rules.

What this means

The pattern is old: valid credentials, a third-party store holding secrets, and a cryptominer at the end. What is new is how readily the claimed tooling could scale it, if the ARTEX link holds. We cannot say it does.

Our assessment for teams operating similar platforms:

Treat any API key that can read broadly as a tier-one secret, and scope it to one job.
Restrict where keys can be used from, so a leaked key fails off-network.
Scrub secrets before logs leave your boundary, and review what a third-party logging vendor’s staff can reach.
Alert on idle or unusual GPU compute. A miner on a development server with no data is a cheap early signal.
Do not rely on customers to find an intrusion. Here the earliest listed activity preceded the customer escalation by about nine days.

If you are a Kernel customer, Kernel says it has notified affected organizations. Kernel gives [email protected] for questions and [email protected] for requesting its attacker fingerprint.

Kernel Breach: Leaked API Key Led to GPU Servers and a Cryptominer